wd-atlas
Sign in

A modern app, built with AI-assisted engineering and a human at every gate

wd-atlas was designed, built, reviewed, and shipped using a repeatable AI-assisted method: a person sets the intent and approves at every gate, while AI does the planning, writing, testing, and review legwork. Here is how that method works, and what it has produced.

A repeatable engineering methodHuman-directed, human-approvedBuilt to industry standards (SOLID, DRY, DevSecOps)

The method

Five disciplined steps, from idea to production

Every change runs the same loop. AI does the heavy lifting at each step; a person reviews and approves before anything reaches users. This is a structured software-development lifecycle, not improvisation.

  1. Plan

    Every feature starts as a written implementation plan: scope, boundaries, risks, acceptance criteria, and the security and design standards it must meet, before any code.

    AI drafts
  2. Review the plan

    A second AI pass audits the plan for completeness, scope creep, architectural fit, and standards compliance. Open decisions are surfaced to a person to settle.

    Human decides
  3. Build

    Focused AI agents implement the approved plan, write the tests alongside the code, and stay inside the agreed scope.

    AI builds
  4. Verify

    Automated tests, type checks, and a production build all run. The change is proven against its acceptance criteria before review.

    Automated checks
  5. Review and ship

    A person reviews the change as a pull request and approves the release. Nothing reaches users without that human gate.

    Human approves
Who does each step:AI does the legworkAutomated checksHuman decision or approval

The toolkit

The automation behind each step

The method is not freehand prompting. Each step is run by a specific, repeatable automation, so the process is consistent every time and independent of any one person's memory.

Structured planning

An automated planner turns an intent into a written implementation plan with scope, boundaries, risks, acceptance criteria, and the security and design standards it must meet, before any code is written.

Independent plan review

A separate automated review pass audits every plan for completeness, scope creep, architectural fit, and standards compliance, and surfaces open decisions to a person.

Phased execution agents

Focused agents implement the approved plan one phase at a time, writing tests alongside the code and staying inside the agreed scope.

Multi-agent code review

Before merge, parallel review agents inspect the change for bugs, security issues, and quality, surfacing findings for a person to confirm.

Diagnose-then-fix pipeline

Bugs run a two-agent loop: one diagnoses to a confirmed root cause, a second fixes against that plan only. The same loop powers the in-app Bug Fix Report.

Session continuity and retrospectives

Each work session opens and closes with a written hand-off, and a retrospective captures lessons, so context and learning never get lost between sessions.

Harness engineering

The engineering is in the harness around the AI

The toolkit above is not a loose set of tricks. It is a deliberate harness built around the AI, and that harness is where the engineering lives.

Harness engineering is the discipline of building a structured harness of AI skills and automations, plan to review to execute to verify to ship, that wraps the AI so it produces consistent, repeatable, verifiable work, with a person approving at every gate. The toolkit above is that harness: the value is not in any single prompt, but in the disciplined, repeatable system built around the AI.

By the numbers

What that method has produced

A working, deployed application, built in days by one person directing AI through the method above.

3
coding sessions over 2 days
from a blank repo to a live, demo-ready wage-lookup MVP
~14k
lines of app code
production TypeScript, fully type-checked
16
architecture decisions
documented design records, not tribal knowledge
100%
human-gated releases
no change ships without a person approving
~1,800
EST human coding hours saved
estimate vs a conventional hand-built equivalent of roughly 1,900 hours, against about 140 hours actually spent directing AI
~300M
AI tokens consumed
order of magnitude estimate across about 37 working sessions, covered by a flat monthly subscription, not metered
~$10k
estimated total cost of creation
mostly lead developer time (about 140 hours), plus a $200 per month AI subscription and platform hosting

MVP scope: data ingestion, geographic wage-determination search, and detail pages, built across three coding sessions over two days (May 6 to 7, 2026) and demo-deployed the same week. Figures as of June 5, 2026.

What it would have cost

AI-assisted versus a conventional manual build

The same shipped application, estimated two ways. Figures are estimates; labor is priced at a blended $75 per hour.

