My Insights from Vibe Coding a CAD App

Vibe coding, a term coined by Andrej Karpathy to describe this new art of software development where you fully surrender to the clairvoyance of AI agents, has become the latest trend in the “you can just build things” corner of the tech world. Weekend projects are now reaching levels of completion that were once hard to imagine, except for a handful of wizards—not just of programming, but of knowing how to filter what’s worth doing and optimizing their own workflows. Tell the AI what you want to achieve, take what it gives you, and tweak it on the fly, ideally with new prompts.

Trying to assess this without bias, the outlook is exciting. As an engineer, few things paralyze me more than a blank slate—that overwhelming “there’s so much to do and so many places to start.” Another common hurdle: figuring out if there are libraries that can handle the less critical parts of the work (and checking their reliability, since blind trust isn’t an option). The deep search mode is another blessing AI brings to these scenarios. This is definitely a pool I’m eager to dive into.

Here’s my pitch in a nutshell. I’ve seen plenty of vibe coding attempts focused on building games, so I went for something less common that, if done well, could find an audience: a CAD app for circuit analysis and design. Or at least, an MVP that might one day evolve into that. Since I’ve already said “where to start” breeds analysis paralysis, I offloaded that first step: I asked Grok to list requirements and break the MVP development into the smallest possible tasks.

Initial prompt where I ask Grok to take on a role, outline the project, and suggest tools to make it feasible with React as the foundation. Since this is mostly about researching resources, I used DeepSearch mode.

The result? The goal became an MVP that lets users connect DC voltage sources with resistors in a circuit and calculate voltages and currents. Basic Ohm’s and Kirchhoff’s laws stuff—capacitors, electronics, or AC circuits are out of scope for now, which feels like a reasonable call.

For visualizing and interacting with the circuit, Grok suggested Konva.js, a framework for drawing on the HTML5 canvas (which it claims should outperform an SVG-based approach). The search also turned up existing JavaScript-based solutions like SimcirJS and circuitjs, noting they also lean on canvas.

Simulations for voltages and currents only need linear algebra, so math.js should do the trick. Since the app can be built as a SPA, Vite is all the extra support needed.

Second prompt
In the next prompt, I asked Grok to break the MVP development into atomic tasks. This time, I went with Thinking mode.

For this second step, Grok gave me 18 tasks, each with a short description, a list of steps (usually two or three), and a purpose. The tasks felt focused and rarely tried to take on too much at once.

The output struck me as clean and well-grounded, with a sequence most pros would likely nod at:

Set Up the Project Environment

Install and Set Up React Konva

Design the Basic UI Layout

Create the Component Palette

Implement Drag and Drop for Components

Add Editable Properties to Components

Implement Wire Connections

Create the Circuit Model

Update the Circuit Model Dynamically

Implement Nodal Analysis for Simulation

Install math.js for Linear Algebra

Add Simulation Button and Display Results

Label Nodes on the Canvas

Implement Ground Node Handling

Add Zooming and Panning to the Canvas

Implement Undo and Redo Functionality

Add Basic Error Handling

Test the MVP

This might be my favorite part of diving into vibe coding (or vibe planning, at this stage). A casual, high-level chat about a feature can quickly turn into a precise, well-structured task plan with almost no effort.

Another perk of this initial phase is that it lays out a clear, written foundation for the coding agent to know exactly what to do. While I kept this part simple in a single conversation, weaving it into an AI-driven workflow feels like low-hanging fruit with immediate payoffs for any project.

So, what about the code?

My next message to Grok was to tackle the first task using Bun and come up with a catchy, unused name. That’s how CircuitSpark was born.

Beyond the name, Grok replied with a series of commands to kick off the project instead of dumping a bunch of code files—an approach I prefer since CLIs give deterministic outputs.

From there, it was just a matter of telling it to implement the next task. We started seeing actual generated code with the first React components, sprinkled with occasional commands for steps like installing dependencies. I ran the commands, copied the code into my editor (with maybe slight style tweaks), tested it, and asked for the next task (aside from a quick note that I’d rather use TypeScript than plain JavaScript). Everything worked as expected up to task 7.

