I’ve been trying to find a word for what I do. I can’t write PHP. I’m not a developer. But I’ve shipped a real SaaS product, handled security reports, fixed performance issues, and made hundreds of commits to a production Laravel codebase. Calling myself “non-technical” doesn’t feel right anymore. Neither does “developer.”
The best term I’ve found is agentic engineer.
Table of contents
Open Table of contents
What is agentic engineering?
Agentic engineering is directing AI agents to build and maintain real software. You don’t write the code — you own everything around it: the architecture decisions, the product direction, the quality bar, the debugging process, and the final judgement on whether something is ready to ship.
It’s engineering because you’re solving real technical problems. You’re reasoning about database schemas, evaluating performance trade-offs, making architecture decisions, and debugging production issues. The difference is that your primary tool is an AI agent rather than a text editor.
The workflow looks like this:
- You define the problem — what needs to change, why it matters, and what the constraints are
- The AI agent writes the code — following the patterns and conventions of your codebase
- You review the output — not the syntax, but the behaviour, the architecture, and the intent
- You iterate — describing what’s wrong, asking why the approach failed, directing the next attempt
- You decide when to ship — balancing quality, scope, and priorities like any engineer would
This isn’t delegation. It’s collaboration with a tool that’s good at writing code but has no opinion about whether the code should exist in the first place.
Agentic engineering vs vibe coding
These look similar from the outside — both involve telling an AI what to build. But they’re different in intent, rigour, and outcome.
Vibe coding is a term coined by Andrej Karpathy to describe a style of building where you prompt an AI, accept what comes back, and keep going. You don’t really look at the code. You don’t understand the architecture. If it works, you ship it. If it breaks, you prompt again.
Agentic engineering is deliberate. You understand what the AI is building and why. You review architecture decisions. You catch when the AI solves the right problem in the wrong place. You maintain a mental model of your system even if you can’t write the syntax from memory.
| Vibe coding | Agentic engineering | |
|---|---|---|
| Goal | Get something working fast | Build something maintainable |
| Code review | Minimal — accept what the AI produces | Active — evaluate architecture, intent, and behaviour |
| Understanding | Surface-level — does it work? | Conceptual — why does it work, and is this the right approach? |
| Debugging | Prompt again until it works | Investigate root causes, ask why the first fix failed |
| Architecture | Whatever the AI defaults to | Intentional decisions about components, patterns, and trade-offs |
| Ownership | The AI wrote it | I directed it, reviewed it, and decided to ship it |
| Codebase over time | Accumulates complexity and inconsistency | Follows conventions, stays maintainable |
| Best for | Prototypes, throwaway projects, learning | Production software, products you need to maintain |
Vibe coding is useful. I’ve done it for quick experiments. But when you’re building something real — something with users, with data, with a future — you need more discipline than “accept and move on.”
The difference isn’t the tool. It’s the intent. Vibe coding optimises for speed of creation. Agentic engineering optimises for quality of outcome.
Agentic engineer vs developer
I sit on one side of this comparison and work alongside people on the other.
A traditional developer’s primary skill is writing code. They think in syntax, patterns, and implementation. They can open a blank file and build something from nothing. They understand the language, the framework internals, and the runtime behaviour at a level I never will.
An agentic engineer’s primary skill is directing AI to write code. They think in outcomes, constraints, and product decisions. They can describe what needs to happen clearly enough for an AI agent to implement it, then evaluate whether the implementation is correct.
| Traditional developer | Agentic engineer | |
|---|---|---|
| Primary skill | Writing code | Directing AI agents to write code |
| Thinks in | Syntax, patterns, implementation | Outcomes, constraints, product decisions |
| Debugging approach | Read the code, trace the logic, fix the bug | Describe the symptoms, evaluate the AI’s diagnosis, direct the fix |
| Architecture | Design and implement from experience | Evaluate and direct based on conceptual understanding |
| Code review | Line-by-line syntax and logic review | Behavioural and architectural review |
| Strengths | Deep technical knowledge, edge case handling, performance optimisation | Product sense, cross-domain knowledge, rapid iteration |
| Weaknesses | Can lose sight of the product while focused on the code | Can miss implementation subtleties the AI gets wrong silently |
| Bottleneck | Time to write and test code | Quality of direction and review |
These aren’t competing roles. They’re complementary. A developer who learns to work with AI agents becomes far more productive. An agentic engineer who deepens their technical understanding becomes more effective at guiding those agents.
But here’s what’s new: the agentic engineer role didn’t exist two years ago. There was no way to contribute meaningfully to a production codebase without writing code. AI agents changed that. Not by making coding easy — by making code the output of a different kind of input.
What an agentic engineer needs to know
You don’t need to know PHP. But you need to know things. Here’s what I’ve found matters:
- Concepts over syntax — I learned five git concepts and never memorised a single command. I understand what a migration does without being able to write one. The concepts help me work with the AI and catch its mistakes.
- Architecture thinking — Knowing when something should be a Livewire component versus plain Blade markup, or when to use a queue versus an inline operation. These decisions shape the entire system and the AI won’t make them for you.
- Product sense — Knowing what to build, what to skip, and what order to build things in. This is the most underrated engineering skill and it has nothing to do with code.
- Taste — The AI will never tell you your border colours are inconsistent or your loading states feel janky. Noticing what’s slightly wrong and caring enough to fix it is what separates functional from good.
- Framework knowledge — Understanding Laravel’s conventions well enough to know when the AI is following them and when it’s drifting. The framework does the structural thinking, but you need to verify it.
Why this matters
The term “developer” has meant “person who writes code” for decades. That definition is breaking down. Not because code doesn’t matter — it does — but because writing code is no longer the only way to produce it.
Agentic engineering is a new discipline. It borrows from product management, engineering, and design — but it’s none of those things on their own. It’s a different skill set applied to the same goal: shipping software that works.
I’m not a developer. I’m an agentic engineer.