How to Use AI in Software Development

The popular advice on how to use AI in software development is wrong in one important way. It tells you to pick a coding assistant, let everyone generate more code, and measure success by accepted suggestions. That approach can make a busy team busier without shipping a safer release any sooner.

Buy the business outcome first. Do you need faster time to market, more delivery capacity, lower cost per release, less production risk, or better quality? Pick one constraint, name its metric, and refuse AI work that can't improve it. AI changes delivery economics. It doesn't lower the standard for architecture, data, security, testing, or production quality.

Map AI to Each Delivery Stage

Say a product team adds coding assistants and output climbs fast. Pull requests get longer, senior engineers spend their days unpicking plausible code, and the release date doesn't move. Review queues, rework, and unstable changes absorb the gain. That's not an AI failure. It's a delivery design failure.

Google's 2024 DORA research found that a 25% increase in AI adoption was associated with a 7.5% improvement in documentation quality, a 3.4% improvement in code quality, and a 3.1% increase in code-review speed. The same analysis associated increased AI adoption with a 1.5% decrease in delivery throughput and a 7.2% reduction in delivery stability. DORA attributed that trade-off to weak delivery fundamentals, including large batch sizes and insufficient testing.

Read that carefully. Better local activity can coexist with worse end-to-end delivery. If generation speeds up but batches grow, tests stay thin, and reviewers become a bottleneck, you've bought motion, not progress.

Start With the Constraint, Not the Tool

Adoption is already mainstream. Stack Overflow's 2025 Developer Survey collected responses from more than 49,000 technologists across 177 countries and found 84% of respondents were using or planning to use AI tools, up from 76% in 2024, while 51% of professional developers reported using AI tools daily. Agents lag behind, with 31% of respondents already using them, 17% planning to use them, and 38% having no plans to adopt them.

That gap gives you the right sequence. Start with governed augmentation in high-volume, reviewable work such as code explanation, test generation, documentation, refactoring suggestions, migration assistance, and repository search. Add more autonomous agents only where permissions, observability, rollback, and human approval already work.

Practical rule: If a proposed AI use can't name its business constraint, owner, and metric, don't fund it yet.

Our AI route to production has four stages: Discover, Design, Build and prove, and Operate. AI work starts with the business process, opportunity, and process economics before any technology selection, with model and architecture decisions made last, on evidence. When AI accelerates implementation, senior engineers remain accountable for data, security, integration, and production quality. If you want a broader view of that operating model in practice, this practical AI driven development guide is useful context for comparing governed delivery with tool-led experimentation.

Put an Owner and a Metric on Every Stage

Where AI belongs across the delivery lifecycle

Stage	AI may accelerate	Engineer still owns	Measure
Discovery	Process notes, opportunity sizing, draft acceptance criteria	Scope, economics, and whether AI is warranted	Analysis time and decision lead time
Design	Option sketches, interface drafts, threat prompts	Architecture, data model, security boundaries	Rework after design review
Implementation	Boilerplate, adapters, migration slices, docs	Diff approval, dependencies, failure paths	Cycle time and review rework
Testing	Unit, contract, and characterization test drafts	Test strategy and what counts as evidence	Escaped defects on critical paths
Release	Changelog drafts, runbook checks, incident summaries	Go-live, rollback, and production ownership	Throughput and change-failure rate

In discovery, let AI turn workshop notes into process maps and draft acceptance criteria. A lead still decides whether the opportunity justifies the spend. In design, let an agent sketch interface options and surface threats. Your architect still owns data boundaries and failure behavior.

During implementation, aim agents at boilerplate, adapters, and narrow migration slices. A senior engineer approves each diff and its failure paths. In testing, agents can draft checks quickly, but engineers decide what evidence is strong enough to ship. At release, agents can prepare changelogs and runbooks. A named person still says go, no-go, or roll back.

Before rollout, baseline one week of lead time, review rework, and escaped defects. Without that baseline, you'll argue from impressions while costs move somewhere else in the system.

Keep Code Generation Inside a Review Loop

Treat an assistant from GitHub Copilot, Cursor, Claude Code, or a similar tool as an acceleration layer, never as the implementation authority. The engineer who'll live with the system owns the result. That distinction protects both speed and quality.

The loop below turns a good intention into a habit your team can enforce on the next pull request.

Seven Moves Before You Merge

1. Define the target first: Write acceptance criteria, architecture constraints, the threat model, and test cases before the first prompt.
2. Require a small plan: Ask the model to propose a change plan and identify affected modules, then reject plans that sprawl across unrelated areas.
3. Generate one narrow commit: Target boilerplate, adapters, migration slices, test scaffolding, documentation, or repository navigation.
4. Demand tests with the code: Require unit and integration tests, plus security tests where the change handles input, authorization, or sensitive data.
5. Run automated checks: Use static analysis and dependency scanning, and block unapproved packages before review.
6. Review the reasoning: Have a senior engineer read the diff, assumptions, and failure paths, not just the green test result.
7. Compare against baseline: Measure cycle time, escaped defects, review rework, and post-release incidents against pre-AI performance.

