Posts

Sean Goedecke:

My guess is that people who work on small codebases with low-turnover teams (say, Redis or games like The Witness) would say “obviously you have to understand it completely, otherwise you can’t do good work”. I’d also guess that people who work on large codebases with high-turnover teams (say, the Google web search backend or GitHub) would say “obviously you can’t understand it completely, you just have to do the best you can in your local area”.

These are two largely different ways of programming with different methods, practices and cultures. However, the first group is over-represented in online discussion about software engineering. I want to defend the second group against the first. In many software engineering environments, there’s nothing wrong with being in a state of partial understanding. In fact, in large systems a partial understanding is the best you can do.

I'm becoming a fan of this Sean Goedecke. Such good writing. No fluff at all. Read the entire post—it's well argued.

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.

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.