Start here
The first 30 days decide whether your new engineer builds what you need or what they assume you need.
When you can't read code, those 30 days are hard to judge. The new hire looks busy, the updates sound good, and the first real signal comes months later, when a feature you paid for doesn't work the way customers expect.
AI coding agents changed the first week. A new engineer can ask an agent to explain an unfamiliar codebase and get a useful answer in minutes, and the agent can write a first version of a change the same day. That's good. It also means a new hire can produce a lot of code before they understand your product, and you can't tell the two apart from the outside.
The agent speeds up whatever habits are already there. Clear context, small changes, tests, and human review make it faster. Missing context and unchecked changes make it faster too, in the wrong direction.
So this plan does four things:
- Gives the new hire your product and customer context in writing, so they and their AI agent start from the same facts.
- Keeps every account and every important decision on your side.
- Puts a small, checkable change in front of customers in the first week.
- Checks progress against outcomes you can see, every week, with someone who can read the code.
It works for an employee, a contractor, or a new agency. Where the steps differ, they say so.
Three terms come up below. A repository is the place where your product's code and its history live. A review is when someone other than the author reads a change before it reaches customers.
A technical reviewer is a senior engineer with no stake in the hire: an advisor, a part-time Fractional CTO, or a senior engineer from your network. Pay them for their time. Every step below that checks code goes through them.
1. Keep the keys
Own every account before anyone starts, because the person who holds the accounts holds the product.
List every service your product runs on: the code repository, hosting, the domain, the database, payments, email, analytics, and any AI services billed to you. Each one should be in an account owned by your company, with your company card and an email address you control.
Then give the new hire their own login on each one they need, with the least access their first tasks require. Never share your login, and never let them create a company account in their own name. If you're switching agencies, move every account into your company's name before the old agency's last day.
Ask your technical reviewer to set the access levels. You decide who gets access; they know what each level allows.
Done looks like: a list of every service, each owned by your company, and a separate login for the new hire with only the access their first tasks need.
2. Write the context down
Write down what you know about the product and customers, because the new hire and their AI agent can only use what they can read.
The Documentation-as-Code Playbook shows how to keep this kind of knowledge up to date.
You don't need much. One page, in plain words, answering these questions:
- Who are the customers, and what problem does the product solve for them?
- What do customers use the most, and what do they complain about?
- What must never break, such as sign-up, payments, or a customer's data?
- What are the outcomes for the first 30 days?
- Who decides what, and who to ask when something is unclear?
Then ask your technical reviewer or the new hire to add a short instructions file to the repository. AI coding agents read this file at the start of every session. Claude Code reads CLAUDE.md, and many other agents read AGENTS.md. It should say how to run the product, how to run the tests, and what the agent must not touch. Keep it short: a long file is harder for the agent to follow.
Done looks like: a one-page product brief the new hire reads before day one, and an instructions file in the repository.
3. Set the AI rules
Write the rules for AI agents before day one, because the new hire will use one on day one.
The Agent Permissions Playbook covers what agents may do on their own and what needs a person.
Encourage the new hire to use AI. It's part of how a modern engineer works, and banning it slows them down without making anything safer. Write down four rules instead:
- The engineer answers for every change they deliver, whatever helped them write it.
- An agent never changes the live product, customer data, or payments without a person approving.
- Every change goes through a review before customers see it.
- Customer data and secrets never go into an AI service your company hasn't approved.
If the new hire works through an agency, send these rules to the agency too, and ask them to confirm in writing.
Done looks like: four written rules the new hire has read and agreed to.
4. Let the agent explain the codebase
Ask the new hire to learn the codebase with their AI agent on day one, and then check what they learned with a person.
An agent can read the whole repository and answer questions about it in a way no single document can. Anthropic's own guidance for Claude Code suggests this as a way to get to know an unfamiliar codebase. It saves days of reading.
The agent can still be wrong, and it can't tell the new hire why the product is built the way it is. So on day one, ask the new hire to write a short note answering four questions, with the agent's help:
- How is the product built, in plain words?
- Where would a change to sign-up, or another feature customers use the most, happen?
- What looks fragile or unclear?
- What do they want to ask the person who built it?
On day two, they go through the note with your technical reviewer, with the previous developer joining if they're still around. The reviewer corrects what the agent got wrong and answers the questions.
Done looks like: a written note about the codebase, checked by your technical reviewer by the end of day two.
5. Ship something small in the first week
Put a small, checkable change in front of customers in the first week, because it tests the whole path from idea to customer.
Choose two or three small tasks before day one. A good first task is a real improvement a customer would notice, can be finished in a day or two, and has a clear way to check it's right. Fixing a confusing error message, adding a missing field to an export, or repairing a known bug on a page customers use are all good examples. A redesign or a new feature isn't.
For each task, write what done means in one sentence a customer could understand. Ask the new hire to add a test that proves it works, then have your technical reviewer review the change before it goes live.
The point isn't the task. It's to prove that the new hire can run the product, change it, test it, get a review, and release it safely. Anything that blocks them along the way is something to fix now, while the change is small.
Done looks like: at least one change live for customers by the end of the first week, with a test and a review.
6. Protect their learning
Ask the new hire to understand each change they deliver, because an engineer who can't explain your product can't keep it working.
In a study Anthropic published on AI and learning, developers learning a new coding library with AI help scored 50% on a quiz afterward, against 67% for developers who wrote the code by hand. The developers who used the AI to ask questions about how things worked, rather than to write the answer, tended to understand more. It's one study with a small group, but the direction matches what I see.
So make understanding part of the job. In each weekly check-in, ask the new hire to explain one change they made: what it does, why they did it that way, and what would break if it were wrong. If they can't, the change isn't finished, however well it works.
Done looks like: every week, the new hire explains one of their changes in plain words.
7. Judge what customers can use
Judge the first 30 days by what customers can use, because AI makes speed hard to see.
In 2025, the research group METR measured experienced developers working in codebases they knew well, with and without AI. They expected AI to make them faster, still believed afterward that it had, and were measured 19% slower. The study measured experienced developers, so it says nothing direct about new hires. The lesson still holds: how fast something felt is weak evidence.
Once a week, meet for 30 minutes. Look at what changed for customers, and open it in the product yourself. Ask your technical reviewer to read the week's changes and tell you in a few lines whether they're sound.
Done looks like: a short weekly note saying what customers can now do, and your reviewer's view of the code.
8. Review at 30 days
Write a 30-day review against the outcomes you set, because it's the first fair point to decide whether this is working.
Go through each outcome from the product brief. For each one, write whether it was met, the evidence, and what's next. Ask the new hire for their view first, then add yours and your reviewer's.
Then set the outcomes for the next 60 days. By now the new hire should be ready for larger work, such as a feature customers asked for or a part of the product that needs rebuilding.
If the outcomes weren't met, find out why before you decide anything. Unclear outcomes, missing access, or a reviewer who wasn't available are yours to fix. If it's the new hire, the 30-day review is when to say so, clearly and in writing.
Done looks like: a written review shared with the new hire, and outcomes for the next 60 days.
Working templates
Before day one
- Every service is in an account your company owns.
- The new hire has a separate login on each service they need, with limited access.
- The one-page product brief is written.
- An instructions file for AI agents is in the repository.
- The four AI rules are written down and sent to the new hire.
- Two or three small first tasks are chosen, each with one sentence saying what done means.
- A technical reviewer agreed to review changes and attend the 30-day review.
30-day plan
| When | What happens | Evidence |
|---|---|---|
| Day 1 | The new hire reads the brief and the AI rules, sets up the product, and learns the codebase with their agent | A short note about the codebase |
| Day 2 | Your technical reviewer goes through the note with them | The note, corrected |
| Week 1 | The first small change goes live | A change with a test and a review |
| Weeks 2 to 4 | Larger tasks tied to the 30-day outcomes, with a 30-minute check-in each week | A weekly note on what customers can now do |
| Day 30 | The 30-day review | A written review and the next 60 days' outcomes |
Weekly check-in questions
| Question | A good answer sounds like | A worrying answer sounds like |
|---|---|---|
| What can customers do now that they couldn't last week? | "They can export invoices as a spreadsheet. Two customers have used it." | "I did a lot of work on the backend." |
| Explain one change you made. | "The export timed out on large accounts, so it now runs in the background and emails a link. The test uses a large account." | "The AI wrote it, and the tests pass." |
| Where was the AI wrong this week? | "It suggested changing how we store prices. I didn't, because it would have broken old invoices." | "It wasn't, it's really good now." |
| What's blocking you? | "I can't test payments without a test account. Can you create one?" | "Nothing," every week, with little shipped. |
Start before day one
Move every account into your company's name and write the one-page product brief. Both take an afternoon, and everything else in this plan builds on them.
If your first engineer or a new agency starts soon and nobody on your side can review their work, that's part of what I do as a part-time Fractional CTO.