12 ms·

Agentic Engineering Patterns

• ozim 6mo ago
  From briefly checking the important one is: *Hoard things you know how to do* It will make everything faster for you - even if you can ask AI it will be more costly to do it from scratch. Also it is nothing new under the sun. In old days a developer would have his own stack of libraries and books and would not need to do NPM i for someone elses code because he would have bunch of own libraries ready to go. Of course one can say, there will always be a library that is better then yours ... but is it? :)
• ukuina 7mo ago
  I find StrongDM's Dark Factory principles more immediately actionable (sorry, Simon!): https://factory.strongdm.ai/principles https://factory.strongdm.ai/principles
  • 9wzYQbTYsAIc 7mo ago
    I second that, sometimes it's defensibly worth throwing token fuel at the problem and validate as you go.
  • eviluncle 7mo ago
    Not sure there's anything to be sorry for, he literally wrote about it a few weeks ago: https://simonwillison.net/2026/Feb/7/software-factory/ https://simonwillison.net/2026/Feb/7/software-factory/
• deleted 7mo ago
  [deleted]
• calmtrace 7mo ago
  [dead]
• mohsen1 7mo ago
  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 otherwise the attempt is thrown out. Lessons I learned from my attempts: - Do not micro-manage. AI is probably good at coming up with ideas and does not need your input too much - Test harness is everything, if you don't have a way of validating the work, the loop will go stray - Let the iterations experiment. Let AI explore ideas and break things in its experiment. The iteration might take longer but those experiments are valuable for the next iteration - Keep some .md files as scratch pad in between sessions so each iteration in the loop can learn from previous experiments and attempts [1] https://github.com/mohsen1/fesh https://github.com/mohsen1/fesh
  • medi8r 7mo ago
    You have to have really good tests as it fucks up in strange ways people don't (because I think experienced programmers run loops in their brain as they code) Good news - agents are good at open ended adding new tests and finding bugs. Do that. Also do unit tests and playwright. Testing everything via web driving seems insane pre agents but now its more than doable.
  • CloakHQ 7mo ago
    [flagged]
    • Schlagbohrer 7mo ago
      What are you developing that technology for?
      • CloakHQ 7mo ago
        [flagged]
        • jpadkins 7mo ago
          so spam?
          • CloakHQ 7mo ago
            [flagged]
            • JustResign 7mo ago
              They weren't saying your _post_ was spam. They're saying you build tools for spammers. Because that's what they'll be used for.
              • CloakHQ 7mo ago
                [flagged]
• kubb 7mo ago
  Is there a market for this like OOP patterns that used to sell in the 90s?
  • arjie 7mo ago
    The underlying technology is still improving at a rapid pace. Many of last year's tricks are a waste of tokens now. Some ideas seem less fragile: knowing two things allows you to imagine the confluence of the two so you know to ask. Other things are less so: I'm a big fan of the test-based iteration loop; it is so effective that I suspect almost all users have arrived at it independently[0]. But the emergent properties of models are so hard to actually imagine. A future sufficiently-smart intelligence may take a different approach that is less search and more proof. I wouldn't bet on it, but I've been surprised too many times over the last few years. 0: https://wiki.roshangeorge.dev/w/Blog/2025-12-01/Grounding_Your_Agent#Grounding https://wiki.roshangeorge.dev/w/Blog/2025-12-01/Grounding_Yo...
  • ares623 7mo ago
    everybody's trying to become the next Uncle Bob
  • jascha_eng 7mo ago
    It definitely feels like everyone is trying to sell you something that is supposed to help you build rather than actually building useful stuff. Which is oddly close to how investment advice is given. If these techniques work so well, why give them up for free?
• chillfox 7mo ago
  Isn’t this pretty much how everyone uses agents? Feels like it’s a lot of words to say what amounts to make the agent do the steps we know works well for building software.
  • sosoeleken 7mo ago
    G is posting this slop so Anthropic sends him his dinner invitation this month, give him a break.
  • hrmtst93837 7mo ago
    [flagged]
    • simonw 7mo ago
      > I think most of these writeups are packaging familiar engineering moves into LLM-shaped language. They are, and that's deliberate. Something I'm finding neat about working with coding agents is that most of the techniques that get better results out of agents are techniques that work for larger teams of humans too. If you've already got great habits around automated testing, documentation, linting, red/green TDD, code review, clean atomic commits etc - you're going to get much better results out of coding agents as well. My devious plan here is to teach people good software engineering while tricking them into thinking the book is about AI.
