> 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.
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.
1. The "black box" problem — you accept generated code without fully understanding it, and later can't debug or extend it because you never built the mental model.
2. The "context fragmentation" problem — you're constantly switching between reviewing AI output, correcting course, and holding your own design intent in your head. It's like pair programming with someone who has perfect syntax recall but zero memory of what you discussed 5 minutes ago.
The teams that seem to avoid the wall are the ones who treat AI as a drafting tool rather than a decision-making tool. You still need to be the architect. The AI just types faster than you do.
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.)
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).
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.
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
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.
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.
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.