alt.hn

3/16/2026 at 1:07:47 AM

What is agentic engineering?

 https://simonwillison.net/guides/agentic-engineering-patterns/what-is-agentic-engineering/

by lumpa

3/16/2026 at 2:19:19 AM

I don't think we should be making this distinction. We're still engaged in software engineering. This isn't a new discipline, it's a new technique. We're still using testing, requirements gathering, etc. to ensure we've produced the correct product and that the product is correct. Just with more automation.

by maxbond

3/16/2026 at 2:29:56 AM

I agree, partly. I feel the main goal of the term “agentic engineering” is to distinguish the new technique of software engineering from “Vibe Coding.” Many felt vibe coding insinuated you didn’t know what you were doing; that you weren’t _engineering_.

In other words, “Agentic engineering” feels like the response of engineers who use AI to write code, but want to maintain the skill distinction to the pure “vibe coders.”

by ssgodderidge

3/16/2026 at 5:15:43 AM

> “Agentic engineering” feels like the response of engineers who use AI to write code, but want to maintain the skill distinction to the pure “vibe coders.”

If there's such. The border is vague at most.

There're "known unknowns" and "unknown unknowns" when working with systems. In this terms, there's no distinction between vibe-coding and agentic engineering.

by zx8080

3/16/2026 at 5:17:41 AM

My definition to "vibe coding" is the one where you prompt without ever looking at the code that's being produced.

The moment you start paying attention to the code it's not vibe coding any more.

Update: I added that definition to the article: https://simonwillison.net/guides/agentic-engineering-pattern...

by simonw

3/16/2026 at 5:35:58 AM

What if you review 50%? Or 10%? Or only 1%, is it not vibe coding yet?

Where is the borderline?

by zx8080

3/16/2026 at 5:41:48 AM

I think the borderline is when you take responsibility for the code, and stop blaming the LLM for any mistakes.

That's the level of responsibility I want to see from people using LLMs in a professional context. I want them to take full ownership of the changes they are producing.

by simonw

3/16/2026 at 6:59:39 AM

Sounds good, however the bar is probably too far and far too idealistic.

The effects of vibecoding destroys trust inside teams and orgs, between engineers.

by zx8080

3/16/2026 at 12:08:31 PM

As would the effects of shipping unverified, untested code pre-agents existing. Bad quality will always erode trust.

The problem with LLM-based coding is that the speed it can generate code (whether good or bad) is much faster than before.

by ssgodderidge

3/16/2026 at 7:18:15 AM

And are you not seeing that level of responsibility?

by Toutouxc

3/16/2026 at 7:27:31 AM

I'm trying to demonstrate that in my own work, but from the comments I see in places like Hacker News there are a lot of people who aren't.

I wrote a note about that here: https://simonwillison.net/guides/agentic-engineering-pattern...

by simonw

3/16/2026 at 9:25:49 AM

Ragentic Engineering is when you curse at the LLM.

by DonHopkins

3/16/2026 at 5:52:49 AM

I don't blame the agent for mistakes in my vibe coded personal software, it's always my fault. To me it's like this:

80%+: You don't understand the codebase. Correctness is ensured through manual testing and asking the agent to find bugs. You're only concerned with outcomes, the code is sloppy.

50%: You understand the structure of the codebase, you are skimming changes in your session, but correctness is still ensured mostly through manual testing and asking the agent to review. Code quality is questionable but you're keeping it from spinning out of control. Critically, you are hands on enough to ensure security, data integrity, the stuff that really counts at the end of the day.

20%-: You've designed the structure of the codebase, you are writing most of the code, you are probably only copypasting code from a chatbot if you're generating code at all. The code is probably well made and maintainable.

by maxbond

3/16/2026 at 7:20:48 AM

I feel like there’s one more dimension. For me, 95%+ of code that I ship has been written (i.e. typed out) by a LLM, but the architecture and structure, down to method and variable names, is mine, and completely my responsibility.

by Toutouxc

3/16/2026 at 5:42:26 AM

Have to consult the Definition Engineers to find out

by 000ooo000

3/16/2026 at 2:52:09 AM

My preferred definition of software engineering is found in the first chapter of Modern Software Engineering by David Farley

  Software engineering is the application of an empirical, scientific approach to finding efficient, economic solutions to practical problems in software.