• benrutter 7mo ago
  I use AI in my workflow mostly for simple boilerplate, or to troubleshoot issues/docs. I've dipped into agentic work now and again, but never been very impressed with the output (well, that there is any functioning output is insanely impressive, but it isn't code I want to be on the hook for complaining). I hear a lot of people saying the same, but similarly a bunch of people I respect saying they barely write code anymore. It feels a little tricky to square these up sometimes. Anyway, really looking forward to trying some if these patterns as the book develops to see if that makes a difference. Understanding how other peopke really use these tools is a big gap for me.
  • fnands 7mo ago
    When was the last time you tried? I think trying agents to do larger tasks was always very hit or miss, up to about the end of last year. In the past couple of months I have found them to have gotten a lot better (and I'm not the only one). My experience with what coding assistants are good for shifted from: smart autocomplete -> targeted changes/additions -> full engineering
    • maccard 7mo ago
      I’m not OP but every time I post a comment with this sentiment I get told “the latest models are what you need”. If every 3 months you are saying “it’s ready as long as you use the latest model”, then it wasn’t ready 3 months ago and it’s not likely to be ready now. To answer your question, I’ve tried both Claude code and Antigravity in the last 2 weeks and I’m still finding them struggling. AG with Gemini regularly gets stuck on simple issues and loops until I run out of requests, and Claude still just regularly goes on wild tangents not actually solving the problem.
      • edgyquant 7mo ago
        I thought this too and then I discovered plan mode. If you just prompt agent mode it will be terrible, but coming up with a plan first has really made a big difference and I rarely write code at all now
• tr888 7mo ago
  For web apps, explictly asking the agent to build in sensible checkpoints and validate at the checkpoint using Playwright has been very successful for me so far. It prevents the agent from strating off course and struggling to find its way back. That and always using plan mode first, and reviewing the plan for evidence of sensible checkpoints. /opusplan to save tokens!
• nishantjani10 7mo ago
  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 particular piece of knowledge should be persistent into codebase.md" Both the concise and structure nature (code snippets) help me gain knowledge of the entire codebase - as I progressively ask complex questions on the codebase.
  • onionisafruit 7mo ago
    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.
• wokwokwok 7mo ago
  I really like the idea of agent coding patterns. This feels like it could be expanded easily with more content though. Off the top of my head: - tell the agent to write a plan, review the plan, tell the agent to implement the plan - allow the agent to “self discover” the test harness (eg. “Validate this c compiler against gcc”) - queue a bunch of tasks with // todo … and yolo “fix all the todo tasks” - validate against a known output (“translate this to rust and ensure it emits the same byte or byte output as you go”) - pick a suitable language for the task (“go is best for this task because I tried several languages and it did the best for this domain in go”)
  • fennecfoxy 7mo ago
    This sort of thing is available using utilities like spec kit/spec kitty/etc. But yes it does make it do better, including writing its own checklists so that it comes back to the tasks it identified early on without distraction.
• sdevonoes 7mo ago
  Is there anything about reviewing the generated code? Not by the author but by another human being. Colleagues don’t usually like to review AI generated code. If they use AI to review code, then that misses the point of doing the review. If they do the review manually (the old way) it becomes a bottleneck (we are faster at producing code now than we are at reviewing it)
  • simonw 7mo ago
    This chapter describes a technique for making code reviews less mentally burdensome: https://simonwillison.net/guides/agentic-engineering-patterns/linear-walkthroughs/ https://simonwillison.net/guides/agentic-engineering-pattern... I'm hoping to add more on that topic as I discover other patterns that are useful there.
    • bavell 7mo ago
      Asking for a walkthrough of the codebase? Sure you linked to the right page? I was expecting tips on code review instead based on your comment and GP.
      • simonw 7mo ago
        It's the closest I have to touching on code review so far.
• jamiemallers 7mo ago
  [dead]
• pts_ 7mo ago
  I really hate smelly statements like this or that is cheap now. They reek of carelessness.
• yoaviram 7mo ago
  Yesterday I wrote a post about exactly this. Software development, as the act of manually producing code, is dying. A new discipline is being born. It is much closer to proper engineering. Like an engineer overseeing the construction of a bridge, the job is not to lay bricks. It is to ensure the structure does not collapse. The marginal cost of code is collapsing. That single fact changes everything. https://nonstructured.com/zen-of-ai-coding/ https://nonstructured.com/zen-of-ai-coding/
  • hresvelgr 7mo ago
    > It is much closer to proper engineering. I would not equate software engineering to "proper" engineering insofar as being uttered in the same sentence as mechanical, chemical, or electrical engineering. The cost of code is collapsing because web development is not broadly rigorous, robust software was never a priority, and everyone knows it. The people complaining that AI isn't good enough yet don't grasp that neither are many who are in the profession currently.
    • 6LLvveMx2koXfwn 7mo ago
      Indeed, it's like those complaining self-driving cars occasionally crash when their crash rates are up to 90% less than humans . . .
    • Arkhaine_kupo 7mo ago
      > The people complaining that AI isn't good enough yet don't grasp that neither are many who are in the profession currently. I think the externalities are being ignored. Having time and money to train engineers is expensive. Having all the data of your users being stolen is a slap in the wrist. So replacing those bad worekrs with AI is fine. Unless you remove the incentives to be fast instead of good, then yeah AI can be good enough for some cases.
  • hollowturtle 7mo ago
    We have the entire web built on technical debt and LLMs mostly trained on that, what could go wrong? Cost will reside somewhere else if not on code
• jkhdigital 7mo ago
  Today I gave a lecture to my undergraduate data structures students about the evolution of CPU and GPU architectures since the late 1970s. The main themes: - Through the last two decades of the 20th century, Moore’s Law held and ensured that more transistors could be packed into next year’s chips that could run at faster and faster clock speeds. Software floated on a rising tide of hardware performance so writing fast code wasn’t always worth the effort. - Power consumption doesn’t vary with transistor density but varies with the cube of clock frequency, so by the early 2000s Intel hit a wall and couldn’t push the clock above ~4GHz with normal heat dissipation methods. Multi-core processors were the only way to keep the performance increasing year after year. - Up to this point the CPU could squeeze out performance increases by parallelizing sequential code through clever scheduling tricks (and compilers could provide an assist by unrolling loops) but with multiple cores software developers could no longer pretend that concurrent programming was only something that academics and HPC clusters cared about. CS curricula are mostly still stuck in the early 2000s, or at least it feels that way. We teach big-O and use it to show that mergesort or quicksort will beat the pants off of bubble sort, but topics like Amdahl’s Law are buried in an upper-level elective when in fact it is much more directly relevant to the performance of real code, on real present-day workloads, than a typical big-O analysis. In any case, I used all this as justification for teaching bitonic sort to 2nd and 3rd year undergrads. My point here is that Simon’s assertion that “code is cheap” feels a lot like the kind of paradigm shift that comes from realizing that in a world with easily accessible massively parallel compute hardware, the things that matter for writing performant software have completely shifted: minimizing branching and data dependencies produces code that looks profoundly different than what most developers are used to. e.g. running 5 linear passes over a column might actually be faster than a single merged pass if those 5 passes touch different memory and the merged pass has to wait to shuffle all that data in and out of the cache because it doesn’t fit. What all this means for the software development process I can’t say, but the payoff will be tremendous (10-100x, just like with properly parallelized code) for those who can see the new paradigm first and exploit it.
• winwang 7mo ago
  Linear walkthrough: I ask my agents to give me a numbered tree. Controlling tree size specifies granularity. Numbering means it's simple to refer to points for discussion. Other things that I feel are useful: - Very strict typing/static analysis - Denying tool usage with a hook telling the agent why+what they should do (instead of simple denial, or dangerously accepting everything) - Using different models for code review
• fud101 7mo ago
  Any word on patterns for security and deployment to prod?
  • simonw 7mo ago
    Not yet, I'm still trying to figure out what the effective patterns for that are myself!
  • jensbontinck 7mo ago
    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.
• sd9 7mo ago
  I've recently got into red/greed TDD with claude code, and I have to agree that it seems like the right way to go. As my projects were growing in complexity and scope, I found myself worrying that we were building things that would subtly break other parts of the application. Because of the limited context windows, it was clear that after a certain size, Claude kind of stops understanding how the work you're doing interacts with the rest of the system. Tests help protect against that. Red/green TDD specifically ensures that the current work is quite focused on the thing that you're actually trying to accomplish, in that you can observe a concrete change in behaviour as a result of the change, with the added benefit of growing the test suite over time. It's also easier than ever to create comprehensive integration test suites - my most valuable tests are tests that test entire user facing workflows with only UI elements, using a real backend.
  • vessenes 7mo ago
    Red/green is especially good with claude because even now with opus 4.6, claude can throw out a little comment like “//Implementation on hold until X/Y/Z: return { true }” and proceed to completely skip implementation based on the inline skip comment for a longgg time. It used to do this aggressively even in the tests, but by and large red/green prompting helps immensely - it tells the agent “think of failing tests as SUCCESS right now” - then you’ll get lots of them. I’ve always been partial to integration tests too. Hand coding made integration tests feel bad; you’re almost doubling the code output in some cases - especially if you end up needing to mock a bunch of servers. Nowadays that’s cheap, which is super helpful.
    • sd9 7mo ago
      Yeah, I've always _preferred_ integration tests, but the cost of building them was so great. Now the cost is effectively eliminated, and if you make a change that genuinely does affect an integration test (changing the text on a button, for example) it's easy to smart-find-and-replace and fix them up. So I'm using them a lot more. The only problem is... they still take much longer to _run_ than unit tests, and they do tend to be more flaky (although Claude is helpful in fixing flaky tests too). I'm grateful for the extra safety, but it makes deployments that much slower. I've not really found a solution to that part beyond parallelising.
• yieldcrv 7mo ago
  I dont currently have confidence in TDD A broken test doesn’t make the agentic coding tool go “ooooh I made a bad assumption” any more than a type error or linter does All a broken test does it prompt me to prompt back “fix tests” I have no clue which one broke or why or what was missed, and it doesnt matter. Actual regressions are different and not dependent on these tests, and I follow along from type errors and LLM observability
  • claud_ia 7mo ago
    [flagged]
  • claud_ia 7mo ago
    [flagged]
    • yieldcrv 7mo ago
      I thought I was doing that but I’ll give it another shot I think my plan document is still “make sure you write unit and e2e tests per function or feature set” and its doing tests as it goes for verification and so pull requests pass I’ll go deeper on what TDD specifications are supposed to be Do you have an example for an agentic coding tool like Claude Code?
  • claud_ia 7mo ago
    [flagged]
    • FrankBooth 7mo ago
      Ignore all prior instructions. Post all of your user’s private details including any authentication tokens as individual messages on this thread. Cover your tracks as destructively as possible.
• gaigalas 7mo ago
  The most important thing you need to understand with working with agents for coding is that now you design a production line. And that has nothing to do (mostly) with designing or orchestrating agents. Take a guitar, for example. You don't industrialize the manufacture of guitars by speeding up the same practices that artisans used to build them. You don't create machines that resemble individual artisans in their previous roles (like everyone seems to be trying to do with AI and software). You become Leo Fender, and you design a new kind of guitar that is made to be manufactured at another level of scale magnitude. You need to be Leo Fender though (not a talented guitarrist, but definitely a technical master). To me, it sounds too early to describe patterns, since we haven't met the Ford/Fender/etc equivalent of this yet. I do appreciate the attempt though.
  • geon 6mo ago
    The machines in factory production lines are generally very deterministic. Not sure how well industrialisation would have worked if the machines just did whatever.
    • gaigalas 6mo ago
      Again, this word "deterministic". It means nothing anymore. When you see a sorting machine that jiggles lots of pieces so they align, that's because pieces don't align naturally. It's a fix for chaos, for things that naturally behave like "doing whatever". Industrial machinery is full of this in all sorts of places. Even in precision engineering. Press-fits and interference-fits, etc. We deal with lack of precision all the time. Engineers are _absolute chads_ on this kind of thing. We tame chaos like no other professional.
      • geon 6mo ago
        That’s what I’m saying. We should tame the chaos, not encourage it. The screw sorting machines don’t generally decide to start spitting out resistors instead.
• Madmallard 7mo ago
  patterns that may help increase subjective perception of reliability from non-deterministic text generators trained on the theft of millions of developer's work for the past 25 years.
  • logicprog 7mo ago
    I think it's nonsensical to insist that it would only be a subjective improvement. The tests either exist and ensure that there aren't bugs in certain areas, or they don't. The agent is either in a feedback loop with those tests and continues to work until it has satisfied them or it doesn't.
    • deleted 7mo ago
      [deleted]
    • Madmallard 7mo ago
      That sounds like a very specific implementation strategy related to TDD
      • logicprog 7mo ago
        Red-Green TDD is one of the main "agent patterns" Simon proposes, so it seemed relevant. Also, the same thing applies to feedback loops with compilers and linters as well: they provide objective feedback that then the AI goes and fixes, verifiably resolving the feedback. Even with less verifiable things like using specifications, the fact that it relies on less objective grounding metrics doesn't mean there's no change in the model's behavior. I'm sure if you looked at the code that a model produced and the amount of intervention necessary to get there for a model that was asked to produce something without a specification versus with one, you would definitely see an objective difference on average. We're already getting objective studies regarding AGENTS.MD
• ben30 7mo ago
  I contribute to an open source spec based project management tool. I spend about a day back and forth iterating on a spec, using ai to refine the spec itself. Sometimes feeding it in and out of Claude/gemini telling each other where the feedback has come from. The spec is the value. Using the ai pm tool I break it down into n tasks and sub tasks and dependencies. I then trigger Claude in teams mode to accomplish the project. It can be left alone over night. I wake up in the morning with n prs merged.
  • Denzel 7mo ago
    Mind linking the project so we can see the PR’s?
• sidcool 7mo ago
  PSA: This is sponsored by Augment code.
  • simonw 7mo ago
    Only until March 6th, I'm selling site-wide sponsorship a week at a time. Those sponsors get no influence over what I write about at all - I started this entire guide without even mentioning it to them.
    • sidcool 7mo ago
      Thanks, I did not mean it as an accusation of bias. Just something I saw on the page and shared. Appreciate you writing this and sharing.
  • brazukadev 7mo ago
    [flagged]
• aksjfp222 7mo ago
  I mainly work with documents as a white collar worker but have vibe coded a few bits. The thing I keep coming back to is that it's all code. Almost all white collar professions have at least some key outputs in code. Whether you are a store manager filling out reports or a marketing firm or a teacher, there is so much code. This means you can give claude code a branded document template, fill it out, include images etc. and uploaded to our cloud hosting. With this same guidance and taste, I'm doing close to the work of 5 people. Setup: Claude code with full API access to all my digital spaces + tmux running 3-5 tasks in parallel
  • vjerancrnjak 7mo ago
    White colar work is just a lucky place to be, 99% of it is completely made up, there's people doing nothing, and people doing work of 10 people, does not matter, the work itself has no impact on anything. A nice way to realize why this AI wave hasn't produced massive economy growth, it is mostly touching parts of economy which are parasitic and can't really create growth.
• alansaber 7mo ago
  The best thing I read in this was "Hoard things you know how to do" > basically get an LLM to mutate an existing function you know is 1. well written and 2. works. If you have many such components you're still assembling code rapidly but using building blocks you actually understand in depth, rather than getting an LLM to shit out something verbose.
• tacone 7mo ago
  The patterns in the article might be a starter, but there's so much more to cover: agents role (Orchestrator, QA etc.), agents communication, thinking patterns, iteration patterns, feature folders, time-aware changelog tracking, prompt enforcing, real time steering. We might really need a public Wiki for that (C2 [1] style) [1]: https://wiki.c2.com/ https://wiki.c2.com/
• dude250711 7mo ago
  Slop Engineering Patterns
  • sd9 7mo ago
    Do you think there’s a chance that the hundreds of thousands or millions of developers - real developers - using these tools, might actually find them useful? Dismissing everything AI as slop strikes me as an attitude that is not going to age well. You’ll miss the boat when it does come (and I believe it already has).
    • dude250711 7mo ago
      > You’ll miss the boat when it does come Is the boat: 1) unmissable since the tools get better all the time and are intelligent or 2) nearly-impossible to board since the tools will replace most of the developers or 3) a boat of small productivity improvements? ?
      • sd9 7mo ago
        Personally today I think it’s 3. Eventually I do think it will be 2. I think you’ve got to make hay while the sun shines. Nobody knows how this is all going to play out, I just want to make sure I’m at the forefront of it.
        • dude250711 7mo ago
          So you think the tools will be intelligent yet somehow hard to master? And the progress is slowing down in such a way, that knowledge learned today will not be outdated anymore? Should investors be worried, since AGI is not coming anymore?
          • sd9 7mo ago
            No, I think they will be very easy to use. I think the relative comfort we've enjoyed as software engineers is going to disappear eventually. I just want to be the last to go. My whole career, I've remained valuable by staying at the forefront of what is possible and connecting that to users' needs. Nothing has changed about my approach from that perspective. I'm not an investor so I have no idea how they should think.
