Hacker News Reader

Comment by fvdessen | Hacker News Reader

I find it excellent news that all the techniques that make agentic coding more efficient also make human coding more efficient. There was a worry that code would become big mud balls that only AI understand, but it looks like the opposite. Clear code is important for AI productivity, so it now matters even more, because the difference of productivity is immediately and objectively measurable. Before AIs what code was well factored or not was largely a matter of opinion. Now you can say; look how better Claude works on codebase A vs codebase B, and present your case with numbers.

View on HN

> There was a worry that code would become big mud balls

That's always been a worry with programming (see basically all Rich Hickey talks), and is still a problem since people prefer "moving fast today" instead of "not having 10 tons of technical debt tomorrow"

LLMs makes it even easier for people to spend the entire day producing boilerplate without stopping for a second to rethink why they are producing so much boilerplate. If the pain goes away, why fix it?

Literally less than an hour ago, I reviewed a bunch of LLM-generated boilerplate. I then told the agent to show me a plan to refactor it. I suggested some tweaks, and then it implemented the plan and then tested that it didn't break anything.

It isn't much different than dealing with an extremely precocious junior engineer.

Given how easy it is to refactor now, it certainly makes economic sense to delay it.

But I'm guessing you're doing those refactors because you know they're ultimately worth it, because you have experience programming since before LLMs?

Like I know boilerplate and messy code sucks because I've had to work with it, without LLMs, and I know how much it sucks. I think you do too, but I think we know that, because we had to fight with it in the past.

Right now devs around the world are pushing ungodly amounts of reinforcement learning data into the big AI labs. There is no reason to believe these models won't handle this stuff themselves and our priors will become a useless relic.

LLMs start to bog down with it at a certain point too. For a couple of my side projects, I decided to let things rip and now worry about code structure at all. After a certain point some of the changes I wanted to make just started either failing work racking up large bills. It would try to make a change, run tests, realize it broke something somewhere else, try to fix that, cause another issue. Undo the original thing, fix the new issue, maybe try to refactor, partially, fail, revert that, decide to make the tests pass by removing the tests! and then keep some broken version of fix. With a few similar cycles of that on repeat as well.

Deliberately telling it how to rethink the structure, refactor first, then seperate out components fixed things.

IF LLMs stayed at the current level, I would expect llm-aided-coders to learn how to analyze and address situations like this. However, I do expect models to be better able to A) avoid these kinds of situations with better design up front or reflection when making changes and B) identify more systematic patterns and reason about the right way to structure things. Basically ambiently detecting "code smells."

You can already see improvements both from newer models and from prompt engineering coming from the agentic tools.

The type of person that would do that would have done the same thing without LLMs. LLMs don’t change anything except now they can just create their big ball of mud faster.

The pain of shitty code doesn’t go away. They can ship your crappy MVP faster, but technical debt doesn’t magically go away.

This is an awesome opportunity for those people to start learning how to do software design instead of just “programming”. People that don’t are going to be left behind.

"There was a worry that code would become big mud balls that only AI understand, but it looks like the opposite."

For now...

As long as interfaces are well defined, comprehensive tests are written, memory is safely handled and time complexity is analyzable, who cares what the rest of the code looks like.

I understand programming for the sake of programming, chasing purity and really digging into the creative aspects of coding. But I get that same kick out of writing perfect interfaces, knowing that the messier the code underneath is, the more my beautiful interface gets to shine. But transformers are offering us a way to build faster, to create more, and to take on bigger complexity while learning deeply about new domains as we go. I think the more we lean into that, we might enter a software golden age where the potential for creativity and impact can enter a whole new level.

Yeh, exactly. Code doesn’t matter. Correct and stable electrical states matter.

Energy based models and machines that boot strap from models, organize their state to a prompt are on their way. The analog hole for coders is closing.

Most software out there is the layers of made up tools and such to manage and deploy software. We’ll save a lot of cycles pruning it all for generic patterns.

5-10 more years it’s all hardware again. Then no longer need to program a computer like it’s 1970.

> As long as interfaces are well defined, comprehensive tests are written, memory is safely handled and time complexity is analyzable, who cares what the rest of the code looks like

The thing is, code that does all of the things you listed here is good looking code almost by definition

If AI was anywhere near capable of producing this quality then it would be so thrilling, wouldn't it?

But it's not. The consensus seems to be pretty universal that AI code is Junior to Intermediate quality at best, the majority of the time

That generally isn't code that satisfies the list of quality criteria you mentioned

Do you give the agent a style guide?

Do you perform (or have another agent perform) code reviews on the agent's code?

Do you discuss architecture and approach with the agent beforehand and compile that discussion into a design and development plan?

If you don't do these things, then you're just setting yourself up for failure.

Ah yes the tried and true "you're holding it wrong"

By the time I did all the stuff you're suggesting, I could just build the damn thing myself

Would you skip these guardrails when working with a "Junior to Intermediate" developer?

No, but the goal of mentoring a Junior or Intermediate developer is that they eventually learn this stuff on their own. The value of helping another human grow is worth the tradeoff

AI is a tool, not a human. I'm not about to invest in it the way I would a Junior developer. If the tool doesn't do the job, it's not a good tool. If a tool requires the same level of investment that a human does it's also not a good tool

These factors are now getting baked into the tools. Primarily via prompt engineering, and what might be called "agentic design," which is how much complexity you put into a single pass vs some hierarchical layering of agents and tools with distinct jobs.

I've been deobfuscating claude code to watch their prompts evolve as I use it and you an see the difference around how and when it chooses to re-analyze a codebase or how it will explicitly breakup work into steps. A lot of the implicit knowledge of software engineering is being added, _outside_ of the LLM training.

But you are holding it wrong, and experience is the difference in being able to recognize when oft-repeated advice should actually be seriously considered, vs dismissing entire swaths of engineers who are holding it right.

Do you know how tiring it gets to constantly engage with people who complain about agentic workflows without actually having the experience or knowledge to properly evaluate them? These people already have intentionally closed their minds on the subject, but still love to debate it loudly and frequently even though they have little intention of actually considering others' arguments or advice. What could be an educational moment turns into ideological warfare reminiscent of the text editor or operating system wars.

It's beginning to get infuriating, because of the unbridled arrogance typically encountered by naysayers.

That’s just the hallmark of good software engineering or do you think everyone else was cowboy coding things with Vim before?

Seemingly so going by the sibling comment to yours.

> As long as interfaces are well defined, comprehensive tests are written, memory is safely handled and time complexity is analyzable, who cares what the rest of the code looks like.

Software engineers and anyone who'd get hired to fix the mess that the LLM created. Also, ironically, other LLMs would probably work better on...not messy code.

> But transformers are offering us a way to build faster, to create more, and to take on bigger complexity

Wow. You sound as if building faster or creating more is synonymous with quality or utility. Or as if LLMs allow us to take on a bigger level of complexity (this is where they notoriously crumble).

> we might enter a software golden age where the potential for creativity

I haven't heard of a single (good) software engineer whose creativity was stifled by their inability to code something. Is an LLM generating a whole book in Hemingway style considered creative, or a poem? Or a program/app?

I was struck by this too. Good error messages, fast tools, stable ecosystems, simple code without magic, straight SQL… it’s what I always want. Maybe agents will be what raises the bar for dev experience, simply because they work so quickly that every slowdown matters.

Reply on news.ycombinator.com