I built a second brain for my codebase so releases keep shipping while I'm away.
In a July 2026 live stream I walked through the loop I built to take a client's bug report to a tested release with as little of my time as possible. I was about to leave on vacation, and I wanted the code to keep shipping without me at the desk.
The business case
As a solo developer, the hardest part of my day was deciding what to work on. Which bug to fix, which build to tune, what to deploy, what to test. In July 2026 I said every team faces the same problem of moving faster without breaking anything.
My goal was blunt. As the developer and the business owner, I should be able to step away from the computer for a week and still ship code reliably, done the way I'd do it. My release pace away from the desk should match my pace at it. That's what the second brain is for.
Codex, Claude and the Sentry plugin change fast, so read this as where my setup stood in July 2026.
Why a second brain
A second brain means moving what's in your head, your notes, SOPs and workflows, into a system so you have room to think. I'd used OneNote for years and started and quit second-brain systems many times. The notes went stale, and nobody wants to go back and update old notes.
AI changed that for me. I put a process in markdown, let the AI run it, and have it improve the process over time while I monitor it. Then I pointed the idea at code. The loop is: watch the code, decide what to work on, act on it, verify it, and learn from the result.
Bug report to issue
On stream I filed a real request from my app's demo account. I dictated it on the communications page: add a filter for incoming and outgoing calls, and collapse the crowded filters behind an icon. An AI cleaned up my rough notes and sent them with a screenshot.
The intake AI worked out what the request was about and gave it a priority of P1, P2 or P3. It classified the module, emailed the client a thank-you, and opened a GitHub issue. This one came back P3, with reasons: a new filtering feature, not blocking, not a defect. Nothing moves until the AI justifies its decision.
It also wasn't set to run on its own. My rule is that any UI change or client feature request gets my look first, so a random request can't get shipped. The issue still arrived with a diagnosis, acceptance criteria, test suggestions and a draft reply for the client.
The two-hour Codex loop
Before the trip I moved these workflows from my laptop to a Mac mini. In Codex I run what I call the two-hourly engineer loop. Every two hours it takes the top 10 GitHub issues, client items and P1 blockers and bugs first. It reads the docs for that module, then works the problem. A request that lands at noon is being worked by 2 PM.
Anything that needs me goes to a "needs code validation" column on my GitHub board. Everything else that passes the filters keeps moving.
Jump to
- 0:00 Intro and the vacation goal
- 3:30 What a second brain is and why it fits code
- 10:56 The loop in practice and real release volume
- 23:03 Live demo: bug report to classified GitHub issue
- 33:20 The two-hourly Codex engineer loop
- 40:12 Guardrails: locked tests, docs and Claude audits
- 1:00:42 Learning: Sentry errors become fixes and tests
- 1:15:09 Recap: the full loop and building in-app
I walk through the whole loop on screen in the full video on my channel: Second brain for your codebase on YouTube.
Three layers of checks
A viewer asked how I stop the AI from going in circles. My answer: AI is non-deterministic and the models keep changing, so it will never be flawless, and a person has to step in at some point. You handle that with layers.
Layer one is deterministic tests in GitHub Actions: API, unit and end-to-end. They were first written by hand, then improved by AI. They're carved in stone. The AI can't change them, and if anything fails, the release stops. The end-to-end test is a robot that clicks through the app and takes screenshots. On a mismatch it files a ticket with the screenshot. The modules I guard hardest are login, billing and payments, email, and PDF generation.
Layer two is documentation. Early on, the AI invented its own approach to problems. Keeping it focused on one module and that module's docs cut that down a lot. Getting there took me about a year of tuning.
Layer three is Claude. It runs twice a day, takes the tickets Codex worked, and audits them against the original requirements instead of what the AI thought it should do. One AI checking another lowers the chance of a miss without removing it. Don't use a cheap model here. The context is large: the original issue, the docs, and everything the first AI did.
Every Codex report has to open with a plain-language summary of the problem, the root cause and the fix, then list the changed files. If I wonder why a file changed, I step in.
Sentry closes the loop
Tests catch what you predicted. Sentry catches what customers hit after release: failed logins, HTTP 500 errors, auth errors. I'm not affiliated with Sentry, and PostHog is an alternative. I installed the Sentry plugin in Codex, then asked "@Sentry, can you view the latest issues and fix them?" It pulls the issues, finds the code, fixes them and sends each fix back through the same cycle, twice a day.
One more rule: every Sentry fix also gets a new test so the problem can't come back. Each pass makes the suite stricter. If anything breaks in GitHub Actions, everything stops until a person steps in. That's what gave me the confidence to take time away.
My daily review list
Each run ends with a summary of what was worked, what's blocked and what's waiting on me. That's my to-do list. The AI tells me what to do now. On a family hiking trip, Claude ran on its overnight schedule and my review list was waiting when I woke up. By the time I see an item, the AIs have already tested the work. I leave a comment on the ticket and tell the AI to read the latest comment.
I build new features the same way now. I open a bug report inside the app, describe the change, and let the loop build it.
Build it piece by piece
I used to tune out the talk about AI loops. Building this one a piece at a time is what made it click for me. It isn't perfect, and it took a long time to tune. What counts is having a system: tests that stop the line, a second AI that audits the first, and a person who reviews what gets flagged.
For more on the docs side, see how I manage a large codebase with layered instructions, my first look at GitHub Copilot CLI and why engineering judgment still matters in vibe coding. If you're the bottleneck between ticket and release and want help mapping your own loop, that's what I cover in a 1:1 strategy call.
About Dwain
I'm Dwain Browne, Founder of LeadScore AI and SnapSuite. I'm a Toronto-based software architect with 25+ years across software, sales, operations and entrepreneurship. SnapSuite helps contractors and trades teams get paid faster, and LeadScore AI shows you which leads deserve your next call. I also run Vibe Code to Profit, a community helping people build software with AI.