How to Use AI Tools the Right Way as a Front-End Developer

TL; DR;

• Treat AI as a tool that amplifies you, not magic that replaces your thinking.
• Use a structured approach: start with planning, not implementation.
• Let AI ask you questions first to clarify requirements before any coding.
• Maintain coding guidelines (like AGENTS.md) to get consistent, clean output.
• Create your file structure manually to stay in control and force planning mode.
• Embed design notes directly in your codebase where they're most relevant.
• Remember: you own the quality, UX, and client's trust. AI is just your ally.

Setting the Stage

Lately, many of my one-on-one talks with colleagues have circled around a single hot topic: AI and how it's changing our work as front-end developers.

These conversations are relaxed but meaningful. Some colleagues worry about their role in industry, others are curious, and some are already experimenting with AI in their daily tasks. It's a mix of excitement and concern — a reflection of the industry right now.

Instead of focusing only on the risks, I encouraged everyone to also share the positive side: what's working well, where AI genuinely helps, and what achievements they feel proud of since adopting these tools.

The stories varied. Some people had concrete examples of saved time, others talked about smoother workflows, and some even joked that AI finally gave them a “coding buddy” who doesn't complain.

But through all these discussions, one key idea kept surfacing:

AI is a tool. It doesn't replace us, not yet at least. It amplifies us.

Responsibility remains ours, and the results depend entirely on how we use it.

When the day of true “general artificial intelligence” arrives, that's a different story. Maybe I'll pack for Mars and beg Musk for a standing ticket. Until then, I stay grounded and continue to learn and experiment with AI.

The Tools I Use Most

AI can be helpful in many ways, but I mostly use two tools on my daily basis: v0 and Cursor.

When I need a prototype for a client, I usually start with v0. It feels more creative, especially on design, and that makes sense since Vercel built it with that in mind.

Once the design is ready, I move things local, set up a GitHub repo, and continue with Cursor. Why? Because at the end of the day, I want full control of my code.

A browser editor is fine, but nothing beats a proper local IDE.

Sometimes, I even skip v0 and start with Cursor + Sonnet 4.0 — and it works fine. In the end, what matters most is how clearly you describe your task.

A Simple Scenario - A Landing Page

Let me give you a concrete example. Imagine I want to build something very simple for myself: a personal landing page. Nothing fancy, no animations that make your laptop sound like it's about to take off. Just a clean page with:

• some basic info about me,
• a photo (where I hopefully look friendly and not half asleep),
• a few details about the projects I've worked on,
• and a CV that people can download if they want to know more.

Basically, I picture it as a minimalist digital business card. A single place where recruiters, potential clients, or even curious friends can get the essentials without scrolling through endless details.

Prompt Level 1 - How We Usually Use AI

Here's the trap: we often behave as if AI is somehow plugged directly into our brain. We assume it can read our thoughts, so we give it the shortest, vaguest instructions and expect magic.

Prompt Level 1

Sounds decent? Not really. It's vague. The output depends entirely on the AI's “mood of the day.”

Why do we write prompts like this?

• We think the task is obvious, so of course AI should get it.
• We believe it already knows the context (because we do).
• We want instant results and hope to fix things later.
• Sometimes, let's be honest… we're just too lazy to think it through.

We assume AI can read our thoughts, and expect magic

Prompt Level 2 – Planning Phase

A much better way is to plan your prompt. Sure, in my example it was obvious that I wrote a lazy prompt, but the problem is that in real situations it's not always so easy to notice. Often the prompt feels fine, but in reality it's not detailed enough.

When it comes to coding,

I usually write my initial prompts in separate markdown files.

This helps me escape the tiny chat box that most AI tools force on us. It feels like they don't actually want me to write too much. Short prompts are easier for them to handle, they give me back some nonsense, and then happily charge me for the tokens.

So whenever I'm planning a big prompt, the kind that should generate multiple files and hundreds or even thousands of lines of code, I always do it in a file. I might spend hours refining it, and that's fine. For smaller things, like bug fixes or quick questions, I'll just type directly in chat.

Back to my hypothetical landing page: if I want good results, I need to give the AI more details about me, my technologies, my skills, the things I want to highlight. The more context I add, the better.

Another technique I use a lot is to flip the script:

I'll ask the AI to create a list of questions for me in a markdown file

Then I go through and answer them one by one. That way, I don't just hand over the thinking to the AI — I'm building the requirements in collaboration with it.

