What an AI Developer Should Be Able to Do

An AI Developer is a senior software engineer who ships what a small development pod used to ship, features, tests, bug fixes, internal tools, and integrations, by working through an AI coding stack they build, direct, and verify themselves. In a business, that means one accountable person takes goals from ticket to tested, reviewed, deployed code at a multiple of traditional pace, with a hard quality gate on every merge. The AI produces implementation volume; the human owns architecture, correctness, and the decision to ship.

This guide describes what that actually looks like: the concrete capabilities a business should expect from anyone calling themselves an AI Developer, organized around the six competencies of the Multistaff Operator Standard, with the benchmarks that separate real augmentation from a Copilot subscription.

The capability baseline: what the role does with AI

Strip away the titles and an AI Developer does three things a traditional developer does not.

First, they treat implementation as directed volume, not personal typing. Well-specified work, the feature whose behavior is written down, the migration with a known shape, the test suite that needs backfilling, goes to AI tooling running against a spec, while the developer’s attention goes to the decisions the tooling cannot make.

Second, they treat the repeatable parts of engineering as automation targets. Codebase research, boilerplate, scaffolding, first-draft documentation, dependency upgrades, and routine refactors run through documented workflows that survive from project to project, instead of being redone by hand each time.

Third, they treat verification as a built-in stage of the work, not a virtue. Every change passes tests and their own review before it merges, because they know precisely how AI-generated code fails: plausible logic that answers a slightly different question, tests that assert the wrong thing confidently, and shortcuts that become security holes.

Everything below is those three behaviors, made testable.

The six capabilities, competency by competency

1. Stack ownership: a coding toolchain they can justify tool by tool

The first observable capability is an owned, current AI stack, not familiarity with a tool the last employer happened to license. In 2026, a defensible developer stack centers on an agentic coding tool, Claude Code or Cursor in most real stacks, driving implementation against written specs, with the model doing multi-file work across the codebase rather than line-by-line autocomplete. Around it sit the supporting layer: version control and CI (GitHub and GitHub Actions in the typical case), a testing framework the suite actually grows in, and browser or end-to-end tooling such as Playwright where the product warrants it.

The test of ownership is the justification. Ask why each tool is in the stack and what it replaced, and a real operator answers in workflow terms: “Claude Code handles implementation from spec because I can review a diff faster than I can type one; the test suite is the gate because my review alone does not scale to the volume the tools produce.” Someone who cannot explain the stack is renting it.

2. Workflow engineering: agentic pipelines for the repeatable

The second capability is the difference between using AI and being augmented by it: leverage that persists. An AI Developer arrives with documented, repeatable workflows, and builds new ones inside your codebase in the first weeks. Concretely, a business should expect:

• Spec-to-implementation pipelines: a feature brief becomes a written technical spec, the spec drives the agentic tool, and the developer reviews the result, so implementation quality does not depend on the day’s typing stamina
• Background agentic runs for well-defined work: migrations, test backfills, mechanical refactors, and integration glue executed end to end by agents while the developer does judgment work
• Codebase research workflows: “where does this behavior live, what would this change break” answered in minutes by directed search rather than hours of reading
• Automation of the team’s manual toil: the internal tool, the data-fixing script, the release checklist turned into a pipeline, the work that never got staffed before

The tell for this competency is Monday morning: if the leverage disappears when the person is out, it was prompting, not engineering.

3. Verification discipline: tests and CI as the merge gate

This is the competency that makes the speed safe, and the one a business should probe hardest. An AI Developer treats the test suite and CI as the merge gate, meaning nothing the AI produced reaches production on the model’s confidence. The observable behaviors:

• Every change lands with tests, and the suite grows with the codebase rather than eroding under velocity
• AI-generated code gets the same review a junior engineer’s code would get, because that is roughly what it is: fast, tireless, and unaccountable
• The developer can name the failure modes they check for: subtly wrong logic that passes superficial reading, hallucinated APIs, tests that assert behavior nobody asked for, and security shortcuts
• Verification is written down: bug fixes and refactors ship with verification logs stating what was checked and how

