From coding against the clock to Engineering better: The Human side of AI-Driven Development

Artificial Intelligence is changing how we build software, but let's be honest: the biggest productivity gains don't come from letting an AI spit out boilerplate code. They come from rethinking the whole development flow—and realising that software engineers matter more than ever.

AI can write code, scan documentation, and work through tedious tasks. But the quality of the output depends entirely on the person driving it. Put a capable AI in the hands of an experienced engineer, and you get something genuinely powerful. Let it run wild, and you create a mountain of technical debt for your reviewers.

Connecting the dots with Claude Code

Lately, we’ve started baking Claude Code into almost every corner of our Android workflow.

Before we brought AI into the mix, our developers lost time doing the administrative tax of software engineering: digging through Jira and Confluence for requirements, cross-referencing Figma designs, answering endless chat threads, spinning up Git branches, writing commit comments (not helpful at all), and opening pull requests. None of these tasks requires deep architectural thought, but they eat up the day.

By using Model Context Protocol (MCP) integrations, the AI now integrates directly with our existing development tools and workflows. But we didn't stop at out-of-the-box connections. We built custom skills that orchestrate multi-step actions while forcing the AI to respect our existing project's architecture.

Take our skill to create a new feature, for example. It pulls the requirements, documentation, and designs, then drafts an implementation plan. A human has to review and chat with the AI about it and accept that plan before a single line of code is written. Once approved, it generates the code and tests, commits the changes, reviews the changes, pushes them up, and opens a PR that automatically gets reviewed by AI and developers in parallel. Developers then review the changes and make the final decision on whether to approve the PR.

We also route tasks to different models depending on the heavy lifting required. We don't need a top-tier reasoning model to write a simple unit test, saving budget for the complex stuff. The magic isn't in using an isolated coding assistant; it's chaining these capabilities into a coherent process.

Why the Engineer behind the AI matters

One thing we learned quickly: AI works wonders if you know how to babysit it.

An LLM will throw a solution at you in seconds, but speed doesn't mean it actually understood the problem. Requirements are always half-baked, Figma designs leave gaps, and a technically correct snippet of code can still completely violate your app's architecture.

This is where human engineering muscle kicks in. The developer has to provide the context, define the constraints, pick apart the proposed plan, and call the AI out when it tries to hallucinate a shortcut.

Ironically, AI has sometimes caught missing edge cases in requirements that our team overlooked, triggering actual conversations with Business Analysts before a line of code was written. That’s what AI should be doing: acting as a sparring partner, not a replacement.

What has actually changed?

We've seen a massive shift in how fast we can get work ready for review. User stories that used to take two or three days can sometimes hit that milestone by lunchtime.

We spend less time writing docs from scratch or updating Jira, which means more capacity to focus on things that actually require a brain: arguing over design decisions, hunting down tricky bugs, and improving product quality.

Faster code doesn't mean less responsibility

If anything, writing code faster makes the review process more terrifying if you aren't paying attention. The AI can generate code faster than a human can carefully read it.

Our validation stack hasn't shrunk; it's adapted. Developers review the logic, QA tests manually, UI tests catch regressions, and Product Owners validate the feature. The difference is that because the grunt work is automated, we actually have the breathing room to do these checks properly.

Simply dropping AI tools into a team's lap and hoping for the best doesn't work. You need someone who understands the code and knows how to construct reliable workflows, manage model costs, and enforce security boundaries. For consultancies like ours, figuring this out is becoming a massive advantage.

Toward Hyperautomation

We're still figuring things out. Model costs fluctuate, and everyone uses the tools a little differently.

Right now, our workflows are mostly developer-triggered, though PR reviews happen automatically. Next up, we want to automate the analysis of production crashes and Store reviews to bubble up customer pain points directly.

At the end of the day, this isn't about cutting people out of the loop. It's about automating the boring stuff so humans can focus where judgment, context, and accountability matter. The best AI development process isn't one where engineers blindly accept whatever the model spits out. It’s one where skilled engineers know what to delegate, how to guide it, and when to push back.