10 ms·

> Code has always been expensive. Producing a few hundred lines of clean, tested code takes most software developers a full day or more. Many of our engineering

> Code has always been expensive. Producing a few hundred lines of clean, tested code takes most software developers a full day or more. Many of our engineering habits, at both the macro and micro level, are built around this core constraint. > ... > Writing good code remains significantly more expensive I think this is a bad argument. Code was expensive because you were trying to write the expensive good code in the first place. When you drop your standards, then writing generated code is quick, easy and cheap. Unless you're willing to change your standard, getting it back to "good code" is still an equivalent effort. There are alternative ways to define the argument for agentic coding, this is just a really really bad argument to kick it off.

random3 8mo ago
Code is cheaper. Simple code is cheap. More complex code may not be cheaper. The reason you pay attention to details is because complexity compounds and the cheapest cleanup is when you write something, not when it breaks. This last part is still not fully fleshed out. For now. Is there any reason to not expect things to improve further? Regardless, a lot of code is cheap now and building products is fun regardless, but I doubt this will translate into more than very short-term benefits. When you lower the bar you get 10x more stuff, 10x more noise, etc. You lower it more you get 100x and so on.
simonw 8mo ago
I was careful to say "Good code still has a cost" and "delivering good code remains significantly more expensive than [free]" rather than the more aesthetically pleasing "Good code is expensive. I chose this words because I don't think good code is nearly as expensive with coding agents as it was without them. You still have to actively work to get good code, but it takes so much less time when you have a coding agent who can do the fine-grained edits on your behalf. I firmly believe that agentic engineering should produce better code. If you are moving faster but getting worse results it's worth stopping and examining if there are processes you could fix.
- akiselev 8mo ago
  Totally agreed. I’ve been reverse engineering Altium’s file format to enable agents to vibe-engineer electronics and though I’m on my third from scratch rewrite in as many weeks, each iteration improves significantly in quality as the previous version helps me to explore the problem space and instruct the agent on how to do red/green development [1]. Each iteration is tens of thousands of lines of code which would have been impossible to write so fast before so it’s been quite a change in perspective, treating so much code as throw away experimentation. I’m using a combination of 100s of megabytes of Ghidra decompiled delphi DLLs and millions of lines of decompiled C# code to do this reverse engineering. I can’t imagine even trying such a large project for LLMs so while a good implementation is still taking a lot of time, it’s definitely a lot cheaper than before. [1] I saw your red/green TDD article/book chapter and I don’t think you go far enough. Since we have agents, you can generalize red/green development to a lot of things that would be impractical to implement in tests. For example I have agents analyze binary diffs of the file format to figure out where my implementation is incorrect without being bogged down by irrelevant details like the order or encoding of parameters. This guides the agent loop instead of tests.
- inejge 8mo ago
  > I was careful to say "Good code still has a cost" and "delivering good code remains significantly more expensive than [free]" rather than the more aesthetically pleasing "Good code is expensive. Which is nuance that will get overlooked or waved away by upper management who see the cost of hiring developers, know that developers "write code", and can compare the developer salary with a Claude/Codex/whatever subscription. If the correction comes, it will be late and at the expense of rank and file, as usual. (And don't be naive: if an LLM subscription can let you employ fewer developers, that subscription plus offshore developers will enable even more cost saving. The name of the game is cost saving, and has been for a long time.)
  - dasil003 8mo ago
    Sure, but clueless leadership is not a new thing. While big companies with structural moats can shamble along with a surprising amount of dysfunction (which is why they tolerate so many muppets in middle management), even they rely on some baseline of system integrity that will erode pretty quickly if they let go of the people who know how things work. Don’t get me wrong, I think SWE headcounts will reduce over time, but the mechanism will be teams that know how to leverage AI effectively will dominate ones who don’t. This takes more market cycles though, and it’s even hard to nail down the specifics of these skills with the speed agentic coding tools are currently evolving. My advice is make yourself part of the second group, and worry less about bad management decisions that are inevitable.
