AI in the Software Development Cycle

AI tools have moved into every phase of software development. Not as a future promise — they're in use right now, on real projects, by developers who are shipping work faster as a result. But the tools aren't evenly useful across the whole cycle, and dropping one into a broken process doesn't fix the process.

This is a practical breakdown of where AI actually fits in the development cycle, based on what I've observed working on client projects over the past year.

Planning and requirements

This is the phase where AI is most underused. Developers tend to think of AI as a coding tool, but it's genuinely useful earlier than that.

Given a rough feature description, a model like Claude can turn vague ideas into structured user stories, surface edge cases you haven't thought of, and flag ambiguous requirements before they become bugs. It won't replace a product manager, but it's good at asking the clarifying questions a PM would ask.

I've used this to stress-test specs before estimation. Feed the spec in, ask the model to find holes in it, and you'll get a list of questions worth raising before the sprint starts. That's a better use of five minutes than discovering the hole mid-implementation.

Design and architecture

For architecture decisions, AI works well as a thinking partner rather than an oracle. You describe the problem — a new service, a data model, a caching strategy — and it gives you options with trade-offs. It's fast, it's reasonably thorough, and it doesn't have opinions about your company politics.

Where it falls short: it doesn't know your codebase, your team's conventions, or the legacy constraints that shaped your current architecture. Any architectural suggestion it gives you needs to be filtered through that context. It's a starting point, not a decision.

For UI design specifically, tools that generate component sketches or design tokens from a description are improving quickly, but I'd still treat their output as a draft to react to, not a finished direction.

Writing code

This is where most developers first encounter AI in their workflow, and it's where the productivity gain is most immediate. Autocomplete in an editor like Cursor or VS Code with Copilot handles the mechanical work — boilerplate, repetitive patterns, obvious implementations — so you can stay in the flow on the interesting parts.

The bigger shift is using a model conversationally for implementation. Instead of writing a utility function from scratch, you describe what it needs to do and iterate on the result. That's not laziness — it's compression. You spend time on the parts that actually require judgment.

Some patterns that work well:

• Generating test data and fixtures — tedious to write by hand, fast to generate with the right prompt
• Translating between formats — JSON to TypeScript types, SQL schema to ORM model, REST response to a typed interface
• Filling in implementations from a typed signature — write the types and the function signature, let AI draft the body
• Explaining unfamiliar code — paste a confusing function and ask what it does before you touch it

Code review

AI-assisted code review is one of the more quietly useful applications. Before sending a PR for human review, running a diff through a model catches a predictable category of issues: null checks, missing edge cases, inconsistent naming, copy-paste errors.

The key is using it as a pre-review pass, not a replacement for human review. AI misses things that require understanding of the broader system — why a particular design decision was made, what the rest of the team will find readable, whether this change fits with a direction that isn't obvious from the code alone.

What it's good at catching:

• Obvious bugs: off-by-one errors, forgotten async/await, unhandled promise rejections
• Security patterns: unsanitised input being passed to queries or HTML, hardcoded credentials
• Documentation gaps: exported functions with no description

Testing

Test generation is one of the clearest wins. Given a function, a model can produce a reasonable set of unit tests quickly — happy path, edge cases, error cases. The tests usually need adjusting, but starting from something is faster than starting from nothing, and the model's edge case suggestions are often genuinely useful.

For integration and end-to-end tests, the lift is higher because the model needs context about your application's behaviour that you'd have to provide explicitly. It's more effort to prompt well, but still faster than writing everything by hand.

One pattern worth knowing: feed the model a failing test and the function it's testing and ask it to explain why the test fails. That's often faster than reading the stack trace yourself, especially in unfamiliar code.

Deployment and monitoring

AI is further from the core workflow here, but it's moving in. A few areas where it's becoming useful:

• Anomaly detection in logs — models can summarise large volumes of log output, identify unusual patterns, and flag things worth investigating
• Incident postmortems — given a timeline of events and logs, AI can help draft a structured incident report faster than writing from scratch
• Infrastructure as code generation — Terraform, Kubernetes manifests, Docker configs — the kind of config that's hard to write from scratch but straightforward once you know what you need

I wouldn't put AI directly in the path of production decisions yet. But as a tool for understanding and documenting what happened after the fact, it's already useful.

An honest take on the limits

The pattern across every phase is the same: AI is most useful for the mechanical parts, least useful for the parts that require understanding of context that isn't in the prompt. That context — your codebase, your team, your constraints, your users — is the thing you know and the model doesn't.

A few things I'd push back on:

• AI doesn't replace thinking. If you accept AI output without understanding it, you own whatever bugs are in it. The review step is not optional.
• Speed isn't free. Moving faster on the wrong thing is still wrong. AI amplifies your direction, good or bad.
• Tool sprawl is real. There's a cost to evaluating, integrating, and maintaining every new AI tool that comes out. Selective adoption beats reflexive adoption.

Used well, AI compresses the low-judgment work so you can spend more time on the high-judgment work. That's a real productivity gain. But it requires knowing which is which.

← All articles  ·  Portfolio