The METR result described below is the argument for this competency in one number: tools without discipline can make even experienced engineers slower and codebases worse. Unreviewed AI code is how repositories rot.

4. Throughput evidence: a measured multiple, not a vibe

The fourth capability is being able to prove the leverage. An AI Developer can show, with real artifacts, what they ship in a normal week: merged pull requests, the test suite delta, the tools built, the report written. A representative augmented week runs one or two features from ticket to deployed code, plus a batch of fixes and refactors through agentic workflows, plus the written summary, work that traditionally staffed a mid-level developer and a junior.

What this rules out is self-declared productivity. “I am much faster with AI” is not evidence; a merge history is. When Multistaff certifies this competency, it is graded from a live, timed exam on a real codebase, because throughput claims are the easiest part of this category to fake and the easiest to test.

5. Domain depth: senior engineering judgment under the tools

AI multiplies judgment; it cannot supply it. The fifth capability is simply being a senior engineer: knowing which architecture will still be sane in a year, which dependency is a liability, when a passing test suite is testing the wrong thing, and when the correct answer to a feature request is a smaller feature. A fast mediocre developer with AI tools is a mediocre codebase arriving sooner.

In practice this shows up as the ability to write a technical spec a founder can read, to push back on a requirement with reasons, and to make the boring correct choice under deadline pressure. It is graded before leverage is, because leverage on top of shallow judgment compounds the damage.

6. Operating communication: async, outcome-based, readable

The last capability is how the work lands in the business. An AI Developer reports in outcomes: what merged, what it does, what is next, and what is blocked, in writing a non-engineer can follow. Expect short decision writeups when architecture forks, a monthly output report tied to shipped work rather than hours, and an async-first rhythm that does not require standups to stay aligned. Hour-counting and status theater are what this competency rules out.

What good looks like: benchmarks and the honest numbers

The context for all of this is that AI-assisted development is now the norm, not the edge: 76 percent of developers were using or planning to use AI tools in their workflow in Stack Overflow’s 2024 Developer Survey. Adoption is no longer a differentiator. What differentiates is the gap between the ceiling and the median, and that gap is unusually well measured in this function:

• The ceiling: GitHub’s controlled study (Peng et al., 2023) found developers completed a standard implementation task 55 percent faster with an AI pair programmer.
• The floor: a 2025 randomized trial by METR found experienced open source developers were 19 percent slower when using AI casually on codebases they knew deeply, while believing they were faster.

Both numbers are true, and together they define the hiring question. The tools are capable of a real multiple, and casual use of the same tools can produce negative leverage plus misplaced confidence. What good looks like is the difference: written specs before implementation, agentic runs scoped to work the developer can verify, a test suite that grows every week, review on every AI-produced line, and a merge history that shows small-pod output from one person. A business evaluating an AI Developer should ask to see exactly those artifacts, not a tools list.

Where the human still leads

The judgment gate in this function is the merge. No AI system in 2026 should decide, unsupervised, that code ships to production, and a developer who delegates that decision has stopped doing the job. The model does not carry your incident pager, does not know that the elegant refactor breaks a customer contract, and does not bear the consequences of a leaked credential. Shipped code review is human, every time.

Above the merge sits the layer AI cannot see at all: what to build. Which architecture fits where the product is going, which technical debt is worth carrying, when a security tradeoff is acceptable, when the roadmap item should be talked out of existence. An AI Developer is valuable precisely because senior judgment now spends its time on those questions while directed machines handle the volume underneath. Human-led, AI-multiplied is not a slogan in engineering; it is the difference between compounding velocity and compounding rot.

Hiring one, or becoming one

If your backlog is the kind that never gets staffed, the fastest path is a certified operator whose capabilities above were tested live, on a real codebase, before you ever saw their profile: hire an AI Developer. Engagements are fractional or dedicated, with a shortlist in 5 business days and two risk-free weeks.

If you are an engineer who wants to work this way, the same standard is teachable. The Academy’s developer track trains the full system, stack, workflows, verification, and throughput evidence, on real work, and certifies against the same exam: become an AI-trained developer. Either way, the standard is the point: this page is what “AI Developer” should mean, and it is checkable.