Live data from Hacker News

Lessons for Agentic Coding: What should we do when code is cheap?

dbreunig.com

201–210 of 260 posts

Re: Lessons for Agentic Coding: What should we do when code is cheap?

#201

Earlier quoted context omitted.

I was an LLM naysayer for a very long time. I continue to have serious reservations about the ethics of LLM use and the likely economic effects (these tools are likely to empower the owners of capital and disempower labor). On the other hand, I had a rather striking experience the other day that convinced me that the future in which these tools write software may not be so bad: I had an idea to improve performance in…

> Could I have written it without Claude? Yes, definitely. But I was able to produce the code in a few days while having a fever of 100-102, which I definitely couldn't have done on my own. While I admire your strength in attempting it, this just adds one more brick to the wall of precedents that "what's stopping you from just sending one prompt, it'll just take 30 seconds and you can do it in bed!" You could sum it…

That's an excellent point. To be fair, I allowed myself to work on this while I was sick only because it was fun. This was a bit like scratching an itch, because I'd had the germ of an idea for a while and wanted to get it out of my head. You're absolutely right that it sets a dangerous precedent: the easier it becomes to do work, the easier it is to demand work of the people doing it. The boundaries need to be firm.

On the other hand, this was also a case where Claude really did help me finish something more quickly than I could have without it. So in thi scase I do think it lowered the number of developer hours per feature.

Re: Lessons for Agentic Coding: What should we do when code is cheap?

#202

Earlier quoted context omitted.

A manager doesn't have to look at the code that's being shipped. An IC will still need to do that, and this will eventually take up much of their work. It can be addressed by moving up the stack to higher level and more strictly checked languages, where there's overall less stuff to review manually.

Just like a manager, you don't need to look at the code. You need to set up quality systems to provide evidence the code does what it is supposed to do, just like a manager.

I’ve never met a manager that have setup “quality” systems to ensure that the job is done correctly. Their actions are always retroactive. And not pertaining to code at all. The overarching contract is “You do a bad job, you will be fired”.

Re: Lessons for Agentic Coding: What should we do when code is cheap?

#203

I am in India, junior developer hiring is all down. Ai has reduced offshoring to India and eliminated the need for janitor work (often offloaded to juniors). Many people are finding it difficult to even land internships. The most affected areas are sysadmin, devops, and frontend. Where you'll have very hard time getting any offer. Companies like BrowserStack are withdrawing campus placement offers. Meanwhile, I am wr…

I'm surprised sys-admin hires are down, is AI doing a lot of that as well?

Yah, that comment is odd.

Sysadmins, Devops engineers will the be the last ones replaced by AI. The context window for their problems are huge.

Unless you define Sysadmins and Devops as fiddling with YAML all day, which might be the case here.

Re: Lessons for Agentic Coding: What should we do when code is cheap?

#204

Earlier quoted context omitted.

"Writing code" as a task of its own is called cowboy coding. It's neat that AI can do this now, but that has nothing to do with proper software engineering which always starts from a careful, human-led design.

Yes and every AI-first development workflow worth its salt does exactly this, and it does it much more thoroughly than I’ve ever seen a team of meatbags do it. My workflow, at a high level, is: 1. I write a high level spec. Not as high level as a single-sentence prompt, but high level enough to capture my top requirements. 2. I prompt the AI to interview me about the spec to clear up any ambiguity or open questions,…

Is this project in production and for how long? How many users?

Re: Lessons for Agentic Coding: What should we do when code is cheap?

#205

Earlier quoted context omitted.

The ticket has subtle errors in its description that are only caught by someone experienced with the codebase. The code hides an exception behind an if-then-else that defaults to the most common state, which isn't caught until it breaks things for the 1% of users who don't have that state. The new feature quietly breaks a feature not covered by the acceptance tests. The documentation is four times as long and nobody…

People noted similar issues ever since LLMs came out, but the rate at which they have been rapidly improving on all of these is significant. Documentation being 4x too long could probably be fixed with a rule instructing the agent to keep it concise and no longer than 2-3 paragraphs.

They seem to be converging toward an asymptotic accuracy level that is not particularly close to 100%. That is not good enough when you're trying to instruct engineers, particularly junior ones.

Re: Lessons for Agentic Coding: What should we do when code is cheap?

#207
Good list, I have intuitively realized all of these except for (3). I agree with the author: cheap experiments to figure out a grand architectural plan, then executing fast without needing to wait for input is the right way to go. "Automate everything that's easy" is also important, but I'd extend it and say you probably should try to automate things that are hard too: it's worth spending a great deal of time on it simply due to how crazy valuable the returns are. But I guess I should look more into end-to-end testing.

Re: Lessons for Agentic Coding: What should we do when code is cheap?

#208

A lot of people down on AI in this thread, but I'm watching the industry slip over the line of trust with these latest frontier models. GPT 5.5 is the first model good enough for me to just let rip. Every jira ticket I see now has acceptance criteria, reproduction steps, and detailed information about why the ticket exists. Every commit message now matches the repo style, and has detailed information about what's con…

The ticket has subtle errors in its description that are only caught by someone experienced with the codebase. The code hides an exception behind an if-then-else that defaults to the most common state, which isn't caught until it breaks things for the 1% of users who don't have that state. The new feature quietly breaks a feature not covered by the acceptance tests. The documentation is four times as long and nobody…

I will give you 4.

1, 2 and 3 happened a ton in the good old times before AI. If anything, we can make the code be more tested than before, but that requires a lot more engineering, that is made easier by LLMs.

It's just we haven't adapted to do them.

Re: Lessons for Agentic Coding: What should we do when code is cheap?

#209

A lot of people down on AI in this thread, but I'm watching the industry slip over the line of trust with these latest frontier models. GPT 5.5 is the first model good enough for me to just let rip. Every jira ticket I see now has acceptance criteria, reproduction steps, and detailed information about why the ticket exists. Every commit message now matches the repo style, and has detailed information about what's con…

Yes, the software that piles up literally is the tech debt. Every automation and tool that was vibe-coded has to be maintained as well. If software is 100x easier to write and you write 100x as much of it, then taking into account network effects, your tech debt is now 100x worse. Congrats!

Re: Lessons for Agentic Coding: What should we do when code is cheap?

#210
It's not a question of cheap or expensive; it's when to pay what costs.

With LLM's, it's arguably easier to avoid exporting costs to the future, or to export them.

Whether because of LLM's or frameworks, process consistency typically creates a forcing function to continuously improve quality (i.e., avoid exporting costs); for each problem, create step in the process to surface and address it - hopefully in an automated way.

Having spent lifetimes trying to get teams to up their game, I'm hopeful this may help, if it gets baked in not just to code generation, but to process.

Post reply on HN