Live data from Hacker News

Agentic Engineering Patterns

simonwillison.net

311–320 of 341 posts

Re: Agentic Engineering Patterns

#311
post #280
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".

> when value Z is not >= X? Is your AI not even doing try/catch statements, what century are you in?

Did you just arrogantly suggest that my LLM should use exceptions for control flow? Funny stuff!

Re: Agentic Engineering Patterns

#312
post #27

Any word on patterns for security and deployment to prod?

A few patterns we've found effective deploying agents to production:

1. Proxy-based governance. Route all LLM traffic through a governance layer. The agent never holds API keys directly — the proxy holds them and issues scoped, short-lived capability tokens (ES256, 60s TTL). Single enforcement point for scanning, classification, and audit.

2. Scan all message roles. Most people scan user input. In practice, PII and secrets show up in system messages (from frameworks like LangChain), tool responses, and assistant messages from previous turns. OpenAI's "developer" role is another unscanned vector.

3. Deterministic detection over LLM judges. Using a second model to evaluate the first sounds elegant but creates a recursive trust problem. Regex + text normalization (reversing ~24 obfuscation techniques) is boring but reliable and adds ~250ms, not seconds.

4. Fail-closed by default. If your policy engine goes down, block everything. Don't fail open.

5. Presets, not configuration. Nobody writes custom Rego policies from scratch. Ship starter/standard/regulated presets and let teams tune.These came from 12 rounds of red-teaming our own pipeline — about 300 test cases across encoding bypasses, multilingual injection, Unicode evasion, and tool-result poisoning.

Re: Agentic Engineering Patterns

#313

Earlier quoted context omitted.

[dead]

BTW, check the comment history of the above account @sarkash, this is almost certainly an LLM replying with the exact same structure/format in all their comments. This is the underrated insight in the whole thread From comment history: This is good advice but it highlights the real issue shich's point about simulator mandates is the sharpest thing in this thread esafak's cache economics point is underrated I'm also p…

There is difference between being a Bot account and using LLM to clean up the response. Yes there is AI slop everywhere but how do differentiate from LLM refined answer.. not sure how good we human are with false positive.. (This post has not been refined with LLM :D

Re: Agentic Engineering Patterns

#314
post #99

Earlier quoted context omitted.

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

I think you can use https://traces.com for that

Re: Agentic Engineering Patterns

#315

The "human in the loop at key checkpoints" pattern has been the most practically useful for us. We found that giving the agent full autonomy end-to-end produces subtly broken code that passes tests but violates implicit invariants you never thought to write down. Short loops with a human sanity check at decision forks catches that class of failure early. The thing I keep wrestling with is where exactly to place those…

The checkpoint pattern you describe is exactly right. I've been dealing with this as well. Instead of vibe coding, it's vibe system engineering and I don't care for it. So I thought about it and came up with a framework to describe and reason about different pipelines. I based it on the types of LLM failures I was seeing in my own pipeline (omissions, incorrect, or inconsistent with existing stuff).

I wanted something I could use to objectively decide if one test (or gate, as I call them) is better than another, and how do they work as a holistic system.

My personal tool encodes a workflow that has stages and gates. The gates enforce handoff. Once I did this I went from ~73% first-pass approval to over 90% just by adding structured checks at stage boundaries.

My hope is that we can have a common vocabulary to talk about this, so I wrote up the data and the framework that fell out of it: https://michael.roth.rocks/research/trust-topology/

Re: Agentic Engineering Patterns

#316
post #193
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…

Code review should be mandatory and reviewers should ask big PRs to be broken up, and its submitters to be able to defend every line of code. For when the computer is generating the code, the most important duty of the submitter is to vouch for it. To do otherwise creates the bad incentive of making others do all your QA, and nobody is going to be rewarded for that.

> the most important duty of the submitter is to vouch for it

When shipping pressure comes, I’ve seen this to be the first thing to go. Despite formalizing ownership standards, etc… people on both the submitting and reviewing end just give up understanding Ai slop when management says they need to hit a deadline.

Probably no company would actually do this, but I wonder if we should actually actively test the submitter’s understanding of the code submitted somehow as a prerequisite to moving a PR to ready for review. I’m not sure if it will be actually hopeful, enforcing people to understand the code, but maybe at least we’ll put the cultural expectation upfront and center?

Re: Agentic Engineering Patterns

#317
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…

Code review is now a bit like Brandolini's law: "The amount of energy needed to refute bullshit is an order of magnitude bigger than that needed to produce it." You ultimately need a lot of buy in to spend more than 5 mins on something that took 5 seconds to produce.

Yes I thinks somehow we need a bulldog check gate before it even goes to a human reviewer

Re: Agentic Engineering Patterns

#318
My simple Agent loop for hobby game dev (In antigravity, but this also works well in Claude Code). 1) I write the prompt for the next feature / tweak / fix I want the model to work on 2) if large, check implementation plan 3) play test prior changes 4) repeat. By the time my play test is done, the next batch of changes are ready for commit.

Has anyone setup a smooth agent setup for game art assets generation? (AI models already do great for shaders and VFX, but I would really love to automate model + texture + animation pipeline)

Re: Agentic Engineering Patterns

#320
post #219

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

How do you model the business domain without modeling the business domain?
Post reply on HN