Vibe Code Warning – A personal casestudy

Similar with famous architects running large studios, mostly taking on a higher level conceptual role for any commissions they're involved in.

Traditionally in software (20+ years ago) architects typically wouldn't code much outside of POC work, they just worked with systems engineers and generated a ton of UML to be disseminated. So if we go back to that type of role, it somewhat fits in with agentic software dev.

I’ve never even able to make a mobile app before. My skillset was just a bit too far off and my background more in the backend.

Now I have a complete app thanks to AI. And I do feel a sense of accomplishment.

For some people building furniture from IKEA is an accomplishment. But a woodworker building an IKEA piece isn’t going to feel great about it.

It sounds like the person who made this repo didn’t need help but used the help anyway and had a bad time.

In some ways, I find that agent-assisted development opens doors to producing even higher quality code. Little OCD nitpicks, patterns that appear later in development, all the nice but not really necessary changes...these time-consuming refactors are now basically automated in 1-shot by an agent.

People who rush to ship the minimum were writing slop long before LLMs. At least now we have these new tools to refactor the slop faster and easier than ever.

Did mass processed food production stop people from cooking or enjoying human made food? No it did not. The same is true in almost all domains where a form of industrialization happens.

So much infrastructure is built by people having a less than good time.

An Engineer might get the jollies designing a bridge, but the workers who work on it dont.

The goal is to give lots of people happiness from not having to drive 100km out of their way.

If we solve a lot of problems for a lot of people and all it costs is the happiness of a few software engineers, well I am not convinced they were happy to begin with. Fund it.

Where do we draw the line where we have to delete our own grouchiness from the Internet for fear of letting others consume something we created in anger?

> If I am eating a delicious meal but the people preparing it had a miserable time, or it was prepared entirely by robots controlled by nefarious people using the profits to harm society, I don’t want it.

So every restaurant you go to, you head to the back to run a purity test on the political beliefs and “happiness” of the people making your food to make sure they line up exactly with what you believe?

This just screams luxury beliefs to me, and historically, Utopianism like this has been the actual dangerous slippery slope. Like…tens of millions of people starving dangerous.

I just don’t think this fully automated luxury communism thing you are fantasizing about will make you happy. Seeking pleasure 24/7 is pathological and means you stop feeling it, and doing things for the benefit of others instead of yourself is miserable…but ultimately more fulfilling.

Unfortunately I feel compelled to express the doomer take here, but I don't think most people care how their fast fashion or iPhones are made. And very few find it practically doable to boycott a company like Nestle. People trying to go full Stallman (sans the problematic stuff, rather along the lines of FSF) also find it just difficult.

Most people are just happy that the boot is on the other foot or someone else's back and that they have enough convenience and isolation from the rest of the world not to care. Or honestly it's hard to get by for them as well and all of those trinkets and unethically made products help them get through the day.

> Human society and civilization is for the benefit of humans, not for filling checkboxes above all else.

I really wish that was the case, instead of for the extraction of what little wealth we have by corpos and the oligarchs (call them whatever you want), to push us more towards a rat race of sorts where we get by just barely enough to keep consuming but not enough to effect meaningful change most of the time. Then again, could be better, could be worse - it's cool to see passionate people choosing to make something just for the sake of the experience and creating something unique, not always with a profit in mind.

In regards to software development in particular, I'm reminded of a few specific paragraphs in https://www.stilldrinking.org/programming-sucks

  Every programmer occasionally, when nobody’s home, turns off the lights, pours a glass of scotch, puts on some light German electronica, and opens up a file on their computer. It’s a different file for every programmer. Sometimes they wrote it, sometimes they found it and knew they had to save it. They read over the lines, and weep at their beauty, then the tears turn bitter as they remember the rest of the files and the inevitable collapse of all that is good and true in the world.
  
  This file is Good Code. It has sensible and consistent names for functions and variables. It’s concise. It doesn’t do anything obviously stupid. It has never had to live in the wild, or answer to a sales team. It does exactly one, mundane, specific thing, and it does it well. It was written by a single person, and never touched by another. It reads like poetry written by someone over thirty.
  
  Every programmer starts out writing some perfect little snowflake like this. Then they’re told on Friday they need to have six hundred snowflakes written by Tuesday, so they cheat a bit here and there and maybe copy a few snowflakes and try to stick them together or they have to ask a coworker to work on one who melts it and then all the programmers’ snowflakes get dumped together in some inscrutable shape and somebody leans a Picasso on it because nobody wants to see the cat urine soaking into all your broken snowflakes melting in the light of day. Next week, everybody shovels more snow on it to keep the Picasso from falling over.