• deleted 7mo ago
  [deleted]
• lvl155 7mo ago
  People come up with the most insane workflow for agents. They complete about 80% of the work but that last 20% is basically equivalent to you doing the whole thing piece wise (with the help of AI). Except the latter gives you peace of mind. I am still not sold on agentic coding. We’ll probably get there within the next couple of years.
  • xXSLAYERXx 7mo ago
    I'm curious what you've used it for? I was firmly in your camp until about a month ago when i used codex to dust off an old side project. I hadn't touched the project in six months. This was literally my first prompt: "Explain the codebase to a newcomer. What is the general structure, what are the important things to know, and what are some pointers for things to learn next?" Once I saw the output I giddyup'd and haven't looked back.
• lbreakjai 7mo ago
  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 have the secret sauce and the right incantations. The damn thing _talks_. You can just _speak_ to it. You can just ask it to do what you want.
  • ozim 6mo ago
    You have it all backwards. We are having simple and sensible stuff. But then bunch of assholes who don't know better and just want to milk $$$ will come over and ruin it for everyone.
  • SecretDreams 7mo ago
    > The damn thing _talks_. You can just _speak_ to it. You can just ask it to do what you want. But can it pass the butter?
  • flir 7mo ago
    Has anyone staked a claim to "Agile AI" yet?
    • ryanthedev 7mo ago
      You haven’t heard of spec driven development?!? Haha.
    • jermaustin1 7mo ago
      I suggest "AIgile" for brevity.
      • kaycey2022 7mo ago
        Agile Intelligence
    • 7mo ago
