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

221–230 of 341 posts

Re: Agentic Engineering Patterns

#221

Post by shepherdjerred »

simonw wrote: post #146
63stack wrote: post #140

Earlier quoted context omitted.

People are rushing to be the first one to coin something and hit it big. Imagine the amount of $$$ you could get for being an "expert ai consultant" in this space. There was already another attempt at agentic patterns earlier: https://agentic-patterns.com/ Absolute hot air garbage.

Which pieces of my writing are garbage?

I've followed you for a while (maybe 2-3 years?) and love your writing. Your posts are always approachable and easy to digest.

I really don't understand where the HN hate comes from. I hope you aren't giving negative comments too much attention.

Re: Agentic Engineering Patterns

#222

Post by computably »

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…

> I don't think we'll get their by scaling current techniques (Dario disagrees, and he's far more qualified albeit biased).

If Opus 4.6 had 100M context, 100x higher throughput and latency, and 100x cheaper $/token, we'd be much closer. We'd still need to supervise it, but it could do a whole lot more just by virtue of more I/O.

Of course, whether scaling everything by 100x is possible given current techniques is arguable in itself.

Re: Agentic Engineering Patterns

#223

Post by andresquez »

I see a lot of people complaining that every day there are 100 new frameworks for “agent teams”, prompting styles, workflows, and everyone insists theirs is the best for one reason or another. It reminds me a lot of early software engineering: every team had its own way of doing things, we experimented with tons of methodologies (waterfall, agile, etc.), and over time a few patterns became widely adopted (scrum, PM roles, architects, tickets, rituals). It feels like we’re in that same messy exploration phase right now.

And actually, these tools actually work, , because 99% of people still don’t really know how to prompt agents well and end up doing things like “pls fix this, it’s not working”.

One thing that worked well for us was going back to how a human team would approach it: write a product spec first (expected behavior, constraints, acceptance criteria, etc), use AI to refine that spec, and only then hand it to an opinionated flow of agents that reflect a human team to implement.

Re: Agentic Engineering Patterns

#224

Post by Balgair »

simonw wrote: post #199
cma256 wrote: post #192

Earlier quoted context omitted.

> There may be an argument for leaning less on code review. When code is expensive to produce and is likely to stay in production for many years it's obviously important to review it very carefully. If code is cheap and can be inexpensively replaced maybe we can lower our review standards? Agree with everything else you said except this. In my opinion, this assumes code becomes more like a consumable as code-producti…

> Agree with everything else you said except this. Yeah, I'm not sure I agree with what I said there myself! > Incorrect, but not visibly incorrect, code will sit in place for years. If you let incorrect code sit in place for years I think that suggests a gap in your wider process somewhere. I'm still trying to figure out what closing those gaps looks like. The StrongDM pattern is interesting - having an ongoing swar…

This kinda gets into the idea of AIs as droids right?

So, you have a code writing droid that is aligned towards writing good clean code that humans can read. Then you have an implementation droid that goes into actually launching and running the code and is aligned with business needs and expenses. And you have a QA droid that stress tests the code and is aligned with the hacker mindset and is just slightly evil, so to speak.

Each droid is working together to make good code, but also are independent and adversarial in the day to day.

Re: Agentic Engineering Patterns

#225

Post by onionisafruit »

nishantjani10 wrote: post #16

I primarily use AI for understanding codebases myself. My prompt is: "deeply understand this codebase, clearly noting async/sync nature, entry points and external integration. Once understood prepare for follow up questions from me in a rapid fire pattern, your goal is to keep responses concise and always cite code snippets to ensure responses are factual and not hallucinated. With every response ask me if this parti…

I tried a slight variation of your prompt after reading this. It worked marvelously. Quick, correct answers instead of waiting for it to do exploration for each answer.

Re: Agentic Engineering Patterns

#226

Post by devin »

Terr_ wrote: post #219
ElectricalUnion wrote: post #164

Earlier quoted context omitted.

Common business-oriented language (COBOL) is a high-level, English-like, compiled programming language. COBOL's promise was that it was human-like text, so we wouldn't need programmers anymore. 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. The main lesson…

I predict the main democratization change is going to be how easy people can make plumbing that doesn't require--or at least not obviously require--such specificity or mental-modeling of the business domain. For example, "Generate me some repeatable code to ask system X for data about Y, pull out value Z, and submit it to system W."

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".

Re: Agentic Engineering Patterns

#227

Post by DanHulton »

malexw wrote: post #195
simonw wrote: post #174

Earlier quoted context omitted.

This is genuinely one of the most interesting questions right now. I don't have solid answers yet, and I'm very keen to learn what people are finding works. If you accelerate the pace of code creation it inevitably creates bottlenecks elsewhere. Code review is by far the biggest of those right now. There may be an argument for leaning less on code review. When code is expensive to produce and is likely to stay in pro…

I think Martin Fowler's "Refactoring" might give a bit of insight here. One of my take-aways after reading that book is that the specific implementation of a function is not very important if you have tests. He argues that it can sometimes be easier to completely re-write a function than to take the time to understand it - as long as you can validate that your re-write performs the same way. This mindset lines up pre…

This is why I've been pushing back on the "just have the AI generate the tests!" mentality. Sure, let it help you, but those tests are the guarantee of quality and fit for purpose. If you vibe code them, how the hell do you know if it even does what you think it does?

You should be planning out the tests to properly exercise the spec, and ensuring those tests actually do what the spec requires. AI can suggest more tests (but be careful here, too, because a ballooned test suite slows down CICD), but it should never be in charge of them completely.

Re: Agentic Engineering Patterns

#228

Post by lmf4lol »

ep103 wrote: post #200
malexw wrote: post #195

Earlier quoted context omitted.

I think Martin Fowler's "Refactoring" might give a bit of insight here. One of my take-aways after reading that book is that the specific implementation of a function is not very important if you have tests. He argues that it can sometimes be easier to completely re-write a function than to take the time to understand it - as long as you can validate that your re-write performs the same way. This mindset lines up pre…

Counter-point, developers that get used to not caring about function implementation, are going to culturally also not care as much about test implementation, making this proposed ideal impossible.

with LLMs, tests cost nearly nothing of effort but provide tremendous value.

Re: Agentic Engineering Patterns

#229

Post by Terr_ »

devin wrote: post #226
Terr_ wrote: post #219

Earlier quoted context omitted.

I predict the main democratization change is going to be how easy people can make plumbing that doesn't require--or at least not obviously require--such specificity or mental-modeling of the business domain. For example, "Generate me some repeatable code to ask system X for data about Y, pull out value Z, and submit it to system W."

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 told there's no budget to fix it. (True even before LLMs.)

Re: Agentic Engineering Patterns

#230

Post by monooso »

lbreakjai wrote: post #169
monooso wrote: post #142

Earlier quoted context omitted.

I'm confused. Are you criticising the article, or simply expressing concern for what may happen? The context suggests the former, but your criticisms bear no relation to the linked content. If anything, your edict to "write tests first" is even more succinctly expressed as "Red/green TDD".

But it is related, isn't it? I wrote "...each swearing they have the secret sauce and the right incantations...". Now compare it to ""Use red/green TDD" is a pleasingly succinct way to get better results out of a coding agent." Doesn't it sound like the "right incantation"? That's the point of LLMs, they can understand (*) intent. You'd get the same result saying "do tdd" or "do the stuff everyone says they do but th…

I view it as a collection of potentially helpful tips which have worked well for the author, which is exactly how it's presented.

There's no suggestion that this is The Only Blessed Way.

Post reply on HN