Tool choice matters less than whether the environment supports this discipline. If you're evaluating editors for agentic work, it helps to compare IDEs for vibe coding against your review, permissions, and testing requirements rather than demo speed.

Bank the Speed Where It's Real

The evidence supports targeted use. A preregistered controlled experiment reported in Empirical Software Engineering involved 151 participants, 95% of them professional developers, and found a 30.7% median reduction in completion time with an AI assistant, while habitual users showed an estimated 55.9% speedup. When other developers later evolved those AI-assisted solutions without AI, the study found no significant difference in completion time or code quality, and any maintainability advantage was at most small and uncertain.

That tells you where to invest. Bounded, testable work is the sweet spot. Architecture, data models, integrations, security, and production approval stay with accountable engineers.

This short walkthrough shows the review discipline in action rather than generation in isolation.

Speed is a measured outcome, not a substitute for engineering controls.

Don't let a fast first draft set the scope. If the model proposes a broad refactor when you asked for one adapter, stop and cut the batch. Smaller diffs review faster, fail more clearly, and roll back cleanly.

Prove the Change Before You Ship It

Passing tests show that a change behaves as expected in tested cases. They do not prove that AI-generated code is secure, maintainable, or ready for production. Treat release evidence as a set of distinct checks, not a single green light.

An arXiv evaluation of generated code quality found no direct correlation between a model's functional performance, measured by Pass@1 unit-test success, and overall code quality and security, measured using SonarQube issues in solutions that passed functional tests. Code can pass on the happy path yet expose data, mishandle errors, or leave a maintenance problem. Review the change against each risk it introduces.

Seven Gates, Seven Different Failures

Production gates for AI-assisted changes

Gate	Evidence required	Failure it catches
Deterministic tests	Unit and integration tests green on the change	Broken behavior that a demo hides
Mutation or negative tests	Critical logic fails when mutated or given bad input	Suites that only repeat the happy path
SAST and dependencies	Findings cleared or explicitly waived by an owner	Injection, weak crypto, unapproved packages
Secret detection	No credentials or tokens in the diff	Hardcoded keys reaching the repo
Auth and input tests	Authorization and validation covered on the API	Missing access control or unchecked input
Performance checks	Database, concurrency, and resource use reviewed	Slow queries and unsafe load
Human review	Maintainability, observability, rollback, and regulation checked	Large diffs and unowned production risk

Each gate has a specific job. Deterministic tests check behavior, while mutation and negative tests challenge whether the suite detects incorrect logic. Static analysis and dependency scanning flag insecure patterns and packages the team has not approved.

Secret detection keeps credentials out of the repository. Authorization and input-validation tests check who can do what, and how the system responds to hostile input. Performance checks examine database calls, concurrency, and resource use. Human review covers judgments automated checks cannot settle, including maintainability, observability, rollback safety, and regulatory duties.

Make security checks enforceable in the delivery pipeline, with findings assigned to an owner and explicit waivers recorded. The practices described in building security controls into delivery pipelines can inform how teams structure those controls. Keep the gates proportionate to the change, but do not let generated code bypass them.

Make Reviewable Evidence Easy to Inspect

Track test pass rate, security findings per change, maintainability violations, review-request rate, escaped defects, and reverts separately. A high pass rate alone can conceal work shifting into review or production.

Preview environments let reviewers test the exact change, rather than relying on a description or code diff alone. Teams can review Vercel preview deployments to attach stakeholder and reviewer feedback to the version under test.

Watch for four traps:

• Green means safe: Passing tests do not prove secure behavior.
• Huge diffs: Changes too large to inspect leave reviewers guessing.
• Happy-path bias: Missing boundary and adversarial cases leave defects undetected.
• Silent supply-chain changes: A generated package or credential can introduce risk without clear review.

AI-generated code belongs in the same pull-request, CI, security, and release process as human-written code. Keep diffs small and name a reviewer. A change without an owner and a rollback path is not ready to ship, no matter how quickly it was produced.

Modernize Legacy Systems in Reversible Slices

Legacy modernization is where casual AI advice breaks down. An agent doesn't just face old code. It faces undocumented dependencies, data contracts other systems rely on, security boundaries nobody wrote down, and behavior that already supports revenue.

A Springer study on AI-assisted development concerns identified generated-code risks including improper input validation, hardcoded credentials, weak cryptography, and injection vulnerabilities, and a 2025 mixed-methods study of 114 developers identified workflow-integration, accuracy, reliability, and ethical concerns around Copilot and ChatGPT use. In a legacy estate, those aren't abstract risks. One wrong assumption can be copied across dozens of generated files before anyone notices.

Preserve Evidence Before You Transform Anything

Start by assessing data reality, quality, and access early, and define risk, regulation, and operating ownership up front. Then work in reversible slices:

