TL;DR

How conversational AI turned a product guy into a full-stack builder

Replit gave me wings. CalendarGenie and Post-er proved I could build real products. But I was hitting a ceiling — and I didn’t fully realize it until that ceiling shattered.

How conversational AI turned a product guy into a full-stack builder


Replit gave me wings. CalendarGenie and Post-er proved I could build real products. But I was hitting a ceiling — and I didn’t fully realize it until that ceiling shattered.

The breakthrough came in two stages: first Claude Desktop, then Claude Code. Together, they didn’t just improve my workflow. They fundamentally changed what „building software“ means for someone like me.

The Replit Ceiling

Let me be honest about where things stood. By mid-2024, I had built a respectable portfolio on Replit. But every project pushed me into the same corners:

  • Performance: Replit’s servers are shared. When your app needs serious compute or fast response times, you’re at the mercy of platform load.
  • Control: You’re in a sandbox. Need a specific system package? A particular database configuration? Custom deployment? Good luck.
  • Complexity: Replit’s AI assistant (Ghostwriter, later Replit Agent) is good for getting started. But when you’re building something with multiple services, background jobs, and complex state management, you need a conversation partner that can hold context across an entire architecture.
  • Cost: At scale, Replit’s pricing doesn’t compete with running your own server.

I didn’t want to go back to depending on developers. I wanted to go forward — with better tools.

Enter Claude Desktop

Claude Desktop was the first tool that made me feel like I had a senior developer sitting next to me. Not writing code for me — thinking with me.

The difference from Replit’s AI was immediate and profound. With Replit, the conversation was transactional: „Add a button here.“ „Fix this error.“ „Make this responsive.“ Each prompt was isolated. The AI didn’t really understand what I was building or why.

Claude Desktop changed the nature of the conversation. I could share my entire project context. I could say: „Here’s my application. It manages marinas. I need to add a contract management system where marina operators can upload PDF contracts and have AI extract the key terms. The contracts are in German and English. The extracted data needs to integrate with the existing tenant management module.“

![Claude Desktop — conversational AI as a development partner](art4-claude-desktop.png)

And Claude would not just write the code — it would ask clarifying questions. „Should expired contracts trigger notifications? What happens when a contract covers multiple berths? Do you want the extraction to run synchronously or as a background job?“

These weren’t generic questions. They were the questions a thoughtful developer would ask after understanding the domain. And answering them forced me to think more clearly about what I was actually building.

This is what I mean by „vibe-coding.“ It’s not typing prompts and hoping for the best. It’s a genuine back-and-forth where the human brings domain knowledge, product intuition, and user empathy — and the AI brings technical execution, pattern recognition, and tireless implementation.

The MCP Ecosystem

One thing that supercharged Claude Desktop was the Model Context Protocol (MCP) ecosystem. MCPs are plugins that give Claude access to external tools — file systems, databases, APIs, browsers, and more.

For a non-developer, this was transformative. Suddenly Claude could:

  • Read and write files on my machine directly
  • Query my PostgreSQL databases to understand the data
  • Browse documentation and API references in real-time
  • Run commands and see the output

I didn’t need to copy-paste code snippets or describe error messages. Claude could see what I was seeing, work in the same environment, and iterate in real-time. It felt less like using a tool and more like pair programming — except my pair partner had read every programming book ever written.

Claude Code: The Quantum Leap

If Claude Desktop was like having a senior developer next to me, Claude Code was like giving that developer direct access to my entire development environment.

Claude Code runs in the terminal. It can read your codebase, write files, run commands, execute tests, and manage git — all conversationally. You talk to it like a colleague: „The login page is broken on mobile. Can you check what’s going on and fix it?“

And it does. It reads the relevant files, identifies the issue, proposes a fix, implements it, and — if you want — commits it to your repo.

For someone with my background, this was revolutionary. Here’s why:

1. No More Context Switching

With Replit, I was constantly jumping between the code editor, the preview, the AI chat, the console. With Claude Code, everything happens in one conversation. I describe what I want, Claude Code builds it, I see the result, we iterate. The flow state is uninterrupted.

2. Full-Stack Without the Stack Anxiety

