Forem: riyaan amin

AI Didn't Write My Code. It Argued With Me. Here's the Difference.

riyaan amin — Mon, 09 Mar 2026 15:17:46 +0000

I'm building an F1 prediction app. I asked Claude to implement the ML service — specifically, a prediction function that takes a driver, a team, and a race, and returns a predicted finishing position.

Claude wrote it. It looked right. Clean code, proper error handling, sensible fallbacks.

Then it added a comment I hadn't asked for:

# Note: blending model output with heuristic baseline
# because with only 1 race in training data, pure model
# predictions will overfit to Australia-specific conditions

I hadn't thought about this. I was going to use the model output directly. Claude was pointing out, unprompted, that my approach was wrong.

We went back and forth for probably 20 minutes. I argued that the model should just learn from whatever data it has. It explained why that would make predictions confidently wrong rather than honestly uncertain. I pushed back. It held its position and gave me a better explanation.

Eventually I changed the implementation to match what it was suggesting.

That's not code generation. That's a technical disagreement where the AI was right and I was wrong. And I only got the benefit of it because I was actually engaging with what it was saying rather than just copy-pasting output.

The thing nobody says about AI coding tools

Everyone focuses on output speed. How fast can it write a function? How many lines per minute?

The more useful question is: how often does it catch something you missed?

In my experience, this happens constantly — but only if you read the code. The number of times I've had Claude write something, skimmed it, pasted it in, and had it fail in a way that was totally predictable from the code... that's on me, not the AI.

The coding AI that makes you faster isn't the one that writes the most code. It's the one that writes code you actually understand, so you can argue with it when it's wrong and learn from it when it's right.

Two patterns I've noticed

When I describe a problem clearly, Claude usually finds a better solution than what I had in mind. Not always, but enough that I've started treating my initial approach as a first draft hypothesis rather than a spec.

When I describe a solution (i.e., "implement X using approach Y"), it just does that. No pushback, no alternatives, even if Y is a bad idea. The framing matters.

The implication: if you want an AI to actually help you write better code, ask about problems, not implementations. "Here's what I need to achieve" gets you better results than "here's what I want you to build."

I don't know if this is a universal experience or just how I use these tools. Would be curious if others find the same thing.

What's the most useful thing an AI coding tool has pushed back on for you?

Everyone Told Me to Pick One AI Tool and Master It. I Used Two Instead. Here's What Happened.

riyaan amin — Mon, 09 Mar 2026 15:14:47 +0000

The advice I kept seeing when I started learning to code with AI assistance: pick one tool, learn it deeply, don't context-switch.

I ignored it. I use Gemini for planning and Claude for coding, on every project. Here's what actually happened.

Why I use two

It started by accident. I was planning a project in Gemini — laying out the architecture, reasoning through the components, figuring out what needed to exist before I built anything. Then I switched to Claude to write the actual code, because at the time I thought it was better at Python.

The interesting thing: switching between them forced me to translate. Gemini's plan was a description. To get Claude to implement it, I had to turn that description into a precise technical spec. That translation step — which felt annoying at first turned out to be where I actually understood what I was building.

When I tried to do everything in one tool, I'd get architecture and implementation tangled together. The AI would start writing code before the design was solid. Then when the design needed to change, the code was already written and change felt expensive. Separating the tools separated the phases.

What each one is actually good at

Gemini is better at reasoning about trade-offs before any code exists. "Should I use FastAPI or Flask for this?" with context about what I'm building gets a genuinely useful answer with real reasoning. It thinks in systems and consequences.

Claude is better at implementation details and catching edge cases in existing code. It'll write the function, then add a comment explaining why it did something a particular way, and sometimes that comment reveals a problem I hadn't considered.

Neither of these is a universal truth. It's what I've found for my specific use case, building Python backends and Streamlit frontends. Your mileage will vary.

The actual cost

Context-switching between tools does have a cost. Keeping two conversations going, translating between them, maintaining consistency it takes more cognitive overhead than a single-tool workflow.

Whether that overhead is worth it depends on the project complexity. For a simple script, one tool is obviously fine. For something with multiple layers — backend, ML service, frontend, data pipeline — the separation has been worth it for me.

The other cost: you can't fully trust either tool's memory of what the other one said. You're the integration layer. Which means you actually have to understand the whole thing, which is probably a feature not a bug.

The question I'd actually ask

Not "which AI tool is best" but "which part of building this thing am I most likely to get wrong without help?"

For me that's usually the design phase I'm impatient and want to start coding before I've thought clearly about structure. So I force myself to use a planning tool first and not touch the code editor until the architecture makes sense on paper.

The specific tools are almost secondary to that discipline.

What's your setup? Single tool, multiple tools, no tools? Genuinely curious whether the two-tool thing is unusual or if others do the same.

I Use Two AI Models to Build Projects. Here's Exactly How.

riyaan amin — Fri, 06 Mar 2026 17:16:21 +0000

Most people pick one AI and stick with it.

I use two — and it's made me build faster, understand more, and actually finish projects instead of abandoning them halfway through. Here's my exact workflow, why it works, and how you can steal it.

The Setup

I use Antigravity — a coding environment by Google that lets you run AI models directly inside your editor. It has a Claude extension built in, which means I can switch between Gemini and Claude without leaving the app.

That's the key. Same environment, two models, completely different jobs.

No tab switching. No copy pasting between windows. Just a clean switch from planning mode to building mode inside one tool.

