> And there was something else: most early startups need to pivot, changing direction as they learn more about what the market wants and what is technically possible. By lowering the costs of pivoting, it was much easier to explore the possibilities without being locked in or even explore multiple startups at once: you just tell the AI what you want.
In my experience so far, AI prototyping has been a powerful force for breaking analysis paralysis.
In the last 10 years of my career, the slow execution speed at different companies wasn't due to slow code writing. It was due to management excesses trying to drive consensus and de-risk ideas before the developers were even allowed to write the code. Let's circle back and drive consensus in a weekly meeting with the stakeholders to get alignment on the KPIs for the design doc that goes through the approval and sign off process first.
Developers would then read the ream and realize that perfection was expected from their output, too, so development processes grew to be long and careful to avoid accidents. I landed on a couple teams where even small changes required meetings to discuss it, multiple rounds of review, and a lot of grandstanding before we were allowed to proceed.
Then AI comes along and makes it cheap to prototype something. If it breaks or it's the wrong thing, nobody feels like they're in trouble because we all agree it was a prototype and the AI wrote it. We can cycle through prototypes faster because it's happening outside of this messy human reputation-review-grandstanding loop that has become the norm.
Instead of months of meetings, we can have an LLM generate a UI and a backend with fake data and say "This is what I want to build, and this is what it will do". It's a hundred times more efficient than trying to describe it to a dozen people in 1-hour timeslots in between all of their other meetings for 12 weeks in a row.
The dark side of this same coin is when teams try to rely on the AI to write the real code, too, and then blame the AI when something goes wrong. You have to draw a very clear line between AI-driven prototyping and developer-driven code that developers must own. I think this article misses the mark on that by framing everything as a decision to DIY or delegate to AI. The real AI-assisted successes I see have developers driving with AI as an assistant on the side, not the other way around. I could see how an MBA class could come to believe that AI is going to do the jobs instead of developers, though, as it's easy to look at these rapid LLM prototypes and think that production ready code is just a few prompts away.
5 years ago: ML-auto-complete → You had to learn coding in depth
Last Year: AI-generated suggestions → You had to be an expert to ask the right questions
Now: AI-generated code → You should learn how to be a PM
Future: AI-generated companies → You must learn how to be a CEO
Meta-future: AI-generated conglomerates → ?
Recently I realized that instead of just learning technical skills, I need to learn management skills. Specifically, project management, time management, writing specifications, setting expectations, writing tests, and in general, handling and orchestrating an entire workflow.
And I think this will only shift to the higher levels of the management hierarchy in the future. For example, in the future we will have AI models that can one-shot an entire platform like Twitter. Then the question is less about how to handle a database and more about how to handle several AI generated companies!
While we're at the project manager level now, in the future we'll be at the CEO level. It's an interesting thing to think about.
> I think many people have the skills they need, or can learn them, in order to work with AI agents - they are management 101 skills.
I like his thinking but many professional managers are not good at management. So I'm not sure about the assumption that "many people" can easily pick this up.
> I find it interesting to watch as some of the most well-known software developers at the major AI labs note how their jobs are changing from mostly programming to mostly management of AI agents.
"AI labs"
Can we stop this misleading language. They're doing product development. It's not a "laboratory" doing scientific research. There's no attempt at the scientific method. It's a software firm and these are software developers/project managers.
Which brings me to point 2. These guys are selling AI tooling. Obviously there's a huge desire to dogfood the tooling. Plus, by joining the company, you are buying into the hype and the vision. It would be more surprising if they weren't using their own tools the whole time. If you can't even sell to yourself...
The limiting factor at work isn't writing code anymore. It's deciding what to build and catching when things go sideways.
We've been running agent workflows for a while now. The pattern that works: treat agents like junior team members. Clear scope, explicit success criteria, checkpoints to review output. The skills that matter are the same ones that make someone a good manager of people.
pglevy is right that many managers aren't good at this. But that's always been true. The difference now is that the feedback loop is faster. Bad delegation to an agent fails in minutes, not weeks. You learn quickly whether your instructions were clear.
The uncomfortable part: if your value was being the person who could grind through tedious work, that's no longer a moat. Orchestration and judgment are what's left.
Deciding what to build and catching when things go sideways (and I'd add: engineering things so that you can better deal with things going sideways) was always the limiting factor.
Sure, writing code was slower before the agentic coder era, but as people coded their understanding of what they coded grew with them while coding and that allowed people to make informed decisions on what to do next and how to fix things when they go sideways.
By replacing the human who writes code with an agent that does it but faster doesn't necessarily improve the speed of the overall process by the same amount. Some of the time saved in producing code is simply shifted elsewhere: to reading, validating, and reconstructing the understanding that previously emerged naturally while writing. If the human still needs a sufficiently deep mental model of the system in order to make correct decisions, diagnose failures, and decide what to do next, then that understanding must be acquired one way or another. When it no longer forms incrementally during the act of coding, it has to be rebuilt after the fact, often under worse conditions and with less context. In that sense, the apparent speedup only holds if we ignore the cost of comprehension and review; once those are included, the comparison becomes less about raw code throughput and more about where and how understanding is generated in the process.
Many people understand this tradeoff in general terms. Just like we generally understand the concept of technical debt.
But just as it's very hard to deal with classic technical debt, it will be very hard to counterbalance the short term gains of AI producing endless streams of code
Curiously, this is where automated checks, that people have known are useful for years but haven't been implementing widely enough, come in really handy!
Not just linters and code tests, but also various checks in regards to the architecture - like how the code is organized, how certain abstractions are used (e.g. if you want to enforce Pinia Setup instead of Option stores, and Vue Composition instead of Options API; or a particular ASP.NET or Spring Boot way of structuring filters and API endpoints and access controls) and so on.
Previously we just expected a bunch of devs to do a lot of heavy lifting along the lines of: "Oh yeah, this doesn't match our ADR described there, please follow the existing structure" which obviously doesn't work when the LLM produces code at 10x the rate.
I think the projects that will truly work well with increased use of agentic LLM use will be those that will have hundreds of various checks and actually ENFORCE standards instead of just expecting them to be followed (which people don't do anyways).
When thinking about automation people overindex on their current class biases. For 20 years we heard that robots were going to take over the “burger flipper” jobs. Why was it so easy to think that robots could replace fast food workers? Because they were the lowest rung on the career ladder, so it felt natural that they would be the first ones to get replaced.
Similarly, it’s easy to think that the lowly peons in the engineering world are going to get replaced and we’ll all be doing the job of directors and CEOs in the future, but that doesn’t really make sense to me.
Being able to whip your army of AI employees 3% better than your competitor doesn’t (usually) give any lasting advantage.
What does give an advantage is: specialized deep knowledge, building relationships and trust with users and customers, and having a good sense of design/ux/etc.
Like maybe that’s some of the job of a manager/director/CEO, but not anyone that I’ve worked with.
I think the logic still holds due to the red queen effect. If everyone else is getting 3% better and you’re not, it could spell trouble.
Medium term, I expect ai adoption to compound. So if you can be 3.5% better, it could become a massive advantage over a few years compared to the competition.
I thought I had a great startup idea. It was niche, but a solid global market. It was unique. There was a genuine pain point being solved. My MVP solved it. The pricing worked, the tiers were sound.
At least ChatGPT, Gemini and Claude told me it was. I did so many rounds of each one evaluating the other, trying to poke holes etc. Reviewing the idea and the "research", the reasoning. Plugging the gaps.
Then I started talking to real people about their problems in this space to see if this was one of them. Nope, not really. It kinda was, but not often enough to pay for a dedicated service, and not enough of a pain to move on from free workarounds.
Beware of AI reviewing AI. Always talk to real people to validate.
The "management as superpower" framing assumes people thoughtfully evaluate AI output. In practice, most users either review everything (slow, defeats the speed benefit) or review almost nothing (fast, but you're trusting the AI entirely). The MBAs who did well probably had domain expertise to spot wrong answers quickly, that's the actual superpower, not generic "management skill
The linked tweets seem like exaggerations or hyperbole. "I shipped 22 PRs yesterday, and 27 the day before" – huh? Are these PRs just one-liner copy changes or something? Even if you're not coding, you have to at least be verifying the changes right? At 15min to run CI and deploy, that's 5.5 hours spent just for changes to go into production. Spending just 15minutes to review and verify and 15minutes to merge and deploy 22 changes is 11 hours, no breaks, no meals. Smells like bullshit to me.
Fire MBAs and other “management” types. If they’re not technical and you’re building something technical, they need to go. Anyone who says otherwise gets fired too.
Keep the engineers who consistently get Exceeds Expectations. Fire everyone else. No Pip just go please.
Keep a few EE product managers. Fire the rest.
Hire a few QAs who can work with AI and work with product to ensure the stuff actually works. You don’t need that many people anymore and a couple of quality people can’t hurt. I don’t trust engineers enough, sorry. You need discerning eyes.
Fire everyone else. Give the best people AI and they will be able to put out more good work. If someone doesn’t get this, fire them too because they’re clearly not EE level.
this is going to be the ultimate rug pull, for lack of a better expression. without actually gaining real skills, how are people relying on AI going to cope when it is unavailable or taken away or becomes too expensive? there's people advocating for UBI but why would you have incentive to donate income to incompetent unproductive people.
23 comments
[ 2.8 ms ] story [ 63.2 ms ] threadIn my experience so far, AI prototyping has been a powerful force for breaking analysis paralysis.
In the last 10 years of my career, the slow execution speed at different companies wasn't due to slow code writing. It was due to management excesses trying to drive consensus and de-risk ideas before the developers were even allowed to write the code. Let's circle back and drive consensus in a weekly meeting with the stakeholders to get alignment on the KPIs for the design doc that goes through the approval and sign off process first.
Developers would then read the ream and realize that perfection was expected from their output, too, so development processes grew to be long and careful to avoid accidents. I landed on a couple teams where even small changes required meetings to discuss it, multiple rounds of review, and a lot of grandstanding before we were allowed to proceed.
Then AI comes along and makes it cheap to prototype something. If it breaks or it's the wrong thing, nobody feels like they're in trouble because we all agree it was a prototype and the AI wrote it. We can cycle through prototypes faster because it's happening outside of this messy human reputation-review-grandstanding loop that has become the norm.
Instead of months of meetings, we can have an LLM generate a UI and a backend with fake data and say "This is what I want to build, and this is what it will do". It's a hundred times more efficient than trying to describe it to a dozen people in 1-hour timeslots in between all of their other meetings for 12 weeks in a row.
The dark side of this same coin is when teams try to rely on the AI to write the real code, too, and then blame the AI when something goes wrong. You have to draw a very clear line between AI-driven prototyping and developer-driven code that developers must own. I think this article misses the mark on that by framing everything as a decision to DIY or delegate to AI. The real AI-assisted successes I see have developers driving with AI as an assistant on the side, not the other way around. I could see how an MBA class could come to believe that AI is going to do the jobs instead of developers, though, as it's easy to look at these rapid LLM prototypes and think that production ready code is just a few prompts away.
And I think this will only shift to the higher levels of the management hierarchy in the future. For example, in the future we will have AI models that can one-shot an entire platform like Twitter. Then the question is less about how to handle a database and more about how to handle several AI generated companies!
While we're at the project manager level now, in the future we'll be at the CEO level. It's an interesting thing to think about.
I like his thinking but many professional managers are not good at management. So I'm not sure about the assumption that "many people" can easily pick this up.
"AI labs"
Can we stop this misleading language. They're doing product development. It's not a "laboratory" doing scientific research. There's no attempt at the scientific method. It's a software firm and these are software developers/project managers.
Which brings me to point 2. These guys are selling AI tooling. Obviously there's a huge desire to dogfood the tooling. Plus, by joining the company, you are buying into the hype and the vision. It would be more surprising if they weren't using their own tools the whole time. If you can't even sell to yourself...
We've been running agent workflows for a while now. The pattern that works: treat agents like junior team members. Clear scope, explicit success criteria, checkpoints to review output. The skills that matter are the same ones that make someone a good manager of people.
pglevy is right that many managers aren't good at this. But that's always been true. The difference now is that the feedback loop is faster. Bad delegation to an agent fails in minutes, not weeks. You learn quickly whether your instructions were clear.
The uncomfortable part: if your value was being the person who could grind through tedious work, that's no longer a moat. Orchestration and judgment are what's left.
Sure, writing code was slower before the agentic coder era, but as people coded their understanding of what they coded grew with them while coding and that allowed people to make informed decisions on what to do next and how to fix things when they go sideways.
By replacing the human who writes code with an agent that does it but faster doesn't necessarily improve the speed of the overall process by the same amount. Some of the time saved in producing code is simply shifted elsewhere: to reading, validating, and reconstructing the understanding that previously emerged naturally while writing. If the human still needs a sufficiently deep mental model of the system in order to make correct decisions, diagnose failures, and decide what to do next, then that understanding must be acquired one way or another. When it no longer forms incrementally during the act of coding, it has to be rebuilt after the fact, often under worse conditions and with less context. In that sense, the apparent speedup only holds if we ignore the cost of comprehension and review; once those are included, the comparison becomes less about raw code throughput and more about where and how understanding is generated in the process.
Many people understand this tradeoff in general terms. Just like we generally understand the concept of technical debt.
But just as it's very hard to deal with classic technical debt, it will be very hard to counterbalance the short term gains of AI producing endless streams of code
Curiously, this is where automated checks, that people have known are useful for years but haven't been implementing widely enough, come in really handy!
Not just linters and code tests, but also various checks in regards to the architecture - like how the code is organized, how certain abstractions are used (e.g. if you want to enforce Pinia Setup instead of Option stores, and Vue Composition instead of Options API; or a particular ASP.NET or Spring Boot way of structuring filters and API endpoints and access controls) and so on.
Previously we just expected a bunch of devs to do a lot of heavy lifting along the lines of: "Oh yeah, this doesn't match our ADR described there, please follow the existing structure" which obviously doesn't work when the LLM produces code at 10x the rate.
I think the projects that will truly work well with increased use of agentic LLM use will be those that will have hundreds of various checks and actually ENFORCE standards instead of just expecting them to be followed (which people don't do anyways).
Similarly, it’s easy to think that the lowly peons in the engineering world are going to get replaced and we’ll all be doing the job of directors and CEOs in the future, but that doesn’t really make sense to me.
Being able to whip your army of AI employees 3% better than your competitor doesn’t (usually) give any lasting advantage.
What does give an advantage is: specialized deep knowledge, building relationships and trust with users and customers, and having a good sense of design/ux/etc.
Like maybe that’s some of the job of a manager/director/CEO, but not anyone that I’ve worked with.
What do you mean by “better”? The advantage is speed. Shipping a feature in 1 week instead of 1 month is a tremendous advantage
Medium term, I expect ai adoption to compound. So if you can be 3.5% better, it could become a massive advantage over a few years compared to the competition.
At least ChatGPT, Gemini and Claude told me it was. I did so many rounds of each one evaluating the other, trying to poke holes etc. Reviewing the idea and the "research", the reasoning. Plugging the gaps.
Then I started talking to real people about their problems in this space to see if this was one of them. Nope, not really. It kinda was, but not often enough to pay for a dedicated service, and not enough of a pain to move on from free workarounds.
Beware of AI reviewing AI. Always talk to real people to validate.
Fire MBAs and other “management” types. If they’re not technical and you’re building something technical, they need to go. Anyone who says otherwise gets fired too.
Keep the engineers who consistently get Exceeds Expectations. Fire everyone else. No Pip just go please.
Keep a few EE product managers. Fire the rest.
Hire a few QAs who can work with AI and work with product to ensure the stuff actually works. You don’t need that many people anymore and a couple of quality people can’t hurt. I don’t trust engineers enough, sorry. You need discerning eyes.
Fire everyone else. Give the best people AI and they will be able to put out more good work. If someone doesn’t get this, fire them too because they’re clearly not EE level.
Scale this to the whole org.