mmsc 8mo ago
Spaghetti code was always a thing though
- chasd00 8mo ago
  Yeah people going on and on about peerless human generated code reminds me of that scene in iRobot when the cop asks sonny “can a robot create a work of art?” And the robot replies “can you?”. In 30 years in this industry I’ve yet seen what I would describe as perfect and maintainable code. It’s an aspirational dream not SOP.
unfunco 8mo ago
Computer programming is cheap. Software engineering is expensive.
wlruys 8mo ago
Definitely the market incentives for "good code" have never been worse, but I'm wouldn't be so sure the cost of migrating decent pieces of generated code to good code is worse than writing good code from whole cloth.
- strogonoff 8mo ago
  I find that implementing a sound solution from scratch is generally lower effort than taking something that already exists and making it sound. The former: 1) understand the problem, 2) solve the problem. The latter: 1) understand the problem, 2) solve the problem, 3) understand how somebody or something else understood & solved the problem, 4) diff those two, 5) plan a transition from that solution to this solution, 6) implement that transition (ideally without unplanned downtime and/or catastrophic loss of data). This is also why I’m not a fan of code reviews. Code review is basically steps 1–4 from the second approach, plus having to verbally explain the diff, every time.
  - locknitpicker 8mo ago
    > This is also why I’m not a fan of code reviews. That's specious reasoning. Code reviews are a safeguard against cowboy coding, and a tool to enforce shared code ownership. You might believe you know better than most of your team members, but odds are a fresh pair of eyes can easily catch issues you snuck in your code that you couldn't catch due to things like PR tunnel vision. And if your PR is sound, you certainly don't have a problem explaining what you did and why you did it.
    - strogonoff 8mo ago
      Code reviews have their place. I just personally don’t like being the reviewer, because it’s more effort on your part than just writing the damn thing from scratch while someone else gets the credit for the result[0]. Of course, having multiple pairs of eyes on the code and multiple people who understand it is crucial. [0] Reviews are OK if I enjoy working with the person whose work I’m reviewing and I feel like I’m helping them grow.
bfbf 8mo ago
In my experience, it’s even more effort to get good code with an agent-when writing by hand, I fully understand the rationale for each line I write. With ai, I have to assess every clause and think about why it’s there. Even when code reviewing juniors, there’s a level of trust that they had a reason for including each line (assuming they’re not using ai too for a moment); that’s not at all my experience with Codex. Last month I did the majority of my work through an agent, and while I did review its work, I’m now finding edge cases and bugs of the kind that I’d never have expected a human to introduce. Obviously it’s on me to better review its output, but the perceived gains of just throwing a quick bug ticket at the ai quickly disappear when you want to have a scalable project.
- cpursley 8mo ago
  Throw your next bug at this: https://skills.sh/obra/superpowers/systematic-debugging https://skills.sh/obra/superpowers/systematic-debugging
  - mixologic 8mo ago
    I find it amazing that skills are essentially excellent tools for humans to understand too.
    - Vegenoid 8mo ago
      I really wish they were called lessons instead of skills. It makes way more sense and prevents the overloading of the term "skill".
      - soulofmischief 8mo ago
        We'd just be overloading "lessons" as well, and even more so because it takes more work to ground the concept, given its larger semantic distance from what we're describing.
      - mycall 8mo ago
        There is some papers [0] showing that the skill and agent files reduce the reasoning effectiveness in some use cases (e.g. autogenerated) [0] https://arxiv.org/abs/2602.11988 https://arxiv.org/abs/2602.11988 reference: https://news.ycombinator.com/item?id=47034087 https://news.ycombinator.com/item?id=47034087
