In most software teams today, a meaningful share of new code is written with help from an AI assistant. Autocomplete suggests whole functions, chat tools generate components from a description, and agentic tools can change several files at once to implement a feature. The productivity gains are real. So are the new risks, and teams that do well are the ones that adjust how they work rather than simply typing less.
This article is written for engineering leads, business owners who manage a development team, and developers trying to use these tools well.
What genuinely gets faster
- Boilerplate. CRUD screens, form validation, API client code, data mapping and configuration files.
- Tests. Generating test cases for existing functions, especially edge cases a tired developer might skip.
- Unfamiliar territory. A developer who knows Laravel but needs a small Python script gets productive far faster.
- Reading code. Explaining an old, undocumented module is one of the most underrated uses.
- Migrations and refactors that follow a clear, repetitive pattern across many files.
What does not get faster, and sometimes gets slower
Understanding the problem
AI cannot tell you that the client actually needs a different workflow from the one described. Requirements, trade offs and business rules still take conversations with people. We cover that in the software requirements checklist.
Architecture
Assistants optimise for making the current task work. They rarely consider how today’s shortcut affects the system in a year. Data models, service boundaries and integration design still need experienced judgment. See microservices versus monolith and database design mistakes.
Code review
When code is produced faster, more code needs reviewing. AI generated code often looks clean and plausible, which makes subtle bugs easier to miss. Many teams find review becomes the real bottleneck.
Debugging generated code
Fixing a bug in code nobody on the team fully understands takes longer than fixing code a teammate wrote deliberately.
The risks to manage
Security
- Missing authorisation checks, where a user can access another user’s data.
- Unsafe handling of user input leading to injection vulnerabilities.
- Secrets pasted into prompts, or hardcoded by generated code.
- Suggested packages that are outdated, unmaintained or do not exist, which attackers can exploit by publishing malicious packages with those names.
Licences and ownership
Understand your tool’s terms on code ownership and whether it filters suggestions that match public code. For client projects, confirm the client has no restrictions on AI use.
Inconsistency
Different developers prompting differently produce different patterns for the same problem. Without shared conventions the codebase fragments quickly.
Team rules that work
- The author owns the code. Whoever commits it must understand it well enough to explain and debug it. “The AI wrote it” is never an answer in review.
- Same review standard for all code. AI assistance does not lower the bar. For security sensitive areas such as authentication, payments and permissions, review more carefully.
- Tests are mandatory for generated logic. If AI wrote the function, AI can help write the tests, and a human checks that the tests are meaningful.
- Document conventions the assistant should follow. Many tools read project instruction files. Put your architecture rules, naming conventions and forbidden patterns there.
- No secrets in prompts. Use environment variables and secret managers, and scan commits for leaked keys.
- Check every new dependency. Confirm it exists, is maintained, and is actually needed.
- Keep changes small. Large AI generated pull requests are hard to review properly. Break them up.
For company wide guidance beyond engineering, see how to write an AI use policy.
What happens to junior developers
This is the question many team leads worry about most. Juniors who lean entirely on AI can ship features without learning why they work, and then struggle badly when something breaks. On the other hand, AI can be a patient tutor that explains every line.
Approaches that help juniors grow:
- Ask them to explain generated code line by line in review.
- Assign some tasks where they write the first version without assistance, then compare with AI suggestions.
- Pair them with seniors on debugging, which AI helps least with.
Students and interns can find more on this in using AI to learn programming.
How to measure whether it is working
Lines of code is a misleading metric, since AI inflates it. Better signals:
- Time from task start to production deployment.
- Bugs found in production per release.
- Time spent in code review and rework.
- Developer satisfaction and burnout.
If speed rises but production bugs rise with it, the team is skipping the review and testing discipline described above.
What clients should ask a development partner
- Which AI tools do you use, and under what account and data terms?
- How do you review AI generated code?
- How do you prevent our confidential code and data from leaking?
- Who on your team understands the code well enough to maintain it long term?
A partner with clear answers is likely using AI responsibly. See also how to choose a software company.
A code review checklist for AI assisted changes
Reviewers should apply the normal review standard, with extra attention to issues AI generated code commonly introduces.
| Check | What to look for |
|---|---|
| Authorisation | Every endpoint and query checks that the user may access this specific record |
| Input validation | User input is validated and safely handled before database queries or file operations |
| Secrets | No keys, passwords or tokens in code, tests or configuration committed to the repository |
| Dependencies | New packages exist, are maintained, licensed appropriately and actually needed |
| Error handling | Failures are handled explicitly rather than swallowed or exposed to users |
| Performance | No queries inside loops, no loading entire tables, reasonable pagination |
| Consistency | Follows existing project patterns instead of introducing a new style |
| Tests | Tests assert meaningful behaviour, not just that code runs |
| Dead code | No unused functions, commented blocks or leftover experiments |
| Understanding | The author can explain every part of the change |
A sample team guideline document
Teams benefit from a short written guideline that everyone, including interns, reads. An example outline:
- Approved tools and which accounts to use for client repositories.
- Data rules: no client secrets, production data or confidential documents in prompts.
- Ownership: the committer is accountable for all code in the change.
- Size: keep pull requests small enough to review properly.
- Tests: required for all new logic.
- Sensitive areas: authentication, payments, permissions and data exports need a senior reviewer.
- Disclosure: mention significant AI assistance in the pull request description so reviewers adjust their focus.
- Learning: juniors explain AI assisted code in review and complete some tasks without assistance.
For company wide rules beyond engineering, see writing an AI use policy.
Where agentic coding tools fit
Newer tools go beyond autocomplete and can plan, edit multiple files, run tests and iterate on their own. They are powerful for well defined tasks with good test coverage, such as upgrading a library across a codebase, adding a field through all layers of an application, or writing tests for untested modules. They are riskier for vague tasks, codebases without tests, and security sensitive changes. Practical safeguards include running them on separate branches, requiring tests to pass, limiting their permissions in development environments, reviewing every change as carefully as any human contribution, and never giving them production credentials.
Impact on estimates and project planning
Teams often ask whether AI should reduce estimates. A realistic view: routine implementation tasks may shrink, but requirements work, integration, testing, review, deployment and client communication change less. Estimate by activity rather than applying a flat discount. Track actual time on several projects with AI tools before adjusting standard estimates. Clients benefit most when efficiency gains are reinvested partly into better testing and quality, not only faster delivery. See how long it takes to build an MVP.
Hiring in the AI era
Interviews that only test whether candidates can write standard algorithms from memory reveal less than they used to. Many teams now emphasise reviewing and improving existing code, debugging a realistic bug, explaining design decisions, and discussing how the candidate uses AI tools and verifies their output. Candidates who can articulate clear verification habits and understand fundamentals deeply tend to perform best on real teams. See technical interview preparation.
Frequently asked questions
Should projects cost less now that AI writes code?
Routine parts can be faster, but design, integration, testing and support are a large share of real project cost. Expect efficiency gains, not dramatic price drops, from a responsible team.
Can non developers build software with these tools?
They can build prototypes. Production software still needs engineering discipline. See vibe coding for business software.
Should AI generated code be labelled in the codebase?
Line by line labelling is rarely practical. Noting significant AI assistance in pull request descriptions is usually enough to guide reviewers.
Can AI tools help with legacy code?
Yes, especially for explaining old modules, writing characterisation tests before changes, and planning refactors, with careful human review of any modifications.
The bottom line
AI coding assistants make good teams faster and careless teams riskier. The winning pattern is clear ownership, strict review, mandatory tests and shared conventions. Typing is cheaper than ever. Judgment is worth more.
If you are planning a project and want to discuss how AI tooling fits into delivery, our custom software development team is happy to talk it through.