Posts

Sean Goedecke:

There are two very different kinds of programming work. The first kind - pure engineering - is interested in solving a technical problem as perfectly as possible. Open-source work is often like this: some engineer wants to write the best HTTP requests library, or their ideal game engine. The second kind - impure engineering - is interested in solving a real-world problem as efficiently as possible. Paid tech company work is often like this: engineers are asked to deliver some project or feature as well as they can do it by the deadline.

In pure software engineering, what you’re doing is close to art or research. It’s close to art because the engineer is driven by an aesthetic sense (e.g. of what makes a good library or game engine). It’s close to research because it’s open-ended: once the engineer arrives at a solution, they can continue testing and tinkering forever, trying (and usually discarding) new approaches.

Impure software engineering is more like plumbing or construction. The engineer’s aesthetic sense is subordinated to someone else’s (usually their employer’s) needs. They’re building a solution to someone else’s problem. And since it’s someone else’s problem, it has to actually be finished to schedule, which means compromising.

Sean Goedecke:

The difference between a “smart” engineer and a “strong” engineer is how they react to problems that aren’t solved instantly. A smart engineer might flail and struggle, hoping to find that flash of insight that eluded them; a strong engineer will have some process for methodically plodding away.

What skill do these smart engineers lack? I think it’s the ability to think slowly and clearly. Smart engineers can think clearly, but they can only think clearly at high speed. Strong engineers can think clearly all the time, even if their highest speed isn’t quite as fast. It’s like the difference between a Formula 1 car and a regular car: Formula 1 cars have a high top speed, but you couldn’t drive them in traffic, because the tyres and brakes don’t work at normal driving speeds.

“smart” engineers and “strong” engineers is really good phrasing and gives vocabulary for something that is otherwise not straightforward to describe.

Dan Moore:

When you have something you want to do and that you feel is in scope for your position, but you want a bit of reassurance or to let the boss know what you are up to, it’s common to reach out and ask them for permission. Don’t. Don’t ask for a yes. Instead, offer a chance to say no, but with a deadline.

The example in the post demonstrates this well. Me likes.

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.

David Oks:

Kyocera was founded in 1959 as a producer of ceramic insulators for cathode-ray tubes; today it manufactures not only industrial ceramics but also printers, smartphones, ballpoint pens, kitchen knives, solar PV modules, lens components, industrial cutting tools, automotive camera modules, electronics components, semiconductor packaging, biocompatible tooth and joint replacements, UV-LED curing systems, LCD systems, medical products, and lab-grown gemstones. Or another e-chuck maker. Sumitomo Osaka Cement, as you might have been able to deduce from the name, produces cement and ready-mixed concrete; but it also produces optical components, measuring instruments, industrial ceramics, artificial marine reefs, cosmetics and nanoparticle materials.

Long fascinating read.

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