Comment by pyman
6 days ago
Something interesting is happening. A false narrative is spreading online, pushed by people who know little about engineering, and others who should know better.
They claim junior devs are now 10x more productive, and project managers are shipping code themselves. Now, close your eyes for five seconds and try to picture what that code looks like. It's 100% legacy, disposable code.
The problem isn't AI, or PMs turning Figma into code, or junior devs prompting like mad. The real problem is the disconnect between expectations and outcomes. And that disconnect exists because people are mixing up terminology that took engineers years to define properly.
- A lean prototype is not the same as a disposable prototype
- An MVP is not the same as a lean prototype
- And a product is not the same as an MVP
A lean prototype is a starting point, a rough model used to test and refine an idea. If it works, it might evolve into an MVP. An MVP becomes a product once it proves the core assumptions and shows there's a real need in the market. And a disposable prototype is exactly that, something you throw away after initial use.
Vibing tools are great for building disposable prototypes, and LLM-assisted IDEs are better for creating actual products. Right now, only engineers are able to create lean prototypes using LLM prompts outside the IDE. Everyone else is just building simple (and working?) software on top of disposable code.
> And a product is not the same as an MVP
Tell that to almost every company I've worked for!
The whole "make it to the next financial quarter" attitude among directors and C-suite these days leads to the kind of crap where developers build an MVP and then are made to move on to the next thing. Like you said, it's not really about vibe coding at all. To a degree, they're right; the perception of feature richness leads to the bottom line irrespective of quality because few are truly comparing products, assuming it's feasible.
Hell, are developers (which we now call engineers apparently) even empowered to prototype things these days? I'm sure it happens, but it doesn't seem all that common. Maybe it happens in the gaming industry and actual tech (not "big tech"). Most coding outfits don't provide much affordance for that. It's just MVPs all the way down. At best, vibe coding just accelerates that process while quality suffers.
> that disconnect exists because people are mixing up terminology that took engineers years to define properly.
This is one of the larger trends I've observed in about 10 years of the software industry. A lot of these terms are really the crystallization of discussions at the water cooler, expositions in books or articles, or on technical fora like these, that span months if not years and thousands upon thousands of words. A veteran utters the word and immediately all the past conversations he's had regarding this topic come to mind.
Newer cohorts come in, and, not having been privy to those discussions, latch on to the jargon in a mimetic attempt to stochastically parrot the experts, but don't have the substance underlying the word - they only have the word itself. Now it gets thrown around as an ill-defined, ill-specified buzzword that means multiple different things to multiple people, none of whom can clarify what exactly the definition of that word is, what it means to them, because they were never part of the discourse, the oral or written tradition, in the first place, and don't understand the meaning of that word in context, its usage.
"Agile." "Technical debt." "DevOps." And now, "vibe coding." There was an article here on HN [0] [1] discussing semantic drift of the term "vibe coding" and how it now means something different from what was originally intended; I will merely point out that this is par for the course in software.
For other, more technical, examples of linguistic sloppiness: see JavaScript's conflation of objects, JSON, dictionaries, and hashmaps; to the computer scientist, you have the compositional primitive from object-oriented programming, the JavaScript Object Notation for serialization, the abstract data type, and the concrete data structure, respectively. To the JavaScript programmer, you just have "objects," and the fidelity of your linguistic and conceptual space has been reduced to a single pixel instead of something with more resolution and nuance.
[0] https://news.ycombinator.com/item?id=43739037
> Everyone else is just building simple (and working) software on top of disposable code.
I'd argue we should better define working. Take for example a generated UI, they all look the same and are subtly wrong or broken in many ways. At a first sight it might seem "working" only to fail at the first user test. Also generated UIs already feel like obsolete, meaning they religiously follow the trend at the training moment, they spectacularly fail coming up with something new
In the past I always talked about other devs in different mindsets. What we see is currently a developer fatigue of code that nobody understands anymore.
Usually that was when an engineer chimed in, and made the broken part into something more useful and more maintainable.
Then an architect looked at the codebase and tried to reduce its complexity.
Now, post LLM, it seems we have 100x the code written by devs, and engineers and architects are completely left out.
And that's what we are observing.
If you figure out how to test this, whether or not with e.g. a TDD MCP server or a DDD MCP server (or whatever workflow and architecture you prefer) you have a potential for a trillion dollar startup. We need to scale the efficiency of code reviews, because currently that is utterly broken as a concept and doesn't scale well enough.
In general, bad design patterns and team management are the primary drivers for sick projects.
"[O]rganizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations." (Melvin E. Conway)
Keep in mind Conway's law also works in reverse, try running a private project wiki with documentation, and a ticket/task queue with small tasks.
Setting pie-in-sky project goals is just as bad as ivory tower engineers. =3
Even thinking outside of product view point - speaking technically, I can't think of anything worse than junior dev's or PM's determining what they want technology-wise. At least once a week in my entire career I've had to shoot down awful ideas because they would be unnecessarily risky, won't possibly scale beyond minor use case, etc.
I would hazard a guess it's going to be extremely profitable being a consultant in the next few years.
> I would hazard a guess it's going to be extremely profitable being a consultant in the next few years.
I hope so. This is something I'm hoping to get into. As long as companies are trying to push their internal teams to use AI tools, I think it makes sense to position myself to follow along after them and clear the mess
same
I've worked on projects where each feature had its own unique part of the technology stack. To the point that multiple databases were used for one application.
I imagine 'vibe coded' applications to be similar to this but even worse.
Have you seen how enterprises write code for internal use?
It's no different to vibe coding, except if you ask an LLM to harden your code base to pass a pen test, it will do something.
Enterprises just don't give a sh!t.
In many cases some of the stuff at the big enterprises is shockingly, remarkably bad. I've seen multiple contracting firms leave things behind that wouldn't warrant a passing grade in an 'intro to programming' class.
Most of the time it's not "don't give a sh!t"--it's they genuinely don't know any better, no actual stakeholders even see the codebase nor are in any position to pass judgement, etc.
Most of the time folks that are "enterprise architects" or some such haven't written code in a decade and spend many hours a day on meetings.
I had a PM at my company (with an engineering background) post AI generated slop in a ticket this week. It was very frustrating.
We asked them: "Where is xyz code". It didn't exist, it was a hallucination. We asked them: "Did you validated abc use cases?" no they did not.
So we had a PM push a narrative to executives that this feature was simple, that he could do it with AI generated code: and it didn't solve 5% of the use cases that would need to be solved in order to ship this feature.
This is the state of things right now: all talk, little results, and other non-technical people being fed the same bullshit from multiple angles.
> I had a PM at my company (with an engineering background) post AI generated slop in a ticket this week. It was very frustrating.
This is likely because LLM's solve for document creation which "best" match the prompt, via statistical consensus based on their training data-set.
> We asked them: "Where is xyz code". It didn't exist, it was a hallucination. We asked them: "Did you validated abc use cases?" no they did not.
So many people mistake the certainty implicit in commercial LLM responses as correctness, largely due to how people typically interpret similar content made by actual people when the latter's position supports the former's. It's a confluence of Argument from authority[0] and Subjective validation[1].
0 - https://en.wikipedia.org/wiki/Argument_from_authority
1 - https://en.wikipedia.org/wiki/Subjective_validation
I’ve recently had a couple people try to help me fix code issues by handing me the results of their AI prompting. 100% slop; it made absolutely no sense in the context of the problem.
I figured the issue out the old-fashioned way, but it was a little annoying that I had to waste extra time deciphering the hallucinations, and then explaining why they were hallucinations.
> And a product is not the same as an MVP
Hahaha you're funny :-)
People are focusing on the artifacts because they can't point to the theory in the physical world, but it's the theory and its correspondence to the artifacts that they actually want.
One would argue that perfectly crafted code is at odds with first to market. Every company I have ever worked for has just run with their MVP, bolted on more and more, until they find they own the market - then they split into these things called microservices that make engineering easy to understand at a service level but a nightmare to orchestrate into the same business processes leading to the inevitable disruption by the next… MVP.