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

▲

simonw 2 hours ago | parent | next [-]

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 an hour ago \| parent [-]
		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.

▲

random3 2 hours ago | parent | prev | next [-]

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.

▲

wlruys 42 minutes ago | parent | prev | next [-]

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 33 minutes ago | parent [-]

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 the final step of verbally explaining the diff.

▲

locknitpicker 20 minutes ago | parent [-]

> This is also why I’m not a fan of code reviews.

That's specious reasoning. Code reviews are a safeguard against cowboy coding, and a tool to enforce shared code ownership. You might believe you know better than most of your team members, but odds are a fresh pair of eyes can easily catch issues you snuck in your code that you couldn't catch due to things like PR tunnel vision.

And if your PR is sound, you certainly don't have a problem explaining what you did and why you did it.

	▲	strogonoff 12 minutes ago \| parent [-]
		Code reviews have their place. I just personally don’t like doing them, because it’s more effort on your part than just writing the damn thing from scratch while someone else gets the credit for the result[0]. Of course, having multiple pairs of eyes on the code and multiple people who understand it is crucial. [0] Reviews are OK if I enjoy working with the person whose work I’m reviewing and I feel like I’m helping them grow.

▲

unfunco an hour ago | parent | prev | next [-]

Computer programming is cheap. Software engineering is expensive.

▲

mmsc an hour ago | parent | prev [-]

Spaghetti code was always a thing though