A microwave isn’t going to take your job; a chef who knows how to use a microwave is going to take your job.
When you vibe code, you are incurring tech debt as fast as the LLM can spit it out. Which is why vibe coding is perfect for prototypes and throwaway projects: It’s only legacy code if you have to maintain it!
The worst possible situation is to have a non-programmer vibe code a large project that they intend to maintain. This would be the equivalent of giving a credit card to a child without first explaining the concept of debt.
If you don’t understand the code, your only recourse is to ask AI to fix it for you, which is like paying off credit card debt with another credit card.
The short version of what I want to say is: vibe coding seems to live very squarely in the land of prototypes and toys. Promoting software that’s been built entirely using this method would be akin to sending a hacked weekend prototype to production and expecting it to be stable.
Remy is taking a very sensible approach here:
I’ve used it myself to solve really bespoke problems where the user count is one.
Would I put this out to production: absolutely not.
Here’s what the “AI will replace developers” crowd fundamentally misunderstands: code is not an asset—it’s a liability. Every line must be maintained, debugged, secured, and eventually replaced. The real asset is the business capability that code enables.
If AI makes writing code faster and cheaper, it’s really making it easier to create liability. When you can generate liability at unprecedented speed, the ability to manage and minimize that liability strategically becomes exponentially more valuable.
This is particularly true because AI excels at local optimization but fails at global design. It can optimize individual functions but can’t determine whether a service should exist in the first place, or how it should interact with the broader system. When implementation speed increases dramatically, architectural mistakes get baked in before you realize they’re mistakes.
I really like the thinking behind this project:
We believe computers should work for people, and dream of a future where computing, like cooking or word processing, is available to everyone. Where you can solve your own small, unique problems with small, unique apps. Where you don’t just rely on mass-market apps made by expert programmers. Where you share home-made little apps with family and friends.
Scrappy is our contribution to this dream.
Frankly, I’d rather quit my career than live in the future they’re selling. It’s the sheer dystopian drabness of it. Mediocrity as a service.
I tried the tab-completion slot machines; not my cup of tea. I tried image generation and was overcome with literal depression. I don’t want a future as a “prompt artist”.
I’m mostly linking this for what it says, but oh boy, do I love the way it says it with this wonderful HTML web compenent.
I don’t use large language models. My objection to using them is ethical. I know how the sausage is made.
I wanted to clarify that. I’m not rejecting large language models because they’re useless. They can absolutely be useful. I just don’t think the usefulness outweighs the ethical issues in how they’re trained.
Molly White came to the same conclusion:
The benefits, though extant, seem to pale in comparison to the costs.
What I do know is that I find LLMs useful on occasion, but every time I use one I die a little inside.
I genuinely look forward to being able to use a large language model with a clear conscience. Such a model would need to be trained ethically. When we get a free-range organic large language model I’ll be the first in line to use it. Until then, I’ll abstain. Remember:
You don’t get companies to change their behaviour by rewarding them for it. If you really want better behaviour from the purveyors of generative tools, you should be boycotting the current offerings.
Still, in anticipation of an ethical large language model someday becoming reality, I think it’s good for me to have an understanding of which tasks these tools are good at.
Prototyping seems like a good use case. My general attitude to prototyping is the exact opposite to my attitude to production code; use absolutely any tool you want and prioritise speed over quality.
When it comes to coding in general, I think Laurie is really onto something when he says:
Is what you’re doing taking a large amount of text and asking the LLM to convert it into a smaller amount of text? Then it’s probably going to be great at it. If you’re asking it to convert into a roughly equal amount of text it will be so-so. If you’re asking it to create more text than you gave it, forget about it.
In other words, despite what the hype says, these tools are far better at transforming than they are at generating.
Iris Meredith goes deeper into this distinction between transformative and compositional work:
Compositionality relies (among other things) on two core values or functions: choice and precision, both of which are antithetical to LLM functioning.
My own take on this is that transformative work is often the drudge work—take this data dump and convert it to some other format; take this mock-up and make a disposable prototype. I want my tools to help me with that.
But compositional work that relies on judgement, taste, and choice? Not only would I not use a large language model for that, it’s exactly the kind of work that I don’t want to automate away.
Transformative work is done with broad brushstrokes. Compositional work is done with a scalpel.
Large language models are big messy brushes, not scalpels.
I have little understanding for people using large language models to generate slop; words and images that nobody asked for.
I have more understanding for people using large language models to generate code. Code isn’t the thing in the same way that words or images are; code is the thing that gets you to the thing.
And if a large language model hallucinates some code, you’ll find out soon enough:
With code you get a powerful form of fact checking for free. Run the code, see if it works.
But I want to push back on one justification I see repeatedly about using large language models to write code. Here’s Craig:
There are many moral and ethical issues with using LLMs, but building software feels like one of the few truly ethically “clean”(er) uses (trained on open source code, etc.)
That’s not how this works. Yes, the large language models are trained on lots of code (most of it open source), but they’re not only trained on that. That’s on top of everything else; all the stolen books, all the unpaid creative work of others.
Even Robin Sloan, who first says:
I think the case of code is especially clear, and, for me, basically settled.
…goes on to acknowledge:
But, again, it’s important to say: the code only works because of Everything. Take that data away, train a model using GitHub alone, and you’ll get a far less useful tool.
When large language models are trained on domain-specific data, it’s always in addition to the mahoosive amount of content they’ve already stolen. It’s that mohoosive amount of content—not the domain-specific data—that enables them to parse your instructions.
(Note that I’m being very delibarate in saying “parse”, not “understand.” Though make no mistake, I’m astonished at how good these tools are at parsing instructions. I say that as someone who tried to write natural language parsers for text-only adventure games back in the 1980s.)
So, sure, go ahead and use large language models to write code. But don’t fool yourself into thinking that it’s somehow ethical.
What I said here applies to code too:
If you’re going to use generative tools powered by large language models, don’t pretend you don’t know how your sausage is made.
Instead of that deep immersion where I’d craft each function, I’m now more like a curator? I describe what I want, evaluate what the AI gives me, tweak the prompts, and iterate. It’s efficient, yes. Revolutionary, even. But something essential feels missing — that state of flow where time vanishes and you’re completely absorbed in creation. If this becomes the dominant workflow across teams, do we risk an industry full of highly productive yet strangely detached developers?
Here’s the main problem I’ve found with generative AI, and with “vibe coding” in general: it completely sucks out the joy of software development for me.
I hate the way they’ve taken over the software industry, I hate how they make me feel while I’m using them, and I hate the human-intelligence-insulting postulation that a glorified Excel spreadsheet can do what I can but better.
We’re at a point in the most ecosystems where pulling in libraries is not just the default action, it’s seen positively: “Look how modular and composable my code is!” Actually, it might just be a symptom of never wanting to type out more than a few lines.
It always amazes me when people don’t view dependencies as liabilities. To me it feels like the coding equivalent of going to a loan shark. You are asking for technical debt.
There are entire companies who are making a living of supplying you with the tools needed to deal with your dependency mess. In the name of security, we’re pushed to having dependencies and keeping them up to date, despite most of those dependencies being the primary source of security problems.
But there is a simpler path. You write code yourself. Sure, it’s more work up front, but once it’s written, it’s done.
The moment you run LLM generated code, any hallucinated methods will be instantly obvious: you’ll get an error. You can fix that yourself or you can feed the error back into the LLM and watch it correct itself.
Compare this to hallucinations in regular prose, where you need a critical eye, strong intuitions and well developed fact checking skills to avoid sharing information that’s incorrect and directly harmful to your reputation.
With code you get a powerful form of fact checking for free. Run the code, see if it works.
Working on this project is great but ten minutes into it and I already miss the resilience of the web. I miss how you have to really fuck things up to make a browser yell at you or implode.
Want to use all those great features that have been in landing in browsers over the past year or two? View transitions! Scroll-driven animations! So much more!
Well, your coding co-pilot is not going to going to be of any help.
Large language models, especially those on the scale of many of the most accessible, popular hosted options, take humongous datasets and long periods to train. By the time everything has been scraped and a dataset has been built, the set is on some level already obsolete. Then, before a model can reach the hands of consumers, time must be taken to train and evaluate it, and then even more to finally deploy it.
Once it has finally released, it usually remains stagnant in terms of having its knowledge updated. This creates an AI knowledge gap. A period between the present and AI’s training cutoff. This gap creates a time between when a new technology emerges and when AI systems can effectively support user needs regarding its adoption, meaning that models will not be able to service users requesting assistance with new technologies, thus disincentivising their use.
So we get this instead:
I’ve anecdotally noticed that many AI tools have a ‘preference’ for React and Tailwind when asked to tackle a web-based task, or even to create any app involving an interface at all.
Detective stories and tales of bughunting in software and hardware.
Sometimes bugs have symptoms beyond belief. This is a collection of such stories from around the web.
Many interactions are not possible without JavaScript, but that doesn’t mean we should look to write more than we have to. The server doing something useful is a requirement for building an interesting business. The client doing something is often a nice-to-have.
There’s also this:
It’s really fast
One of the arguments for a SPA is that it provides a more reactive customer experience. I think that’s mostly debunked at this point, due to the performance creep and complexity that comes in with a more complicated client-server relationship.
When haters deny HTML’s status as a programming language, they’re showing they don’t understand what a language really is. Language is not instructing an interlocutor what to do in a way that leaves no room for other interpretations; it is better and richer than that. Like human language, HTML is conversational. It is remarkably adept at adapting to context. It can take a different shape on any machine, from a desktop browser or an e-reader screen to a mobile app or a screen reader for the blind (so long as that device is built to present hypertext).
Hell, yeah!
Ultimately, even as HTML has become the province of professionals, it cannot be gatekept. This is what makes so many programmers so anxious about the web, and sometimes pathetically desperate to maintain the all-too-real walls they’ve erected between software engineers and web developers.
Hell, yeeeeaaaaahhh!!!
What other programmers might say dismissively is something HTML lovers embrace: Anyone can do it. Whether we’re using complex frameworks or very simple tools, HTML’s promise is that we can build, make, code, and do anything we want.
Yesterday when I mentioned my paranoia of third-party dependencies on The Session, I said:
I’ve built in the option to switch between multiple geocoding providers. When one of them inevitably starts enshittifying their service, I can quickly move on to another. It’s like having a “go bag” for geocoding.
(Geocoding, by the way, is when you provide a human-readable address and get back latitude and longitude coordinates.)
My paranoia is well-founded. I’ve been using Google’s geocoding API, which is changing its pricing model from next March.
You wouldn’t know it from the breathlessly excited emails they’ve been sending about it, but this is not a good change for me. I don’t do that much geocoding on The Session—around 13,000 or 14,000 requests a month. With the new pricing model that’ll be around $15 to $20 a month. Currently I slip by under the radar with the free tier.
So it might be time for me to flip that switch in my code. But which geocoding provider should I use?
There are plenty of slop-like listicles out there enumerating the various providers, but they’re mostly just regurgitating the marketing blurbs from the provider websites. What I need is more like a test kitchen.
Here’s what I did…
I took a representative sample of six recent additions to the sessions section of thesession.org. These examples represent places in the USA, Ireland, England, Scotland, Northern Ireland, and Spain, so a reasonable spread.
For each one of those sessions, I’m taking:
I’m deliberately not including the street address. Quite often people don’t bother including this information so I want to see how well the geocoding APIs cope without it.
I’ve scored the results on a simple scale of good, so-so, and just plain wrong.
Then I tot up those results for an overall score for each provider.
When I tried my six examples with twelve different geocoding providers, these were the results:
| Provider | USA | England | Ireland | Spain | Scotland | Northern Ireland | Total |
|---|---|---|---|---|---|---|---|
| 1 | 1 | 1 | 1 | 1 | 1 | 7 | |
| Mapquest | 1 | 1 | 1 | 1 | 1 | 1 | 7 |
| Geoapify | 0 | 1 | 1 | 0 | 1 | 0 | 3 |
| Here | 1 | 1 | 0 | 1 | 0 | 0 | 3 |
| Mapbox | 1 | 1 | 0 | 1 | 1 | -1 | 3 |
| Bing | 1 | 0 | 0 | 0 | 0 | 0 | 1 |
| Nominatim | 0 | 0 | 0 | 0 | -1 | 1 | 0 |
| OpenCage | -1 | 1 | 0 | 0 | 0 | -1 | -1 |
| Tom Tom | -1 | -1 | 0 | 0 | -1 | 1 | -2 |
| Positionstack | 0 | -1 | 0 | -1 | 1 | -1 | -2 |
| Locationiq | -1 | 0 | -1 | 0 | 0 | -1 | -3 |
| Map Maker | -1 | 0 | -1 | -1 | -1 | -1 | -5 |
Some interesting results there. I was surprised by how crap Bing is. I was also expecting better results from Mapbox.
Most interesting for me, Mapquest is right up there with Google.
So now that I’ve got a good scoring system, my next question is around pricing. If Google and Mapquest are roughly comparable in terms of accuracy, how would the pricing work out for each of them?
Let’s say I make 15,000 API requests a month. Under Google’s new pricing plan, that works out at $25. Not bad.
But if I’ve understood Mapquest’s pricing correctly, I reckon I’ll just squeek in under the free tier.
Looks like I’m flipping the switch to Mapquest.
If you’re shopping around for geocoding providers, I hope this is useful to you. But I don’t think you should just look at my results; they’re very specific to my needs. Come up with your own representative sample of tests and try putting the providers through their paces with your data.
If, for some reason, you want to see the terrible PHP code I’m using for geocoding on The Session, here it is.
Last year I described how I syndicate my posts to different social networks.
Back then my approach to syndicating to Bluesky was to piggy-back off my micro.blog account (which is really just the RSS feed of my notes):
Micro.blog can also cross-post to other services. One of those services is Bluesky. I gave permission to micro.blog to syndicate to Bluesky so now my notes show up there too.
It worked well enough, but it wasn’t real-time and I didn’t have much control over the formatting. As Bluesky is having quite a moment right now, I decided to upgrade my syndication strategy and use the Bluesky API.
Here’s how it works…
First you need to generate an app password. You’ll need this so that you can generate a token. You need the token so you can generate …just kidding; the chain of generated gobbledegook stops there.
Here’s the PHP I’m using to generate a token. You’ll need your Bluesky handle and the app password you generated.
Now that I’ve got a token, I can send a post. Here’s the PHP I’m using.
There’s something extra code in there to spot URLs and turn them into links. Bluesky has a very weird way of doing this.
It didn’t take too long to get posting working. After some more tinkering I got images working too. Now I can post straight from my website to my Bluesky profile. The Bluesky API returns an ID for the post that I’ve created there so I can link to it from the canonical post here on my website.
I’ve updated my posting interface to add a toggle for Bluesky right alongside the toggle for Mastodon. There used to be a toggle for Twitter. That’s long gone.
Now when I post a note to my website, I can choose if I want to send a copy to Mastodon or Bluesky or both.
One day Bluesky will go away. It won’t matter much to me. My website will still be here.
React is a non-transferable skill.
React proponents might claim that React will teach you modern UI, but from what I’ve seen it barely copes with modern UI.
autofocus is broken, custom elements don’t work in all but the experimental version, using any “modern” features likedialogor popovers requiresuseEffect, and the synthetic event system teaches you so little about how DOM actually works. This isn’t modern UI, it’s UI from 2013 at its inception. I don’t have the time left in my career to pick up UI paradigms that haven’t evolved much beyond from when Barack Obama was in office.When I mentor early career developers and they ask me what they should learn, I can’t say React, they don’t have time. I mean sure, pick up enough React to land you the inevitable job doing it, but it’s not going to level up your career.