What if the people, miserable or not, getting paid to make the meal have a fundamentally opposed world view to you and will use some amount of their wealth to try and enforce it on you in roundabout ways.

Because I assure you, some guy in a warehouse in Des Moines filling out some bullshit web form just so he can swipe his employee key card and start his forklift, doesn't want to enrich you, or me, or just about anyone else on HN. And his boss who felt compelled to buy the crap just to save a buck on insurance probably feels about the same.

Vegetarian I presume?

8h work, 1 or 2h commute, then a little bit of self care etc - there is not much time to work on "sideprojects", unfortunately: AI is a superbooster here, as it allows to much forward much quicker than before.

What if the real reason for recent softness in software engineer hiring, is that we have almost all the software we really need?

I feel like it's been a while since I even saw some software and thought "oh, I really need that!" Vs "here is something we will force you to download and install on your phone in order to do something that previously didn't require software". Like online menus in restaurants or event tickets or parking meter apps.

Superior disasters you mean.

You know the feeling of starting a new mmorpg video game? The first time you enter a new world, you dont know what to do, where to go, there is no "optimal" way to play it, there are no guides, you just try things and explore and play and have fun. Every new project I start I have this feeling.

Few years later the game is a chore, you have daily quests, guides and optimal strategies and simmulations and if you dont play what elitistjerks say you are doing it wrong.

With AI it feels the game is never new.

I used to create requirement-oriented prompts and I felt something similar to what you describe. However, I've switched to generating parts of my source code from my specs in a semi-automated way and it made the process much more pleasant (and efficient, I think).

I wrote a bit about my current state here: https://alejo.ch/3hi - for my Duende project I generate 8821 lines of code (2940 of implementation, 5881 of tests) from 1553 lines in specifications.

"Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith."

https://news.ycombinator.com/newsguidelines.html

There are also times where it isn't.

Developing the judgment for when it is and isn't faster, when it's likely to do a good job vs isn't likely, is pretty important. But also, how good of a job it does is often a skill issue, too. IMO the most important and overlooked skill is the having the foresight and the patience to give it the context it needs to do a good job.

If we're not telling the computer exactly what do then we're leaving the LLM to make (wrong) assumptions.

If we are telling the computer exactly what to do via natural language then it is as complicated as normal programming if not more complicated.

As least that's how I feel about it

One example is just laborious typing-heavy stuff. Like I recently needed a table converted to an enumeration. 5 years ago I'd have spent half a day to figure out a way to sed/awk/perl that transformation. Now I can entertain an AI for half an hour or so to either do the transformation (which is easy to verify) or to setup a transformation script.

Or I enjoy that I can give an LLM a problem and 2-3 solution approaches I'd see, and get back 4-5 examples on how that code would look like in those solution approaches, and some more. Again, this would take me 1-2 days and I might not see some of the more creative approaches. Those approaches might also be entire nonsense, mind you.

But generating large amounts of code just won't be a good, time-efficient idea long-term if you have to support and change it. A lot of our code base is rather simple python, but it carries a lot of reasoning and thought behind it. Writing that code is not a bottleneck at all.

Wow, they are really going for that human-like behavior aren’t they?

Agentic coding is like a drug or slot machine, it slowly draws you in with the implicit promise of getting much for little. The only ways it is useful to me now is for very focused tasks where I have spent a lot of time defining the architecture down to the last detail, and the agents are used to fill in the blanks, as it were.

I also think I could write a better agent, and as to why the bog corps have not done so is baffling to me. Just event getting the current agents to obey the guidelines in the agent .md files is a struggle. They forget pretty much everything two prompts down the line. Why can't the CLI systemically prompt them to check every time, etc.?

Something tell me the future is about domain-aware agents that help users to wring better performance out of the models, based on some domain-specific deterministic guardrails.

- tell it to ask you clarifying questions, repeatedly. it will uncover holes and faulty assumptions and focus the implementation once it gets going

- small features, plan them, implement them in stages, commit, PR, review, new session

- have conventions in place, coding style, best practices, what you want to see and don't want to see in a codebase. we have conventions for python code, for frontend code, for data engineering etc.

- make subagents work for you, to look at a problem from a different angle (and/or from within a different LLM altogether)

- be always critical and dig deeper if you have the feeling that something is off or doesn't make sense

- good documentation helps the machine as well as the human

And the list goes on.

It's a giant, non-deterministic, let's see what works good based on our vibes, mess of an approach right now. Even within the models, architecturally, there are recent results that indicate people are trying out weird things to see if they work, unclear if they are coming from first-principle intuition and hypothesis formation, or just throwing things at the wall to see what sticks

