There’s a tension every developer feels right now. On one hand, we’ve been handed the most powerful set of tools in our generation. AI code assistants can feel like a superpower, promising to write boilerplate code, solve complex algorithms, and accelerate our workflow beyond what we thought possible. On the other hand, using them blindly is a professional trap: a path that leads to fragile code, painful debugging sessions, and a slow erosion of the very skills that make us valuable engineers.
The central question is no longer if we should use AI, but how.
I believe companies must not only allow but actively encourage their developers to embrace AI tools. However, developers also bear the responsibility to resist the allure of “vibe coding” and instead master these tools as genuine co-pilots. About nine months ago, the leadership at my company, Doximity, addressed the topic of AI in development head-on during an off-site Q&A. Their response was a resounding “yes,” and they framed it with a perfect analogy: AI tools are a turbo engine for developers. Why would we want to drive a standard model when we could be supercharged?
That moment was a catalyst. It set the stage for how we could build better, faster, and smarter.
Putting a Turbo Engine in Your Development Workflow
Since that day, we haven’t just gotten approval; we’ve fully embraced it. We have a Slack channel, #gsd-with-ai (Get Stuff Done with AI), #ai-engineering, and #ios-ai, where not just developers, but PMs, designers, and everyone else share tips and tricks. This open embrace is crucial for three reasons.
- Unlocking Full Potential: Let’s be honest, AI tools make you faster. They handle the tedious stuff, generate solid starting points, and let you focus on the hard architectural problems. This isn’t just true for developers, but all roles in the company.
- Staying on the Learning Curve: Prompt engineering, context engineering, and knowing which tool to use for which job are becoming essential skills. The tools are evolving at a breakneck pace. If companies block access, they aren’t protecting their codebase; they’re ensuring their developers have a massive skill gap to close later.
- Winning the Talent War: Developers are already feeling overwhelmed trying to keep up with the dizzying pace of AI advancements. Now imagine the anxiety of working at a company that forbids you from using these tools at all. In today’s market, companies that shun AI aren’t just falling behind technologically; they risk isolating the very developers who are most driven to innovate and grow.
This is all incredibly positive, but it comes with a massive caveat. The power to generate code instantly is also the power to create a mess instantly.
The ‘Vibe Coding’ Trap: Fun, Fast, and Fragile
I’ll admit it: I’ve vibe coded on side projects, and it’s incredibly fun. For me, “vibe coding” is my term for prompting an LLM, getting a chunk of code, and dropping it into your project without truly reviewing or even understanding it. You just keep prompting based on “vibes” until the feature kind of works. It feels like a video game where every prompt is another turn, and you get to see new output instantly.
It’s a fantastic way to play and learn in a low-risk environment. But in a professional setting, for production-level code, it’s dangerous.
The danger is what happens when things go wrong. When you only vibe code, you don’t learn the code that’s being generated. So when it comes time to debug, you’re facing a black box. The same LLM that wrote the “great” code is now your only hope for fixing it, and you’re left prompting blindly: “I’m getting this error, please help.”
An experienced software engineer, by contrast, has a superpower: the ability to reason. We can look at a bug and hypothesize: “Is this a race condition? Did our API token expire? Is the problem in the logic or view layer?” Vibe coding short-circuits this diagnostic muscle.
Ultimately, every line of code I open a PR for, I’m responsible for. If it breaks and becomes a blocker, I need to be able to fix it, fast. If an associate developer asks me to explain a shared framework I built, I need to have the answers. With true “vibe coding,” you won’t have them.
How I Actually Use AI to Get Stuff Done
So how do you use the engine without flying off the road? For me, it comes down to a simple rule: vibe coding is for low-risk side projects; rigorous analysis is for production code. I’ve been using AI as an intelligent co-pilot that helps me write better code, faster.
My toolset has evolved right alongside the technology:
- Phase 1: Basic ChatGPT. A year ago, this was it. Great for brainstorming algorithms or getting high-level explanations of a framework. But the code quality was often on par with a questionable Stack Overflow answer, and without an enterprise account, I couldn’t share any proprietary code. I saw the potential, but it wasn’t ready.
- Phase 2: Integrated Tools (Alex, CodePilot). When tools like Github Copilot, and Alex (formerly Alex Sidebar) integrated directly into Xcode, everything changed. Context-awareness was the game-changer. The AI could see my actual codebase, making its suggestions relevant and immediately useful.
- Phase 3: The Agentic IDE Trade-Off. The rise of agentic IDEs like Cursor offered compelling automation, but it posed a significant trade-off for iOS developers. The productivity gains didn’t outweigh the friction of sacrificing Xcode’s essential build-and-run ecosystem.
- Phase 4: Advanced CLIs (Gemini CLI). Today, even integrated sidebars and agentic IDEs feel a bit dated. Tools like Claude Code and Google’s Gemini CLI are a step closer to true agentic coding, compatible with any IDE since they run in your command line terminal. With massive context windows and the ability to use tools to search my entire project, it functions as a true pair programmer.
At Doximity, our app is massive. It’s essentially an app of apps, with different teams dedicated to each tab. Jumping into another team’s domain can feel daunting. But instead of scheduling an ad-hoc meeting, I can now ask Gemini CLI to help me understand parts of our codebase I don’t frequently visit. Here are some of my daily use cases:
- The Codebase Archaeologist: “How does our analytics infrastructure work?” or “Why in our networking layer are we setting our auth token?” I can ask it, and it will search the code and give me a high-level explanation, usage patterns, and even sample code. It’s an on-demand expert for our own codebase.
- The Pair Programmer: I use it as a sounding board. “Here’s my proposed approach for this feature. What are the potential downsides?” Or “What APIs are available to perform a custom multi-step animation?”
- The Proactive Code Reviewer: After writing a block of code, I’ll ask it to look for potential bugs or edge cases I might have missed.
- The Unit Test Generator: This has been one of the most valuable uses. I ask it to write unit tests for logic I’ve created. In the process, it often comes up with edge cases I hadn’t considered. Some of these have even uncovered legitimate bugs in my original code.
- The Code Refiner & Documenter: I use it to suggest ways to make my code clearer and to help write documentation, saving me from tedious, time-consuming tasks.
In all these cases, I am the final checkpoint. I read, analyze, and understand every single line. I’ll absolutely use AI for small functions or boilerplate code, but I try to keep AI as a partner, not a replacement.
Don’t get me wrong, I do try to push it to its limits every couple of months or with every new tool. But I’ve found that trying to generate large, complex pieces of code for an app of our size doesn’t work out well. The back-and-forth it takes to prompt, refine, and debug the output to meet our quality standards often takes more time than if I had just written the feature myself. My experience mirrors what recent studies are finding: productivity gains from AI can decrease as the complexity of the codebase increases. This is talked about from this study by METR that claims that developers are actually 19% slower when using AI and this video showing Stanford’s similar research.
That said, this is a snapshot of where we are today. Given how quickly these tools are improving, this limitation might not be true six from now.
Beyond the Co-Pilot: Directing the Agentic Future
There’s a lot of hype around AI, and it’s possible we’re in a bubble. But when the dot-com bubble burst, the internet didn’t go away. The revolutionary technology remained, and it reshaped our world. I see the same thing happening with AI. The hype will die down, but the tool will remain.
Today, that tool is a co-pilot, not an autopilot. But the gap is closing faster than anyone predicted. The world of programming has already changed fundamentally in the last six months; imagine what it will look like in another twelve. With agentic coding on the rise, it’s clear we’ll be writing much less line-by-line code.
But this doesn’t make our jobs obsolete. In fact, it makes them more critical. As we shift from implementation to architecture, our value will be in directing those agents, defining robust specifications, and applying critical thinking to complex systems. I believe the premium on true engineering skill is about to skyrocket.
So the challenge remains for both sides. Companies must push their developers to stay on this accelerating curve. And as developers, we must embrace this evolution. Learn to master the engine, because even when it drives itself, you’re the one who has to tell it where to go and make sure it gets there safely.
(Side note, we’re currently hiring for our iOS team!)