It's both. Lot of people vibe coding purely from financial motivations, lot of people vibe coding to rapidly prototype and explore ideas. The latter camp certainly will be the ones to carry the torch forward, now that the cat is out of the bag.
Carry what torch forward where? Vibe coders aren't going to learn more about the languages or techniques the LLM uses, or how to write that code themselves. They aren't going to exercise curiosity about anything beyond the LLMs API and prompts. They aren't going to pursue deep knowledge. By definition they only want to get a viable end product with the least amount of creative or cognitive effort on their part. That seems like the opposite of the "curious developer" archetype the article is talking about.
What the developer learns from the experience of AI programming is more down to the attitude of the individual than that.
Here's an example from my perspective.
Recently while developing a way to output a PAL video signal from two digital lines(an endeavour obviously driven by curoiosity more than utility). I learned a great deal about far more than I would have if I had not have used AI. I wasn't blind to what the AI was emitting, It helped me decide upon shifting one output to 0.285v and the other to .715v. Write a program to use pytorch to learn a a few resistors/capacitors to smooth out the signal and a sample of 2-bit data that when emitted though the filters produced a close sine wave for the color burst. AI enabled me to automatically emit Spice code to test the waveform. I had never used spice before, now I know the pains of creating a piecewise linear voltage source in it.
Yesterday I used an AI to make a JavaScript function that takes a Float32Array of voltage level samples and emits a list of timings for all parts of a scanline along with the min and max voltage levels, calculates the position and frequency of the color burst and uses the measured color burst to perform the quadrature decoding to produce a list of YUV values at a lower sample rate.
This should let me verify the simulated waveform so that I can compare the difference between what I intend to emit, and what should be a correct signal. If there turns out to be a discrepancy between what I am emitting and what I think I am emitting, this will come in quite handy.
Perhaps I might learn more if I did all of this myself unaided by an AI, but it would also take much longer, and likely not get done at all. The time I save writing tests, wrangling libraries and software is not stored in the bank. I used that time too, doing other things, learning about those as I did so.
Exactly, if you are interested in what you are doing, you will learn no matter what tool you use, be it AI or vim without syntax highlighting. A person that's trying to get rich quick, and sees software as a means to that end (and nothing more) will learn pretty much nothing vibe coding.
Luckily, vibe coders have yet to see ACTUAL success, just hyping up CLAIMS of success on social media.
They want to produce something without having the skills to produce it. Which, you know, probably isn't uncommon. I'd love to be able to rock out the guitar solo in Avenged Sevenfold's "Bat Country" [0] or "Afterlife" [1] or the first solo in Judas Priest's "Painkiller" [2], but to get to that skill level takes years of practice, which I'm quite frankly not willing to put in.
The difference is the honesty. A vibe coder produces something barely more than "Hello world" and brags about being able to produce software without learning to code. Nobody grabs a guitar, learns two chords, then claims to be a guitarist.
You get some of this for free if you create branches and squash merge them when finished. Without needing to think much about commit message, just a few words per commit is enough. This is good enough for me and I don't need to waste any time thinking about it.
Example commits of something I worked on a few days back:
$ git l feature/character-selection
c54825f 3 days ago Robert Schaap (feature/character-selection) Simplify color picker, fetch current color
d512569 3 days ago Robert Schaap Fix recolor for female, clean up files
6d05ce4 3 days ago Robert Schaap Add color picker to change shirt color
441180b 3 days ago Robert Schaap Show male in editor
17045dc 3 days ago Robert Schaap Remove old character
95772ff 3 days ago Robert Schaap Add characters
Then when I squash merged it I ended up with this commit message:
$ git show HEAD~1
commit be50e0d701d565cebdf4f29e0c9d8030a1a8faf7
Author: Robert Schaap
Date: Mon Mar 24 21:29:20 2025 +0100
Character selection (#14)
* Add characters
* Remove old character
* Show male in editor
* Add color picker to change shirt color
* Fix recolor for female, clean up files
* Simplify color picker, fetch current color
Granted, I'm not the target audience of your commit messages, but they tell me very little about what happens.
> Add characters
I can probably tell from the code that that's what's happening. But what requirements drove these particular characters?
> Remove old character
What makes it old? How would I recognise an old character in the future?
> Show male in editor
Why did male not show before? Was there a bug or a partially implemented feature?
> Fix recolor for female, clean up files
What does it mean to "fix recolor"? And even worse, what is "clean up files"? What requirements drove this file cleaning? Why were the files unclean in the first place?
etc. Commit messages in the style of "fix X" or "add Y" or "remove Z" or "nondescript action on W" are the bane of my existence. They seem so meaningful but they don't tell me anything when I'm trying to trace why a particular bug was introduced – or whether it's even a bug in the first place.
Yeah I think the most important thing to think about when writing a commit message is the intent; a LOT of people use it as a "work log", describing what they did like "removing a character" or "add color picker".
But a commit message needs to describe what the commit does, when applied. A good rule of thumb - also explained on the git site [0] - is to put it in a template like "When applied, this patch will <your commit message>".
The grandparent comment is almost there though, using the right tense of "fix" instead of "fixed", the latter being in the work log form of "I fixed such and such".
Yes! Please tell me _why_ the commit happened. The _what_ is in the diff, so almost no need to tell me in the commit message. Often I get commits with some LLM-generated slop in the commit message. It always looks good and always tells nothing. Commit messages like that are garbage.
"Whatever you now find weird, ugly, uncomfortable and nasty about a new medium will surely become its signature. CD distortion, the jitteriness of digital video, the crap sound of 8-bit - all of these will be cherished and emulated as soon as they can be avoided. It’s the sound of failure: so much modern art is the sound of things going out of control, of a medium pushing to its limits and breaking apart. The distorted guitar sound is the sound of something too loud for the medium supposed to carry it. The blues singer with the cracked voice is the sound of an emotional cry too powerful for the throat that releases it. The excitement of grainy film, of bleached-out black and white, is the excitement of witnessing events too momentous for the medium assigned to record them."
It also reminds me of that Arcade Fire song about how "we used to wait" for letters to arrive. The novelty isn't just in the thing, it's also in anticipation of the thing that you had to take out of the dust jacket and set up.
We like creating decentralised technologies to then graviate around centralised services built on top. The Internet was meant to be decentralised (it still is in terms of the protocols that make it work), but then we ended up consuming very much centralised services. Bitcoin's decentralised in terms of technology, but then we are centralising in terms of exchanges, wallets etc.
I guess the decentralisation aspects of a given technology just means it's a resilient building block. And since the only way we make sense of things nowadays is through markets, it's inevitable we starting building and consuming centralised services.
I'm not saying centralisation is good or bad btw, but I do share the irony in your reply, mostly because I find it funny when a new tech is being sold as new way of doing something in a decentralised way.
Decentralization mainly grants
flexibility/customization/freedom, but generally you don’t really care about this — freedom only really matters when you can’t do the thing you’re trying to do.
If everything is already covered without such freedom, or you don’t care about what’s not covered (or failed to conceive it), then you don’t really mind having the freedom or not. It doesn’t change much.
Gmail is a good email client — email being decentralized is only relevant to me if I wanted to get off gmail to go to say fastmail. But if I didn’t, what do I care whether the underlying protocol is centralized or not?
> freedom only really matters when you can’t do the thing you’re trying to do.
Disagree, or at least think there’s a need to clarify. This makes it look like a freedom is only occasionally relevant.
This kind of freedom derived from decentralization also exists as a persistent threat against bad behavior. If users can leave and bring their stuff with them, that constrains the choices that the platform can even consider.
Attempts to centralize should be seen as strategic attempts to change the landscape in a way that makes it easier to exploit users.
People don't care about whether their tools are decentralized or centralized (apart from a few principled individuals). They care about the UX of the tool, and so far centralised options have won on UX. I'm not sure how much of that is due to being centralised, rather than being due to companies investing in UX to gain market share preferring a centralised model.
Ofc centralised/decentralised is also part of the UX (what happens when the centralised service goes down), but so far it's not been a net win for decentralised.
I would expect more permissive licenses in the future. GPL was instrumental in changing the world to an open source mindset. It fixed the problems with software that became obvious in the 90s. The world has evolved and the restriction just feel outdated now.
