All posts
9 min readaibuild-in-publicfounder-journey

How I Built Ada, My AI Employee (And How You Could Build Yours)

The exact system behind Ada, the AI teammate that ships code for Classentra while I sleep: the spec format, the quality gates, the review loop, what broke.

By Adin Ashby

The short version: write specs with a "done means" line, keep tasks small, put gates between the AI and anything real, review its work like a coworker's, feed every failure back into the instructions, and keep production behind a human. The rest of the post is what that looks like in practice, plus a prompt that scaffolds the whole thing for you.

Most nights my phone buzzes somewhere around 3am. It's not a person. It's Ada, telling me she finished a feature, ran the tests, and pushed the code for review. I go back to sleep. In the morning I read her work the way I'd read any coworker's, and if it's good, it ships.

Ada isn't something you can buy. She's a system I built: an AI model running inside a loop, with guardrails I added one at a time as things went wrong. I'm a software engineer and getting her to actually work took months. Not months of writing code. Months of figuring out how to delegate to an AI without things quietly falling apart.

This post is the whole method. The first half works whether you write code or not. The second half is the hands-on setup, including a prompt you can paste into Claude Code to scaffold your own starter version.

The method

Every rule below exists because something went wrong without it.

1. Write specs, not wishes

The difference between AI output that's useful and AI output that wastes your evening is almost always the instruction you gave it.

A wish looks like this: "add validation to the signup form."

A spec looks like this: "invalid emails and empty passwords must be rejected with visible error messages. Write tests that submit those inputs first, then make the tests pass. Done means: all tests green, no other files changed."

Every task Ada picks up has a spec with a "done means" line. If I can't write that line, the task isn't ready to hand over.

2. Cut the work small

Ada never gets "build the billing system." She gets one bounded slice at a time, each one finishable in a single run. Small tasks fail small. Big ones fail in ways you only discover three days later.

If you're delegating anything to an AI, task size is your main risk dial. Turn it down.

3. Build gates the AI cannot skip

I don't trust Ada. I trust the gates.

Nothing she writes counts as done until it passes the test suite, the type checker, the linter, and a full production build. They run every time, and she doesn't get to mark her own homework.

If you're not technical, the same rule looks like this: AI output never goes straight to the destination. There's always a checkpoint it has to pass through that the AI doesn't control. A checklist, a second read, a test send to yourself before the real send.

4. Review like it's a coworker, not magic

Every morning I read what Ada shipped overnight, line by line, the way I'd read a pull request from a human teammate. Sometimes it's great. Sometimes I send it back with notes. The review is never optional.

AI output looks confident whether or not it's right. Review is where you catch the difference.

5. Keep a learnings log

When something goes wrong, I don't just fix it. I write down what happened, why, and what rule would have prevented it. Those notes feed back into Ada's standing instructions. She's better this month than she was last month because the instructions got better, not because the model did.

Almost everyone skips this step. It's the one that compounds.

6. Keep the final door human

Ada can ship to my staging environment all night long. Production waits for one specific word from me, and nothing automates around that.

Whatever your version of production is, your published post, your client deliverable, your live course page, keep a human hand on that last door.

The actual stack, for the builders

What Ada physically is:

  • The brain is Claude, driven by Claude Code, Anthropic's agentic CLI. Any capable agentic coding tool could fill this slot. The loop matters more than the brand.
  • The queue is a markdown file listing tasks. Each task points at a spec (what and why, with the "done means" criteria) and a plan (how, step by step). I write these during the day.
  • The loop is a PowerShell script that watches the queue, picks up the next task, and hands it to the AI on its own branch.
  • The gates are unit tests, TypeScript strict mode, ESLint, and a full production build. All four have to pass before anything counts as done.
  • The ping is a Telegram bot. Ada messages me when she finishes, and messages me differently when she fails. The 3am buzz is that bot.
  • The cost is a Claude subscription plus roughly zero infrastructure. The loop runs on my own machine.

There's no secret product in there. Specs in, gates on, review after.

Build your starter version in one afternoon

You need three things: a project that lives in git, Claude Code or any agentic CLI that can read files and run commands, and about an hour.

One warning before you paste anything: you're not building overnight-autonomous Ada today. You're building the supervised starter. One task at a time, gates on, you watching. That's the same system I still run. The overnight part is a scheduling detail I only added after months of the supervised loop being boring and reliable.

Step 1. Scaffold the system. Open Claude Code inside your project and paste this:

Set up a minimal "AI teammate" system in this repository. Scaffolding only, no feature work yet.
 
1. Detect this project's tooling: test command, type check, lint, build. List what you found and wait for my confirmation before creating anything.
 
2. After I confirm, create an ai-team/ folder with these files:
 
