svnscha - coding

The Passenger Seat Developer

2025-10-27T00:00:00+00:00

The Great Prototype Experiment

Here's what nobody tells you about AI-assisted rapid prototyping: After six months and nearly 100 projects, I had to face an uncomfortable truth.

Every prototype feels like success. But is it really?

Why, You Ask?

Picture this: Me, armed with Claude, spinning up project after project like I'm some kind of coding machine gun. A productivity suite here, a file manager there, throw in some web scrapers, automation tools, data processors - you name it, I've probably built a prototype of it in the past six months.

Nearly 100 projects. The dopamine hits were insane. Every idea that popped into my head, no matter how half-baked, could become a working prototype in hours instead of weeks. The velocity felt otherworldly.

The result took me too long to acknowledge: out of nearly 100 prototypes, only one reached production.

One. Literally. One.

That project? mcp-windbg. And guess what made it special? It's the only one where I spent those classic, grinding hours sitting there, actually understanding every line of code, debugging the edge cases, and wrestling with the gnarly implementation details.

The Dopamine Factory

Let me be real with you about what those early days felt like. I'd wake up with some random idea - "What if I built a tool that automatically organizes screenshots by content?" or "I need a better way to manage my development environments" - and by lunch, I'd have a working prototype.

Six months ago, I was writing about vibe coding like I'd discovered fire. The euphoria was real - watching AI refactor entire codebases, generate complex implementations, solve architectural problems in seconds. I was living in that perfect state where "the barrier between thinking and implementing just got so much thinner."

Me: Build me a screenshot organizer that uses OCR to categorize images
Claude: *Generates Python app with OCR integration, file management, GUI*
Me: This actually works perfectly!

The rush was incredible. Idea to implementation in hours. No tedious boilerplate. No debugging mysterious dependency issues. No wrestling with documentation. Just pure, frictionless creation.

I felt like a goddamn wizard. Every prototype that worked felt like validation that I'd cracked some secret code of productivity. Friends would ask what I was working on, and I'd rattle off a dozen projects like I was running a software factory.

That euphoric beginning? It was exactly six months ago. Time has a funny way of providing perspective.

The Reality Check: Why Nothing Shipped

After several months, my project folder had grown to nearly 100 directories, but I still had not shipped anything.

Why? Because prototypes aren't products.

Every time I'd come back to one of these AI-generated prototypes to actually finish it - to handle edge cases, add proper error handling, write tests, or make it production-ready - I'd hit the same wall: I had no clue how the thing actually worked.

The code looked familiar. The structure made sense at first glance. But when it came time to:

Debug why it crashed with certain file types
Add a feature that required understanding the data flow
Optimize performance bottlenecks
Handle edge cases the AI hadn't considered

I was lost. Completely, utterly lost.

The One That Made It: mcp-windbg

So why did mcp-windbg succeed when 99 others failed? It wasn't because I spent months on it - it was a small weekend project. But I approached it differently.

I started by vibe-coding with Claude, just like the other prototypes. Got the basic structure working, had it generating and parsing WinDBG commands. But then - and this is the crucial difference - I actually went back and reviewed what the AI had built. Debugged the edge cases myself. Traced through the subprocess communication to understand how it really worked.

When pytest failures popped up, I didn't just ask Claude to fix them. I sat there and figured out why they were failing. When the CDB interaction got weird with certain commands, I debugged it manually until I understood the communication protocol.

The result? A weekend project that actually solved a real problem in my daily work. Something I could confidently maintain, extend, and explain to others.

I owned the code because I'd taken the time to understand what Claude had built.

The Brutal Truth About AI-Generated Prototypes

Those 99 failed projects weren't failures because the code was bad. Most of them actually worked pretty well for their basic use cases. They failed because I'd delegated understanding to AI instead of using it as a tool to support my understanding.

Here is what was happening:

Week 1: "Holy shit, look at this amazing prototype!"
Week 2: "I should probably clean this up and ship it"
Week 3: "Hmm, there are some edge cases I need to handle"
Week 4: "Why is this crashing? Let me ask Claude to fix it"
Week 5: "The fix broke something else. This is getting messy"
Week 6: "Maybe I'll just start a new project instead..."

