Understudy

• 

  Every decision keeps its evidence: the failure receipt, the changed data that actually arrived, the guardrail result, and the test result.

• 

  Payment sync was repaired and tested like any other automation, then stopped at the last step because it writes payment records.

• 

  Three automations under watch. Two are running normally. One has deliberately stopped and is waiting for a human decision.

• 

  A live repair in progress. The receipt was captured before GPT-5.6 was called, proving the original code really failed.

Inspiration

I build automations, and I don't always keep an eye on them. Even with an alert system, an alert only tells me something broke. It doesn't fix anything. A company renames an API field, or retires a model, and the automation stops working. Then someone has to wait for me to log in and make the change, even when the change is small.

What it does

Understudy watches the automations I've built. When one breaks, it reads the code, diagnoses what changed, writes a patch, and re-checks that the patch actually works before anything is turned on.

It never edits my original code. Repairs are stored as separate patches and versions, so I can always see what is running and go back.

There is also a safety layer. It cannot repair everything. If something touches payments or amounts, it is not allowed to fix it on its own. It stops and waits for approval. Anything to do with money is something a person should know about and decide on.

Right now it is connected to mock automations only. Connecting my real working automations is the next step.

How I built it

I started with a full plan and asked GPT-5.6 to critically analyze it and mark everything that needed to change. That made the plan much better before I wrote any code.

Then we built it in batches. I worked task by task. Codex would build a small piece, run it, and give me a summary of what it had done. That is how the whole system got built. I was on bypass permission, so it ran for long stretches on its own.

Afterwards I went back through the repository to understand what had actually been built, because it had built everything. Then came the dashboard. It took five or six rounds of checking and fixing before it worked properly.

Challenges I ran into

I am not from a technical background, so the first challenge was simply understanding the terminology around automations and the parts of this system.

The bigger one came later. Codex built a working dashboard, but it did not show what the system was actually doing. The interface worked, but the repair steps were invisible. I broke an automation to test it, it healed itself, and I could not tell what had just happened. If I couldn't follow it, nobody else would either.

So I told it to rebuild the interface so that anyone who reads English can understand what is going on. Plain steps, plain words, no jargon. That is where the step by step repair guide came from.

I was also skeptical about how I would connect this to my real working automations, and working that path out took time.

Accomplishments that I'm proud of

I built a layer that can sit on top of the systems I already run, and it takes away the feeling that someone is waiting on me to fix something small.

I try to build my automations well so they don't break easily, but some things are outside my control. Those breaks are usually small. Understudy handles the small ones on its own, and for the few that are genuinely major, it stops and leaves them to me. That split is the part I'm happiest with.

What I learned

This was my first time using Codex, and it was a great experience. The way it worked suited me. I would give it a task, it would build that piece, and at the end it would tell me what it had built, what had changed, and what to do next. Working in batches like that kept the project moving.

The bigger thing I learned is that an autonomous system can genuinely repair something that has broken, not just tell you that it broke. Before this I thought of AI mostly as something that writes code while I watch. Seeing it diagnose a real failure, write a fix, test that fix, and then decide whether it was even allowed to use it was different.

I also learned that the hard part is not the repair. The hard part is deciding what should never be repaired automatically. Most of my thinking went into where the system has to stop and hand the decision back to a person, and I think that is the part that makes it something I would actually trust.

What's next for Understudy

A proper onboarding flow, so the automations I build can connect to Understudy easily instead of being wired in by hand.

After that, a diagnostic layer that runs weekly or monthly across every connected automation, checks whether anything has broken or drifted, and repairs what it safely can, so a break gets found and fixed before a user ever runs into the error.

Built With

• beautiful-soup
• codex
• css
• fastapi
• gpt-5.6
• html
• javascript
• modal
• openai
• pydantic
• pytest
• python
• sqlite
• uvicorn