As for the practitioner, he said that they:

  …must become experts at learning and experts at managing complexity
For the learning part, that means

  Iteration
  Feedback
  Incrementalism
  Experimentation
  Empiricism
For the complexity part, that means

  Modularity
  Cohesion
  Separation of Concerns
  Abstraction
  Loose Coupling
Anyone that advocates for agentic engineering has been very silent about the above points. Even for the very first definition, it seems that we’re no longer seeking to solve practical problems, nor proposing economical solutions for them.

by skydhash

3/16/2026 at 3:02:23 AM

That definition of software engineering is a great illustration of why I like the term agentic engineering.

Using coding agents to responsibly and productively build good software benefits from all of those characteristics.

The challenge I'm interested in is how we professionalize the way we use these new tools. I want to figure out how to use them to write better software than we were writing without them.

See my definition of "good code" in a subsequent chapter: https://simonwillison.net/guides/agentic-engineering-pattern...

by simonw

3/16/2026 at 3:15:14 AM

I’ve read the chapter and while the description is good, there’s no actual steps or at least a general direction/philosophy on how to get there. It does not need to be perfect, it just needs to be practical. Then we could contrast the methodology with what we already have to learn the tradeoffs, if they can be combined, etc…

Anything that relates to “Agentic Engineering” is still hand-wavey or trying to impose a new lens on existing practices (which is why so many professionals are skeptical)

ADDENDUM

I like this paragraph of yours

We need to provide our coding agents with the tools they need to solve our problems, specify those problems in the right level of detail, and verify and iterate on the results until we are confident they address our problems in a robust and credible way.

There’s a parallel that can be made with Unix tools (best described in the Unix Power Tools) or with Emacs. Both aim to provide the user a set of small tools that can be composed and do amazing works. One similar observation I made from my experiment with agents was creating small deterministic tools (kinda the same thing I make with my OS and Emacs), and then let it be the driver. Such tools have simple instructions, but their worth is in their combination. I’ve never have to use more than 25 percent of the context and I’m generally done within minutes.

by skydhash

3/16/2026 at 4:57:14 AM

[dead]

by justboy1987

3/16/2026 at 4:35:06 AM

You can do these things with AI, especially if you start off with a repo that demonstrates how, for the agent to imitate. I do suggest collaborating with the agent on a plan first.

by esafak

3/16/2026 at 2:49:22 AM

Yeah, I see agentic engineering as a sub-field or a technique within software engineering.

I entirely agree that engineering practices still matter. It has been fascinating to watch how so many of the techniques associated with high-quality software engineering - automated tests and linting and clear documentation and CI and CD and cleanly factored code and so on - turn out to help coding agents produce better results as well.

by simonw

3/16/2026 at 5:20:34 AM

Actually, if you defer all your coding decisions to agents, then you're not doing engineering at all. You don't say you're doing "contractor engineering" when you pay some folks to write your app for you. At that point, you are squarely in the management field.

by archagon

3/16/2026 at 6:28:40 AM

If you're producing a technological artifact and you are ensuring it has certain properties while working within certain constraints, then in my mind you're engineering and it's a question of the degree of rigor. Engineers in the "hard engineering" fields (eg mechanical engineers, civil engineers) a rule don't build the things they design, they spend a lot of time managing/working with contractors.

by maxbond

3/16/2026 at 7:41:03 AM

> If you're producing a technological artifact and you are ensuring it has certain properties while working within certain constraints, then in my mind you're engineering

This covers every level of management in tech companies.

by Peritract

3/16/2026 at 9:40:06 AM

I’m pretty sure engineers in those professions need to know the physical/mathematical properties of their designs inside and out. The contractors are not involved in that and have limited autonomy.

I would not want to drive over a vibe-coded bridge.

by archagon

3/17/2026 at 7:18:40 AM

The fact that simonw is so eager to drop the word "software" in software engineer and keep the word "engineer" reeks of ego.

You're not the engineer anymore, but you're still responsible for creating software. Why drop the most important word and keep the ego stroking word?

by imtringued

3/17/2026 at 12:29:59 PM

Because in order to distinguish what we are doing from vibe coding we need the word that sounds more impressive.

by simonw