Spend five minutes on any social network, and you'll see the battle lines drawn over Artificial Intelligence. In one camp, you have developers claiming, "AI-generated code is garbage!" while in the other, enthusiasts insist, "Developers will soon be obsolete!"

After reading countless "hot takes," I've realized that using AI in my daily work is far less dramatic and infinitely more useful.

For me, the point was never to replace the developer. The point was to upgrade my toolset. Using an AI coding assistant is like finally giving a farmer a combine harvester. You still need the farmer's expertise to operate the machine, check the quality of the grain, and watch the property lines. You're just not harvesting the entire field by hand with a scythe anymore.

I first tested this approach on my pet projects (using a React, NestJS, and Supabase stack with tools like Windsurf), and later brought the same mindset to my enterprise work with Cursor, where I worked on both the frontend (Angular) and backend (.NET) of a complex application. I learned that both extremes—completely ignoring AI or blindly trusting it—are dead ends. The path forward is a disciplined, thoughtful approach.

This text is my guide to that "middle path." It's an instruction manual on how I successfully use AI not as a magic black box, but as a sophisticated tool to write better code, faster.

My Code, My Rules

Before I show you "the what", I want to share "the how". The most important lesson I've learned is one foundational principle: the more context you give the AI, the better the code you get back. Modern "AI-first" IDEs are powerful because they build a "memory" of your project. The rules you set, the chat history you create, and the files you have open all contribute to a deep understanding of your codebase. Giving the AI this context is the key to getting suggestions that are not just correct, but relevant to your specific project.

With that foundation, here are my three practical rules:

Rule #1: AI suggests, I approve. I treat the AI like a junior developer. It can generate ideas and write boilerplate code, but I am always the one who makes the final decision. I never, ever commit code that I can't explain line-by-line to a colleague.

Rule #2: Stick to what you know (when it matters). The goal is to finish the task. I use AI to help me with a framework I already understand. It's there to speed up the main goal, not to create new side quests.

Rule #3: It doesn't have to be perfect, it has to work. I don't ask the AI to write perfect, elegant code. I ask it to solve a problem. Once it solves the problem, I ask it to adhere to the established patterns from previously well-written components. Iterations must and should exist.

The process in action

Part 1: Debugging - From TypeError to a Passing Test in 5 Minutes

We've all been there. You run your tests and are greeted by a wall of red text. For me, it was a TypeError in a component's test—the kind of error that can send you down a 30-minute rabbit hole. Instead of that manual digging, I first handed the problem to the AI. The result? The entire process was a perfect example of using the combine harvester—it didn't replace my thinking, it just automated the tedious manual labor, saving me time and mental energy.

Part 2: Feature development - from a blank file to a working component

Let's imagine a common scenario: you need to build a new "Notification Settings" page. It's the very definition of boilerplate code. This is where your job as a 'senior' developer begins. The AI delivers the "scaffolding," but your workflow becomes a focused process of review and refinement:

Reviewing the foundation: First, you review the AI's overall approach to ensure it's correct (Rule #1: You approve). Is it creating new components, or has it successfully recognized reusable components from the code?

Integration with your architecture: You refactor the generic code to use your project's specific building blocks. Did it use existing helper functions, or did it not take enough project context into its memory?

Adding the key business logic: You connect the component to your actual APIs and add standard error handling.

Guaranteeing quality: Finally, you write the unit tests from scratch to ensure the component's behavior and robustness.

The AI handles the repetitive setup, freeing you to focus entirely on high-value tasks.

Part 3: From a Messy switch to a clean design pattern

Finally, let's tackle technical debt. Imagine a monstrous switch statement or some mapping that is a nightmare to maintain. Here, you use the AI not as a simple code writer, but as a brainstorming partner. Your query would be a high-level question, like, "What design patterns could I use to refactor this?"

After a joint review, you decide that, for example, the Strategy pattern is a perfect solution. You, as the architect, define the interface, and the AI, as the code generator, creates the boilerplate for the concrete classes. It's the ultimate example of using the combine harvester to manage the entire harvest, not just to cut a single field.

A quick note for C#/.NET Developers

While I used Cursor for many of the examples above, I must add a practical note. For developers deeply integrated into a dedicated C# environment like Rider, constantly switching to another editor can create unnecessary "friction". In that scenario, you might find more value in tools that live inside your existing environment, such as the agent functionalities in GitHub Copilot. The principle is the same—use a powerful AI partner—but the key is to integrate it in a way that reduces friction, not adds to it.

Bonus tip: Which AI model to choose?

A common question is: does it matter which AI model powers these tools? The short answer is—yes, very much so. While the tool itself (like Cursor) provides context, the "brain" that generates the code is key. Different models have different strengths, and I use them in the following way:

Claude Sonnet 4: For writing and refactoring code. In my experience, it provides very clean and logical code, and understands complex programming structures very well.

Google Gemini 2.5: For writing text. Whether it's documentation, blog posts, or emails, I find it has the best feel for language and style.

Grok 4: For "brainstorming" and generating first drafts. It's excellent for exploring ideas, suggesting different approaches to a problem, and creating an initial structure before I move on to concrete coding.

Disclaimer: these are the models I chose at the time of writing this text. List will update in a matter of months.

The proof is in the numbers (for skeptics)

So, what does this disciplined approach actually bring? The results are what matter.

Massive time savings on "boring" tasks. I estimate that I've reduced the time spent per task by 20-25%.

A measurable improvement in code quality. By using the AI to consistently enforce best practices, I estimate a 20-30% potential reduction in future bugs. A well-written component or endpoint will serve as a template for all future ones and be used as a reference.

A change in how I spend my time. My interactions broke down to: ~60% code and test generation, ~30% analysis and debugging, and ~10% consulting and brainstorming. You don't always have to use the agent mode; you can also just ask.

Conclusion: AI is a tool, not a teammate

My opinion? AI is neither "useless garbage" nor the end of our profession.

It's a powerful tool. The AI is the combine harvester, a complex and powerful machine, but you are—and must always be—the farmer at the controls. My biggest successes came when I stopped treating the AI as a magic oracle and started treating it as a very fast, slightly naive junior developer who needs clear instructions.

My final message is for the two groups I see most often:

For the "vibe coders" who blindly trust AI: Start taking responsibility. Review every line. Understand the why behind the code before you send it. Your seniors, your team, and your future self will thank you.

For the skeptics who refuse to try: Pick one, small, boring task this week. See if you can use this approach to solve it faster. You don't have to love it, but you owe it to yourself to understand it.

I know many of you have half-finished projects gathering dust on your hard drives. Maybe it's time to blow that dust off. With the right tool and the right process, you might finally have the leverage you need to finish them.