I'm not a coder, I'm a medical doctor. I see some interesting parallels in how medical students sort themselves into specialties by cognitive style to this new rift in programming with LLMs.
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.
> a third of them were instantly converted to being very pro-LLM. That suggests that practical experience
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.
The term he’s searching for is possibly “intellectual control”: https://www.georgefairbanks.com/ieee-software-v36-n1-jan-201...
If after 7 or 8 weeks you can’t change the software, it’s wise to start putting tests in to document retroactively how things work / worked and why.
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.
the cognitive debt framing clicks for me. I've been using claude code on a laravel project and the thing that actually keeps velocity up isn't the AI getting better, it's me writing tests first. sounds boring but when the LLM generates code against an existing test suite it basically has to follow your architecture. you keep the mental model because you wrote the tests, and the AI keeps the codebase coherent because it has concrete constraints to work against. without that the codebase drifts into this weird state where technically everything works but you can't reason about any of it.
Part of me feels like LLMs will struggle to architect code properly, no matter how good they get.
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.
I like the idea of "cognitive debt" vs "technical debt".
[dead]
[dead]
This cognitive debt bit from the linked article by Margaret-Anne Storey at https://margaretstorey.com/blog/2026/02/09/cognitive-debt/ is fantastic:
> 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.