I know there's some sentiment that like, announcing "maybe THIS level of our exclusive new AI is just TOO POWERFUL for the world" is kind of an old ploy already - and as Fireship (one of the more enjoyable ways of absorbing tech news) points out, some of the metrics and test cases... even if Mythos is quantitatively better it's not clear how big of a qualitative change it is.
Even if you're all hot and bothered to hop onto the "vibe coding maestro" train, it's good to have some idea of what's going on in Javascript in 2026.
I wonder if browsers will ever start doing Typescript natively. There's such a beauty in buildless systems, and browsers have been so good at backwards compatibility and keeping things evergreen.
I guess we don't realize how much of LLM's helpfulness and good spirit comes from being trained on online technical resources with that point of view - maybe in a more-than-poetic way, LLM reflects the community spirit of OSS. But if you change that vibe at a fundamental level - you have a formidable tool. And maybe the best we can do is make sure our "gray hot" bots help us shore up our defenses before the black hats get a hold of it.
There's a straight shot for me from "slapping up webpages via my university ~/public_html directory" to "put up CGI on cheap shared webservers" to "running whatever I want on a rented VPS". Actually I still think buildless/evergreen on my VPS is my secret sauce, where I'm able to put up a new service or webapp without putting down a credit card of starting a new business relationship, and AI (agentic and chatbot) plays REALLY well with that. Sky's the limit and with my Porchfest sites I've seen how simple, almost under-engineered things can scale to accommodate even super-spiky traffic days. (Which makes my disenchantment with how complexity has grown in the Enterprise even stronger.)
So my question is, what would the Geocities of this current era be? Obviously it's much much more fraught to offer space where web apps can run, but still, while I get how empowering agentic can be for people who can clearly describe what they want but have never learned to put that in deterministic coding, WHERE they put things (besides running it locally, or maybe using some cheap freebie hosting) seems like an interesting question.
I'm reading Gene Kim and Steve Yegge's book "Vibe Coding":
When we say vibe coding, we mean that you have AI write your code—you’re no longer typing in code by hand (like a photographer going into a darkroom to manually develop their film). Although the most visible and glamorous part is code generation, AI helps with the whole software life cycle. AI becomes your partner in brainstorming architecture, researching solutions, implementing features, crafting tests, and hardening security. Vibe coding happens whenever you’re directing rather than typing, allowing AI to shoulder the implementation while you focus on vision and verification.
I've "vibe-coded" a few medium-small things, but they were enough to impress friends who were techie but not in the loop.
Still I am more or less persuaded that the future of dev will likely be Yegge's kitchen model:
You’re the head (or executive) chef of the kitchen, and AI represents the army of chefs who help bring your vision to life. AI serves as your sous chef (your second in command) who understands your intentions, handles intricate preparations, and executes complex techniques with precision under your guidance. But AI is also your army of station chefs and cooks, specialists who help handle various technical details.
But it's not clear to me how individual devs should ramp up to that style of production if their current day job isn't there yet.
So some thoughts after reading the first section of the book:
The book spends a page talking about how complex web app construction has gotten, and how many things enterprise developers need to know - "package managers (npm, Yarn), bundlers (webpack, Rollup), transpilers (Babel), task runners (gulp, Grunt), testing frameworks, CSS preprocessors, build toolchains, deployment pipelines" and then says "Because of the DevOps philosophy of 'you build it, you run it,' you also need to learn Docker, Kubernetes, AWS, and infrastructure-as-code tools like Terraform, not to mention a whole host of AWS, GCP, or Azure services." That's definitely been true for my professional life, but I'm still shocked at how little of that I need for my side projects (and I laugh at how "Server Side Rendering" was the new hotness a few years ago, when older, simpler stacks never left that.) So when I try and get into a fuller vibe coding model, I have to decide if my monolithic, buildless, evergreen stack is still the best bet (and frankly AI understands it really well) or if I should use it as an excuse to add some buzzword bingo to my resume.
As a side note, it's still startling how bad LLMs can be if they don't have access to the right subtools. I was feeling lazy (or experimental, at least) and asked both Claude and ChatGPT to do a simple "here's a big hero splash image for a porchfest site with an embedded date, please keep the image the same but update the date" task. ChatGPT choked on it, Claude got it in at a barely acceptable level, and I realized I should have just sucked it up and done it by hand.
There's such a cyberpunk feel to this moment, or at least the near future. A little hard to explain if you're not familiar with the genre, but like the decision to use a "corpo" LLM vs maybe a grungy LLM you have on your own hardware... or just everyone running around with their own bespoke software. It smells like mirrorshades.
The book has a chapter of cautionary tales, examples of LLM going way off the rails, sometimes causing damage. I ran into one of those cases of LLM shortcutting when I vibecoded a CSV to address label PDF app - Claude was all too happy to keep using hardcoded test data for the actual print pages even after I had had it switch to live data for the setup and config pages. (I only had one set of data I cared about to test, so it took me a bit to notice)
One thing the book is a little light on discussing frankly is costs. This stuff threatens to create a real divide between the have and the have nots. I have a couple buddies (both formerly involved in guitar bands, interestingly) where tech was the path out of poverty. It seems like that could be harder if the people who can afford $20-$200/month in AI helpers are the only ones who really learn to leverage helpers at scale.
And of course there's the other lingering fear for developers... we have to hope that the people we report to now, the PMs and POs, don't find out we're not necessary - that running AI at scale will be enough of a skill that we still have value to add.
There can be such a religious fevor to both the AI-believers and the AI-rejectors. A while back I grabbed this passage from Jim Holt's "When Einstein Walked with Gödel": "[Richard Rorty] also liked to cite Nietzsche’s observation that truth is a surrogate for God. Asking of someone, “Does he love the truth?” Rorty said, is like asking, “Is he saved?”"
At any rate, I know I do need to professionalize my side project world at least a bit - when you're dealing with a hoard of junior programmers you don't quite trust, testing, first rate source control, and deployment strategies can be more important than ever...
It's a worthwhile summary of this point in development history.
Earlier I was appreciating the zeitgeist that maybe we were near the top of the S-shaped curve of what LLM could do, things might be settling down a bit. But recently I've been catching a different spin, that specifically the model releases last November really pointed to a new level of capability - something beyond the intuitions programmers experimenting with LLM the years before would have developed. (The future might be the dev as head chef, with a bot sous chef bossing around a small hoard of underling agents.)
Scott mentioned Red Hat is pivoting to agentic workflow: "One interesting thing our CTO said was, we will not measure AI consumption, we will measure code coverage, quality, etc. Focus on outcomes."
Now, casting a blind eye to consumption reminds me of a tale from AOL/Millennial Media, when they thought pivoting to the cloud/AWS was giving them a bunch of dev and qa servers "too cheap to meter" - an expensive lesson they had to correct course around. And of course, there's the environmental impact (energy and water consumption - not to mention the "environment" of the crazy costs of GPUs and memory). And for all the democratization of code LLM offers, the idea that you must shell out month after month on a service (or buy some ridiculously priced hardware) in order to be competitive threatens to undermine the self-starting developer paradigm that got its start when home computers became cheap in the 80s.
But as I try to figure out how I can maintain my role as mediator between Business Folk and Machines I want to think about the second part of Scott's paraphrase, "code coverage, quality, etc"
Too often (in my heretical, anti-reductionist opinion) organizations go to quantify code coverage via unit tests percent coverage. But AI is going to require a new sense of what "quality" is:
* ability for future gens of your AI hoards to pick things up and iterate on earlier work
* consistent behaviors (externally testable)
* human-friendly UX (when applicable)
* edge cases covered
* one layer of AI check looking for weirdass shortcuts AI may have taken
* security, security, security
All of these have parallels in what traditional software development has to be keeping an eye on, but with humans being not as deeply embedded in the core loops, we will need more a more sophisticated way of quantifying how well things are going.
My buddy Scott is a highup Project Manager at Red Hat. We hang out on a tiny group chat.
Scott has a huge experience with Open Source (and did some pioneering work in containerization) and is on board with the idea that AI is the future of development. He's really worried that the good guys get busy, overcome their inertia and reservations, and learn the arts of leveraging AI to make good stuff (with efficient token/energy use) and learning how to defend things from the bad guys, who never seem to have the same kind of compunctions about using any tool they can find.
He's fighting a war on two fronts; he yells at me for bringing up stuff from the AI-skeptic side, both from absolutists who will push back against AI tooth and nail, as well as from middle of the road developers who find utility in these "Jr Programmer Level of companions" but keep bumping their head into the limitations and confusion that results as context windows get filled up and what not, as well as some of the infamous AI gaffes making the rounds.
The other front is against executives who are too gung-ho about it all - who say "just build it" without acknowledging how the problem is no longer the coding - we now are in an age of surplus programming/build potential - but deciding what to build that will provide sustainable value, as well as socializing and building community around what gets built.
* Yegge claims that a real corner was turned last November, in terms of what models like Claude Opus could do vs the earlier stuff. I'm currently nursing a theory that says, there might be a qualitative difference between those "$200/mo" models vs the "$20/mo" models that both the naysayers and the CEO types have been messing with, which has increased the skepticism in the first camp (as they run into limits) but with CEOs empowered enough to build cool stuff and not getting bothered by the MVP/prototype level of what they make. (I don't think Scott agrees with my analysis, but anyway) But Yegge says stuff like the long vaunted "10x Programmer" is now actually unlocked.
* Yegge points out that this AI-driven 10x mode is actually exhausting (hence the title of the piece) I'm guessing coding with AI takes a significant part of the fraction of doing it "by hand". It's a more concentrated set of demands and focus.
* and So we have a classic "where does the value go" situation. If the company tries to get 10x the work all the time, endless go-go-go mode, that's just a recipe for burnout. Conversely, if it's more like employees just put in 1/10 the effort, that's a plan to get swamped by competitors who are increasing their productivity. Yegge thinks its crucial we find a balance for the value capture.
And so I'm working but wondering what the rest of my career looks like - and where I am on the bellcurve of adoption...
I was really bummed to see journalist Benj Edwards got in trouble with AI fabricating quotes (he claims he was loopy with COVID and mistook paraphrases from one tool for actual quotes from another.)
I really enjoyed his previous work on computer history and retrogames - his occasional appearance on the podcast Retronauts, and I even bought a arcade stick for the Atari 2600 he was making as a side hustle.
Basically the TLDR is: isVisible && <item /> to control visibility in React isn't great... edges cases of falsiness (like "NaN") may show up when you were hoping for a blank. So use the ternary operator with "null" as the false case instead.
On my team I pushed it a little further and asked if we could prefer
I really do love a good URL scheme. The first time I was blown away by an elegant scheme was Jira, back around 2010 I think. They incorporated ticket numbers directly in the path, and I had a brief flicker of "wait, they can do that now?" (at that point, URL routers weren't ubiquitous, and URLs often had to be implemented as a physical file structure.)
URLs remain such a powerful form of UI, even after the industry's pivot to "mobile (app) first". Even to this day, people always aren't in a hurry to download your company's app, and a lovely URL can be so expressive - so much kinder to humans than "robot throwup" QR codes.
(And don't get me started on ?fbclid privacy-breaking tracking nonsense; I wouldn't be QUITE so resentful if they weren't so long and winding - no GUID needs to be that long.)
Most likely this is a ruse (with fake books and authors) to sucker would-be authors in to pay for "Resources for Writers" etc, or to just harvest contacts.
As KJ Charles puts it:
"I've just realized. Banks used to be big imposing high street buildings because it gave people confidence they had money and weren't fly by night. A big elaborate website was the internet equivalent: proving someone had invested £ and was here to stay.
You can't trust that any more."
It reminds me of "Nigerian Prince" scams... people wondered why they were so transparently false and full of typos, but the smart view was the clumsiness and blatancy was a feature, not a bug - they were casting a very wide net and wanted only the most gullible fish.
This changes that equation, but only somewhat. It's still pretty obvious it's a fake site (you can google based on the fake titles and author names if you want) since everything is put behind a "contact us" personal data harvesting form, but that is lurking beneath a very polished veneer.
Like everyone else, still trying to get a read on the present and future of AI in tech. Most everyone is daunted by being on the wrong side of a "have and have not" divide in terms of being able to use these tools, and thoughtful people have concerns ranging from the cultural to the environmental about the long term impacts.
People's results when handing parts of development over to AI seem to vary greatly, and it's hard to know if people are tackling different problems (so it's not apples to apples comparisons) or if some people are using better tools (or throwing more tokens at things!) or using methods to provide more structure to the AI, vs the "prompt and pray" approach.
It may be useful to see places that are taking more experimental and data-driven approaches, than just relying on anecdotes...
"Novice workers who rely heavily on AI to complete unfamiliar tasks may compromise their own skill acquisition in the process. [...] We find that AI use impairs conceptual understanding, code reading, and debugging abilities, without delivering significant efficiency gains on average. Participants who fully delegated coding tasks showed some productivity improvements, but at the cost of learning the library."
Another video is "We Studied 150 Developers Using AI" that had a special focus on longer term maintainability, vs just the initial cost.
"Well, the headline is there was no significant difference between the cost of maintenance between AI and human generated code. That's interesting and perhaps not what we might have expected. Code written with AI assistance was no harder to change, no easier to change, no worse in quality and no better in quality."
And also, besides some of the speed up in dev, dev who used AI on the the regular tended to make more idiomatic "normal" code.
Anecdotally this lines up with some of my experiments with Claude Code - where you give high level direction as a PM/QA rather than using CoPilot or ChatGPT has a coding buddy. I feel like the sweet spot is using AI to augment rather than replace the classic developer role. Maybe some of that's wishful thinking, maybe some of that's recognizing the cost these systems have and how they really can lose the thread sometimes. (I mean so can humans, but it has a different feel...)
Recently I saw an ad for Wes Iseli's "flip" coin magic trick (the algos have figured out I kind of like 'magic exposed' videos) and went to google up more on it and found this blog boston.conman.org entry
So I was tickled to see a link to my own blog, kirk.is site on the side
(And then a link to flutterby - another long running blog site, even more aggressively rooted in the page layout tropes of an earlier era.)
I realized that the only reason I could reach out to the first link was because of an oldschool mailto: tag - and that my own site didn't have any "contact me" info. I probably avoided putting my own email up because of spammers, though that fight has more or less moved on. (Also there's a kind of half-wise, half-dumb assumption that most people who view my blog actually know me IRL)
Still, it's nice to see fellow old-school-bloggers still at it. There's probably a kind of mental hangup that keeps us at a pursuit for over two decades... but owning a little piece of the 'net that way before Web 2.0 moved everything onto other people's sites is still kind of fun.
I'm annoyed Amazon swapped up the colors it offers for highlighting in the Kindle App (and the devices that support color.)
Like the colors had meaning that made sense to my brain in a synesthesia kinda of way - yellow "plain old highlight", blue "quote this on the blog" (blue being the color of links), red "I disagree or it makes me annoyed" (red being associated with anger), leaving orange which I used for "I want to go look this up"These are the new colors, and "Aqua" replaces Blue and "Pink" the old version of Red. Like the colors are close enough that there's not too much conclusion, but it's annoying to have the new palette retroactively applied to all my years of past reading. (I wonder if the choice is aesthetic or has some accessibility concerns I'm unaware of.)
In 1982, Atari had a movie trailer commercial featuring the game "Yar's Revenge"....specifically, it was a fanciful "making of" that had the programmer making all kinds of absurdly high level voice commands and gestures to construct an original game.
Of course, this commercial was hitting differently from 1982-2022 (the introduction of accessible LLMs) than it does now - it's still out there but less of a crazy fantasy.
And we've had a year or two of extreme hype. Was LLM - FINALLY - the fulfillment of the dream (started with COBOL, believe it or not) of "*now* the non-programmers can make a program from plain text"?
Well, sort of.
In some places the wheels have fallen off the hype bus. It's tougher to "vibe code" your way to complete system than was promised. When you use a complex "do it all" system like Claude, at least without detailed BDUF (big design up front)/waterfall, regressions show up all the time, and if you're not throwing tons of money at it, you hit token/usage ceilings frustratingly quickly.
I'm fascinated by the modes of collaborating with AI to program. I think I've seen three modes:
A basic chat ala ChatGPT, where you CAN copy and paste a file or block in, but its mostly working out of its sandbox
B do it all systems like Claude... still chat based, but it's more geared at getting a lot of instructions at the outset and doing it all for you
C context sensitive, in-editor solutions like CoPilot in VS Code
I've had a lot of luck with style A, and use style C for work.
I've been writing a bespoke todo webapp with Claude in style B, and the results have been mixed. I repeatedly hit usage limits with the $17/mo program (charged annually) and I'm not positive if that represents Anthropic being more upfront about the costs, or if I'm just asking Claude to do to much, to keep to much in its cyberhead.
Which is the decisive factor right now - when top down things go badly, are you just not doing enough design in your prompts? Should you be throwing more money at it? Or would be better if to take a more "paired programmer" approach.
I think I need to start paying for some CoPilot... letting the human drive the context probably gets better results from "dumber" AI than have an LLM do it all.
As a sci-fi loving kid I said "I think the sweet spot will be computers working in tandem with humans, over computers or humans alone". That seems (optimistically!) weirdly prescient at this moment.
My 11 year old nephew independently discovered a kind of fun art technique I made up for myself a decade ago - using layers to draw over a photo, and then using the eyedropper tool to grab a flat color and then apply it to a larger region, resulting in a nice illustrated/cel shaded look.
Being a life long doodler myself, I bought him an iPad and an Apple Pencil last year to encourage this kind of play, but was curious that he ignores the Pencil in favor of the fingers nature gave him. This sort of surprised me; when I doodle on my own iPad I NEED the precision of a good stylus... with a fat opaque fingertip it's too hard to make lines meetup. And his lines were fine! But I put on my UX researcher hat and observed - and in a minute the answer was clear - he pinches and zooms in ALL the time as needed to where the imprecision of a finger doesn't matter. And not just zoom, but rotate to get a more convenient angle for the coloring motion of his fingertips. Stodgy old me, growing up with pen-on-paper, this wasn't an option. And I never was comfortable with how some iPad art programs made it "too easy" to rotate. (Heck, my current favorite doodle pad Apple Notes doesn't even have zoom in!) But this next generation - they're touchscreen native in a way I will never be... The kids are alright.
Making the rounds (as in, Apple fans seeing it on Daring Fireball)
A seriously damning critique of Apples overuse + underdistinguishment of icons on dropdown menus: It’s hard to justify Tahoe icons
The root cause is that assuming every item needs an icon is a misthink.
I don't know if there's a counter argument that for certain cognitive ways of being, for certain visual thinkers, all the icons help. But probably the old Apple HIG (Human Interface Guidelines) got it right.
