Live data from Hacker News

Writing code is cheap now

simonwillison.net

231–240 of 522 posts

Re: Writing code is cheap now

#231
post #64

This is the first "chapter" in a not-quite-book I've started working on - I have an introductory post about that here: https://simonwillison.net/2026/Feb/23/agentic-engineering-pa... The second chapter is more of a classic pattern, it describes how saying "Use red/green TDD" is a shortcut for kicking the coding agent into test-first development mode which tends to get really good results: https://simonwillison.net/gu…

I believe the ChatGPT code has a bug, in that it accepts three spaces or tabs before a code fence, while the Google Markdown spec says up to three spaces, and does not allow a tab there.

I also see that the tests generated by ChatGPT are far too few for the code features implemented. The cannot be the result of actual red/green TDD where the test comes before the feature is added.

For examples, 1) the code allows "~~~" but only tests for "```", 2) there are no tests when len(fence) fence_len, and 3) there are no tests for leading spaces.

There's also duplicate code. The function _strip_closing_hashes is used once, in the line:

  text = _strip_closing_hashes(m.group("text")).strip()
The function is:

  def _strip_closing_hashes(s: str) -> str:
      s = s.rstrip()
      # remove trailing " ###" style closers
      s = re.sub(r"[ \t]+#+\s*$", "", s).rstrip()
      return s
The ".rstrip()" is unneeded as the ".strip()" does both lstrip and rstrip.

I think that rstrip() should be replaced with a strip(), the function renamed to "_get_inline_content", and used as "text = _get_inline_content(m.group("text")).

Also, the Google spec also says "A sequence of # characters with anything but spaces following it is not a closing sequence, but counts as part of the contents of the heading:" so is it really correct to use "\s*" in that regex, instead of "[ ]*"? And does it matter, since the input was rstrip'ped already?

So perhaps:

  def _get_inline_content(s: str) -> str:
      s = s.rstrip(" ") # remove trailing spaces
      s = s.rstrip("#") # removing "#" style closers
      return s.strip() # remove leading and trailing whitespace
would be more correct, readable, and maintainable?

Re: Writing code is cheap now

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

I hear you, but it seems quicker to predict whether the agent's solution is correct/sound before running it than to compose and "start" coding yourself. Understanding something that's already there seems like less effort. But I guess it highly depends on what you are doing and its level of complexity and how much you're offloading your authority and judgment.

Re: Writing code is cheap now

#233

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…

Nice to see you here (Just reached out on bluesky over sandboxing - gandolin). I follow your work and agree and am hoping that you and others who have well earned audiences based on awesome open source work, can help with the advocacy on mental shifts, not just for developers but also non Devs that become builders.

I'm very focused on their minimalistic building experience as a way to make me and other traditional developers, not the bottleneck and empowering them end to end.

I think AI evals [1] are a big part of that route and hope that different disciplines can finally have probable product design stories [2] instead of there being big gaps of understanding between them.

[1] https://alexhans.github.io/posts/series/evals/measure-first-...

[2] https://ai-evals.io

Re: Writing code is cheap now

#234
post #203

Every modern (and not so modern) software development method hinge on one thing: requirements are not known and even if known they'll change over time. From this you get the goal of "good" code which is "easy to change code". Do current LLM based agents generate code which is easy to change? My gut feeling is a no at the moment. Until they do I'd argue code generated from agents is only good for prototypes. Once you…

We won't be able to be sure of 100% with LLMs but maybe proper engineering around evals get us to an acceptable level of quality based on the blast radius/safety profile.

I'd also argue that we should be pushing towards tracer bullets as a development concept and less so prototypes that are nice but meant to be thrown away and people might not do that.

The clean room auto porting, after a messy exploratory prototyping session would be a nice pattern, nonetheless.

Re: Writing code is cheap now

#235

