The cockpit passed its checks. The workflow still failed.
Brutal is a native cockpit for supervising work written by coding agents. Projects, agent sessions, terminals, changed files, review evidence, and recovery stay in one workspace. It is still in development, so this case separates what I observed, what I reconstructed, what I executed, and what is still proposed.
- Role
- Solo product, UX, architecture, engineering
- Research
- 13 Claude and 44 Codex sessions
- Evidence
- 2,515 recorded tool calls
- Status
- 16 cards shipped, 4 active on 27 July 2026
The cockpit passed its checks. The workflow still failed.
Brutal is a native cockpit for supervising work written by coding agents. Projects, agent sessions, terminals, changed files, review evidence, and recovery stay in one workspace. It is still in development, so this case separates what I observed, what I reconstructed, what I executed, and what is still proposed.
The interface could run the work. It could not explain the work.
The first brief was about replacing a pile of editor windows with one multi-pane app. The session record showed a different problem. I kept asking what was left, pasting screenshots to explain defects, and sending a separate push instruction after the work looked finished.
Solo product, UX, architecture, engineering
Solo product, UX, architecture, engineering
Brutal stopped pretending to be an editor.
The transcripts showed that most of the work happened in the shell. I rarely edited by hand. What I needed was a way to watch the work and correct it. Brutal changed from an editor with agents around it to a supervision cockpit with an editor available when I need to inspect a file.
The launched artifact, not the roadmap, decides what is real.
A parity audit found fixture data presented as real state and five controls that did nothing, even though fifteen roadmap cards had passed. I listed every visible surface, connected displayed values to production state, and removed unverified claims from the shipped column.
A native cockpit for directing, watching, and shipping agent work.
I am the primary observed user: one developer running several local coding agents across repositories. Each project and pane keeps its own state. The terminal, agent, editor, diff, review, and workflow evidence stay close enough to supervise as one system.
The interface could run the work. It could not explain the work.
The first brief was about replacing a pile of editor windows with one multi-pane app. The session record showed a different problem. I kept asking what was left, pasting screenshots to explain defects, and sending a separate push instruction after the work looked finished.
- 01Current work, failures, changed files, and remaining steps were not visible without another status request.
- 02A screenshot was the recurring way to point at a visual defect because agent work was not watchable in the cockpit.
- 03Several panes initially reused one application-level agent, terminal, and editor state instead of owning independent sessions.
- 04A model response could end while tests, review, commit, push, or remote verification were still incomplete.
Start with the problem, not the finished interface.
Brutal began as a way to keep several agents, terminals, and repositories in one native workspace. The transcripts changed the brief. Editing code was not the hard part. The hard part was seeing what the agents were doing, what remained, what failed, and whether the work was ready to ship.
Observed evidence comes from the active repository, packaged-app audits, 13 Claude Code sessions, 44 Codex sessions, 2,515 recorded tool calls, the PRD, decision log, and execution ledger. The sitemap, flows, SWOT, wireflow, and low-fidelity frames are analytical reconstructions. No external usability study or adoption claim is made.
Problem, users, team, and method
How might one developer direct, watch, correct, and ship agent-written work without asking the interface what is happening or rebuilding context after every interruption?
- 01Observe
- 02Frame
- 03Map
- 04Wireframe
- 05Build
- 06Verify
The operator could run several coding agents, but project state, remaining work, changed files, failures, and readiness to ship were scattered across windows and had to be requested in chat.
Make agent-written work continuously supervisable: show live state without asking, make each agent's work inspectable, preserve recovery context, and make shipping a deliberate verified action.
Solo product, UX, architecture, and engineering. Jason Poindexter defined the product, audited the work sessions, mapped the flows, built the prototypes and native application, and recorded acceptance evidence.
Primary observed user: Jason, a keyboard-and-mouse developer supervising several local coding agents across repositories. This is evidence from self-use, not a stand-in for external interviews or a market persona.
Repository and decision audit, transcript analysis, packaged-app launches, interaction and parity checks, responsive comparisons, failure review, and repeated screenshot-based critique.
Local-first, native Rust and GPUI, provider-neutral agent contracts, real persistent PTYs, project-scoped state, explicit human gates, and no success claim without executed evidence.
What the evidence says is broken
The operator had to ask what was left.
- Evidence
- Across the observed sessions, “what's left” or status was requested 12 times because current work, blockers, changes, and completion state were not visible.
- Design response
- Add an always-visible state strip with running work, repository state, failures, changes, and remaining steps.
A screenshot was the main defect-reporting channel.
- Evidence
- The observed loop repeatedly moved from long command runs to visual inspection and a pasted screenshot when the interface missed the mark.
- Design response
- Make agent work watchable in the product: surface commands, changed files, visual output, failed checks, and a compact review path beside the run.
Demo parity did not prove product fit.
- Evidence
- Fifteen roadmap cards passed their named criteria while five demo controls were inert and two surfaces rendered fabricated fixture data.
- Design response
- Enumerate every visible control, derive displayed values from production state, and test the launched artifact rather than trusting the roadmap or screenshot.
Several panes could show the same underlying session.
- Evidence
- The packaged-app audit found application-level agent, terminal, and editor state reused across panes.
- Design response
- Key agent, terminal, editor, transcript, draft, and execution state by pane identity.
Switching projects did not switch the workspace.
- Evidence
- Project selection changed the active label while one global pane tree and one active pane continued to render.
- Design response
- Give every project its own pane tree, sessions, layout, drafts, and persistence boundary.
A model response could end without verified success.
- Evidence
- The runtime had treated provider completion as if the requested work had passed its tests and review contract.
- Design response
- Separate model completion from workflow success. Require observed command evidence and independent review before a graph can succeed.
Status reports the July 2026 audit record. Proposed work is not presented as shipped.
SWOT reconstructed from the project record
Strengths
Internal / helpful- A native shell owns panes, sessions, persistence, permissions, and rendering.
- Agent, terminal, editor, diff, review, and workflow are peer surfaces.
- The graph contract separates model completion from evidence-backed success.
Weaknesses
Internal / harmful- The cockpit is still in development and has no user adoption evidence.
- The foundation changed repeatedly before the current boundaries settled.
- A mature terminal, editor, persistence, and agent host create a broad quality surface.
Opportunities
External / helpful- Parallel coding agents need a workspace built around independent session state.
- Persistent local workflows can reduce the cost of reconstructing work after interruption.
- Provider-neutral contracts can keep product behavior stable while runtimes change.
Threats
External / harmful- Provider-owned tools do not all expose the same pre-execution control.
- Editor and terminal expectations are set by mature products with years of integration.
- A multi-pane interface can become visual noise without strict focus and ownership cues.
Map the work before showing the finish.
The information architecture, user tasks, screen inventory, connected wireflow, individual frames, and implementation boundary are kept in one sequence.
Brutal sitemap
- Brutal
- Workspace
- Project launcher
- Project tabs
- Session navigator
- Pane tree
- State strip
- Supervise
- Agent work
- Live commands
- Changed files
- Failures
- Workflow evidence
- Inspect
- Files
- Editor
- Diff
- Review
- Search
- Git
- Control
- Approval
- Retry or stop
- Ship
- Recovery
- System
- Providers and permissions
- Persistent runtime
- Settings and shortcuts
- Help and diagnostics
- Workspace
3 complete paths, including recovery
Direct and supervise agent-written work
Give one directive and keep the work visible without asking for status.
- 01Operator
Give one short directive
- 02Brutal
Bind the task to a project, pane, agent, and completion contract
- 03Agent
Run commands and stream work evidence
- 04Brutal
Keep process, changes, failures, and remaining work visible
- 05Operator
Inspect, steer, approve, or stop
- 06Operator
Accept the result or continue the loop
If a command, provider, or check fails, preserve the transcript, changed files, and terminal reason. Return the failed step to the operator with retry, revise, fork, and stop choices.
Run several independent agents
Run several agents without mixing their transcripts, processes, drafts, or writers.
- 01Operator
Split the workspace or open another project
- 02Brutal
Create a new pane identity
- 03Operator
Choose agent, terminal, editor, or review
- 04Runtime
Create independent transcript, PTY, draft, and execution state
- 05Brutal
Check the repository writer boundary
- 06Operator
Supervise both sessions from one cockpit
If a writer lease conflicts, the new agent stays read-only until the user isolates a worktree, transfers the lease, or cancels the write path.
Review and ship verified work
Commit and push only after the named checks pass.
- 01Operator
Open changed files, commands, and the completion contract
- 02Brutal
Run deterministic checks and independent review
- 03Evidence gate
Compare observed results with the declared contract
- 04Operator
Review the diff and shipping scope
- 05Brutal
Commit, push, and verify the remote result
- 06Operator
See an honest shipped or refused outcome
A failed check, review, commit, push, or remote verification refuses the ship action, preserves the evidence, and routes back to the exact failed step.
Screens, purposes, and routes
Enter and orient
Open a repository or return to a persistent session.
Hold project tabs, navigator, pane tree, utilities, and persistent status.
Show what is running, what changed, what failed, and what remains.
Direct and watch
Direct one agent and inspect its transcript, tool events, commands, and result.
Run and inspect one persistent real process attached to the project.
Inspect changed files without turning the cockpit into an editor-first IDE.
Decide, ship, recover
Hold risky action, diff, scope, test evidence, and reviewer decision together.
Commit, push, and verify through one deliberate action with an honest result.
Restore projects, panes, drafts, processes, and checkpoints without hiding incomplete work.
The supervision loop keeps execution, correction, recovery, and shipping connected.
The main path follows the observed work pattern. Interruptions and corrections stay visible instead of sending the operator back to chat for status.
- startActive cockpit
- report live stateState strip
- interruptedRecovery
- open evidenceAgent work
- judge workOperator review
- reviseCorrection
- accept for checksVerification
- steerActive cockpit
- resume or forkActive cockpit
- verifiedShip result
- failedCorrection
End state
Structure and state before visual finish
Project launcher
Recent projects, runtime health, and one clear open action.
Cockpit
Navigator, independent panes, live state, and bottom utilities in one native window.
idle / running / blocked / ready to ship
Agent work
The operator can judge the work without asking for another status summary.
ready / streaming / waiting / failed / complete
Two-agent split
Each pane has its own identity, model, transcript, status, and writer lease.
Agent and terminal
A scoped agent works beside the persistent process it controls.
Build-review workflow
Human gate, builder, deterministic checks, reviewer, and bounded retry.
Ship review
A single action may commit and push only when scope and evidence are ready.
not ready / ready / shipping / failed / shipped
Narrow workspace
One focused pane stays visible while background work continues.
The native shell composes panes. Core contracts remain independent of the UI.
This comes from the active Rust workspace and PRD. Provider SDKs and GPUI types stay outside the core contracts.
- User opens a project and selects a pane
- Pane identity owns transcript, process, draft, and execution state
- Agent or workflow requests a scoped capability
- Capability broker checks filesystem, process, executable, and network policy
- Runtime executes through a detached session
- Events and evidence update the pane, graph, and persistent checkpoint
Brutal stopped pretending to be an editor.
The transcripts showed that most of the work happened in the shell. I rarely edited by hand. What I needed was a way to watch the work and correct it. Brutal changed from an editor with agents around it to a supervision cockpit with an editor available when I need to inspect a file.
Make supervision the product boundary
The observed loop became the brief. Across 13 Claude Code sessions and 44 Codex sessions, the pattern stayed the same: a short instruction, a long run, visual inspection, a status question, and a deliberate ship command. I put that loop ahead of editor chrome. The interface shows the state, the work, the correction path, and the ship step.
Make the pane the unit of session
Parallel views are not parallel agents. Every pane owns its agent, terminal, editor, transcript, draft, process, and execution state. The pane is part of the runtime identity. Two panes on one repository can no longer collapse onto the same terminal or conversation.
Separate model completion from verified success
A response ending is a checkpoint, not an outcome. The build-review flow requires a plan, human approval, scoped work, deterministic checks, independent review, and evidence for the completion claim. If the evidence fails, the work returns to a bounded correction loop. It does not get renamed as success.
Keep the mature substrate, replace the product surface
Do not rebuild years of terminal and editor integration. The first Rust and GPUI shell proved the interaction model. It also showed how much mature rendering, terminal, editor, focus, accessibility, and restoration behavior I would have to rebuild. Brutal now owns the product and application contracts while using a pinned editor codebase for those lower-level parts.
The mapped screens became a testable cockpit.
This prototype connects the sitemap, pane model, recovery routes, and screen inventory. The sample repositories and transcripts are fixtures, not product data. It tests the interaction shape. It does not mean every surface is shipped.
A dashboard organized information, not concurrent work.
I kept the rejected dashboard because it makes the wrong model obvious. Cards and summaries pushed the active agents away from the work. I replaced it with project tabs, a quiet navigator, peer panes, contextual evidence, and one persistent state boundary.
Chrome is necessary. The supervision loop decides whether it works.
The current contract covers project tabs, session navigation, peer panes, utilities, overlays, responsive focus, and recovery. A later audit showed that visual parity was not enough. Visible state, watchable work, and the ship action are now part of the contract too.
The launched artifact, not the roadmap, decides what is real.
A parity audit found fixture data presented as real state and five controls that did nothing, even though fifteen roadmap cards had passed. I listed every visible surface, connected displayed values to production state, and removed unverified claims from the shipped column.
| Capability | Evidence status | Boundary |
|---|---|---|
| Independent pane sessions | Executed | Agent and terminal state keyed by pane |
| Project-scoped workspaces | Executed | Tabs switch panes, sessions, layout, and drafts |
| Build-review workflow | Executed | Human gates and terminal outcomes exercised |
| Visible work state | Active | Contract exists; production surface remains in progress |
| Watchable agent work | Partial | Harness evidence exists; final surface remains active |
| One-action ship | Active | Shell path exists; product control remains in progress |
| External usability or adoption | Not established | No external study or adoption claim |
The roadmap stays inspectable because green cards were not enough.
The roadmap keeps shipped, active, blocked, and superseded work with its acceptance evidence. It is a trace of the work. It does not replace launching the product and running the operator path.
What remains unproven.
Brutal has one observed primary user: me. I have no external usability or adoption evidence yet. This case covers self-use, architecture, executed acceptance, and the gaps that remain. Dates matter because the repository moves quickly. Proposed frames stay separate from shipped behavior.
Make the work visible before calling it done.
I stopped treating Brutal as another editor. The product is the supervision loop: direct the work, watch it happen, correct it, and ship only after the checks pass.
Active development. One observed primary user. No external adoption claim.