Vibe coding seems to be all the rage right now. Vibe coding is a casual, flow-driven approach to building software — often without a strict plan or spec. It’s about exploring ideas, trying things out quickly, and letting the code evolve organically based on what "feels right" in the moment.
Last weekend, I decided to test out vibe coding with Cursor AI, the VS Code-style IDE infused with generative AI capabilities. I gave myself one challenge: could I take a raw idea and build a full, production-ready web app in just two days?
Spoiler: I more-or-less did.
Cursor helped me ship a responsive, fully deployed web app with both frontend and backend components — in a single weekend.
And the process revealed a lot more than just the power of modern dev tools. It gave me a glimpse into where engineering is headed next.
What I Built (and How Fast)
Using Cursor AI, I was able to:
Build both the frontend and backend, fully deployable, from scratch to production
Make the entire interface responsive — it worked cleanly across desktop and mobile
Feed wireframes from Gemini and ChatGPT-4o image inputs (and some Microsoft Paint monstrosities I came up with), and have Cursor generate working React code with surprising accuracy
Helped configure a MongoDB Atlas database that I could use for both a local and a production environment
The dev workflow was fast and smooth — but not magic. You still need to know what you’re doing. That said, even when you aren’t sure, tapping into ChatGPT or Copilot serve as remarkably faster tools for edification than Stack Overflow ever used to do for me in my ex-dev days.
Cursor in action after suggestion code changes. I ultimately have the ability to review, reject or accept the changes.
The Catch: You Still Need Engineering Chops
Here’s the reality: if you don’t know the fundamentals of software development, you’re going to burn time and money. Cursor is powerful, but only when paired with the right context and prompting.
Some real examples:
Cursor would default to running terminal commands in PowerShell instead of cmd, causing errors. Defining a default instruction rules-set could help here.
It tried to execute scripts from the wrong directory, simply because the prompt lacked specificity.
In the worst of situations, it would often times not find the appropriate directory and create redundant file structures which then led to refactoring exercises in the future if you missed these actions.
Without understanding best practices, you risk deploying insecure, unstable, or just plain inefficient code
The Cursor Reddit community is currently up in arms over a supposed recent Context scope change made by the company which has made the IDE less precise, in turn forcing the user to be more specific about their engineering prompting.
Prompting is a skill. And right now, the value of a good engineer is being able to translate abstract goals into high-context prompts while understanding the infrastructure it all runs on.
Reflections on the Role of Engineers (and the Replit Controversy)
The CEO of Replit recently said that “it’s no longer worth studying programming.”
I disagree — at least for now. But I understand where the statement is coming from.
AI models are already smoothing over tasks that used to require years of experience. If Cursor (or tools like it) can handle frontend layout, boilerplate backend scaffolding, and deployment — all from a prompt — then what exactly is the engineer’s role in five years?
I think we’re heading toward a shift:
From builder to orchestrator
From writing every line to designing systems, shaping architecture, and managing the interface between human goals and machine output
We already have a term for this — prompt engineering — but it’s only the tip of the iceberg. You still need someone who understands APIs, CI/CD, auth flows, and all the “complicated stuff” that makes software actually work.
“The dev stack is changing. Fast. Adaptation is the new comp sci degree.”
The Broader Ecosystem (and the Strange Case of Apple)
For this weekend build, I leaned on a few AI tools:
Cursor AI (leveraging Anthropic’s Claude models) - as the primary dev tool
Microsoft’s Copilot, built into my Surface Laptop - Windows specific questions
Gemini - image generation, some Typescript code reviews, and an extra pair of eyes on console error logs
ChatGPT-4o for image-to-code and Vercel deployment troubleshooting
Each had its strengths. But there’s a glaring absence in the mix: Apple.
Not long ago, the idea that Apple might be falling behind in a core technology would’ve felt laughable. But when it comes to generative AI, especially in developer tooling, they’ve been almost invisible.
Siri remains far behind. Apple’s traditional playbook — building its own tightly integrated solutions — may not be fast enough to compete in this cycle. If Apple wants to stay relevant in AI-powered computing, they may need to do something bold. An acquisition of Anthropic doesn’t sound that far-fetched anymore and would immediately get them on an even playing field with Google, OpenAI, and Microsoft.
And this says nothing of the complexities of international competition with the likes of China and DeepSeek’s rumored reasoning model jumps.
Final Thoughts
I went into the weekend curious about a tool. I came out of it convinced we’re watching software development itself transform — and quickly.
The tools are strong. The pace is wild. But the engineer isn’t going away. We’re just being asked to level up in new directions:
From syntax to systems
From code to context
From typing to prompting
And it’s actually pretty exciting.
Great points. The challenge I see in role evolution is that we only need those many developers to do high level design, orchestration stuff. Net of it, this will reduce the absolute number of developers needed in a company. Much of work in development is grunt where lot of developers time was getting spent. So developers themselves may not become more productive but be replaced by AI-enabled IDE and few left will have to upskill to do the other orchestration referred here