What a Fractional Chief AI Officer Does for Dev Teams

TL;DR: For a small engineering team, a fractional Chief AI Officer is not an AI strategy deck or a governance board. The job is the engineers’ daily workflow: which coding agents run on which repos, how their output gets reviewed, what controls and evidence exist, and whether any of it is measurably helping. Four jobs, a 30-day plan, three metrics. The rule underneath it: standardize the workflow, the controls and the measurements, and leave the vendor open, because nobody knows who wins. This is a new offer, and no client has bought it yet.

What does a fractional Chief AI Officer do for a small engineering team?

They own how AI coding agents enter your codebase: the workflow, the review rule, the controls and the measurement, part-time, so a 5 to 20 person team gets that leadership without a full-time executive. That’s the whole job at this size. Everything else on the typical role description is either someone else’s job or doesn’t exist yet at your company.

This isn’t a buyer’s guide. I run four to seven agent sessions in parallel through a normal day, as I laid out in my daily agentic workflow, and that practice is what everything below is built on. I offer vCISO and fractional CTO work, which is where the controls half of this comes from.

Why doesn’t the enterprise definition fit a 5 to 20 person team?

Because the enterprise version of the role is built around an organization you don’t have yet. Search the title and the definitions are written for larger companies: one widely cited playbook has the role own AI strategy and model governance, sign model-risk policies, and chair the AI governance board, at Series B and C companies. A 12-person startup has no board to govern and no policy backlog. It has twelve engineers who each installed a different tool, with different permissions, on different repos, and a founder who can’t answer “who is using what?”

At that size the AI question isn’t strategic. It’s operational and it’s daily. Which agent does an engineer open on Monday morning? What is it allowed to touch? Who reads what it wrote before it ships? Those are management questions, not policy questions, and I’ve argued before that agents don’t need better prompts, they need managers. An agent arrives without the queue, the reviewer and the manager a new hire comes wrapped in. For a small team, building that layer is the part-time role this post is about.

What are the four jobs?

Standardize the workflow, enforce a review rule, put controls and evidence in place, and measure.

1. Standardize the workflow, not the vendor. The team agrees on how work moves: what gets delegated to a background agent, what gets done pair-style with one, and what gets adversarially reviewed. In my own practice that’s three modes (delegate, collaborate, verify), and the failure that post names first is using the wrong mode for the task. It also covers the handoff format, where a human writes the curated context when one agent’s output feeds the next, and a team instructions file, so every session starts from the same written rules.

2. Review discipline. The rule I use and would put in front of a team: agents work on isolated branches, never main, and the human engineer is the one who merges. Review means the tests always, and the diff where the risk is: auth, data, money. The reason is that agent code can compile, read reasonably and still be subtly wrong in ways the agent can’t detect.

3. Controls and evidence. Permissions the developer can’t quietly widen, an allowlist for MCP servers, an audit trail, and one page you can hand to a customer’s security reviewer. I describe these as categories on purpose, because every harness implements them differently. Claude Code is the one I’ve documented: its managed settings apply above every other level, so no user, project, local or command-line value overrides them, and the SOC 2 evidence map shows the telemetry and artifacts that come with them. For any other harness, I’d map the same categories before you lean on it.

4. Measurement. If you can’t tell whether the agents are helping, you’re running on feelings. More on this below.

What does the first 30 days look like?

Four weeks, one theme each, and every week ends in a written artifact.

Week 1, inventory. Which AI tools the team uses, who uses them, on which repos, and with what permissions. The output is a one-page current state. I expect it to surprise the founder, because adoption at this size tends to happen engineer by engineer and nobody writes it down.

Week 2, the standard. Choose the agents and models the team will support, write the review rule (agents on branches, a human merges), define the handoff format, and draft the team instructions file. For that last piece, what a good AGENTS.md looks like is the best worked example I’ve read: a short router that points at task guides and keeps procedure separate from reference.

