Tagged: ai

Luke Kuzmish:

I don’t know if people were always saying “it’s not X, it’s Y,” but I’m hyper-aware of it. When I see it, I assume it was written by AI. I am starting to look for the fingerprints of LLM generated text everywhere. It’s exhausting to be suspicious all the time.

Whether I write the code myself or an agent does, having two separate models review the code has been a win, hands down. Remember, both AI and humans are sometimes bad at code. Multi-model code reviews add more Swiss cheese to the process.

Many such truisms in this post. I agree with a lot—but not all—of them.

Max Leiter:

"They're made out of weights."

"Weights?"

"Weights. Floating-point numbers. We checked the whole thing through. It's nothing but weights."

"Weights doing what? Where do the words come from?"

"The weights make the words. Are you understanding me? We opened it up. There's no dictionary in there, no grammar rules, no little man. Just weights. Eighty layers of numbers getting multiplied together."

…

Beautiful. Maybe I’ll call ‘em weights instead of clankers.

Steven (Batman) Batchelor-Manning:

I've been down the rabbit hole on how memory reaches the model for a while now. The assumption I kept running into, before this research, was that the hard part of agent memory was retrieval quality. Get the right chunks, the thinking goes, and the rest is plumbing.

That assumption is half right. Retrieval quality matters. But the mechanism that delivers those chunks to the model matters more, and the field has quietly reversed its position on it without most people noticing. The mature systems have all converged on the same shape: the agent is given memory tools, and the agent decides when and how to use them. The middleware is no longer a predictor of what the agent needs. It's a service the agent calls.

The first part of this post is about how the world has moved from RAG to tools for giving relevant context to the agent. While this has been described in reference to memory systems, it's more broadly applicable.

Of the 19 systems I went through, the mature ones have all converged on this shape. Supermemory, Graymatter, OpenContext, Tolaria, second-brain, MemoryOS, GitNexus, mem9 all expose memory as a tool surface rather than as automatic injection. The systems that do something closer to injection are the ones the field treats as the prior state of the art, not the current one.

The second part compares and contrasts several memory systems. I hadn't heard of most of these, and having these listed at one place is itself valuable. The choices made by the different systems are also quite fascinating.

Footnote: The post feels like it was written (or heavily edited) by AI. It's valuable nevertheless.

Om Malik:

Lately there has been a lot of talk of how the foundational models are quickly becoming like every other iPhone release. They are ho-hum, till the next one comes around. But it is not the right analogy. I have a more boring, and more accurate, analogy that will explain the growth so far, and how it will evolve.

I have been fortunate enough to have been involved with the last five cycles of technology. As a result, I have been able to see patterns in the history of technology. It doesn’t matter what the technology is – we go from shock and awe to ho-hum, go-to-work. A technology eventually becomes invisible to us.

This is so counter-intuitive to me.

Om is arguing here that the arc of AI capability is going to be more like that of broadband capacity (which continually but silently increased over the last 30 or so years) and less like CPU or smartphones (where there have been very visible improvements that eventually plateaued out). He is clearly zagging where everyone else is zigging.

Like I said, counter-intuitive. Recommended reading.

Thorsten Ball:

But here’s the very important bit, the one bit I want you to take with you into this week: there is no way in hell, absolutely zero chance, that you can build something new and avoid bumping into “that’s not what I meant”, or “now that I’m working on it I’m not actually sure”, or “hmm, now that I use it, I don’t like it”. Because the only way you could avoid that would be to fully specify what you want up front and, well, guess what programming is? It’s fully specifying what you want. You can’t avoid it, because you can’t define it yet, because building software is learning!

What exactly you do doesn’t matter as much as constantly asking: how can I get feedback on what I’m trying to build as soon as possible? And “feedback” here is used in the widest sense possible. Feedback comes in all shapes and sizes: feedback from the CI system on main, feedback from colleagues, feedback from users, feedback from you once you actually use it.

So good. So, so good. Recommended reading.

The quotes may make it sound obvious: who doesn’t agree with “get early feedback”? But it is one thing to intellectually understand it, and a totally different thing to feel it viscerally.

As I started reading this, I was thinking that we at udaan do this almost as a habit; even the business folks think & act this way, not just the tech team. But as I finished reading and reflected, I felt that no, we don’t actually do enough of it. We can do more, we can do better, and this is one good way in which AI can enable us.

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”.

Armin Ronacher:

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:

Benedict Evans:

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.

Arnav Gupta:

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.