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.)
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.
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.
