All posts
aibuild-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, and a copy-paste starter prompt to build your own with Claude Code.

By Adin Ashby

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 review her work the way I'd review any coworker's, and if it's good, it ships.

Ada is not a product you can buy. She's a system I built: an AI model running in a loop, with rules, checklists, and guardrails around it. I'm a software engineer and getting her to actually work took months. Not months of writing code. Months of learning how to delegate to an AI without everything quietly falling apart.

This post is the whole method. The first half works whether you write code or not. The second half is the technical setup for people who want to build the real thing.

The method

Everything below came from something going wrong first. That's the honest version of "best practices."

1. Write specs, not wishes

The single biggest difference between AI output that's useful and AI output that wastes your evening is 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 delegate. That rule alone will save you more time than any tool.

2. Cut the work small

Ada never gets "build the billing system." She gets one bounded slice at a time, each with its own spec, each finishable in one run. Small tasks fail small. Big tasks fail big, and they fail in ways you discover three days later.

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

3. Build gates the AI cannot skip

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

Before anything she writes counts as done, it has to pass the test suite, the type checker, the linter, and a full production build. Automatically. Every time. She cannot mark her own homework.

The non-technical version of this: never let AI output go straight to the destination. There's always a checkpoint the output must 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 same way I'd review a pull request from a human teammate. Sometimes it's great. Sometimes I send it back with notes. The review is not optional and it never will be.

The trap with AI is that the output always looks confident. Confidence is not correctness. 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 went wrong, why, and what rule prevents it next time. Those notes feed back into Ada's standing instructions. She's better this month than last month, not because the AI model changed, but because the instructions did.

This is the part almost everyone skips, and it's the part 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. No exceptions, no automation around it.

Whatever your equivalent 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

Here's what Ada physically is:

  • The brain: Claude, driven by Claude Code, Anthropic's agentic CLI. Any capable agentic coding tool can fill this slot. The loop matters more than the brand.
  • The queue: 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: a PowerShell script that watches the queue, picks up the next task, hands it to the AI with the spec and plan, and lets it work on its own branch.
  • The gates: unit tests, TypeScript strict mode, ESLint, and a full production build. All must pass before the work is considered done.
  • The ping: a Telegram bot. Ada messages me when she finishes, and messages me differently when she fails. The 3am buzz is that bot.
  • The cost: a Claude subscription plus effectively zero infrastructure. The loop runs on my own machine.

That's it. There is no secret product. The magic is boring: specs in, gates on, review after.

Build your starter version in one afternoon

Everything above is the theory. Here's the hands-on version. 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 the copy-paste: you are not building overnight-autonomous Ada today. You're building the supervised starter. One task at a time, gates on, you watching. That's not the compromise version, that IS the system. The overnight part is a scheduling detail I added only 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 the project's tests, type check, lint, and build. All must pass. Record the results in the task's notes.
  * 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. Show me the created files and stop.

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 first 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. That's not paranoia, it's calibration. You're learning what it's reliably good at, and it's accumulating rules in LEARNINGS.md.

Step 4. Review the branch like a PR. Read the diff. Good? You merge it yourself. Not good? Notes into the spec, task back in the queue, run it again.

Step 5. Graduate slowly. When ten tasks in a row have been boring, queue more at once. When that's boring, look up your CLI's headless mode (Claude Code has one), put the run command on a schedule, and add a notification so it pings you when a run finishes. Congratulations, you've arrived at the 3am buzz. Every guardrail you added on the way up is the reason that buzz is exciting instead of terrifying.

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 detects 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 it taught me the rule: the system 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 verifies by checking what's actually running, and kills by process ID.

Notice the pattern: none of these were AI failures. They were system failures. The AI was fine. My guardrails had holes, and every hole became a rule.

If you don't write code

You can run the same method with nothing but a chat AI and 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 with your name on it. The AI is confident either way. You're the one who can tell.

You won't get the 3am shipping. You'll get the thing that actually matters: leverage that compounds, because the quality of your delegation keeps improving.

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, including Ada's wins and faceplants, on Instagram at @adinashby. 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.