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

331–340 of 341 posts

Re: Agentic Engineering Patterns

#331

Post by vidarh »

jplusequalt wrote: post #208
vidarh wrote: post #75

Earlier quoted context omitted.

Yes, it's often faster if you sit around waiting . What I will do instead is prompt the AI to create various plans, do other stuff while they do, review and approve the plans, do other stuff while multiple plans are being implemented , and then review and revise the output. And I have the AI deal with "knowing how to do it" as well. Often it's slower to have it do enough research to know how to do it, but my time is…

>And I have the AI deal with "knowing how to do it" as well. Often it's slower to have it do enough research to know how to do it This is exactly the sort of future I'm afraid of. Where the people who are ostensibly hired to know how stuff works, out source that understanding to their LLMs. If you don't know how the system works while building, what are you going to when it breaks? Continue to throw your LLM at it? A…

There are many layers to "knowing how stuff works". What does your manager do when your code breaks?

> Continue to throw your LLM at it?

Increasingly, yes. If you have objective acceptance criteria, just putting the LLM in a loop with a quality gate tends to have it converge on a fix itself, the same way a human would. Not always, and not always optimally, but more and more often, and with cheaper and cheaper models.

I also tend to throw in an analysis stage where it will look at what went wrong and use that to add additional criteria for the next run.

Re: Agentic Engineering Patterns

#332

Post by abustamam »

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…

Related: https://www.commitstrip.com/en/2016/08/25/a-very-comprehensi...?

At my job, we use a lot of AI to literally move fast and break things when working on internal tools. The idea is that the surface area is low, rollbacks are fast, and the upside is a lot better than the downside (our end users get a better experience to help them do their job better).

But our bottleneck is still requirements for the project. We routinely run out of stuff to do and have to ask for new stuff or work on a different project.

But you're absolutely right. Most people (programmers, managers, etc) don't know exactly what problems need to be solved, or at least, struggle to communicate it adequately for it to be implemented well enough. They say they want X. But they haven't thought about the repercussions of it, or that it requires Y first. AI might be able to help there, but it will give a totally bogus answer if it does not have any context of the domain, which is almost never documented in code.

These are still very much so technical roles, but maybe we are becoming more "technical domain experts."

Re: Agentic Engineering Patterns

#333

Post by port11 »

vidarh wrote: post #330
port11 wrote: post #185

Earlier quoted context omitted.

This sounds like one recipe for burnout, much like Aderal was making everyone code faster until their brain couldn’t keep up with its own backlog.

If anything, it's the opposite. With a proper harness you stop having to spend so much energy reviewing every little intermediate step, and can focus on the higher level. I'm actually working on a project now where the biggest problem I need to solve is that the verifier that reviews the test harness is too strict .

I keep being told that a proper harness makes agents better, but no one has shown me exactly what is it that gives them such amazing results.

Yesterday Gemini burned 40 minutes trying to diagnose a failed Expo build and going into loops of changing the Podfile and re-running the build, when the issue was that Xcode needed updating (quick Google search for it).

But my comment on burnout stands. The lack of downtime and dynamic thinking modes (admin, planning, review, actual coding) seems like it would conspire to make you either cram out more work or disconnect from it. Both of these become dangerous, after a while.

(Information workers were productive 4–6 hours a day, and the economy did just fine.)

Re: Agentic Engineering Patterns

#334

Post by geon »

gaigalas wrote: post #42

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

The machines in factory production lines are generally very deterministic. Not sure how well industrialisation would have worked if the machines just did whatever.

Re: Agentic Engineering Patterns

#335

Post by gaigalas »

geon wrote: post #334
gaigalas wrote: post #42

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

The machines in factory production lines are generally very deterministic. Not sure how well industrialisation would have worked if the machines just did whatever.

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.

Re: Agentic Engineering Patterns

#336

Post by geon »

gaigalas wrote: post #335
geon wrote: post #334

Earlier quoted context omitted.

The machines in factory production lines are generally very deterministic. Not sure how well industrialisation would have worked if the machines just did whatever.

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

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.

Re: Agentic Engineering Patterns

#337

Post by jplusequalt »

vidarh wrote: post #331
jplusequalt wrote: post #208

Earlier quoted context omitted.

>And I have the AI deal with "knowing how to do it" as well. Often it's slower to have it do enough research to know how to do it This is exactly the sort of future I'm afraid of. Where the people who are ostensibly hired to know how stuff works, out source that understanding to their LLMs. If you don't know how the system works while building, what are you going to when it breaks? Continue to throw your LLM at it? A…

There are many layers to "knowing how stuff works". What does your manager do when your code breaks? > Continue to throw your LLM at it? Increasingly, yes. If you have objective acceptance criteria, just putting the LLM in a loop with a quality gate tends to have it converge on a fix itself, the same way a human would. Not always, and not always optimally, but more and more often, and with cheaper and cheaper models.…

Do you feel no shame shipping code without understanding how any of it works?

Re: Agentic Engineering Patterns

#338

Post by yencabulator »

toraway wrote: post #292
sarkarsh wrote: post #216

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…

Even without that, the relentless spamming of their latest project is insufferable.

Re: Agentic Engineering Patterns

#339

Post by ozim »

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…

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.

Re: Agentic Engineering Patterns

#340

Post by ozim »

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? :)

Post reply on HN