Learning AI-assisted Coding in Three Weeks: What Worked for Me

AI did not replace the hard part of learning. It compressed the distance between idea, code, feedback, and judgment.

This is the system I used to build real products quickly without pretending the machine could decide everything for me.

TL;DR

This is not a story about becoming a full-time programmer. It is a story about becoming a faster builder.

I wasn’t trying to become a full-time programmer—just someone who could bring ideas to life faster. Coming from a business and finance background, I already knew enough coding to get things moving, but not enough to build complex systems quickly.

AI changed the starting point. Instead of spending months learning frameworks in the abstract, I used AI as a coding partner: part pair-programmer, part debugger, part sounding board. The result was not magic. It was a tighter loop between idea, structure, code, and judgment.

In three weeks, I shipped real products and learned by building. This article is the system behind that jump: what AI handled well, what still needed human taste, and how I kept the process from turning into chaos.

From 0 to 80%

AI can take you from zero to 80% fast. The last 20% is still yours.

The first useful mental model was separating production speed from product judgment. AI is very good at getting something on screen. It is much weaker at deciding what should exist, why it matters, and when the details feel right.

One of the earliest lessons I learned was this: AI can get you from zero to about 80% incredibly fast if you have a clear scope and a sensible architecture. That first 80% covers the things that usually slow beginners down: boilerplate, syntax, routes, components, and environment setup.

But speed does not remove the last stretch. The final 20% is where the product becomes coherent: product vision, architecture, tricky bugs, and design decisions that do not feel generic. AI is fantastic at writing code. It is not so great at figuring out which code you actually need.

What AI handled well

  • Spinning up Next.js apps, API routes, and TypeScript scaffolding.
  • Generating CRUD handlers and translating product intent into first-pass code.
  • Comparing tools like Postgres, MongoDB, Supabase, and deployment options.
  • Reading errors and suggesting fixes when the implementation broke.

What still needed me

  • Defining the product vision and the smallest useful version.
  • Choosing an architecture that would not collapse after the demo.
  • Debugging by forming hypotheses instead of accepting vague fixes.
  • Making design decisions that did not feel generic or accidental.

My Build Loop

Plan first, build fast, then narrow the problem.

The workflow that made AI useful was simple: start with a small product brief, create visible structure, let AI accelerate the boilerplate, and then debug with increasingly specific questions.

  1. 01

    Scope

    Write the smallest version that would still be useful.

  2. 02

    Scaffold

    Let AI create the initial routes, components, handlers, and project shape.

  3. 03

    Constrain

    Keep planning docs, TODOs, and agent rules close to the code.

  4. 04

    Debug

    Turn vague failure into a concrete hypothesis and test it minimally.

  5. 05

    Polish

    Bring human judgment back to UX, naming, structure, and design.

Every project started with one question: What is the smallest, most essential version of this thing I can make? That forced me to write a one-page Minimum Viable Product brief before touching the implementation.

Once the brief existed, I broke the work into phases and created a /planning folder. TODO.md tracked work, SYSTEM_DESIGN.md recorded architecture decisions, and LOG.md captured the history in plain English.

Later, I added AGENTS.md so AI agents had rules: what they could touch, what conventions to follow, and how to summarize their edits. What felt like overkill became essential. AI works better when the project has boundaries.

Tool Roles

The tools mattered less than the roles they played.

The stack worked because each tool had a clear job in the learning loop.

I used ChatGPT to think through approaches, Cursor to work inside the codebase, GitHub to keep experiments reversible, and Vercel, Cloudflare, Supabase, and Textract to ship the surrounding product infrastructure.

The important part was not the logo list. AI let me start interacting with real tools much earlier than I could have on my own, which meant every tool became part of a live feedback loop instead of something I studied in isolation.

ChatGPT

Thinking partner

Brainstormed approaches, tested tradeoffs, drafted planning docs, and helped turn vague questions into concrete next steps.

Cursor

Coding surface

Made iteration fast because the assistant could read the codebase, run commands, and work in context.

GitHub

Safety rail

Kept experiments reversible. Branches and commits turned mistakes into recoverable checkpoints.

Vercel, Cloudflare, Supabase, Textract

Shipping layer

Handled deployment, domains, auth, data, and OCR so I could focus on product logic.

What I Built

What I actually built

The learning became real because it was attached to products, not tutorials.

01

Personal website

The simplest technically, but important mentally: Next.js, TypeScript, deployment, domain, content structure, and a site that felt polished.

02

Data provider platform

A more complex product with login, payments, permissions, Supabase auth, and Stripe. The hard part was not code volume; it was permission logic.

03

Digitable OCR platform

An image-to-table workflow using Textract, review screens, and spreadsheet-like cleanup. UX mattered more than raw integration.

04

Toolipie

A local-first toolbox for reusable scripts: converters, table summarizers, document utilities, and personal automation patterns.

What Changed

The accelerators were not just technical.

AI made the slow parts faster, but the bigger shift was learning how to think in small systems.

The fastest progress came from moving attention away from syntax and toward product logic. AI could fill in a lot of implementation detail, but I still had to understand how the thing should behave, where the user would get stuck, and what counted as finished.

The failures had a pattern too. Vague prompts, weak Git habits, and large unconstrained AI edits made the project less coherent. The fix was not more automation. It was clearer boundaries.

What worked

  • Focus on product logic. AI can fill in syntax, but I needed to understand behavior and flow.
  • Learn in small chunks. Build something small, break it, fix it, repeat.
  • Keep logs and version control. Clear history saved entire days of frustration.

What failed

  • Vague prompts led to hallucinated solutions.
  • Skipping Git hygiene made rollback painful.
  • Letting AI generate whole folders created chaos.
  • Hoping AI would invent a brand produced generic design.

The fix

I built guardrails: smaller asks, clearer design references, explicit file boundaries, and agent instructions. The goal was not to make AI autonomous. It was to make collaboration predictable.

A Repeatable Playbook

A practical way to start

If someone asked me how to repeat this, I would not start with a course list. I would start with a small real project and a tight feedback loop.

Planning

  • Define the audience and goal.
  • Write a one-page MVP.
  • Keep a planning folder.
  • Pick a boring, stable stack.

Coding with AI

  • Be specific.
  • Use branches.
  • Ask for diffs.
  • Keep agents constrained.

Debugging

  • Reproduce the problem.
  • Read the stack trace.
  • Isolate the cause.
  • Test minimally, then roll back if needed.

Final thought

AI did not turn me into a software engineer overnight. It made me a builder sooner.

The best way to learn is still by doing. AI just lowers the cost of starting before you feel ready.

If you want to learn coding with AI, start with one real project. Write a one-page MVP. Open a repo. Build the smallest working version today.

< Previous
Toolipie: Turning Scattered Scripts into a Swiss-army Knife