Get the top HN stories in your inbox every day.
maxbond
ssgodderidge
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.”
zx8080
> “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.
simonw
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...
undefined
skydhash
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.
…must become experts at learning and experts at managing complexity
Iteration
Feedback
Incrementalism
Experimentation
Empiricism
Modularity
Cohesion
Separation of Concerns
Abstraction
Loose Coupling
simonw
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...
skydhash
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.
esafak
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.
simonw
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.
archagon
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.
maxbond
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.
Peritract
> 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.
archagon
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.
imtringued
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?
simonw
Because in order to distinguish what we are doing from vibe coding we need the word that sounds more impressive.
vidarh
I think the automation makes a significant difference though. I'm building a tool that is self-improving, and I use "building" for a reason: I've written about 5 lines of it, to recover from early failures. Other than that, I've been reviewing and approving plans that the system has executed itself. Increasingly I'm not even doing that. Instead I'm writing requirements, reviewing high level specs, let the system generate its own work items and test plans, execute them, verify the test plan was followed. Sometimes I don't even read past the headline of the plan.
I've read a reasonable proportion of the code. Not everything is how I'd like it to be, but regularly I'll tell the system to generate a refactoring plan (with no details, that's up to the agent to figure out), and it does, and they are systematically actually improving the quality.
We're not quite there yet, but I plan to build more systems with it that I have no intention of writing code for.
This might sound like "just" vibe coding. But the difference to me is that there are extensive test plans, and a wide range of guard rails, a system that rewards gradually refining hard requirements that are validated.
undefined
neonbrain
The term feels broken when adhering to standard naming conventions, such as Mechanical Engineering or Electrical Engineering, where "Agentic Engineering" would logically refer to the engineering of agents
simonw
Yeah, Armin Ronacher has been calling it "agentic coding" which does at least make it clear that it's not a general engineering thing, but specifically a code related thing.
pamelafox
I think “agent engineering” could refer to the latter, if a distinction needs to be made. I do get what you’re saying, but when I heard the term, I personally understood its meaning.
victorbjorklund
Lots of things already violate it. The normal Site Reliability Engineer isn’t building the tools for Site Reliability but rather applies the tools to other software.
sigbottle
There should be more willingness to have agents loudly fail with loud TODOs rather than try and 1 shot everything.
At the very least, agentic systems must have distinct coders and verifiers. Context rot is very real, and I've found with some modern prompting systems there are severe alignment failures (literally 2023 LLM RL levels of stubbing out and hacking tests just to get tests "passing"). It's kind of absurd.
I would rather an agent make 10 TODO's and loudly fail than make 1 silent fallback or sloppy architectural decision or outright malicious compliance.
This wouldn't work in a real company because this would devolve into office politics and drudgery. But agents don't have feelings and are excellent at synthesis. Have them generate their own (TEMPORARY) data.
Agents can be spun off to do so many experiments and create so many artifacts, and furthermore, a lot more (TEMPORARY) artifacts is ripe for analysis by other agents. Is the theory, anyways.
The effectively platonic view that we just need to keep specifying more and more formal requirements is not sustainable. Many top labs are already doing code review with AI because of code output.
jbethune
I think there is a meaningful distinction here. It's true that writing code has never been the sole work of a software engineer. However there is a qualitative difference between an engineer producing the code themselves and an engineer managing code generated by an LLM. When he writes there is "so much stuff" for humans to do outside of writing code I generally agree and would sum it up with one word: Accountability. Humans have to be accountable for that code in a lot of ways because ultimately accountability is something AI agents generally lack.
nlawalker
I think within the industry and practice there's going to be a renewed philosophical and psychological examination of exactly what accountability is over the next few years, and maybe some moral reckoning about it.
What makes a human a suitable source of accountability and an AI agent an unsuitable one? What is the quantity and quality of value in a "throat to choke", a human soul who is dependent on employment for income and social stature and is motivated to keep things from going wrong by threat of termination?
aewens
“It’s not vibe coding, it’s agentic engineering”
From Kai Lentit’s most recent video: https://youtu.be/xE9W9Ghe4Jk?t=260
simonw
Thanks for the reminder, I should add a note about vibe coding to this piece.
DonHopkins
Except for the bad advice about using VIM. Emacs FTW! I even named my cat Emacs.
redhale
As someone who works with real licensed engineers (electrical, civil), I wish we would use the term "agentic software engineering" to describe this. Omitting "software" here betrays a very SWE-centric mindset.
Agents are coming for the other engineering disciplines as well.
danieltanfh95
Agentic engineering is working from documentation -> code and automating the translation process via agents. This is distinct from the waterfall process which describes the program, but not the code itself, and waterfall documentation cannot be translated directly to code. Agent plans and session have way more context and details that are not captured in waterfall due to differences in scope.
nclin_
I've discovered recently as code gets cheaper and more reliable to generate that having the LLM write code for new elements in response to particular queries, with context, is working well.
Kind of like these HTML demos, but more compact and card-like. Exciting the possibilities for responsive human-readable information display and wiki-like natural language exploration as models get cheaper.
jdlyga
Sure, you could argue it's like writing code that gets optimized by the compiler for whatever CPU architecture you're using. But the main difference between layers of abstraction and agentic development is the "fuzzyness" of it. It's not deterministic. It's a lot more like managing a person.
pamelafox
I’ve been using the term “agentic coding” more often, because I am always shy to claim that our field rises to the level of the engineers that build bridges and rockets. I’m happy to use “agentic engineering” however, and if Simon coins it, it just might stick. :) Thanks for sharing your best practices, Simon!
simonw
I decided to go with it after z.AI used it in their GLM-5 announcement: https://z.ai/blog/glm-5 - I figured if the Chinese AI labs have picked it up that's a good sign it's broken out.
sigseg1v
I think there are a lot of reasons to use your suggested alternative title. One example being that in a lot of countries such as Canada, it's illegal to use the title Engineer without holding a PEng designation from the countries/provinces engineering body, eg: https://www.egbc.ca/complaints-discipline/unauthorized-pract...
iamcreasy
Is there any article explaining how AI tools are evolving since the release of ChatGPT? Everything upto MCP makes sense to me - but since then it feels like there is not clear definition on new AI jergons.
kevintomlee
the practice of developing software with the assistance of coding agents.
Spot on.
Get the top HN stories in your inbox every day.
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.