An unplanned problem becomes amplified by 10-100x worse than if you coded things slowly, by hand. That's when the AI starts driving you into Complexity Corner™ (LOL) to work around the lack of planning.

If all you're ever doing is using prompts like, `write a function to do...` or `write a class...` you're never going to run into the sorts of super fucking annoying problems that people using AI complain the most about.

It's soooooo tempting to just tell the AI to make complete implementations of things and say to yourself, "I'll clean that up later." You make so much progress so fast this way it's unreal! Then you hit Complexity Corner™ where the problem is beyond the (current) LLM's capabilities.

Coding with AI takes discipline! Not just knowledge and experience.

I do believe the problem is different:

I think I am pretty good at planning, but I have a tendency (in particular for private projects) to work on things where the correctness requirements are very high.

While I can describe very exactly what the code is supposed to do, even small errors can make the code useless. If the foundations are not right, it will be complicated to detect errors in the higher levels (to solve this issue, I implement lots of test cases).

Also, I often have a very specific architecture for my code in mind. If the AI tries to do things differently, the code can easily become much less useful. In other words: concerning this point, exactly because I plan things carefully (as you claimed), the AI becomes much less useful if it "does its own thing" instead of following my plan.

I eventually wrote the whole thing off as mostly one giant choose-your-own-adventure placebo effect. There is no end to the epicycles you can add to "perfect" your personal system.

There’s more you’ll get a feel for when you do all that. But it’s a place to start.

Planning is 80% of the battle. If you have a well-defined plan, that defines the architecture well, then your LLM is going to stick to that plan and architecture. Every time my LLM makes mistakes, it's because there were gaps in my plan, and my plan was wrong.

Use the LLM for planning. It can do research. It can brainstorm and then evaluate different architectural approaches. It can pick the best approach. And then it can distill this into a multi-phased plan. And it can do this all way faster than you.

Store plans in Markdown files. Store progress (task lists) in these same Markdown files. Ensure the LLM updates the task lists as you go with relevant information. You can @-mention these files when you run out of context and need to start a new chat.

When implementing a new feature, part of the plan/research should almost always be to first search the codebase for similar things and take note of the patterns used. If you skip this step, your LLM is likely to unnecessarily reinvent the wheel

Learn the plan yourself, especially if it's an ambitious one. I generally know what my LLM is going to do before it does it, because I read the plan. Reading the plan is tedious, I know, so I generally ask the LLM to summarize it for me. Depending on how long the plan is, I tell it to give me a 10-paragraph or 20-paragraph or 30-paragraph summary, with one sentence per paragraph, and blank lines in between paragraphs. This makes the summary very easy to skim. Then I reply with questions I have, or requests for it to make changes to the plan.

When the LLM finishes a project, ask it to walk you through the code, just like you asked it to walk you through the plan ahead of time. I like to say, "List each of the relevant code execution paths, then walk me through each one one step at a time." Or, "Walk me through all the changes you made. Use concentric circles of explanation, that go from broad to specific."

Put your repeated instructions into Markdown files. If you're prompting the LLM to do something repeatedly, e.g. asking the LLM to make a plan, to review its work, to make a git commit, etc., then put those instructions in prompt Markdown files and just @-mention it when you need it, instead of typing it out every time. You should have dozens of these over time. They're composable, too, as they can link to each other. When the LLM makes mistakes, go tweak your prompt files. They'll get better over time.

Organize your code by feature not by function. Instead of putting all your controllers in one folder, all your templates in another, etc., make your folders hold everything related to a particular feature.

When your codebase gets large enough, and you have more complex features that touch more parts of the code, have the LLM write doc files on them. Then @-mention those doc files whenever working on these features or related features. They'll help the LLM be more accurate at finding what it needs, etc.

I could go on.

If you're using these tools daily, you'll have a similar list before long.

I've built "large projects" with AI, which is 10k-30k lines of algorithmic code and 50k-100k+ lines of UI/Interface.

I've found a few things to be true (that aren't true for everyone).

1. The choice of model (strengths and weaknesses) and OS, dramatically affect how you must approach problems.

2. Being a skilled programmer/engineer yourself will allow you to slice things along areas of responsibility, domains, or other directions that make sense (for code size, context preservation, and being able to wrap your head around it).

3. For anything where you have a doubt, ask 3 or more models -- have them write their findings down in a file each -- and then have 3 models review the findings with respect to the code. More often than not, you march towards consensus and a good solution.

