As I'm prepping Season 5 of The Adventures of Blink, I've been building the code for our Adventure ahead of time.
SIDE NOTE: Season 5 starts NEXT WEEK!!!! Episodes drop on Thursdays just like our Adventures here - make sure you come by the Youtube channel and leave me a like, a comment, even just an emoji... and click subscribe. It's free and it helps more people find our Adventures together!
In the process of building our app, I've been using AI as a companion. It's readily available, usually faster than me wading through the docs for whatever random thing I need to remember how to do, and, well, most of all... I'm curious about it. There's tons upon tons of hype out there, and folks who've sold out to the idea that software engineers are going to be replaced next week. Is it true? One way to find out is to try it out and see... so the fact that I'm regularly building something for an education project is a really handy tool for experimentation. (Ooh, we should talk sometime about the value of building in public and learning in this fashion...💡💡💡)
Anyway... as I'm doing this, I thought I'd write down some things I learned from the process. What follows are some observations from several weeks of coding work.
You'll note that I call myself a "half-committed" Vibe Coder. What I mean by this is that I'm not necessarily meeting the definition of VibeCoding - I don't just yeet my requirements in there and tell the model to generate the code. I'm working alongside it, writing as much code myself as I'm asking it to write, and using it for sounding board and exploration.
Also, I do software work for a day job in addition to The Adventures of Blink. Some of my observations come from that work, too.
Watching a Bubble Pop In Real Time
The longer I use it, the less I trust AI tooling to take on big things. This is weird to me, because as I listen to the Hype Machine, they're recommending the exact opposite approach. "You need to give it more freedom! You need to write less code yourself and get the bot to do more for you!"
But literally every time I do this, it gets in over its head almost right away! The project we're building for Season 5 is a game... so it has a couple basic patterns to consider:
- The game Event Loop
- Screen painting logic
- Loading & Saving
It's important to note that I'm not thoroughly designing every requirement and building a full project plan... because that's not usually how a hobbyist works. We like to build some basics, get a couple things working, and then try to add features. This isn't like a Waterfall shop where we have a couple of weeks of design phase to document every capability before anyone touches a keyboard.
This brings me to my first point:
Your Copilot will absolutely lead you down the Primrose Path
When I said "I'm thinking about building a Breakout clone game"... the LLM started in the middle. It began responding to the idea of building a Pygame-based application and constructed a main loop that initialized the game right in the window.
I had to stop it and say, "Hey, wouldn't the game's user experience be better if we had a main menu before just dropping you into the game?"
record scratch
It immediately built out the main menu code in our chat. But then I had to stop it again, and point out that I had an empty project structure - how am I going to organize the code files? Where will my art assets live? What about the app's configuration file, so that I'm not hard-coding all my variables into it? Automated tests?
My point in all of this is that you can't eliminate the human developer from this conversation. In its eagerness to please, AI completely bypasses the design thinking and decisions that make the project maintainable. It doesn't stop to ask questions about the big picture, it just builds...
...Like a brand-new junior developer.
Would you just turn a fresh-out-of-school new hire loose on your company's mission-critical applications with minimal guidance? If not... why would you ever do it with an AI?
The Token Consumption Loop
I gave my copilot a task to build a function with a very simple calculation in it that I didn't feel like doing (fight me, Trigonometry class was 2 decades ago 😏).
SIX ITERATIONS LATER, we have something that I'm still not completely happy with, but it's kinda functional. My copilot and I have argued over how this works for a couple hours at this point, and I'd be embarrassed to find out how many tokens I burned on the problem. I'm frustrated with it and at the point where I'm most likely going to pitch the whole thing out and rewrite from scratch. My "time-saving" vibe-coding prompt has cost me more time than stopping to figure it out by hand.
That wasn't a one-off situation, either; I've had the same experience repeatedly.
Another observation I've had in this space is that when I ask it to do something, it... talks. A LOT. I can ask a question that should resolve to a one-liner, and it feels the need to explain the whole history of the process of getting that to a one-liner. Even when I ask it to be terse, it still tries to explain itself more.
In a world where tokens-per-invocation is highly monetized (and therefore, tightly controlled by budget), it's just not cost-effective... and even borderline suspicious. If you're selling tokens, it certainly makes sense that you'd squeeze as many as you can out of every invocation...
Ensloppification
At work, I picked up a story to do some refactoring on a 1,000-line python module. The signs of vibe-coding are there:
- One file, a thousand lines long.
- Three different classes declared in it.
- The core functionality in the module wasn't even part of any of the classes, it was just riding along in the file.
- No organization to the code - just a plate of 🍝 to try to trace my way through.
- Circular import logic.
- Minimal documentation / comments, and what was there didn't really explain anything.
- Files were opened and read and their content was never used before the variable was used to open a different file and read it in.
- Our static analysis tool had a stroke - one method scored 211 on the cognitive complexity calculator.
Now, it's important to realize:
The code works. The outputs match the inputs. If someone who's never done coding work before picked this up, they'd be excited by it (and that's kinda the story-- the business execs saw it run and were thrilled with how fast we delivered).
But this module is the first use case in what we anticipate will be a family of use cases... each of which will need a customized version of this module that plugs into the overall application frame.
In its current state, this code can't be an example to another developer of how to build your use case.
Think about it: the new requirement comes in to build the second use case, and what's the developer going to do? LOOK at the first one! And he'll spend days unraveling the spaghetti.
And now the arguers appear
A lot of you reading this will probably want to correct me, to explain why I'm being unfair to our new AI overlords, why my opinions are invalid.
That's totally cool. We should be debating these kinds of things, and we should do it in a civil manner. So here are some of the things I've already thought of as counterarguments to this post:
- The "Junior Dev" Analogy is a Feature, Not a Bug
Blink, you should be scaling up so you have a collection of a hundred Junior Devs doing your bidding, while you're the Architect!
This feels compelling, and on the surface it seems like it should be empowering... but it doesn't reconcile with what we hear in the hype, does it? I just refreshed my LinkedIn feed and the first 3 posts were people telling me how AI Agents have ended software engineering, we just don't know it yet... how the AI-pocalypse is upon us and our entire profession is on the chopping block. So which is it? Are we being empowered or destroyed? Can't really be both.
- The "Vibe Coding" vs. "Agentic Workflows" Gap
Blink, you're just doing it wrong. These problems exist because you aren't using $SOME_FRAMEWORK, or $SOME_MODEL.
I find it highly suspicious when anyone promises that I'll get all the benefits, as long as I just add this one other thing... because it becomes a perpetual "you need one more thing". I feel the ick, like when a pyramid marketing scheme person comes after me.
- "Ensloppification" is a Human Discipline Issue.
Blink, you could actually cure ensloppification with AI if you just prompt it to produce clean code...
Here's the problem with this line of reasoning: AI is being marketed as a way to make it possible for ANYONE to build an app. And it's being used by ANYONE, regardless of their knowledge level, to build apps.
You're not wrong: the human is absolutely responsible for the quality of their code. But many of them probably don't know that yet. And they're going to put things out into the world that look like good apps... that work... that might even generate revenue... yet they're buggy and full of security holes and dangerous to use but there's no way to tell them apart from well-engineered production-quality systems.
We saw this just a couple weeks ago, when someone vibe-coded a platform that hit 1.5M users in 4 days. And then 3 days after that, the entire production database was accessed and leaked - API keys, emails, private messages.
Y'all. We have enough trouble keeping the bad guys out in traditional software engineering, and this vibe-into-production model is over here leaving the key in the doorknob.
Wrapping Up
I'm excited about new tech... it's a major reason why I'm in the field. What I'm not excited for is irresponsible uses of new tech. Our planet has enough problems already without us destroying the software that runs it.
All I'm asking for is a little caution and thoughtfulness. Is that too much?
Top comments (0)