renegat0x0 8mo ago
I think the cost and work remains the same. What has change is efficiency. Previously people had to manually program byte after byte. Then came C and streamlined it, allowing faster development. With python I can write a simple debugging UI server with a few lines. There are frameworks that allow me to complete certain tasks in hours. You do not need to program everything from scratch. The more code, the faster everything gets, since the job is mostly done. We are accelerating, but we still work 9 to 5 jobs.
- shiroiuma 8mo ago
  C, Python, and frameworks don't generate all-new code for every task: you're taking advantage of stuff that's thoroughly tested. That simple debugging UI server is probably using some well-tested libraries, which you can reasonably trust to be bug-free (and which can be updated later to fix any bugs, without breaking your code that relies on them). With AI-generated code, this isn't the case.
  - renegat0x0 8mo ago
    Depends on what you think with AI-generated code. Do you mean vibe-coded? If yes, then I agree, but there are also other scenarios of AI-generated code. I use regularly AI in my hobby projects, it provides me feedback, proposed other libraries to use, or other solutions. It generates some classes for which I write tests. I also need to understand the code it generates. If I don't I don't use it. It does speed up my process of creation of code. If other people also are accelerated lets say 30% then, everything is sped up, cheaper. I think many people use it AI like that. It is just a tool, like a hammer, with which you can harm yourself if you do not know how to use it.
- skydhash 8mo ago
  > I think the cost and work remains the same. What has change is efficiency. Previously people had to manually program byte after byte. Then came C and streamlined it, allowing faster development. I think you got your history wrong. People didn’t program bit by bit. They programmed on paper (flowcharts, pseudo-code, diagrams,…), then encoded that afterwards. There was a lot of programming languages before C like Lisp and APL (which are high-level, btw). Why would they waste precious computer time, when you could plan out procedures on a notepad or a whiteboard.
thih9 8mo ago
> When you drop your standards, then writing generated code is quick, easy and cheap. Not as cheap as generating code of equivalent quality with an LLM.
ap99 8mo ago
Code has a generation cost and a maintenance cost. If you just look at generation then sure it's super cheap now. If you look at maintenance, it's still expensive. You can of course use AI to maintain code, but the more of it there the more unwieldy it gets to maintain it even with the best models and harnesses.
- kakacik 8mo ago
  I 'love' that folks are seemingly inching slowly towards more acceptance of crappy llm code. Because it costs marginally less to produce to production if you just pass some smoke tests? Have we not learned anything about technical debt and how it bites back hard? Its not even seniority question, rather just sane rational approach to our craft unless one wants to jump companies every few months like a toxic useless apple (not sure who would hire such person but world is big and managers often clueless). There are of course various use cases, for few this is an acceptable tradeoff but most software ain't written once and never touched (significantly) again, in contrary.
  - hnthrow0287345 8mo ago
    People aren't interested in long-term thinking when companies are doing layoffs for bullshit reasons and making vague threats about how most of us will have to go find a new career which causes a heck of a lot of stress and financial costs. That isn't being petty, it's having self-respect. They get the quality when the companies treat the craftspeople with respect.
  - pdhborges 8mo ago
    I wouldn't say acceptance of crappy code. I think the issue is the acceptance of LLM plans with just a glance and the acceptance of code without any code review by the author at all because if the author would waste any more time it wouldn't be worth it anymore.
  - kranner 8mo ago
    The inching-towards-acceptance of crappy processes is quite influencer-driven as well, with said influencers if not directly incentivised by LLM providers, then at least indirectly incentivised by the popularity of outrageous exhortations. There's definitely a chunk of the developer population that's not going to trade the high-craft aspects of the process for output-goes-brrr. A Faustian bargain if ever I saw one. If some are satisfied by what comes down to vibe-testing and vibe-testing, I guess we wish them well from afar.
AyanamiKaine 8mo ago
I really like the idea of Ousterhout's tactical vs strategic programming. Where we either create a new feature as fast as possible vs focusing on architecture and keeping complexity in check. I truly believe that LLMs are replacing tactical programming. Focusing on implementing features as fast as possible with not much regards to the overall complexity of a system. Its more important then ever to focus on keeping complexity low at a system level.
pmontra 8mo ago
The problem is to know what to write. I spent a whole day yesterday to understand what the problem was with a PDF file we were failing to process. Once I understood the cause it took one line of code to fix it and another dozen of lines for a unit test. A LLM helped me to write the code to explore several possible candidate problems but it did not find the problem by itself. So code is both cheaper (what the LLM wrote for me much faster than I could have typed it) and is also expensive (the only line that we deployed to production today.)
zahlman 8mo ago
Yeah, I have to agree. Worth noting that deterministic "code-generation" systems have existed for quite some time. It's just that once you saw something like that being useful for your system, that gave pause to critique the existing system design. Boilerplate is boilerplate, whether filling it in is purely mechanical or benefits from an LLM's fuzzy logic.
deterministic 8mo ago
> When you drop your standards, then writing generated code is quick, easy and cheap Nope not at all long term. That's the kind of code that leads to maintenance hell, very angry customers, and burned out developers.