Claude Code doesn’t care that I don’t know the difference between useEffect and useMemo. When I say „the page should refresh the data when the user comes back to the tab,“ it knows what React hooks to use, implements them correctly, and explains what it did if I ask.

This isn’t about ignorance. I’ve learned an enormous amount about how software works over these 2.5 years. But there’s a difference between understanding architecture and memorizing syntax. Claude Code handles the syntax. I handle the architecture.

3. Debugging as Conversation

This one changed everything. Before Claude Code, debugging was my weakest point. An error message would appear, and I’d copy it into ChatGPT or Claude, get a suggestion, try it, get a different error, paste that in, and spiral for hours.

With Claude Code, debugging is: „This endpoint returns a 500 error when I try to save a contract with special characters in the title. Fix it.“ Claude Code reads the route handler, finds the missing input sanitization, adds it, tests it, done. What used to take me an afternoon takes five minutes.

4. The CLAUDE.md Pattern

One pattern I’ve adopted across all my projects: a CLAUDE.md file in each repository. It’s a project guide written specifically for Claude — explaining the architecture, coding conventions, key decisions, and gotchas.

Think of it like onboarding documentation, but for your AI pair programmer. When Claude Code opens a project, it reads CLAUDE.md first and immediately understands the lay of the land. Which database? What ORM? Where do the routes live? What’s the deployment flow?

This is a small thing that made a massive difference. Without it, every Claude Code session started with re-explaining the project. With it, Claude hits the ground running.

What Changed In My Output

The tooling upgrade had measurable impact on what I could build:

Before (Replit era):

  • Single-service applications
  • Simple database schemas
  • Basic authentication
  • Limited to what Replit’s environment supported
  • Deployment: Replit handles it (convenient but constraining)

After (Claude Desktop/Code era):

  • Multi-service architectures (backend + frontend + gateway + workers)
  • Complex database schemas with Prisma migrations
  • JWT authentication with role-based access control
  • Docker containerization, nginx reverse proxies, SSL certificates
  • CI/CD pipelines, staging environments, production deployments
  • Real-time WebSocket connections
  • Background job processing

The jump in capability wasn’t incremental. It was a step function. In the three months after switching to Claude Code, I built more complex software than in the entire year before.

The Conversational Development Loop

Here’s what a typical development session looks like now:

1. I describe the feature in business terms. Not „add a REST endpoint that accepts multipart form data.“ Instead: „Marina operators need to upload contracts and have the AI extract tenant name, berth number, start date, end date, and monthly rate.“

2. Claude Code asks questions I haven’t thought of. „What about contracts with multiple tenants? Should we store the raw extraction alongside the parsed data? What happens if extraction confidence is low?“

3. We design together. I bring the product perspective („operators will want to correct extraction mistakes“), Claude brings the technical perspective („we should use a review queue pattern with status tracking“).

4. Claude Code implements. Database migration, API endpoint, service layer, frontend form, validation — the full vertical slice.

5. I test and iterate. „The date parsing doesn’t handle German date formats correctly.“ Claude fixes it. „Can we add a confidence score to each extracted field?“ Claude adds it.

6. Ship. Commit, push, deploy.

![The Conversational Development Loop — from idea to product](art4-dev-loop.png)

This loop is fast. A feature that would take a traditional development team a sprint to spec, build, and test takes me a day. Sometimes less.

Is the code as clean as what a senior engineer would write? Probably not. Is the feature exactly what the user needs? Usually yes — because the person defining it is the same person testing it.

What Enterprise Gets Wrong — And Right