Task 7 was the first where I hit bugs running the project. Basically, each component (a simple rectangle) had circles as terminals. Dragging the rectangle moved the component, while dragging a terminal was supposed to create a connection if dropped near another component’s terminal—without moving the original terminal. (The connection? Just a line from terminal A to B, obviously.)

What actually happened was the terminal moved with the drag-and-drop. Since the goal here was to charge ahead with pure vibe coding, I did what you’re supposed to: I told Grok, “There’s a bug in task 7’s implementation.” No context, just figure it out—you’re the one who’s supposed to know everything.

Grok’s response listed four potential issues (terminal positioning, snapping logic, line rendering, state updates) and suggested fixes for each. It then churned out code and described the changes. But nope, the app still misbehaved the same way. Sorry, Grok, not buying it—own up to your skill gaps.

That’s when I finally put on my developer hat instead of my vibe coder one. I dug into the code snippets most tied to the failing feature and poked around Konva’s docs. After a bit, I realized it was an event propagation issue: the terminal’s drag-and-drop was also triggering the rectangle’s (or group’s, to be precise) handlers. Bug fixed.

I told Grok what the issue was and how I’d tweaked the code (this is where you really miss something like Windsurf or Cursor to tie this agentic coding into your actual codebase). Then I told it to hit the next task.

From there, perfect runs (Grok nailing a task without new bugs) got rarer. At some point, I also felt the urge to refactor some antipatterns—most uses of useEffect are guilty, just accept it. Grok’s speed at churning out mostly solid answers is impressive, but I was starting to hit the limits of either the model or how I was using it back then.

The stickiest issue came with math.js, where Grok was dead-set on using methods from an outdated version of the library. I also concluded its approach to solving circuit problems with Kirchhoff’s Laws via linear equations and matrices was far from correct. At first, I blamed the lack of a ground node, which wouldn’t come until a later task.

Zooming and panning were another headache, with fresh event bubbling issues and misuse of positioning/offset values (you’ve got to watch what those are relative to). I fixed most of the glitches, but I’m pretty sure some edge cases are still doing their own thing.

How’d the rest of the code hold up as the implementation evolved? Was it robust, suitable, and scalable?

For domain logic, Grok mostly suggested sound approaches—some even had clever upsides—but a few ideas didn’t feel built to scale. Overall, it did a solid job with domain logic, and access to vast info gives it an edge. Still, there’s clear room to grow in agentic coding, reinforcement learning, and beyond.

With just two tasks left (error handling and tinkering with the app) and after some neat UX/UI additions from Grok (like Undo/Redo), I decided to pause development for now. The interface was decent as an MVP, but the math needed a serious overhaul. Until I dust off my electrical engineering notes and circuit analysis skills, pushing forward doesn’t make much sense. Plus, a few garbled responses hinted I might be hitting context size limits—time to call it a day and maybe rethink the approach for a future iteration.

Conclusion

In short, vibe coding with cutting-edge LLMs like Grok offers a fresh take on software development—one that, to me, comes with this share of pros and cons at the moment:

What I Loved:

Speeds Up Planning: Turns casual chats into precise, structured task plans.
Cures Analysis Paralysis: Jumpstarts projects by offloading requirement definition and initial prioritization.
Automates the Grunt Work: Churns out boilerplate code and sets up environments efficiently.
Uncovers Tools and Libraries: Suggests relevant frameworks and libraries, cutting research time.
Broad Domain Knowledge: Makes spinning up MVPs and experimenting with ideas a breeze.

Where It Falls Short:

Implementation Limits: Agents can stumble on complex algorithms (drowning in noise that clouds reliable domain knowledge) or libraries mid-update (like math.js).
Refactoring Needed: Code can carry antipatterns and need cleanup for quality.
Model Dependency: Code quality hinges on the AI’s capabilities and context grasp. I didn’t hit a project too big for the convo context, but there’s a tipping point where effectiveness drops. Cramming it all into one Grok chat also tested context limits.
Needs Oversight and Fixes: Generated code can have bugs and demand manual fixes—keep an eye on it.
Workflow Integration: Not a flaw per se, but right now, it’s about experimenting with tools and approaches to nail vibe coding. Expect dedicated recommendations and software soon.

My Insights from Vibe Coding a CAD App

Conclusion

Links