random3 8mo ago

Code is cheaper. Simple code is cheap. More complex code may not be cheaper. The reason you pay attention to details is because complexity compounds and the cheapest cleanup is when you write something, not when it breaks. This last part is still not fully fleshed out. For now. Is there any reason to not expect things to improve further? Regardless, a lot of code is cheap now and building products is fun regardless, but I doubt this will translate into more than very short-term benefits. When you lower the bar you get 10x more stuff, 10x more noise, etc. You lower it more you get 100x and so on.

simonw 8mo ago

I was careful to say "Good code still has a cost" and "delivering good code remains significantly more expensive than [free]" rather than the more aesthetically pleasing "Good code is expensive. I chose this words because I don't think good code is nearly as expensive with coding agents as it was without them. You still have to actively work to get good code, but it takes so much less time when you have a coding agent who can do the fine-grained edits on your behalf. I firmly believe that agentic engineering should produce better code. If you are moving faster but getting worse results it's worth stopping and examining if there are processes you could fix.

akiselev 8mo ago
Totally agreed. I’ve been reverse engineering Altium’s file format to enable agents to vibe-engineer electronics and though I’m on my third from scratch rewrite in as many weeks, each iteration improves significantly in quality as the previous version helps me to explore the problem space and instruct the agent on how to do red/green development [1]. Each iteration is tens of thousands of lines of code which would have been impossible to write so fast before so it’s been quite a change in perspective, treating so much code as throw away experimentation. I’m using a combination of 100s of megabytes of Ghidra decompiled delphi DLLs and millions of lines of decompiled C# code to do this reverse engineering. I can’t imagine even trying such a large project for LLMs so while a good implementation is still taking a lot of time, it’s definitely a lot cheaper than before. [1] I saw your red/green TDD article/book chapter and I don’t think you go far enough. Since we have agents, you can generalize red/green development to a lot of things that would be impractical to implement in tests. For example I have agents analyze binary diffs of the file format to figure out where my implementation is incorrect without being bogged down by irrelevant details like the order or encoding of parameters. This guides the agent loop instead of tests.
inejge 8mo ago
> I was careful to say "Good code still has a cost" and "delivering good code remains significantly more expensive than [free]" rather than the more aesthetically pleasing "Good code is expensive. Which is nuance that will get overlooked or waved away by upper management who see the cost of hiring developers, know that developers "write code", and can compare the developer salary with a Claude/Codex/whatever subscription. If the correction comes, it will be late and at the expense of rank and file, as usual. (And don't be naive: if an LLM subscription can let you employ fewer developers, that subscription plus offshore developers will enable even more cost saving. The name of the game is cost saving, and has been for a long time.)
- dasil003 8mo ago
  Sure, but clueless leadership is not a new thing. While big companies with structural moats can shamble along with a surprising amount of dysfunction (which is why they tolerate so many muppets in middle management), even they rely on some baseline of system integrity that will erode pretty quickly if they let go of the people who know how things work. Don’t get me wrong, I think SWE headcounts will reduce over time, but the mechanism will be teams that know how to leverage AI effectively will dominate ones who don’t. This takes more market cycles though, and it’s even hard to nail down the specifics of these skills with the speed agentic coding tools are currently evolving. My advice is make yourself part of the second group, and worry less about bad management decisions that are inevitable.

mmsc 8mo ago

Spaghetti code was always a thing though

chasd00 8mo ago
Yeah people going on and on about peerless human generated code reminds me of that scene in iRobot when the cop asks sonny “can a robot create a work of art?” And the robot replies “can you?”. In 30 years in this industry I’ve yet seen what I would describe as perfect and maintainable code. It’s an aspirational dream not SOP.

unfunco 8mo ago

Computer programming is cheap. Software engineering is expensive.