This moves me into planning mode. AI asks, I answer, I refine, and add details. Then, using AI I'm adjusting the initial requirements:

By repeating this, vague ideas become real specs. That's our job as developers: to understand what we're building.

Prompt Level 3 – Technical Guidelines

Once I know what to build, I can decide how to build it. That's where a file like AGENTS.md comes in.

AGENTS.md is just the name I use when working with Cursor, but honestly, I can call the file whatever I like. The important part is that I pass this file into my prompt whenever I ask the AI to generate something.

Instead of cleaning up messy AI code later, I give it rules upfront

For example:

• Function vs. arrow function components?
• One or multiple components per file?
• Where do constants go?
• Use type or interface?
• File naming conventions?
• Where to keep reusable components?
• Which libraries to use, and when?

For a medium project, a guideline can mean hundreds or thousands of lines of rules, with examples, folder structures, best practices, and anti-patterns. It's not an easy task, but it's worth doing if I want to benefit from AI in a productive way.

Guidelines are not static. I keep updating them as the project evolves.

That said, even with all my carefully written guidelines, the models still act stubborn sometimes and ignore my rules. The good part is that it's usually easier to fix a few style errors than to waste time in yet another round of back-and-forth with the AI, especially when, for the fifth time in a row, it insists on creating an unnecessary index.ts file just to re-export a couple of related components.

Even with all my carefully written guidelines, the models still act stubborn sometimes and ignore my rules.

Prompt Level 4 – File Structure

After requirements and rules, I'm defining the file structure. There are two things to consider here. Most of the overall project structure rules are living in my guidelines file. But what I'm talking about here is guiding the AI to generate exactly the files I need for the feature I'm working on. I can do that by describing the components, hooks, lib, and so on directly in my prompt. Or, I can do what I often do: go “old school” and just create the files myself by right-clicking in the editor and adding new folders and files.

I actually like creating files manually. The process is slow, but that's the point,

it forces me into a thinking and planning mode

Once I've created the files, I usually add empty placeholders: functions, constants, hooks, components. Then I start leaving comments directly inside those files. These aren't polished notes; they're more like a brainstorming session with myself. I'll write down

• how many props a component might need
• how it could interact with other components or the API
• or even some pseudocode in plain language to sketch out an order of operations.

What I'm really doing here is writing down my thoughts on what I consider the best practices for that specific feature. Instead of drafting a separate document or filling in a Jira ticket,

I'm embedding the design notes straight into the codebase where they're most relevant.

If I end up implementing the feature myself, great — I already have a head start. If someone else picks it up later, at least they've got a clear starting point to work from. It doesn't mean the final implementation will follow my notes to the letter, but it gives me a framework to discuss and refine.

In short,

I'm still the one doing the thinking and designing.

I'm not outsourcing that to the AI just because it can generate things quickly. Fast doesn't always mean good.

For the fictional landing page, I could have:

• home-hero.tsx
• home-about.tsx
• home-projects.tsx
• home-testimonials.tsx
• home-contacts.tsx
• home-cta.tsx

Once I've created all the files — which, in a complex project, could include constants, hooks, utility functions, API fetchers, and plenty more — then I'm ready to let the AI do its magic. At this point,

I make it clear that the AI should also take into account all the comments I've already written inside those files.

If I want to be really strict, I'll tell it not to create any new files at all. Usually though, I allow it, but with one condition: it has to explain why it created those extra files. That way, I can see whether there's a valid reason and maybe expand my initial view of the feature.

Creating the overall project structure is something I think about right at the beginning, but it's also a process that never really ends. Even if I follow examples and practices documented by engineers with more experience than me, every project has its own quirks. At the end of the day,

I still need to make decisions about the structure myself

not blindly copy something I found on the internet, and definitely not blindly accept whatever structure the AI decides to generate.

Quick Recap

• Define your initial prompt clearly.
• Don't rush; plan first.
• Create your prompt in a file, not directly in the chat.
• Keep you feature requirements in a md file.
• Use AI as a question-asking assistant.
• Keep coding rules in a guide file.
• Define the structure yourself to stay in control.
• Remember: AI is just a tool, a great one, but a tool nonetheless.

Conclusion

AI tools are powerful, but only when used with care. If you're careless, you'll end up with spaghetti code that future-you (or unlucky teammates) will have to fix. At the end of the day, AI is remixing human-written code. The responsibility is ours.

Don't let AI decide for you. You are the developer. You own the quality, the UX, and the client's trust.

Use AI as an ally, not a substitute for your own thinking