Building an AI engineering loop that can keep working when my laptop is closed

Today I tried to connect a group of AI tools into an engineering workflow for EduDojo. When you read 'we', that means me and my new buddy "Astra (Medium)". Btw, I still have 88% usage left for the week. Wow!!!

The experiment was straightforward to describe: I discuss a feature with an AI architect, approve a clear direction, and delegate implementation. A different, fresh AI session reviews the result. If it finds problems, the builder fixes them. If the work passes review and its merge checks, the coordinating bot ships it and updates the product board.

The practical challenge was making the handoffs dependable without adding another paid model API, another orchestration service, or a new dashboard for me to maintain.

We now have a working pilot. We also learned why a working pilot and a fully validated autonomous engineering system are different claims.

What we wanted to achieve

I wanted to spend my attention on product decisions and the work that benefits from founder involvement, while keeping the freedom to code manually whenever I want.

Our existing tools already had useful roles:

• ChatGPT Work and Codex for planning and independent review.

• An existing Grok bot team, coordinated by a Chief of Staff, for execution and coordination.

• Cursor Cloud Agents for implementation.

• GitHub for code, pull requests, checks and merge history.

• One Notion Product Board for plans, ownership, progress and handoffs.

My cost constraint was specific: our planning/review route had to use my existing ChatGPT/Codex subscription allowance. I did not want to solve orchestration by quietly introducing separately metered model API calls. The overall stack still has its existing subscriptions and usage limits; this was not a “free software factory” experiment.

I also wanted the unattended parts to continue when my personal computer was off.

The options we explored

Our preferred design was event-driven: a GitHub event would launch a fresh reviewer as soon as a PR became ready.

We investigated native GitHub-triggered routes. A generic Codex cloud review diagnostic demonstrated that an event could launch work, but that did not establish the exact combination we required: the selected Astra High configuration, a fresh review context, retrieval of the Notion plan, and a reliable verdict written back to the board.

That distinction mattered. “A review bot ran” was not sufficient evidence that our intended review process ran.

We also considered a Notion webhook and a receiver on the bots' always-on virtual machine. That could provide orchestration, but it would introduce another integration boundary and still require a supported way to launch the exact reviewer under the desired billing model. A webhook alone does not solve model selection, authentication or subscription access.

Local automation was another possible route, but it conflicted with the requirement that my laptop could be off.

We eventually accepted scheduled cloud checks as the experiment's practical starting point. This was an account- and interface-specific conclusion from what we could configure and test, not a claim that event-driven review is universally impossible.

The final setup we are testing

The review dispatcher runs in ChatGPT Work at 9 AM and 9 PM IST. When eligible work exists, it processes the queue sequentially within available capacity.

Each ticket gets a fresh Astra High reviewer context. Remediation reviews and protected security reviews also get fresh contexts. The dispatcher coordinates the work; it does not reuse one long implementation conversation as the independent reviewer.

The Grok team keeps its existing weekday checks and continues looking for eligible work after finishing a task. We did not add hourly model polling.

The workflow is:

Plan → Ready → Implementation → Review Ready → Independent review → Review Passed → Merge verification → Merge and delivery → Done.

Notion provides the coordination record. GitHub provides the code and execution evidence. A board status does not magically make a failed check successful.

The details that made the handoff work

The plan is frozen as a versioned document, with a digest that lets the reviewer verify its exact contents. The review records the exact code version, target-branch version and plan digest.

If those inputs change, the previous verdict is no longer a verdict on the current candidate.

The reviewer publishes evidence to GitHub first, then mirrors the result into Notion. If that second write fails, the system should repair the synchronization rather than perform the review again.

We made ownership explicit. The reviewer stops at its verdict. CoS owns the next action after Review Passed: recheck the current candidate, verify merge eligibility, perform an eligible Standard merge, verify delivery, clean up the feature branch and record Done.

That last instruction was surprisingly important. A team that only checks Ready tickets can miss work that has already passed review.

We also limited the automatic engineering review loop to two completed cycles: the initial review and one remediation review. A second unsuccessful review goes back to the founder. Infrastructure failures and stale attempts are tracked separately; they are not permission to retry forever.

What stays with the founder

Changes involving scoring, telemetry, privacy or student data, and authentication still require a separate security/privacy review and a founder-performed merge.

Ordinary work can proceed without repeatedly asking me for permission. Protected work retains an explicit human responsibility.

Manual coding uses the same board and ownership rules. If I work with Codex on a feature, the bots should not simultaneously claim that work. The resulting PR still gets an independent review.

What the test actually proved

We chose a small documentation change: fixing a repository clone command in the README.

A fresh Astra High reviewer checked the PR and plan. It published a commit-bound PASS, which appeared in Notion. CoS consumed that handoff, checked the current inputs and GitHub's effective merge conditions, squash-merged the PR, deleted the branch and recorded Done with the matching merge identifier.

That proved the review-to-merge-to-board handoff.

The trial PR was prepared during setup. It did not, by itself, prove a brand-new delegated ticket passing through every Cursor implementation step. We also have not completed the full failure matrix: outages, duplicate dispatches, stale reviews, exhausted remediation cycles and every protected-change case.

The limitations we are keeping visible

Our integrations currently share a GitHub account. Recorded native reviewer provenance helps distinguish the work, but GitHub does not see separate human and agent identities for every action. Some separation is therefore procedural rather than independently enforced by permissions.

A skipped check also deserves honest reporting. Cursor Bugbot hit its quota during the trial. GitHub accepted its skipped/neutral result under the effective rules, but that does not mean Bugbot performed a review. Independent bug finding remains part of Astra's review.

Fresh contexts, clear plans and bounded retries reduce confusion and wasted work. They do not eliminate hallucinations, prompt injection, defects or service outages.

We have not benchmarked token savings. Twice-daily checks are an efficiency hypothesis we can now measure, with an obvious tradeoff: work can wait for the next scheduled check.

What I learned

The hardest part was defining the contract between tools.

Who owns the next action? What evidence allows a transition? What becomes invalid after a new commit? What happens if a write succeeds in one system and fails in another? When does the loop stop?

Those questions turned a promising diagram into a small working experiment.

For now, I prefer an honest scheduled pilot with visible evidence over a claim of instant, permanent autonomy. The next step is to run more small tickets through it and see where the handoffs, review quality and economics actually hold up.