~140 hrs
human time actually spent directing, reviewing, and approving
~1,900 hrs
estimated hand-built equivalent for the same deliverable
~13x
effective leverage, about 1,760 hours saved
93%
lower cost than a conventional manual build
About $132,000 less for the same shipped application. The AI-assisted build cost an estimated ~$10,700 versus ~$143,000 to hand-build.
Total cost of creation
Manual
~$143,000
AI-assisted
~$10,700

Bars to scale: the AI-assisted build is about 7.5 percent of the manual cost. Estimates; labor at $75 per hour.

Line itemManual buildAI-assisted (actual)Delta (saved)
Engineering hours~1,900 hrs~140 hrs~1,760 hrs
Labor cost (at $75 per hour)~$142,500~$10,500~$132,000
AI subscription (Claude Max, $200 per month, about 1 month)$0~$200-$200
Platform and hosting (about 1 month)~$30~$30$0
Total cost of creation~$143,000~$10,700~$132,000

Estimates. Human hours come from the project commit history (about 18 active days). The manual equivalent uses a conservative industry rule of thumb of roughly 10 to 15 lines of production code per hour, all in. Formal parametric models such as COCOMO II would estimate a larger manual effort, so this figure is intentionally conservative. Figures as of June 5, 2026.

In practice

The method, on real work

Two features the app uses to show its own users how their feedback is handled, both built with the same loop.

Shipped

Bug Fix Report

When a user reports a bug, the app shows them exactly how it was handled: pulled down, diagnosed to a root cause, fixed, verified, and shipped, with a human reviewing at the gate. A live, per-bug audit trail of the method itself.

Reported to shipped: often same day.

Shipped

Enhancement Report

When a user suggests an idea, the app shows how it moved from suggestion to a decision: considered, then accepted and built, or declined with the reason recorded. Transparency about what gets built and why.

Every idea: a visible decision trail.

A representative session

Two complete features, planned and shipped in a single sitting

In one working session, two full features were each taken from idea through a written plan, independent review, AI-built implementation, automated verification, and human-approved release, and deployed to production the same day. That cadence is what the method makes routine, not exceptional.

Built to standard

Industry engineering practices, enforced automatically

Speed does not come at the cost of quality. The same recognized standards a seasoned engineering team would apply are written into the planning and coding automation, and checked on every change, not left to discipline or memory.

SOLID principles

The five long-standing object-oriented design principles. In plain terms: each piece of code has one clear job and the parts fit together cleanly, so the system stays easy to change as it grows.

DRY (Don't Repeat Yourself)

No copy-pasted logic. Every rule lives in exactly one place, so a change is made once and applies everywhere, which is fewer bugs and lower maintenance cost.

Coding standards and clean architecture

Consistent naming, typed interfaces, and strict layer boundaries are enforced on every file, so the codebase reads as if one disciplined team wrote it.

DevSecOps, security shifted left

Security is designed in at the planning stage, not bolted on at the end. Each feature's threats are identified up front and the mitigations are required before it can ship.

Secure-by-design controls

Authentication, access control, and data-handling rules map to a recognized security-controls framework, with abuse-case tests that prove the protections actually hold.

Independent quality review

Every plan and every change is audited by a separate automated pass for these standards before a person sees it, so quality issues are caught early, not in production.

Why it is safe

Speed without giving up control

The velocity above is only credible because of the discipline underneath it. These guardrails are built into every change.

A human approves every release

AI plans, writes, and tests; a person reviews the result and approves the pull request. No change reaches users on AI judgment alone.

Every change is planned before it is built

Work begins from a written plan with explicit scope and acceptance criteria, audited by an independent review pass. Scope creep is caught before code.

Tests and type checks gate every change

Automated tests, type checking, and a production build must pass before review. Regressions are caught by machines, not by users.

Decisions are documented, not lost

Architecture decisions are recorded as durable design records. The reasoning behind the system is auditable, not locked in one person's head.

Every change is tracked and reversible

All work lands as small, reviewed pull requests in version control. Any change can be traced, audited, or rolled back.

The same method, every time

Plan, review, build, verify, ship is repeatable and consistent, not dependent on one person's mood or memory on a given day.