Live data from Hacker News

Agentic Engineering Patterns

simonwillison.net

281–290 of 341 posts

Re: Agentic Engineering Patterns

#281

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…

>Doesn't it sound like the "right incantation"?

It sounds like you have a misunderstanding of what LLMs are/can do.

Imagine that you only get one first interaction with a person that you're having try to build something and you're trying to minimize the amount back and forth.

For humans this can be something like an instruction manual. If you've put together more than a few things you quickly realize that instruction manuals vary highly in quality, some will make your life much easier and other will leave you confused.

Lastly, (human) intent is a social construct. The more closely you're aligned with the entity in question the more it's apt to fully comprehend your intent. This is partially the reason why when you throw a project at workers in your office they tend to get it right, and when you throw it towards the overseas team you'll have to check in a lot more to ensure it's not going off the rails.

Re: Agentic Engineering Patterns

#282
post #273

Earlier quoted context omitted.

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…

These are just agents with a different name ? People have been working like that today.

Theoretically I'd want a totally different model cross checking the work at some point, since much like an individual may have blind spots, so will a model.

Re: Agentic Engineering Patterns

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

> 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? I don't care how cheap it is to replace the incorrect code when it's modifying my bank account or keeping my lights on.

Oh, don't worry, even before AI the companies in question were already outsourcing a lot of this to the cheapest companies they could find. We are just very very lucky most of the problems incurred get caught before being foisted on the wider world.

Re: Agentic Engineering Patterns

#284
post #261

Earlier quoted context omitted.

> consensus best practice I'm not sure I agree with this. I don't think there needs to be a whole spec & documentation process before plan mode. There is alternative thought leadership that the waterfall approach for building out projects is not the right Agentic pattern[1]. Planning itself can be such an intensive process where you're designing and figuring out the specs on the fly in a focused manner for the thing…

I think there's a Danger Zone when planning is light-weight and iterative, and code is cheap, but reviewing code is expensive: it leads to a kind of local hill-climbing. Suppose you iterate through many sessions of lightweight planning, implementation, and code review. It _feels_ high velocity, you're cranking through the feature, but you've also invested a lot of your time and energy (planning isn't free, and code r…

nice thoughts

Re: Agentic Engineering Patterns

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

Re: Agentic Engineering Patterns

#287
post #195
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…

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.

Re: Agentic Engineering Patterns

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

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

Re: Agentic Engineering Patterns

#289
post #269

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…

> create an entire industry of consultants and experts selling books and enterprise coaching around it I suspect that this time around, management will expect the AI chatbot to explain these things to you, because who pays for anything anymore if the AI can do it all.

That's why there needs to be some mysticism around it. The agile manifesto is short enough to be memorised by a toddler, simple enough to be understood by management, yet created an entire industry of parasites around it.

If the answer is just "Install Oh My Opencode and stick any decent model in it" then it doesn't work.

And honestly, the answer is just to install Oh My Opencode and Kimi K2.5 and get 90% of the performance of Opus for a fraction of the price.

Re: Agentic Engineering Patterns

#290
post #157
post #153

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.

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.

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

This has nothing to do with agentic engineering. This is just normal software development. Everybody wants faster compilation speed

Post reply on HN