Sound familiar? This cycle repeated so consistently I could set my calendar by it.

The Sitting-There Hours: Why They Matter

You know those classic hours every developer has experienced? The ones where you're just sitting there, staring at code, trying to figure out why something isn't working the way you expect? Those moments when you're debugging line by line, tracing execution paths, and slowly building up a mental model of how everything fits together?

Those hours aren't wasted time. They're investment time.

When you skip those hours - when you let AI generate the solution and just accept it - you never build that intimate knowledge of your own system. You become a tourist in your own codebase.

With mcp-windbg, I didn't spend weeks wrestling with it - it was just a weekend project. But during that weekend, when I hit issues with subprocess communication or weird CDB behavior, I actually debugged them myself instead of immediately asking Claude for fixes. I took the time to understand why certain commands failed and how the debugging session management worked.

That weekend of actually understanding what I was building made the difference between prototype #99 and shipped product #1.

The False Productivity Trap

I felt productive while building those 99 prototypes. Each working demo felt like progress, and my GitHub activity supported that impression. It did not mean I was finishing useful products.

But productivity isn't about how much code you generate. It's about how much value you ship. And by that metric, I had a 1% success rate.

The problem was not AI itself, but how I used it. I treated it as a replacement for understanding instead of a debugger or knowledge base that could help me learn faster.

How I Use AI Now

I still use AI regularly, but now I treat it like any other development tool.

AI as a knowledge base: "How does subprocess communication work in Python?" "What are the edge cases for file parsing?" "Show me different approaches to error handling."
AI as a debugging partner: "Here's my stack trace, what could be causing this?" "This function isn't behaving as expected, help me trace through the logic."
AI for the boring repetitive stuff: Boilerplate code, test scaffolding, documentation generation, refactoring patterns I've done a million times.
AI as a code reviewer: "Does this implementation handle edge cases properly?" "Are there performance issues with this approach?"

The key difference: I use AI to accelerate my understanding, not replace it.

For anything I might ship, the rule is simple: If I can't explain how the core functionality works without looking at the code, I don't ship it. AI can help me get there faster, but it can't get there for me.

This isn't about being a purist or rejecting AI assistance - it's about maintaining professional competence and shipping software you can actually support.

What Success Actually Looks Like

After six months of this experiment, here's what I've learned about successful AI-assisted development:

Delegate the repetitive stuff: Boilerplate generation, test scaffolding, documentation, refactoring patterns you've done before.
Use it as a knowledge multiplier: Research APIs, explore different approaches, get explanations of complex concepts, debug tricky issues.
Keep the understanding: Architecture decisions, core business logic, data flow design, system integration points.
Invest in the sitting-there hours: For anything you plan to ship, spend the time to truly understand how it works.

AI is similar to a good debugger or profiler: it can make you more effective, but it does not replace understanding the system you are building.

The Uncomfortable Question

Here's the question that keeps me up at night: How many developers are building careers on AI-generated code they don't understand?

This is also a matter of professional responsibility. If you own a piece of code, you should be able to explain, modify, and debug it, especially when a production issue occurs and the AI assistant is unavailable.

I don't have a good answer to that question. I just know I don't want to be that kind of developer.

Summary

After six months and nearly 100 AI-assisted prototypes, only mcp-windbg shipped. The difference was that I used AI to speed up my learning instead of asking it to replace that learning.

Remember that uncomfortable truth from the beginning? Every prototype feels like success, but success is measured by shipping, not building. The dopamine hits from rapid prototyping are real, but they're not the same as the satisfaction of maintaining code you actually understand.

The lesson isn't to use less AI. The lesson is to use it better.

AI is like having a brilliant research assistant, debugger, and code reviewer all rolled into one. Use it to explore ideas faster, understand concepts deeper, and eliminate the boring repetitive work that burns you out. But don't delegate the understanding itself.

Next Steps

If this resonates with you, here's what I'd suggest doing right now:

