banner

About the project

Inspiration

AI coding agents have dramatically reduced the time required to create the first version of a product. A developer can describe an idea and quickly receive working routes, database models, interfaces, and integrations.

But getting software to run is not the same as making it ready to serve real users.

The hardest work often remains in the final 10%: authorization, data integrity, failure handling, observability, deployment safety, recovery, regression testing, and the architectural assumptions that were never made explicit. AI-generated code can look correct file by file while still producing an inconsistent or unsafe system.

RunReady was inspired by this gap between a convincing prototype and a production-ready product:

AI built the first 90%. RunReady finishes the last 10%.

The project was also influenced by the idea of conceptual integrity from The Mythical Man-Month. When several developers—or several AI agents—contribute to a system, each change may be locally reasonable while the system as a whole loses a coherent design.

We wanted to explore an AI-era question:

What would a production-readiness agent look like if it protected the integrity of the entire system instead of reviewing isolated lines of code?

That became RunReady: a system that takes AI-built software from $90 \rightarrow 100$.

What it does

RunReady is a production-readiness agent for AI-built software.

It examines a project, makes its implicit architectural assumptions explicit as a Conceptual Constitution, and evaluates changes against concrete production requirements.

The Conceptual Constitution captures system-level principles such as:

Identity must come from a verified session.
Tenant-owned resources must remain tenant-scoped.
Payment and webhook operations must be idempotent.
External calls must have timeouts.
Privileged instructions must not be controlled by untrusted input.
High-impact infrastructure or data-policy changes require human approval.

RunReady’s first product surface is a GitHub Production Gate.

When a pull request is evaluated, RunReady combines deterministic source analysis with schema-constrained Codex reasoning. It produces an evidence-backed Production Score, a release verdict, and findings that include the affected file and line range, severity, evidence, realistic failure scenario, remediation, verification method, confidence, and required action.

RunReady does not silently modify a repository. Analysis is read-only by default, and remediation starts only after the developer selects Fix the last 10%.

Actions are separated by risk:

Safe, scoped changes such as input validation, tests, timeouts, health checks, or logging can be prepared automatically after an explicit request.
Changes involving authorization, schemas, migrations, deployment configuration, or infrastructure require human approval.
Decisions involving destructive data operations, payments, retention policies, public contracts, or major architecture remain manual.

The submitted demonstration starts with an intentionally incomplete AI-built application. RunReady evaluates it and produces a 61/100 — Blocked result with concrete evidence. After the user selects Fix the last 10%, RunReady applies only the permitted remediation, independently reassesses the changed application, and produces a verified 61 → 94 result.

The remaining high-impact decisions are clearly labeled as approval-required rather than being silently changed.

How we built it

RunReady was built during OpenAI Build Week using Codex with GPT-5.6.

We used Codex to accelerate implementation, exploration, refactoring, test creation, and documentation. However, the product boundaries and safety decisions remained human-directed.

Before implementing the product, we defined several non-negotiable rules:

Production findings must include concrete evidence.
Analysis must be read-only by default.
Inferred architectural principles must never silently become approved policy.
Remediation must be explicit, scoped, and independently verified.
RunReady must know where automation should stop and human approval should begin.

Technically, RunReady is a TypeScript monorepo built with pnpm. Its main components include:

A Next.js App Router web application for the product interface, reports, settings, GitHub webhooks, and requested actions.
A long-running worker for repository analysis, Codex execution, remediation, and verification.
PostgreSQL with Drizzle for durable projects, Constitutions, assessments, remediation runs, installations, repositories, webhook deliveries, and queued jobs.
Zod-validated domain contracts for findings, evidence, assessments, Constitution principles, remediation changes, and runtime configuration.
A deterministic scanner for supported Next.js and OpenAI application patterns.
Real and mock Codex analyzer and remediator adapters.
A GitHub App integration for authenticated webhooks, installation tokens, Check Runs, annotations, pull-request summaries, and requested actions.
A leased PostgreSQL job queue with idempotency, retries, backoff, and stale-lease recovery.
A bounded temporary workspace for source analysis.
An opt-in trusted-verification boundary with a fixed lint, typecheck, test, and build command allowlist.

The analysis pipeline first verifies and queues a GitHub event. A worker then fetches a bounded collection of changed text files, classifies the repository, loads or infers relevant Constitution principles, runs deterministic source checks, and invokes Codex in a read-only workspace.

The results are validated, normalized, deduplicated, scored, persisted, and converted into a Production Gate verdict.

For remediation, RunReady creates a separate writable worktree and gives the Codex remediator only the selected findings, applicable Constitution principles, and explicit acceptance criteria. Protected files and out-of-scope changes are rejected. An improved score is shown only after the resulting changes pass independent rescanning and reassessment.

For the hackathon, we also built a credential-free deterministic mode. This allows judges to experience the full product story without creating a GitHub App, configuring an OpenAI key, supplying a database, or connecting a sample repository.

The mock and live implementations share the same domain contracts and product flow, so the demo is deterministic without turning the production architecture into a fake interface.

