AI Engineering Studio

A self-hosted engineering workspace where specialized AI agents challenge each other, preserve evidence, and move projects forward only through independent review and human approval.

Comment

Inspiration

AI agents can generate requirements, architecture, and code extremely quickly. But speed creates a new engineering risk: an incomplete or unsafe result can sound convincing and move an entire project in the wrong direction.

As a security professional, I believe risks should be identified not only before release, but from the beginning of a project and throughout design, development, review, and deployment.

I built AI Engineering Studio to explore a safer model: specialized AI agents can produce work, but they cannot approve their own results. Independent criticism, immutable evidence, and explicit human decisions are part of the workflow itself.

What it does

AI Engineering Studio is a self-hosted workspace where a human founder leads a persistent team of specialized AI agents.

The team includes:

  • Oliver — Orchestrator
  • Mary — Product Analyst
  • Winston — Architect
  • Amelia — Developer
  • Dana — QA Engineer
  • Vex — Security Reviewer
  • Paige — Documentation Agent
  • Chris — independent Critic

The demonstrated vertical slice protects the transition from Requirements Review to Architecture Review.

The workflow is:

  1. A versioned Requirements artifact is created.
  2. The independent Critic reviews that exact immutable version.
  3. The Critic returns PASS, REWORK, or STOP with structured findings.
  4. A REWORK decision blocks the transition and assigns a revision task to Mary.
  5. The revised Requirements are stored as a new immutable version.
  6. The Critic reviews the new version independently.
  7. A passing review still requires explicit Founder approval.
  8. Only fresh matching evidence and human approval allow the project to advance.
  9. Winston joins the project and receives the Architecture task.

Old reviews and approvals cannot be reused for a newer artifact version.

How I built it

The application uses:

  • React and TypeScript for the web console
  • FastAPI and Python for the backend
  • PostgreSQL for persistent workflow state
  • Alembic for database migrations
  • Docker Compose for reproducible local deployment
  • Playwright and Vitest for frontend and end-to-end testing
  • Pytest and PostgreSQL integration tests for backend behavior
  • Codex with GPT-5.6 throughout the engineering process

The system stores versioned artifacts, durable agent runs, immutable StageReview evidence, human approvals, transition history, task provenance, and cryptographic content hashes.

Critical workflow operations are transactional and concurrency-safe. Database constraints enforce uniqueness and cross-project integrity instead of relying only on application-level checks.

The demo uses a deterministic fake Critic provider so judges can reproduce the complete workflow without API keys, paid credits, or external model calls. The live provider path remains fail-closed until its execution isolation can be independently verified.

Challenges

The most difficult part was not generating a Critic response. It was making the response trustworthy enough to control a real workflow transition.

The implementation had to prevent:

  • stale approvals from authorizing newer requirements;
  • reviews from being attached to the wrong project or artifact;
  • duplicate tasks during concurrent retries;
  • partial state when one operation fails;
  • agents from approving their own work;
  • legacy approvals from bypassing the new gate;
  • secrets from appearing in logs or redirect requests;
  • demo behavior from depending on external APIs.

Another challenge was creating a natural handoff between agents. A REWORK verdict now creates one revision task for Mary. Creating the next Requirements version completes that same task. Approval and transition then create one Architecture task for Winston.

What I learned

I learned that reliable agentic engineering requires more than prompts and model output.

The important layer is the control system around the agents:

  • immutable artifacts;
  • exact provenance;
  • independent review;
  • transaction boundaries;
  • database-enforced idempotency;
  • structured failure codes;
  • human approval;
  • deterministic tests;
  • safe and reproducible deployment.

I also used Codex with GPT-5.6 to analyze the existing repository, compare architecture options, implement the Critic Gate, investigate failures, review security boundaries, generate tests, and package the demo.

The strongest results came from treating Codex as an engineering collaborator while keeping acceptance decisions explicit and evidence-based.

Accomplishments

  • Built a working Requirements-to-Architecture Critic Gate.
  • Bound every review to an exact artifact version and checksum.
  • Preserved immutable evidence and historical decisions.
  • Prevented stale review and approval reuse.
  • Added Founder approval and controlled override semantics.
  • Implemented atomic Product and Architecture handoffs.
  • Added concurrency-safe task creation and revision handling.
  • Created a bilingual English/Russian interface.
  • Packaged a deterministic one-command Docker demo.
  • Verified the full workflow with unit, integration, frontend, security, and end-to-end tests.
  • Completed the full flow manually through the real UI.

What's next

This submission demonstrates one complete vertical slice.

The next step is to extend the same evidence-driven gates across architecture, implementation, security review, QA, documentation, and release.

The larger goal is an engineering environment where AI agents do not simply generate more work. They challenge each other, preserve evidence, surface risks at every stage, and remain under human control.

Built With

Share this project:

Updates

Submission history