The consequences of task switching in supervisory programming
martinfowler.com
martinfowler.com
> But by weeks 7 or 8, one team hit a wall. They could no longer make even simple changes without breaking something unexpected. When I met with them, the team initially blamed technical debt: messy code, poor architecture, hurried implementations. But as we dug deeper, the real problem emerged: no one on the team could explain why certain design decisions had been made or how different parts of the system were supposed to work together. The code might have been messy, but the bigger issue was that the theory of the system, their shared understanding, had fragmented or disappeared entirely. They had accumulated cognitive debt faster than technical debt, and it paralyzed them.
You could argue LLMs let me learn enough about the product I was trying to build that the second rewrite was faster and better informed, and that’s probably true to some degree, but it also was quite a few weeks down the drain.
it acts as a guide for the LLM too, so it doesn't have to just come up with everything on its own in terms of style or design choices in terms of consistency I'd say?
If you have a solid architecture they can be almost prescient in their ability to modify things. However they're a bit like Taylor series expansions. They only accurate out so far from the known basis. Hmm, or control theory where you have stable and unstable regimes.
For me, anyway.
I design as I code, the architecture becomes more obvious as I fill in the detail.
So getting AI to do bits, really means getting AI to do the really easy bits.
As someone who gets quickly bored with repetitive work, this is big though.
That's my hunch too.
The problem isn't "I don't understand how the code works", it's "I don't understand what my product does deeply enough to make good decisions about it".
No amount of AI assistance is going to fill that hole. You gotta pay down your cognitive debt and build a robust enough mental model that you can reason about your product.
I think of cognitive debt as more of a product design challenge - but yeah, it certainly overlaps with abstraction debt.
https://www.reddit.com/r/ExperiencedDevs/comments/1g2l3wc/bo...
Some people like the deep work, some like managing a steady rain of chaos. There's no one right answer. But I'll tell you that my classmates who are happy as nephrologists are very different to the ones that are happy as transplant surgeons.
I wasn't aware one could get 'practical experience' "instantly." I would assume that their instant change of heart owes more to other factors. Perhaps concern over the source of their next paycheck? You have admitted you just "forced" them to do this. Isn't the question then, why didn't they do it before? Shouldn't you answer that before you prognosticate?
> that junior developers will still be needed, if nothing else because they are open-minded about LLMs
You're broadcasting, to me, that you understand all of the above perfectly, yet instead of acknowledging it, you're planning on taking advantage of it.
> I think the equivalent of cruft is ignorance
Exceedingly ironic.
> Will two-pizza teams shrink to one-pizza teams
The language you use to describe work, workers, and overcoming challenges are too depressing to continue. You have become everything we hated about this profession.
(Based on your comment history I'm guessing you haven't experienced this yourself yet.)
So far it's all been endless unfounded FOMO hype by people who have something to sell or podcasts to be on. I am so tired of it.
I know you'll dismiss that as the same old crap you've heard before, but it's pretty widely observed now.
a year ago they could easily one shot full stack features in my hobby next.js apps but imploded in my work codebase
as of opus 4.6 they can now one shot full features in a complex js/go data streaming & analysis tool but implode in low latency voice synthesis systems (...for now...)
just depends on how you're using it (skill issues are a thing) and what you're working on
The only other code that I write is for a handful of industry specific products that are not challenging in any way to code but are fun to design for the specific needs of my users and are informed by their incredible feedback from the field. The time and effort to play games with an LLM prompt would have effectively zero value here and again is the opposite of what makes these products great enough to be sold by word of mouth alone.
Aside from all of this I have no desire to pay a subscription to a service that requires me to submit all of my code to their engine for output. Given their models apparent fondness for taking copyrighted code and passing it off as it's own I would not put it past them to play games behind my back with my work.
Finally I see no new "AI billionaires" suddenly rising out of the field and I see no "AI heavy" companies suddenly increasing their profits, productivity or quality in any way. I hear what you are saying, and you're certainly not alone in saying it, but I see zero evidence that it's actually meaningful in the real world software market.
My experience (as someone how works with a team of PhD's) is that code is about 30% of what we do but in these, 75% are "trivial things" (building charts, quickly designing apps to process information, etc). Out of these 75%, AI certainly helps us at least 50% of the time (and amazes me 10% of the time :-))
> I see no new "AI billionaires" suddenly rising out of the field and I see no "AI heavy" companies suddenly increasing their profits, productivity or quality in any way.
Exactly what I was telling myself yesterday. That's rather not in line with the media coverage.
However, it's been a full quarter now since November 2025.
Based on facts on the ground, i.e. the rate and quality of new software and features we observe, change has been nowhere as dramatic as your comment would suggest.
It seems to me that a possible explanation is that people get very excited about massive speedups in specific tasks, but the bottleneck of the system shifts somewhere else immediately (e.g, human capacity for learning, team coordination costs, communication delays).
I think it's a bit early to expect to see huge visible output from these new tools. A lot of people are still spinning up on them - learning to use a coding agent effectively takes months.
And for people who are spun up, there's a lot more to shipping new features and products that writing the code. I expect we'll start to see companies ship features to customers that benefited from Opus 4.5/4.6 and Codex 5.2/5.3 over the next few months, but I'm not surprised there hasn't been a huge swell in stuff-that-shipped in just the ~10 weeks since those models become available.
There is one notable example that's captured the zeitgeist: https://github.com/openclaw/openclaw had its first commit on November 25th 2025, 3 months later it's had more than 10,000 commits from 600 contributors, attracted 196,000 stars and (kind-of) been featured in a Superbowl commercial (apparently that's what the AI.com thing was, if anyone could get the page to load - https://x.com/kris/status/2020663711015514399 )
The more the test suite grows, the more you & future agents will be able to consult it to understand how things should work - but also, why.
Imagine a test case that covers some non-compliant API response from a third party. The commit that’s tied to, the date the test was added, all that becomes metadata.. and the fact it’s executable means your agent can’t undo that fix without something very visible in the PR.
Software engineering is different from programming. Other kinds of engineers often ridiculed software engineers as "not real engineers" because mainstream engineers never had to build arbitrarily complex software systems from scratch. They have never experienced the cascading issues which often happen when trying to make changes to complex software systems. Their brief exposure to programming during their university days gave them a glimpse into programming but not software engineering. They think they understand it but they don't.
Other engineers think that they're the only ones wrestling with the laws of nature.
They're wrong. Software engineering involves wrestling with entropy itself. In some ways, it's an even purer form of engineering. Software engineering struggles against the most fundamental forces and requires reasoning skills of the highest order.
I think software engineers will be among the last of the white collar professions to be automated besides the ones which have legal protections like lawyers, judges, politicians, accountants, pilots... where a human is required to provide a layer of accountability. Though I think lawyers will be reduced to being "official human stamping machines" before software engineers are reduced to mere Product Owners.
It's kind of terrifying to think that all professions are going to have to shift away from value creation to pure politics to survive.
I have a feeling that big tech companies will be legally forced to pay royalties to software engineers. Once software engineers stop applying their reasoning skills to solving real problems and start vengefully focusing it on politics, we're going to corrupt the whole system in our favor. We have enough collective knowledge to frame such corruption as moral in the context of an already corrupt system.
Either software engineers will create regulatory moats for themselves or there will be a more broad political movement like communism. I've met many people working deep in the critical systems which underpin our society who are full-blown communists.
Software engineers in aggregate will happily automate themselves out of a job. Legal cartels like the AMA and the ABA will persist. It would take years of strong threats to software engineers' livelihoods to compel them to support a cartel of their own. Even the first step for their regulatory capture, credentialization, is rejected, as enough autodidacts without degrees practice in the field.
Essentially, too many software engineers view themselves as temporary embarrassed millionaires, rather than workers who need to band together. Automation in the field is happening faster than individuals' minds will change.
GeLLMan Amnesia – AI can fully automate every profession except the ones I’m deeply familiar with.
I’m a software engineer who wears the product owner hat a lot these days, there’s no way AI will automate this any time soon. Too much peopling and accountability.
It’s scary how quickly people start to mistake LLMs appeasing them for actual conversation.
Discussing something with an LLM isn’t equivalent to having a conversation with a person. It’s just a text generator trained to show you what you want to see.
YMMV. Ask the bot for supporting evidence, and follow up on google/wikipedia.
You can try something like this on Gemini 3 Pro:
> Break down aspects of the economy by amenability to state control high/medium/low, based on what we see in successful economies. Include a rationale and supporting evidence/counterexamples. Present it in 3 tables.
It should give you dozens of things you can look up. It might mention successful Singapore and Vienna-style public housing. Some nice videos on that on Youtube.
Online discussions are usually at the level of "[Flagged] Communism bad".
Because of that good fortune, it hasn't occurred to me to use an LLM to organize information for these topics. I appreciate your sharing your approach and I look forward to trying this use case of LLMs.
I've been doing this for more than 25 years.