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

211–220 of 341 posts

Re: Agentic Engineering Patterns

#211

Post by lbreakjai »

jihadjihad wrote: post #158

I wish there was a little more color in the Testing and QA section. While I agree with this: > A comprehensive test suite is by far the most effective way to keep those features working. there is no mention at all about LLMs' tendency to write tautological tests--tests that pass because they are defined to pass. Or, tests that are not at all relevant or useful, and are ultimately noise in the codebase wasting cycles…

That's where mutation testing becomes even more valuable. If the test still passes after the code has been mutated, then you may want to look deeper, because it's a sign that the test is not good.

Re: Agentic Engineering Patterns

#213

Post by hsaliak »

I'd like to plug https://github.com/hsaliak/std_slop/blob/main/docs/mail_mode... my coding harness (std::slop)'s mail model (a poor name i admit). I believe this solves a fundamental problem of accummulating errors along with code in your project.

This brings the Linux Kernel style patch => discuss => merge by maintainer workflow to agents. You get bisect safe patches you 'review' and provide feedback and approve.

While a SKILL could mimic this, being built in allows me to place access control and 'gate' destructive actions so the LLM is forced to follow this workflow. Overall, this works really well for me. I am able to get bisect-safe patches, and then review / re-roll them until I get exactly what I want, then I merge them.

Sure this may be the path to software factories, but it scales 'enough' for medium size projects and I've been able to build in a way that I maintain strong understanding of the code that goes in.

Re: Agentic Engineering Patterns

#216

Post by sarkarsh »

MartyMcBot wrote: post #132
mohsen1 wrote: post #6

I've experimented with agentic coding/engineering a lot recently. My observation is that software that is easily tested are perfect for this sort of agentic loop. In one of my experiments I had the simple goal of "making Linux binaries smaller to download using better compression" [1]. Compression is perfect for this. Easily validated (binary -> compress -> decompress -> binary) so each iteration should make a dent o…

[flagged]

[dead]

Re: Agentic Engineering Patterns

#217

Post by noisy_boy »

bhekanik wrote: post #215

[flagged]

I have come to the same conclusion. I'm thinking it more like "raising" these subagents via iterations and tuning until they are "grown-up" and basically become reliable. Thats why even though I can setup a team pretty easily via claude code, I don't see the benefit until the would be team members are reliable. Once the main subagents are solid, we can move on to build a team by pointing them to these subagents - atleast thats what I'm thinking in my one-step-at-time slow way. Most probably overcautious and maybe even wrong but if I'm seeing a subagent doing weird stuff across many executions, I can't build much in terms of layers on top of it.

Re: Agentic Engineering Patterns

#219

Post by Terr_ »

ElectricalUnion wrote: post #164
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…

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

Re: Agentic Engineering Patterns

#220

Post by solarkraft »

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…

> The damn thing _talks_. You can just _speak_ to it. You can just ask it to do what you want

I mean - yeah. So do humans. But it turns out that that a lot of humans require considerable process to productively organize too. A pet thesis of mine is that we are just (re-) discovering the usefulness of process and protocol.

Post reply on HN