I'm not sure I agree with that. Many (or most) of the software engineers I know find the heavy reliance on AI coding agents/assistants pretty soul-sucking and uninteresting. I feel the same, and I'm looking for some kind of middle ground. For example, I will only use agents when doing so would not deprive me of learning and discovery.
Also peppered with a lot of bad, redundant writing: "That’s the shape I’m watching for. That’s the shape I think wins." - those sentences both say the same thing and you didn't need either of them.
I feel like that indicates they may not have understood HOW to write a coherent and professional article here, or, indeed, an article worth reading. They clearly understood WHY - they wanted lots of attention and to show how big of an AI booster they are but WHAT they wrote was a lot of gibberish because they didn't know HOW to write.
All of these inputs are rarely well-defined. that's the crux of the whole agile manifesto
Ah ok, wait until Anthropic sends you the bill.
How do you think the How people learn how to How at the deepest layer when something genuinely hard breaks?
This jumped off the page to me and it's an assumption that underlies everything else in the article. For the record I agree with the author that if it is true that 95% of the codebase should be unsupervised, the how layer does indeed become very small.
But my experience has given me little reason to believe that it's true. Code doesn't conveniently break in the 5% you choose to care about. Systems fail in seemingly random places very often in the seemingly uninteresting parts of the system. The macro and micro decisions that make code actually work have to be of high quality everywhere. They have to be fixable in the worst case by a human and that still very much requires a human to review nearly everything the agents generate.
As always there's a risk-management question here. You can choose to take on a lot of risk by increasing the amount of code that only agents touch. And maybe I am still too in the oughts with a belief that code should be secure, do what it says, and do it reliably. Turning over your code to unsupervised agents in such large quantities amps that risk level up to a place that I (at least) am not comfortable with it.
So ya I think the author is right in their model. Why, what, how is a great way to think about orgs. I agree that the output of the how layer has been pretty turbocharged and I agree that the how layer is going to shrink but I think I disagree with them by how much.
I don't think an executive's job is why, it's strategy (what in the long term).
I also think what/how questions are inextricably interlinked -- what we should build depends on whether or not we can build/maintain it cheaply enough.
Here's where I do agree -- I do think the AI era changes how companies work, it does make them smaller, that reduction in size reduces the amount of filler roles (project managers), and this will be a great benefit to the bottom line. Though ideally this means more competition so that benefit goes to the consumer too.
AI can certainly look at more user feedback than executives can...
Or you could have more work being outputted that isnt really relevant but is trying to pad up a resume. Same number of people remaining but more noise to see through
Middle managers were not “waste”, they served a social function of creating stability and managing workloads.
I think the proposed “new model” probably doesn’t scale. Also probably a single human can’t comfortably do that many things.
We don’t build orgs to maximally squeeze every drop of productivity and leave behind an empty human husk. Orgs have grown as a negotiated balance between the desire of the capitalist at the top for high productivity, and the desire of the contributors at the bottom for stability. The layers of management in between provide an interface that makes this possible.
We’re going to see a couple years of companies crashing and burning trying this “AI native” thing.
I mean, I guess. But I thought the romantic ideal and sometimes, some rare times actually the real lived experience was that what made these people founders was their ideas, their drive, their focus, belief in an idea, their ability to make space for people to take part in their plan etc.
If that is getting delegated to Claude, it kind of sounds like they shouldn’t really be expecting the big bucks.
If it’s just going to be some wealthy kid with an idea they had in the shower and Claude, why would anyone want to be part of that?
Every part of this article makes me fear for our souls, like, sure, you’re a great developer but understand that your manager who is already not listening to your concerns has got Codex on his side telling him he’s got rare insight.
In my experience this is what a lot of product managers do but more importantly they are talking to users, talking to stakeholders, and having discussions with the the team to define the product. His description seems more of the project manager role.
> If a manager isn’t contributing to the why, the what, or the trust system that holds the how, it’s hard to say what they’re doing.
I think people management is a large part of engineering management. There are definitely other aspects that are significant but I the author made no argument for AI taking over people management nor did they really mention it at all. Also if the other work is all translation and is getting compressed, I don't think the author made any argument as to why the 'non contributing manager' suddenly has to contribute?
Seems like the author's old thesis was that non-contributing managers are inefficient or something. Then, without really explaining why they are saying that AI has made his argument stronger.
Every engineering decision and debate I have seen has always boiled down to 2 things "people don't know the motivation for an action" and "people have incomplete knowledge of the situation". Normally both. Every single conversation, when poised in a "this is the high level goal" context, went from a debate to a constructive design session in seconds.
Failure to "propagate the why" is a tar-pit for execution and decision making.
> The 5% of the codebase the agent shouldn’t touch unsupervised
WOW.
Sorry, the combination of my eyes rolling into the back of my head while simultaneously vomiting distracted me.
I'm ok now, continue.
It matches my other experiences with the PR industry - they'd often have blanket bans on the usage of certain phrases, terms or references to "uncomfortable" events.
I'm pretty sure this goes for bots on social media too. Indirect references to slop (particularly where it is due to a skill issue) - fine. Just Don't Mention The Word.
