AI Coding Tools in Production: What Actually Works (And What Doesn't)

The hype around AI coding tools is exhausting. Every week there's a new "revolutionary" assistant that promises to replace developers or solve all your technical debt. Meanwhile, those of us actually building software are trying to figure out which tools deliver real value and which ones just burn through API credits.

We've been using AI coding tools across our development workflow for over a year now. This time, our Android developer shares their insights from using these tools in production environments. While the examples focus on Android development, the workflow and principles apply equally to other programming languages and frameworks, with performance and effectiveness varying accordingly. In healthcare applications where code quality and compliance are non-negotiable, these considerations become even more critical.

So let’s walk through what we’ve learned: first, the uncomfortable truths about these tools; then how Copilot and Cursor compare in practice; and finally, the workflows and guardrails that make AI a multiplier rather than a liability.

The uncomfortable truth about AI development tools

Before diving into specific tools, let's address the elephant in the room: AI coding assistants are expensive, context-limited, and prone to making changes you didn't ask for.

Context is everything (and always limited) 

AI models can only hold so much information at once. This means every time you start a new chat session, you're essentially onboarding a new developer who knows nothing about your project. They might have vast general knowledge, but they don't know your business logic, your architectural decisions, or why that seemingly weird workaround exists.

The refactoring addiction 

These tools love to rewrite code. Ask them to add a simple validation check, and they'll often restructure your entire function. This isn't just annoying, it's dangerous when you're working on production systems, especially in healthcare where unexpected code changes can impact patient data handling or compliance requirements.

Cost creep 

Processing large codebases or maintaining long conversation contexts gets expensive quickly. We've seen monthly bills spike when developers start treating AI tools like unlimited resources rather than focused assistants.

These truths frame how we evaluate every tool: not by what they promise, but by how they behave under these constraints.

Two distinct approaches: Copilot vs Cursor

Once you accept those realities, the tools themselves start to show clear personalities. Copilot and Cursor, the two we use most, work best when you play to their strengths.

GitHub Copilot: the pattern matcher

Copilot excels at what we internally call "copy-paste-change" workflows. If your task looks like “do the same as this other piece of code, but slightly different,” it usually nails it.

Where it shines:

• Writing tests that follow your existing test structure
• Creating API endpoints that match established patterns in your codebase
• Building UI components when you have clear design system examples
• Generating data models from JSON responses

The process that works: Keep the scope narrow. Attach only the files directly relevant to your task. Describe what you want in plain language. Let Copilot follow patterns it can see in your code.

Real workflow example: When adding a new API integration, we provide Copilot with our existing API service files and the new endpoint documentation. It consistently generates code that follows our error handling patterns, authentication approach, and data transformation logic. The success rate is around 85-90% for this type of task.

Cursor: the strategic planner

Cursor, on the other hand, is more like a strategic partner. It's built around the idea that you should plan before coding, which sounds obvious but is surprisingly rare in AI tools.

The planning advantage: Instead of jumping straight into code generation, Cursor encourages you to define rules, create implementation plans, and provide comprehensive context. This upfront investment pays off with higher-quality output and fewer surprises.

How we use it: We create project-specific rules that define our architecture patterns, coding standards, and technology constraints. For complex features, we develop detailed implementation plans that break down the work into steps with confidence levels.

The agent mode difference: Unlike Copilot, Cursor can autonomously work through multiple files and make coordinated changes. When it works, it's impressive. When it doesn't, it can create more problems than it solves.

In short: Copilot is your fast pattern-completer, Cursor your more deliberate planner. Neither is a silver bullet, but together they cover different ground.

Our development workflow: rules and reality checks

Of course, tools are only as good as the workflows you wrap around them. After plenty of trial and error, we’ve developed a three-part system.

Rule creation

We maintain project-specific documents that tell AI tools about our constraints and preferences. These include architectural patterns we follow, libraries we use, and coding standards we maintain. For healthcare projects, we also include compliance requirements like HIPAA data handling rules and security protocols. The key is being specific about what you want rather than hoping the AI will guess correctly.

Implementation planning

For any feature more complex than a simple bug fix, we create implementation plans that outline the business requirements, technical approach, and integration points. This isn't just documentation—it's a communication tool that helps AI understand what we're actually trying to accomplish.

Validation process

Every AI-generated change goes through human review, but we've learned to focus our attention on specific risk areas: unintended refactoring, missing error handling, and integration points with existing systems. In healthcare applications, we pay extra attention to data privacy implementations and audit trail functionality that AI might overlook or implement incorrectly.

This system keeps the tools useful without letting them run wild.

The surprising failures

Even with guardrails, AI tools fail—sometimes hilariously, sometimes expensively. We’ve seen them:

• Invent color values hallucinated from design files (the AI confidently provided hex codes that didn't exist in the original)
• Rename API response field names without notification, breaking integrations
• Generate Android lifecycle code that looked correct but implemented completely wrong patterns
• Test suites that passed but didn't actually validate the intended functionality

The pattern behind these failures is overconfidence. AI tools rarely hedge. They present wrong answers with the same authority as correct ones. That’s why code review isn’t optional—it’s survival.

And yet, the failures don’t negate the value. They just define the conditions under which the tools are safe to use.

Performance and productivity impact

Used carefully, AI coding tools can be genuine accelerators.

Measurable time savings: For routine tasks like test creation and API integration, we see development time reduced by 25-40%. This isn't marketing fluff, we track these metrics because tool adoption decisions need to be based on real productivity gains.

Quality improvements: AI-generated tests often catch edge cases that human developers miss during initial implementation. The tools are particularly good at generating comprehensive test scenarios once they understand your testing patterns.

Consistency benefits: Perhaps the biggest advantage is consistency. AI tools follow established patterns religiously, reducing architectural drift that typically occurs when different developers work on similar features. Over time, that discipline matters as much as productivity.

Making AI tools work for your team

The real difference between teams that get value from AI coding assistants and those that don’t usually comes down to process. Tools themselves are neutral—it’s how you structure their use that determines whether they save time or create chaos.

The first step is to start small. Don’t throw these tools at your entire development process on day one. Pick a narrow, well-defined task (writing unit tests, generating API stubs) where it’s easy to measure whether the output is helping. Early wins here build trust without putting production at risk.

From there, the focus shifts to context. We’ve seen again and again that the quality of AI output rises and falls with the quality of the input. Detailed documentation, architectural rules, and clear examples do more to improve results than any clever prompting trick.

Once the AI starts producing usable code, you need a safety net. That means review standards. Instead of treating review like a generic code check, focus attention on the places AI most often stumbles: integrations, error handling, and compliance edge cases. In healthcare, this also means encryption, consent flows, and audit trails – areas where “close enough” is never good enough.

Finally, none of this matters if you don’t measure impact. Track the hours saved, the defect rates, the test coverage, whatever metrics tie most directly to your team’s goals. Without numbers, it’s easy for AI adoption to become a story people tell themselves rather than a demonstrable gain.

{{lead-magnet}}

The bottom line

AI coding tools won’t replace skilled engineers, but they can compress routine work without sacrificing quality when you use them deliberately. They deliver the most value when you constrain scope, give them real project context, and keep rigorous human review in place (especially around integrations, error handling, and compliance). Used this way, they’re disciplined assistants; used carelessly, they invite hidden refactors, cost creep, and fragile code.

Start small, measure the impact, expand what works, and retire what doesn’t. Make the process the product.

Ready to choose where they’ll help your team next?

-

This article is based on real experience using AI coding tools in production environments. Your results may vary depending on your specific use cases, team structure, and development practices.