I've been following this 3D artist for awhile who runs a Patreon called "Happy Flexi Pets". Last night, she posted this ludicrously adorable Owlcat. So, I practically lunged to download the models, get them sliced up, and started the printer running overnight.
The result was pretty great. Look at those beans! đž Sometimes, I love living in the future.
Still thinking about that METR study and I saw John Whiles write this:
The developers could provide chunks of that mental model to their AI tools - but doing so is a slow and lossy process that will never truly capture the theory of the program that exists in their minds. By offloading their software development work to an LLM they hampered their unique ability to work on their codebases effectively.
This feels to me like a good take on why AI assistants slowed down developers in that study. A core challenge with AI coding assistants is context composition and management. But, creating that context takes time and effort that's often orthogonal to writing code.
For developers who can manage complex context in their heads as wordless thought-forms, just writing the code can be faster. AI agents aren't mind-readers, and LLM context windows don't match human headspace.
Here's the irony: AI tools help in situations where human mental models are weakestâand those situations often exist because expert programmers never tried to write down their mental models in the first place. When you're working on projects built by people who left years ago, onboarding engineers struggle to form accurate mental models because the veteran engineers who had those models never documented them. New engineers have to start from scratch.
LLMs can ingest unfamiliar code faster than humans and generate changes that work because they resemble historic patterns. More importantly, they excel at transforming code symbols into readable explanationsâroughly reverse-engineering a likely facsimile of documentation that should have existed.
If you expect to work on a project long-term and want to truly understand it, you need to do the homework: write the code yourself with maybe a little LLM advice and way-finding. At the very least, you should be reviewing LLM-generated code in detail before merging it.
The best approach treats these tools as what they are: power tools for symbol transformation and pattern completion, grinding through boilerplate work that doesn't demand high creativity. They're not replacements for human thinking about architecture, requirements, and constraints.
Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity - METR:
We conduct a randomized controlled trial (RCT) to understand how early-2025 AI tools affect the productivity of experienced open-source developers working on their own repositories. Surprisingly, we find that when developers use AI tools, they take 19% longer than withoutâAI makes them slower.
I'm seeing plenty of "I told you so" as this makes the rounds. But, having spent the past month deep in AI-assisted coding, it directly contradicts my experience. Maybe I've drunk too much Kool-Aid, but I don't think I'm entirely delusional. I want to head-scratch through this, though.
we recruited 16 experienced developers from large open-source repositories (averaging 22k+ stars and 1M+ lines of code) that theyâve contributed to for multiple years.
That's a rather small sample and a very specific scenario, isn't it?
The researchers themselves acknowledge the limitations:
We caution readers against overgeneralizing on the basis of our results. The slowdown we observe does not imply that current AI tools do not often improve developerâs productivityâwe find evidence that the high developer familiarity with repositories and the size and maturity of the repositories both contribute to the observed slowdown, and these factors do not apply in many software development settings. For example, our results are consistent with small greenfield projects or development in unfamiliar codebases seeing substantial speedup from AI assistance.
Maybe this bit from the "Key Caveats" section basically jibes with my experience? My recent work (admittedly, a sample of 1) has indeed been largely with greenfield projects and relatively unfamiliar codebases.
The researchers hint at something important:
We expect that AI systems that have higher fundamental reliability, lower latency, and/or are better elicited (e.g. via more inference compute/tokens, more skilled prompt-ing/scaffolding, or explicit fine-tuning on repositories) could speed up developers in our setting (i.e. experienced open-source developers on large repositories).
I think this rhymes with my experience, too. When I've just charged into a rambling chat & autocomplete session with Cursor, things steer into the ditch early and often.
But when I've worked with Claude Code through a multi-step process of describing the problem, asking the agent to prompt me with clarifying questions, reviewing the problem and considering a solution, breaking it down into parts, and then asking the agent to methodically executeâthat's yielded decently reliable success.
The study notes:
All else equal, faster AI generations would result in developers being slowed down less. Qualitatively, a minority of developers note that they spend significant time waiting on AI to generate code.
I rarely wait, because I'm juggling multiple projects. When one agent instance is working, I switch to another window. Sometimes it's a separate git worktree of the same codebase. Yes, context switching is tiring, but it also seems to help me overcome ADHD-related activation energy barriers?
Over the years, there've been days when I just sit there staring at the IDE window, poking my brain with a stick saying "c'mon, do something" and nothing happens for an hour or more. I'm not planning my next move, I'm just dissociating. My executive function doesn't, like, function. Often. My own brain makes me wait long periods of time before it starts generating useful results. đ
Maybe it's the cycling novelty that keeps me going? I enjoy task switching between prosing and coding. I enjoy finding that the model appears to have "read" everythingâevidenced by it echoing my intent back in code or follow-up questions. I enjoy discovering that while I was in another window, new things happened in the background for me to review.
I've also found that many agents are reliable at handling drudgery. Re-jiggering data structures, applying repeated refactorings, etc. Those tasks can seize me up for tens of minutes at a time with brain-killing waves of tedium. But usually, I can just tell the bot to do it, while I turn to more interesting stuff.
Although the influence of experimental artifacts cannot be entirely ruled out, the robustness of the slowdown effect across our analyses suggests it is unlikely to primarily be a function of our experimental design.
This study focuses on one specific scenario: experienced developers using specific tools on massive, mature codebases. The researchers themselves caution against overgeneralization, noting that different contexts likely yield different results.
These tools aren't magic and they're not universally beneficial. But dismissing them based on this narrow study would be premature. The key is understanding when, how, and why to use themâsomething that's still evolving rapidly as both tools and techniques improve.
I've been procrastinating getting back to it, but I finally threw some hours into a substantial overhaul of my Pebbling Club web link sharing projectâthe first real efforts since December! Migrated from SQLite to Postgres, switched to uv for dependency management, and moved deployment from fly.io to my basement machine running Docker Compose.
I built my own git-push deployment post-receive hook because I'm a masochistâer, I mean I wanted complete control over the deployment process. It's nice watching your own server rebuild containers when you push to main, even if cloud platforms would be more practical.
The development environment became a hybrid: Docker Compose for stable services, Honcho + Procfile for active development. Added Flower for Celery monitoring and experimented with Prometheus and Grafana metrics. (But, then, I reverted django-prometheus because it doesn't work at all like I thought it did.)
I got several useful features working: RSS feed reading, duplicate URL detection through normalized hashing, ActivityStreams-inspired import/export, and a Netscape Bookmarks HTML export (for fun). Built a link inbox that currently handles RSS feeds, with in-progress work to add Mastodon timeline integration and plans for Bluesky.
Along the way, I wanted to see how far I could get with Claude Code and make tweaks to my overall process. If nothing else, the bot helped me get past the barrier of activation energy to get some things done that I've put off for most of a year. The bot wrote a bunch of just-fine codeâand where it was wrong, the wrongness motivated me to get it fixed and done myself.
To make steps toward showing and telling about my Claude Code workflow, I built a browser-based Breakout game with Phaser 3. The repository captures the full development process so farâprompts, commands, and session transcripts.
Along with the basic game, I added a multi-ball power-up to demonstrate iterative development. The game itself isn't particularly novel, but the documented development process might be useful for others exploring AI-assisted coding workflows.
At some point, this will turn into a show-and-tell presentation for co-workers and maybe a follow-up to last month's blog post on "Baby steps into semi-automatic coding".
This took all of a couple hours on a Saturday afternoon on the couch watching TV, but I kind of want to keep going with it. It's rather addictive to just kind of riff on ideas and get them into the game with quick little iterations.
TDD, AI agents and coding with Kent Beck - YouTube
Now, with over five decades of programming experience, Kent is still pushing boundariesâthis time with AI coding tools. In this episode of Pragmatic Engineer, I sit down with him to talk about whatâs changed, what hasnât, and why heâs more excited than ever to code.
This was a really neat interview. I'm a bit behind Kent Beck in years and industry contributions, to say the least. But, it's cool to hear how someone with his level of experience is dealing with the AI era.
Taste Is the New Intelligence - by stepfanie tyler
We used to associate intelligence with accumulation. The smartest people were the ones who knew the most. But that model doesnât hold anymore. AI knows more than anyone. Wikipedia is free. The internet has flattened information access so thoroughly that hoarding knowledge is no longer impressive. What matters now is what you do with it. How you filter it. How you recognize signal in the noise.
Curation is the new IQ test.
If I can keep myself motivated to make progress on Pebbling Club, I kinda want to build something that's basically a web curation platform with the ability to share your taste with others.
amantus-ai/vibetunnel: Turn any browser into your terminal & command your agents on the go.
Ever wanted to check on your AI agents while you're away? Need to monitor that long-running build from your phone? Want to share a terminal session with a colleague without complex SSH setups? VibeTunnel makes it happen with zero friction.
This reminds me of when I once in college when I managed to telnet from a computer lab back into my Commodore Amiga 1200 dialed into a SLIP internet connection. No firewalls. It would have really sucked if someone else had known my IP address at the time. đ
I've spent a lot of hours this week on this project instead of the usual lucky dip. Here's what I've done so far using my AY tracker terminal-based software
I built an RC2014 kit computer, last year. I also built a Why Em-Ulator Sound Module for it and managed to get it playing some neato tunes. I should check out this tracker and see if I can make some neato tunes.
Jason Santa Maria, Large Language Muddle:
As someone who has spent their entire career and most of their life participating and creating online, this sucks. It feels like someone just harvested lumber from a forest I helped grow, and now wants to sell me the furniture they made with it.
The part that stings most is they didnât even ask. They just assumed they could take everything like it was theirs. The power imbalance is so great, theyâll probably get away with it. ... I imagine there will be a time when using these tools or not creates a rift, and maybe it will be difficult to sustain a career in our field without using them. Maybe something will change, and Iâll come around to using these services regularly. I donât think Iâll ever not be angry about it.
This is involuntary stone soup at scale. I'm also dismayed about how LLMs came to be, yet aware that the bomb still works regardless of my feelings. I'm convinced I need to understand this technologyâI don't think I can afford to simply opt out.
But I'm also staying tuned to skeptical takes, fighting to keep my novelty-seeking brain from falling into cult-like enthusiasm. While I can't dismiss this technology as pure sham, I refuse to swallow inflated claims about what it actually is. I want clear-eyed understanding.
Jason's anger resonates because it points to a deeper loss:
And still that anger. Itâs not just that they didnât ask. If these tools have so much promise, could this have been a communal effort rather than a heist? I donât even know what that wouldâve looked like, but I can say I would feel much differently about AI if I could use a model built on communal contributions and opt-ins, made for the advancement of everyone, not just those who can pay the monthly subscription.
Behind that anger is sadness. How do we nurture curiosity and the desire for self growth?
I believe there's a path forward that can nurture curiosity and growth.
I've seen how these models can surface insights and patterns from overwhelming pools of informationâhallucinations are always possible, but it's surprising how often they don't happen. I've seen how their "spicy autocomplete" can help me get where I intended to go fasterâlike talking to a fellow ADHD'er who sees where I'm going and jumps straight there.
And these models aren't disappearing, even if the companies burning cash do. The models already released openly will power unexpected developments for decades, even if just passed around as warez torrents.
This feels like the dot-com bubble all over again. When that bubble burst, the web didn't die: people with spare time and leftover experience built the blogosphere, API mashups, and the foundations of Web 2.0.
I suspect we're heading for a similar pattern. Maybe it's wishful thinking, but I kind of expect we'll see a bust followed by cheap, surplus capacity thatâwhile not the communal effort we deservedâbecomes accessible to anyone who wants to experiment and build something better.
Most of my work has happened in Windsurf and Claude Code over recent weeks. I can picture a future where I'm essentially an LLM managerâkeeping code-generation plates spinning and nudging toddling bots away from falling into ditches.
Some folks claim they play games while the agent codes, but I'm actively reviewing as it writes. Turns out watching a bot write code for you takes surprising mental effort. đ
As I get deeper into this, I'm still processing the skeptical pushback. I know I'm drawn to novelty and clever tricks, so I'm trying to temper my enthusiasm and engage seriously with contrary opinions.
Some people haven't had success with these tools, but "you're holding it wrong" is a bad response that doesn't address the real objections. I'm having concrete wins personally, but figuring out the precise how and why feels elusiveâtoo many variables and RNG elements to be properly scientific about it.
My main stake in AI coding is that it's what I'm paid to do right now in this industry. I am also rather fascinated with the stuff. Not exactly an unbiased position, but at least I'm not trying to sell anything other than my time & labor.
I've seen arguments that this could all be Stockholm syndrome and excuse-making for the machine. Others warn that I shouldn't trust my own judgment on AI because I'm essentially self-dosing with cognitohazards.
The more antagonistic responses make me sympathize with the guy who says his AI skeptic friends are all nutsâwhich feels like tit-for-tat, since accusations of mental instability seem to flow both ways.
Honestly, I can also relate to just being done thinking about the whole thing for now. But, personally, I don't think I can afford to do that.
So I did a thing. I spent time this week building an actual project using an AI coding agent. I ended up with 11,000 lines of code that actually work. To be clear: it wasn't great codeâlots of boilerplate, plenty of "I would have written this eventually anyway" stuffâbut it did what I intended it to do. More importantly, it got done without me having to fight my ADHD through every tedious implementation detail. [ ... 1017 words ... ]
Since re-launching my blog, I wanted to monitor traffic and logs more closely. Nothing groundbreaking, but it had been a while since I'd run Grafana, Prometheus, and Loki on my own hardware.
Turns out there's this handy all-in-one docker-compose setup that runs on Synology NAS. It fired up with minimal fuss, and soon I had metrics machinery humming in my basementâexcept the package didn't include Loki. A quick docs consultation got it running alongside the rest.
My blog is a static site hosted via AWS S3 and CloudFront. Both services dump logs into an S3 bucket, but I'd never bothered reading them beforeâand didn't want to start now. Instead, I loaded up Claude.ai and described my problem:
I want to get logs out of CloudFront. I have enabled new-style log delivery that stores gzipped JSON logs in an S3 bucket at s3://lmorchard-logs/blog.lmorchard.com/ with names like E5YXU82LZHZCM.2025-06-04-04.d024d283.gz
Can you help me write a script for my home Loki server to download only new log files and push them into Loki?
Claude stepped right up:
I'll help you create a script to process CloudFront logs and push them to Loki. Let me write a Python script that tracks processed files and handles the gzipped JSON format.
After some vibey iteration, we landed at this artifact:
It's quite verbose and could use some tightening up. But, I really don't careâit does the quick & dirty needful.
I wrote zero Python. I just henpecked Claude to add features until the script did what I needed. I wasn't even in an IDE, just the Claude.ai interface in a browser. An interesting thing to note is that Claude didn't have access to my AWS resourcesâI didn't even give it a sample of my logs. But, still, what I told it about JSON, S3, and CloudFront was enough for it to be off to the races.
Anyway, after a quick review and a satisfactory dry run, I dropped it into a cronjob to grab new logs every 5 minutes. Then I pestered Claude with Grafana dashboard questions I could have figured out myself. But why read docs when you can just ask? (Which I realize is ironic, since I wrote Too long? Read anyway. but I think I make an exception for LLMs.)
Total time from idea to working dashboard: about an hour.
Not revolutionary, but pretty satisfying for barely having to think about it.
W. David Marx, GenAI is Our Polyester:
Everyone knows happened next: There was a massive cultural backlash against polyester, which led to the triumphant revaluation of natural fibers such as cotton and linen. The stigma against polyester persists even now. The backlash is often explained as a rejection of its weaknesses as a fiber: polyester's poor aeration makes it feel sticky. ... While polyester took a few decades to lose its appeal, GenAI is already feeling a bit cheesy. We're only a few years into the AI Revolution, and Facebook and X are filled to the brim with âAI slop.â Everyone around the world has near-equal access to these tools, and low-skilled South and Southeast Asian content farmers are the most active creators because their wages are low enough for the platforms' economic incentives to be attractive.
This along with remembering that some professors are going back to handwritten essays (and also that handwriting is better for memory and learning) had me wondering if there's going to be a handcrafted backlash in the next few years?
I write journal entries nearly every day by handâalbeit these days on an e-ink tablet. I think that helps me focus on what I want to dredge out of my head. I keep meaning to get back to that handwriting recognition project I started a few weeks ago, since no product I've tried yet has been able to turn my writing into clean machine-readable text.
But, then again, maybe producing machine-illegible works by hand will be the next big trend?
According to the count in my archives, I've published over 50 blog posts in the past few weeks. That's roughly 50 more than I managed in the previous 10 years! These aren't masterpiecesâmostly just random thoughts and half-baked ideas. But as I mentioned before, I'd rather throw a bunch of stuff at the wall and see what sticks than spend another decade crafting the perfect post that never gets published. So, here's how I tinkered my way into a writing setup that seems to actually be working. [ ... 873 words ... ]
I found myself in a frustrating argument with someone convinced that LLMs are pure vaporwareâincapable of real work. Their reasoning? Since LLMs were trained on stolen material, the results they produce can't actually exist.
Not that the results should be considered illegitimate or taintedâbut that they're literally impossible. That the training data's questionable origins somehow prevents the technology from functioning at all.
I couldn't convince them otherwise. But, life isn't fair and both things can be true simultaneously: the origin of something can be problematic and the results can be real.
This analogy kept coming to mind: If someone steals materials to build a bomb and successfully builds it, they have a functioning bomb. The theft doesn't retroactively prevent the bomb from existing or reduce its explosive capability. Proving the theft might help with future bombs or justify going after the bomb-maker, but it doesn't cause the current bomb to magically self-dismantle.
This seems obvious to meâembarrassingly so. Yet I keep encountering this form of reasoning about LLMs, and it strikes me as a particular kind of denial.
There's something almost magical in the thinking: that moral illegitimacy can somehow negate physical reality. That if we disapprove strongly enough of how something was created, we can wish away its actual capabilities.
The ethical questions around LLM training data are important and deserve serious discussion. But pretending the technology doesn't work because we don't like how it was built isn't engaging with realityâit's a form of wishful thinking that prevents us from dealing effectively with the situation we actually face.
Whether we like it or not, the bomb has been built. Now we need to figure out what to do about it.
Someone told me that prompt engineering isn't realâthat it's just techbros rebranding "good writing" and "using words well." I disagree, and here's why:
Prompt engineering fundamentally differs from writing for human audiences because LLMs aren't people. When done rigorously, prompt engineering relies on automated evaluations and measurable metrics at a scale impossible with human communication. While we do test human-facing content through focus groups and A/B testing, the scale and precision (such as it is) here are entirely different.
The "engineering" aspect involves systematic tinkeringâsometimes by humans tweaking language, sometimes by LLMs themselvesâto activate specific emergent behaviors in models. Some of these techniques come from formal research; others are educated hunches that prove effective through testing.
Effective prompts often resemble terrible writing. The ritual forms, repetitions, and structural patterns that improve LLM performance would make a professional editor cringe. Yet they produce measurable improvements in evaluation metrics.
Consider adversarial prompts: they're often stuffed with tokens that are nonsense to humans but exploit specific model quirks. Here, the goal is explicitly to use language in ways that aren't human-legible, making attacks harder to detect during review.
Good writing skills can help someone pick up prompt engineering faster, but mastering it requires learning to use words and grammar in weird, counterintuitive ways that are frankly sometimes horrifying.
All-in-all, prompt engineering may still be somewhat hand-wavy as a discipline, but it's definitely realâand definitely not just rebranded writing advice.
Simon Willison on no-build wedev:
If you've found web development frustrating over the past 5-10 years, here's something that has worked worked great for me: give yourself permission to avoid any form of frontend build system (so no npm / React / TypeScript / JSX / Babel / Vite / Tailwind etc) and code in HTML and JavaScript like it's 2009.
This blog has a "backend" build process to produce the static HTML. But, the frontend is pretty much build-free.
Web development with "vanilla" JavaScript has gotten pretty good in the last decade, thanks to Modules, dynamic import(), Custom Elements, and a pile of other relatively recent APIs.
The easy path at work these days tends to be Next.js, but I kind of hate it. All my side projects start with touch index.{html,js,css}. I roll on from there with maybe a live-reload HTTP server pointed at the directory (e.g. npx reload src).
That said, I have started playing with carefully re-introducing some build tooling for a few side projects - but, only for external dependencies. I've tinkered a bit with using esbuild to compose bundles as JS modules importable by the rest of my unbundled modules.
The nice thing about this is that I can treat those external dependencies as standalone utility modules without infecting the rest of my project with build machinery. I can even just check in a copy of the built asset to keep the project stable and usable, years later.
Jon Udell, MCP Is RSS for AI:
It may sound impressive to say âI built an MCPâ server, but the mechanics are delightfully trivial â which is why Iâm inclined to think of MCP as RSS for AI. The beauty of RSS as a protocol was its simplicity. You can write an RSS feed by hand, or write very simple code to generate one. Writing an RSS reader was the starter project for many a beginning coder. Itâs not quite that easy to work with MCPâs protocol, JSON-RPC, but vastly easier than working with, say, the protocols spoken by Fediverse or Bluesky clients and servers.
I need to play with MCP more. I've gotten through the basic "hello world" tutorial and hacked together a server that emits random cat facts. That was pretty cool, asking Claude to do "research" on cats and vomit a little throwaway essay sourced from that.
But, yeah, it was very simple. In fact, I worried it's too simple. It's kind of a slapdash protocol. But, I think I worried that about RSS when I first saw it, way back in like 1999. I figured I'd have to learn SGML and XML and NewsML (?!?) to do anything interesting with syndicating content on the web. I don't even remember where I dug up references to NewsML, back then.
Like Anil Dash notes, "slightly under-specified protocols that quickly get adopted by all the players in a space are what wins". There do seem to be similar vibes coming from MCP as we got from things like RSS and XML-RPC back in the 2000s.
Dan Sinker, The Who Cares Era:
The writer didn't care. The supplement's editors didn't care. The biz people on both sides of the sale of the supplement didn't care. The production people didn't care. And, the fact that it took two days for anyone to discover this epic fuckup in print means that, ultimately, the reader didn't care either.
It's so emblematic of the moment we're in, the Who Cares Era, where completely disposable things are shoddily produced for people to mostly ignore.
This hits me hard right now. Itâs part of a broader sadness Iâve been feelingâespecially around the shrinking prospects for paid work that actually feels career-meaningful.
Dan calls it âdisheartening,â and I feel that. He also writes, âItâs easy to blame this all on AI, but itâs not just that.â Exactly. This didnât start with LLMs. They just sped things upâand ensured even fewer people get paid to produce an ever-growing volume of slop.
Whatâs worse: much of this output isnât even for people anymore.
The user isnât the customer. And theyâre not the product either. The real product is behavioral optimizationâmetrics on a dashboard. The paying customer is somewhere else entirely, and the "content" is just a means to nudge behavior and juice KPIs.
Thatâs why we see this flood of AI-generated blog posts, podcasts, and articles that barely say anything and just conjure a vibe. Why publish something devoid of editorial oversight or substance? Like, who is this for?! It meets a quota, hits a keyword target, triggers an engagement metric. But, it doesn't reach a person except incidentally or by accident.
The point isnât to communicate. Itâs to simulate relevance in order to optimize growth. It's all goal-tracking, A/B tests, fake doors, and dark patterns.
Itâs not publishing. Itâs performance art for algorithms. Interpretive dance for the bots. It's sympathetic magicâbuilding the runways and replicas, hoping the traffic increases.
And thatâs what makes me so sad. It reveals such a grim meathook future ahead, a solipsistic view of humanity: most people reduced to NPCs in someone else's growth funnel. Not peers. Not audiences. Just marksâbehavioral units to be nudged for another uptick.
Anyway, I donât have a better conclusion than Danâs: "In the Who Cares Era, the most radical thing you can do is care." Heâs right. And honestly, Iâm still trying to figure out what that looks like, day to dayâbesides being caremad and grumpy all the time, that is.
