From goal to merged PR — with the reasoning intact.
The hard part of building software was never writing the code — it was agreeing on what to build. Now that AI writes most of it, that's only clearer. The bottleneck has moved from execution to alignment.
Penling structures that alignment: work arrives, it gets defined, the definition becomes a plan a human approves, and the plan becomes a build a human steers. Here's every stage, and why it exists.
Goals get broken into focus areas. Focus areas are the spec.
This stage exists because an agent without a contract is just guessing. A focus area gives the agent exact edges: what to build, what a good result looks like, which constraints apply, and where to stop.
Every build that follows inherits this contract. The agent can't start without it — and neither can the reviewer who reads the PR.
- Definition — what you're building, in plain English.
- Expected results — numbered, testable, no vagueness.
- Conditions — the environment and constraints the agent must satisfy.
- Boundaries — what's explicitly out of scope, before the agent starts.
An LLM proposes an implementation plan. You shape it before it ships.
The AI drafts a step-by-step strategy from the focus area. It doesn't guess — it derives from the spec: what to build, what order to do it in, what to check along the way.
This is the moment a human asserts control over what the AI will do. Before any code is written, you decide the shape of the build. When you publish, the plan becomes the agent's mandate — and the agent can't start without it.
- Human edits are tracked and shown in the plan history.
- Multiple plans can be drafted - only the published one runs.
- Plan version is locked to the build that executes it.
Any MCP-compatible agent picks up the plan and starts building.
This stage exists because the agent shouldn't choose what it builds — only how to build what the plan says. Penling is the source of truth; the agent is the executor.
Bring Claude Code, Cursor, VS Code, or your own agent framework — Penling speaks MCP, so your tools connect without a wrapper or lock-in. The agent claims the build, streams progress back, and asks a human when it needs a decision.
- One Penling server, any MCP-compatible agent.
- Builds run in your runtime — your machine, your cloud.
- Clarifications pause the agent until a human responds.
Every move the agent makes streams back to Penling.
This stage exists so a build is never a black box. As the agent works, Penling receives every event: commits, test runs, check resolutions, clarifications, PR opens. Everything timestamped, everything attributed.
Subscribe and you can watch a build evolve in real time — in Penling, in Slack, in Datadog, in your own dashboard. The full event history is replayable from any point.
- Webhooks for every event type.
- Streaming subscriptions via Server-Sent Events.
- Replayable history — scrub from any point in the build.
A PR opens, traced to its spec, with every contributor named.
When the build closes, Penling opens a PR with the full reasoning attached. Every check traces to a file. Every commit traces to a human or an AI. The reviewer sees the spec, the plan, and the build record — all in one place.
One workflow. End-to-end documented.
Spec per focus area
Definition, results, conditions, and boundaries - every time.
Plans per spec
Draft as many as you need. Only the published one runs.
Native agent runtime
Any MCP-compatible agent. No wrapper, no lock-in.
Available
Every event streams. Every build is replayable from any point.
Ready to ship with structure?
Define your goal, spec the focus areas, connect your agent, and watch a pull request land — with the full reasoning intact.