Live data from Hacker News

Agentic Coding Is a Trap

larsfaye.com

391–400 of 403 posts

Re: Agentic Coding Is a Trap

#391

Earlier quoted context omitted.

LLMs are plenty innovative and generate good quality code by default, and great quality code when directed well. If you're not seeing this, at best you're probably unable to direct them or use them well. FWIW, if you don't believe the above, I challenge you to put up a quick git repo, where you are unable to get the deserved quality out, and we can quickly show you how the same quality is available via SOTA agents, w…

I do agree with this. I was able to get exactly what I needed even out of GPT3.5. If you put enough parameters and examples, along with a real solid system prompt and (if you can) proper temperature and topK/topP, there's no reason they can't basically function like "smart typing assistants". The issue is that its a sliding scale of ambiguity to chaos. The more ambiguity, the more the LLM fills that in. And it can be…

Great article! I use LLMs 99.9% in the chat box, to bounce ideas around, ask research and reference questions, and so forth. However, I have sworn off 'agents' entirely for serious code, for reasons your article captures almost totally and perfectly.

I'll still use 'agents' for throwaway tasks--mostly with local models--including tasks where some sort of ad-hoc code generation is in the critical path (e.g. scraping data).

Re: Agentic Coding Is a Trap

#392
"For this invention will produce forgetfulness in the minds of those who learn to use it, because they will not practice their memory. Their trust in writing, produced by external characters which are no part of themselves, will discourage the use of their own memory within them"

- Socrates, decrying the invention of writing

Re: Agentic Coding Is a Trap

#394
hey yall, try writing a few specs at the component/module/package level. define the api contract, types/interfaces, dependencies, package behavior. effectively do the same work you do writing code, but with a layer of "behavior statements" instead of code blocks.

define observable behaviors, let codegen workout most of the rest by implementing the contract.

decompose specs into proper units (a hundred lines or so), not god-awful, unreadable, vibe-coded, frankenstein documents. follow the software engineering best practices you've honed for the last 25 years.

you end up slowing down, sitting in the problem, figuring out "the right problem to solve", all the benefits of writing the code. but now you have a spec to iterate on, and the behavior statements in the spec generate code and tests from a single source of truth (each statement a provable assertion).

as bugs arise, trace back to the spec. changes often end up being a single line of text in the spec which cascades into an easy to review diff plus tests.

spec prose allows writing "why" and "how" together without code comments which go stale.

and lean on your type system to leverage opportunities to be terse, creating a spec which has fewer words, yet still produces strong correctness guarantees (aka, the spec can be shorter than the code, and still be readable).

bonus: versioning a spec is easy, so now you have a change signal when reviewing your peer's code changes. be more careful with major/minor bumps, skim patch bumps.

while many of my peers are taking the giant-ass sdd approach, shipping fast, and losing touch with the actual system behavior, ive been taking the approach outlined above with a modest 2x speedup in feature delivery (their speedup appears much larger), without losing touch with the underlying system.

i am working on large, complex, overgrown, legacy code, so i dont have the luxury of floating in a vibe coding cloud, miles above the scary jungle and tigers and lava and spike traps that i call home.

ive found this approach to be a brilliant balance of speed, incremental AI opt-in, hands-on to avoid context loss, and most importantly to me: maintainability.

i suspect a subset of "proper" ai-codegen software engineer tooling and flows will settle in this vicinity.

encourage folks to swiftly vibe-code prototypes, but then from there, let software engineers do what we do best: engineer software, and transform the protoypes into something maintainable.

Re: Agentic Coding Is a Trap

#395

hey yall, try writing a few specs at the component/module/package level. define the api contract, types/interfaces, dependencies, package behavior. effectively do the same work you do writing code, but with a layer of "behavior statements" instead of code blocks. define observable behaviors, let codegen workout most of the rest by implementing the contract. decompose specs into proper units (a hundred lines or so), n…

apologies, usually I delete these kinda rants, but a combination of whiskey, skittles, and ai brain fry is telling me to leave this one up.

Re: Agentic Coding Is a Trap

#396
post #361

Earlier quoted context omitted.

Validating / Verifying mediocre code is pretty hard as nobody was able to agree what that even means.

If you are working with AI to define the purpose and goal of the change -- which is to say planning how the changes to the code should result in some sort of feature/bugfix/whatever, then planning phase should ask you to define clear success conditions for the code that it writes. These could be otel/datadog metrics, or some kind of funnel metric or some cessation of errors in your APM, whatern. In any case the outco…

Functional requirements can be handled easily that way, yes. Maintainability however is about non-functional requirements like low complexity / decoupling.

To me the trend seems to be that AI produce the same challenges as human did before and that the same solutions are helping. Without a good maintainable code base, AI will eventually fail to even fulfill quantifiable requirements of changes.

That's kind of the point of software since the beginning. Nobody cares about the easy stuff that can be produced without much effort and what's possible without much effort has changed dramatically over the years.

Re: Agentic Coding Is a Trap

#397

Earlier quoted context omitted.

I’ve build a configuration transpiler to Claude code and codex and found I can switch pretty quickly between both and run both at once. At the moment codex performs better. Prior CC did. There is no vendor lockin and this is an old canard in technology that LLMs in fact themselves make irrelevant. Once you’ve got an implementation that uses X converting it to Y is almost trivial with an LLM because the spec is canoni…

Great idea. I would love to see your transpiler Mind sharing it?

FYI, I factored it out and improved it, you can find it here: https://github.com/fnordpig/chameleon

Re: Agentic Coding Is a Trap

#398

I agree with most points in the article but I disagree with the idea of coding as planning. Coding is a really bad way to plan; it maximizes sunk cost fallacy. People tend to code the first approach which came to their heads and they are resistant to revisit an approach once it has been transformed into code. Sometimes ideas which work well in the short term don't work well in the long term. When you start coding as…

This. All day long.

Code was never the scarce resource. Your neighbors' nephew could code a working website that would service the corner shops needs since ten years ago.

The value is and always will be the support and community behind the code.

HN isn't valuable because of a code repo, but because of the community of users and a steady hand cultivating the continued participation thereof. But this too has no real moat, something could change the zeitgeist and tomorrow it joins friendster and TheGlobe.com

Re: Agentic Coding Is a Trap

#400

Earlier quoted context omitted.

On liberal arts is simply a matter of what the students want to get out of the class, vs what the teacher wants the students to do: There's a huge disconnect in goals and expectations, so there's no way for the teacher to actually win. The fact that there's such disconnect should give the departments pause. This doesn't happen at all for using agentic coding: What the programmer wants and what the boss wants are pret…

Honestly I'm not really thinking about the boss-programmer relationship, but rather the programmer-agent relationship. At best, you get what fnordpiglet is talking about, where it's a symbiotic relationship. On the other side of the coin, you get a parasitic relationship like the OP is talking about: the agent delivers results, you take credit, you fail to develop (or maintain) long-term skills, you become a non-valu…

To be fair, many people should be replaced. What is happening right now with layoffs in tech is that the overstaffing these organizations have been accruing across the last decade is staggering
Post reply on HN