Audit your current projects: Look at your recent work. Can you explain how the core functionality works without looking at the code? If not, spend some time diving into those systems.
Set a new rule: For anything you plan to ship, implement the "explain it without looking" test. If you can't walk someone through how it works from memory, you're not ready to ship.
Change how you prompt: Instead of "Build me X," try "Help me understand how to build X" or "What are the key concepts I need to know for X?"
Embrace the sitting-there hours: When you hit a bug or weird behavior, resist the urge to immediately ask AI for a fix. Spend 15-20 minutes trying to understand it yourself first.

Someone still needs to own the code. AI can help you move faster, but it cannot take that responsibility from you.

Vibe Coding is So Damn Real

2025-04-27T00:00:00+00:00

Why, You Ask?

Ever had that moment when your coding flow is so perfect it feels like you and your tools are in some kind of cosmic alignment? That's vibe coding. It's when the friction between thought and implementation practically disappears. And let me tell you, with GitHub Copilot and VS Code, this isn't just a fleeting sensation-it's a consistent reality.

I'm tired of writing about theoretical capabilities. Let me show you something concrete.

A Childhood Dream Come True

Let me share something personal: since I first started coding, I've had this recurring dream. A dream where I could simply talk to my computer, tell it what I want in plain language, and watch as it translates my intentions into working code. No syntax gymnastics. No hunting for semicolons. Just pure, frictionless creation.

"Hey computer, refactor this module to use dependency injection instead of globals."
"Computer, optimize this database query, it's running too slow."
"Add translation support to all user-facing strings in this module."

For decades, this remained firmly in the realm of science fiction-something for Star Trek episodes where they casually ask the computer to "reconfigure the deflector dish" and it just... happens.

DAMN, we're just there now. Not in some distant future, not as a tech demo, but as a practical, everyday reality in my development workflow.

Real-World Context: Nofidoc

