I think it will be difficult to measure productivity using coding agents in any sense until the industry starts standardizing around specific agentic engineering techniques
Vibe-coding/prompting a feature will produce much more slopulence than writing a .md spec and delegating specific pieces of implementation to the agent. But then is that better than writing it by hand?
Surely there’s an optimal equilibrium but I’m not convinced many engineers have found it yet
Love the analogy and as someone who has been coding for a very long time now and also run a startup (nonbios) in the same space as Cursor/Claude code - I broadly agree.
However I have a different take on two counts:
Firstly, those who build camrys, couldnt do so without AI. But now that they can, they have the opportunity to learn how to build Ferarris. And some of them will push through, and earn their place. We see it happening already at nonbios - non-engineers are 'learning' to build through AI, rather than simply delegating.
Secondly, those who build Ferraris - would still prefer to use AI to do it. The 'taste' is still the limiting function as it is the slowest part to get right, but everything around it is better delegated to AI. I do it myself - but your take is hot - it might not have meaningfully increased the speed. However, despite that, building with AI has a lower 'cognitive' cost, as it can take care of the low level stuff, while I focus on the high level design.
My engineers are hitting 2.5x their previous delivery velocity with agents while still passing all human code reviews. But this took a significant, ground up restructure of our development process. If you're still running Agile and wasting time being hyper prescriptive by typing out individual user stories, agentic dev isn't going to do much for you at all.
We're a product-first org, so whatever their product leadership (which is me for my team) is asking them for. The acceleration is consistent across product teams though.
What is it about Gen-Z'ers that makes them think that the rules of punctuation, capitalization, etc., shouldn't apply to their long-form writing? Your credibility quickly approaches zero when you make the quite incorrect assumption that you've somehow earned the poetic license to override the readability of your content with your poor stylistic choices.
Do you believe you write good content? Imagine how many other people might also think so if they could make it more than half-way through your articles before giving up.
Please consider this, rather than simply taking it as an attack. I stumbled upon your article because someone thought enough of it to write his own derivative article. So you must have something worse saying. But you're needlessly limiting the people whom you might be saying it to.
Until now, I had to deal with narcissistic developers who created spaghetti code, making them untouchable in the eyes of management, even when the code was underperforming, slow and memory-intensive. Now, with AI, I can do it myself: I can iterate on domain-specific areas with ease, and companies don't depend on developer egos.
Hi Ethan, thank you for writing this article. I was very surprised to learn that "comma.ai‘s software subsidiary famously had an alarm that triggered when the codebase exceeded a certain size", but neither Google nor Bing has any search results about this. Could you provide a source for this? Thanks again!
The lore here is the “tinygrad” repo (https://github.com/tinygrad/tinygrad), it had a pre-commit check of whether the total library was under 1000 lines of code or not. Mostly as a dig at PyTorch being quite verbose. It’s since grown past that threshold but for the first 2-3 years it was there. You can watch George Hotz’s old livestreams on YouTube building the library from scratch and enforcing the limit on himself/others contributing.
the empirical evidence used to be with you, but now goes against these claim! cf. metr’s update to their open source source dev productivity study. an interesting point nonetheless. catching up to the frontier has always been easier than pushing the frontier, and in the world of code, coding agents have made that even easier. I do think pushing the frontier has become easier, too, through enabling faster iteration, but much less so than it has accelerated catching up.
I think the most important point is missed here is that ai should not be used solely for code generation. It should be used as contributor, engineer, collegue who can engineer, build tools, verify output results, ui, and the product.
Becuase if you just using ai to generate more LOC, you are not even using it. Because if you do need so much code, you should think twice - can it be generated from tool? What tools could be useful there? What reusability practices and Generational Architecture principles we should apply to support. Working with ai should not be treated as generation software. Other problems comes from managing scaling project - when you are working with many projects at scale, your most investment should go to tools to support its maintainabilty, from small pieces to large pieces, to work with systems at scale e2e declarative when possible- for example, I'm pushing forward term Engineering Stewarship - when engineers and ai work together on project and its tools, communication, patterns depending on scale and applicable ethics. One of projects which I personally developed to target the problem having multiple projects, monorepos - https://github.com/arenukvern/skill_steward - the idea is to have some kind of ladders to guide and curate such work inside your project.
The tool doesn’t fix the product, it just makes shipping a bad product faster. Teams with weak product thinking and vague requirements get exactly the same vague code, just at 10x velocity. I’ve been writing about this from the product side at Parth’s Substack, specifically why every “the model is bad” complaint usually traces back to context, tooling, or the product loop, not the model itself.
great post! if the world's best coding agent gave a real compounding product-velocity edge and anthropic had it for 7 months, codex shouldn't be competitive. but it is
i suspect coding agents are doing for software what cheap debt did for startups, increasing output today by pulling maintenance costs forward from the future
article makes very good points but it’s pretty disingenuous to frame an argument about coding agents with a chart that terminates in q1 of 2025 lol
oh i think taht's just ai LOL
asme trned line holds w axis extending to today - or at least i would stand by taht
Definitely not going to assume that when coding agents only really took off 6 months after your chart ends.
Some of the top engineers in the world stopped writing code as of 4-5 months ago.
eh, doubt it
i know folks like karpathy say that but karpathy's majority of projects dont' involve a ton of horrible codebases
You can stop writing code. We have a bunch of engineers at work who generate practically everything.
The problem is we can't see any productivity gain, any gain for customers, etc.
They are just doing it because it is cool.
I think it will be difficult to measure productivity using coding agents in any sense until the industry starts standardizing around specific agentic engineering techniques
Vibe-coding/prompting a feature will produce much more slopulence than writing a .md spec and delegating specific pieces of implementation to the agent. But then is that better than writing it by hand?
Surely there’s an optimal equilibrium but I’m not convinced many engineers have found it yet
How do I tell Substack I never want to see your content
What is the source of your first graph, the k-shaped productivity curve? Thanks.
Love the analogy and as someone who has been coding for a very long time now and also run a startup (nonbios) in the same space as Cursor/Claude code - I broadly agree.
However I have a different take on two counts:
Firstly, those who build camrys, couldnt do so without AI. But now that they can, they have the opportunity to learn how to build Ferarris. And some of them will push through, and earn their place. We see it happening already at nonbios - non-engineers are 'learning' to build through AI, rather than simply delegating.
Secondly, those who build Ferraris - would still prefer to use AI to do it. The 'taste' is still the limiting function as it is the slowest part to get right, but everything around it is better delegated to AI. I do it myself - but your take is hot - it might not have meaningfully increased the speed. However, despite that, building with AI has a lower 'cognitive' cost, as it can take care of the low level stuff, while I focus on the high level design.
My engineers are hitting 2.5x their previous delivery velocity with agents while still passing all human code reviews. But this took a significant, ground up restructure of our development process. If you're still running Agile and wasting time being hyper prescriptive by typing out individual user stories, agentic dev isn't going to do much for you at all.
Is your revenue exploding / accelerating?
Can you tell us how your engineers are choosing what to deliver?
We're a product-first org, so whatever their product leadership (which is me for my team) is asking them for. The acceleration is consistent across product teams though.
What is it about Gen-Z'ers that makes them think that the rules of punctuation, capitalization, etc., shouldn't apply to their long-form writing? Your credibility quickly approaches zero when you make the quite incorrect assumption that you've somehow earned the poetic license to override the readability of your content with your poor stylistic choices.
Do you believe you write good content? Imagine how many other people might also think so if they could make it more than half-way through your articles before giving up.
Please consider this, rather than simply taking it as an attack. I stumbled upon your article because someone thought enough of it to write his own derivative article. So you must have something worse saying. But you're needlessly limiting the people whom you might be saying it to.
Take your meds unc
Dynamite drop-in there, sweetie.
Until now, I had to deal with narcissistic developers who created spaghetti code, making them untouchable in the eyes of management, even when the code was underperforming, slow and memory-intensive. Now, with AI, I can do it myself: I can iterate on domain-specific areas with ease, and companies don't depend on developer egos.
Hi Ethan, thank you for writing this article. I was very surprised to learn that "comma.ai‘s software subsidiary famously had an alarm that triggered when the codebase exceeded a certain size", but neither Google nor Bing has any search results about this. Could you provide a source for this? Thanks again!
uhhhh i guess it wasn’t as famous as I thought
the guy who told me it was an engineer on our team, went to their office - said it was famous, i guess i never double checked them
The lore here is the “tinygrad” repo (https://github.com/tinygrad/tinygrad), it had a pre-commit check of whether the total library was under 1000 lines of code or not. Mostly as a dig at PyTorch being quite verbose. It’s since grown past that threshold but for the first 2-3 years it was there. You can watch George Hotz’s old livestreams on YouTube building the library from scratch and enforcing the limit on himself/others contributing.
the empirical evidence used to be with you, but now goes against these claim! cf. metr’s update to their open source source dev productivity study. an interesting point nonetheless. catching up to the frontier has always been easier than pushing the frontier, and in the world of code, coding agents have made that even easier. I do think pushing the frontier has become easier, too, through enabling faster iteration, but much less so than it has accelerated catching up.
The liability framing is right. It skips that buyers pay for shipped features, not deletion, so agents optimize what gets paid for.
I think the most important point is missed here is that ai should not be used solely for code generation. It should be used as contributor, engineer, collegue who can engineer, build tools, verify output results, ui, and the product.
Becuase if you just using ai to generate more LOC, you are not even using it. Because if you do need so much code, you should think twice - can it be generated from tool? What tools could be useful there? What reusability practices and Generational Architecture principles we should apply to support. Working with ai should not be treated as generation software. Other problems comes from managing scaling project - when you are working with many projects at scale, your most investment should go to tools to support its maintainabilty, from small pieces to large pieces, to work with systems at scale e2e declarative when possible- for example, I'm pushing forward term Engineering Stewarship - when engineers and ai work together on project and its tools, communication, patterns depending on scale and applicable ethics. One of projects which I personally developed to target the problem having multiple projects, monorepos - https://github.com/arenukvern/skill_steward - the idea is to have some kind of ladders to guide and curate such work inside your project.
The tool doesn’t fix the product, it just makes shipping a bad product faster. Teams with weak product thinking and vague requirements get exactly the same vague code, just at 10x velocity. I’ve been writing about this from the product side at Parth’s Substack, specifically why every “the model is bad” complaint usually traces back to context, tooling, or the product loop, not the model itself.
great post! if the world's best coding agent gave a real compounding product-velocity edge and anthropic had it for 7 months, codex shouldn't be competitive. but it is
AI coding agents create a K-shaped productivity curve because they amplify the operator.
Senior builders gain leverage.
Junior builders gain velocity without judgment.
That is why the same tool can make one product sharper and another product more chaotic.
The bottleneck is not code generation.
It is taste, architecture, and verification.
i suspect coding agents are doing for software what cheap debt did for startups, increasing output today by pulling maintenance costs forward from the future