AI-Assisted Development: A Three-Act Play

Developers on my team use Cursor’s Tab feature. Designers use vibe-coded prototypes to gather feedback from stakeholders. I rely on Claude Code to plan and build larger features. Same AI technology, completely different approaches.

The conversation around AI coding tools assumes a binary: you either use AI or you don’t. But that misses how practitioners actually work.

In my journey with AI coding tools, I observed three fundamentally different approaches emerging in AI-assisted development. Each of them has its own pros and cons, and is suited for different tasks, or different skills.

Three Emerging Approaches

The first approach, Vibe Coding, can be described as asking the LLM to build an application, and iterating on it via chat, until it is ready for production.

To me, it’s similar to being a product manager. Ideally, you just have to care about the product requirements, and delegate the implementation to someone else.

If I need a working prototype for an application I’m thinking of, I sometimes bootstrap it using a vibe-coding approach (usually the UI part of the app).

With the second approach, AI is your Copilot. You’re asking the LLM to build parts of an application, often using a plan approach, possibly with some implementation instructions. You review changes, fix manually what is easier to you than it is for the LLM, and approve or deny the changes.

You’re basically a team lead. You have junior or midlevel developers who you can delegate most of the features to, as long as you know enough about their work be accountable for it. That means planning implementation with them first, code review and possibly manual testing.

But at the same time, you keep charge of some implementation, especially the most technically challenging details that you don’t feel AI agents are ready for.

Finally, with the third approach, AI tools are your HUD¹. You use the LLM only as a tool to help you write code. This is typically what the “Tab” feature in Cursor offers, and is very good at.

You’re in charge of everything and can’t delegate much, but you have fantastic tools to help you make your task more efficient, robust, and enjoyable. You might not take advantage of all the features that AI offers, but at least you can’t blame it for going the wrong direction.

Usage Patterns For Each Approach

There is obviously nothing wrong with any of these approaches, and none of them is better than the other. It all depends on what it is used for.

At work, I’ve started noticing that we use the three approaches for different tasks.

Our team is composed of developers (mostly senior) and UX/UI designers. None of us considers themselves as an expert with AI coding tools (barely a few months of experience), but here is what I’ve noticed in how we use them:

• Most developers use the HUD approach, i.e. the Cursor “Tab” feature, to write code. Sometimes they use Cursor’s agent mode to interact via a chat, but only for small tasks.

• Some developers (including me) experiment more with the copilot approach, via Claude Code. We don’t apply it (yet) to all tasks, but at least we can plan features or review the code, even if we sometimes fallback to the HUD approach for the implementation.

• Developers don’t really use the Vibe Coding approach, but the UI/UX designers love it! They use it to prototype features, get feedback from stakeholders or even users, and iterate much more quickly than on a static Figma design.

New Skills To Learn

As I said already in my post Turning Claude Code Into My Best Design Partner, using AI coding tools (especially with the copilot and vibe coding approaches) requires you to learn new skills such as planning features.

But on top of that, I noticed that dealing with Vibe Coded code is a specific skill to learn too. Whether you like the idea of Vibe Coding or not, at some point you’ll need to deal with vibe code, whether it is from someone else, or from your past you who just wanted to prototype something quickly.

Usually, apps generated by Vibe Coding are not production-quality, not without the intervention of a developer. AI might create a working app, but shortly you’ll need to find someone to maintain it, make it scale, fix bugs or add features. Will AI be ready for that role in a few years, months, or weeks? Nobody knows…

Until then, when such situations happen, we need to take over the code, understand its architecture and making it easy to maintain not only for us, but also for an AI agent.

From Vibe Coded Code To Maintainable Code

Here are some examples of common issues I encountered when transitioning from vibe-coded prototype to maintainable code:

• AI created wrong abstractions, often too complex: it sometimes tries to make too generic components, because it assumes it/you might need to reuse it. Or passes down global config props to many components, instead of making it globally available (e.g. the URL of your API, or an API key).

• AI stores state locally instead of globally: some components handle their state locally while it should be global to the app; or the opposite, storing form values globally where they could belong to the form component only.

It’s not that the AI makes mistakes in these cases. It has trouble to know the right approach, and without someone to tell it how to do things properly, it just takes a guess and does its best. I know that with experience, you can put some common rules in the initial prompt (or any other rules file).

At work, when we receive a working prototype from the UX/UI team, we usually don’t even try to use it as is. We start from fresh, but it’s very helpful to have a working prototype of what the feature must look like.

The reason why we don’t use the code generated for the prototype is that it doesn’t respect our full tech stack (e.g. we use MobX for state management, where the prototype relies on classic React states), and doesn’t use the components from our design system (for that one I’m sure it won’t take long to be possible).

To me, it isn’t a problem, it’s even a good thing, as long as you know from the beginning that the prototype’s goal is to get an idea of the feature’s full flow and UX, not more.

Plus, reimplementing a prototype in a working app is not complex. We can sometimes reuse some small pieces of code from the prototype, such as animations.

AI can actually even help a lot at this stage: Claude Code is good at understanding a codebase, refactoring it to make it cleaner (e.g. extract UI components in different files), and documenting it (generating a README.md or a CLAUDE.md file). The idea of this refactoring phase is not that much to help AI understand it (although I think it can’t hurt), but more to help human developers understand it, and guide AI agents in implementing next features, and fixing potential bugs.

What’s Next?

AI coding tools are still in their early stages, so it’s hard to guess how it will shape the future of software engineering. But one thing is sure: the three approaches I described in this post are not mutually exclusive.

I’ve already built a couple of features at work using the following workflow:

1. The designer creates a vibe-coded prototype, and gives it to us developers after iterating over it with stakeholders (sometimes, the stakeholders themselves make the prototype);
2. We implement the feature using the prototype (screenshots, code snippets, etc.) using the copilot approach with Claude Code;
3. We fix issues, clean the code and tweak the UI relying on Cursor’s amazing Tab feature.

This workflow works great, and I can easily imagine it being used more and more in the future. I’m even sure that in the coming months, we’ll discover new places where AI can help us even more when building features.

What excites me the most: we’re not just learning new tools

We’re discovering new ways to think about the craft itself.