Challenges we ran into

One of the biggest challenges was defining what “production ready” actually means.

A generic checklist was not enough. Production requirements depend on the system’s architecture, trust boundaries, data ownership, failure semantics, and business invariants. This led us to elevate the Conceptual Constitution from documentation into a versioned and executable product object.

Another challenge was deciding how much autonomy RunReady should have.

It would have been easy to market the product as an autonomous agent that fixes everything. We concluded that this would be unsafe and misleading. The important differentiator is not maximum autonomy—it is correctly recognizing where autonomy must stop.

We therefore had to create a risk-aware action model that distinguishes automatic remediation, approval-required changes, and manual architectural decisions.

Running tools against unfamiliar repositories introduced another major challenge. Installing dependencies or executing repository commands can run untrusted code. RunReady therefore performs source-only analysis by default and does not execute repository commands during webhook handling or initial assessment.

Trusted verification is a separate, explicit capability. It uses a restricted environment, installs dependencies with lifecycle scripts disabled, runs only a fixed command allowlist, and terminates timed-out process groups.

We also had to ensure that remediation results were honest.

A prepared patch must not improve the Production Score of an unchanged pull request. The improved score is attached only after a real workspace diff passes action-scope validation, independent reassessment, optional trusted verification, and branch-head consistency checks.

Concurrency created additional complexity. A pull request may change while RunReady is analyzing or fixing it. To avoid overwriting newer work, remediation commits use the expected pull-request head as their parent and recheck the branch immediately before performing a non-force update.

Finally, we needed a demonstration that was both credible and reliable. A fully live GitHub, PostgreSQL, deployment, and Codex environment would create multiple external failure points during judging. Building real adapters alongside a deterministic end-to-end mode gave us a stable judge experience without pretending that unverified live infrastructure had already been tested.

Accomplishments that we're proud of

We are proud that RunReady became more than a static mockup or another AI code-review interface.

We built a complete, interactive product journey:

AI-built pull request → Production Gate → blocked assessment → explicit remediation → independent verification → approval-aware release decision.

We turned conceptual integrity into a tangible product mechanism through the Conceptual Constitution. It makes architectural intent explicit, versioned, reviewable, and executable.

We also created a hybrid assessment model that combines deterministic checks with Codex reasoning. Deterministic scanners provide reproducible evidence for known production patterns, while Codex can reason across files and identify semantic inconsistencies that conventional linters may miss.

The product produces structured evidence rather than relying on an agent saying that something “looks fixed.”

We are especially proud of the safety boundaries:

No hidden source mutation.
No automatic promotion of inferred policy.
No repository command execution during initial analysis.
No pushing to forked pull requests.
No improved score for an unchanged pull-request head.
No automatic high-impact production decisions.
No force-pushing or overwriting newer work.

RunReady also includes durable queue and persistence boundaries, GitHub webhook and Check Run contracts, real and mock Codex adapters, independent post-remediation reassessment, browser-tested product flows, and deployment-ready web, worker, and PostgreSQL topology.

What we learned

The most important lesson was that AI coding changes the software-engineering bottleneck, but it does not eliminate essential complexity.

AI makes implementation cheaper. It does not automatically resolve questions about identity, ownership, consistency, failure recovery, observability, deployment, or operational responsibility.

We also learned that production readiness cannot be represented by one opaque score. A useful score must expose its coverage, blockers, uncertainty, evidence, and approval requirements.

Another major lesson was that project context becomes more valuable as coding becomes faster. When many agents can produce code, durable knowledge about the project’s architecture, invariants, accepted risks, and previous release decisions becomes a critical asset.

We learned that deterministic analysis and language-model reasoning work best together. Rules are valuable for high-confidence, reproducible checks. Codex is valuable for interpreting system behavior, following data across files, and identifying contradictions. Neither approach is sufficient alone.

Most importantly, we learned that trustworthy agents need visible limits.

A production agent should not only know how to act. It should know when it lacks enough evidence, when a decision belongs to a human, and when changing the system would cross a protected boundary.

What's next for RunReady

The immediate next step is to complete external live verification.

We plan to deploy the web application, worker, and PostgreSQL services; register the GitHub App; and run a real same-repository pull request through assessment, explicit remediation, verification, and Check Run publication.

After validating the complete live path, we plan to expand RunReady in several directions:

Support more languages, frameworks, and repository architectures.
Add richer Constitution discovery, editing, approval history, and version comparison.
Integrate runtime evidence from cloud infrastructure, databases, authentication systems, observability platforms, deployments, and backup systems.
Add architecture tests, integration tests, database assertions, and runtime probes generated from approved Constitution principles.
Learn from verified remediation and release outcomes while preserving project privacy and explicit user control.
Build organization-level context around accepted risks, incidents, critical paths, and release history.
Provide reusable production-readiness policies for common application types while keeping each project’s Constitution specific to its own architecture.

The long-term vision is for RunReady to become the trust and verification layer between AI-generated software and production: