There is a lot of noise about AI in software development right now. Vendor claims about 10x productivity. Studies showing developers are actually slower when they use AI tools. The reality, as usual, sits somewhere in the middle — and it depends almost entirely on how you use the tools, not just whether you use them.
At Lycore, we have been integrating AI tools into our development workflow across Python, Django, React, Flutter, and .NET projects for the past year and a half. This post is an honest account of what we actually do, what has worked, what has not, and what the practical impact has been for the clients we build for.
Not a vendor pitch. Not a stat-padded overview article. Just what we have learned from shipping real software with AI as part of the process.
The honest picture on AI and developer productivity
Before we get into what we do specifically, it is worth being clear-eyed about what the research actually says. A study from METR in early 2025 found that experienced developers working on complex open-source projects were actually 19% slower when using AI tools — not faster. The reason was not that the AI was unhelpful. It was that reviewing, debugging, and correcting AI-generated code added overhead that outweighed the speed of generation.
At the same time, surveys consistently show that over 80% of developers believe AI makes them more productive, and controlled experiments show 30–55% speed improvements on well-scoped, contained tasks.
Both things are true. AI makes certain tasks significantly faster. It adds overhead to others. The teams and companies that extract real value from AI are the ones that have figured out which is which — and built their workflows accordingly.
Where we use AI tools and why
Boilerplate and scaffolding
The clearest productivity win. Setting up a new Django app, scaffolding a REST API endpoint with serializers and viewsets, generating initial migration files, creating Flutter widget structures — these are tasks where AI generates accurate, usable code in seconds that would otherwise take 20–30 minutes of typing and referencing documentation. We use Claude Code and GitHub Copilot here, and the output quality for standard patterns in our stack is consistently high.
The rule we follow: AI writes the skeleton, a senior engineer reviews the architecture before anything else is built on top of it. This stops structural mistakes from propagating through the whole codebase.
Writing and running tests
Test generation is one of the most underrated AI use cases in development. Given a function or a class, AI can generate a thorough set of unit tests — including edge cases a developer might not think to write manually — in a fraction of the time. On a recent Django REST project, our QA cycle for a new module was cut by roughly 40% because the initial test suite was AI-generated and comprehensive, leaving our engineers to focus on integration tests and scenario testing rather than basic coverage.
The caveat that matters: tests must be written against the specification, not against the AI-generated code. If you let AI write both the code and the tests for that code, the tests will pass but may not reflect what the software is actually supposed to do. We write tests from requirements first, then use AI to fill in coverage.
Code review and debugging
When a developer is stuck on a bug or wants a second opinion on an implementation, asking Claude or Copilot is faster than waiting for a colleague to be available. We have found AI particularly useful for catching obvious issues — missing null checks, off-by-one errors, inefficient database queries — before code goes to human review. This means our human code reviews spend more time on architecture, business logic, and edge cases, and less time on the mechanical stuff.
Documentation and handoff materials
Documentation is the task developers are most likely to skip under time pressure. AI has made it much easier to keep documentation current. After a sprint, we use AI to generate initial API documentation from code, write changelog entries, and summarise what changed in plain language for non-technical stakeholders. A task that used to take half a day now takes under an hour.
Requirements clarification and scoping
Before development starts, we use AI to stress-test a requirements document — looking for ambiguities, missing edge cases, and scope risks that are not immediately obvious. On several recent projects this has surfaced questions that, if left unaddressed until mid-development, would have caused significant rework. The cost of a one-hour requirements review is far lower than the cost of a two-week redesign.
Where we do not use AI
Knowing where not to use AI is just as important as knowing where to use it.
We do not use AI-generated code for security-critical logic without thorough manual review. Research shows a 23.7% increase in security vulnerabilities in AI-assisted code. Authentication systems, payment processing, data encryption, and access control are areas where we write carefully and review carefully.
We do not use AI for novel architectural decisions. AI is trained on existing patterns. When a project requires a genuinely new approach — a custom multi-tenant architecture, a non-standard data pipeline, a real-time system with unusual constraints — AI suggestions tend toward the generic. These decisions need human expertise and judgment.
We do not let junior developers use AI unsupervised on complex tasks. Junior engineers in our team use AI tools under supervision, with explicit guidance on when to trust the output and when to be sceptical.
What this means for clients
The practical impact for the businesses we build for comes down to three things.
Faster MVPs. The scaffolding and boilerplate acceleration is most visible on new projects. Getting from a blank repository to a working, testable first version takes meaningfully less time than it did two years ago.
More thorough testing earlier. Because generating test coverage is faster, we test more comprehensively earlier in the project lifecycle. This means fewer bugs reach QA, and fewer surprises emerge post-launch.
Better documentation. Handoff materials, API docs, and technical summaries are more consistently produced and of better quality. This reduces friction when clients bring in internal engineers to work alongside us or take ownership of a system we have built.
Our current AI toolset
- Claude Code — primary tool for complex code generation, architecture review, and explaining unfamiliar codebases. Particularly strong on Python and Django.
- GitHub Copilot — inline suggestions in the IDE, useful for boilerplate and autocomplete in well-understood patterns.
- Claude via API — used within client applications themselves, building AI features including document processing, intelligent search, and automated workflows.
- ChatGPT — occasional use for research, generating draft documentation, and exploring approaches before committing to implementation.
AI-Assisted Development: Measured Productivity Outcomes
Productivity claims about AI tools tend toward the optimistic in vendor marketing and the sceptical in research literature. Our experience sits between both. Across projects where we tracked time explicitly, we see consistent gains on specific task types: test generation runs 40-50% faster when AI drafts the initial test stubs that engineers then review and extend; documentation writing for handoff materials runs 50-60% faster; and boilerplate scaffolding — setting up new Django apps, REST endpoints, serialiser classes, migration files — runs 30-40% faster. Code review first-pass time drops by roughly 25-30% when AI pre-populates the review checklist with structural observations, freeing the reviewer to focus on logic and business correctness rather than formatting and obvious issues.
Where we see minimal or negative productivity effects: novel architecture design, security-critical implementation, and work in unfamiliar codebases where the AI’s suggestions are plausible but wrong in ways that take longer to identify and correct than writing from scratch. The net effect across a typical project is a meaningful reduction in the low-complexity implementation work that AI handles well, without any reduction in the engineering judgement and domain expertise that clients are actually paying for.
Our Team Norms for AI-Assisted Development
Unstructured AI tool adoption produces inconsistent quality and creates risk. We have developed working norms that govern how AI tools are used across our team, revised regularly as the tools and our experience with them evolve.
What AI output always gets reviewed
Every line of AI-generated code that goes into a client codebase is reviewed by an engineer before commit. We treat AI output the same way we treat code from an external contributor — it gets reviewed against the same standards, not rubber-stamped because the tool is trusted. Security-related code (authentication, authorisation, input validation, cryptographic operations) gets a second engineer review regardless of whether AI was involved in its generation. This is not distrust of AI tools — it is the same review discipline that prevents human errors from shipping.
What stays off the AI tools
Client code, client data, and confidential project details do not go into cloud-based AI tools without explicit client consent. We use locally running models for tasks that involve sensitive code, or we ensure that the tools we use have enterprise data agreements in place. This is a firm policy, not a guideline. The risk of a client’s proprietary business logic or data appearing in a future model’s training set is not a risk we take without their knowledge and consent.
AI-Assisted Development: Pros and Cons
Pros
- Faster delivery on clearly specified tasks — boilerplate, test generation, documentation, and code review assistance all show consistent time savings that translate to faster delivery on the tasks where AI performs reliably.
- Improved test coverage — AI-generated test stubs make it easier to achieve higher test coverage because the low-effort work of writing the structural test scaffolding is handled by the tool, leaving engineers to focus on the edge cases that actually matter.
- Better documentation at handoff — AI-assisted documentation writing produces more thorough handoff materials than the same engineers writing without assistance, because the time cost of comprehensive documentation is lower.
- Architecture review support — using AI as a sounding board for architectural decisions surfaces considerations the primary architect may have missed, improving decision quality on complex design choices.
Cons
- Confidently wrong suggestions — AI tools generate plausible-sounding incorrect code, particularly for less common libraries, edge cases, and anything involving recent API changes. Catching these requires the same level of engineering review that prevents the tools from providing the productivity gains they promise without oversight.
- Junior developer over-reliance risk — less experienced developers can accept AI suggestions without the critical evaluation that identifies subtle errors. Managing this requires explicit team norms and senior review of junior AI-assisted output.
- Data and confidentiality risk without policy — using cloud AI tools without a clear policy about what code and data can be submitted creates intellectual property and confidentiality risk that organisations may not have considered.
Frequently Asked Questions: AI-Assisted Development
Does using AI-assisted development mean projects cost less?
Productivity gains from AI tools do not automatically translate to lower project costs — they translate to faster delivery and higher quality on the tasks where AI performs well, which is how we use them. We do not reduce quotes by the productivity percentage on scaffolding tasks because that productivity is reinvested into better test coverage, more thorough documentation, and more careful review of the complex parts that AI does not handle well. The value to clients is faster time to first working version and better quality on the implementation details that AI accelerates — not cheaper projects of the same scope.
Is AI-assisted development suitable for security-sensitive applications?
Yes, with appropriate review processes. We use AI tools on security-sensitive applications subject to the same code review standards as all other code — with the addition that security-critical code (authentication, authorisation, input validation, cryptographic operations) receives mandatory second-engineer review regardless of how it was written. The risk with AI and security is not that the tools are malicious but that they generate subtle vulnerabilities that are easy to miss in a quick review. Research from Stanford showed AI-assisted code had a higher rate of security vulnerabilities in some categories — our review process is designed to catch exactly those cases before they reach production.
Which AI tools do you recommend for a development team starting out?
For a team starting with AI-assisted development, the highest-impact starting point is an AI-integrated IDE — Cursor is our current recommendation, with GitHub Copilot as a solid alternative for teams already invested in the GitHub ecosystem. Start with the tasks where AI is most reliable: test generation, documentation, and boilerplate scaffolding. Establish a clear review policy before deploying to production — the policy does not need to be elaborate, but ‘all AI-generated code is reviewed before commit’ needs to be explicit and enforced. Avoid starting with the tasks where AI is least reliable (security logic, complex business rules, unfamiliar codebases) and expand usage as the team develops intuition for when AI suggestions are trustworthy and when they need careful scrutiny.
The bottom line
AI tools have made our engineering team meaningfully more productive on the tasks where they work well: scaffolding, testing, documentation, debugging, and requirements analysis. They have not replaced the judgment, experience, and communication that determine whether a software project succeeds.
If you are evaluating an outsourced development partner and wondering whether they use AI responsibly — ask them specifically how. Not just “do you use AI” but “where in your workflow, with what guardrails, and how does it affect quality.” The answer will tell you a lot about how mature their engineering practice actually is.
Related Posts