Step 1: Gemini for Planning

Before I write a single line of code, I ask Gemini to create a PRD — a Product Requirements Document.

I describe what I want to build in plain English. What it does, who uses it, what features it needs, what tech stack makes sense, what problems I might run into. Gemini is genuinely great at this. It thinks broadly, considers angles I hadn't thought of, and gives me a structured plan I can actually follow.

For my current project GeoAlert — a real-time global conflict tracker with an interactive world map, AI-generated conflict summaries, and a historical year filter — the Gemini PRD covered everything. Folder structure, which APIs to use (ACLED for conflict data, GDELT for news), how the React frontend and Python FastAPI backend talk to each other, a realistic six week build timeline, and potential problems I'd likely face.

That planning session took maybe 20 minutes. And it meant when I actually started coding, I wasn't guessing. I had a roadmap. Every decision had already been thought through.

The difference between starting with a plan and starting without one is massive. Without a plan you write code, hit a wall, rewrite everything, lose motivation, and abandon the project. With a plan you just follow the next step.

Step 2: Claude for Coding

Once the plan is solid, I switch to Claude inside Antigravity and give it one instruction:

"Use this plan and start building Stage 1."

Claude is better at staying consistent across a codebase. It follows the structure Gemini laid out, writes clean readable code, and — crucially — explains what it's doing if you ask it to.

This is where context engineering makes the real difference. I don't just say "build this." I add this to every coding prompt:

"Add a comment above every function explaining what it does. Add inline comments on any line that isn't obvious. After each stage, pause and ask me if I understand before continuing."

That one addition completely changes the output. Claude stops being a code generator and becomes something closer to a patient tutor who happens to write perfect code. Every function is explained. Every confusing line has a note next to it. I move forward only when I actually understand what just got built.

I learned this the hard way. My first project — a Rubik's Cube simulator in pygame — was built with a single vague prompt. The code worked perfectly. I had no idea why. I couldn't explain a single function. That's not a portfolio, that's a magic trick someone else performed.

The second time I built it with this workflow, I understood every line by the time it was done.

Why Two Models Instead of One?

Each model has a genuinely different strength and trying to force one model to do everything well is fighting against how these tools actually work.

Gemini thinks big picture. It's good at research, planning, weighing options, and structuring ideas across an entire project. Claude is precise and consistent. It's good at executing a specific plan, maintaining context across a long codebase, and explaining technical decisions clearly.

Using one model for everything is like using a hammer for every job. Sometimes you need a screwdriver.

The Full Workflow in 5 Steps

Open Antigravity
Ask Gemini: "Create a full technical plan for [project]. Include folder structure, tech stack, build order, and potential problems I'll face."
Review the plan, ask follow up questions until it feels solid and complete
Switch to Claude: "Use this plan. Start with Stage 1. Add comments on every function and explain each part as you go."
Build stage by stage, understanding every line before moving to the next

That's the whole system. No magic. Just being intentional about which tool does which job.

The Bigger Point

AI tools are only as good as how you use them. A bad prompt to a great model gives you code you don't understand. A great prompt to any model gives you something you can actually learn from, explain, and build on.

The workflow I'm describing isn't about being lazy or cutting corners. It's about being deliberate, using planning tools to plan and coding tools to code, and making sure you genuinely understand what's being built at every stage.

That's not vibe coding. That's engineering.

I'm an IB student in Mumbai documenting my CS journey while applying to university.Follow along if you're on a similar path.

Just published my first dev post how I rebuilt a project from scratch because I didn't understand the AI-generated code

riyaan amin — Thu, 05 Mar 2026 17:15:06 +0000

I Asked AI to Build Me a Rubik's Cube Simulator. It Worked. I Had No Idea Why.

riyaan amin ・ Mar 5

#ai #python #programming #productivity

I Asked AI to Build Me a Rubik's Cube Simulator. It Worked. I Had No Idea Why.

riyaan amin — Thu, 05 Mar 2026 17:11:56 +0000

So there I was, staring at a fully working Rubik's Cube simulator on my screen.

Colors, grid, faces — everything exactly where it should be. It ran first try.

And I had absolutely no idea what any of the code did.

The Problem With "It Works"

I'm an IB student trying to build a CS portfolio for university applications. Everyone says the same thing: build projects, put them on GitHub, show you can code.

So I did what most students do. I described what I wanted to an AI, it gave me the code, I ran it, it worked. Done. Next project.

Except — when I looked at the code, it was completely foreign to me. I knew what I asked for. I had no idea what the AI had actually built. I couldn't explain a single function if someone asked me to.

That's not a portfolio. That's a magic trick I didn't understand.

The Rebuild

I decided to start over. Same project, same AI tools — but this time with one rule: I don't move to the next line until I understand the current one.

The difference was in how I prompted. Instead of just saying "build me a Rubik's cube simulator in pygame," I wrote something like this:

"Add a comment above every function explaining what it does. Add inline comments on any line that isn't obvious. After each stage, pause and ask me if I understand before continuing."

That one change made everything different. Suddenly the AI wasn't just handing me a finished product — it was teaching me as it built.

What I Actually Learned

This isn't really about Rubik's Cubes or pygame. It's about context engineering — the quality of what AI gives you is entirely determined by the quality of how you ask.

What's Next

The cube now has a full 2D net, live notation input, and a kociemba solver in progress.

I'm an IB student documenting my CS journey while applying to university. Drop a comment if you're doing the same.