Behind the redesign: agents built our landing, and a few things broke

The Allye landing you see at allye.app was built by agents working from specs. It mostly worked. This is how that went, including the parts that did not go well, and one bug we copied on purpose by accident.

Start in a canvas, not in code

We did not start with components. We designed the whole page as a prototype in a design canvas: structure, copy, motion, mobile. We built four options, compared them and picked one ("Flight plan"). Then we pushed a second round into the winner: Memory, knowledge base, MCP and team sections, plus a layer of scroll motion.

The canvas has a hard limit. Artboards stop at 8000px tall, so the page was split into parts. That detail matters later, because the prototype is not the page.

Specs with a fidelity rule

The prototype became the source of truth through specs. A spec in Allye is the unit of work: rules, acceptance criteria, decisions, and thin tasks that point at them. Ours carried one binding rule: the implementation must match the prototype exactly. Only technical necessities were allowed to deviate (framework and SEO constraints, merging the canvas parts into one page). Anything else needed the owner's explicit approval, and every deviation was listed in the PR.

Two things made that enforceable:

• Every pull request had to include prototype-versus-implementation screenshots, section by section, desktop and mobile.
• Every difference went into a deviations file with a reason and who approved it.

The Bridge crew ran the work. A Pilot (the implementing agent) took each task, then independent checks came from Copilot, Medic and Shield, and a final Watcher review compared everything against the spec. You can read how that pipeline works in the Allye plugin docs.

Parallel missions

The work was split by spec and run as separate missions in separate worktrees:

canvas prototype
  -> spec: home page            -> PR #2
  -> spec: secondary pages      -> PR #3
  -> develop supersedes main    -> PR #4, PR #5
  -> live on allye.app

The first mission rebuilt the home page, restyled blog and docs, and shipped the new logo. The second took the pricing, product, MCP, terminal and comparison pages, stacked on the first until it merged. Each mission only touched the files its tasks listed, and the orchestrator did the commits.

What went wrong

1. Sticky stopped working and no check noticed

The pinned Memory and Team stories use position: sticky. In the first build they simply scrolled away. Build, lint and type-check were all green, because nothing was wrong with the code.

The cause was a legacy rule on the old page: html and body both had overflow-x: hidden. That makes body a scroll container, and a sticky element sticks to its nearest scroll container, not the viewport. The fix is overflow-x: clip, which clips without creating a scroll container. The prototype had already learned this. The legacy stylesheet had not.

The lesson: a green build says nothing about layout behavior. We now measure the pinned offset across scroll steps in a real browser and keep the numbers in the PR evidence.

2. The prototype had a bug, and we copied it faithfully

Under the armed motion layer, the phase header rows of the flight rail ("blueprint" and "launch") never became visible. The reveal key was never applied to the step element of those header rows, so the rule that hides un-revealed steps kept the heading, glyph and rail segment hidden.

A strict fidelity rule reproduces defects too, and ours did it with great discipline. Our evidence screenshots showed the headers missing in the prototype and present in the implementation, which is how we found it. We recorded it as a deviation and kept the headers visible, because that was clearly the intended design. Fidelity needs an escape hatch with a name on it.

3. A test wrote to a real configuration

This one is not funny, so here are the facts. While testing an install guide for one of the supported harnesses, in the plugin's install-guide mission that ran alongside the redesign (ALY-85), a mission pointed HOME at a temporary directory and believed it was isolated. It was not. The session also had a config-directory variable inherited from the real environment, and the guide followed that one. The test rewrote a real user config file.

The "use temp copies only" instruction in the task was not enough, because the leak came from environment variables nobody listed. The rule that came out of it is concrete:

• Any mission that runs a guide, installer or config writer starts from an empty environment, with HOME and every XDG_* variable pointing into a fresh temporary directory.
• The run asserts first that every resolved path lives inside that directory.
• Reviewers check this per slice, not once at the end.

The guides themselves were then hardened: pinned versions and a backup before any config is rewritten.

4. Parallel missions need decisions in one place

Two missions touching the same site can each make small, reasonable choices that disagree. The decisions that actually needed coordinating were not visual:

• The canonical domain, so metadata, sitemap and links all agree.
• Install guides hosted on our own site instead of fetched from a mutable branch.
• Which harness tabs to show while a guide was still missing.
• Whether mobile gets sections the mobile artboards had left out.
• What to do with the old main branch, which had diverged: we recorded it as merged and let the redesign supersede it (PR #4 and PR #5).

We recorded these as decisions in the specs and as memories, so missions could pick them up as hints at the start instead of rediscovering them. Memories are hints, not the source of truth: the spec decisions and the coordinating session still carried the weight.

What we would keep, and what we would change

We would keep the prototype first, specs as the contract, evidence in every PR, and one place for decisions.

We would change two things. Run a real-browser check for layout-dependent behavior as an explicit task from the start, and write the sandbox rule into the mission template before the first install guide is tested, not after. Yes, we learned the second one the hard way.

If you want to see the result, it is live. If you want to see how the pipeline works, start with the docs or the plugin guide. And if you spot something wrong on the page, write to app@devshire.app.