Journal of a Half-Committed Vibe Coder

Source: Dev.to

Season 5 Prep & AI‑Assisted Coding

Side note: Season 5 starts NEXT WEEK! Episodes drop on Thursdays – just like our Adventures here.
Head over to the YouTube channel, leave a like, a comment, an emoji, and hit Subscribe. It’s free and helps more people find our Adventures together!

Why I’m Using AI

While building the app for the upcoming season I’ve been using AI as a companion. It’s:

• Readily available – no need to wade through docs for every random thing I need to remember.
• Fast – often quicker than a manual search.
• Curiosity‑driven – there’s a ton of hype about AI replacing software engineers. Is it true? The best way to find out is to try it out.

(We should chat sometime about the value of building in public and learning this way… 💡💡💡)

My “Half‑Committed” Vibe‑Coder Approach

I don’t just yeet requirements at a model and let it generate everything.
Instead I:

1. Write as much code myself as I ask the model to write.
2. Use the model as a sounding board and for exploration.

I also have a day‑job in software development, so some observations come from that work too.

Observations After Several Weeks of Coding

1. Too Much Freedom = Too Much Head‑Scratching

The project for Season 5 is a game, which involves a few basic patterns:

• Game Event Loop
• Screen painting logic
• Loading & Saving

I’m not doing a full‑blown requirements document – hobbyists tend to build a few basics, get something working, then add features.

When I said, “I’m thinking about building a Breakout‑clone game,” the LLM jumped straight into a Pygame main loop that initialized the game right in the window.

I had to stop it:

“Hey, wouldn’t the user experience be better with a main menu before dropping straight into the game?”

The model instantly added a main‑menu implementation, but then I had to remind it that I still had an empty project structure:

• Where do the code files go?
• Where do the art assets live?
• How do I handle a configuration file instead of hard‑coding variables?
• What about automated tests?

Takeaway: You can’t eliminate the human developer. In its eagerness to please, AI bypasses the design thinking that makes a project maintainable. It behaves like a brand‑new junior developer.

Would you release a fresh‑out‑of‑school hire on mission‑critical applications with minimal guidance? If not, why trust an AI to do it?

2. “Simple” Tasks Can Turn Into Long Iterations

I asked my copilot to build a tiny function for a trigonometric calculation I didn’t feel like doing.

Result: After six iterations we ended up with something functional but not quite right. We spent a couple of hours arguing over how it works, and I’m left wondering how many tokens were burned.

My “time‑saving” vibe‑coding prompt actually cost more time than solving it manually.

This isn’t a one‑off; I’ve hit the same roadblock repeatedly.

3. The Model Loves to Talk (A Lot)

When I request a one‑liner, the model feels compelled to explain the entire history behind it. Even when I ask for brevity, it still adds extra exposition.

In a world where tokens‑per‑invocation are monetized, this verbosity is not cost‑effective and feels borderline suspicious. If you’re selling tokens, you’ll want to squeeze as many out of each call as possible.

4. Real‑World Refactoring Pain

At work I was tasked with refactoring a 1,000‑line Python module. The “vibe‑coding” red flags were obvious:

Bottom Line

• Human judgment still matters. AI can accelerate certain tasks, but it often skips the crucial design and architectural decisions that keep code maintainable.
• Be wary of token costs. Verbose responses can quickly eat up budgets.
• Use AI as a partner, not a replacement. Treat it like a junior developer you mentor, not a fully autonomous coder.

What’s Next?

• Continue building the Season 5 game, but reinforce the design phase before letting the model write code.
• Keep a project structure checklist (folders for assets, config, tests, etc.) to remind the AI where things belong.
• Set token limits and ask for concise answers when possible.

Happy coding, and see you on Thursday for the next episode! 🎮🚀

Cognitive Complexity Calculator

Context

The code works – the outputs match the inputs. If someone who has never done coding before picks this up, they’d be excited (and that’s kind of the story: the business execs saw it run and were thrilled with how fast we delivered).

However, this module is the first use case in what we anticipate will become a family of use cases, each requiring a customized version that plugs into the overall application framework.

In its current state, this code can’t serve as an example for another developer building a new use case.

Think about it: a new requirement arrives to build the second use case. What will the developer do?
LOOK at the first one! They’ll spend days unraveling the spaghetti.

Anticipated Counter‑Arguments

1. “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 sounds compelling and empowering on the surface, but it doesn’t reconcile with the hype we hear. I just refreshed my LinkedIn feed and the first three posts were people claiming AI agents have ended software engineering.

• Question: Are we being empowered or destroyed?
• Answer: It can’t be both.

2. “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 “all the benefits” as long as you add one more thing. It feels like a perpetual “you need one more thing” sales pitch—much like a pyramid scheme.

3. “Ensloppification” Is a Human Discipline Issue

Blink, you could actually cure ensloppification with AI if you just prompt it to produce clean code…

The Core Problem

AI is marketed as a way for anyone to build an app, and it’s being used by anyone, regardless of skill level.

• Human responsibility: The developer is ultimately responsible for code quality.
• Reality: Many developers don’t yet know that, and they’ll ship apps that look good, work, and may even generate revenue—yet are buggy, insecure, and dangerous.

Real‑World Example

A few weeks ago, someone “vibe‑coded” a platform that hit 1.5 M users in 4 days. Three days later, the entire production database was accessed and leaked (API keys, emails, private messages).

We already struggle to keep bad actors out in traditional software engineering. This vibe‑into‑production model is leaving the key in the doorknob.

Closing Thoughts

I’m excited about new tech—that’s a major reason I’m in the field. What I’m not excited about is irresponsible uses of new tech. Our planet already has enough problems without us destroying the software that runs it.

All I’m asking for is a little caution and thoughtfulness.

Is that too much?