About Workhorse

1The context

AI has upended software development. The very role “Software Developer” is a legacy concept, fading fast from the vocabulary of contemporary tech companies. In its place are agents that are incredibly efficient at coding, as well as being useful at every other point in the software lifecycle. Workhorse was born from a need to adapt to that massive change.

2The new division of labour

The primary human job that remains is to shape the product: decide what to build, define the rules it lives by, judge how it should look and feel. Specs are the key output in that process, and provide the input for everything else. There’s also a bit of curatorship, review, and agent management to do. Otherwise, agents handle the rest.

2aProduct shaping

The shaping happens at two levels. A project starts with a PRD: a product requirements document developed by interview with the AI, with a product manager or equivalent in the lead. Once the PRD is in shape, the next step is to break it into cards, again with AI assistance. The cards land on the project board, each ready to go through spec refinement and on through implementation. Projects appear on a roadmap that gives product leaders a view across what’s in flight and when each is likely to land.

2bProduct engineering

As AI takes more of the work, the traditional software roles (product owner, designer, developer, tester) compress into one: the product engineer. This is the human role Workhorse is built for: the person writing specs, workshopping the design, driving AI through implementation, and validating the result.

Platform engineering remains an important parallel discipline. Infrastructure, on-call, dangerous-layer changes, and codebase health all need a dedicated team thinking at that level. Workhorse focuses on the product engineering side, but the two go hand in hand.

3Specs are king

If the spec is wrong, everything downstream is wrong, regardless of whether a human or AI writes the code. Getting specs right is now the core discipline.

A spec describes how the system behaves: what it does, what it doesn’t, what the edge cases look like. Code, automated tests, release notes, and user manuals all derive from it. Specs are committed to the repo as markdown alongside the code they describe, where they accumulate over time. That history is how the next person, or the next agent, knows what the system is supposed to do.

3aThe work along the way

Specs and code are long-lived. They describe the system as it is, and they stick around. Mockups, plans, and test cases work differently. They live in the repo for the duration of a card and then dissolve into something else: a mockup becomes the implementation, a test case becomes an automated test, a plan becomes a finished checklist. Workhorse commits them alongside the spec while the card is open and clears them when the card ships, so the long-lived parts of the codebase stay clean.

Each of these is an input to the implementation step, and each is shaped to be both agent-consumable and human-reviewable. Plans are checklists the implementation agent ticks off as it goes, which is a simple way of stopping it from skipping a step. Test cases are written out in prose before any automated test exists, so a human can sign off on the coverage before any code gets generated. Mockups are HTML and CSS, in the same medium the implementation eventually lives in, so an agent reads and copies from them directly.

3bDriven by conversation

Most of the work in Workhorse happens in chat: you develop specs, mockups, plans, and test cases by talking them through with the agent. There aren’t forms or fields or ticket templates to fill out, just a conversation that shapes the artifact.

The agent asks questions to fill in what it needs to know, surfaces edge cases, drafts the spec, and revises as you give feedback. Workshopping designs is one of the most creative and fun parts: you riff with the agent on look and feel, mockups appear in minutes, and you can keep generating variations until something clicks.

Common moves like interviewing or mocking up have named skills to kick off that step. Skills are markdown files in the repo, so a team can add or refine its own.

4Design is the fun part

The design system is the other long-lived artifact in the repo, alongside the specs. It captures the visual language: components, spacing, palette, the patterns the product is built from. Every mockup the agent generates inherits from it. A designer sets the system up at the start, reviews the bigger flows that come out of product-engineer conversations, and refines the system itself as the product grows.

All of that means anyone can engage in workshopping a design. The AI handles the fundamentals, and what comes back is on-brand because the design system tells the agent how. It’s the part of the loop you’ll enjoy most.

4aMockups in conversation

Mockups happen the way specs do, in chat. Ask for three takes on the slot picker, sit with them, ask for the same again with a quieter palette, choose one. What used to take a day takes a conversation, and trying something costs almost nothing.

The feedback runs in plain language: “too busy”, “the green is loud”, “I prefer the second one but with the spacing of the first”. The agent takes that and runs with it.

4bNative to the build

Mockups live in the same medium as the implementation: HTML and CSS. Most design tools store their output in formats that are hostile to agents: opaque binaries, proprietary scene graphs, screenshots that have to be reverse-engineered into structure. HTML and CSS sidesteps that whole problem because it’s just text. The agent reads from the mockup straight into the build, and what ships looks faithfully like what was drawn.

5Always multi-tasking

A consequence of agents doing the work is that you’re rarely waiting on yourself. While one agent is drafting a spec, another is implementing an earlier card, another is running CI, another is reviewing a pull request. The bottleneck is direction, not production, so a product engineer naturally has three or five things in flight at once.

Workhorse keeps you in flow across those threads. An in-flight sidebar with subtle notifications directs your attention to whatever needs you next, and the back-and-forth turns into a kind of hyper-engaged momentum. The volume one person can sustain across that many threads at once goes well past what serial work allows.

6Optimised for handoff

Workhorse is designed for handoff at any step. Every artifact it produces lives in the repo in formats agents can read directly: specs, plans, and test cases as markdown, mockups as HTML and CSS, code as…code.

Want to design a flow in Figma or implement a step in Cursor? Workhorse will generate a briefing prompt with how it works, what’s on the current branch, and the relevant spec. When you’re done, upload a mockup, paste in a spec, or just have your agent commit directly and Workhorse will pull it straight in.

Workhorse won’t be the best tool at every step. Better tools for design, implementation, and specific use cases will keep arriving. Use Workhorse where it earns its place, hand off where it doesn’t, and trust that the work survives because it lives in the repo.