What a Year of Building with AI Actually Taught Me

Describing an idea to an AI and watching it build the thing feels like a superpower. It is, with one catch: the AI does everything you say. Not everything you mean.

I spent the last year building full-stack applications with AI. Here is what I learned.

Vibe coding

I started with Lovable.dev. The workflow was simple: describe what I wanted, see what appeared, self-correct. Nothing was obviously breaking. The interface looked right. The features worked.

What I could not see was the foundation. Because I had no system, the AI had no reference. It built for the immediate request, not for a codebase that would be easy to maintain or extend over time.

It stored user relationship data in a separate database table, when that information could have lived inside the existing users table. A small decision, but it meant two places to update whenever something changed. It built a custom table layout for each screen instead of one shared component. When the design changed, the fix had to be made a dozen times. Features stacked on features, each one working in isolation, none of them built with the next one in mind.

The AI was not making mistakes. It was executing exactly what I asked. That was the problem.

AI is an executor

AI coding tools have a limitation: they optimize for the ask, not for the system.

If you ask for a table component, you get a table component. If you ask for a database table, you get a database table. Whether that component should be shared across screens, or whether that relationship should live in an existing table, is a question you have to bring. The AI will not volunteer it.

This is not a flaw. It is just what the tool is. The ceiling of what you can build with it is not the AI's capability. It is your ability to direct it.

Adding structure

I switched to Cursor for my next codebase and started with a product requirements document (PRD) and a technical requirements document (TRD) before writing a line. Not because I needed the documents, but because the AI needed them. Having an architecture document and a design system gave the AI something to refer back to. It stopped making local decisions that conflicted with the larger structure.

It was a meaningful improvement. But I was still working without process discipline. I would start a feature and keep refining it like a design file, no commits, no clear stopping point. When something broke, there was no safe state to return to.

Thinking like a product manager

When I moved to Claude, the shift was different. It was not about the AI's capabilities. It was about how I was managing my own work.

The discipline that changed everything was ticket-level focus:

1. Write a complete, scoped ticket before you start.
2. Open a new branch for each piece of work.
3. Commit before you iterate.
4. Do not refine past "done."

The last one is the hardest for designers. The instinct is to keep going. In design, that costs time. In code, it costs rollback. When you have not committed and you keep modifying, you have no safe point to return to. You have to live with whatever state the codebase is in.

Testing is the other thing that falls away when there is no process. It was never intentional. There was just no systematic moment to do it. A structured workflow creates that moment. That workflow eventually became a structured process I call the feature sprint.

Understanding the constraints of the tool

Working with AI at this depth means understanding how it degrades.

Context overload is real. A long session accumulates history. The AI carries earlier decisions, earlier errors, and earlier framing into every new response. Output quality drops before you notice it has dropped. The fix is simple: clear context, start fresh. Treat it like a meeting that has gone too long.

Model selection matters by complexity. A straightforward UI task does not need the same model as a complex architectural decision. Matching the model to the problem keeps sessions efficient and outputs higher quality.

Once you are comfortable with the basics, the most underused practice is multi-agent review. Just as you would not ship design work without another set of eyes, you should not ship architectural decisions without another agent pressure-testing them. I built a habit of drafting a plan in one session and having a separate agent review it for regressions, gaps, or tradeoffs I had not considered. The parallel to design critique is exact: you are not looking for approval. You are looking for what you missed. A fresh agent, approached with no context from the original session, will catch things the first one cannot.

Three categories of AI-assisted building

Before you start any project, decide which of these you are in. The answer changes everything about your process.

Prototyping to learn

If you are exploring an idea and do not plan to carry the codebase forward, vibe coding tools like Lovable, Bolt, and v0 are the right choice. You are building to see, not to ship. Do not apply engineering discipline to this. Move fast.

Full-stack with a real database

If the product has authentication, data relationships, edge functions, or background jobs, you need to understand those fundamentals before you start directing the AI. Not because you will write the code yourself, but because you will need to catch when the AI is doing it wrong. Database relationships, authentication patterns, and cloud functions are not things you can review without a baseline understanding.

Scalable codebase

If the product needs to grow, process is the product. Think about the end state before you write line one. What does a secure, maintainable, testable codebase look like for this problem? Write that down. Give it to the AI as a reference. Build against it.

Final thoughts

AI coding tools are not replacing the judgment required to build well. They are making that judgment the only thing that matters.

The designers and engineers who build the best things with these tools are not the ones who describe features most fluently. They are the ones who understand process, architecture, and constraints well enough to direct an executor that never pushes back.

Learn how to direct it. The execution takes care of itself.

If you are starting out, the most useful thing you can do before opening any AI tool is write down what you are building, who it is for, and what a working version looks like. That document is the foundation everything else runs on.