If writing code was the only part of the job, and it was easy, these jobs wouldn't pay so well.
Engineering is hard. It's always going to be hard. I'm glad that AI makes some parts of it easier, and we (software engineers) can focus on engineering, that's nice.
Code is NEVER cheap. Just because, at current completely unrealistic AI pricing, using agents is cheaper than hiring juniors, does not make code cheap. It makes producing code cheap, which has always been low-cost. Every line of code is a cost, is a maintenance burden, is complexity. An AI, even with somehow infinite context window, will cost more money the more code you have.
Could you replace a whole team of engineers with AI? Probably, yeah. Could you simply fire everyone at your company and close it down, without much of a problem? Also probably yes, for most companies.
AIs can help with debugging, can help with writing code, with drafting designs, they can help with almost every step. The second you let OpenAI, or Anthropic, take full code ownership over your products, and you fire the last engineer, is the time when the AI pricing can go up to match what engineers make today. You've just reinvented the highly paid consultant.
Or you could take the middle-ground and hire good engineers, make sure they maintain an understanding of the codebase, and let them use whatever tools they use to get the job done, and done well. This is the way that I've seen competent companies handle it.
"Producing code has always been low cost"
Relative to what?
I don't understand people dismissing the massive decrease in both cost of producing code and the speed of producing code.
Before AI, people running businesses had similar issued as people have with AI now, but the costs were much greater.
They could hire someone to write them a prototype for their idea, but it would cost them on the order of 1000s of dollars, and it would take weeks at the minimum!
Now it could cost them 20$ and be done in a few days. The feedback loop is the bottleneck.
I'm not dismissing it, I'm saying it's never been the bottleneck. Like you said, the feedback loop is A bottleneck, so is figuring out all the nasty things that nobody on HN seems to have heard of before, like "what are the requirements", "which tradeoffs can we make to get this done in time", "what is the architecture for this", and building it in such a way that you can guarantee that it won't fall apart in 20 years when your requirements change.
Code has always been a bottleneck for any product which involves software.
I understood it in the spirit of “code is a liability not an asset.” Code still needs to be maintained, changed, etc whether that is by a human or LLM.
In other words, just because more code can be produced quickly does not mean that it is cheap.
edit: I’m maybe hearing your point is that LLMs may change that POV but I think that is TBD.
I don't really think that's accurate either, from a business POV.
Software has been such a gold mine, exactly because the maintenance are minimal when you scale, compared to the revenue. The upfront costs are expensive, but once you have software built, in most cases it's relatively cheap to maintain
Things can provide value to a business while still acting as a liability -- that is to say, by virtue of their existence they cost you money, even if, when properly leveraged, they can be used as a tool to make more.
Consider a canonical loan: you get a pile of cash, but in exchange you need to make regular interest payments (plus, at some point pay back the principal, but this isn't strictly necessary -- e.g. governments used to issue perpetual bonds, which paid their coupons indefinitely). The analogy I would make with software is that the product has value, but the code you use to create it is a liability, in that it demands continuous maintenance and upkeep. Just as when you go shopping for a car loan, you look for one with the smallest interest rate -- if the debt itself were an asset, you would want more of it, which doesn't make sense. In the same way, it behooves a business to try and achieve its goals with a relatively small amount of code, not to create as much software as possible.