ProjectDNA

ProjectDNA is an AI software architect that turns product ideas into a traceable engineering blueprint and keeps contracts, diagrams, agent rules, and tests synchronized as requirements evolve.

Comment

Inspiration

AI can generate code and technical documents quickly, but those artifacts often drift apart as soon as a project changes. A requirement may be updated while the API contract, data model, agent instructions, and tests continue to reflect the old design.

I started ProjectDNA to explore a different approach: instead of generating isolated documents, could AI help maintain one connected engineering blueprint that preserves requirements, decisions, contracts, and validation as the project evolves?

What it does

ProjectDNA is a decision-aware specification compiler for software projects.

Starting from a product idea, it identifies the product purpose, users, scope, requirements, constraints, scale assumptions, critical invariants, and architecture decisions. When an important policy is ambiguous, ProjectDNA asks a blocking clarification question instead of silently inventing an answer.

Accepted design intent is stored in a typed canonical model called ProjectIR. ProjectDNA then derives four synchronized artifact layers from that model:

  • Design: requirements, invariants, priorities, and engineering decisions
  • Contracts: OpenAPI definitions, ERDs, and sequence flows
  • Harness: AI-agent instructions and implementation constraints
  • Validation: acceptance scenarios and traceability checks

When a requirement changes, ProjectDNA proposes a reviewable patch, shows its direct and indirect impact, preserves the relevant trade-offs, and updates every affected artifact together. Model output always begins as proposed; only an explicit human action can make it accepted.

How we built it

ProjectDNA is a React and TypeScript web application built with a Next.js-compatible vinext runtime and deployed for Cloudflare Workers.

The application uses a typed Zod schema for ProjectIR and validates stable IDs, references, lifecycle states, decisions, and invariant coverage. The OpenAI Responses API with GPT-5.6 Structured Outputs is used to interpret product intent and produce typed proposals.

The model is responsible for interpretation and proposal generation, while deterministic application code validates proposals, renders artifacts, applies accepted changes atomically, and supports one-step undo. ProjectDNA generates OpenAPI documents and Mermaid definitions for ERDs and sequence diagrams from the same canonical state.

I used Codex throughout Build Week to refine the product scope, design the ProjectIR model, implement the application, diagnose issues, and build the validation and testing workflow.

Challenges we ran into

The hardest problem was not generating each artifact independently. It was preserving the relationships between requirements, invariants, decisions, endpoints, entities, agent rules, and tests while the project changed.

Another challenge was separating AI interpretation from trusted state mutation. A structurally valid model response can still contain broken references, self-approved decisions, or unverified invariants. ProjectDNA therefore treats every model result as a proposal and runs deterministic lifecycle, reference, and consistency validation before it can become canonical project state.

Change handling was also challenging because a small requirement can have a large blast radius. The prototype represents changes as typed patches so users can review affected artifacts and unresolved decisions before anything is applied.

Accomplishments that we're proud of

I am proud of turning a broad AI software architect idea into a focused, testable workflow:

product idea → clarification → proposed blueprint → human acceptance → synchronized artifacts → requirement change → impact review → atomic update

The prototype maintains Design, Contracts, Harness, and Validation views from one ProjectIR model. It prevents blocking questions from being bypassed, preserves engineering trade-offs, validates trace links, rejects unverified accepted invariants, and supports resetting or undoing the latest synchronized change.

This demonstrates a path beyond one-off document generation toward engineering artifacts that remain connected as a system evolves.

What we learned

The biggest lesson was that reliable AI-assisted engineering depends less on fluent document generation and more on structure, lifecycle, and traceability.

AI is valuable for interpreting intent, finding ambiguity, and comparing options. Humans still need to accept material decisions, while deterministic software should enforce references, contracts, and invariants.

We also learned that design documentation becomes much more useful when it can be compiled into machine-readable contracts, AI development rules, and executable validation instead of remaining disconnected prose.

What's next for ProjectDNA

Next, I plan to add downloadable artifact bundles, versioned design history, and richer traceability visualization. Longer-term work includes repository analysis and GitHub integration so ProjectDNA can compare the accepted blueprint with the actual codebase and propose updates in either direction.

The long-term goal is to make ProjectDNA a living technical blueprint that evolves alongside both product decisions and implementation.

Built With

Share this project:

Updates