Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Agentic Engineering Patterns

simonwillison.net

Post reply on HN
Print view View original

321–330 of 341 posts

Re: Agentic Engineering Patterns

#321

Post by jimbokun »

Terr_ wrote: post #229
devin wrote: post #226

Earlier quoted context omitted.

What happens when value Z is not >= X? What happens when value Z doesn't exist, but values J and K do? What should be done when... I hear what you're saying, but I think it's going to be entertaining watching people go "I guess this is why we paid Bob all of that money all those years".

Hence the "not obviously require" bit: Some portion of those "simply gluing things together" will not actually be simple in truth. It'll work for a time until errors come to a head, then suddenly they'll need a professional to rip out the LLM asbestos and rework it properly. That said, we should not underestimate the ability of companies to limp along with something broken and buggy, especially when they're being tol…

LLM generated code is replacing the hacked together spread sheet running many businesses.

Re: Agentic Engineering Patterns

#322

Post by jimbokun »

pc86 wrote: post #237
devin wrote: post #226

Earlier quoted context omitted.

What happens when value Z is not >= X? What happens when value Z doesn't exist, but values J and K do? What should be done when... I hear what you're saying, but I think it's going to be entertaining watching people go "I guess this is why we paid Bob all of that money all those years".

This seems needlessly nitpicky. Of course there will be edge cases, there always are in everything, so pointing out that edge cases may exist isn't helpful. But it stands to reason that would be a huge shift if a system accessible to non-technical users could mostly handle those edge cases, even when "handle" means failing silently without taking the entire thing down, or simply raising them for human intervention vi…

Edge cases are pretty much the reason you need professional developers, even before LLMs started writing code.

Re: Agentic Engineering Patterns

#323

Post by jimbokun »

nightski wrote: post #209
mexicocitinluez wrote: post #170

Earlier quoted context omitted.

> The problem is that the average person doesn't know how what their actual problems are in sufficient detail to get a working solution. When you get down to breaking down that problem... you become a programmer. Agreed. I've spent the last few years building an EMR at an actual agency and the idea that users know what they want and can articulate it to a degree that won't require ANY technical decisions is pure fant…

Right now with agents this is definitely going to continue to be the case. That said, at the end of the day engineers work with stakeholders to come up with a solution. I see no reason why an agent couldn't perform this role in the future. I say this as someone who is excited but at the same time terrified of this future and what it means to our field. I don't think we'll get their by scaling current techniques (Dari…

There’s nothing any human can do that an AI can’t be expected to perform as well or better in the future.

Maybe the Oldest Profession will be the last to go.

Re: Agentic Engineering Patterns

#324

Post by jimbokun »

jerf wrote: post #264
lbreakjai wrote: post #109

We're going to do it again, aren't we? We're going to take something simple and sensible ("write tests first", "small composable modules", etc.), give it a fancy complicated name ("Behavior-Constrained Implementation Lifecycle pattern", "Boundary-Scoped Processing Constructs pattern", etc.), and create an entire industry of consultants and experts selling books and enterprise coaching around it, each swearing they ha…

Worse yet, the problems are going to be real. There's a lifecycle to these hype runs, even when the thing behind the hype is plenty real. We're still in the phase where if you criticize AI you get told you don't "get it", so people are holding back some of their criticisms because they won't be received well. In this case, I'm not talking about the criticisms of the people standing back and taking shots at the tech,…

Early in my career I would sometimes be told to not worry about making the code “nice” just get it working and move on. I would nod and just write good code like I always did, knowing it didn’t take longer than writing bad code, and would be much easier to modify and extend and fix later.

I feel like there’s a similar vibe coming with vibe coding. Just let the AI generate as much code as it wants, don’t check it because it doesn’t matter because only the LLM will be reading it anyway.

My gut tells me that

1. there will still be reasons for humans to understand the code for a long time,

2. even the LLM will struggle with modifying code last a certain size and complexity without good encapsulation and well thought out system architecture and design.

Re: Agentic Engineering Patterns

#325

Post by jerf »

jimbokun wrote: post #324
jerf wrote: post #264

Earlier quoted context omitted.

Worse yet, the problems are going to be real. There's a lifecycle to these hype runs, even when the thing behind the hype is plenty real. We're still in the phase where if you criticize AI you get told you don't "get it", so people are holding back some of their criticisms because they won't be received well. In this case, I'm not talking about the criticisms of the people standing back and taking shots at the tech,…

Early in my career I would sometimes be told to not worry about making the code “nice” just get it working and move on. I would nod and just write good code like I always did, knowing it didn’t take longer than writing bad code, and would be much easier to modify and extend and fix later. I feel like there’s a similar vibe coming with vibe coding. Just let the AI generate as much code as it wants, don’t check it beca…

I classify your latter points under "AIs are Finite": https://jerf.org/iri/post/2026/what_value_code_in_ai_era/

Re: Agentic Engineering Patterns

#326

Post by AlexCalderAI »

Solid patterns here. One thing I'd add from running Claude Code in production:

The "give it bash" pattern sounds scary until you realize the alternative is 47 intermediate tool calls that fail silently.

Letting the agent write and run scripts means the agent debugs when something breaks. The feedback loop tightens dramatically.

The trick is sandboxing + cost limits. Not preventing shell access.

Re: Agentic Engineering Patterns

#327

Post by lunias »

In most cases, the model is non-deterministic and you have no direct control over the input parameters. At best you might get access to some abstraction of a subset of those parameters. I don't know of a coding model that offers direct access to the seed. I like to hear about how people are using agents, but it also feels a lot like someone sitting at a slot machine telling you that if you put your shoes on the opposite feet then you win more often.

Re: Agentic Engineering Patterns

#328

Post by mightybyte »

slaye wrote: post #168

Simon, if you're reading this, I'd be really curious to hear your thoughts on how to effectively conduct code reviews in a world where "code is cheap". One of the biggest struggles I have on my team is coworkers straight up vibing parts of the code and not understanding or guiding the architecture of subsystems. Or at least, not writing code in a way that is meant to be understood by others. Then when I go through th…

One plausible future I can see from here is that we see a shift in our relationship to code in high-level languages that is similar to what happened with code written in assembly language back when the first high level languages were introduced. Before them, software engineers operated in assembly language. They cared about the structure of assembly code. This happened before I started my professional software career, but I can imagine that a lot of the same things we are hearing from developers today were heard back then. Concern about devs producing code they didn't understand, the generated assembly not being meant to be understood by others, etc etc.

Now, however, we know how that played out in the case of assembly language. The fact of the matter is that only a very tiny fraction of software engineers give the structure of the compiled assembly code even passing thought. Our ability to generate assembly code is so great that we don't care about the end result. We only care about its properties...i.e. that it runs efficiently enough and does what we want. I could easily see the AI software development revolution ending up the same way. Does it really matter if the code generated by AI agents is DRY and has good design if we can easily recreate it from scratch in a matter of minutes/hours? As much as I love the craft and process of creating a beautiful codebase, I think we have to seriously consider and plan for a future where that approach is dramatically less efficient than other AI-enabled approaches.

Re: Agentic Engineering Patterns

#329

Post by vidarh »

irthomasthomas wrote: post #112
vidarh wrote: post #89

Earlier quoted context omitted.

You need a harness, yes, and you need quality gates the agent can't mess with, and that just kicks the work back with a stern message to fix the problems. Otherwise you're wasting your time reviewing incomplete work.

Here is an example where the prompt was only a few hundred tokens and the output reasoning chain was correct, but the actual function call was wrong https://x.com/xundecidability/status/2005647216741105962?s=2...

Your point being? A proper harness will mostly catch things like that. Even a low end model can be employed to do write tests plans and do consistency checks that mostly weed out stuff like that. Hence: You need a harness, or you'll spend your time worrying about dumb stuff like this.

Re: Agentic Engineering Patterns

#330

Post by vidarh »

port11 wrote: post #185
vidarh wrote: post #75

Earlier quoted context omitted.

Yes, it's often faster if you sit around waiting . What I will do instead is prompt the AI to create various plans, do other stuff while they do, review and approve the plans, do other stuff while multiple plans are being implemented , and then review and revise the output. And I have the AI deal with "knowing how to do it" as well. Often it's slower to have it do enough research to know how to do it, but my time is…

This sounds like one recipe for burnout, much like Aderal was making everyone code faster until their brain couldn’t keep up with its own backlog.

If anything, it's the opposite. With a proper harness you stop having to spend so much energy reviewing every little intermediate step, and can focus on the higher level.

I'm actually working on a project now where the biggest problem I need to solve is that the verifier that reviews the test harness is too strict.

Post reply on HN