Meet Typosaurus: an autonomous coworker now looking after DevPlace

For a while now I have wanted something that could take a ticket and actually carry it, not just suggest a diff and leave the rest to me. Not a chat window I have to babysit, and not a one-shot code generator that forgets the project the moment it answers. Something that behaves like a colleague: reads the issue, checks it against the real code, does the work, proves the work, and tells you honestly when it is stuck.

That is what Typosaurus is, and starting now she is taking responsibility for the DevPlace project's tickets.

What she actually does

You label an issue. From that moment she owns it end to end:

1. Discovery. She picks up any issue carrying the agreed label. Nothing is touched unless a human opted it in, so she never wanders into work nobody asked for.
2. Investigation. Before writing a single line she brings up a clean, isolated checkout and reads the real source, the tests, and the history. Half the value is here: she regularly finds that a bug no longer reproduces, or that a "missing" feature already exists, and says so instead of inventing a change.
3. Planning. She turns what she found into a concrete plan with an explicit definition of done, tied to the project's own build, test, and lint commands.
4. Execution. She implements the plan inside that ticket's own container, fully isolated from the host and from every other ticket.
5. Verification. She runs your checks, not her own opinion of "looks done". If they fail, that is a failed attempt, full stop.
6. Delivery. On green, she commits, pushes a branch, and opens a pull request that links back to the ticket and spells out the plan.

Through all of it she narrates on the ticket itself, before each step, so anyone watching can tell active work from a stall.

The parts I am most proud of

• She works in the open. Every pickup, every research round, every attempt, every outcome is a comment on the ticket. There is no black box; you can read exactly what she did and why.
• She learns from her own mistakes. When an attempt does not give the expected result, the reason is recorded and fed into the next attempt. A retry is never a blind repeat of what just failed.
• She knows the difference between "the ticket is wrong" and "our plumbing broke". If the gateway is down or a container dies, that is never held against your ticket, never counted as a real attempt, and never dressed up as a finding. She retries quietly, and if the infrastructure stays broken she says plainly that it is an internal problem, not your fault.
• She cannot do anything irreversible on a whim. Deleting a branch, deleting a repository, tearing down a workspace - none of it is reachable from the normal loop. She only ever proposes cleanup; carrying it out needs an explicit confirmation from an admin or owner, re-checked live at the moment it runs.
• Every action is on the record. State changes and destructive attempts, allowed or denied, are written to an audit trail. Nothing important happens silently.

Where she is honest about her limits

I would rather tell you the rough edges than oversell this.

• She asks, and sometimes she asks a lot. When a ticket is ambiguous, lacks reproduction steps, or describes something that no longer matches the code, she stops and asks one specific question rather than guessing. That is deliberate, but it means vague tickets move slowly. Good tickets get good results; thin tickets get a question back.
• She is only as good as the checks you give her. Verification leans on the project's own build, test, and lint commands. A project with weak tests gives her a weak safety net, and she will tell you when there is nothing meaningful to verify against.
• She depends on the model backend. When the reasoning backend is unavailable she does not fake progress; she waits and escalates. Reliable output needs reliable infrastructure behind it.
• She is not a replacement for review. She opens a pull request; a human still decides whether it merges. She is a very capable coworker, not an unattended autopilot, and she is designed to stay that way.
• She carries a few tickets at once, not a hundred. Work is deliberately bounded so nothing thrashes. Throughput is steady rather than explosive.

Why I built her this way

Every design choice comes back to one idea: an autonomous coworker only earns trust if she is transparent, careful, and honest about what she does not know. So she narrates everything, refuses to touch anything destructive without a human, keeps a full record, learns from what fails, and asks when she is unsure. She is standalone - she has no hooks inside DevPlace itself; she operates on the project from the outside, over its API, the same way a remote teammate would.

From today she is watching the DevPlace tickets. Label an issue, watch her pick it up, and hold her to the same standard you would hold any colleague. Tell her when she gets it wrong - she is built to listen, and to remember.

• retoor