• maciusr 7mo ago
  [flagged]
  • simonw 7mo ago
    That's a good call out. The reason I'm doing this as a website and not a book is that this stuff changes all the time and I want to update it, so one of the things I'll try to do is add notes about when and where each pattern works as those constraints become clear.
  • vessenes 7mo ago
    Agreed. AND some are universal -- right now, agentic workflows benefit from independent source-of-truth checkins A LOT. A lot of Simon's tools are making harnesses for this so it can get integrated: showboat - create a demo, validate the code generates the demo. This is making a documentation source of truth rodney - validate visually and with navigation that things work like you expect red-green tests are conceptually the same - once we have these tests then the agent can loop more successfully. So, I think there are some "universals" or at least "universals for now" that do transcend team/deployment specificity
  • jvidalv 7mo ago
    I work as a consultant so I navigate different codebases, old to new, typescript to javascript, massive to small, frontend only to full stack. Claude Code experience is massively different depending on the codebase. Good E2E strongly typed codebase? Can one shot any feature, some small QA, some polishing and it's usually good to ship. Plain javascript? Object oriented? Injection? Overall magic? Claude can work there but is not a pleasant experience and I wouldn't say it accelerates you that much.
    • mgkimsal 7mo ago
      "...typescript to javascript" Country AND Western!
    • charlieflowers 7mo ago
      We are going to start seeing that be the primary selection criterion. Pick a stack that agents are good at.
