Tempo

The most expensive gap in software development is not between an idea and a design. It is between a design and the code that eventually ships.

A designer produces a mockup in a tool that knows nothing about the codebase. An engineer rebuilds it approximately, using components that exist rather than the ones drawn. Somewhere in that translation the spacing changes, a state gets forgotten, and the thing that ships is a reasonable interpretation of what was approved.

Tempo's answer is to remove the translation. If the canvas is code in your repository, built from your real components, then there is nothing to reimplement — the design ships because it was never a mockup.

Tempo: One IDE For Four Roles

• Designers, PMs, engineers and agents share one tool, working on the same real codebase rather than on parallel artefacts.
• Canvases are code in your repo, built from your real components and tokens, and they ship as a pull request.
• Four named agents: Triage, Spec and Design, Bug Fixer and Feature Builder, each owning a distinct stage.
• Agents run on any model, in any harness, across as many worktrees as needed, with PR and CI status in one view.
• A desktop application, downloadable for Windows, macOS and Linux.

Can Designers, PMs And Engineers Share One Tool?

Tempo describes itself as one IDE for the whole team, with distinct views for designers, product managers, engineers and agents, all working from the real codebase.

The technical argument is sound. Every role in product development is ultimately arguing about the same artefact, and the reason they use different tools is historical rather than necessary — a designer's tool cannot compile, so it drew pictures instead.

The organisational argument is harder, and it is where products like this usually fail. Adopting a shared IDE means a designer giving up a tool they know intimately, and a specialist tool that a specialist loves is extremely hard to displace with a general one that is merely adequate.

The realistic path is therefore partial rather than total. A team where designers keep their existing tool for exploration and use Tempo for production work — the point where a design becomes real — captures most of the benefit without asking anyone to abandon anything.

It is also worth noting who benefits most and least. Engineers gain a design that already compiles; designers give up expressive freedom in exchange for their work shipping accurately. Whether that trade is attractive depends on how often a designer currently watches their work get built wrong.

Most coding tools decline this problem entirely. Aider and Zencoder serve engineers well and have nothing to say about the designer who watched their work ship approximately.

A designer's tool draws pictures because it cannot compile. That is a historical accident, not a requirement — and it is where the expensive translation happens.

Canvases As Code Is The Real Idea

Tempo states that canvases are code in your repo, built from your real components and tokens, and that they ship as a pull request because they were never a mockup.

The consequence people underestimate is constraint. A canvas built from your actual component library cannot draw a button that does not exist, cannot invent a spacing value outside your tokens, and cannot specify a state your components do not support.

That sounds restrictive and is the entire point. Most design-implementation friction comes from designs that are subtly impossible — a variant nobody built, a layout the grid does not permit — and discovering that during implementation is the expensive moment.

It also changes what review means. A design arriving as a pull request goes through the same review as any other change, with the same CI, the same checks and the same history, rather than through a separate approval process nobody can audit later.

The limitation follows from the same property. A canvas constrained to your components is not where you explore something new, because the components for something new do not exist yet. Exploration needs a freer tool; production benefits from the constraint.

Four Named Agents And What They Own

Tempo names four agents: Triage watches feedback channels and turns ideas and bug reports into prioritised issues; Spec and Design turns triaged issues into PRDs and clickable designs; Bug Fixer reproduces a bug, finds the root cause and ships a tested pull request; Feature Builder builds a specced feature on its own branch.

Separating them by stage rather than offering one general assistant is the right design, and the reason is the same as in any workflow product: each stage has a different input, a different output and a different definition of done.

Triage is the least glamorous and probably the most valuable. Feedback arrives as Slack messages and support threads and never becomes an issue, which is why teams simultaneously have a backlog and no idea what users actually want. Converting that stream automatically is a real gain.

Bug Fixer is the most testable claim in the product. Reproducing a bug, finding the root cause and shipping a tested fix is a complete engineering task with a checkable outcome, and it is the one to evaluate first because you will know immediately whether it worked.

Feature Builder is where the caution belongs. An agent building a whole feature on its own branch produces a pull request somebody must review properly, and reviewing generated code is slower and less reliable than reviewing code a colleague wrote — because you cannot ask it what it was thinking.

Whatever the agents produce still has to clear the same gates as anything else, which is where a quality platform such as Codacy belongs — reviewing generated code is exactly what automated checks are for.

• Evaluate Bug Fixer first, since a fixed bug is a checkable outcome.
• Let designers keep their exploration tool and use Tempo for production work.
• Treat agent-generated pull requests as needing more review, not less.
• Use Triage on a real feedback channel to see what it surfaces that you missed.
• Check that canvases genuinely build from your components before committing a team.

Adopting A Shared IDE Without A Revolt

Products that ask several roles to change tools at once fail for organisational reasons rather than technical ones.

The sequence below starts where the benefit is unambiguous and the disruption is smallest.

1. Start with engineers only, using the agents on an existing repository, and change nothing about how designers work.
2. Run Bug Fixer on three real bugs you have already fixed, and compare its root cause analysis against what you found.
3. Point Triage at one feedback channel for a fortnight and review what it surfaced against what your team caught.
4. Only then bring one designer in, on one production feature rather than on exploration.
5. Confirm a canvas actually builds from your real components and tokens, since that claim is the whole proposition.
6. Expand by role rather than by team, and stop if the designers are working around it rather than with it.

Where A Shared Codebase Helps Most

The teams this suits are identifiable, and it is a narrower group than the positioning suggests.

The strongest case is a small product team where the same people already wear several hats. When a designer occasionally writes CSS and an engineer occasionally makes design decisions, a shared tool matches how the work already happens rather than imposing a structure.

The second is a team with a mature design system. Canvases built from real components only work if your components are real, documented and consistently used — a team whose design system is aspirational will find the constraint infuriating rather than helpful.

The weakest case is a large organisation with established, separately owned toolchains. Displacing three toolchains simultaneously is a change management project, and the benefit has to be enormous to justify one.

Model and harness flexibility — agents running on any model, in any harness, across multiple worktrees — points at teams already running agents seriously rather than experimenting. That is a specific and growing group, and it is probably who this is really for.

The far end of the same lifecycle belongs elsewhere again: once the feature ships, showing it to buyers is a demo platform's job, which is what Navattic exists to do.

Tempo: Platforms And Agents