Live data from Hacker News

Writing code is cheap now

simonwillison.net

251–260 of 522 posts

Re: Writing code is cheap now

#251

I'm going to shill my own writing here [1] but I think it addresses this post in a different way. Because we can now write code so much faster and quicker, everything downstream from that is just not ready for it. Right now we might have to slow down, but medium and long term we need to figure out how to build systems in a way that it can keep up with this increased influx of code. > The challenge is to develop new p…

The focus is on downstream, but is upstream ready for this speed up?

The linked blog post draws comparisons to the industrial revolution however in the industrial revolution the speed up caused innovation upstream not downstream.

The first innovation was mechanical weaving. The bottleneck was then yarn. This was automated so the bottleneck became cotton production, which was then mechanised.

So perhaps the real bottleneck of being able to write code faster is upstream.

Can requirements of what to build keep up with pace to deliver it?

Re: Writing code is cheap now

#252
post #245
post #240

Earlier quoted context omitted.

I am constantly getting LLMs to change features and fix bugs. The key is to micromanage the LLM and its context, and read the changes. It's slower that vibe coding but faster than coding by hand, and it results in working, maintainable software.

A study last year concluded that while AI coding feels faster it actually isn't. At least in mid 2025. https://news.ycombinator.com/item?id=44522772

6 months ago in AI development is too old to be relevant.

Re: Writing code is cheap now

#253
First there's no "code". There are many different variations. Doing basic UI in React is way different from doing low-level embedded code with locking and mutexes, etc.

AI is quite good at what I call "code in-painting": you give the outlines, and it fills the boring stuff (writing out UI, writing out the test content, etc)

It's still VERY bad at maths. For technical reasons (you can't differentiate a SAT solver, so for now LLMs are mostly "hallucinating" plausible-sounding reasonings, but not doing any "solid math") And when you start reasoning about locks / mutexes, etc, what you're really doing is (some primitive form of) maths and logic.

For now, there's no easy-to-use framework (eg a streamlined way to encode the constraints in Lean / Coq etc) or AI capacities that allow to bridge something like this to make it safe for very "math-like" code. And it's easy to shoot yourself in the foot.

Re: Writing code is cheap now

#254
post #245
post #240

Earlier quoted context omitted.

I am constantly getting LLMs to change features and fix bugs. The key is to micromanage the LLM and its context, and read the changes. It's slower that vibe coding but faster than coding by hand, and it results in working, maintainable software.

A study last year concluded that while AI coding feels faster it actually isn't. At least in mid 2025. https://news.ycombinator.com/item?id=44522772

The comments explain the nuance there pretty well:

> This study had 16 participants, with a mix of previous exposure to AI tools - 56% of them had never used Cursor before, and the study was mainly about Cursor.

> My intuition here is that this study mainly demonstrated that the learning curve on AI-assisted development is high enough that asking developers to bake it into their existing workflows reduces their performance while they climb that learing curve.

Giving people a tool, that have no experience with it, and expecting them to be productive feels... odd?

Re: Writing code is cheap now

#255
I agree, writing code is cheaper than ever ... but "writing the code" isn't the main challenge in SWE since decades.

Our IT infrastructures & applications run on a stack that has grown for the past 40 years and what we are currently doing with all this LLM & vibecode mania is adding more stuff (at an accelerated rate) on the top of the stack.

The main challenge today is combining the user requirements with the stack in a way it works, it's easy to maintain and it donesn't cost too much.

Re: Writing code is cheap now

#256
post #195

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

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 than one-shotted vibe code.

Re: Writing code is cheap now

#258
post #229

Earlier quoted context omitted.

What tremendously helps is asking the LLM to add a lot a lot explanations by adding comments to each and every line or function. You can remove those comments afterwards if you feel they are too much but it helps a lot the reviewing. More a trick than a silver bullet but it's nice.

> What tremendously helps is asking the LLM to add a lot a lot explanations by adding comments to each and every line or function. No, it doesn't. It's completely useless and unhelpful. These machine-generated comments are only realizations of the context that already outputted crap. Dumping volumes of this output adds more work to reviewers to parse through to figure out the mess presented by vibecoders who didn't e…

You don't get me. I don't say that those are good comments, I even say that you should probably delete them afterwards.

But as you say, they are realization of the context of the LLM. Their role is not helping you to understand what the code is doing, but how the LLM understood the problem and how it tried to solve it. Now you can compare its own understanding with yours.

Now I need to add context myself : I'm not talking about vibe coding entire apps, here adding verbosity wouldnt help a lot. My main usage of LLMs is at $JOB where I need to execute "short" tasks into codebases I barely know most of the times, that's where I use this trick. It also have the side benefit to help me understand the codebase better.

Re: Writing code is cheap now

#259
On a higher level, this is wishful thinking. However, for people who think this way, getting code to compile at all used to be very "expensive". AI makes abstract code above machine level much easier to compile.

My benchmark for code being cheap is when AI is able to write machine level code. At that point, yes, code is cheap. Currently, the Dollar Store version of code is available.

Re: Writing code is cheap now

#260
Here's an easy to understand example. I've been playing EvE Online and it has an API with which you can query the game to find information on its items and market (as well as several other unrelated things).

It seems like a prime example for which to use AI to quickly generate the code. You create the base project and give it the data structures and calls, and it quickly spits out a solution. Everything is great so far.

Then you want to implement some market trading, so you need to calculate opportunities from the market orders vs their buy/sell prices vs unit price vs orders per day etc. You add that to the AI spec and it easily creates a working solution for you. Unfortunately once you run it it takes about 24 hours to update, making it near worthless.

The code it created was very cheap, but also extremely problematic. It made no consideration for future usage, so everything from the data layer to the frontend has issues that you're going to be fighting against. Sure, you can refine the prompts to tell it to start modifying code, but soon you're going to be sitting with more dead code than actual useful lines, and it will trip up along the way with so many more issues that you will have to fix.

In the end it turns out that that code wasn't cheap at all and you needed to spend just as much time as you would have with "expensive code". Even worse, the end product is nearly still just as terrible as the starting product, so none of that investment gave any appreciable results.

Post reply on HN