Starting Over

This one's more of a journal entry folks.

I had to kill Frankenstein last night.

Saying I had to kill Frankenstein is like my younger in cheek way of saying that I had to start my project over. It feels bad, but there’s no better alternative to a few too many missed assumptions, complicated merges, and short-sighted architectural designs. For example, I learned that it’s better to start off a project by building out all of the core components together - authentication, storage, DB included - rather than taking them on piece by piece. It begs me to wonder how this is determined in the old school, no AI assisted coding world. Where do you start?

It’s also important to start over because every time I start over I go into it with fresh insights, a more complete mental model of yes, how the app will function in the background but just as important, how the app will look and feel. The better you understand how it should be presented to the user, and what actions they’ll take first, vs throughout core workflows, the more accurate that coding agents will be when bringing your vision to life. Sure, this much seems obvious. But unless you’ve tried to build a Frankenstein yourself (with or without coding agents), your reaction is probably blinded by arrogance.

And IS there one path, one route that’s the most efficient in building an application with coding agents from scratch? I’ve skimmed hundreds of blog posts claiming so, with instructions on how, and yet they all diverge. Moreover, the toolset, frameworks, and development infrastructure are all different too. It’s a symptom of the variance in the applications being built as well.

I picture each attempt at the same project as taking a new path in a CYOA game, albeit with extra insight into the decisions I shouldn’t make again. This is different than going into a new attempt with more insight I suppose, because 80% of the time I just know what WONT work rather than what definitely WILL. For example, my auth provider was added on after a lot of core feature attempts were built out, and it didn’t end up playing very well with my chrome extension client / server routes. That’s the hypothesis, anyway. There were also performance issues due to bloat created by feature tack ons. And, I had a hunch that my original storage approach was wrong for the types of data and workloads it was handling / would eventually need to handle. After all, in order to tune a storage engine to perform well on your kind of workload, you need to have a rough idea of what the storage engine is doing under the hood. So after my lash attempt to refactor the codebase failed - as I falsely assumed that performance was tanking due to a lack of abstraction - the best.

Reading and listening to Developing Data Driven Applications while I’m “vibe coding”^ unlocks a whole new dimension of perspective for me (found a free pdf here!!) . I don’t read it as a manual, but a sort of learning-reinforcement mechanism. It helps me zoom out, identify where my own design choices stack up against the bigger universe of choices, and make meaning of the guidance embedded in the text as I go. It's critical to effective skill-navigation.

Even as early as chapter 1, the author reviews core principles of software development. If these principles were placed on one side of a venn diagram, and the priorities of non technical vibe coders, then we’d observe zero overlap.

Enter my rant: Finding vibe-coded AI slop apps created by Gemini Antigravity is infuriating. The deviation (or lack of acknowledgement whatsoever) of classic software development principles isn’t me just being elitist. I myself on the low end of technical relative to the normalized deviation of people who actually engineer software, but the apps I’ve seen don’t even cut the category of software engineering. It’s slop, but unfortunately slop implies that it’s “The AI’s Fault” not the fault of the operator.

I need to dedicate another post to my woes about the state of vibe-coders vs power users vs dissenting software engineers since this post is veering too far if its tracks. I am no authority at this point on how to “vibecoders” a lasting application successfully. But I will dedicate more time to sharing what I AM seeing.

Back to mourning Frankenstein- I try to reframe it to myself as “starting over” rather than “beginning again”. It’s understanding the game board a little better. It’s getting to a certain stage of a side scrolling super Mario bros game and realizing which order of operations, and quick decisions, are leading to your inability to reach the checkpoint. Turning Restrictions into a Roadmap, as ChatGPT would probably describe it [cringe].

But it's okay - I'm researching. I mentally frame it as me operating as a research lab - allocating time and capital to systematic trial and error, advancing one experiment at a time, week by week. The near-term costs are intentional: research almost always consumes resources long before it produces returns, precisely because it requires a level of patience, conviction, and sustained investment that few are willing or able to provide at the outset.

:)