AI in software development
This is about the workflow rather than the tools. The tools change every few months; the way the work reorganises around them has been fairly stable.
Statements about other products were checked on 23 September 2026 and are cited at the foot of this page.
The bottleneck moves
The work of writing code goes down. The work of deciding whether code is correct does not, and it is now spread across more changes than before. So the constraint moves from authoring to review, and a team that does not notice this ends up with a review queue instead of a backlog.
The second-order effect is the one that hurts: when there is more to review than there is attention to review it, review quality falls quietly. Nobody decides to rubber-stamp. It just becomes the only way to keep up.
The failure modes that actually show up
| Failure | What it looks like | What helps |
|---|---|---|
| Done without checking | The agent reports success. Nothing was run. The change does not work. | Require the agent to run something, and show what it ran. |
| Confident edits to unseen code | A caller in a file the agent never opened is now broken. | Retrieval across the repository, not just open files. |
| Review fatigue | Large diffs approved quickly, defects found in production. | Smaller units of change; agent output reviewed as strictly as a colleague's, not more leniently. |
| Tests become load-bearing | They were a safety net. They are now the specification the agent is working against. | Verify that a test fails when the behaviour it guards is removed. |
That last one deserves more attention than it gets. A test that passes whether or not the behaviour exists was always useless, but it used to be harmless. When an agent is iterating until the suite is green, a test like that actively steers it wrong.
What becomes worth measuring
- Change failure rate, before and after. This is the number that tells you whether review is keeping up.
- Time from change proposed to change reviewed, which is where the new queue forms.
- How often the agent is wrong in a way the tests did not catch. This is the honest measure of whether your suite is specification enough to work against.
What this implies for tooling
Most of the failures above are not model failures, they are process failures that tooling can either mitigate or worsen. The properties worth insisting on are unglamorous: the agent should read more than your open files, it should run your commands and show you what it ran, it should verify before it claims to be done, and it should not leave you guessing which model can do the job.
AstraCode is built to those properties. Its agents plan across the repository, run your tests and prove them, and check their own work before they report, while AstraOne chooses the model and brings in a stronger one when a check fails. Because the same agent runs in the editor, the terminal, CI and pull requests, a team gets one way of working wherever the work happens.
Sources
- JetBrains AI Assistant — JetBrains' own description of the assistant built into their IDEs. Checked 23 September 2026.
- GitHub Copilot documentation — Copilot as an extension to an existing editor rather than an editor of its own. Checked 23 September 2026.