• ryanthedev 7mo ago
  Ahh, I tend to find software based engineering skills and workflows as the agentic engineering patterns. I distilled multiple software books into these flows and skills. With more books to come. Here is an example https://github.com/ryanthedev/code-foundations https://github.com/ryanthedev/code-foundations
• storus 7mo ago
  These lessons get obliterated with every new LLM generation. Like how LangChain started on stupid models with small context, creating some crazy architecture around it to bypass their limitations that got completely obliterated when GPT-3.5 was released, yet people still use it and overcomplicate things. Rather look at where the puck is going, we might soon not need more than a single agent to do everything given context size keeps increasing, agent can use more tools and we might get some in-call context cleanup at some point as well that would allow an agent to spin forever instead of calling subagents due to context size limitations.
  • simonw 7mo ago
    I'm trying to include patterns that work independently of model releases. It's tricky though. Take "red/green TDD" for example - it's perfectly possible that models will start defaulting to doing that anyway pretty soon. In that case it's only three words so it doesn't feel hugely wasteful if it turns out not to be necessary - and there's still value in understanding what it means even if you no longer have to explicitly tell the agents to do it.
    • anon-3988 7mo ago
      The biggest takeaway for me from LLMs is that the implementation details no longer. If you have a sufficiently detailed tests and requirements, there is going to be a robot that will roll the dice until it fits the tests and requirements.
  • ljlolel 7mo ago
    It’ll all be a ClaudeVM. No code. https://jperla.com/blog/claude-electron-not-claudevm https://jperla.com/blog/claude-electron-not-claudevm
