From a question in standup to a pull request in review.
Six steps, in the order they happen. The same loop covers a new feature, a spec that needs checking and a number that moved overnight. Below the steps there is a full worked example, start to finish.
The six steps in full.
-
Connect your product stack
Authorise your issue tracker, your document tools and your code repositories. You choose the scopes and the projects. Steelax indexes what it can reach, then reports back on what it found and what it was refused, so there is no silent blind spot in the picture it has.
Typical first connection: one tracker, one docs space, one repository.
-
Ask the question you actually have
Not a prompt, a question. How does password reset work today. Does this spec match what we built. Why did checkout conversion fall last week. Which parts of the billing flow have no tests. Steelax answers from the connected systems and shows the evidence behind each part of the answer.
Answers cite files, issues and documents by name.
-
Shape the intent together
This is the conversation that normally happens in a hallway and is never written down. Steelax challenges the parts that do not hold, proposes a scope the architecture can actually support, separates what it is confident about from what it is guessing, and keeps your broader direction in view while it does it.
The rejected options are kept, with the reason they were rejected.
-
Generate the tasks
When the shape is agreed, Steelax writes the work: linked tasks covering interface, logic, integration and data, each carrying the problem, the approach, the files in scope, the edge cases and the open questions. Anything requiring judgment is held back and assigned to a person instead of being guessed at.
Pushed to your tracker with your labels, your project, your format.
-
Hand the right tasks to the agent
You choose which tasks go to the coding agent and which stay with your team. The agent clones the repository into an isolated environment, reads the surrounding code, makes the change on a branch, and runs your test and lint suites before it offers anything for review.
It stops and asks when a task turns out to be larger than its scope.
-
Review, steer, merge
The result is an ordinary pull request in your repository, linked back to the task and the session that produced it. Your reviewers see the diff next to the reasoning that led to it. Approve it, send it back with notes, or take it over by hand with none of the context lost.
Merging and deploying stay entirely with your team.
Checkout conversion dropped twelve percent.
One real-shaped problem, carried through the whole loop. The point of the example is not the fix, it is how much context is still attached at the end.
The question
The weekly dashboard shows completed checkouts down twelve percent against the previous week. Nothing shipped to the checkout flow. The payments provider reports no incident. The product manager asks Steelax the only question anyone has: what changed.
Steelax pulls the events, the recent deploys across all connected services, and the error logs referenced in the tracker, then narrows to the one thing that correlates.
Checkout completions are down twelve percent week on week. We did not ship anything here. What changed?
Nothing shipped in checkout, but payments-service moved to the new gateway client on Tuesday. Declines are up, and every decline now returns a generic error instead of a reason code.
Drop-off is concentrated on the failure screen, not the form.
The shaping
The first instinct is a retry button on the failure screen. Steelax pushes back, because the code says the problem is upstream of that: the form remounts on a declined charge and clears the card fields, so the customer is being asked to type everything again before they can retry anything.
It also finds a second problem that a retry button would have made worse. The charge endpoint is not idempotent, so a customer pressing retry twice can be charged twice.
Add a retry button to the failure screen then.
That would ship a double-charge bug. charge.ts sends no idempotency key, so two presses create two authorisations.
Fix the state loss and the idempotency first. The retry button becomes a two-line change once they are in.
Agreed scope. Keep form state through failure, make retries idempotent, pass the real decline reason to the client, split the metric by failure type.
The tasks
Four linked tasks land in the tracker twenty minutes later, grouped under the same parent and labelled for the checkout project. Each carries the diagnosis, not just the instruction, so the engineer picking one up does not need the thread it came from.
One task is held back. The wording customers see when a card is declined has legal implications, so Steelax drafts nothing and assigns the question instead.
Assigned, not written. Customer-facing decline wording goes to the product lead for legal review.
The implementation
Two of the four tasks are mechanical enough to hand over. The agent takes CHK-412 and CHK-413, works in an isolated environment, lifts the card state out of the component, adds idempotency keys on the charge path, and writes two tests for the retry case.
It raises one open question on the way: how long stored idempotency keys should live. That goes into the pull request description rather than being decided quietly in code.
The review
An engineer opens the pull request and sees the diff next to the diagnosis that produced it: the gateway change on Tuesday, the remount, the missing idempotency key, the two tests added. They answer the open question about key expiry in a comment, approve one, and request a change on the other.
Nothing about the original problem had to be re-explained. The reason the work exists travelled with the work.
What the reviewer had in front of them
- The diff, on a branch, with the full test run attached
- The task, including the approach taken and the two rejected
- The diagnosis that started it, with the deploy that caused it
- One open question, stated plainly and left for a person
- The complete log of files the agent read and wrote
Who does what.
Useful automation is specific about where it stops. This is the line we hold.
| Step | Steelax | Your team |
|---|---|---|
| Connecting systems | Indexes what it is given access to and reports the gaps | Chooses the scopes, projects and repositories |
| Answering questions | Produces the answer with its evidence | Judges whether the evidence supports the answer |
| Shaping work | Challenges assumptions and proposes a scope | Decides the scope and accepts the trade-offs |
| Writing tasks | Drafts, links and publishes them to the tracker | Edits, reprioritises and assigns |
| Implementation | Implements the tasks you hand over, on a branch | Chooses which tasks are handed over |
| Quality | Runs your existing tests and linters | Owns the suite and the standards it encodes |
| Review | Explains the change and the reasoning behind it | Approves, rejects or rewrites |
| Merge and release | Nothing | Everything |
What the first month usually looks like.
Teams that get value quickly tend to follow the same path. Start narrow, build trust on questions before tasks, and only hand work to the agent once you have read a few of its task descriptions.
You do not need to connect everything, restructure your backlog or change how your team works to begin.
-
Week one: questions only
Connect one tracker and one repository. Ask the things new joiners always ask. Check the answers against what you already know to be true.
-
Week two: shape one idea
Take something half-formed that has been sitting in a backlog and work it through. Read the scope proposal critically.
-
Week three: generate tasks
Publish one task set to the tracker and let an engineer pick it up cold. The quality of a task is measured by how few questions it generates.
-
Week four: hand over the mechanical work
Give the agent the tasks that are well understood and low risk, and review the pull requests as you would any other.
Common questions about the loop.
Do we have to give write access to start?
No. Steelax begins with read-only scopes on every system. Publishing tasks to your tracker requires write access to that tracker, and the coding agent requires permission to push a branch. Both are granted separately, later, and either can be refused without disabling the rest of the product.
What happens when Steelax is wrong about the codebase?
Correct it in the session. Steelax carries the correction forward into the shaping and into any tasks generated afterwards, and records it against the relevant part of the product so the same mistake does not reappear next week.
Answers always name their sources, which makes a wrong answer quick to spot. That is deliberate. An ungrounded answer that sounds right is worse than no answer.
Can we use the shaping and task generation without the coding agent?
Yes, and plenty of teams do for the first few months. The agent is a stage, not a requirement. Everything up to and including publishing tasks to your tracker works with no write access to any repository.
How large a task can the agent handle?
The agent is reliable on well-scoped changes within a few related files: state handling, API plumbing, instrumentation, straightforward refactors, test coverage. It is not the right tool for an architectural change or anything that needs a product judgment call mid-flight.
When a task turns out to be bigger than it looked, the agent stops, writes up what it found and hands back rather than pushing on.
Does it work on a monorepo or across several services?
Both. Repositories are connected individually, and Steelax links work across them, which is how it spots that a checkout problem originates in a payments service deploy. For a monorepo you can scope it to the directories that matter to your team.
What if our documentation is out of date?
Most of it is, everywhere. Steelax treats the code as the authority on behaviour and documents as the authority on intent. Where the two disagree it reports the conflict rather than picking a winner, which in practice is one of the more useful things it does in the first week.
Run the loop on a problem you already have.
Bring the thing that has been stuck in the backlog for a month. Forty-five minutes on your own systems tells you more than any demo of ours.