I keep hearing folks claim that the fact we can ‘prototype’ so quickly now is a good thing (thanks to modern genAI). But what if the slow parts about prototyping are actually what make it worth doing?
I haven't made anything with AT Proto yet
This is the blog post I write before I actually build anything on AT Proto
There's no reason for software to be slow anymore
The other day, I saw a viral tweet saying that people talking about how LLMs are causing slow, bloated, code are going to eat crow once they re-write everything in super-optimized assembly. We're not quite at the point where we want to write everything in assembly, but some variant of what Nolan Lawson said about testing, you can choose how many bugs you want now, which I less eloquently noted here, is becoming more true for performance.
Everything is ugly, so go build something that isn't — Raiza Martin, Huxe (ex NotebookLM)
In spite of hype, many companies are moving cautiously when it comes to generative AI | TechCrunch
Companies are extremely interested in generative AI as vendors push potential benefits, but turning that desire from a proof of concept into a working product is proving much more challenging.
No Vibes Allowed: Solving Hard Problems in Complex Codebases – Dex Horthy, HumanLayer
the new product designer (and why we’re getting it wrong)
What my chess app taught me about the future of multi-user software - hadsie's blog
I was skeptical that AT Proto was anything more than Bluesky-with-extra-steps, learnt how much potential the protocol has after building a multiplayer chess app, entirely client side and "on protocol". The real value is that apps become different views into the same data.
Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity
Despite widespread adoption, the impact of AI tools on software development in the wild remains understudied. We conduct a randomized controlled trial (RCT) to understand how AI tools at the February-June 2025 frontier affect the productivity of experienced open-source developers. 16 developers with moderate AI experience complete 246 tasks in mature projects on which they have an average of 5 years of prior experience. Each task is randomly assigned to allow or disallow usage of early 2025 AI tools. When AI tools are allowed, developers primarily use Cursor Pro, a popular code editor, and Claude 3.5/3.7 Sonnet. Before starting tasks, developers forecast that allowing AI will reduce completion time by 24%. After completing the study, developers estimate that allowing AI reduced completion time by 20%. Surprisingly, we find that allowing AI actually increases completion time by 19%--AI tooling slowed developers down. This slowdown also contradicts predictions from experts in economics (39% shorter) and ML (38% shorter). To understand this result, we collect and evaluate evidence for 20 properties of our setting that a priori could contribute to the observed slowdown effect--for example, the size and quality standards of projects, or prior developer experience with AI tooling. 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.
What We Learned from Letting AI Posttrain AI
We built a posttraining task that runs for 20 hours with the Tinker API. The core bottleneck is research intuition.
Scott Jenson – Exploring the world beyond mobile
Fast AI requires slow thinking The current Silicon Valley flex is trading notes on your favorite new AI tools over lunch. Each week brings another one to explore. Some of these tools are very impressive; I’ve been able to reply to someone with an alternative UI design in less than a minute, and they were […]