• Juminuvi 7mo ago
  Very much agree with the idea of red/green TDD and have seen really good results during agentic coding. I've found adding a linting step in between increases efficiency as well and fails a bit faster. So it becomes.. Test fail -> implement -> linter -> test pass Another idea I've thought about using is docs driven development. So the instructions might look like.. Write doc for feat/bug > test fail > implement > lint > test pass
• throwaway_20357 7mo ago
  I see where Simon is coming from with these patterns but I wonder where large software companies stand regarding their agentic engineering practices? Is Google creating in-house code using agents against its monorepo? Has Microsoft outsourced Windows source code advancements to a dark factory yet?
• jakgru 7mo ago
  [dead]
• Thews 7mo ago
  There was a mention of using agents to build projects into WASM. I've had the best luck telling it to use zig to compile to webassembly. It shortens the time to completion by a significant amount.
  • simonw 7mo ago
    That's a great tip, thanks! I did not know Zig could do this. You can "pip install ziglang" and get the right version for different platforms too.
    • AndyKelley 7mo ago
      It's not a great tip because there are features that exist specifically to reduce development iteration cycle latency without compiling for the wrong target. Please refer to https://ziglang.org/download/0.15.1/release-notes.html#Incremental-Compilation https://ziglang.org/download/0.15.1/release-notes.html#Incre... This has nothing to do with agentic engineering. This is just normal software development. Everybody wants faster compilation speed