wlruys 8mo ago

Definitely the market incentives for "good code" have never been worse, but I'm wouldn't be so sure the cost of migrating decent pieces of generated code to good code is worse than writing good code from whole cloth.

strogonoff 8mo ago
I find that implementing a sound solution from scratch is generally lower effort than taking something that already exists and making it sound. The former: 1) understand the problem, 2) solve the problem. The latter: 1) understand the problem, 2) solve the problem, 3) understand how somebody or something else understood & solved the problem, 4) diff those two, 5) plan a transition from that solution to this solution, 6) implement that transition (ideally without unplanned downtime and/or catastrophic loss of data). This is also why I’m not a fan of code reviews. Code review is basically steps 1–4 from the second approach, plus having to verbally explain the diff, every time.
- locknitpicker 8mo ago
  > This is also why I’m not a fan of code reviews. That's specious reasoning. Code reviews are a safeguard against cowboy coding, and a tool to enforce shared code ownership. You might believe you know better than most of your team members, but odds are a fresh pair of eyes can easily catch issues you snuck in your code that you couldn't catch due to things like PR tunnel vision. And if your PR is sound, you certainly don't have a problem explaining what you did and why you did it.
  - strogonoff 8mo ago
    Code reviews have their place. I just personally don’t like being the reviewer, because it’s more effort on your part than just writing the damn thing from scratch while someone else gets the credit for the result[0]. Of course, having multiple pairs of eyes on the code and multiple people who understand it is crucial. [0] Reviews are OK if I enjoy working with the person whose work I’m reviewing and I feel like I’m helping them grow.

bfbf 8mo ago

In my experience, it’s even more effort to get good code with an agent-when writing by hand, I fully understand the rationale for each line I write. With ai, I have to assess every clause and think about why it’s there. Even when code reviewing juniors, there’s a level of trust that they had a reason for including each line (assuming they’re not using ai too for a moment); that’s not at all my experience with Codex. Last month I did the majority of my work through an agent, and while I did review its work, I’m now finding edge cases and bugs of the kind that I’d never have expected a human to introduce. Obviously it’s on me to better review its output, but the perceived gains of just throwing a quick bug ticket at the ai quickly disappear when you want to have a scalable project.

cpursley 8mo ago
Throw your next bug at this: https://skills.sh/obra/superpowers/systematic-debugging https://skills.sh/obra/superpowers/systematic-debugging
- mixologic 8mo ago
  I find it amazing that skills are essentially excellent tools for humans to understand too.
  - Vegenoid 8mo ago
    I really wish they were called lessons instead of skills. It makes way more sense and prevents the overloading of the term "skill".
    - soulofmischief 8mo ago
      We'd just be overloading "lessons" as well, and even more so because it takes more work to ground the concept, given its larger semantic distance from what we're describing.
    - mycall 8mo ago
      There is some papers [0] showing that the skill and agent files reduce the reasoning effectiveness in some use cases (e.g. autogenerated) [0] https://arxiv.org/abs/2602.11988 https://arxiv.org/abs/2602.11988 reference: https://news.ycombinator.com/item?id=47034087 https://news.ycombinator.com/item?id=47034087

renegat0x0 8mo ago

I think the cost and work remains the same. What has change is efficiency. Previously people had to manually program byte after byte. Then came C and streamlined it, allowing faster development. With python I can write a simple debugging UI server with a few lines. There are frameworks that allow me to complete certain tasks in hours. You do not need to program everything from scratch. The more code, the faster everything gets, since the job is mostly done. We are accelerating, but we still work 9 to 5 jobs.

shiroiuma 8mo ago
C, Python, and frameworks don't generate all-new code for every task: you're taking advantage of stuff that's thoroughly tested. That simple debugging UI server is probably using some well-tested libraries, which you can reasonably trust to be bug-free (and which can be updated later to fix any bugs, without breaking your code that relies on them). With AI-generated code, this isn't the case.
- renegat0x0 8mo ago
  Depends on what you think with AI-generated code. Do you mean vibe-coded? If yes, then I agree, but there are also other scenarios of AI-generated code. I use regularly AI in my hobby projects, it provides me feedback, proposed other libraries to use, or other solutions. It generates some classes for which I write tests. I also need to understand the code it generates. If I don't I don't use it. It does speed up my process of creation of code. If other people also are accelerated lets say 30% then, everything is sped up, cheaper. I think many people use it AI like that. It is just a tool, like a hammer, with which you can harm yourself if you do not know how to use it.
