Live data from Hacker News

Agentic Coding Is a Trap

larsfaye.com

121–130 of 403 posts

Re: Agentic Coding Is a Trap

#121

Using AI to go faster is optimizing the wrong thing. At every place I've worked, the "code writing" part takes the least amount of time, compared to all the other things you need to do in order to implement a feature. Let's examine a feature that takes a day to code: First, you've got to plan everything, using whatever Agile or Waterfall planning ritual your company uses, get the task breakdown, file the JIRA tickets…

I think it depends a lot on how automated the agent is and how long you let it run for. Full automation where you try to build an entire piece of software with agents... yeah, no, we are not there yet. At least not a few you care about maintainability.

Short-lived tightly-scoped agents can do alarmingly thorough and high-quality knowledge work, as long as the work itself is relatively mechanical and can either be carried out in independent chunks or sequentially. For example, a research agent like the Gemini "deep research" tool can save hours of digging around the web and compiling information. With careful prompting, sufficient background context, and good self-evaluation tools, an agentic loop can do very detailed data analysis, carry out serious statistics and machine learning projects, produce high-quality data visualization thereof, and put together a handy executive summary.

They occasionally hallucinate, go off track, get confused, and make mistakes. But they "know" everything that's been published in English for the last 200 years, they never get tired, and the code they write is good enough for throwaway scripting. The real power of agents being able to write code is that they can be extremely self-sufficient and flexible in carrying out these kinds of tree- and sequence-structured knowledge work tasks.

That's of course a different thing from "designing good software", which is neither tree-structured or sequential, and requires a level of intelligence (for lack of a better term) that LLMs do not seem to be capable of, at least not yet. But that's a more specific thing than just writing code in order to get stuff done that happens to require code.

Re: Agentic Coding Is a Trap

#122

Interestingly I’ve learned more about languages and systems and tools I use in the last few years working with agentic coding than I did in 35 years of artisanal programming. I am still vastly superior at making decisions about systems and techniques and approaches than the agentic tools, but they are like a really really well read intern who knows a great deal of detail about errata but have very little experience.…

you have 35 years of experience and have already built up the learning capability and general framework to acquire new knowledge. you know how to use agentic coding as a tool to supplement your work. the juniors who start today don't have that, they overrely on agentic coding and do not know what they don't know

someone probably made this same argument against certain frameworks over the years and juniors still figured it out. we need to stop trying to babysit learning for hypothetical situations.

the bar to "start" is lower and the bar to actually competency is higher now, juniors who want to actually learn instead of just pressing enter over and over again will do so regardless of whatever you do to "help" them.

Re: Agentic Coding Is a Trap

#123

Using AI to go faster is optimizing the wrong thing. At every place I've worked, the "code writing" part takes the least amount of time, compared to all the other things you need to do in order to implement a feature. Let's examine a feature that takes a day to code: First, you've got to plan everything, using whatever Agile or Waterfall planning ritual your company uses, get the task breakdown, file the JIRA tickets…

Or you can have a conversation with an agent to build up a requirements/plan spec, asking it to analyse existing code patterns. When it seems like the agent has a good understanding of what needs to be done and how. Ask it to implement, keeping changes as a local spike.

Ask the agent questions about all the other teams' code, reaching out to them for questions it can't answer or clarification. With agent capabilities atm this is rare or can be done fairly async: "please confirm these things".

Maybe realise your code architecture is completely wrong. Manually code up some new abstractions that fit better, write the learnings into the spec plan. Strip out any implementation that largely doesn't fit your updated abstractions. Ask the agent to migrate the code to the new structure.

Repeat until spike is operational and you're happy with the abstractions used

Chat with the agent to create a Design Doc for the approach in the spike. Create a single JIRA ticket for "Productionise CodeShmode's spike". Get reviews and feedback from stakeholders.

Integrate feedback into your spike, or even the original spec document and regenerate the whole thing.

So much of the ritual you've outlined here is overhead from working in a large org where roles are siloed. When one person is empowered to do more then the actual work per person goes down and the overhead becomes the dominant. But that overhead isn't needed anymore because one person can now do many people's work.

I've whipped up spikes in a few days that would've been a month of work across a team multiple DDs and approvals. In the past this wasn't feasible so we would need to justify what those people would work on. Now you can whip it up, show a working demo and ask "should we productionise this"

Re: Agentic Coding Is a Trap

#124
post #79

As a senior developer, 25+ years, I have been thrown recently into a meeting "hey can you join in for 5 mins". I really don't like these meetings where you're dragged in in the middle of them without any clue. The questions came flying in fast, without any introduction, and this was about an external integration out of a dozen. They have their own lingo, different from ours, to make the situation worse. I had a _very…

> As a senior developer, 25+ years, I have been thrown recently into a meeting "hey can you join in for 5 mins".

This is a common thing doctors complain about. Patients come in, saying they just need a prescription for some drug or other. Good doctors often refuse to give any drugs or any advice until they understand the whole situation properly.

If you're a senior developer, you're the one who has to push back against behaviour you don't like. You have the authority. "Hm, interesting question. I'm going to need more context before I can give you my point of view. Can you give me a quick overview of the system architecture / explain what actual problems you're trying to solve with this approach?"

Re: Agentic Coding Is a Trap

#126

Using AI to go faster is optimizing the wrong thing. At every place I've worked, the "code writing" part takes the least amount of time, compared to all the other things you need to do in order to implement a feature. Let's examine a feature that takes a day to code: First, you've got to plan everything, using whatever Agile or Waterfall planning ritual your company uses, get the task breakdown, file the JIRA tickets…

>Using AI to go faster is optimizing the wrong thing. At every place I've worked, the "code writing" part takes the least amount of time, compared to all the other things you need to do in order to implement a feature. Let's examine a feature that takes a day to code:

Ai writes the plans now. I just review and modify.

Re: Agentic Coding Is a Trap

#127

>and then pulls the slot machine lever over and over Does anyone really do this? You want verification and self-correction in a loop, not rerolling and cherrypicking. The non-determinism point is really tiresome to hear over and over.

> The non-determinism point is really tiresome to hear over and over.

When the problem is fixed, you'll stop hearing about it.

Re: Agentic Coding Is a Trap

#130

Using AI to go faster is optimizing the wrong thing. At every place I've worked, the "code writing" part takes the least amount of time, compared to all the other things you need to do in order to implement a feature. Let's examine a feature that takes a day to code: First, you've got to plan everything, using whatever Agile or Waterfall planning ritual your company uses, get the task breakdown, file the JIRA tickets…

> Using AI to go faster is optimizing the wrong thing. At every place I've worked, the "code writing" part takes the least amount of time, compared to all the other things you need to do in order to implement a feature.

This reminds me of one of my software engineering axioms:

  When making software, remember that it is a snapshot of 
  your understanding of the problem.  It states to all, 
  including your future-self, your approach, clarity, and 
  appropriateness of the solution for the problem at hand.  
  Choose your statements wisely.
> So here's a feature that took, what, maybe two months from design to release, and we're falling all over ourselves to optimize the part that took a day so that it takes 5 minutes instead...

Well said.

Post reply on HN