Caleb Gross:
“Humans are valuable.” You can just say it. As a human yourself, I advise you to. You do not need to qualify it. This is a robust[1] statement that is not conditional on a point-in-time snapshot of the leading frontier model’s score on some recent benchmark.
John Gruber:
Wireless networking is pervasive too. But Apple doesn’t have “a killer wireless networking product”. Wireless networking simply pervades everything Apple makes. I’m hard pressed to think of a single product Apple makes that doesn’t use some combination of Wi-Fi, cellular, Bluetooth, and proprietary wireless protocols. There was a time, not too long ago, when Apple didn’t make a single product with wireless connectivity. Now it’s pervasive in all their devices. That’s more what AI is going to be like. There’s not going to be one “killer AI device”. Everything is going to be an AI device, to some extent, just like how everything today is a wireless connectivity device, to some extent.
I have been arguing AI is a technology and not a product for a while. While wireless technology is a good analogy in the context of a hardware company like Apple, a much more widely applicable analogy would be database (or more generically, storage) technology.
There is hardly a product out there which does not use a database in some form. But we don’t call them “database products” do we? As AI matures, I believe we similarly won’t call every product that uses AI an “AI product”.
In my last post I used the word “clanker” as an alternative to “agent” quite consistently and probably excessively. That choice ended up attracting a lot more attention than I expected in the Hacker News comment section of that post and a number of folks had a very strong reaction: to them it sounded like a slur, in one case even something adjacent to the n-word.
For me “clanker” is useful because it creates distance from the machine and that is a quality which is important to me. The machine is not a person, not a co-worker, not a friend, not a little spirit in the terminal. It is just a machine, a tool, and nothing more.
I wholeheartedly agree with Armin.
From a few weeks ago:
Many people would like to analyse which jobs, companies and industries are most exposed to AI, and assign scores, build charts, and map that against the progress of LLMs. I think this is mostly impossible: you don’t know how the jobs will change, you don’t know what else will change around this, and you can’t measure work like that anyway.
Lots of commentary out there on the impact of AI on jobs, mostly on the lines of “AI will lead to massive job losses” (tch. Dario).
This is a more nuanced take from Evans. It may feel a little unsatisfactory given the crux of the argument is that nobody can predict where this will go (a common theme of much of Evans’ writing), but I strongly believe it’s a very good framework for thinking about this.
Recommended reading. Don’t just take the conclusion, nod, and move on. Developing a deep appreciation for why you should disregard most predictions about AI is important to actually do the said disregarding.
Jordan Lord:
These are the 3 constraints that I use before I start building anything. I'm a believer in constraints as an enabler for creativity. Constraints help us collapse the search space, and figure out innovative solutions to problems.
I've been a builder for 10 years, and I've built products that went nowhere because they were either too complex or had no identity. These are the constraints that I landed on after making those mistakes.
I tend to agree with the author — constraints breed creativity and all that jazz.
I find the second constraint fascinating in particular: “The core tech must be separable from the product.” I’ve been thinking about this in the context of product ideas I’m constantly exploring.
For example, Pi, my favourite coding agent and daily driver has this: the pi-ai package which is similar to Vercel’s AI SDK (abstract access to various models & providers) and pi-agent-core (built on top of pi-ai and provides common constructs to build an agent). OpenClaw is built on the latter, and that played a big role in making Pi popular.
But the truth is that these layoffs, even if they they are not because AI is replacing you, and even if they are some form of AI-washing. These layoffs are still because of AI. And these layoffs will continue till we learn to use AI. Till we learn to convert AI-tokens into outcomes and not just input. Till we learn to re-align the speed of "alignment" with the new speed of coding. And till we figure out, beyond our 2 good and 8 stupid ideas, 10 more ideas that we can chase with our increased productivity.
This is a very refreshing take on the layoffs in large tech companies. It’s the best take I’ve read on this.
Aparna Dhinakaran:
Someone asked me at a hacker event last week: "Can anyone actually tell me what a harness really is?" It was said with real skepticism. The kind of skepticism that says we all use the word "Harness" in the industry, but nobody actually knows what it is.
Fair question. Let me try.
This is a good post and does the important job of defining a term that is getting used increasingly in the context of AI agents.
Perhaps a good addendum would be to define an agent as something that wraps the harness into an app that users interact with. Claude Code is a harness and a coding agent merged into one. Codex cli is a coding agent that builds on the codex-app-server harness. Cursor is also a harness + coding agent, but they are also experimenting with Claude Code as a harness!
T3Code is a coding agent that demonstrates this difference best: it does not ship with its own harness and can instead use Codex, Claude Code, or OpenCode as harnesses.
One exception I take with the linked post is that not every component that it describes as making up a harness is actually necessary in every harness.
As an obvious example, you could very well build an agent without subagents (if you do want subagents, it would have to come in at the harness level as subagents are exposed as tools to the LLM).
So what are the absolute minimal components in a harness? I think it's just the agentic loop. That includes assembling the system prompt, tool definitions, executing the tool calls & assembling the results, etc.
Context management and compaction is not required (it could live outside the harness). Skills are not required. We already talked about subagents. Built-in prepackaged skills should probably not be there in any harness. Lifecycle hooks are nice to have. Session persistence & recovery is optional. So is a permission & safety layer.
Denis Stetskov:
Five to ten years from now, we’ll need senior engineers. People who understand systems end to end, who can debug distributed failures at 2 AM, who carry institutional knowledge that exists nowhere in the codebase. Those engineers don’t exist yet because we’re not creating them. The juniors who should be learning right now are either not being hired or developing what a DoD-funded workforce study calls “AI-mediated competence.” They can prompt an AI. They can’t tell you what the AI got wrong.
Ignore the click-baity title. This is a well-written and well-argued post on how the software industry might be hurtling towards a grim future, the kind of present that the West’s defence industry has found itself in as an unexpected war broke out between Ukraine & Russia.
Thorsten Ball:
Here's what I consider to be the basics. I call them that not because they're easy, but because they're fundamental. The foundation on which your advanced skills and expertise rest. Multipliers and nullifiers, makers and breakers of everything you do.
They don't usually show up in technical books and yet without them a lot of brilliant effort can go to waste. I constantly have to remind myself of them, sitting on my own shoulder and wagging a finger in my face.
What a great set of obvious but seldom articulated things that every developer would do well to go through at some regular interval (because these are easy to forget, especially in this age of agentic engineering).
This is an old post that I discovered through last Sunday's Joy & Curiosity, Thorsten Ball's weekly round up of really wonderful links (a lot of them focused on agentic engineering, given Thorsten is building Amp, which I've heard described as the Porsche of coding agents).
I had come across this old lecture from Richard Hamming before but never watched it. But I had multiple people recommending it on Xitter in just the last day, including Paul Graham. Thorsten Ball (of Amp Code) recommended it in his excellent Joy & Curiosity newsletter today, and I had to watch it.
What an excellent talk covering such a wide array of topics, but all towards an exhortation for how to be great. I watched the entire thing at 1x speed. Yes, it's that good!