The friction itself does not add value. The time spent thinking on the problem does. Friction should be minimized beyond the absolute bare minimum. Programming is a discipline where your workstation is already streamlined, and it is easy to forget where the friction is. Programming is done in a world of pure though, in a sense, so most of the friction already lives in your head, and it is difficult to distinguish effort wasted fighting friction from effort making real progress.
Consider the Wright brothers. They worked iteratively. When they wanted to design an airplane they moved from Ohio to a windy place with lots of loose sand (NC outer banks). Why? So that they could do test runs with good wind conditions (for an airplane that is barely able to fly this matters a lot) and crash with the least amount of damage. They rebuilt the airplane dozens and dozens of times and had a workshop tuned to their needs on location. They reduced friction wherever they could so that they got the most work done that they could with the least amount of distraction.
It seems that way, but that's not actually true. A fully greased-up brain would produce just incoherent nonsense decoupled from reality, because it would lack all constraints that would allow it to judge the value of an idea (i.e. how possible and useful it would be to implement in the real world). The friction comes from fitting your ideas into the real world.
>They reduced friction wherever they could so that they got the most work done that they could with the least amount of distraction.
They reduced unnecessary friction. They could have eliminated all friction by imagining a teleporter machine that can send you anywhere instantly and that runs on the hopes of children. But they still wanted the friction of unsuccessful attempts so they could actually build a plane that worked.
I would say that, within the Wright Brothers example, working with a battered, worn-out screwdriver is an example of friction (or, perhaps having to use a bit and brace instead of a power drill), but the act of building a new unsuccessful airplane iteration is not friction. Every build is asking physics for feedback on the design; every airplane build is just the same as running your code through the compiler. I wish I had a good word to distinguish this from friction. The closest thing I can imagine is how waste is defined in Lean Manufacturing, but keeping in mind that what you are manufacturing is Ideas and Software.
Concretely, If your only goal is to produce "software" then learning about design, planning, project management, testing etc is all unnecessary friction when you can just ask an LLM to "make it so"
You'll get the exact same muscle loss with a CICO calculation weight loss.
Exactly. I don't have to write binary machine code directly, every zero and one artisanally crafted by hand, to have thought deeply for years about a how to solve a problem.
In fact, choosing the right level of abstraction is essential to my ability to solve the problem.
For most problems, the friction of writing binary code by hand is the wrong level.
And we're discovering that many important problems can be solved faster and with greater quality than can be achieved by dogmatically hand-writing every line of source code just for the friction.
But overall yes, time spent thinking is the thing that matters.
It's less "there should be more friction" and more "LLMs remove too much". Instant gratification is great if you're a consumer, awful if you're a creator.
In game design friction very important; remove all friction and you don't even have a game any more, you might as well show the You Win screen. My favourite metaphor for it is sex: there is no sex without friction.
What LLM have done is massively reduce the friction of intellectual effort, completely devaluing most expressions of it.
Both needs heat.
This is all friction that is intended to make car-driving work at scale.
There really, truly, absolutely, 100% is no accounting for taste...
Worst of all I've seen good engineers lean in and begin thinking uncritically and magically.
Let's first settle on the definition of vibecoding so that we're not miscommunicating over definitions. I'm using the one that seems the median definition nowadays: >95% of the code written by LLMs, <60% of the output code human-reviewed, meaning there's a large part of the codebase that no human ever reviews.
As you said it's about time invested in thinking about it, yes. But remember that even pre-AI >90% of software got never used, it was dead on arrival. Look up "success rate of software projects in business".
You can put lots of time into thinking and vibecode everything. You can put very little time into thinking and write by hand. Of course, vibecoding makes the former much more likely. But nothing about it is inherent to it.
I sometimes think of something Kant wrote, about how friction (hardship, etc.) elevates us.
In Kant's own words:
"Without those in themselves unamiable characteristics of unsociability from whence opposition springs-characteristics each man must find in his own selfish pretensions-all talents would remain hidden, unborn in an Arcadian shepherd’s life, with all its concord, contentment, and mutual affection. Men, good-natured as the sheep they herd, would hardly reach a higher worth than their beasts; they would not fill the empty place in creation by achieving their end, which is rational nature. Thanks be to Nature, then, for the incompatibility, for heartless competitive vanity, for the insatiable desire to possess and to rule! Without them, all the excellent natural capacities of humanity would forever sleep, undeveloped. Man wishes concord; but Nature knows better what is good for the race; she wills discord. He wishes to live comfortably and pleasantly; Nature wills that he should be plunged from sloth and passive contentment into labor and trouble, in order that he may find means of extricating himself from them. The natural urges to this, the sources of unsociableness and mutual opposition from which so many evils arise, drive men to new exertions of their forces and thus to the manifold development of their capacities. They thereby perhaps show the ordering of a wise Creator and not the hand of an evil spirit, who bungled in his great work or spoiled it out of envy."
See the section titled "FOURTH THESIS" at the following link if interested.
https://en.wikisource.org/wiki/Idea_for_a_Universal_History_...
http://www.catb.org/~esr/writings/taoup/html/end-user.html
"""Master Foo turned to the end-user. “Tell me”, he inquired, “why do you seek the Way?”
“I am discontent with the software I see around me”, the end user replied. “It neither performs reliably nor pleases the eye and hand. Having heard that the Unix way, though difficult, is superior, I seek to cast aside all snares and delusions”."""
Thinking of software from finance and derivatives pov really blew my mind. here’s the article, it has AI smell but it’s short and the mental model is good: https://newsletter.kentbeck.com/p/the-cost-yagni-was-never-a...
it’s a breakthrough for me because i too like to build so it’s hard to not build. With options, i don’t get to build blindly but there’s still satisfaction in holding the option. collect the options, system design them, build on that layer.
1. Same services provided using similar software stack, but maintained by fewer developers. I suspect this may hold for some sectors in the economy. Or
2. The Jevons case: similar # of developers maintaining a much bigger software stack that provides more services.
I might add:
2a: Similar but with lots of accidental complexity everywhere.
Probably we're heading towards some mix of the above? Depending on which application area you're talking about. Web dev is a lost cause, deeply-embedded won't see a big shake-up.
"If one teenager works hard and saves for a few years to buy themselves a car and another has theirs bought for them on a whim, who would appreciate their car more?"
Odds are it's the former, not always. But mostly.