Press enter or click to view image in full size

5 min readJust now

–

I used to be a “mobile engineer.”

That label came with invisible walls. The Flutter app lived in one repo. The Rails backend lived in another. Different teams, different standups, different Slack channels, different worlds. When a bug crossed the boundary between mobile and backend, it became a multi-day coordination exercise. File a ticket. Wait for prioritization. Hope someone picks it up. Schedule a meeting to discuss the handoff.

Last week, I fixed a bug that touched both the mobile app and the Rails backend. It took less than an hour.

Not because I suddenly became twice as smart. Not because I pulled an all-nighter. Because we killed the artificial boundary. And because I had an AI pair programmer that didn’t care about my job title.

The Lie of Specialization

Somewhere along the way, we convinced ourselves that splitting engineers into narrower and narrower specialties was progress. Mobile engineers. Backend engineers. iOS engineers. Android engineers. Frontend engineers who only touch React. Backend engineers who refuse to look at a CSS file.

You build walls. You create handoff ceremonies. You generate tickets that sit in queues. You schedule “alignment meetings” that are really just expensive translation services between people who should have been working on the same thing from the start.

The bug I fixed last week would have taken two days in our old setup. One day waiting for the backend team to acknowledge my finding. Another day coordinating the fix, reviewing separate PRs, deploying separately, hoping the timing worked out.

Instead, I opened the monorepo, traced the bug from the Flutter client through the Rails API, fixed both sides, and shipped it. One PR. One review. One deploy.

The Monorepo Is Not About Code Organization

Everyone focuses on the wrong thing when they hear “monorepo.” They think it’s about directory structure. About build systems. About whether you use Melos or Nx or Bazel.

That’s not it.

The monorepo is about permission. Permission to understand the whole system. Permission to fix problems where they actually live instead of where your job title says you’re allowed to look. Permission to be an engineer again instead of a “mobile engineer” or a “backend engineer.”

When the code lives together, the artificial jurisdictions dissolve. You stop thinking “that’s a backend problem” and start thinking “that’s a problem.” Full stop.

AI Removed the Knowledge Barrier

Permission is worthless if you don’t know how to use it.

The monorepo gave me access to the Rails backend. But I’m a Flutter guy. I had never written Ruby professionally. I knew the concepts, sure. MVC. ActiveRecord. But knowing concepts and actually navigating a production Rails codebase are different things.

This is where Claude Code changed everything.

I use Anthropic’s Claude Code as my daily driver. When I’m in unfamiliar territory — which is constantly now — I’m not alone. I can ask it to explain what a Rails concern does. I can have it trace a request through the middleware stack. I can say “this endpoint is returning the wrong data, help me find where the transformation happens” and actually get a useful answer.

It feels like science fiction. It also feels like the most natural thing in the world.

The AI doesn’t care that I’m “not a backend engineer.” It doesn’t gatekeep knowledge behind years of Ruby experience. It just helps me understand the code in front of me and write the fix I need to write.

The monorepo removed the organizational barrier. Claude Code removed the knowledge barrier. Together, they turned a mobile engineer into a Product Engineer who can work anywhere in the stack.

From Mobile Engineer to Product Engineer

Here’s what changed for me: I stopped being a mobile engineer who occasionally filed backend tickets. I became a product engineer who happens to know Flutter really well.

The difference is fundamental.

A mobile engineer thinks about screens and widgets and state management. A product engineer thinks about problems and users and outcomes. The mobile app is just one surface where those outcomes manifest. The API is another. The database is another. They’re all part of the same system, serving the same user.

The monorepo didn’t teach me Rails. Claude Code didn’t teach me Rails either, not really. But together they gave me something better than teaching: they gave me the ability to be productive in Rails while I learn. I’m not sitting through tutorials. I’m shipping code. The learning happens in context, on real problems, with real feedback.

The Efficiency Gain Is Real

I’m not talking about marginal improvements. I’m talking about order-of-magnitude differences.

Bug that crosses mobile/backend boundary:

• Old way: 1–2 days minimum. Often longer.
• Monorepo + AI way: Less than an hour.

Feature that requires API changes:

• Old way: Design the contract. Write a ticket. Wait for backend. Integrate. Debug the mismatches. Iterate.
• Monorepo + AI way: Build it end-to-end. Ship it.

Unfamiliar code in a language you don’t know well:

• Old way: Google. Stack Overflow. Tutorials. Ask a colleague. Wait for their availability.
• AI way: Ask Claude. Get an answer in seconds. Keep moving.

This isn’t a minor process tweak. This is reclaiming hours every week that used to disappear into coordination overhead and knowledge gaps.

This setup compounds. The monorepo makes it possible to attempt cross-boundary fixes. The AI makes those attempts successful. Each successful fix builds confidence. Confidence leads to more attempts. The cycle accelerates.

Just Do It

If you’re still running separate repos for your mobile app and your backend, stop. Merge them. It’ll take a weekend. The tooling exists. The patterns are documented.

If you’re not using agentic AI assistance in your daily workflow, start. Claude Code, Codex, whatever. Pick one. (Don’t get stuck on code completion with Cursor!) Get comfortable asking an AI agent to help you understand unfamiliar code.

And if you’re a “mobile engineer” or a “backend engineer” or any other kind of specialist, ask yourself: is that label protecting you or limiting you?

The walls are coming down whether you want them to or not. The monorepo and AI together are making full-stack product engineering accessible to anyone willing to try. You can fight it, or you can use it to become the engineer you always could have been.

Kill the walls. Merge the repos. Embrace the AI. Become a real engineer. A problem solver.