Penling penguin markPenling
The spec-driven workflow for AI-native teams

Build to spec.

Penling turns your team's work into planned, built, and tested code — then writes the spec into your repo as the permanent record of why. Your team decides what to build; AI builds it; the reasoning never gets lost.

No credit card·14-day free trial
Spec

Define the work

What to build, what “done” looks like, what’s off-limits.

Build

Agent ships it

The agent writes the code — and proves it meets the spec.

PR + /specs

The record lands

Spec committed to the repo — the reasoning, forever.

The permanent record

The spec doesn't live in a tool. It lives in your code.

When the work ships, Penling writes the specification into your repository as markdown — in a /specs directory, next to the code it produced, updated whenever the work changes.

No separate wiki to drift out of date, no doc nobody updates. The record is version-controlled with everything else — it changes when the code changes, and it's reviewed in the same PR.

your-repo
src
components
auth.ts
specs
FA-008-add-microsoft-sso.mdNEW
FA-012-rate-limiting.md
tests
auth.test.ts
Written by Penling when the PR opens
The Penling workflow

From brief to merged PR.

Every stage hands off a concrete artifact — nothing lives only in someone's head.

  1. 01
    Brief

    The raw ask and its context land in one place.

    Human + AI
  2. 02
    Goal

    A named milestone the work moves toward.

    Human
  3. 03
    Specification

    Definition, results, conditions, boundaries.

    Human
  4. 04
    Plan

    AI proposes the steps; you shape and publish.

    AI + Human
  5. 05
    Build

    An MCP agent picks it up; writes code and proves each spec result.

    AI + Human
  6. 06
    PR

    Verified against the spec, attributed, ready to review.

    AI + Human
The problem with shipping AI code

Code ships in hours. Reasoning fades in days.

Tickets get vaguer. AI fills the gaps.

When the AI "figures it out," tickets stop saying what the work actually is. The reasoning lives in one developer's head - until they leave.

Drift

The diff is reviewable. The decisions aren't.

A PR shows what changed, but not what the AI was asked to build or what it chose along the way. Reviewers approve code without ever seeing the reasoning behind it.

Context

AI moves fast. Decisions scatter.

When a feature ships in an hour, there's no time for the usual coordination checkpoints. PMs find out what was built from the PR — not from the spec, because there wasn't one.

Coordination
What spec-driven gives you

Every build, specified and shared.

Two things the team gets on every piece of work — before a single line of AI code is trusted.

Specified

Every line of AI code traces back to a spec the team wrote.

Specs in Penling carry definitions, expected results, conditions, and boundaries. The AI builds against them — and the build can't close until every acceptance result the spec defined has been met. When the spec changes, the change is on the record.

Penling · Focus area · FA-08
In progressFA-08
3 / 4 results met
Returning-user login — acceptance results
Expected resultProven by
Returning users matched by verified email
auth.test.ts:42
Session persists across page reloads
session.test.ts:18
Logout clears all session data
auth.test.ts:89
Auth error shows a friendly messageawaiting build
Shared

One spec. The whole team in it at once.

Designers shape expected results, PMs set conditions, leads draw the boundaries — all on the same living artifact, at the same time. Not a printout, not a retelling, not a doc that forks into five stale copies. The spec the agent builds against is the spec the team is editing.

FA-08
MASFPJ
3 EDITING
Returning-user login
DefinitionMaya · Design
Returning users sign in with a verified email and land back where they left off
Expected resultsSam · PM
Session persists across reloads
Logout clears all session data
BoundariesPaul · Lead
No password reset flow in this focus area — tracked separately in FA-11
Same artifact the agent builds against · autosaved
Day 0 vs. month 6

The day you ship, they look identical. Six months later, they don't.

Same feature. Same merged PR. Same AI doing the work. The only difference is what's left behind once everyone's moved on.

Day 0
PR #42 mergedfeat: add Microsoft SSO✓ shipped
identical for both teams
Month 6
DA

“Why is it built this way?”

$ git log auth.ts
a3f1b9 feat: add SSO
Paul · 6 months ago
?Ask around. Read the diff. Guess.
DA

“Why is it built this way?”

specs / FA-008-add-microsoft-sso.md

Entra ID only — every tenant is on Entra. Okta out of scope. Decided by Paul, recorded at build.

One file. Answered.
A small manifesto

AI is changing how code gets written. We think it should also change how teams agree on what to build.

Every other tool in this space races to take humans further out of the loop. Penling does the opposite — it keeps the team in it, with the reasoning behind every decision attached to the work from the first spec to the merged PR.

We built it because the hardest part was never writing the code — it was keeping the whole team aligned on what the code was supposed to do, and why. We hope you build with it for the same reason.

Try Penling free for 14 days. Bring a goal, define a spec, and ship something your whole team can explain by Friday.

Penling