EnGenious
Software Development
May 20, 2026
Author: Senior Android engineer: Pavel Budanov

I've Been Writing Android Code for more than 10 Years.

There's a version of this article where I tell you AI is overhyped, that experienced engineers don't need it, and that nothing beats hard-won intuition. I believed that for longer than I'd like to admit. Then I delivered a complete Chat History screen - Figma spec to a merged PR - in two hours. Alone. What used to take a full working day. That's when the thinking shifted.


 

Ten Years In - What "Senior" Actually Means

I've spent over a decade building Android applications across consumer apps, e-commerce platforms, fintech products, and real-time voice and text chat systems (think WhatsApp-scale complexity). The kind of work where the edge cases don't show up in any tutorial.

Over that time, I've had to care deeply about things that don't make it onto most CVs:

  • Architecture under pressure. Greenfield projects are easy. Inheriting a 60k+ line codebase mid-sprint, keeping it alive while migrating it to Clean Architecture with MVVM - that's a different discipline entirely.
  • Performance where it counts. Startup time, memory pressure, rendering on mid-range devices. Not theoretical optimization, but profiling real user sessions and fixing what actually hurts.
  • Real-time communication systems. WebSocket management, audio pipeline reliability, aggressive reconnection logic. The kind of code that fails in ways you never anticipated.

The Problem AI Actually Solves

"There aren't enough hours in the day for everything that needs to happen at the level of quality it deserves."

In startup environments especially, the math never works out. Ship velocity is expected to match a team. Test coverage slides because the next feature can't wait. Documentation is aspirational. Code review is you, reviewing yourself.

I was maintaining a 60,000+ line codebase alone. Not surviving it - actually moving it forward. But there was a clear ceiling on what one person could do without compromising quality somewhere.

AI didn't lower that ceiling. It raised it.

The AI-First Workflow, Concretely

I want to be specific here, because "I use AI in my workflow" has become meaningless. Here's what it actually looks like in practice.

Claude Code as the Engine

The foundation is Claude Code running in terminal in agentic mode - not as a chat assistant you copy-paste from, but as an active participant in the development process. The distinction matters. Agentic mode means it can read your project, understand context across files, execute commands, and iterate. It's closer to pairing with a developer than asking a question.

CLAUDE.md - Teaching the Agent Your Standards

Every project gets a CLAUDE.md file. This is where I define the things that would otherwise require constant correction: the architectural patterns in use, code style conventions, which libraries are acceptable (and which aren't), how the module structure works, what a proper ViewModel looks like in this codebase.

Without this, AI-generated code is generic. With it, Claude Code generates code that looks like it belongs in your project - because it understands your project. As the codebase evolves, so does CLAUDE.md. It's a living document, not a one-time setup.

MCP Servers - Closing the Loop Between Tools

This is where the workflow becomes genuinely different from "using AI to write code faster."

Figma MCP means design handoff is no longer handoff - Claude Code can read the Figma spec directly and scaffold UI from it. GitHub MCP keeps code review, PR creation, and branch management inside the same context. Jira MCP means a ticket isn't something I read before switching to my editor - it's input the agent can work from directly.

 

Image jira

A Real Example: Jira Ticket to Merged PR in Two Hours

Let me make this concrete with a specific case.

The task: implement a Chat History screen. Full feature - data layer, business logic, Compose UI, tests.

The old way would have looked like this: read the Jira ticket, open Figma, manually inspect the design, write the UI layer in Compose (getting it approximately right, iterating), implement the use case logic, realize the architecture needs a small adjustment, fix it, remember to write tests if time permits (it usually didn't), open a PR, review it myself.

Six hours, conservatively. Tests optional.

The new way: type

/implement PHOEN-2699   

Screen

 

  • Use case logic is implemented, and tests for it are written - not as an afterthought, but as part of the same pass

 

 

Files

 

I review the output: architecture comments, UI refinements, a few things that need adjustment. The fine-tuning so that it’s exactly how it’s in figma typically needs extra prompts and some hand-writing of the code, and thus takes the most of the time.

Comparison

 

"Two hours. Tests included. That last part matters more than the time saving."

What Actually Improved

Speed: 2x-3x speedup

Feature delivery time roughly halved across the board for well-scoped work. The Chat History example isn't an outlier - it's representative of what happens when context is well-established and requirements are clear.

The caveat worth stating: the time saving is highest on work that is structurally clear. Ambiguous requirements, novel architectural decisions, debugging subtle async race conditions - AI helps less there. That's where the ten years still matter.

Test Coverage: from 0% to 100%*

*By 100% it’s meant covering 100% of domain logic (usually UseCases). In mobile development, there’s usually not much sense in unit-testing UI or data layers. UI and integration tests are a whole different story.

Before AI-first development, test coverage was the first casualty of velocity. In a startup-paced environment, use-case logic went untested because there was no time to write tests that weren't immediately blocking.

Now, tests are written in the same pass as the implementation. Crucial business logic - payment flows, message delivery state machines, use case layers - has coverage it didn't have before. Not because the standards changed, but because the cost of writing tests dropped dramatically.

Bug Detection: ~50% less bugs

With test coverage comes earlier bug detection. Issues that previously surfaced in QA (or worse, in production) are now caught before a PR is opened. The review process is cleaner. Regressions are less common. Here’s the real data from JIRA: November 2025 before AI-first approach, and March 2026 after Claude Code processes are fully adopted.

March 2026 saw 45% fewer Android bugs filed compared to November 2025 (down 30 bugs).

Effective Output

Maintaining a 60,000+ line codebase alone while continuing to ship features at a pace that typically requires a team is the headline result. It's less a metric than a working condition - one that AI tooling made possible without compromising the architecture or accumulating debt.

What This Means If You're Evaluating Me as a Collaborator

I'm not writing this to claim AI made me a better engineer in isolation. The workflow I've described requires someone who can define the right CLAUDE.md conventions, recognize when generated code violates architectural constraints, write review comments precise enough for an agent to act on correctly, and know when to take the wheel entirely.

AI amplifies good engineering judgment. It doesn't substitute for it.

What I bring to a team is ten years of decisions - good and bad - about how Android codebases stay maintainable under pressure. Combined with a workflow that lets me move at a pace that would otherwise require two or three people, and a discipline around test coverage and architecture that doesn't bend when deadlines push.

If your team is trying to ship more with the people you have, that combination is useful.

A Note on What Comes Next

The tooling is moving fast. The number of MCP servers is increasing. Agentic workflows are getting more capable. The engineers who will be most valuable in the next few years aren't the ones who know the most syntax - it's the ones who know how to work with these systems effectively, at the architecture level, without losing the high standards that actually makes software reliable.

That's the direction I've been moving deliberately. Not because it's fashionable, but because it works.

We’re global leaders in test automation, software development, working with Apple, Match Group, and Grammarly. Why they’ve chosen us? It’s our unique expertise , and we’re eager to share it with you!
Join Our Community
Back to all blog posts