I recently listened to an excellent podcast — [programmier.bar Deep Dive #200](https://www.programmier.bar/podcast/deep-dive-200-coding-agents-mit-julia-kordick) — where Julia Kordick, a Software Global Black Belt at Microsoft, talks about how she introduces GitHub Copilot’s Agentic Mode to enterprise customers. Her observations resonated deeply with my own experience.

Julia describes a spectrum: on one end, companies with strong engineering cultures that immediately ask „what’s the newest thing we can try?“ On the other end, traditional companies where she has to dictate prompts word by word to developers with 25 years of experience. Not because they’re bad engineers — but because the mental model of „describe what you want in natural language“ is fundamentally different from „write explicit instructions in a programming language.“

Here’s what struck me: I had the opposite advantage. As a non-developer, I never had to unlearn the traditional coding mindset. Describing what I want in natural language? That’s literally how I’ve communicated with teams my entire career. The conversational development loop came naturally because I was never trained to think in code first.

Julia makes another critical point: context engineering matters more than prompt engineering. It’s not about crafting the perfect prompt — it’s about giving the AI the right information to work with. Her mantra: „Teile und herrsche“ (divide and conquer). Break the task down. Give the agent precisely the context it needs for this one thing. Not everything at once.

This matches my experience exactly. My best Claude Code sessions happen when I’m specific about scope. My worst sessions happen when I dump the entire project on Claude and say „make it better.“

The Human Side of AI Adoption

Julia also describes a pattern I’ve seen play out in companies everywhere: change comes from both directions simultaneously. Executives read about AI on LinkedIn and demand adoption — often without talking to the actual developers. Meanwhile, individual engineers start experimenting on their own, share cool results with their team, and create grassroots momentum. The poor middle management? They’re stuck trying to reconcile „move fast!“ from above with „but safely!“ from the same above, while developers are already three tools ahead.

Her advice to all of them: „Don’t wait for Microsoft or Anthropic to tell you what best practices are. Install the tool, try it, develop your own practices.“ Because every team, every codebase, every company culture is different. What works at a fintech startup won’t work at a car manufacturer — and that’s fine.

The biggest mistake she sees? Companies abandoning everything they learned about software engineering in the last 15 years because „we have AI now.“ Tests still matter. Code review still matters. Security scanning still matters. The pull request has YOUR name on it — not the agent’s.

The Honest Downsides

I won’t pretend this is all upside. There are real risks to this approach:

Dependency. I can’t debug my own code without Claude. If Anthropic’s API goes down, I’m stuck. That’s a genuine risk, and I think about it.

Technical debt. When you’re building fast, you accumulate shortcuts. Claude Code will happily implement the quickest solution unless you specifically ask for the robust one. You need product discipline to say „no, do it properly.“

The illusion of understanding. Sometimes I think I understand how a piece of my code works, and then Claude is unavailable and I realize I was leaning on its explanations more than I thought. I’m working on this — reading more of the code myself, asking Claude to explain its decisions more often.

Cost. Claude Code with Opus isn’t cheap. I spend real money on API calls every month. For a hobby project, it’s expensive. For a business, it’s cheaper than a developer — but it’s not free.

These are honest trade-offs. Anyone considering this path should know about them.

Why This Matters Beyond Me

I’m one person. An unusual case, maybe — a 50-year-old product executive who decided to build his own software. But I don’t think I’ll be unusual for long.

The tools are getting better every month. What required Claude Code today will require a simpler tool tomorrow. The barrier to entry is dropping fast.

And when it drops far enough, the world changes. Not because non-developers will replace developers — that’s a lazy take. But because the millions of people who understand problems deeply but can’t code solutions will finally be able to build. Product managers, domain experts, small business owners, community organizers.

The Marktmeister builds the market app. The marina operator builds the marina system. The insurance professional builds the risk tool.

That’s not a threat to professional development. It’s the biggest expansion of the builder class since spreadsheets.


This is Part 4 of a 7-part series about my journey from zero coding experience to building production applications with AI. In Part 5, I’ll deep-dive into Energy Backbone — my first real SaaS with IoT, smart meters, and payment integration.

Try what I’ve built:

  • 🧞 [CalendarGenie](https://calendargenie.replit.app) — Turn any screenshot into calendar events
  • ✍️ [Post-er](https://post-er.replit.app) — AI-powered content creation
  • ⚡ [Energy Backbone](https://energy-backbone.bigdataheaven-software.de) — Smart energy management
  • ⚓ [Marina Master](https://marina-master.bigdataheaven-software.de) — AI-powered marina management

Andreas Kulpa is Executive Director of Product Management at CRIF and a vibe-coder based in Wiesbaden, Germany. He builds software the way he used to build strategies — conversationally. Connect with him on [LinkedIn](https://linkedin.com/in/akulpa).