skydhash 8mo ago
> I think the cost and work remains the same. What has change is efficiency. Previously people had to manually program byte after byte. Then came C and streamlined it, allowing faster development. I think you got your history wrong. People didn’t program bit by bit. They programmed on paper (flowcharts, pseudo-code, diagrams,…), then encoded that afterwards. There was a lot of programming languages before C like Lisp and APL (which are high-level, btw). Why would they waste precious computer time, when you could plan out procedures on a notepad or a whiteboard.

thih9 8mo ago

> When you drop your standards, then writing generated code is quick, easy and cheap. Not as cheap as generating code of equivalent quality with an LLM.

ap99 8mo ago

Code has a generation cost and a maintenance cost. If you just look at generation then sure it's super cheap now. If you look at maintenance, it's still expensive. You can of course use AI to maintain code, but the more of it there the more unwieldy it gets to maintain it even with the best models and harnesses.

kakacik 8mo ago
I 'love' that folks are seemingly inching slowly towards more acceptance of crappy llm code. Because it costs marginally less to produce to production if you just pass some smoke tests? Have we not learned anything about technical debt and how it bites back hard? Its not even seniority question, rather just sane rational approach to our craft unless one wants to jump companies every few months like a toxic useless apple (not sure who would hire such person but world is big and managers often clueless). There are of course various use cases, for few this is an acceptable tradeoff but most software ain't written once and never touched (significantly) again, in contrary.
- hnthrow0287345 8mo ago
  People aren't interested in long-term thinking when companies are doing layoffs for bullshit reasons and making vague threats about how most of us will have to go find a new career which causes a heck of a lot of stress and financial costs. That isn't being petty, it's having self-respect. They get the quality when the companies treat the craftspeople with respect.
- pdhborges 8mo ago
  I wouldn't say acceptance of crappy code. I think the issue is the acceptance of LLM plans with just a glance and the acceptance of code without any code review by the author at all because if the author would waste any more time it wouldn't be worth it anymore.
- kranner 8mo ago
  The inching-towards-acceptance of crappy processes is quite influencer-driven as well, with said influencers if not directly incentivised by LLM providers, then at least indirectly incentivised by the popularity of outrageous exhortations. There's definitely a chunk of the developer population that's not going to trade the high-craft aspects of the process for output-goes-brrr. A Faustian bargain if ever I saw one. If some are satisfied by what comes down to vibe-testing and vibe-testing, I guess we wish them well from afar.

AyanamiKaine 8mo ago

I really like the idea of Ousterhout's tactical vs strategic programming. Where we either create a new feature as fast as possible vs focusing on architecture and keeping complexity in check. I truly believe that LLMs are replacing tactical programming. Focusing on implementing features as fast as possible with not much regards to the overall complexity of a system. Its more important then ever to focus on keeping complexity low at a system level.

pmontra 8mo ago

The problem is to know what to write. I spent a whole day yesterday to understand what the problem was with a PDF file we were failing to process. Once I understood the cause it took one line of code to fix it and another dozen of lines for a unit test. A LLM helped me to write the code to explore several possible candidate problems but it did not find the problem by itself. So code is both cheaper (what the LLM wrote for me much faster than I could have typed it) and is also expensive (the only line that we deployed to production today.)

zahlman 8mo ago

Yeah, I have to agree. Worth noting that deterministic "code-generation" systems have existed for quite some time. It's just that once you saw something like that being useful for your system, that gave pause to critique the existing system design. Boilerplate is boilerplate, whether filling it in is purely mechanical or benefits from an LLM's fuzzy logic.

deterministic 8mo ago

> When you drop your standards, then writing generated code is quick, easy and cheap Nope not at all long term. That's the kind of code that leads to maintenance hell, very angry customers, and burned out developers.