- QUEUE.md: a task table with columns: id, title, spec file, status (queued / in-progress / done / failed), branch, notes.
 
- specs/TEMPLATE.md: a spec template with sections: Goal (one paragraph), Done means (verifiable criteria a command or test can prove), Out of scope, How to verify (exact commands).
 
- RULES.md with these standing rules:
  * One task at a time, always from QUEUE.md, always following its spec file.
  * Work on a fresh branch named ai/<task-id>. Never commit to the default branch. Never push, never merge, never touch remotes. The human reviews and merges.
  * Before marking a task done, run every gate this project actually has from the step-1 detection (tests, type check, lint, build). All existing gates must pass. Record each result in the task's notes, and record any gate the project doesn't have as "N/A (not configured)" rather than skipping it silently.
  * If blocked after 3 materially different attempts, stop. Mark the task failed with a note on what was tried.
  * Never run destructive commands. Never delete or modify files outside the spec's scope. List any new dependency in the notes before installing it.
  * On every failure, append a dated entry to ai-team/LEARNINGS.md: what went wrong and what rule would have prevented it.
 
- LEARNINGS.md: empty, with a one-line header explaining its purpose.
 
3. Commit the ai-team/ folder to the current branch with the message "chore: add ai-team scaffolding", show me the created files, and stop.

Two things to expect when you run it. It pauses after step 1 and waits for you to reply, that's deliberate, it's the first human checkpoint. And if your project only has some of the four gates, that's fine, the rules bind to whatever step 1 actually found.

Step 2. Write your first spec. Copy specs/TEMPLATE.md and fill it in for something small and annoying you've been putting off. Small matters here: if it fails, you should lose minutes, not your weekend. Add a row to QUEUE.md.

Step 3. Run one task. Start a fresh session and paste:

Read ai-team/RULES.md and follow it exactly. Pick the topmost queued task in ai-team/QUEUE.md, mark it in-progress, and do it on its own branch per the rules. When the gates pass, mark it done, summarize what you changed and why, and stop for my review.

Watch it work the first few times. You're learning what it's reliably good at, and it's building up its own rules in LEARNINGS.md.

Step 4. Review the branch like a PR. Read the diff. If it's good, you merge it yourself. If it isn't, add notes to the spec, put the task back in the queue, and run it again.

Step 5. Graduate slowly. When ten tasks in a row have been boring, queue more at once. When that gets boring too, look up your CLI's headless mode (Claude Code has one), put the run command on a schedule, and add a notification for when a run finishes.

The Telegram version of that notification, since people always ask: message @BotFather on Telegram, send /newbot, and it hands you a bot token. Send your new bot any message from your own account, then open this URL in a browser and copy the chat.id number out of the response:

https://api.telegram.org/bot<YOUR_TOKEN>/getUpdates

From then on, one line at the end of your run script is the entire notification system:

curl -s "https://api.telegram.org/bot<YOUR_TOKEN>/sendMessage" -d chat_id=<YOUR_CHAT_ID> -d text="Ada: run finished"

That's the 3am buzz, and it only feels good because of every guardrail you added on the way up.

What broke along the way

You should know what this looks like when it goes wrong, because it will.

The overnight shutdown. My machine once shut down mid-run and orphaned Ada's work in a half-finished state. Now the loop checks for stale runs on startup and recovers them instead of pretending they never happened.

The wrong branch. Early on, the loop had no branch awareness. One night the previous task's branch had been cleaned up, and Ada quietly committed a whole feature to the wrong branch, skipping my review gate entirely. Nothing bad shipped, but the system now checks where it's standing before its first commit, every time.

The zombie processes. Dev servers that never died stacked up until the machine crawled. Now nothing gets assumed dead. The loop checks what's actually running and kills by process ID.

None of these were AI failures. My guardrails had holes, the holes showed up as incidents, and every incident became a rule.

If you don't write code

You can run the same method with nothing but a chat AI and some discipline:

  1. Keep a standing instructions document: who you are, what good output looks like, what to never do. Paste it into every project, or use a tool that persists it.
  2. Write a spec for every real task, with a "done means" line.
  3. Keep tasks small enough that one bad output costs you minutes, not days.
  4. Put a checkpoint between AI output and the real world. Always.
  5. Keep a running note of every miss and what instruction would have prevented it. Feed it back in.
  6. Review everything that goes out with your name on it. The AI sounds confident either way. You're the one who can tell.

You won't get the 3am shipping. You'll get the part that matters more: delegation that keeps improving, because you keep feeding the misses back in.

Why I'm telling you this

I build Classentra in public. It's a live teaching platform for educators and creators, and I share the day-to-day on Instagram at @adinashby, including Ada's wins and her faceplants. If you got here from a reel, this is the playbook I promised.

Come tell me what you'd hand an AI teammate first. I answer my own DMs.