.svg){kind=spacer}
PROMPTS ARE THE NEW SOURCE CODE : I tried Vibe coding and it was liberating
March 17, 2025
I’ve spent two decades in technology, more than half of that in customer engineering roles. But most of my work has been on the infrastructure and systems side—designing networks, optimizing workflows, making sure everything runs smoothly. Outside of basic scripts, I never wrote any real code. It wasn't for lack of trying. Back in college, I wanted to be a good coder so badly. I loved logic and problem-solving. But when it came to expressing ideas through code, something never clicked. I just couldn’t stick with it.
So I leaned into what I was good at—systems thinking. I built a career understanding the architecture of things, connecting dots, scaling systems. But deep down, the inability to code felt like a gap. I couldn’t build software. I couldn’t create on my own.
That gap stayed with me. Until now.
Subscribe now to unlock the full article and gain unlimited access to all premium content.
SubscribeI’ve spent two decades in technology, more than half of that in customer engineering roles. But most of my work has been on the infrastructure and systems side—designing networks, optimizing workflows, making sure everything runs smoothly. Outside of basic scripts, I never wrote any real code. It wasn't for lack of trying. Back in college, I wanted to be a good coder so badly. I loved logic and problem-solving. But when it came to expressing ideas through code, something never clicked. I just couldn’t stick with it.
So I leaned into what I was good at—systems thinking. I built a career understanding the architecture of things, connecting dots, scaling systems. But deep down, the inability to code felt like a gap. I couldn’t build software. I couldn’t create on my own.
That gap stayed with me. Until now.
The X Module Breaks
Recently, I got an email from Make informing me that they were deprecating their X (formerly Twitter) module due to API cost reasons. I get it—infrastructure costs add up. But for me, it meant something crucial was breaking. I had until April 30th to find a replacement.
My entire automation stack lived in Make. Ripping it out wasn't an option. I needed a modular solution that replaced the X module cleanly and kept everything else intact. So I started looking.
Discovering Vibe Coding
As I started exploring tools, I came across an episode of the Startup Ideas Podcast where Greg Isenberg and Ras Mic break down a category of tools known as "vibe coding" platforms. In that episode, Ras lays out two line spectrums to categorize these tools.
- Control: How much control do you need over your code?
- Technical skills: How technical are you?
It was a lightbulb moment. I suddenly had a way to map these tools to my needs.
I started with Bolt. It seemed intuitive, simple, and built for someone like me. But 20 minutes in, I was stuck. Prompting felt random. The UI wasn’t helping me structure my app. I realized I needed more control—not less.
Then I remembered I had some Replit credits.
Building With Replit + ChatGPT
This time, I wanted to be prepared before i got started with Replit. So, I spent time with ChatGPT defining the structure of what I needed. I honestly didn't know where to start, so i explained the scenario to ChatGPT 4o and asked if there was a way to replace just the Twitter/X module with a simple app, while preserving the rest of the processing as-is.
After a few prompts back and forth, 4o suggests creating a simple app that would retrieve tweets and pass it to a webhook in make. That way, we can just replace the X module in the scenario with a webhook, which will be setup to accept data from our app.
I have never built an app before, but i understand systems and data flow pretty well. So, I asked chatGPT 4o to explain the data flow to me using a diagram so i had a visual of what the architectural components could look like. Now, this was actually "too" simple, but did gave me a good overview of how things will connect and data will flow.
I kept going. It felt very natural, as if i was speaking to an engineering collaborator, breaking down the app into its components and trying to understand how to build it. I was asking it questions about features, feasibility and even deployment strategies. Sometimes, i was unsure so i would offer my thoughts and ask it to clarify. It felt collaborative and in about 15 minutes, i had an understanding of the app that needed to be built and a prompt to get started with Replit.
Armed with confidence and a prompt, i got started with Replit. This process was daunting when i started, because i wasn't sure how the Replit agent functioned. I asked it questions, the same way i did with chatGPT 4o. Within a few minutes i had a visual preview of the UI, with some functioning components.
In the past when i spent time debugging things with chatGPT, screenshots proved extremely helpful. So, i took screenshots of errors and provided it to the Replit agent. I took screenshots of the UI and pointed out where i would like buttons or features implemented. I even took screenshots of The Rift website, so it could use them as a design reference for the color scheme and UI elements.
After about 2 hours of debugging and designing, i had a functional app ! I just solved a major production hurdle with minimal change to my larger architecture. I clicked Deploy, gave it pennies worth of horsepower, and in a single click I was in production—like magic.
The Moment That Changed Everything
It wasn’t just that the app worked. It was how it worked. I hadn’t written traditional code. I didn’t architect this from scratch. I expressed my logic, step by step, and the tools filled in the gaps. ChatGPT helped me shape it. Replit made it real.
This was my first real taste of vibe coding.
The phrase finally made sense. Vibe coding isn’t about syntax. It’s about collaborating with the machine to translate ideas into reality and Prompts become the real Source Code.
Can Everyone Create Magic?
That experience opened my eyes to a whole new world. I fell into the rabbit hole of text-to-code tools. I went back to the Startup Ideas Podcast episode where Ras plots the tools along that control vs. skill spectrum. He makes a compelling point: everyone can find a tool that meets them where they are.
That made me wonder: can everyone create magic like I did?
So I started brainstorming with 4o, I explored different personas. We narrowed it down to three that represent a broad cross-section of skills and needs:
- The Designer: Great with visual flow, user experience, and interfaces. Not traditionally a coder, but knows how things should feel. With tools like Loavable or V0, they can turn mockups into working prototypes with a few prompts.
- The Founder: Resourceful, strategic, focused on outcomes. May not have the budget for a dev team, but has a clear vision. Tools like Replit or WindSurf allow them to build scrappy MVPs quickly without waiting on engineering.
- The Freelancer: Multi-talented, often juggling several clients. Has to build landing pages, automate tasks, or prototype interactions. Cursor and AI-native IDEs give them the power to extend their skills without deep coding knowledge.
What matters most is not the tool, but the approach.
Try different tools. Be patient. Break your problem into smaller parts. Plan the structure of your build with AI. Think through your features. Iterate on prompts. You don’t need to get it right in one shot—you just need to start.
Magic doesn’t happen all at once. It happens layer by layer, until one day, it works.
A Creative Shift
This wasn’t just a fix for a broken module. It was something bigger. It felt like a personal revolution.
For years, I thought building software was a club I couldn’t join. Now, a skill gap I’d carried for 20 years just disappeared. The backlog of problems I had shelved due to lack of code skills? Suddenly in reach.
It was exciting. It was liberating. It was fun.
This is probably the most empowering technological shift I’ve lived through. Not because it eliminates the need for engineers—but because it invites more people into the world of creation.
If you can imagine it, you can build it.
I’ve spent two decades in technology, more than half of that in customer engineering roles. But most of my work has been on the infrastructure and systems side—designing networks, optimizing workflows, making sure everything runs smoothly. Outside of basic scripts, I never wrote any real code. It wasn't for lack of trying. Back in college, I wanted to be a good coder so badly. I loved logic and problem-solving. But when it came to expressing ideas through code, something never clicked. I just couldn’t stick with it.
So I leaned into what I was good at—systems thinking. I built a career understanding the architecture of things, connecting dots, scaling systems. But deep down, the inability to code felt like a gap. I couldn’t build software. I couldn’t create on my own.
That gap stayed with me. Until now.
The X Module Breaks
Recently, I got an email from Make informing me that they were deprecating their X (formerly Twitter) module due to API cost reasons. I get it—infrastructure costs add up. But for me, it meant something crucial was breaking. I had until April 30th to find a replacement.
My entire automation stack lived in Make. Ripping it out wasn't an option. I needed a modular solution that replaced the X module cleanly and kept everything else intact. So I started looking.
Discovering Vibe Coding
As I started exploring tools, I came across an episode of the Startup Ideas Podcast where Greg Isenberg and Ras Mic break down a category of tools known as "vibe coding" platforms. In that episode, Ras lays out two line spectrums to categorize these tools.
- Control: How much control do you need over your code?
- Technical skills: How technical are you?
It was a lightbulb moment. I suddenly had a way to map these tools to my needs.
I started with Bolt. It seemed intuitive, simple, and built for someone like me. But 20 minutes in, I was stuck. Prompting felt random. The UI wasn’t helping me structure my app. I realized I needed more control—not less.
Then I remembered I had some Replit credits.
Building With Replit + ChatGPT
This time, I wanted to be prepared before i got started with Replit. So, I spent time with ChatGPT defining the structure of what I needed. I honestly didn't know where to start, so i explained the scenario to ChatGPT 4o and asked if there was a way to replace just the Twitter/X module with a simple app, while preserving the rest of the processing as-is.
After a few prompts back and forth, 4o suggests creating a simple app that would retrieve tweets and pass it to a webhook in make. That way, we can just replace the X module in the scenario with a webhook, which will be setup to accept data from our app.
I have never built an app before, but i understand systems and data flow pretty well. So, I asked chatGPT 4o to explain the data flow to me using a diagram so i had a visual of what the architectural components could look like. Now, this was actually "too" simple, but did gave me a good overview of how things will connect and data will flow.
I kept going. It felt very natural, as if i was speaking to an engineering collaborator, breaking down the app into its components and trying to understand how to build it. I was asking it questions about features, feasibility and even deployment strategies. Sometimes, i was unsure so i would offer my thoughts and ask it to clarify. It felt collaborative and in about 15 minutes, i had an understanding of the app that needed to be built and a prompt to get started with Replit.
Armed with confidence and a prompt, i got started with Replit. This process was daunting when i started, because i wasn't sure how the Replit agent functioned. I asked it questions, the same way i did with chatGPT 4o. Within a few minutes i had a visual preview of the UI, with some functioning components.
In the past when i spent time debugging things with chatGPT, screenshots proved extremely helpful. So, i took screenshots of errors and provided it to the Replit agent. I took screenshots of the UI and pointed out where i would like buttons or features implemented. I even took screenshots of The Rift website, so it could use them as a design reference for the color scheme and UI elements.
After about 2 hours of debugging and designing, i had a functional app ! I just solved a major production hurdle with minimal change to my larger architecture. I clicked Deploy, gave it pennies worth of horsepower, and in a single click I was in production—like magic.
The Moment That Changed Everything
It wasn’t just that the app worked. It was how it worked. I hadn’t written traditional code. I didn’t architect this from scratch. I expressed my logic, step by step, and the tools filled in the gaps. ChatGPT helped me shape it. Replit made it real.
This was my first real taste of vibe coding.
The phrase finally made sense. Vibe coding isn’t about syntax. It’s about collaborating with the machine to translate ideas into reality and Prompts become the real Source Code.
Can Everyone Create Magic?
That experience opened my eyes to a whole new world. I fell into the rabbit hole of text-to-code tools. I went back to the Startup Ideas Podcast episode where Ras plots the tools along that control vs. skill spectrum. He makes a compelling point: everyone can find a tool that meets them where they are.
That made me wonder: can everyone create magic like I did?
So I started brainstorming with 4o, I explored different personas. We narrowed it down to three that represent a broad cross-section of skills and needs:
- The Designer: Great with visual flow, user experience, and interfaces. Not traditionally a coder, but knows how things should feel. With tools like Loavable or V0, they can turn mockups into working prototypes with a few prompts.
- The Founder: Resourceful, strategic, focused on outcomes. May not have the budget for a dev team, but has a clear vision. Tools like Replit or WindSurf allow them to build scrappy MVPs quickly without waiting on engineering.
- The Freelancer: Multi-talented, often juggling several clients. Has to build landing pages, automate tasks, or prototype interactions. Cursor and AI-native IDEs give them the power to extend their skills without deep coding knowledge.
What matters most is not the tool, but the approach.
Try different tools. Be patient. Break your problem into smaller parts. Plan the structure of your build with AI. Think through your features. Iterate on prompts. You don’t need to get it right in one shot—you just need to start.
Magic doesn’t happen all at once. It happens layer by layer, until one day, it works.
A Creative Shift
This wasn’t just a fix for a broken module. It was something bigger. It felt like a personal revolution.
For years, I thought building software was a club I couldn’t join. Now, a skill gap I’d carried for 20 years just disappeared. The backlog of problems I had shelved due to lack of code skills? Suddenly in reach.
It was exciting. It was liberating. It was fun.
This is probably the most empowering technological shift I’ve lived through. Not because it eliminates the need for engineers—but because it invites more people into the world of creation.
If you can imagine it, you can build it.
