The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 1,839 other subscribers

Mumbly_Bum excellent comments on “AI is working great for my team, and y’all are making me feel crazy”

Posted by jpluimers on 2026/06/24

Planning and feedback loops in extreme programming

Planning and feedback loops in extreme programming

TL;DR:

Using LLM in the software development process is shifting the feedback cycle to the top of the development cycle in the graph on the right. This is a costly endeavour.

LLM deliver output that is statistically likely, decreasing the chance to incorporate outliers as they are statistically unlikely but form the burden of software development.

[Wayback/Archive] Mumbly_Bum comments on AI is working great for my team, and y’all are making me feel crazy

Most of our tickets are now (initially) generated using Claude + the Atlassian MCP, and that’s allowed us to capture missed requirements up-front.

I think this is the key disconnect (even taking into account the notes from meetings) in understanding our jobs and why we’re not going away and why LLMs create harm in delivery.

A developers’ job is to reduce ambiguity. We take the business need and outline its logic precisely so a machine can execute. The act of writing the code is the easy part.

Odds are, you aren’t creating perfect code specs into tickets, even with meeting notes, because developers will encounter edge cases that demand clarification over the course of implementation. That makes a feedback loop to the customer. Those edge cases (where a substantial proportion of the work comes from) often don’t get discovered ahead of time.

LLMs are sycophants. They won’t be watching, skeptically, for assumptions that are excluded in coded conditionals and api calls. They produce legitimate-looking code, and if no one has had the experience of thinking through the assumptions and then writing them into code – considering the edge cases- it’ll be lgtm’d and shipped. You’re shifting the burden of this feedback cycle to the right, after the code is output, and that makes us worse off since code is tougher to read than write.

And that’s not even getting to consider that the requirements no one’s bothered to digest are well written.

I’ve gotten into the habit of tacking “-ai” into google because when I read that top blurb, I’m already influenced to think a certain answer. I can’t imagine how getting flooded with LLM- generated requirements would steer a software project over time.

Slowly, no one will own the requirements, and no one will own the development, but that won’t change that it’s your job on the line when the product is in customers’ hands.

Mumbly calls the top of the above graph “to the right” as often the development process is not drawn as a feedback cycle but as a timeline:

6 phases of the software development life cycle (SDLC)

6 phases of the software development life cycle (SDLC)

[Wayback/Archive] image-11-1024×452.png (1024×452)

Topmost picture from Extreme programming – Wikipedia.

SDLC picture from [Wayback/Archive] From Idea to Launch: Journey of a Successful Software Product Development. – StatusNeo which despite StatusNeo claiming “Achievements, Agile, Data, Knowledge, Scrum, Software Development, Software Development Life Cycles, Technology” isn’t Agile or Scrum at all.

--jeroen

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.