AI News HubLIVE
站内改写

What If the Real Key to AI Coding Is Old-Fashioned and Boring?

The article argues that the key to AI-assisted software development is not better specifications or tools, but old-fashioned practices of small batches and rapid feedback loops. Data shows that faster code generation leads to bottlenecks in design, testing, and review, slowing delivery and reducing stability. The real leverage lies in reducing batch sizes and shortening feedback cycles.

Article intelligence

EngineersAdvanced

Key points

  • AI code generation speeds up creation but creates bottlenecks in design, testing, and review.
  • Data from DORA, CircleCI, and Faros shows slower delivery and less stability due to phase-gated processes.
  • The solution is reducing batch sizes and shortening feedback loops.
  • The author suggests 'feedbackmaxxing' as a modern term for these practices.

Why it matters

This matters because AI code generation speeds up creation but creates bottlenecks in design, testing, and review.

Technical impact

May affect model selection, inference cost, product capability, and evaluation benchmarks.

“The key to AI-assisted and agentic software development is ”

The Big Design Up-Front folks say the key is better specifications. The plan-driven folks say it’s better plans. The architects say it’s better architecture. The product managers say it’s better product management. The command-and-control folks say it’s better agent orchestration. The test automators say it’s better test suites. The folks selling static analysis tools say it’s better automated code reviews. The folks selling the models say… well, we know what they say. MORE TOKENS!!!

It’s true that I’m also claiming that the key to AI-assisted software development is something I just happen to specialise in – development practices that work in small batches and rapid feedback loops.

The difference is that the data’s led me back here, just like it led me to it in the first place.

advertisement

The only thing that AI code generation has really changed is the speed at which code’s generated and the amount of code that needs designing, testing, reviewing, refactoring and integrating.

Data collected on thousands of teams by the DevOps Research & Assessment group shows code being created faster, only to end up languishing in queues waiting for user feedback, design decisions, testing, review and merging to the release branch. Net effect – slower delivery and less stable releases.

Data collected on millions of CI workflows by CircleCI shows code being created faster on developer branches, only to end up languishing in queues waiting for user feedback, design decisions, testing, review and merging to the release branch. Net effect – slower delivery and less stable releases.

Data collected on thousands of teams by Faros shows code being created faster on developer branches, only to end up languishing in queues waiting for user feedback, design decisions, testing, review and merging to the release branch. Net effect – slower delivery and less stable releases.

The problem is what it always was – phase-gated development processes that try to handle design, testing, review, refactoring, merging and releasing large batches of changes.

You can’t specify your way out of it. You can’t architect your way out of it. You can’t automate your way out of it (because judgement will always be needed – Actual Intelligence). You can’t product manage or type-check or DDD or team topology your way out of it.

That’s not to say these things bring no value. They all do.

But batch sizes and feedback loops hold the biggest leverage here, by orders of magnitude. They always did and they always will.

But who wants to hear about taking smaller steps, right? That’s just boring stuff from the 1990s.

Would it help if I called it “feedbackmaxxing”?