The interesting thing nobody's talking about here is that cheap code generation actually makes throwaway prototypes viable. Before, you'd agonize over architecture because rewriting was expensive. Now you can build three different approaches in a day and pick the one that works. The real cost was never the code itself. It was the decision-making around what to build. That hasn't gotten cheaper at all.

This feels to me like peak sfba mentality on par with "move fast and break things". Outside of trying to create a unicorn, is this really how people create things? It seems to me that in order to obtain the ability to build things that other people like, you need to go through the process of creating things they won't. Like a painter needs to paint a bunch of crappy paintings to learn how to create a good painting. I…

> It seems to me that in order to obtain the ability to build things that other people like, you need to go through the process of creating things they won't.

Okay, granted. What does that have to do with how the code is written? Do people generally care if a web app is running from nicely formatted JS or minified JS? Is a product manager not getting better at building things people like because they're not iterating on the code themselves?

Without agreeing or disagreeing with the premise, I think a relevant metaphor* here is that the painter can practice and iterate and go from creating crappy paintings to creating good paintings, without needing to make their own paint and canvas and brushes. If they're particular, they can have their assistant go to the supply shop and get just the right things they want, with increasing specificity as needed, but they don't need to manufacture them by hand.

* Like most metaphors, it's not perfect; please try to understand the intent.

Re: Writing code is cheap now

#236
post #203

Every modern (and not so modern) software development method hinge on one thing: requirements are not known and even if known they'll change over time. From this you get the goal of "good" code which is "easy to change code". Do current LLM based agents generate code which is easy to change? My gut feeling is a no at the moment. Until they do I'd argue code generated from agents is only good for prototypes. Once you…

> Once you can ask your agent to change a feature and be 100% sure they won't break other features then you don't care about how the code looks like. That bar is unreasonably high. Right now, if I ask a senior engineer to change a feature in a mature codebase, I only have perhaps 70% certainty they won't break other features. Tests help, but only so far.

This bar only seems high because the bar in most companies is already unreasonably low. We had decades of research into functional programming, formal methods and specification languages. However, code monkey culture was cheaper and much more readily available. Enterprise software development has always been a race to the bottom, and the excitement for "vibe coding" is just the latest manifestation of its careless, thoughtless approach to programming.

Re: Writing code is cheap now

#237

The interesting thing nobody's talking about here is that cheap code generation actually makes throwaway prototypes viable. Before, you'd agonize over architecture because rewriting was expensive. Now you can build three different approaches in a day and pick the one that works. The real cost was never the code itself. It was the decision-making around what to build. That hasn't gotten cheaper at all.

I think the prototype thing is absolutely true but breaks down like all prototypes at the level of collaborating, sharing and evolving while handling entropy throug simplicity UNLESS you know what you're doing or the agent steers you with very opinionated tooling customized to your context. I'm thinking about empowering people to be builders and less so a software developer who can make the right tradeoffs.

Empowering people to work Tracer bullet style after they've selected their prototype of choice and thrown it away might be a powerful pattern that actually gets us into a nice collaborative space.

Re: Writing code is cheap now

#238
post #182

Earlier quoted context omitted.

And you think these people will now produce better results with the assistance of an LLM that was trained on their work?

No, that's the opposite of what I think. Bootcamp grads are basically obsolete now. The real skill has always been the ability to make good design decisions and that's still the case in the LLM era.

> The real skill has always been the ability to make good design decisions and that's still the case in the LLM era.

For now maybe yes but the goal is totally removing the human from the decision loop regarding technical stuff.

Re: Writing code is cheap now

#239

Earlier quoted context omitted.

Throw your next bug at this: https://skills.sh/obra/superpowers/systematic-debugging

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

Re: Writing code is cheap now

#240
post #203

Every modern (and not so modern) software development method hinge on one thing: requirements are not known and even if known they'll change over time. From this you get the goal of "good" code which is "easy to change code". Do current LLM based agents generate code which is easy to change? My gut feeling is a no at the moment. Until they do I'd argue code generated from agents is only good for prototypes. Once you…

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.
Post reply on HN