You have a working product. Customers use it. Most of the code was written by AI coding agents, directed by you or by whoever built it. Now the product needs someone in-house who owns that code every day.

That first hire is a different job than it used to be. It is less about writing a product from nothing and more about understanding one that already exists, much of which nobody typed by hand.

I build v1s this way, and handing them to the team that comes next is part of the work. Here is how I would approach the hire.

Hire someone who reads code well

The core skill is reading unfamiliar code quickly and judging it. Agents produce a lot of plausible code. Your engineer's job is to see what is wrong with it: the missing permission check, the untested edge case, the shortcut that breaks next month.

What I would look for:

  • A generalist. A first engineer touches the interface, the server, the database and the deployment, often in one day.
  • Someone who uses coding agents and reviews them. Tools like Claude Code, Cursor and Devin should feel normal to them, and agent output should get the same scrutiny as a colleague's.
  • Security instincts. Who can see what, and where the keys live.
  • Product sense. They ask what the user is trying to do before asking how to build it.
  • They write things down.

Be wary of two types. One wants to rewrite everything before reading it. The other merges whatever the agent produces. Google's code review guide has a principle I like here: reviewers should favor approving a change once it definitely improves the overall health of the code, even if it is not perfect. There is no perfect code, only better code. You want someone who improves what is there.

Prepare the handover before they start

A new engineer's first week finds every gap in your documentation. Close the obvious ones first:

  • The repository in the company's own organization, not a personal account. GitHub recommends at least two owners per organization, and your new engineer is a good second.
  • Setup instructions that work on a clean machine. Try them yourself.
  • The spec and the decision log, including the options you rejected and why.
  • The rules your agents worked under, and the prompts the product uses, in the repository. I wrote about the rules my coding agents work under.
  • Tests that run on every change, plus an honest note on what they do not cover.
  • Every account and key: hosting, database, domain, email, app stores, analytics, AI providers. Who owns each one and where the keys are stored.
  • Known limitations: what is fragile, unfinished or deliberately simple.
  • Seed data and a test environment, so they never need real customer records to learn the product.

It is nearly the same list a buyer checks in technical due diligence.

A paid trial task that shows the real job

Interviews tell you how someone talks about code. A short trial shows how they work with yours. Pay for it, keep it small and time-boxed, and do not use it to get real work done for free.

Give them a copy of the repository with seed data, under an NDA if you need one, and three tasks:

  1. Review an agent-written pull request. Pick or plant one with real problems: a permission check that is missing, an untested edge case, a confusing name. Ask for written review comments.
  2. Fix one small bug, with a test, through your normal process, including a preview.
  3. Write one page: what they would change first, what they would leave alone and what they still need to know.

Then look at how they worked, not just the result. Did they read before changing things? Did they find the permission problem? Did they check the agent's work, or trust it? Could you act on their notes?

The first 30 days

Week one: get it running. They set the project up from your instructions alone, fixing whatever did not work, read the spec and ship one small change through tests, preview and release.

Week two: own review. Every change goes through them, whether a person or an agent wrote it. GitHub's protected branches can require an approving review and passing checks before anything merges, so the rule does not depend on memory.

Weeks three and four: own operations and write it down. They take over monitoring, alerts and runbooks. Then they write a short note on the codebase: what is fragile, untested or risky, and what they would fix first. Together you pick what goes into the next month.

One rule for the whole month: no rewrites. Improvements, yes. Replacing a piece of the product needs a written case and your agreement.

Stay in the product decisions

One common mistake is the founder quietly stepping back from the product because someone else now owns the code. The opposite mistake is the founder who keeps prompting agents straight into the repository, around the new engineer.

A clear split helps:

  • You own what and why. Who it is for, what it does, what comes next.
  • They own how. Architecture, tools, quality and how long things take.
  • The spec stays the source of truth. Changes to what the product does go through the spec, not a chat message to an agent.
  • Every change takes the same path, including the ones you make. Same review, same preview, same tests.
  • Review a working preview every week, not a status update, and keep sitting in on tests with real users.
  • Ask for trade-offs, then decide. A good engineer tells you what something costs and what it risks. The decision is still yours.

If you would rather not make this hire alone, one pattern I suggest is to do both in sequence: I build the v1, you hire, and I stay on for a while to lead the new team through the next releases.

A checklist before you post the role

  1. Describe the job as reading and reviewing code, not only writing it.
  2. Put the repository, accounts and keys in the company's name, with a second owner.
  3. Get the setup instructions, spec, agent rules and limitations into the repository.
  4. Prepare a paid, time-boxed trial built around an agent's pull request.
  5. Plan the first 30 days, with no rewrites.
  6. Agree who owns what, and who owns how.

If you have an AI-built v1 and are about to hire your first engineer, email me with where the product is today. I can help you prepare the handover and design the trial.