• Inventory first: Map dependencies, data contracts, batch jobs, integrations, and owners before rewriting a module.
• Lock current behavior: Add characterization tests around legacy behavior, including odd edge cases users may depend on.
• Propose one slice: Let AI draft one bounded migration or transformation, not a wholesale replacement.
• Review invisible assumptions: Have an architect challenge data meaning, transaction boundaries, and security assumptions the model can't see.
• Test the seams: Run static and dynamic security analysis plus contract tests against neighboring systems.
• Stage the release: Deploy behind a controlled rollout with a numeric rollback trigger, such as an error-rate threshold or failed contract check.
• Keep an audit trail: Retain prompts, decisions, and diffs so a future owner can explain why the change exists.

Those controls should include security boundaries and access control for models and data, human approval steps with explicit exception handling, auditability of decisions, prompts, and actions, and evaluation, monitoring, and model operations after go-live. For the wider modernization sequence, our legacy system modernisation guide for CTOs sets out how to sequence risk before replacement.

The sponsor's question isn't whether an agent can draft replacement code. It's whether every change is traceable, testable, reviewable, and reversible.

AI is excellent at migration analysis, repetitive transformation, code explanation, and draft test creation. It's dangerous when you give it broad write access and ask it to infer business rules from incomplete code. Keep its permissions limited to the slice, its diff small, and its output tied to characterization and contract evidence.

Don't approve big-bang rewrites. Don't let an agent touch production data to learn the system. Don't ship a slice without a rollback owner who can act without a meeting. Extreme ownership means naming that person before deployment, not during the incident.

Read the Signals That Show AI Is Hurting Delivery

Don't judge AI by lines generated, prompts sent, or suggestions accepted. Judge it by whether safe releases reach users faster without creating downstream work.

Use the baseline you captured before rollout and read five signals together every two weeks: lead time, review rework, escaped defects, throughput with change-failure rate, and reviewer understanding. Our view on measuring engineering efficiency without gaming the numbers applies here too. One attractive metric can hide damage in the other four.

Read the Pattern, Not the Headline

Signals that separate real gains from hidden costs

Signal	Healthy pattern	Warning sign
Lead time	Falls against the baseline while failures stay flat	Falls at coding but release wait grows
Review rework	Stable or lower per change	Climbs as diffs grow larger
Escaped defects	Flat or falling on critical paths	Rising after AI-heavy releases
Throughput and change-failure rate	Both improve together	Throughput rises while failures rise with it
Reviewer understanding	Reviewers can explain each approved diff	Diffs are approved that nobody can explain

If coding gets faster but release wait grows, your bottleneck moved to review, testing, or approval. Adding more generation will make that queue worse. Shrink batches, increase reviewer capacity, or improve automated evidence.

If rework climbs with diff size, cut scope before you tune prompts. If escaped defects rise after AI-heavy releases, tighten gates before expanding agent access. If reviewers can't explain a diff, stop merging that class of change until a senior engineer owns it.

Set a numeric trigger for each signal in advance. Decide who acts, what they'll change, and when you'll pause rollout. Review the pattern with the stage owners, not just engineering management.

Speed is only a win when rework, defects, stability, and reviewer understanding hold.

That's the commercial test. Faster drafting that creates slower releases, more incidents, or code nobody understands hasn't reduced cost. It has deferred cost and added interest.

Pick the First Slice and Name the Owner

You don't need an enterprise-wide AI transformation to start. You need one valuable slice, one measurable constraint, and one person accountable for the production result.

The standard doesn't move. AI changes the cost and speed of delivery, but it doesn't lower the bar for architecture, data, security, tests, or production ownership. Choose the entry point that matches your current clarity.

Three Practical Starts

• The opportunity is fuzzy: Commission an AI opportunity assessment, readiness review, or roadmap for a fixed fee priced by complexity, starting from the business process and its economics.
• The slice is defined: Contract defined automation or AI system delivery as fixed scope and fixed price against agreed acceptance criteria, with human approval gates and production evidence.
• A previous AI build has stalled: Assess the code, data, architecture, and security position before adding more generation, then stabilize what's viable and prepare a controlled path to release.

After the first slice, good looks concrete. The batch is smaller. Tests and scans run in the same pipeline as human code. A reviewer can explain the diff. You have a before-and-after read on lead time, rework, defects, and incidents.

Rite NRG runs this as RiteWay, combining architecture before generation, AI-accelerated execution, human approval gates, and production evidence. We use AI when it creates measurable value and conventional software when that's simpler, safer, or more economical. That's the consulting mindset we'd want from a partner spending our money. Challenge the assumption, show the trade-off, and take responsibility for the complete result.

Bring one process, one constraint, and the name of the person who'll own the release. We'll help you decide whether AI belongs in that slice, what evidence will prove it worked, and where experienced architects must stay firmly in charge.

---

Rite NRG helps companies scope an AI opportunity assessment or deliver a defined, production-ready slice with senior engineers accountable for architecture, security, testing, and release quality. If you want faster delivery without betting production stability on unchecked generation, visit Rite NRG and bring us one process, one constraint, and your release owner.