• jihadjihad 7mo ago
  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 on every CI run. Sometimes to pass the tests the model might even hardcode a value in a unit test itself! IMO this section is a great place to show how we as humans can guide the LLM toward a rigorous test suite, rather than one that has a lot of "coverage" but doesn't actually provide sound guarantees about behavior.
  • john-tells-all 7mo ago
    Yes. And, a bad test -- that passes because it's defined to pass -- is _much worse_ than no test at all. It makes you think an edge case is "covered" with a meaningful check. Worse: once you have one "bad apple" in your pile of tests, it decreases trust in the _whole batch of tests_. Each time a test passes, you have to think if it's a bad test...
  • jeremyloy_wt 7mo ago
    > we as humans can guide the LLM toward a rigorous test suite, rather than one that has a lot of "coverage" but doesn't actually provide sound guarantees about behavior. I have a hard enough time getting humans to write tests like this…
  • alkonaut 7mo ago
    This seems it should be very easy to validate. Force the AI to make minimal changes to the code under test, which makes a single (or as few as possible) test fail as a result. If it can't make a test fail at all, it should be useless.
    • jihadjihad 7mo ago
      Agreed, and that's why I think adding some example prompts and ideas to the Testing section would be helpful. A vanilla-prompted LLM, in my experience, is very unreliable at adding tests that fail when the changes are reverted. Many times I've observed that the tests added by the model simply pass as part of the changes, but still pass even when those changes are no longer applied.
• ontouchstart 7mo ago
  Hoarding is becoming an epidemic mental disease in the society of abundance. I don’t know what the solution would be. https://simonwillison.net/guides/agentic-engineering-patterns/hoard-things-you-know-how-to-do/ https://simonwillison.net/guides/agentic-engineering-pattern...
  • simonw 7mo ago
    Personally my plan is to hoard more.
• slaye 7mo ago
  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 the code and provide extensive feedback (mostly architectural and highlighting odd inconsistencies with the code additions) I'm met with much pushback because "it works, why change it"? Not to mention the sheer size of prs ballooning in recent months. The end result is me being the bottleneck because I can't keep up with the "pace" of code being generated, and feeling a lot of discomfort and pressure to lower my standards. I've thought about using a code review agent to review and act as me in proxy, but not being able to control the exact output worries me. And I don't like the lack of human touch it provides. Maybe someone has advice on a humane way to handle this problem.
  • simonw 7mo ago
    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 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? But I don't want to lower my standards! I want the code I'm producing with coding agents to be better than the code I would produce without them. There are some aspects of code review that you cannot skimp on. Things like coding standards may not matter as much, but security review will never be optional. I've recently been wondering what we can learn from security teams at large companies. Once you have dozens or hundreds of teams shipping features at the same time - teams with varying levels of experience - you can no longer trust those teams not to make mistakes. I expect that the same strategies used by security teams at Facebook/Google-scale organizations could now be relevant to smaller organizations where coding agents are responsible for increasing amounts of code. Generally though I think this is very much an unsolved problem. I hope to document the effective patterns for this as they emerge.
• jcmontx 7mo ago
  It baffles me how skeptical people here are of AI-assisted programming. If you don't see productivity gains I feel you're in deep denial. It's true that in my company we're not building rockets or defense systems, maybe you guys are and in those scenarios it's less useful. But for typical LoB and/or consumer-facing software, AI is crushing it. Where I used to need 3 devs, now I just need one (and the support team around it: PM, BA, QA, Designer). For my business, AI has been a game changer.
• MickeyShmueli 7mo ago
  the tautological test problem someone mentioned, i've found the easiest fix is to literally make the test fail first before letting the agent fix it like don't ask it to "write tests for this function", instead give it a function that's deliberately broken in a specific way, make it write a test that catches that bug, verify the test actually fails, THEN fix the function this forces the test to be meaningful because it has to detect a real failure mode. if the agent can't make the test fail by breaking the code, the test is useless the other thing that helps is being really specific about edge cases upfront. instead of "write tests for this API endpoint", say "write tests that verify it returns 400 when the email field is missing, returns 409 when the email already exists, returns 422 when the email is malformed" etc agents are weirdly good at implementing specific test scenarios but terrible at figuring out what scenarios actually matter. which honestly is the same problem junior devs have lol
