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

301–310 of 341 posts

Re: Agentic Engineering Patterns

#301

Post by scuff3d »

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…

In a business (or any large project setting) where there are real users and real risk involved, code can't move into a code base any faster then it can be reviewed by a human. Period. I apply the exact same standards to PRs for AI assisted code as I do for human written code. If the code is crap, the PR is too larger, or the dev can't explain it. it gets rejected. End of story. We are a long way away from the need for human review going away.

Re: Agentic Engineering Patterns

#302

Post by scuff3d »

JetSetIlly wrote: post #91
pkorzeniewski wrote: post #52

Earlier quoted context omitted.

One thing I rarely see mentioned is that often creating code by hand is simply faster (at least for me) than using AI. Creating a plan for AI, waiting for execution, verifying, prompting again etc. can take more time than just doing it on my own with a plan in my head (and maybe some notes). Creating something from scratch or doing advanced refactoring is almost always faster with AI, but most of my daily tasks are b…

I've heard people say that these coding agents are just tools and don't replace the thinking. That's fine but the problem for me is that the act of coding is when I do my thinking! I'm thinking about how to solve the problem and how to express it in the programming language such that it is easy to maintain. Getting someone/something else to do that doesn't help me. But different strokes for different folks, I suppose…

I'm similar, but I do find some natural places where LLMs can be helpful.

Just today I was working on something that involves a decent amount of configuration. It's in Python unfortunately and I hate passing around dictionaries for configs, I usually like to parse the JSON or YAML or whatever into a config class so I have a natural way to validate and access without just throwing strings around.

As I was playing with the code for the actual work that needs to be done, I was thinking what configs I needed and what structure made sense. Once I knew what I needed I gave the JSON to an LLM with some instructions regarding helper functions and told it to give me the appropriate Python code. It's just a bunch of dataclasses with some from_dict or from_string methods on them, not interesting or difficult to write. Freed me up to keep working on the real problem.

Re: Agentic Engineering Patterns

#303

Post by p_v_doom »

flir wrote: post #117
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…

Has anyone staked a claim to "Agile AI" yet?

you mean agile dot ai?

Re: Agentic Engineering Patterns

#305

Post by fragmede »

maccard wrote: post #99
fragmede wrote: post #87

Earlier quoted context omitted.

At this point though, after Claude C Compiler, you've got to give us more details to better understand the dichotomy. What do you consider simple issues?

> At this point though, after Claude C Compiler, Perfect example. You mean the C compiler that literally failed to compile a hello world [0] (which was given in it's readme)? > What do you consider simple issues? Hallucinating APIs for well documented libraries/interfaces, ignoring explicit instructions for how to do things, and making very simple logic errors in 30-100 line scripts. As an example, I asked Claude cod…

Excellent examples, thank you!

Shame Claude Code doesn't have sharable chat logs, it would be interesting to see where your Roblox exploration went off the rails.

Re: Agentic Engineering Patterns

#306

Post by theshrike79 »

DanHulton wrote: post #227
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…

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 te…

AI generated tests can "lock down" features pretty well, do the basic bounds checking etc. and make sure no unrelated change breaks the feature.

But the more complex bits require human instruction and/or intervention.

Re: Agentic Engineering Patterns

#307

Post by theshrike79 »

malexw wrote: post #288
MattGrommes wrote: post #287

Earlier quoted context omitted.

A related book I've been thinking about in terms of LLMs is "Working Effectively With Legacy Code". I'd love to be able to work a lot of that advice into some kind of Skill or customized agent to help with big refactors.

Oh gosh - now that you mention it, it was "Working Effectively with Legacy Code" that I was thinking of, not "Refactoring".

IIRC that was the book that coined the term "Refactoring" though =)

Re: Agentic Engineering Patterns

#308

Post by theshrike79 »

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…

> The StrongDM pattern is interesting - having an ongoing swarm of testing agents which hammer away at a staging cluster trying different things and noting stuff that breaks. Effectively an agent-driven QA team.

That sounds a lot like Chaos Engineering: https://en.wikipedia.org/wiki/Chaos_engineering

Re: Agentic Engineering Patterns

#309

Post by theshrike79 »

skapadia wrote: post #104
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…

"Test harness is everything, if you don't have a way of validating the work, the loop will go stray" This is the most important piece to using AI coding agents. They are truly magical machines that can make easy work of a large number of development, general purpose computing, and data collection tasks, but without deterministic and executable checks and tests, you can't guarantee anything from one iteration of the l…

Agents run tools in a loop.

The ability to test their work reliably is a tool, if you don't give them that, it's kinda silly to expect any kind of quality output.

Re: Agentic Engineering Patterns

#310

Post by AlexCalderAI »

Great patterns here. I'd add one more critical layer that many miss: orchestration state management.

Running multiple agents concurrently (QA, content, conversions, distribution), we hit this exact wall - agents didn't know what other agents had done, creating duplicate work and missed context.

Solved it with a stupidly simple approach: 1. Single TODO.md with "DO NOW" (unblocked), "BLOCKED", "DONE" sections 2. Named output files per agent type (qa-status.md, scout-finds.md, etc) 3. active-tasks.md for crash recovery - breadcrumbs from interrupted runs 4. Daily memory logs with session IDs for searchability

The key: File-based state is deterministic. After a crash, the next agent reads identical input, same decision rules, same output structure. Zero state collision, zero "what was I thinking?"

Deployment: ~8 agents on cron. They wake, read files, work, write results, die. No persistent terminal. No coordination overhead.

This turned "5 terminal tabs with unmanageable logs" into "grep yesterday's log, see exactly what happened."

Patterns + implementation details: https://osolobo.com/first-ai-agent-guide/

Post reply on HN