A little context: In my free time, I've been pushing the boundaries of what's possible with AI-assisted coding-well beyond just casual experiments. While I also use these workflows at work, Nofidoc has become my personal playground for exploring how far I can take this technology. It's a space where I can try things that aren't always ready for the spotlight, but the results have been too compelling not to share (even if I'm keeping things a bit low-key for now).

The codebase uses Qt for the UI components, has a wizard-based document import flow, and handles various document formats with a focus on PDFs. It's exactly the kind of mid-sized C++ project where refactoring used to be tedious and error-prone.

The Perfect Pairing

VS Code with GitHub Copilot doesn't just assist your coding-it transforms it. No more wasting precious brain cycles on trivial tasks. No more tedious refactoring operations that make you question your career choices at 2 AM.

I recently needed to refactor the document import workflow to remove direct database dependencies in the wizard component. Why having that in the first place? Well, getting something proof-of-concept-ish is the answer. Anyways, this is a classic case of improving architecture by decoupling components, but it typically requires careful changes across multiple files and understanding the entire call hierarchy.

See The Entire Workflow In Action

I've recorded a full ~6-minute video showing the entire refactoring process from start to finish. You'll see me:

Prompt Copilot with my refactoring requirements
Watch the initial code changes being proposed
Hit compilation errors (because real-world code is messy!)
Provide additional guidance to Copilot
Get a complete, working solution

Your browser does not support the video tag.

What's remarkable here is not just that Copilot could make the changes, but how the entire interaction feels like working with a senior developer who deeply understands your codebase.

The Real Example: DocumentImportWizard Refactoring

Here's a snapshot of what happened in the video. I needed to update the DatabaseWidget class to use the new API of our DocumentImportWizard that we had refactored to remove direct database dependencies.

Copilot analyzed the code and came up with this solution:

// Before refactoring, direct database dependency:
void DatabaseWidget::onDocumentImportWizard()
{
    auto importWizard = new DocumentImportWizard(_database, this);
    importWizard->exec();
}

// After refactoring, using callback approach:
void DatabaseWidget::onDocumentImportWizard()
{
    auto importWizard = new DocumentImportWizard(this);
    importWizard->setGetDocumentTypesCallback([this]() {
        if (!_database)
            return QList<DocumentType>();
            
        auto docTypeService = _database->getDocumentTypeService();
        if (!docTypeService)
            return QList<DocumentType>();
            
        return docTypeService->getDocumentTypes();
    });
    importWizard->exec();
}

Copilot explained its reasoning:

"I've updated the onDocumentImportWizard() method in DatabaseWidget to use the new refactored API of our DocumentImportWizard class. The key changes were:

1. Removed passing the _database parameter directly to the DocumentImportWizard constructor 2. Added a call to setGetDocumentTypesCallback() with a lambda that:

Checks if _database is valid

Gets the document type service from the database

Returns the document types list from the service

Returns an empty list if any step fails

This completes the refactoring work by updating all the calling code to use the new API. The change maintains the same functionality but with a cleaner design that removes direct dependencies on the database pointer.

The implementation follows modern C++ practices by using a lambda to encapsulate the specific functionality needed (getting document types) while keeping the rest of the database access logic out of the wizard class. This makes the code more maintainable and easier to test."

This is exactly the kind of architectural improvement that typically takes deep understanding of both the codebase and software design principles. Yet Copilot produced it in seconds.

The Key Lesson: Human-AI Collaboration

My main takeaway is simple: AI tools work best when you bring your own domain knowledge.

Just before that, I was debugging a frustrating issue with field registration in that document import wizard. The fields weren't passing values between pages correctly. I asked Copilot to help fix the bug and it initially proposed an overly complex workaround that would have been a maintenance nightmare.

So I gave it a hint:

"I think there's an issue with the registerField calls for 'importSuccessCount' and 'importErrorCount'. The implementation doesn't specify the property name correctly."

And just like that, it had an "aha!" moment. It immediately identified the real issue:

// Before (buggy implementation):
registerField("importSuccessCount", this);

// After (Copilot's correct fix):
registerField("importSuccessCount", this, "importSuccessCount");

This simple fix resolved the entire issue. The fix works because it properly uses the Qt property system (third parameter) as the remaining code and pages expected, whereas Copilot's initial workaround was mega ugly - setting properties directly with setProperty() calls. With just a small hint about the actual problem, we were back on track. This perfectly illustrates why domain expertise remains critical - AI tools can suggest solutions, but knowing which ones make sense in your framework requires human judgment.

Sometimes AI tools need a gentle nudge in the right direction, and then they're off to the races again.

Not Always Perfect Magic

Let me be real with you - it's not all sunshine and rainbows. AI assistance sometimes misses the mark, and when it does, you need to steer it in the right direction. But I've found that:

The initial attempt is usually close
AI is exceptionally good at understanding feedback
With the right hints, it can quickly recover and find the optimal solution

The collaboration workflow is what makes all the difference. Instead of wrestling with a tool, it feels like having a junior developer who's eager to learn and quick to adapt.

What I Learned

This isn't just about saving time (though I saved HOURS). It's about changing how we think about coding. When you can express your intent in natural language and have it accurately translated into code changes, you're no longer programming computers-you're conversing with them.

The barrier between thinking and implementing just got so much thinner.

Getting This Setup Yourself

Want this superpower? Here's what you need:

VS Code
GitHub Copilot
A clear understanding of your codebase - To craft effective prompts

That's it! No complex configuration, no elaborate plugin chains.

Oh, which model? Right now I am using Claude 3.7 - it's so good.

Where This Is Going

You know that saying about technology and magic? This is it. We're witnessing the early days of a transformation in how software gets built. The tools are evolving to understand not just the syntax of our code, but the intent behind it.

Could I have written a complex bash script to do some of this refactoring? Maybe. Could I have used search-and-replace with regex? Probably. Would either approach have understood the semantic meaning of my code well enough to know which strings need translation? Absolutely not.

Summary

Vibe coding isn't just some feel-good developer term. It's that perfect state where you and your tools are in sync, where expressing your intent feels natural and immediate. With GitHub Copilot and VS Code, I'm experiencing this daily while building Nofidoc.

If you're still doing manual refactoring in 2025, you're not just missing out on productivity-you're missing out on the pure joy of frictionless development.

Try it. Feel it. Vibe code.