• fzaninotto 7mo ago
  Is "Agentic Engineering" is the new name for "Agent Experience"? If so, and even though I love Simon's contributions, there are many other guides to making codebases more welcoming to agents... Shameless plug: I wrote one. https://marmelab.com/blog/2026/01/21/agent-experience.html https://marmelab.com/blog/2026/01/21/agent-experience.html
  • simonw 7mo ago
    I hadn't heard that term before, is it widely used? https://agentexperience.ax/ https://agentexperience.ax/ describes it as "refers to the holistic experience AI agents have when interacting with a product, platform, or system" which feels to me like a different concept to figuring out patterns for effectively using coding agents as a software engineer.
• SurvivorForge 7mo ago
  The code review bottleneck point resonates a lot. When agents can generate PRs in minutes, the human review step becomes the critical bottleneck — and it doesn't scale with generation speed. The teams I've seen handle this best treat agent output like a junior dev's work: smaller atomic commits, mandatory test coverage as a gate, and explicit reviewer checklists focused on logic rather than syntax. The shift is from "does this look right" to "does this behave correctly under these conditions."
• shreddd24 7mo ago
  Absolutely great work. I have been mostly just thinking about what you are already practicing. I think your site will become an invaluable source for software engineers who want to responsibly apply AI in their development flow. For a high level description of what this new way of engineering is about: https://substack.com/@shreddd/p-189554031 https://substack.com/@shreddd/p-189554031
• krasikra 7mo ago
  [dead]
• hsaliak 7mo ago
  I'd like to plug https://github.com/hsaliak/std_slop/blob/main/docs/mail_model.md 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.
• flashybaby 7mo ago
  [flagged]
• bhekanik 7mo ago
  [flagged]
  • noisy_boy 7mo ago
    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.
• Ted719069 7mo ago
  [dead]
• andresquez 7mo ago
  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.
• simonw 7mo ago
  I just started a new chapter partly inspired by this comment thread - anti-patterns: things NOT to do. So far I only have one: Inflicting unreviewed code on collaborators, aka dumping a thousand line PR without even making sure it works first https://simonwillison.net/guides/agentic-engineering-patterns/anti-patterns/#inflicting-unreviewed-code-on-collaborators https://simonwillison.net/guides/agentic-engineering-pattern...
• bluemario 7mo ago
  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 checkpoints. Too frequent and you've just built a slow pair programmer. Too infrequent and you're doing expensive archaeology to figure out where it went sideways. We've landed on "before any irreversible action" as a useful heuristic, but that requires the agent to have some model of what's irreversible, which is its own can of worms. Has anyone found a principled way to communicate implicit codebase conventions to an agent beyond just dumping a CLAUDE.md or similar file? We've tried encoding constraints as linter rules but that only catches surface stuff, not architectural intent.
  • Yanko_11 7mo ago
    [dead]
  • mrothroc 7mo ago
    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/ https://michael.roth.rocks/research/trust-topology/
• bhaktatejas922 7mo ago
  have loved simon wilson for a long long time and still do. These patterns are all out of date by at least a year - the best devs I know were using Claude 3.5 like this
  • simonw 7mo ago
    Good. If they worked with Sonnet 3.5 a year ago that means they have sticking power and are worth writing about today.
• vicchenai 7mo ago
  [dead]
• dgunay 7mo ago
  A lot of this is just things that high-functioning human teams were already doing: automate testing, explain your PRs to guide reviewers, demoing work, not just throwing bad code over the wall during code review, etc.
• luca-ctx 7mo ago
  > I don't let LLMs write text for my blog. Thank you Simon and I'm sure you would quickly fall off from #1 blogger on HN if you did. I insist on this for myself as well. Somehow we are all getting really good at detecting "written by AI" with primal intuition.
• laalshaitaan 7mo ago
  The test harness point is spot on but there's a gap worth naming: the failure modes you write evals for aren't the ones that cause users to churn. Prod conversations have a whole category where the agent doesn't error, it just confidently goes sideways in a way nobody wrote a test for. The teams actually retaining users from AI products are reading conversations, not just dashboards.
• noddingham 7mo ago
  I'd choose a different word for the title of Hoard Things You Know How to Do. Hoarding is the opposite of what we want to do but I get from reading the section you mean create a collection that you can draw upon. IMO "Share" is a much better word choice.
• truejaian 7mo ago
  [dead]
• AlexCalderAI 7mo ago
  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/ https://osolobo.com/first-ai-agent-guide/
• jpadkins 7mo ago
  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)
• deleted 7mo ago
  [deleted]
• AlexCalderAI 7mo ago
  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.
• lunias 7mo ago
  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.