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.
> 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.
If you haven't experenced a post-November-2025 coding agent before and someone coaches you through how to one-shot prompt it into solving a difficult problem in your own codebase that you are deeply familiar with I can see how you might be an almost instant convert.
(Based on your comment history I'm guessing you haven't experienced this yourself yet.)
> 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.
Appreciate Simon sharing this here, the discussion is helpful. I’m especially curious how teams are mitigating knowledge loss when AI accelerates code production. Would love more concrete examples from folks doing this in practice.
On a possible concrete mitigation strategy. I wrote up a pattern that seems to be working for me as I push through a brownfield migration. It's a little mental model file. Always human edit. Agent checks for falseness only. I started calling it `HITL.md`
https://warrenwhipple.com/hitlhttps://github.com/warrenwhipple/hitl
Curious if you've seen anything like it. Or whether you think it can scale to teams/PR workflows.
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.
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.
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.
14 comments
[ 3.1 ms ] story [ 42.3 ms ] threadSoftware 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 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.)
> 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.
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.
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.