You're a Builder
You don't write every line of code because you don't need to. You've developed the taste to know what good output looks like, and that's what lets you operate one level up: steering agents, verifying output, and shipping without personally writing every part of it.
In a few years, most engineers will work this way. What separates a good Builder from the rest isn't the tooling, it's the judgement they bring to it.
You steer agents, verify output, and ship.
What this means
Where others write code line by line, you operate one level up. You set direction, define outcomes, and judge agent output against your expectations. You know when something is going off track before reading every line because you've developed a feel for what good code looks like and what drift looks like before it compounds.
That feel is the skill. The taste for quality and the instinct to spot when something is heading in the wrong direction are what matter. The tooling is just how you apply it.
What you actually do
- Drive velocity by focusing on product outcomes rather than implementation details. Your job is to ship the thing, not to personally author every part of it.
- Build verification loops into your process: you watch agent thinking, track how long something is taking relative to what you'd expect, check diff size, and verify output before it moves forward. If any of those feel off, something probably is.
- Know when something is off-track without reading every line of code, and course-correct before small drift becomes a bigger problem.
- Adapt your tooling to the task: parallel agents when the work suits it, more focused approaches when complexity demands closer attention.
- Accept "good enough" when it genuinely is: slightly verbose code or adequate performance is a reasonable trade if the product ships and the customer is unblocked.
- Own your output. The agent made it, but you shipped it. That's on you, and you know it.
- Defend your worldview when it's challenged. Working at abstraction, accepting "good enough," and trusting agents over line-by-line review are deliberate choices built on experience. When colleagues push back, you can articulate why this approach produces good outcomes rather than retreating or over-explaining.
What you don't do
- Ship buggy or genuinely non-performant code. Operating at high abstraction is a responsibility to maintain quality through different means, not a licence to ignore it.
- Blame the AI for mistakes. You set the direction, you verified the output, you shipped. The accountability is yours.
How you use AI
You treat AI as an autonomous execution engine. You define what needs to happen, you watch it happen, and you verify the result. Claude Code and agentic tools are your main environment. The loop is short: brief agent, verify output, iterate if needed, ship.
You've developed a feel for the rhythm: how long something should take, how big a diff should be, what an agent heading in the wrong direction looks like before it's gone too far. That instinct is the skill.
Where you shine
- Feature delivery on established codebases where the patterns are clear and the main constraint is time-to-delivery.
- Customer-driven changes where speed matters and quality is non-negotiable. You can hold both.
- Any situation where the pace of delivery has gone up across the board and the team needs to meet it. In a world where the floor has risen, your ability to operate at higher velocity without burning out is what makes you valuable.
Your blind spots
- The higher you operate, the easier it is to miss slow pattern drift. A slightly off decision in the agent output that you accept ten times in a row starts to compound. If you notice you're delegating almost everything to AI and skill atrophy is starting to kick in, that's a signal worth paying attention to. Slow down for a bit and build something manually again.
- Your pace should follow your taste, not the other way around. Work that needs little taste can move fast. Work that needs real craft, like a genuinely delightful experience or a technically tricky problem, deserves more time and focus.
- On highly novel or technically uncertain problems, this archetype can hit its limits. Agentic tools work best when the direction is clear. When it isn't, slowing down to think or pairing with a Multiplier is usually the right call.
- Defending your worldview is healthy up to a point. Watch for the version where you stop genuinely hearing feedback. If an Artisan flags drift and your first instinct is to dismiss it as perfectionism, pause. The confidence that makes you effective can become the thing that stops you improving.
Where you might be heading
Builders who develop systems thinking and start asking not just "how do I ship this faster?" but "how do I make the whole team faster?" are on the path toward Multiplier. The skills transfer. The instinct for good output becomes the ability to build guardrails that improve everyone's output.
Builders who go deep in a specific area and develop expertise beyond what agents can reliably do are moving toward Artisan. That's a different kind of leverage, and it's valuable too.
Neither path is better. Both are worth choosing intentionally.
Explore the other archetypes
Not sure this one fits? Read about the others and see what lands.
- The Multiplier: Makes everyone around them faster. Uses AI to think bigger: prototyping patterns, setting guardrails, and extending team capability instead of just personal output.
- The Explorer: Reads systems from the outside in. Uses AI to answer their own questions about the codebase instead of pulling other people off product work.
- The Artisan: Leads AI moment-to-moment because default output isn't good enough in their area of depth. Stays close to the code and catches drift early.
- The Apprentice: Co-creates with AI through dialogue. Builds judgement one prompt at a time, and ships only what they can defend.
Or go back to the AI Engineering Archetypes overview to see the full picture.