living software

Software that observes real workflows and lets AI propose safe, reviewable, reversible improvements.

Comment

Inspiration

What it does

How I built it

Inspiration

Most analytics tools explain what users clicked, but product teams must still manually translate that behavior into a useful software improvement. I wanted to explore a different idea: software that can understand how it is being used, propose its own improvement, and still keep humans in control.

What it does

Living Software is an installable developer tool for TypeScript Next.js applications.

It maps an application's routes, interface elements, source files, and relationships. It then captures privacy-minimized workflow evidence including routes, actions, timing, outcomes, performance, and bounded layout information. It does not capture typed values, customer data, screenshots, or persistent user identity.

When the developer runs living improve, GPT-5.6 receives the complete verified behavior matrix and bounded source context. The model chooses the evidence-supported workflow problem, selects an existing source file, and authors a bounded code improvement.

The proposed change cannot modify the application automatically. Living Software validates and seals the artifact, then requires a human to approve its exact artifact and proof hashes. After approval, it applies the source change, records receipts, verifies the host, and supports byte-exact rollback.

How I built it

Living Software is a TypeScript and Node.js monorepo containing:

  • An installable terminal CLI
  • Static Next.js product and source mapping
  • Privacy-safe browser observation
  • Hash-linked JSONL evidence collection
  • A complete behavior-matrix generator
  • GPT-5.6 integration through Codex CLI or the OpenAI API
  • Strictly bounded source projection and patch generation
  • Deterministic safety validation around the untrusted AI response
  • Exact-hash human approval
  • Source application, verification receipts, recovery, and rollback
  • An optional local Studio for visualizing the lifecycle

Codex helped design and implement the architecture, CLI, contracts, observer, intelligence layer, evolution engine, tests, security boundaries, documentation, and demo workflow.

Inside the finished product, GPT-5.6 examines the observed evidence and authors the actual improvement. The feature is not hardcoded in advance: the model chooses what to propose based on the available behavior matrix and bounded source code.

Challenges

The hardest challenge was allowing AI to invent a useful source change without giving it unrestricted authority over the repository.

I separated creativity from control. GPT can interpret evidence and author a proposal, but it cannot access the terminal, approve itself, write directly to the filesystem, run tests, or remove rollback history. Living Software owns those capabilities and exposes them only through validated, receipt-bound lifecycle steps.

Another challenge was collecting useful behavioral evidence without recording sensitive content. The observer therefore records structural actions and measurements rather than form values, DOM contents, screenshots, query strings, or customer identity.

Accomplishments

  • Installed Living Software into a separate CRM application
  • Automatically mapped 144 product nodes and 180 relationships
  • Captured privacy-safe workflow evidence
  • Passed the full behavior matrix and bounded CRM source context to GPT-5.6
  • Received a genuinely model-authored source improvement
  • Proved and sealed the proposed artifact before any write
  • Required exact-hash human approval
  • Applied the change to the real CRM
  • Verified the updated application through tests and a production build
  • Restored the original source byte for byte through rollback

What I learned

AI-generated software changes become much more credible when every step is explicit: evidence, interpretation, proposal, proof, approval, application, verification, and rollback.

The goal should not be uncontrolled self-modifying software. The goal should be software that earns permission to evolve.

What's next

The next step is post-change measurement. Living Software should compare controlled before-and-after workflow cohorts and determine whether an applied improvement actually reduced friction. Other future work includes broader framework support, pull-request integration, team approval policies, and production-grade privacy controls.

Challenges I ran into

Accomplishments that I'm proud of

What I learned

What's next for living software

Built With

Share this project:

Updates