I’m working as a single solo developer of a tiny video game. I’m writing it in C with raylib. No coding assistants, no agents, not even a language server.
I only work on it for a few hours during the week. And it’s progressing at a reasonable pace that I’m happy with. I got cross-compilation from Linux to Windows going early on in a couple of hours. Wasn’t that hard.
I’ve had to rework parts of the code as I’ve progressed. I’ve had to live with decisions I made early on. It’s code. It’s fine.
I don’t really understand the, “more, better, faster,” cachet to be honest. Writing the code hasn’t been the bottle neck to developing software for a long time. It’s usually the thinking that takes most of the time and if that goes away well… I dunno, that’s weird. I will understand it even less.
Agree with writing less code though. The economics of throwing out 37k lines of code a week is… stupid in the extreme. If we get paid by the line we could’ve optimized for this long before LLM’s were invented. It’s not like more lines of code means more inventory to sell. It’s usually the opposite: the more bugs to fix, the more frustrated customers, the higher churn of exhausted developers.
>I don’t really understand the, “more, better, faster,” cachet to be honest. Writing the code hasn’t been the bottle neck to developing software for a long time. It’s usually the thinking that takes most of the time and if that goes away well… I dunno, that’s weird. I will understand it even less.
This is what I've always found confusing as well about this push for AI. The act of typing isn't the hard part - its understanding what's going on, and why you're doing it. Using AI to generate code is only faster if you try and skip that step - which leads to an inevitable disaster
> The act of typing isn't the hard part - its understanding what's going on, and why you're doing it. Using AI to generate code is only faster if you try and skip that step - which leads to an inevitable disaster
It’s more than just typing though. A simple example remembering the exact incantation of CSS classes to style something that you can easily describe in plain English.
Yes, you could look them up or maybe even memorize them. But there’s no way you can make wholesale changes to a layout faster than a machine.
It lowers the cost for experimentation. A whole series of “what if this was…” can be answered with an implementation in minutes. Not a whole afternoon on one idea that you feel a sunk cost to keep.
Honestly I think you can tell pretty quickly if a company or person is approaching AI from the viewpoint of accelerating development and innovation or just looking to do the same amount of work with less people. The space has been flooded by mean-spirited people who love the idea of developers becoming obsolete, which is a viewpoint that isn't working out for a lot of companies right now...many are already scrambling to rehire. Approaching the situation practically, integrating AI as a tool and accelerator is the much smarter way and if done right will pay for itself anyway.
> Writing the code hasn’t been the bottle neck to developing software for a long time. It’s usually the thinking that takes most of the time
Does your coding not involve thinking? And if not, why are you not delighted to have AI take that over? Writing unthinking boilerplate is tedious garbage work.
Today I wanted to address a bug I found on a product I work on. At the intersection of platform migration and backwards compatibility I found some customers getting neither. I used an LLM to research the code paths and ensure that my understanding of the break was correct and what the potential side effects of my proposed fix would be. AI saved me stepping through code for hours to understand the side effects. I asked it for a nice description of the flow and it gave it to me, including the pieces I didn’t really know because I’d never even touched that code before. I could have done this. Would it have been a better use of my time than moving on to the next thing? Probably not. Stepping through function calls in an IDE is not my idea of good “thinking” work. Tracing through glue to understand how a magical property gets injected is a great job for a machine.
>Writing the code hasn’t been the bottle neck to developing software for a long time.
Then we're doing different things.
I didn't like GitHub so I wrote my own. 60k lines of code later... yes writing code was the bottleneck which has been eliminated. The bottleneck is now design, review, and quality assessments that can't be done trivially.
This isn't even the project I wanted to be doing, the tools that were available were holding me back so I wrote my own. It also consumes a few hours a week.
If you think writing code isn't the bottleneck then you aren't thinking big enough. If you don't WANT to think big enough, that's fine, I also do things for the joy of doing them.
> Writing the code hasn’t been the bottle neck to developing software for a long time.
I see this on HN just so much and I am not sure what this is, almost seems like a political slogan that followers keep repeating.
I had to do some rough math in my head but in the last 5 years I have been involved with hiring roughly 40 SWEs. Every single one of them was hired because writing the code was THE bottleneck (the only one) and we needed more people to write the code
If you’ve never read Fred Brooks, I’d recommend it. The aphorism is a bit dated but rings true: you can’t add another developer and make the process go faster. It usually slows teams down.
I’ve seen it time and again: startups move from their market-fit phase into an operational excellence phase on the backing of VC funding and they start hiring a ton of people. Most of those developers are highly educated, specialized people with deep technical skills and they’re often put to work making the boxes more blue or sitting in meetings with PMs for hours. Teams slow down output when you add more people.
You don’t have a quota. It’s not like you’ll have fewer units to sell if you don’t add that 30k lines of code by Friday.
This is knowledge work. The work is understanding problems and knowing how to develop solutions to them. You add more people and you end up adding overhead. Communication, co-ordination, operations overhead.
The real bottle necks are people and releasing systems into production. Every line of code change is a liability. There’s risk tolerance to manage in order to achieve five-nines.
A well-sized team that has worked together a long time can outperform a massive team any day in my experience.
I've worked in two different types of environments - one where what you said is absolutely true (most of my jobs), and another where it's not true and the quote holds up.
The difference, I think is:
- Code factories where everything is moving fast - there's no time to think about how to simplify a problem, just gotta get it done. These companies tended to hire their way out of slowness, which led to more code, more complexity, and more code needed to deal with and resolve edge cases introduced by the complexity. I can count many times I was handed directives to implement something that I knew was far more complex than it had to be, but because of the pressure to move forward it was virtually impossible to push back. Maybe it's the only way they can make the business case work, but IMO it undoubtedly led to far, far more code than would've been necessary if it were possible to consider problems more carefully and if engineers had more autonomy. In these companies also a lot of time was consumed by meetings trying to "sync up" with the 100 other people moving in one direction.
- Smaller shops, open source projects, or indie development where there isn't a rush to get something out the door. Here, it's possible to think through a problem and come up with a solution that reduces code surface area. This was about solving the largest number of problems with the least amount of complexity. Most of my time at this company was spent thinking through how to solve the problem and considering edge cases and exploratory coding, the actual implementation was really quick to write. It really helped that I had a boss who understood and encouraged this, and we were working on safety critical systems. My boss liked to say "you can't birth a baby in less than 9 months just by adding another woman".
I think most of the difference is in team size. A larger team inherently results in more code to do less, because of the n*(n-1)/2 communication overhead [1].
Recently I learned the Navy SEALs saying "Slow is smooth, smooth is fast" which I feel sums up my experience well.
Even if the entire totem pole of decision makers in a company thinks writing code is the bottleneck doesn't make it true that writing code is the bottleneck.
On the extreme end to prove the point, the suits intentionally abstract out reality into neat forecasts and spreadsheet cells.
It's hard for me to think of something concrete that will convince you. Does code map directly to business outcomes in your experience? Because it's overwhelmingly not even remotely true in my experience.
even just "all lines of code are not created equal" tells me there's no direct correlation with business value.
It sounds like you just aren't very good at managing teams of programmers tbh. If your bottleneck is producing code, very rarely does hiring more programmers actually help.
I agree the slogan isn't very true. It's similar to another line of commentary that would suggest soft skills are more important than the hard skills of actually being able to program, i.e. the primary service being paid for.
There is some truth to it, like Brooks' Law (https://en.wikipedia.org/wiki/Brooks's_law) about how adding people to an already late project will just make it later. There are many factors in how long a software engineering task takes beyond pure typing speed, which suggests there are factors beyond code produced per day as well. But some typing has to be done, and some code has to be produced, and those can absolutely be bottlenecks.
Another way of looking at it that I like is Hickey's hierarchy of the problems of programming and their relative costs, from slide 22: https://github.com/matthiasn/talk-transcripts/blob/master/Hi... If you have inherent domain complexity, or a misconception on how to apply programming to a domain, those are 10x worse costs than any day-to-day practice of programming concerns ("the code"), and there's a 10x further reduction for trivialisms like typos.
I think some of it must be cope since so many are in organizations where the more they get promoted the less they program, trending towards (and sometimes reaching) 0. In such an organization sure, code isn't the bottleneck per se, it's a symptom of an underlying cause. The bottleneck would be the bad incentives that get people to schedule incessant unnecessary meetings with as many people as they can to show leadership of stakeholders for promotion doc material, and other questionable things shoved on the best engineers that take them away from engineering. Remove those, and suddenly productivity can go way up, and code produced will go up as well.
I've also always been amused by estimates of what constitutes "good" productivity if you try to quantify it in lines of code. There's a paper from 1994 by Jim Coplien, "Borland Software Craftsmanship: A New Look at Process, Quality, and Productivity". It's summarized in the free book by Richard Gabriel, "Patterns of Software". (https://www.dreamsongs.com/Files/PatternsOfSoftware.pdf pg 135) They were making new spreadsheet software for Windows, and had a group of "very high caliber" professionals, with a core group of 4 people (2 with important prior domain expertise) and then 4 more team members added after a year. "The QPW group, consisting of about eight people, took 31 months to produce a commercial product containing 1 million lines of code. This elapsed time includes the prototypes, but the line count does not. That is, each member of this group produced 1,000 lines of final code per week."
Later on, Coplien was asked "what he thought was a good average for US software productivity", and the answer was "1000 to 2000 non-commentary source lines per programmer per year". Also: "this number was constant for a large in-house program over its 15-year lifetime -- so that original development and maintenance moved at the same pace: slowly". An average of 1k lines a year is 19 lines a week, or about 4 lines a day for a work-week. This was considered acceptable for an average, whereas for an exceptional team you could get 200 a day. Might not there be ways to boost the average from 4 to something like 12 or 20? If your organization is at 4, there is clearly a bottleneck. (For extra context, the QPW group was in C++, and Gabriel notes he had personal experience with several groups demonstrating similar productivity levels. "I watched Lisp programmers produce 1000 lines of Lisp/CLOS code per month per person, which is roughly equivalent to 350 to 1000 lines of C++ code per week." Of course language matters in lines of code comparisons.)
It was always possible to write large amounts of crappy code if you were motivated or clueless enough (see https://github.com/radian-software/TerrariaClone). It's now just easier, and the consequences less severe, as the agent has code comprehension superpowers and will happily extend your mud ball of a codebase.
There are still consequences, however. Even with an agent, development slows, cost increases, bugs emerge at a higher rate, etc. It's still beneficial to focus on code quality instead of raw output. I don't think this is limited writing it yourself, mind - but you need to actually have an understanding of what's being generated so you can critique and improve it.
Personally, I've found the accessibility aspect to be the most beneficial. I'm not always writing more code, but I can do much more of it on my phone, just prompting the agent, which has been so freeing. I don't feel this is talked about enough!
I’m working as a single solo developer of a tiny video game. I’m writing it in C with raylib. No coding assistants, no agents, not even a language server.
I only work on it for a few hours during the week. And it’s progressing at a reasonable pace that I’m happy with. I got cross-compilation from Linux to Windows going early on in a couple of hours. Wasn’t that hard.
I’ve had to rework parts of the code as I’ve progressed. I’ve had to live with decisions I made early on. It’s code. It’s fine.
I don’t really understand the, “more, better, faster,” cachet to be honest. Writing the code hasn’t been the bottle neck to developing software for a long time. It’s usually the thinking that takes most of the time and if that goes away well… I dunno, that’s weird. I will understand it even less.
Agree with writing less code though. The economics of throwing out 37k lines of code a week is… stupid in the extreme. If we get paid by the line we could’ve optimized for this long before LLM’s were invented. It’s not like more lines of code means more inventory to sell. It’s usually the opposite: the more bugs to fix, the more frustrated customers, the higher churn of exhausted developers.
>I don’t really understand the, “more, better, faster,” cachet to be honest. Writing the code hasn’t been the bottle neck to developing software for a long time. It’s usually the thinking that takes most of the time and if that goes away well… I dunno, that’s weird. I will understand it even less.
This is what I've always found confusing as well about this push for AI. The act of typing isn't the hard part - its understanding what's going on, and why you're doing it. Using AI to generate code is only faster if you try and skip that step - which leads to an inevitable disaster
> The act of typing isn't the hard part - its understanding what's going on, and why you're doing it. Using AI to generate code is only faster if you try and skip that step - which leads to an inevitable disaster
It’s more than just typing though. A simple example remembering the exact incantation of CSS classes to style something that you can easily describe in plain English.
Yes, you could look them up or maybe even memorize them. But there’s no way you can make wholesale changes to a layout faster than a machine.
It lowers the cost for experimentation. A whole series of “what if this was…” can be answered with an implementation in minutes. Not a whole afternoon on one idea that you feel a sunk cost to keep.
4 replies →
Honestly I think you can tell pretty quickly if a company or person is approaching AI from the viewpoint of accelerating development and innovation or just looking to do the same amount of work with less people. The space has been flooded by mean-spirited people who love the idea of developers becoming obsolete, which is a viewpoint that isn't working out for a lot of companies right now...many are already scrambling to rehire. Approaching the situation practically, integrating AI as a tool and accelerator is the much smarter way and if done right will pay for itself anyway.
Those mean spirited people are actually capitalists and they've been chasing the dream of perpetual labor since the 1800s.
> Writing the code hasn’t been the bottle neck to developing software for a long time. It’s usually the thinking that takes most of the time
Does your coding not involve thinking? And if not, why are you not delighted to have AI take that over? Writing unthinking boilerplate is tedious garbage work.
Today I wanted to address a bug I found on a product I work on. At the intersection of platform migration and backwards compatibility I found some customers getting neither. I used an LLM to research the code paths and ensure that my understanding of the break was correct and what the potential side effects of my proposed fix would be. AI saved me stepping through code for hours to understand the side effects. I asked it for a nice description of the flow and it gave it to me, including the pieces I didn’t really know because I’d never even touched that code before. I could have done this. Would it have been a better use of my time than moving on to the next thing? Probably not. Stepping through function calls in an IDE is not my idea of good “thinking” work. Tracing through glue to understand how a magical property gets injected is a great job for a machine.
You can use LLM to write less code too. Just takes more intention. Which is kind of the whole point.
>Writing the code hasn’t been the bottle neck to developing software for a long time.
Then we're doing different things.
I didn't like GitHub so I wrote my own. 60k lines of code later... yes writing code was the bottleneck which has been eliminated. The bottleneck is now design, review, and quality assessments that can't be done trivially.
This isn't even the project I wanted to be doing, the tools that were available were holding me back so I wrote my own. It also consumes a few hours a week.
If you think writing code isn't the bottleneck then you aren't thinking big enough. If you don't WANT to think big enough, that's fine, I also do things for the joy of doing them.
> Writing the code hasn’t been the bottle neck to developing software for a long time.
I see this on HN just so much and I am not sure what this is, almost seems like a political slogan that followers keep repeating.
I had to do some rough math in my head but in the last 5 years I have been involved with hiring roughly 40 SWEs. Every single one of them was hired because writing the code was THE bottleneck (the only one) and we needed more people to write the code
If you’ve never read Fred Brooks, I’d recommend it. The aphorism is a bit dated but rings true: you can’t add another developer and make the process go faster. It usually slows teams down.
I’ve seen it time and again: startups move from their market-fit phase into an operational excellence phase on the backing of VC funding and they start hiring a ton of people. Most of those developers are highly educated, specialized people with deep technical skills and they’re often put to work making the boxes more blue or sitting in meetings with PMs for hours. Teams slow down output when you add more people.
You don’t have a quota. It’s not like you’ll have fewer units to sell if you don’t add that 30k lines of code by Friday.
This is knowledge work. The work is understanding problems and knowing how to develop solutions to them. You add more people and you end up adding overhead. Communication, co-ordination, operations overhead.
The real bottle necks are people and releasing systems into production. Every line of code change is a liability. There’s risk tolerance to manage in order to achieve five-nines.
A well-sized team that has worked together a long time can outperform a massive team any day in my experience.
4 replies →
I've worked in two different types of environments - one where what you said is absolutely true (most of my jobs), and another where it's not true and the quote holds up.
The difference, I think is:
- Code factories where everything is moving fast - there's no time to think about how to simplify a problem, just gotta get it done. These companies tended to hire their way out of slowness, which led to more code, more complexity, and more code needed to deal with and resolve edge cases introduced by the complexity. I can count many times I was handed directives to implement something that I knew was far more complex than it had to be, but because of the pressure to move forward it was virtually impossible to push back. Maybe it's the only way they can make the business case work, but IMO it undoubtedly led to far, far more code than would've been necessary if it were possible to consider problems more carefully and if engineers had more autonomy. In these companies also a lot of time was consumed by meetings trying to "sync up" with the 100 other people moving in one direction.
- Smaller shops, open source projects, or indie development where there isn't a rush to get something out the door. Here, it's possible to think through a problem and come up with a solution that reduces code surface area. This was about solving the largest number of problems with the least amount of complexity. Most of my time at this company was spent thinking through how to solve the problem and considering edge cases and exploratory coding, the actual implementation was really quick to write. It really helped that I had a boss who understood and encouraged this, and we were working on safety critical systems. My boss liked to say "you can't birth a baby in less than 9 months just by adding another woman".
I think most of the difference is in team size. A larger team inherently results in more code to do less, because of the n*(n-1)/2 communication overhead [1].
Recently I learned the Navy SEALs saying "Slow is smooth, smooth is fast" which I feel sums up my experience well.
[1] https://en.wikipedia.org/wiki/The_Mythical_Man-Month
2 replies →
Even if the entire totem pole of decision makers in a company thinks writing code is the bottleneck doesn't make it true that writing code is the bottleneck.
On the extreme end to prove the point, the suits intentionally abstract out reality into neat forecasts and spreadsheet cells.
It's hard for me to think of something concrete that will convince you. Does code map directly to business outcomes in your experience? Because it's overwhelmingly not even remotely true in my experience.
even just "all lines of code are not created equal" tells me there's no direct correlation with business value.
But how much time per week does an SWE actually spend writing code?
5 replies →
It sounds like you just aren't very good at managing teams of programmers tbh. If your bottleneck is producing code, very rarely does hiring more programmers actually help.
I agree the slogan isn't very true. It's similar to another line of commentary that would suggest soft skills are more important than the hard skills of actually being able to program, i.e. the primary service being paid for.
There is some truth to it, like Brooks' Law (https://en.wikipedia.org/wiki/Brooks's_law) about how adding people to an already late project will just make it later. There are many factors in how long a software engineering task takes beyond pure typing speed, which suggests there are factors beyond code produced per day as well. But some typing has to be done, and some code has to be produced, and those can absolutely be bottlenecks.
Another way of looking at it that I like is Hickey's hierarchy of the problems of programming and their relative costs, from slide 22: https://github.com/matthiasn/talk-transcripts/blob/master/Hi... If you have inherent domain complexity, or a misconception on how to apply programming to a domain, those are 10x worse costs than any day-to-day practice of programming concerns ("the code"), and there's a 10x further reduction for trivialisms like typos.
I think some of it must be cope since so many are in organizations where the more they get promoted the less they program, trending towards (and sometimes reaching) 0. In such an organization sure, code isn't the bottleneck per se, it's a symptom of an underlying cause. The bottleneck would be the bad incentives that get people to schedule incessant unnecessary meetings with as many people as they can to show leadership of stakeholders for promotion doc material, and other questionable things shoved on the best engineers that take them away from engineering. Remove those, and suddenly productivity can go way up, and code produced will go up as well.
I've also always been amused by estimates of what constitutes "good" productivity if you try to quantify it in lines of code. There's a paper from 1994 by Jim Coplien, "Borland Software Craftsmanship: A New Look at Process, Quality, and Productivity". It's summarized in the free book by Richard Gabriel, "Patterns of Software". (https://www.dreamsongs.com/Files/PatternsOfSoftware.pdf pg 135) They were making new spreadsheet software for Windows, and had a group of "very high caliber" professionals, with a core group of 4 people (2 with important prior domain expertise) and then 4 more team members added after a year. "The QPW group, consisting of about eight people, took 31 months to produce a commercial product containing 1 million lines of code. This elapsed time includes the prototypes, but the line count does not. That is, each member of this group produced 1,000 lines of final code per week."
Later on, Coplien was asked "what he thought was a good average for US software productivity", and the answer was "1000 to 2000 non-commentary source lines per programmer per year". Also: "this number was constant for a large in-house program over its 15-year lifetime -- so that original development and maintenance moved at the same pace: slowly". An average of 1k lines a year is 19 lines a week, or about 4 lines a day for a work-week. This was considered acceptable for an average, whereas for an exceptional team you could get 200 a day. Might not there be ways to boost the average from 4 to something like 12 or 20? If your organization is at 4, there is clearly a bottleneck. (For extra context, the QPW group was in C++, and Gabriel notes he had personal experience with several groups demonstrating similar productivity levels. "I watched Lisp programmers produce 1000 lines of Lisp/CLOS code per month per person, which is roughly equivalent to 350 to 1000 lines of C++ code per week." Of course language matters in lines of code comparisons.)
For various internal tools & other projects, I started using config only tools and avoid code as much as possible.
https://avilpage.com/2026/03/config-first-tools.html
A similar post with more emphasis on validating changes: https://bower.sh/thinking-slow-writing-fast
It was always possible to write large amounts of crappy code if you were motivated or clueless enough (see https://github.com/radian-software/TerrariaClone). It's now just easier, and the consequences less severe, as the agent has code comprehension superpowers and will happily extend your mud ball of a codebase.
There are still consequences, however. Even with an agent, development slows, cost increases, bugs emerge at a higher rate, etc. It's still beneficial to focus on code quality instead of raw output. I don't think this is limited writing it yourself, mind - but you need to actually have an understanding of what's being generated so you can critique and improve it.
Personally, I've found the accessibility aspect to be the most beneficial. I'm not always writing more code, but I can do much more of it on my phone, just prompting the agent, which has been so freeing. I don't feel this is talked about enough!
[dead]