[tabs_or_spaces]

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

[bfbf]

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.

[heisenbit]

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.

[zozbot234]

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.

[cpursley]

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

[vips7L]

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

Even my seniors are just copy pasting out whatever Claude says. People are naturally lazy, even if they know what they’re doing they don’t want to expend the effort.

[frgturpwd]

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.

[simonw]

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]

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]

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

[mexicocitinluez]

> I chose this words because I don't think good code is nearly as expensive with coding agents as it was without them.

Still navigating this territory, but I think a lot of people are getting caught up on the idea that producing code is simply a matter of typing it at the keyboard.

One of the benefits of something like Claude Code isn't just the code it produces, but the ability to quickly try out ideas, get some feedback, AND THEN write the good code.

> than the more aesthetically pleasing

Agreed. What even is "good" code? So much of the bad code I write isn't necessarily that it's ugly, it's bad because it misses the mark. Because I made too many assumptions and didn't take the time to actual learn the domain. If I can eek out even a few more hours a week to actually build worthwhile solutions because I was able to focus a bit more, it's a win to me. My users in particular have a really difficult time imagining features without actually seeing them. They have a hard to articulating what's wrong/right without something tangible in front of them. It would be hard to argue that having the ability to quickly prototype and demo features to people is a bad thing.

[kranner]

> I was careful to say "Good code still has a cost" ...

Misleading headline, with the qualifier buried six paragraphs deep. You have a wide enough readership (and well deserved too). Clickbait tactics feel a little out of place on your blog.

[random3]

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.

[unfunco]

Computer programming is cheap. Software engineering is expensive.

[AyanamiKaine]

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.

[ap99]

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]

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.

[neilwilson]

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.

[pmontra]

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

[renegat0x0]

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]

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.

[skydhash]

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

[zahlman]

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]

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

[mmsc]

Spaghetti code was always a thing though

[chasd00]

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.

[thih9]

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

[wlruys]

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]

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.