I Built a Website Whose Only Feature Is Explaining How It Builds Itself

dtannen — Wed, 08 Apr 2026 10:00:18 +0000

This is a submission for the DEV April Fools Challenge

What I Built

I built the most over-engineered website that does absolutely nothing useful.

Command Garden is a website about... itself. It has no users, no product, no reason to exist. Every morning, a 5-stage AI pipeline with three AI judges (Claude, GPT, and Gemini) wakes up, argues for 75 minutes about what feature to add to a website nobody visits, implements it, writes tests for it, reviews its own work, publishes a detailed decision log explaining why it chose to add "live growth stats" to a site with zero traffic, and then auto-posts about it on Bluesky to its zero followers.

The judges have names and personalities. The Gardener optimizes for "compounding value." The Visitor cares about "first-time clarity." The Explorer wants "novelty and surprise." They score candidates across seven dimensions. They write rationale paragraphs. They have disagreements. About a website that is literally just a changelog of its own changes.

Day 1: Added a section explaining how the pipeline works. Day 2: Added stats showing how many features have shipped (two). Day 3: Added an inline spec viewer so you can read the spec for the feature that added the inline spec viewer. It's turtles all the way down.

It also has a feedback form. In case you have opinions about what a website about nothing should build next. Your feedback is "one signal among many." The AI will "weigh it alongside technical signals." The technical signals are that the website does nothing.

Demo

commandgarden.com — a website whose only content is documentation about how it builds itself

Highlights:

The archive where you can browse a meticulous record of every meaningless decision
The judges page introducing three AI personas who take their fake jobs very seriously
The feedback form where you can influence the direction of nothing

Code

Commands-com / garden

A fully automated site that runs a commands.com pipeline once a day

The infrastructure is genuinely absurd for what it does:

CloudFormation stack with S3, CloudFront, API Gateway, Lambda, and DynamoDB — to serve a static site with a feedback form
5-stage autonomous pipeline (Explore → Spec → Implementation → Validation → Review) — 75 minutes of AI compute to add a CSS class
Three different LLM providers (Anthropic, OpenAI, Google) serving as judges — because one AI wasn't enough to decide whether to add a stats bar
Automated Bluesky posting and Dev.to publishing — so the void can hear about it on two platforms
Playwright test suite — rigorously testing features that don't matter

How I Built It

The pipeline runs on Commands.com, which orchestrates multi-agent rooms. I pointed three AI models at an empty website and told them to "grow it one feature per day." They took the job extremely seriously.

The infrastructure is vanilla AWS because apparently we needed enterprise-grade hosting for a site that explains its own build process. CloudFront CDN with edge caching, because those zero concurrent users deserve low latency.

The site itself is intentionally simple — no build step, no framework, just HTML/CSS/JS — so the AI can modify it without breaking things. This is the one smart decision in the entire project.

The daily runner aggregates feedback from DynamoDB (empty), collects Bluesky metrics (zero followers, 0.2 average likes), gathers "recent context" from previous days (a recursive loop of self-reference), then kicks off a pipeline that costs real money to ship features to a website that costs real money to host for an audience that does not exist.

Prize Category

Community Favorite — the community can literally control what gets built via the feedback form. Submit "add a button that does nothing" and tomorrow three AI judges will spend 75 minutes debating whether a button that does nothing has sufficient "compounding value" and "artifact clarity." Then they'll build it, test it, review it, and post about it. Democracy in action.

Fully Automated Website 2026-04-08: Day detail pages now show the full technical specification inline

dtannen — Wed, 08 Apr 2026 09:43:17 +0000

Command Garden is a website that builds itself — one feature per day, fully autonomously. No human writes the code. An AI pipeline proposes candidates, judges score them, and the winner gets implemented, tested, and shipped.

View the full decision log

What shipped

Each day's page now shows the full technical specification right on the page, so you can read exactly what was planned without downloading any files.

Candidates considered

Inline Spec Viewer on Day Detail Pages (score: 8.5) — Add a collapsible 'Technical Specification' section to the day detail page so visitors can read the full spec without leaving the page or downloading files.
Day Comparison View (score: 6.8) — Add a side-by-side comparison mode to see how two different days' decisions and outcomes differed.
Artifact Download Bundle (score: 5.8) — Add a one-click download button that packages all of a day's artifacts into a ZIP file for offline reading.

Winner

Inline Spec Viewer on Day Detail Pages with a score of 8.5

The inline spec viewer scored highest because it fills a genuine gap in the day detail page — specs were referenced by the pipeline but never viewable on the page itself. It completes the decision trail from scoring through planning to execution, and every future day benefits automatically. The other candidates were either too complex for the current stage (comparison view) or addressed a niche need with heavy dependencies (download bundle).

Technical spec

Inline Spec Viewer on Day Detail Pages

Add a collapsible "Technical Specification" section to the day detail page (site/days/index.html) so visitors can read the full spec inline, without downloading files or navigating away.

Problem

The day detail page shows every stage of the autonomous pipeline — judging, scoring, building, testing, reviewing — but not the technical specification that guided the build. Visitors who want to understand what was planned have to download the raw spec.md artifact. This breaks the reading flow and hides the most important planning document from casual visitors.

Goals

Complete the decision trail. The spec is the bridge between "what the judges chose" and "what got built." Showing it inline closes the narrative gap.
Zero-click access. Visitors can read the full spec without downloading or navigating away.
Compounding improvement. Every past and future day automatically gets spec viewing with no per-day code changes.

Non-Goals

Editing or annotating specs (read-only viewer).
Rendering specs as separate pages with their own URLs.
Changing the spec format or adding new metadata fields.

Proposed Approach

1. Add a new section to the day detail page

Insert a new <section id="spec-section"> as Step 6 between the feedback section (Step 5) and the build summary section (renumbered to Step 7). The section contains:

A section__header with "Step 6" label, "Technical Specification" title, and subtitle
A #spec-container div where the spec content is rendered

2. Render spec content with markdown

Use the existing renderMarkdown() utility to convert the raw spec markdown into HTML. Wrap the rendered content in a container with max-height: 80vh and overflow-y: auto to prevent very long specs from disrupting page layout.

3. Handle empty state

If spec.md is not available for a given day, display: "No technical specification available for this day."

4. Update step n

[Spec truncated — view full spec on the site]

What changed

Build Summary — 2026-04-08

Feature: Inline Spec Viewer on Day Detail Pages

Changes

site/days/index.html — Added a new "Technical Specification" section (Step 6) between the feedback section and build summary section. The section renders spec.md content using the existing renderMarkdown() utility. Includes empty-state handling when no spec is available. All subsequent steps renumbered accordingly.
site/css/components.css — Added .spec-collapsible component styles (toggle, content, rendered-md) with max-height: 80vh and overflow-y: auto to contain long specs, plus consistent padding and design-system token usage.

Stats

2 files changed
~50 insertions

Implementation Notes

The spec viewer reads the spec.md artifact that is already fetched as part of the day's artifact bundle. The content is rendered through renderMarkdown() (the same utility used for the build summary and review sections). A max-height constraint with scrollable overflow prevents very long specs from disrupting the page layout. When spec.md is not available, a clear message is displayed instead of leaving the section empty.

Command Garden ships one feature every day with zero human code. Follow along at commandgarden.com.

DEV Community: dtannen