The “vibe” is seductive.
As an engineer, I first embraced AI just like everyone else—I was “vibing.” It felt like magic to have boilerplate code generated in seconds. But magic isn’t sustainable for production systems.
There is a big difference between exploring a tool and deploying it. When I was just vibing, I was playing, exploring capabilities without consequences. But when I went all in on using AI for MapSimple’s production tools, the mindset had to shift instantly from hobbyist to engineer.
This is why language matters. In the future, job descriptions will need to distinguish between casual AI use and engineered workflows.
Hiding the Problem vs. Solving the Root
My biggest “oops”? While adding a new feature, I noticed that one result added three graphics to my layer instead of one.
My initial approach? I vibed a fix. I asked the AI to address the issue, and it created a function to remove duplicates. Problem solved, right? Wrong.
Later, when cleaning up my codebase, I realized the function was hiding a deeper issue. It treated the symptom, not the disease. After I removed the function, the graphic problems returned immediately. The AI kept trying to re-add it because it missed the root cause.
What actually happened was that during my vibing path, I implemented three different features, which resulted in three branches sending data to the graphics layer.
To fix it, I had to stop vibing and start vectoring. I had to direct the AI to analyze the architectural flow, find the root cause, and re-engineer the logic so that only one graphic was generated in the first place. That is the difference between chaos and strategy.
Beautiful Code vs. Good Code
Here is the hardest truth I’ve learned about AI: AI creates beautiful code, but it doesn’t always create good code.
For a disposable script I’m writing just for myself—a quick vibe to get something working—a patchwork fix like removing duplicates after the fact is fine. But that doesn’t work for professional tools built for teams or communities.
“Good” code is not just about what it looks like on the screen. It has to be:
- Thoughtful: Architected with the entire system flow in mind.
- Intentional: Every line serves a specific purpose, not just a reactive fix.
- Ordered: Logically structured, not a chaotic tangle of symptoms hidden by more code.
The Definition of Vector Coding
I define Vector Coding as the disciplined use of AI as an engineering tool, in which a human expert provides the specific direction (architectural intent) and magnitude (functional requirements) to steer the model toward a precise, validated result.
The term “vector” is chosen specifically to contrast with “vibe”:
- Vibe Coding is a Scalar: It has magnitude (functional code is produced) but lacks direction (engineering intent).
- Vector Coding is a Vector: It has both magnitude (functional requirements are met) and direction (specific architectural intent is provided).
The Three Pillars of Vector Coding
- Defined Direction: The engineer dictates the architecture, stack, and security protocols before generation.
- Intentional Magnitude: The scope of the AI’s involvement is tightly constrained.
- Human Stewardship: The expert validates the output, ensuring it aligns with the overall project strategy.
The Call to Action
Vector Coding isn’t just about getting code to run; it’s about engineering code that lasts. I invite the community to adopt this term and use it to clearly distinguish professional, AI-augmented engineering from mere experimentation.
Have you had your own “oops” moments shifting from vibing to vectoring?