The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Back to feedPost
AI-Assisted
Development vs. Vibe Coding: Who Is Actually Making the Decisions?
Using
AI to write code is not the same thing as outsourcing the thinking.
Not every AI-assisted project is “vibe coding”
Over the last couple of years, “vibe coding” has become a label people attach to almost anything made with AI. Ask ChatGPT to write a function? Vibe coding. Use Claude to inspect a bug? Vibe coding. Let a model generate most of the implementation because you cannot write thousands of lines of C++, Lua or Kotlin yourself? Same label again.
I do not think that distinction is useful. In several of my own projects, AI writes a large part of the code. I am not a traditional programmer, and I do not pretend to be one. But the more complex the project becomes, the clearer the difference is between using AI as an implementation tool and letting AI become the actual decision-maker.
For me, the important question is not who typed the code. It is: who is deciding what should exist, why it should work that way, what evidence matters, which approach is wrong, and when to stop?
Problem first, product second
A good technical project usually starts with a real problem. One of my examples was an in-game settings framework for mods. The idea did not begin with “I want to build a framework.” It began after several mods had accumulated separate config files, console commands and awkward setup steps. The user experience was becoming unnecessarily fragmented.
That changed the design goal completely. The question was not “how do I make the architecture look professional?” It was “how can another mod author expose a toggle, number or option with the least possible friction?” I even tested my own documentation as if I were a newcomer who did not know the internals. If a framework is supposedly for other people, then those people are part of the product.
This is where AI can become dangerous in a surprisingly boring way: it is very good at producing architecture that sounds impressive. Ask for a scalable framework and you may quickly get providers, adapters, registries, runtimes, lifecycle layers, protocols and abstractions. None of those things are inherently bad. The problem is when the architecture appears before the need for it.
AI is excellent at solving the wrong problem
One pattern keeps repeating in difficult projects. AI makes a plausible assumption, builds a solution around it, and then starts repairing the consequences of that assumption instead of questioning the assumption itself.
A slow operation gets a cache. The cache becomes stale, so invalidation is added. Invalidation fires too often, so a debounce layer appears. The debounce breaks updates, so a fallback is introduced. A few iterations later, the project has a “performance-focused architecture” largely because performance problems created by the architecture had to be fixed.
The individual steps can all look reasonable. That is what makes this hard. Generated code does not need to be obviously broken to lead a project in the wrong direction. Sometimes the correct move is not another fix. It is to go backwards and ask whether the whole path should exist at all.
The human can quietly become the assistant
There is a version of AI development where the model chooses the architecture, writes the code, analyzes the logs, explains why its previous hypothesis was wrong, proposes the next fix, writes the documentation and prepares the release notes. The human runs the build, sends back the log and says: “still broken” or “now it works.”
At that point, calling the process “AI-assisted development” feels backwards. The human is assisting the AI development process.
The number of iterations does not fix this. A project can go through fifty, a hundred or two hundred passes and still be based on the wrong model of the problem. Iteration is useful only when someone is actually learning from the result rather than treating every failure as a request for the next generated patch.
What I mean by AI-assisted development
The workflow that works for me is different. AI may still write most of the implementation, but I keep responsibility for the product and the system.
That means finding the problem, defining the intended behavior, deciding what evidence would confirm or reject a hypothesis, testing the real result, reading logs, comparing expected and actual behavior, discarding approaches that stop making sense, and simplifying when the model starts building layers around a bad assumption.
In reverse-engineering projects this becomes especially obvious. A model can produce a beautiful explanation of how a binary structure probably works. Then the game renders garbage. The garbage wins the argument. Reality is the test suite.
The same is true outside reverse engineering. A feature is not good because the implementation is elegant. A framework is not useful because the README is long. A project is not mature because it went through many internal versions. The useful questions remain simple: does this solve a real problem, does it behave correctly, is the complexity justified, and can the intended user actually use it?
AI-assisted development and human-assisted AI development
The distinction I use now is roughly this.
In AI-assisted development, the human finds the problem, sets the goal, owns the product logic, tests assumptions, rejects bad directions and is responsible for the result. AI accelerates implementation, explores options, analyzes logs, helps with reverse engineering and removes a huge amount of repetitive work.
In human-assisted AI development, the model effectively owns the project: architecture, code, documentation, fixes, optimization and even the explanation of what was built. The human mainly supplies execution and approval.
Both workflows can produce something that launches. From the outside, they may even look similar at first. The difference usually appears later: when a system needs to be changed, simplified, debugged after an update, adapted to a new constraint, or explained to someone else.
The most important skill may be saying “no”
AI makes software creation dramatically more accessible. For someone without a classical programming background, that is extraordinary. Problems that would previously have been completely out of reach can now become workable projects.
But accessibility does not remove judgement. If anything, it makes judgement more important, because generating complexity is now cheap.
The most valuable AI skill I have developed is not prompt engineering. It is being able to look at a polished, confident answer and say: “No. This is solving the wrong problem. Make it simpler.”
And sometimes the even better question is:
“Why are we building this at all?”
That is where I draw the line between AI-assisted development and vibe coding. Not at who typed the code, but at who is actually thinking about the product.
The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Related posts
Amazing work
Branding Design for a AI Startup
The client wanted a solution to its boring and non-convertible logo and we came with with a solution by creating a branding that converts and speaks to its clients.
This color palette is nice🙌
Experience buys you time.
Good references help a project, but they're not what saves it. What saves it is knowing the tools within your reach and the creative processes you can run.
I'm not an animator. Still, this project, which started recently here at the studio, called for animation: hand-drawn characters, in thin lines, living around 3D pieces from a furniture company, for a set of product Reels.
The client needed it in two days. Done the traditional way, it would have taken far longer, so I turned to AI tools. But using the tool for the tool's sake would never have gotten me here.
What got me here was the process. I spent my time hunting for the right reference, and found it in Vitra's "Mariposa Family" film, an excellent reference for illustration and for bringing 3D and drawing together. From there, the tools and the workflow I've built over the years did the rest. There's still room to improve, I know, but it's a good step forward.
I hear a lot that AI will take some designers' jobs. Maybe it will. But I see it a little differently. AI lets you do things that used to take far more complex processes. An axe in a lumberjack's hands brings a tree down. In a beginner's hands, it rarely gets the same result. AI works the same way: in the hands of someone who knows how to use it, it doesn't take work away. It creates more.
The tools will keep changing. What doesn't change is each designer's sense of aesthetics: knowing what fits, how it fits, and what to do. AI can make almost anything. Deciding what deserves to be made is still up to us.
Has AI taken work from you, or brought you more?
You brought creativity to the table 💪