Not an autonomous AI developer: why CRUX keeps people in the loop

A task goes through interview, code and review steps, with checkpoints where a person approves, instead of straight to a PR; the agent asks whether a decision changed.

The promise: assign a task, get a pull request

A popular kind of AI tool works like this: you assign a task to an agent, it spins up a sandbox, reads the repository, writes the code and opens a pull request. Some promise to ship many times faster. For a small, well-described task (a typo, a failing test with a clear stack trace, a dependency bump) it really works.

CRUX started from the opposite feeling. We build with AI agents every day, and the more we let them run on their own, the more time we spent afterwards finding where they had misunderstood us.

Where "autonomous" breaks

The task description is rarely the whole task. Here is what kept going wrong for us before CRUX:

  • The agent didn't know why the code is the way it is. We pasted the task text into a session. The agent saw code that looked odd, "fixed" it, and broke a feature another task had added for a reason it couldn't see.
  • Every session started from zero. The agent forgot what the project is about. Either we explained it again, or it burned a lot of tokens rediscovering it.
  • Nobody could tell a requirement from a guess. Teammates write tasks with AI too. A developer reads three screens of generated text and has to work out which lines the client asked for and which ones someone's assistant made up. An autonomous agent can't tell either, so it builds the guesses as carefully as the requirements.
  • The agent agreed with everything. "Great idea!", even when today's idea contradicted what we had decided three days earlier.
  • Big features had no good shape. One long session gave a huge pull request where mistakes and hallucinations piled up. Splitting the work into notes meant tracking by hand which agent did what, and in what order.

None of this is about a weak model. It's about context and feedback: the agent doesn't know enough, and nobody sees its wrong assumption until the pull request, when fixing it costs the most.

The idea behind CRUX: keep people in the loop, make the loop cheap

"Human in the loop" often sounds like a brake. We think it's the opposite: the cheapest moment to fix a misunderstanding is right after it happens, and the people who can spot it are already on the team. So CRUX doesn't try to remove them. It tries to make each check short and put it in the right place.

1. The agent knows the project, not just the task

A CRUX agent doesn't get the whole project pasted into its context. It gets access to it: the task in the tracker, earlier tasks and the decisions recorded on them, the tasks planned next, and the project wiki that describes how the system works today. The agent chooses what to read for the task in front of it. That's the balance we're after: enough context to solve the task well, but not so much that the agent drowns in it and starts ignoring its instructions. (More on this in Wiki, tracker and code graph instead of RAG and how we keep the wiki.)

That changes the result more than we expected. An agent that knows why old code exists leaves it alone. An agent working on task A that can see A1 and A2 queued behind it shapes its solution so they fit later. And an agent that reads past decisions can do what a good colleague does:

Agent: On Monday the decision on the parent task was that refunds go back to the original card only. This task asks for refunds as store credit. Has the decision changed, or should I keep Monday's rule?

That one question is worth more than any number of "great idea"s.

2. Questions go to the person who knows the answer

In CRUX every status on the board belongs to a role, and each role has its own agents. So questions reach the person who should know: business questions go to whoever owns the request, technical ones to a developer, test questions to QA. (See AI agents for PMs, QA and clients and the client answering in the task.)

  • People's words and agents' guesses stay apart. The original request is kept as written, and an agent says when it is guessing until a person confirms. Nobody has to wonder whether a line came from the client or from someone's chatbot.
  • Fewer meetings. Instead of a call where the whole team walks through open questions, each person has a short session in which an agent asks only their part. The team discussion keeps only what really needs everyone.

The answers land in the tracker the team already uses, so anyone can see what an agent wrote and correct it before the next steps build on it.

QA is a good example. An agent can draft test cases from the task and its approved answers. The QA engineer then spends their time on what an agent can't judge well: the risky paths, the odd user, the "this feels wrong" check.

3. A workflow instead of babysitting

A big feature becomes an ordered set of tasks, each moving through the same steps: interview, implementation, review, docs. Each step starts from a ready-made template, so you don't retype "use this skill, then verify, then open a PR", and you can see which session is working on what. (More in Stop writing prompts.) Our workflow is just one example. A team writes its own, with its own statuses, roles and checks.

4. Artifacts: context you can predict and improve

Every step ends with an artifact: a structured comment on the task. At the checkpoints (understanding, plan, result) a person approves it; between them the work goes on without anyone watching each step. The next step reads the artifacts, not someone else's chat history.

  • Predictable context. A chat keeps changing, but a posted artifact doesn't. When you start the next session, you know exactly what it will read.
  • Instructions you can improve. The artifact history shows where agents keep going wrong, so you fix the skill or prompt behind it instead of correcting the same mistake by hand.
  • Problems you can trace. A retrospective over a sprint reads the board and the artifacts. When delivery slows down or bugs start piling up, you can find when it started and why, and fix the cause instead of cleaning up after it.

For team leads and CTOs

The autonomous pitch is "fewer people needed". Ours is different: the same people, spending less time on relays and rework.

  • A visible process. Every decision, question and approval sits on a task in your tracker, under the name of the person who made it.
  • Fewer whole-team meetings, because questions go to the person who knows.
  • A process you can measure and tune, through retrospectives and the artifact history.
  • Your agents, your tracker. CRUX connects through an MCP server, so each developer keeps the coding agent they already use (Claude Code, Codex or another MCP client) on the plan they already pay for. CRUX doesn't resell model tokens or bill per agent-hour. It works on top of the tracker your team already has: Plane, Jira, Linear or GitHub Projects.

When autonomous is fine

We're not against agents that work alone. For a one-line bug with a clear reproduction, a check at every step is overkill, and your workflow can give such tasks a short path. The question is which tasks those are. For most product work the real task isn't written down yet: it's in the heads of the people around it, and an agent that asks them is faster than one that guesses.

In short

  • "Assign a task, get a PR" works when the description is the whole task. Usually it isn't.
  • CRUX agents can reach the whole project through the tracker and the wiki, including past decisions and planned work, and pick what they need for the task.
  • Questions go to the person whose role knows the answer, and people's words and agents' guesses stay apart.
  • Every step ends in an artifact, and people approve it at the checkpoints where a wrong turn is still cheap to fix. That gives predictable context, instructions you can improve and problems you can trace.
  • You keep your own coding agent and your own tracker.
All articles