4. GPT-5-Codex via OpenAI Codex CLi on Linux/WSL was, for me, the most capable model for coding while Claude is the most capable for quick fixes and UI.

5. Tooling and ways to measure "success" are imperative. If you can't define the task in a way that success is easy to define -- neither a human nor AI would complete it satisfactorily. You'll find that most engineer tasks are laid out in very "hand-wavy" way -- particularly UI tasks. Either lay it out cleanly or expect to iterate.

6. AI does not understand the physical/visual world. It will fail hard on things which have an implied understanding. For instance, it will not automatically intuit the implication of 50 parallel threads trying to read from an SSD -- unless you guide it. Ditto for many other optimizations and usage patterns where code meets real-world. These will often be unique and interesting bugs or performance areas that a good engineer would know straight out.

7. It's useful to have non-agentic tools that can perform massive codebase analysis for tough problems. Even at 400k tokens context, a large codebase can quickly become unwieldy. I have built custom python tools (pretty easy) to do things like "get all files of a type recursively and generate a context document that will submit with my query". You then query GPT-5-high, Claude Opus, Gemini 2.5 Pro and cross-check.

8. Make judicious use of GIT. The pattern doesn't matter, just have one. My pattern is commit after every working agentic run (let's say feature). If it's a fail and taking more than a few turns to get working -- I scrap the whole thing and re-assess my query or how I might approach or break down the task.

9. It's up to you to guide the agent on the most thoughtful approaches -- this is the human aspect. If you're using Cloud Provider X and they provide cheap queues then it's on you to guide your agent to use queues for the solution rather than let's say a SQL db -- and it's on you to understand the tradeoffs. AI will perhaps help explain them but it will never truly understand your business case and requirements for reliability, redundancy, etc. Perhaps you can craft queries for this but this is an area where AI meets real world and those tend to fail.

One more thing I'd add is that you should make an attempt to fix bugs in your 'new' codebase on occasion. You'll get an understanding for how things work and also how maintainable it truly is. You'll also keep your own troubleshooting skills from atrophying.

I don't think there is much doubt AI can produce split out a lot of code, that mostly works. It's not too hard to imagine that one day an can AI produce so much code that it's considered a "large, complex project". A single mind dedicated to a task can do remarkable things, be it human or silicon. Another mind reading what they have done, and understanding it is another thing entirely.

All long term, large projects I'm familiar have been developed over a long time by many contributors, and as a consequence there has been far more reading and understanding going on than writing new code. This almost becomes self evident when you look at large open source projects, because the code quality is so high. Everything is split into modules a single mind can pick up relatively quickly and work on in isolation. Hell, even complier error messages become self explanatory essays over time.

Or to put it another way, no open source project is a ball of mud. Balls of mud can only be maintained by the person who wrote them, who get away with it because they have most of the details stored in their context window, courtesy of writing it. Balls of mud are common in proprietary code (I've worked on a few). They are produced by a single small group were paid to labour away for years at one task. And now if this post it to be believed, AI vibe coded projects are also a source of balls of mud. Given current AI's are notoriously bad at modifying even well structured projects, they won't be maintainable by anyone.

When me move from just making use of something to using something to make with, that is when we should have a deeper understanding I think.

Does that sound right?

> the important distinction here is that I wouldn't call myself an electrician if my relationship to the subject matter doesn't extend beyond the desire to flip a switch.

Yeah, that seems right to me!

How so? We actually don't have any specific characteristics on what makes code "good", nor do we have any quantifiable metrics that say "said good code is better"?

I may think your chair is more comfortable or that it lasts longer under load, but that doesn't always mean is "better". A cheaper chair could be considered better because its cheaper to acquire, even if its not as comfortable or doesn't last as long.

Some 3D printing enthusiast: "Hold my beer ..." :-)

What is a programming language in the first place if not a programer satiating their own need for a better tool?

I don't use it as inspiration. It's like I said: code that is not reviewed yet.

It takes the idea of 50 juniors working for you one step ahead. I manage the workflow in a way that they already made the code they wrote merge and build before I review it. When it doesn't, I delete it from the stash.

I could keep a branch for this. Or go even deeper on the temptation and keep multiple branches. But that's more of my throughput I have to spent on merging and ensuring things build after merging. It's only me. One branch, plus an extra "WIP". Stash is perfect for that.

Also, it's one level of stashing. It's stacked in the sense that it keeps growing, but it's not several `git stash pop`s that I do.

One thing that helps is that I already used this to keep stuff like automation for repos that I maintain. Stuff the owner doesn't want or isn't good enough to be reused. Sometimes it was hundreds of lines, now it's thousands.