alt Hacker NewsThe cost of code never lived in the typing — it lived in the intent, the constraints, and the reasoning that shaped it. LLMs make the typing cheap, but they don’t make the reasoning cheap. So the economics shift, but the bottleneck doesn’t disappear.
Replies
It doesn't disappear but it does easy up some instances of fighting configuration, documentation, syntax or even comparing three approaches that are similar but you don't know their full effect.
I think it's a very fun space, finally being able to empower many people who in the past wouidve been bottlenecked unless they were using very simple tools for their domain and upskilled enough. Those 2 things will still be true, but the speed at which some things can happen at the exploration and other layers has seen a significant speedup.
Other problems like entropy/slop, security, system testing, lack of automation fundamentals arise but it's a good problem to start tackling.
I'm very focused on evals [1] because is what allows me to not to be the bottleneck with economists who I want to empower to code end to end and I'd like that mental shift to happen for anyone becoming a builder so non traditional developers and developers by trade have a common language for product building [2]. That part of speaking to different audiences and combating hype that promises to do everything for you Vs the intent that's actually needed is hard, but trying gets you to advance quite a lot.
[1] https://alexhans.github.io/posts/series/evals/measure-first-...
> LLMs make the typing cheap, but they don’t make the reasoning cheap.
LLMs lower the cost of copy/pasting code around, or troubleshooting issues using standard error messages.
Instead of going through Stack Overflow to find how to use a framework to do some specific thing, you prompt a model. You don't even need to know a thing about the language you are using to leverage a feedback loop.
LLMs lower the cost of a multitude of drudge work in developing software, such as having to read the docs to learn how a framework should be used to achieve a goal. You still need to know what you are doing, but you don't need to reinvent the wheel.
For most non-hobby project, the cost of code was in breaking a working system (whether by a bona fide bug, or a change in some unspecified implicit assumption). That made changes to code incredibly expensive - often much more than the original implementation.
It sounds harsh, but over the lifetime of a project, 10-lines/person/day is often a high estimate of the number of lines produced. It’s not because humans type so slow - it is because after a while, it’s all about changing previously written lines in ways that don’t break things.
LLMs are much better at that than humans, if the constraints and tests are reasonably well specified.