More mulch faster was never the goal. I've watched a lot of people put their foot on the gas over the last few months and steamroll out a mountain of code using the latest generation of model-assisted tools. I've done it myself. I wrote recently about the burnout that comes from indulging in extreme concurrency - running a swarm of agents, producing at a pace that outstrips your capacity for comprehension - and I think it's worth unpacking why that approach, while intoxicating, is probably a trap. It's something I've changed in myself over the last month or so to try stem the flow of blood and find, new, good, working patterns. The instinct to parallelise everything is the wrong instinct. I think it's a fool's errand to focus on concurrency as your primary workflow. You'll still end up with unfinished projects, but this time they'll be unfinished projects that you don't understand. This isn't really a new thought - we've long understood that focus time for software teams always wins. Because of this, over the last couple of weeks I've taken to preferring what I'm going to call Co-Design with agents over raw parallelism. I think I've probably been stumbling towards these working patterns since the end of last year, but I've only recently started to articulate them and understand them as a set of workflows. This isn't the same thing as what most people seem to be describing as "human in the loop". Whenever I see people talk about human in the loop, I see a pattern focused on after-the-fact PR style review of machine generated code. I suspect that model is already dying under the weight of its own volume constraints. After-the-fact review will become arduous, long-winded, and ineffective as the pace of code generation accelerates. PR workflows in organisations will probably take longer to die that we expect because people will cling to their existing, familiar, illusion of safety. Pull requests - an adversarial technique for untrusted authors to contribute to critical codebases - were never designed for the kind of workplace collaboration they're normally used it, and were always worse than code review and pair programming and we shouldn't lament their death. With some sense of symmetry, traditional pair programming with the machine is also better than after-the-fact adversarial review. Focusing on raw output and concurrency is the same mistake it ever was, because quality subsides underneath it. Even if you personally don't care about the quality of the output, even in a world where models are generating most of the glue code, quality still matters for software that has to operate reliably in production. Many of these assurances on quality don't map to one-shotting consumer grade "apps", but they absolutely matter when you operate systems. Context Matters with Regards to Quality It's important to realise that much of what good looks like when it comes to adapting to model assisted development in enterprise are echos of the lessons we learnt twenty-five years ago in the extreme programming movement. This is an adaptation of technique to new tooling. The people that were sceptical or ineffective at writing tests, doing TDD, verifying their code in automated, system-driven ways will continue to be resistive to these techniques and will end up with very poor, low quality outcomes. The context of the kinds of change you're working on - especially in business software - change how effective these practices are. Models are mostly good at remixing existing ideas - which might sound limiting, but it's largely fine in business software where the vast majority of programming and systems integration work is remixed work to start with. The inverse is also true. people just saying "give me code that does X" are going to receive poor quality results, because quality of specification always begets quality of implementation. I wrote a talk about fifteen years ago about how the gulf of understanding between specification and implementer was the quality ceiling of all software. That gap defined how good the software could possibly be. This will play out en mass with low quality tool usage - the specification problem doesn't go away just because the implementer is a machine. If anything, it gets worse, because models lack the social context and domain intuition to fill in the gaps that a human colleague would. This isn't a new problem. It's common to all code generation, low-code solutions and other boilerplate-centric techniques. Despite all this, it seems to me today that anyone that can't get roughly 80% good outcomes from the current early 2026 frontier models is experiencing operator error. The tools are good enough. The question is the same one of technique. The reality is that most people have never really cared about technique or code quality - this isn't new either. The same people that achieved poor results before will continue to do so using new tooling. The accelerant doesn't change the traj