Week 3, controls. Managed permission settings, an MCP allowlist, telemetry switched on, and the evidence page for security reviews. On Claude Code that means managed settings. On another harness it means that harness’s equivalent, or a written note that it doesn’t have one yet.

Week 4, pilot and measure. Two or three engineers use the standard on real work. They keep a written log of what the agents got wrong. I pull baselines from your existing PR and ticket history, so the pilot has something to beat. At the end there’s a go or no-go for a team-wide rollout, with the log as the reason, not a vibe.

What gets measured?

Three numbers: PR review time, PRs merged per week, and tickets closed. The engagement baselines them in week 4 and tracks them after.

I chose those three because they sit downstream of the work and are already in your tooling. Seats purchased and prompts sent aren’t on the list. They measure spend and activity, not output, and a team can buy every seat and still be slower. Review time is the one I’d watch hardest. If agents produce more code and review time doubles, you’ve moved the bottleneck, not removed it. That’s the “slop” pattern from the workflow post: lots of code committed, a team that feels productive, and a codebase that’s worse three weeks later. Spend is a separate question, and I put real numbers on what my team’s agents actually consume.

The log of what the agents got wrong is the qualitative companion to the numbers. In my own use of an adversarial review agent, I dismiss roughly 60 to 70 percent of its findings as noise, and the rest become real review comments. That ratio is how I know the agent is a first pass and not a verdict, and a team should learn its own ratio the same way.

Why should the engagement be model-agnostic?

Because nobody knows which harness or model wins, and standardizing on one now risks picking the eventual loser. My read is that Codex and Claude Code keep trading the top spot, and OpenCode and others are credible too. I don’t expect any ranking to hold. Your team picks the harness and the model; I’d standardize everything around them.

The review rule is the same whichever agent wrote the branch, and so are the handoff format and the three metrics. If you switch tools in six months, the main thing that changes is which settings file implements the controls.

Portable instructions are the practical piece. The team instructions file should be an AGENTS.md, because agents.md lists Codex, opencode, Cursor, Gemini CLI, Aider, Zed and many other tools as compatible with it, so one file serves whichever harness an engineer opens. Even where a tool wants its own filename, the Omarchy repo I read points its CLAUDE.md at AGENTS.md with a single line.

When is a fractional role the right size, and when do you hire full-time?

Fractional is right when the work is leadership and standards, not 40 hours a week of building. That’s the same reasoning I laid out for security leadership in the vCISO math for AI founders: a small company has a few hours a month of executive-level work and a lot of execution its own engineers should be doing. Choosing the standard, setting the review rule and wiring the controls is a few hours of senior judgment. Your engineers do the daily work inside it.

This role doesn’t write your product code, run your models in production or sit in your Slack all day. Four to eight hours a month is four to eight hours.

A full-time AI lead makes sense when the AI work stops being an engineering workflow question and becomes a product and platform of its own: you’re training or fine-tuning models, you have a team of AI engineers who need a manager, or the work is consistently past what a few hours a month can carry. At that point you’ve outgrown the fractional version and you should hire for it. If you’re a founder trying to get five or fifteen engineers onto coding agents without a mess, you’re still in fractional territory.

What I’d do first, with or without me

Run the week 1 inventory yourself. Ask every engineer which AI tools they use, on which repos, with what access, and write it on one page. Then write the review rule in one sentence: agents work on branches, a human merges. That’s an afternoon. For the copyable versions of the rule, the instructions file and the baseline commands, see how to roll out coding agents to an engineering team.

If the page comes back messier than you expected, that’s the work, and it’s what the Fractional Chief AI Officer engagement is for, and the scope and pricing are on that page. It’s a new offer and nobody has bought it yet, so there are no client stories here and I won’t invent any. What exists is the way I work every day and the vCISO and fractional-CTO background I bring to the controls side, fitted to your team.

Read this next: my daily agentic workflow, the practice this whole role is built on.