The thing about "vibe coding" is that is begins from a foundation that is "coding".
A decade, two decades ago, there was already an ominous tendency among new people learning how to touch computers.
They wanted to learn how to make things that already existed. How to reproduce ideas that they already saw in the world.
And their instruction pandered to this desire. Tutorials on how to do this or that bog standard thing. "Code camps" and "bootcamps" that worked through regimented drills of cookie cutter concepts.
This was not programming as "planning a dinner party", to cite Hopper, navigating all the bespoke challenges of a unique circumstance. It was "coding" as assembling a licensed-IP Lego kit, the only object being to get the thing pictured on the box. It wasn't trying to solve interesting new problems, but rather trying to master the rote use of tools that were solutions to problems now forgotten.
1/2
A field that once was shaped by wood-workers and sculptors, each following their own muse for the art and the craft of it, became a hansa or fraternity for journeyman carpenters and apprentice brick-layers.
So, of course, when the Patented Brick-layer 4000 came along, promising to shape, and dry, and fire the bricks from raw materials even as it mortared them into place, no one questioned that all the snazzy thingamabob would do, all that it could ever do, was reproduce what came before.
Reproducing what came before is what is wanted, after all.
Sure, it doesn't reproduce what came before very well, but it's improving! It's getting better at never making anything new! Our job now is to learn how to describe only the things we already know, with such fidelity, that it can't help but do the same thing again!
It is the fulfillment of the generational shift from "What can I do with this?" to "How do I do that?"
2/2
I’ll give you a little bit of pushback on this: the process of learning a craft and developing artistry really does require a period of working through known challenges and problems, this is how the artist develops the toolkit of their craft.
I teach young musicians, and while the goal is interesting and unique artistry, first they need to learn to speak the language and develop the reflexes that make the instrument do what they intend, and that involves travelling well-worn paths.
Now, you are right that if *all* they do is mindlessly recreate by rote, they will never progress into true craftsmanship, so exploration and play need to part of the journey from the start, but the other side of the token is that *only* play is not an efficient route to mastery. Maintaining the balance is the core challenge in the art of teaching.
@DavidM_yeg @beadsland I'll give both of you some pushback. ;-) Software development has never been "art" or "craft"; it's science. The former terms are for hobbyists, and such attitudes have kept measurement definition/development underutilized. This has led to over 8000 programming languages, without empirical evidence of efficacy, and lessor numbers of processes to the same effect.
Ooof… sorry, I don’t buy that. The prejudice that craft is somehow not rigorous or is just for hobbyists is not well-founded. Craft is the intersection of science and human, honed through relentless experimentation and analysis. The luthier, or carpenter, or architect who disregards science fails, yet their pursuit is not purely science or knowledge, but its application to human need and aspiration. Programming is not just machines, code, algorithm, but information science applied to human need and aspiration. Complaining that there are over 8,000 programming languages sounds suspiciously like complaining that there are over 7,000 spoken languages in the world and suggesting that the world would be better without that diversity.
Developing Mitchell's point further, Dijkstra's dream was always aspirational folly.
Your own argument undermines your thesis (if your playful winking emoji hadn't preemptively subverted it already). It never was a science, for had it been, there would have been more efficacious utilization of measurement all along. Hobbyists couldn't have prevented that.
(To push back on David a smidgen, craft may be founded at the intersection of science and human(ities) [science is no less human than other forms of inquiry], but craft is not science, per se. Not all experimentation and analysis is scientific method, nor ought it be. An individual craftsperson, if so inclined, may contribute to the ongoing project of science, but this is incidental to craft itself.)
1/2
@beadsland @DavidM_yeg I would say that Capers Jones work has been evidence of efficacious measaurement.
CTO of Namcook Analytics? He's doing project management consulting and (labor) cost estimation. Worthwhile, but operating at a wholly different scope than programming.
To wit, he's measuring productivity of programmers, not "efficaciousness" of programs. How to cost effectively deliver project deliverables, not how useful those deliverables might be. The intended effect being the completion of projects in alignment with business objectives, not the use-value of fulfilling any such objectives.
It's time and motion studies for knowledge workers.
@beadsland @DavidM_yeg Have you read his books, or are you just making half-baked assumptions based on a perusal of his profile? (Sounds like the latter.)
The same year. "It does so by providing current data on average software schedules, effort, costs, and quality for several industries and countries....It shows quality results using defect potential and DRE metrics because the number one cost driver for software is finding and fixing bugs." Labor.
Also that year. "This comprehensive reference uses a formal and standard evaluation technique to show the strengths and weakness of more than 60 software development methodologies such as agile, DevOps, RUP, Waterfall, TSP, XP and many more." Project management.
2021. This is the first title that suggests it's about programs, drawing on a term popularized in the 90s. Of course, that term, itself, is more often about project management than actual program design choices. "The first section of the book examines common software development problems that have been observed in many companies and government agencies." Project management. "The second section shows patterns that lead to software success. The data comes from actual companies....a major telecom company whose CEO was troubled by repeated software failures...methods of achieving excellence, as well as measures that can prove excellence to C-level executives". Project management.
2/3
Have myself read books that clearly aren't directed to me, as someone interested in how programs, not software, are used to address problems? No. The book covers tell me they aren't for me.
My concern is whether the problem myself am interested in seeing addressed IS addressed, by the tools at hand, effectively (how well a task is accomplished), which is to say goal-oriented programming, not efficaciously (whether it accomplishes the task at all), which is to say process-oriented project management, and certainly not with how productively labor is utilized by companies in the management of projects to accomplish a task at all, however ineffectively.
You can throw around ten-dollar words without understanding their nuance all you like, this does not change the fact that measuring labor is not measuring anything about a program except as a proxy for labor.
You can throw around ten-dollar words without understanding their nuance all you like, this does not change the fact that measuring labor is not measuring anything about a program except as a proxy for labor.
The thing about efficacious product design is that is shifts labor somewhere else, externalizing it. An efficaciously developed software product reduces the cost of the company *making* that product for sale, but insofar as the produce is less than effective, it demands more labor of those who use the product, just to accomplish the effects the end-user (or the end-user's own company) seek to achieve.
This, of course, and to bring this whole discussion back to where it started, being the story, at multiple levels, of vibe coding.
4/4
Which is all to say, don't try to tell a psych / comp sci double major who got into the weeds of industrial organizational psych as an undergrad, about measurement.
Measurement begins and ends with the construct you're seeking to measure. That's the ballgame. If your construct is measuring how efficacious your product development process is, that's what you're measuring. It does what it says on the tin. No amount of insisting it does other than what it explicitly says it does changes that.
And it is that very measurement regime that gives us vibe coding. Vibe coders, per my OP, had already prepared the ground for this, by they and their predecessors fulfilling their desire to learn tools (process) rather than learn craft (goals).
It is that fertile soil, more amenable to efficacy than effectiveness, that makes it so easy for folk not even in "software" spaces (e.g., F/OSS) to be tempted by Claude, et al.
The irony of all this is that efficacy is baked into the DNA of programming. Presented with a problem, we try to find a solution, given knowledge, skills and resources available, to solve that problem. This is hacking.
It needn't be a pretty solution. It needn't do the job particularly well. It only needs to work. This is the genesis of every new program. Here, however, the only metric of cost-effectiveness is a boolean. Does it do the thing? True or False? However much labor or cost went into it is justified if the answer is True.
What happens next is a function of use. The more our new program, our new tool, is used, the more widely it is deployed across a problem domain, the more pain points become apparent in that productive use (in "production" as the parlance has it). Eventually, if used enough and widely enough, the cost of use of the tool comes to overshadow the cost of production of the tool, per se.
1/3
The inclination of the programmer, here, is, insofar as they are able, to invest more labor or resources into the tool as product, so to refine and specialize that tool, to improve its effectiveness for the tasks to which it is suited. The hacker becomes a developer, crafting what started as a hack into something more robust.
This is how we get many hundreds of different programming languages, each refined and specialized for its own problem domain. Just as we get new specialized tools in any other craft, as new problem domains emerge for those committed to that craft.
In rare instances, a program or a component thereof may reach a point of being sufficiently feature complete, or absent that, mission critical, that just as attention turned from efficacy to effectiveness, it may now turn from effectiveness to efficiency.
Not efficiency of the labor going into the product, to be clear, but the efficiency of the program with respect to one or more specific physical constraints: processor resources, memory, energy use, storage demands, signal density, noise and latency, responsiveness, even fault tolerance.
2/3
This is where science comes into the fore, as once again, more, not less, labor and resources are committed to working to optimize at the edges of such physical constraints. Insofar as getting this optimization wrong can result in unintentional* material harm or loss, even especially harm to or loss of human or other life, this intensification of labor might even be deemed engineering.
*We must always remember that by etymology, "engineer" originates as the construction of war engines.
By this analysis, vibe coding rests on the laurels of the accomplishments of others, at a pseudo-hacking stage, concerned with efficacy only, damn the cost. Only here, that cost is borne by others, as the vibe coder's commitment of their own labor to the task is insignificant by comparison to the labor and other resources colonized by the tools they use.
Already, the results have been repeatably demonstrated to be counter to effectiveness, with tools becoming less suited to purpose, not moreso, even as the whole is undeniably running full-tilt in the opposite direction from anything resembling the physical constraints of concern to efficiency.
3/3
@beadsland @DavidM_yeg I can't argue with ignorance.
@lwriemen
Back matter tells the tale.
1986 "how leading corporations medium and large have increased their programming productivity rates and how these rates can be duplicated". This is about labor.
1993 "Considers in depth the software-related risks in the domains of methodologies, tools, organization structures, skills and specialization, client relations, and sociological issues". Project management.
2000 "The methodology presented in this book gives developers and managers a powerful new way to project and evaluate the productivity and quality improvements associated with changes in software processes." Labor and project management.
Jumping ahead:
2017 "One of the most common leaks is that of unpaid overtime....This means that software effort is underreported by around 15%, which is too large a value to ignore. Other sources of leaks include the work of part-time specialists who come and go as needed." Labor.
The same year. "It does so by providing current data on average software schedules, effort, costs, and quality for several industries and countries....It shows quality results using defect potential and DRE metrics because the number one cost driver for software is finding and fixing bugs." Labor.
Also that year. "This comprehensive reference uses a formal and standard evaluation technique to show the strengths and weakness of more than 60 software development methodologies such as agile, DevOps, RUP, Waterfall, TSP, XP and many more." Project management.
2021. This is the first title that suggests it's about programs, drawing on a term popularized in the 90s. Of course, that term, itself, is more often about project management than actual program architecture. "The first section of the book examines common software development problems that have been observed in many companies and government agencies." Project management. "The second section shows patterns that lead to software success. The data comes from actual companies....a major telecom company whose CEO was troubled by repeated software failures...methods of achieving excellence, as well as measures that can prove excellence to C-level executives". Project management.
Have myself read books that clearly aren't directed to me, as someone interested in how programs are used to address problems? No. The book covers tell me they aren't for me.
My concern is whether the problem myself am interested in seeing addressed IS addressed effectively (how well a task is accomplished), which is to say goal-oriented programming, not efficaciously (whether it accomplishes the task at all), which is to say process-oriented project management, by the tools at hand, and certainly not with how productively labor is utilized by companies in the management of projects to accomplish a task at all, however ineffectively.
@DavidM_yeg