Live data from Hacker News

Writing code is cheap now

simonwillison.net

321–330 of 522 posts

Re: Writing code is cheap now

#321
post #291

Earlier quoted context omitted.

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.

Once writing code is cheap you don't maintain code. You regenerate it from scratch. What you maintain is the specification harness, and change that to change the code. We have to start thinking at a higher level, and see code generation in the same way we currently see compilation.

I'm not sold on that idea yet.

I don't just have LLMs spit out code. I have them spit out code and then I try that code out myself - sometimes via reviewing it and automated tests, sometimes just by using it and confirming it does the right thing.

That upgrades the code to a status of generated and verified. That's a lot more valuable than code that's just generated but hasn't been verified.

If I throw it all away every time I want to make a change I'm also discarding that valuable verification work. I'd rather keep code that I know works!

Re: Writing code is cheap now

#322
post #291

Earlier quoted context omitted.

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.

Once writing code is cheap you don't maintain code. You regenerate it from scratch. What you maintain is the specification harness, and change that to change the code. We have to start thinking at a higher level, and see code generation in the same way we currently see compilation.

Unless the specification is also free of bugs and side effects, there is no guarantee that a rewrite would have fewer bugs.

Plenty of rewrites out there prove that point.

Re: Writing code is cheap now

#323

> 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…

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.

Re: Writing code is cheap now

#324
post #195

Earlier quoted context omitted.

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.…

You need to have the AI write an increasingly detailed design and plan about what to code, assess the plan and revise it incrementally, then have it write code as planned and assess the code. You're essentially guiding the "Thinking" the AI would have to perform anyway. Yes, it takes more time and effort (though you could stop at a high-level plan and still do better than not planning at all), but it's way better tha…

TDD is a great way to start the plan, stubbing things it needs to achieve with E2E tests being the most important. You still need to read through them so it won't cheat, but the codebase will be much better off with them than without them.

Re: Writing code is cheap now

#325
post #291

Earlier quoted context omitted.

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.

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 ap…

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.

Re: Writing code is cheap now

#326

Earlier quoted context omitted.

I find it amazing that skills are essentially excellent tools for humans to understand too.

I really wish they were called lessons instead of skills. It makes way more sense and prevents the overloading of the term "skill".

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

reference: https://news.ycombinator.com/item?id=47034087

Re: Writing code is cheap now

#327
> 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.

Wasn't writing code always cheap? I see this more like a strawmen argument. What is clean code? Tested code? Should each execution path of a function be tested with each possible input?

I think writing tests is important but you can over do it. Testing code for every possible platform takes of course much time and money.

Another cost factor for code is organization overhead, if adding a new feature needs to go through each layer of the organization signing it off before a user can actually see it. Its of course more costly than the alternative of just pushing to production with all its faults.

There is a big difference of short term cost and long term ones. I think LLMs reduce the short time cost immensely but may increase the long term costs. It will take some real long studies to really show the impact.

Re: Writing code is cheap now

#328
Each line of code is a liability.

I think it’s funny that we’re all measuring lines of code now and smiling.

It was/is expensive because engineers are trying to manage the liability exposure of their employers.

Agents give us a fire hose of tech debt that anyone can point at production.

I don’t think the tool itself is bad. But I do think people need to reconsider claims like this and be more careful about building systems where an unaccountable program can rewrite half your code base poorly and push it to production without any guard rails.

Re: Writing code is cheap now

#329

Earlier quoted context omitted.

There is demand for non scalable, not committed to be maintained code where smaller issues can tolerated. This demand is currently underserved as coding is somewhat expensive and focused on critical functions.

What are some examples of when buggy code can be tolerated?

Points at the public sector

Re: Writing code is cheap now

#330
post #280

Earlier quoted context omitted.

100%. That's why if you want good code you need to pay attention to what it's writing and testing and throw feedback like that at it.

My points though are 1) the development isn't actually using red/green TDD, and 2) the result doesn't show "really good results", including not following a very well-defined specification so doesn't work as a concrete example of your description of what the second chapter is supposed to be about. Perhaps you could show the process of refining it more, so it actually is spec compliant and tests all the implemented fea…

Yeah I'm going to ditch those examples and find better ones. I was hoping to illustrate the idea as simply as possible but they're not up to scratch.
Post reply on HN