Software engineering agent

Software engineering agent

Engineering time is the most expensive time in the business. The agent that works alongside engineers changes the economics of the engineering work.

The workflow

1. The engineer creates an issue or selects an existing one. The agent reads the issue, the relevant code, the related tests.
2. The agent proposes a change: code, tests, documentation. The proposal is a pull request.
3. The CI runs. The agent reads the CI results. If the CI fails, the agent reads the failure and proposes a fix.
4. The agent proposes a review of the pull request. The agent checks for style, tests, security patterns, existing patterns in the codebase.
5. The engineer reviews the proposal. The engineer accepts, rejects or requests changes. The merge is the engineer’s decision.
6. The agent updates the documentation to reflect the change.

What this looks like in production

The agent operates inside the existing toolchain. The agent does not have write access to main without an approved pull request. The agent does not bypass code review.

The agent’s proposals are evaluated against the codebase’s existing standards. The agent is configured with the repository’s style guide, the test coverage expectations, and the security review requirements.

The agent learns from the engineer’s feedback. When the engineer requests changes, the agent uses the feedback to improve the next proposal.

What good looks like

• Engineering time shifted from context switching to design and judgement.
• Pull request cycle time reduced, with the agent as the first-pass reviewer.
• Test coverage and documentation kept in sync with the code.
• Engineer satisfaction with the agent measured, and the deployment adjusted accordingly.