AI how-to guides Technology and data
How to use AI across the software development lifecycle
Use AI at every stage, not only for writing code: to turn requirements into specs, draft code and tests, review pull requests and keep documentation current. Engineers keep design decisions, review and accountability for what ships. Roll it out with governed tools, an evaluation harness in the pipeline and a baseline so you can measure the real effect.
What AI does
- Turns requirements and conversations into structured specs, user stories and acceptance criteria.
- Drafts code, refactors and explains unfamiliar parts of the codebase.
- Generates unit and integration tests from specs and existing behaviour.
- Reviews pull requests for bugs, security issues and policy breaches before a person looks.
- Writes and updates documentation, release notes and runbooks as the code changes.
What stays with people
- Architecture and design decisions, and the trade-offs behind them.
- Reviewing and approving what gets merged, and owning it in production.
- Deciding which tools, models and data the team may use, and under what rules.
How to put it in place
-
Map current use and set a baseline
Find out which AI tools teams already use, for what and with which code. Measure lead time, pull request throughput and defect rate today, so later claims about productivity rest on data rather than anecdote.
-
Choose tools and write the policy
Compare the assistants against your stack, security model and team needs. Write down which repositories, data and models each tool may touch, how code leaves the organisation and what must never be pasted into a prompt.
-
Wire evaluation and security gates into CI
Run AI-generated code through the same tests, static analysis, dependency checks and policy rules as any other change, before merge. Add checks specific to AI output, such as invented dependencies or secrets in code.
-
Pilot in one team across several stages
Pick one team and use AI for specs, code, tests and reviews, not just autocomplete. Share prompts that work in a versioned library and record what helped and what created rework.
-
Train, measure and scale by team
Coach engineers to use assistants with judgement: when to trust, when to verify, when not to use them. Compare the metrics with the baseline and extend to the next teams only when quality holds.
What you need
- Approved AI coding tools with enterprise terms on data retention and training.
- A CI pipeline with tests, static analysis and dependency scanning you can extend.
- Integration with identity and logging, so you know who used what on which code.
- Baseline delivery metrics from your source control and ticketing systems.
- Sponsorship from engineering leadership and sign-off from security.
When it is not worth it
- Teams without tests or code review: AI will produce more code than anyone can check. Fix the basics first.
- Very small codebases or one-off scripts where a governed rollout costs more than it returns.
- When security cannot accept any external model and no approved self-hosted option exists yet.
Risks and how to control them
- Insecure or wrong code that looks plausible: keep tests, static analysis and human review mandatory before merge.
- Source code or secrets leaking to external services: use enterprise agreements, scope what each tool can see and block secrets in prompts.
- Prompt injection through files, issues or dependencies the assistant reads: treat that content as data and limit what agents can execute.
- Shadow AI and uneven practice across teams: offer approved tools that are easy to use and publish one shared playbook.
- Licence and IP exposure from generated code: enable the tools' provenance filters and keep an audit trail of AI-generated changes.
How Thinkia does it
We start by mapping current co-pilot use, your stack, security posture and the gaps between team practice and what the CISO expects. Then we set up a governed prompt library, an evaluation harness for AI-generated code and security and IP gates wired into the SDLC.
Adoption comes with a playbook, training and coaching, and telemetry measured against a baseline, so leadership sees lift with evidence. Engineering owns the rollout cadence and security signs off on the controls.
The Thinkia solution behind this guide
Frequently asked questions
Where in the SDLC does AI help most?
Usually in the repetitive parts: drafting tests, explaining unfamiliar code, writing documentation and first-pass reviews. Turning requirements into clear specs also pays off, because better input makes every later stage better.
Is AI-generated code safe to ship?
Only after the same checks as any other code: tests, static analysis, dependency scanning and human review. AI can write insecure code that looks correct, so the gates matter more, not less.
Which AI coding tool should we choose?
It depends on your stack, security model and how teams work. Compare the options on real tasks in your codebase and on their data terms, not on demos.
How do we measure whether it works?
Take a baseline before the rollout, such as lead time, pull request throughput and defect rate, and compare by team afterwards. Without a baseline, productivity claims are anecdote.
Will AI replace software engineers?
It changes the work more than it removes it. Engineers spend less time on boilerplate and more on design, review and specification, and they remain accountable for what ships.
Keep exploring
Related guides
Related decisions
- LLM evals vs human review: how should you assure the quality of enterprise AI?
- AI pilot vs production: what actually changes when you scale?