AI-Assisted Software Development

What is AI-assisted software development?

It is software development in which a model participates in producing the artefacts: code, tests, documentation, migrations and review comments. The developer stays the author. The model behaves like an extremely fast contributor with broad recall, no knowledge of your domain, and no sense of its own uncertainty.

The term sits alongside several others that are often used interchangeably and should not be:

How it works: three tool shapes, three different jobs

Most confusion about this topic comes from treating three quite different tools as one thing.

1. Completion. The model predicts the next lines inside your editor from surrounding context. Low friction, low risk, best inside a codebase whose conventions are already visible. It is the shape most developers meet first.

2. Chat with context. You ask a question with files attached. Strongest for explaining unfamiliar code, proposing an approach, drafting a test suite or debugging a stack trace. The developer still integrates the answer by hand.

3. Agents. The model plans a change, edits multiple files, runs the tests, reads the failures and iterates until the task passes or it gives up. This is where the largest gains and the largest risks both sit, because the diff arriving for review can be far bigger than a person would have written.

The rule that makes agents safe is not a better prompt. It is a verifiable success condition: a test suite, a type checker, a migration that either applies or does not. Agents are reliable exactly to the degree that success is checkable by a machine.

The tools teams actually use

• Editor completion: GitHub Copilot, Tabnine, Amazon Q Developer, Google Gemini Code Assist.
• AI-native editors: Cursor, Windsurf, which hold whole-repository context while you edit.
• Terminal and agent tools: Claude Code, Codex-style agents, and the agent modes built into the editors above.
• Cloud-tied assistants: Google Gemini in Google Cloud, Amazon Q in AWS, tied to the estate they run in.
• Review and quality: Sonar and similar static analysis, which matter more once generated volume rises.
• Security: Snyk, Semgrep and similar, for vulnerability detection and suggested fixes in the pipeline.

Companies using AI for coding at scale now include most large technology firms, which publish adoption claims that are worth reading as positioning rather than as measurement. Self-hosted options exist for organisations whose code cannot leave their environment, at a capability cost that is narrowing but real.

Can AI write production-grade code safely?

Yes, under two conditions, and no without them.

The first condition is a checkable definition of done. Where a test suite, a type system or a schema can verify the result, generated code is about as safe as any other code, because the same gate catches the same failures.

The second is review proportional to consequence. The defects that survive AI assistance are not syntax errors. They are plausible implementations of a rule the model was never told: the discount that should not apply to the second item, the permission check that covers reads but not writes, the timezone that is correct in the office and wrong for half the customers.

Where both conditions fail at once, which is typically authorisation logic, money arithmetic, concurrency and cryptography, the honest answer is that the model produces a starting point and a person does the work.

Can AI help with security fixes?

It helps in two distinct ways, and they are worth separating.

• Detection of known vulnerable patterns is a good fit for automation, and tools have done it for years with AI now improving the signal-to-noise ratio and reducing false positives.
• Remediation suggestions are useful for dependency upgrades and well-known classes such as injection or unsafe deserialisation, and much weaker for design-level flaws, because a broken authorisation model is not a pattern in one file.

The risk running the other way deserves equal attention. Generated code brings dependency suggestions, and models will confidently recommend packages that are abandoned, or occasionally that do not exist at all, a gap attackers have already learned to occupy by registering the invented names. A dependency allowlist and a licence scanner in the pipeline are the two controls that pay for themselves.

Are agents ready to own tickets?

Partly, and the boundary is sharper than the debate suggests. Agents do well on tickets that are mechanical, bounded and verifiable: dependency upgrades, framework migrations, adding a field through a stack, test coverage for existing behaviour, renaming across a repository, and converting one format to another.

They do badly on tickets that are under-specified, which is most tickets. An agent given “fix the reporting bug” will produce something confident and often beside the point, because the real work was deciding what correct means.

The practical pattern in teams that get value: an agent opens the pull request, a human reviews it exactly as they would any contributor’s, and the ticket is not closed by the machine. The interesting bottleneck is no longer generation. It is review capacity.

What the evidence says about productivity

Be careful here, because this is where the topic is least honest. Most circulated figures come from tool vendors measuring their own tools, often via suggestion acceptance rate, which counts keystrokes saved and says nothing about whether the software got better or arrived sooner.

The findings that recur across independent studies are narrower and more useful:

• Gains are largest on unfamiliar or boilerplate work and smallest on complex work in a codebase the developer knows well.
• Gains are larger for less experienced developers on routine tasks, and can invert for experts, who sometimes spend longer reviewing a suggestion than writing the line.
• Perceived speed exceeds measured speed. Developers report feeling faster more consistently than the delivery data shows they are.
• Throughput rises before quality falls, and where quality falls it shows up later, as rework and escaped defects, which is why year-one enthusiasm and year-two disappointment are both common.

The measurements worth running on your own team: lead time for change, change failure rate, review latency and size, defect escape rate, and the share of generated code rewritten within thirty days.

What goes wrong: the failure modes in order of frequency

1. Review becomes the bottleneck. Output rises, review capacity does not, and large diffs get approved on trust.
2. Plausible-but-wrong logic. Code that runs, reads well and encodes a rule nobody stated.
3. Test theatre. Generated tests that assert what the code does rather than what it should do, which locks in the bug.
4. Dependency sprawl. Suggested packages accepted without checking maintenance, licence or existence.
5. Context loss. The model does not know last quarter’s decision, so it reintroduces the thing you removed deliberately.
6. Skill erosion. Junior developers who never debug without help build less of the model that lets them review well later.
7. Tool integration complexity. Five tools, five configurations, five permission models, and a pipeline nobody fully understands.
8. Policy discovered late. A client security review asks where the code went, and nobody wrote the answer down beforehand.

Practices that separate the teams it works for

• A named human author on every change, accountable regardless of how it was produced.
• Pipeline gates unchanged for generated code: static analysis, security scanning, coverage.
• Review scaled by consequence, not by diff size, with a second reviewer on access control, money and data handling.
• A verifiable success condition before any agent is given a task.
• A dependency allowlist and a licence scanner in the pipeline.
• Written policy on which tools are approved and where code may go, agreed before the first commit.
• Measurement of lead time and change failure rate, so the claim can be falsified.
• Deliberate learning paths for junior developers that include working without assistance.

The future of software development

Three directions look reasonably safe to state, and one does not.

Reasonably safe. The unit of work keeps growing, from line to function to task to ticket. Verification gets more valuable in proportion, which means tests, types and specifications become the artefacts that matter most. And the review surface becomes the main design problem in a development process, because it is where everything now queues.

Not safe. Predictions that developer headcount collapses on a stated timetable. Those have been made in every tooling wave, and they misread what the job is: deciding what should exist, judging which failure is unacceptable, and being accountable to someone for the result. A system that cannot be held responsible cannot hold that part of the job.

The more likely shape is the one already visible: fewer people typing routine code, more people specifying, reviewing and integrating, and a larger volume of software in existence with all the maintenance that implies.

Working this way with SoluLab

We deliver with AI assistance under a written policy agreed with the client: approved tools, where code may go, human authorship on every change, unchanged pipeline gates, and review capacity planned into the estimate.

FAQ