A hands-on, self-paced path to building, debugging, and shipping your own small web tool — with an AI assistant doing the coding. No coding required from you.
Welcome. By the end of this guide you'll have built one small but real web tool — a simple expense tracker — and you'll have debugged it, made it safer, documented it, and shipped it. You won't write a single line of code. You'll direct an AI that does.
The one idea, if you remember nothing else: You don't write the code. You describe what you want clearly, give the AI the right context, and check that it actually works. That's the whole job.
Everything you'll learn stacks into three skills — a ladder. You'll spend almost all your time on the first two rungs.
How to use this: work top to bottom, at whatever pace suits you — an hour here, an evening there. Each step builds the same project, so it all adds up to something real. The "Your turn" boxes are where the learning happens — actually do them. Tick a step off when you're done; your progress saves in this browser.
A note on screenshots-that-aren't: Claude's interface changes often, so a button might sit in a slightly different place than described. The idea is what matters, not the exact pixel.
The fastest way to believe you can do this is to do it. So before any theory, you're going to make a working tool — right now.
You type a plain request. Claude writes all the code and shows you a live, working version you can click — that preview panel is called an Artifact. You never have to look at the code.
Go to claude.ai, start a new chat, and paste this:
Watch it appear in the preview and try it. Now change it — without touching any code:
You built and changed working software by describing it in plain English. The AI wrote every line; your job was saying what you wanted, clearly. AIxTech calls this whole skill working with an AI coding assistant — and you just did your first round.
"Did I just code?" Not quite — and that's the point. You didn't write code; you directed something that did. That shift, from writer to director, is the whole idea behind this guide.
A working tip calculator, and proof this is for you. Next, we make your requests far more powerful.
A vague request gets a vague result. The single highest-value skill in this whole guide is learning to brief the AI the way you'd brief a sharp new colleague: who they're helping, what you want, and a little context.
"Build an expense tracker" makes the AI guess everything and probably miss what you meant. "You're helping a hawker-stall owner — build a phone-friendly tool to log daily expenses by category and show a weekly total in Singapore dollars" gets far closer, first try. The difference is role + goal + context.
First, feel the difference. In a fresh chat, try the lazy version and notice what it assumes:
Now the real thing — this brief becomes your project for the rest of the guide:
Before it builds anything big in later steps, get it to think first:
You gave the AI a role, a goal, and context — and got a much better result. In the AIxTech curriculum this is prompt engineering, and it's rung one of the ladder: what you say. That last move — approving a plan before work begins — is called "plan mode."
Beginners under-specify because they assume the AI "knows what they mean." It doesn't — it fills the gaps by guessing, and wrong guesses cost you time. When in doubt, say more.
The first real version of your expense tracker, and a brief you can reuse. But the AI forgets between chats — so next, you'll make your context stick.
The AI only knows what's in front of it right now. Managing what it sees — its context — is a skill of its own, and it fixes the most common beginner frustration of all.
In a long, messy chat, the AI starts to "forget" earlier decisions and gets worse. That's not it breaking — it's the context getting cluttered. The fix: keep your standing instructions somewhere stable, and start fresh when a chat gets noisy.
In Claude.ai, create a Project (think of it as a folder for this build). In the Project's instructions, write your house rules — the things the AI should always follow:
Now start a new chat inside the Project and keep working on your tracker. Notice it already "knows" the rules without you repeating them.
You gave the AI persistent context — a brief pinned to the wall, not just a one-off sentence. That's context engineering, rung two of the ladder: what it sees. The gradual decline you saw in long chats has a name too — context rot. In the real AIxTech course, those house rules live in a file called AGENTS.md (Claude's own tools call it CLAUDE.md) — now you know what it's for.
A prompt is a single sentence to the AI right now. Context is the standing brief it carries into every reply. Don't re-type your rules into each message — put them where they persist.
Your project living in a Project, with house rules that stick. Next: letting the AI do things, not just talk.
Older AI just chatted. Newer AI can act — search the web, run code, make you a file. When an AI can take actions and use tools, we call it an agent. This is the leap from "answer machine" to "thing that does work for me."
Instead of describing a sample spreadsheet, you can ask the AI to actually make one and hand it to you. Instead of guessing a fact, it can look it up. It takes steps, like a colleague would.
In your project, ask Claude to produce something, not just describe it:
Watch it create the file and hand it over. (Depending on what you ask, Claude may also run a quick calculation or search the web to get something right.)
You used Claude as an agent — it took an action and produced a real file, not just text. Under the hood, agents reach tools through plumbing with names like MCP (Model Context Protocol) and skills. You don't need to build those — just know that's what lets an agent connect to things.
"Agent" sounds like science fiction. Keep it plain: an agent is a model plus the ability to take actions and use tools. That's all it means.
Test data for your tracker, made by the AI. More power means more ways to get hurt, though — so before we go further, let's make you safe.
AI-built software fails in a few specific, predictable ways. A beginner who trusts the AI blindly will, eventually, ship something broken or leak something private. Knowing the handful of risks — and a quick check for each — is what separates a responsible builder from a lucky one.
The AI is fluent and confident even when it's wrong. It can invent a software add-on (a "package") that doesn't exist. It will happily use any data you give it — including data you shouldn't share. None of this is malice; it just does what it's told, convincingly.
You ran a safety pass. That fake-package risk has a name — slopsquatting: the AI confidently names a package that doesn't exist, and a bad actor may have already registered that exact name to plant malware. It's real — a made-up "huggingface-cli" package was downloaded roughly 30,000 times. And the private-data rule is Singapore law: the PDPA governs personal data, so don't feed it to a chatbot.
Singapore built tools for exactly this. IMDA's AI Verify is the national framework for testing AI responsibly; Project Moonshot is its open-source toolkit for testing AI apps (usable even by non-technical people); and IMDA's Starter Kit names four risk areas to test for — hallucination, undesirable content, data disclosure, and vulnerability to adversarial prompts. Your 3-point check is the beginner version of that list.
The biggest trap is reading confident as correct. The AI's confidence is not evidence. Check.
A safer project and a habit that scales. Next, a tidy workspace so mistakes surface before you ever see them.
You can't spot mistakes in code you can't read. So you let the machine catch them for you. Two simple, automatic helpers act like spell-check for code — and the AI sets them up.
Ask the AI to add basic quality checks, and it quietly flags sloppy bits and obvious errors as it works — catching problems before they ever reach you.
Read its plain-English explanation. You're not configuring anything by hand; you're asking the AI to set up its own safety net.
You added the basics of an AI-minded tech stack. Linting is a grammar-checker for code — it catches messy, error-prone style. Type-checking catches a whole class of bugs, like putting text where a number should go. The AI runs them so it can check its own work.
These sound deeply technical. They're not your job to understand in detail — only to know they exist, and to ask the AI to use them.
A project that checks itself. Now let's adopt the way professionals actually work.
The beginner's trap is "looks done → isn't → endless fiddling." The fix the pros use: decide what "done and correct" means before you build. Write the goal, write the check, then build to pass it.
For a new feature, you first write one plain sentence describing it, then have the AI write a simple test — a yes/no check of whether it works — and only then build. When the check passes, you're actually done.
You did spec-driven and test-driven development in miniature — AIxTech's professional workflow, in beginner form. You defined the target, then aimed.
Writing the test before the thing feels backwards. Reframe it: you're writing down what success looks like, so both you and the AI can see the moment you've hit it.
A feature you can trust, because it's checked. But things still break — so next, fixing.
Debugging is where beginners quit. The secret: you don't need to read the code. You need to give the AI the right clue and run a tight loop.
When something breaks, the screen usually shows an error message. You copy that exact message back to the AI, tell it what you did, and it fixes the cause — then you test again. Show the symptom → get a fix → test → repeat.
Break it on purpose, so you can practise the fix:
Now fix it the right way:
Then lock it in so it can't sneak back:
You ran a closed-loop debugging cycle and used AI test generation — exactly the AIxTech debugging-and-testing skills. Notice the skill wasn't reading code; it was feeding back a precise symptom.
Beginners say "it's not working." That gives the AI nothing. Always paste the exact error and the exact steps — specific symptoms get specific fixes.
A debugged, tested tracker. Now make sure future-you understands it.
In six months you won't remember how your tool works. Documentation is how a solo builder avoids getting stuck — and it's something the AI writes for you in seconds.
Ask the AI to explain your project in plain English and to draw a simple diagram of how it fits together. You get a guide for future-you, for free.
You generated AI-assisted documentation — including a diagram-as-code (the AI writes a diagram from a description). Bonus: good docs also make the AI better at editing your project later, because it re-reads them.
Docs feel optional, so people skip them. Treat them as a gift to future-you — two minutes now saves hours later.
A README and a diagram. You've done the full loop on one real project — here's where it scales.
Hard jobs go better when you split them across two AI "workers" who hand work to each other — and you run the hand-off. You'll do this for real now, by hand. It's the steepest step, and the most satisfying.
One AI builds; another checks. You pass the work between them. Doing the hand-off manually is the best way to feel what "orchestrating agents" actually means — before any tool does it for you.
You ran a two-agent hand-off — one of AIxTech's most advanced topics (multi-agent orchestration, context passing, artifact hand-offs), done by hand. Here's the punchline: the coordinating you just did manually is exactly what harness engineering automates — the rules and feedback loops built around agents so they stay reliable. Agent = model + harness. That's rung three of the ladder, and the honest horizon of where this field is heading.
"Two agents" sounds automated and magical. What you actually did was pass an artifact between two roles. That's the real, unglamorous heart of it — and you did it.
A tool you built end-to-end and shipped — and you've personally touched all three rungs of the ladder, the third by being the harness yourself.
The one thing to remember: you don't write the code. You describe precisely, give context, and verify. Everything else is detail.