Show HN: An addendum to the Agile Manifesto for the AI era

2026-03-1320:48715github.com

An addendum to the Agile Manifesto for the age of AI - brackishman/Agile-Manifesto-AI-Addendum

We are uncovering better ways of developing software alongside AI. Through this work we have come to value:

Shared understanding over working software

Independent challenge over efficient agreement

Teaching the why over delivering the what

Pace of learning over pace of shipping

That is, while there is value in the items on the right, we value the items on the left more.

"Individuals and interactions over processes and tools" argues that people matter more than process. This addendum argues that what those people understand matters more than what they produce with AI.

"Working software over comprehensive documentation" argues that working software is more important than documentation. This addendum argues that the way we arrive at working software matters. It is no longer the case that working software is proof that the team understood the problem.

"Customer collaboration over contract negotiation" argues that understanding develops in conversations with the customer, not in the contract. This addendum extends this argument inward to the conversations between team members.

"Responding to change over following a plan" argues we should respond to change rather than following a rigid plan. This addendum argues that people cannot respond to change if they do not understand what they already built.

The twelve principles behind the Agile Manifesto still hold. Three need refinement:

3. Deliver working software frequently, but never faster than it can be deeply understood.

7. Shared understanding of the systems we build, demonstrated through working software the team can explain, is the primary measure of progress.

8. Agile processes promote sustainable development. Sponsors, developers, and users should be able to maintain a constant pace of building shared understanding indefinitely.

"Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale." The original optimizes for delivery speed because delivery and understanding were intertwined. The update acknowledges that AI broke this assumption, and requires the team to understand a solution before delivering it.

"Working software is the primary measure of progress." The original assumed that working software was a proxy for understanding. The update makes explicit what the original was tracking by proxy.

"Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely." The original protects against burnout from overwork. The update recognizes that burnout also comes from the accumulated cost of maintaining code the team doesn't understand.

Matthew Cullum
VP of Engineering, thatDot Inc.
March 13, 2026

Twenty years leading software engineering teams, from system architecture to organization design.

LinkedIn


Read the original article

Comments

  • By stevenalowe 2026-03-144:42

    The proposal elevates team learning above delivering working software, which is contrary to the point of any programming job. Expect to be fired, a lot.

  • By disrael 2026-03-1323:33

    I like what you've done but doesn't

    Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

    need changing also? I think the software needs to be delivered early and continuously, but not necessarily to the customer in production.

    Delivering directly to the customer made sense when there was much less software in the world and nearly anything you made was useful. These days the last thing customers need is more half baked software to have to evaluate.

  • By smackeyacky 2026-03-1321:471 reply

    It’s pretty obvious that Agile as practiced in most places is a failure, only highlighted by how fast coding has become. The problem it tries to solve was always the wrong one. It has become obvious that it isn’t the speed of iteration it’s the crappy requirements most organisations generate.

    This is because your average BA or project manager have long gotten away with blaming programmers for missed deadlines. If you’ve worked both sides of the fence you know the users only vaguely know what they want, the BA role is essentially an incredibly lazy one (I made a wrong ticket but nobody knows it’s wrong until UAT so who gives a fuck about making them right). No matter how your sprint is organised or how many stupid ceremonies you insist on, if you can’t be arsed doing the hard work of specification the whole process is pointless.

    I truly hope AI starts doing 100% of the coding so that the tide properly goes out on this farce.

    • By Kim_Bruning 2026-03-141:061 reply

      Oh, my impression is that there's many iterative approaches to writing code (and doing other things besides). All of them work for a while, and then either someone "simplifies" out the iteration part, or in some way they render the iterative part toothless.

      Basically you end up with something resembling a cargo cult, with all the rituals still there, but the tightly coupled feedback loop is missing.

      Quick question: There's some sort of minor UAT ~once a week (or per whatever your cycle is), RIGHT? And then you find out umpteen things wrong (with the software and with the specs) , and you fix them; RIGHT?

      If you have an actual commissioning or final UAT at the end of your project, it's just a formality with cake RIGHT?

      Else how is that even agile? :-P

      • By smackeyacky 2026-03-142:471 reply

        I yeah, I’m holding it wrong that’s the problem. Agile suffers from the “no true Scotsman” fallacy to a massive extent. If the methodology was any good nobody would be arguing whether they were doing it wrong or not.

        My contention is not “holding it wrong”, my contention is that it’s irredeemably flawed because the nature of it puts 99% of the actual (not fabricated) work and responsibility solely on developers, making the project manages and BA useless noise you have to fight just to get anything finished.

        • By Kim_Bruning 2026-03-144:12

          Heh, you are probably not wrong? It's not that you're holding it wrong. It's just you're more likely to have gotten a cargo cult version of it by now, so there's no way to hold it right in the first place. Agile isn't the first and isn't the last iteration of this particular pattern.

          Extreme Programming, RUP, Spiral Model, RAD, DSDM, probably some variants of CMMI, ISO 9001 , we can continue this list for a while or even get into other disciplines. Each time you start out with a real feedback loop doing real work, and in the end everyone has cargo culted it. Mostly because a lot of people don't grok what feedback loops are, and think they can leave 'em out. I'm not even sure the project managers and BAs are the only ones to blame here. The whole organization conspires to replace scary feedback (and it really is scary!) with comfortable processes. Users don't want to talk to devs. Devs don't want to ship half-baked things. Managers need predictability for their spreadsheets. Everyone gets the cargo cult they deserve. "We mostly just took the good parts" := We left out the active ingredient.

          After a while someone comes along with this radical new invention: "let's ACTUALLY apply a feedback loop", and here we go again.

          To be fair, it DOES work for a while. you can start out dressing in drag and doing the hula[1] for all I care, so long as you iterate and run a feedback loop! At some point you'll actually successfully build a million dollar product anyway. .... Of course people will then copy you and dress in leaf skirts and dance all night long, and THEIR projects all fail.

          This has been "Kim's overly oversimplified history of innovation in development methodologies". You're welcome, I'm sure.

          [1] https://www.youtube.com/watch?v=Etkws_5mexg

HackerNews