libraryofbabel

Exactly. As distributed systems legend Leslie Lamport puts it: “Writing is nature’s way of letting you know how sloppy your thinking is.” (He added: “Mathematics is nature’s way of letting you know how sloppy your writing is.”)

I still have a lot of my best ideas in the shower, no paper and pen, no LLM to talk to. But writing them down is the only way to iron out all the ambiguity and sort out what’s really going to work and what isn’t. LLMs are a step up from that because they give you a ready-made critical audience for your writing that can challenge your assumptions and call out gaps and fuzziness (although as I said in my other comment, make sure you tell them to be critical!)

Thinking is great. I love it. And there are advantages to not involving LLMs too early in your process. But it’s just a first step and you need to write your ideas down and submit them to external scrutiny. Best of all for that is another person who you trust to give you a careful and honest reading, but those people are busy and hard to find. LLMs are a reasonable substitute.

I agree with this. It is an extremely powerful tool when used judiciously. I have always learned and sharpened my ideas best through critical dialog with others. (After two and a half thousand years it may be that we still don't have a better way of teaching than the one Socrates advocated.) But human attention is a scarce resource; even in my job, where I can reasonably ping people for a quick chat or a whiteboard session or fire off some slack messages, I don't want to do that too often. People are busy and you need to pick the right moment and make sure you're getting the most value from their precious time.

No such restriction on LLMs: Opus is available to talk to me day or night and I don't feel bad about sending it half-baked ideas (or about ghosting it half way through the discussion). And LLMs read with an attention to detail that almost no human has the time for; I can't think of anyone who has engaged with my writing quite this closely, with the one exception of my PhD advisor.

LLMs conversations are particularly good for topics outside work where I don't have an easily-available conversational partner at all. Areas of math I want to brush up on. Tricky topics in machine learning outside the scope of what I do in my job. Obscure topics in history or philosophy or aviation. And so on. I've learned so much in the last year this way.

But! It's is an art and it is quite easy to do it badly. You need to prompt the LLM to take a critical stance towards your ideas (in the current world of Opus 4.5 and Gemini 3, sycophancy isn't as much of a problem as it was, but LLMs still can be overly oriented to please). And you need to take a critical stance yourself. Interrogate its answers, and push it to clarify points that aren't obvious. Sometimes you learn something new, sometimes you expose fuzziness in the LLM's description (in which case it will usually give you the concept at a deeper level). Sometimes in the back-and-forth you realize you forgot to give it some critical piece of context, and when you do that it reframes the whole discussion.

I see plenty of examples of people just taking LLM's answers at face value like it's some kind of oracle (and I'm sure the comments here will contain many negative anecdotes like that). You can't do that; you need to engage and try and chip away at its position and come to some synthesis. The nice thing is the LLM won't mind having its ideas rigorously interrogated, which is something humans can be touchy about (though not always, and the most productive human collaborations are usually ones where both people can criticize each other's ideas freely).

For better or for worse, the people who will do best in this world are those with a rigorously critical mindset and an ability to communicate well, especially in writing. (If you're in college, consider throwing in a minor in philosophy or history alongside that CompSci major!) Those were already valuable skills, and they have even more leverage now.

Devin? Now that's a name I've not heard in a long time...a lonnng time.

Seriously, in this age of Claude Code and Codex, does anyone use Devin, or even know someone who does? Do they have any users at all?

Ironically, their product has probably got massively better in the last couple of years, because the underlying LLMs got massively better at coding and long-context tasks. But that doth not a successful business model make, and unless you’re Cursor (and even then I’m not so sure) this is a very very hard space to succeed in without owning your own frontier model (i.e being Anthropic, OpenAI, or Google).

This rings true and reminds me of the classic blog post “Reality Has A Surprising Amount Of Detail”[0] that occasionally gets reposted here.

Going back and forth on the detail in requirements and mapping it to the details of technical implementation (and then dealing with the endless emergent details of actually running the thing in production on real hardware on the real internet with real messy users actually using it) is 90% of what’s hard about professional software engineering.

It’s also what separates professional engineering from things like the toy leetcode problems on a whiteboard that many of us love to hate. Those are hard in a different way, but LLMs can do them on their own better than humans now. Not so for the other stuff.

[0] http://johnsalvatier.org/blog/2017/reality-has-a-surprising-...

I was also curious about this quote, and it sounded to me too like Donne (or Pascal or Robert Boyle, a bit).

But Gemini 3.0 knew what it was, and it is from Omar Khayyám like the sibling commenter said, but from the little-known E. H. Whinfield translation (1883) rather than the more famous Fitzgerald one:

—-

221. (395.)

Such as I am, Thy power created me,

Thy care hath kept me for a century!

Through all these years I make experiment,

If my sins or Thy mercy greater be.

——-

Link to the actual page in Google books:

https://books.google.co.uk/books?id=NN_TAAAAMAAJ&q=Experimen...

Question for the well-informed people reading this thread: do SoTA models like Opus, Gemini and friends actually need output schema enforcement still, or has all the the RLVR training they do on generating code and json etc. made schema errors vanishingly unlikely? Because as a user of those models, they almost never make syntax mistakes in generating json and code; perhaps they still do output schema enforcement for "internal" things like tool call schemas though? I would just be surprised if it was actually catching that many errors. Maybe once in a while; LLMs are probabilistic after all.

(I get why you need structured generation for smaller LLMs, that makes sense.)

Then what sort of math problem would be a milestone for you where an AI was doing something novel?

Or are you just saying that solving novel problems involves remixing ideas? Well, that's true for human problem solving too.

2026 should be interesting. This stuff is not magic, and progress is always going to be gradual with solutions to less interesting or "easier" problems first, but I think we're going to see more milestones like this with AI able to chip away around the edges of unsolved mathematics. Of course, that will require a lot of human expertise too: even this one was only "solved more or less autonomously by AI (after some feedback from an initial attempt)".

People are still going to be moving the goalposts on this and claiming it's not all that impressive or that the solution must have been in the training data or something, but at this point that's kind of dubiously close to arguing that Terence Tao doesn't know what he's talking about, which to say the least is a rather perilous position.

At this point, I think I'm making a belated New Years resolution to stop arguing with people who are still staying that LLMs are stochastic parrots that just remix their training data and can never come up with anything novel. I think that discussion is now dead. There are lots of fascinating issues to work out with how we can best apply LLMs to interesting problems (or get them to write good code), but to even start solving those issues you have to at least accept that they are at least somewhat capable of doing novel things.

In 2023 I would have bet hard against us getting to this point ("there's no way chatbots can actually reason their way through novel math!"), but here we are are three years later. I wonder what comes next?

Not to mention instrumental in getting the Manhattan Project going, along with many other research projects during WWII. He basically knew everyone. I didn't know he was Shannon’s advisor though!

But it’s not really an argument, it’s a statement about feelings. Some people really do prefer coding with AI. Is that so strange? Often we’ve spent 1 or 2 decades writing code and in our day jobs we don’t see a lot of novel problems come our way at the level of the code anymore (architecture, sure, still often novel). We’ve seen N number of variations on the same thing; we are good at doing them but get little joy in doing them for the N + 1th time. We find typing out api serializers and for loops and function definitions and yaml boilerplate just a little boring, if we already have a picture in our head of what we want to do. And we like being able to build faster and ship to our users without spending hours and extra brain cycles dealing with low-level complexity that could be avoided.

I am happy to accept that some people still prefer to write out their code by hand… that’s ok? Keep doing it if you want! But I would gently suggest you ask yourself why you are so offended by people that would prefer to automate much of that, because you seem to be offended. Or am I misreading?

And hey, I still enjoy solving interesting problems with code. I did advent of code this year with no LLM assistance and it was great fun. But most professional software development doesn’t have that novelty value where you get to think about algorithms and combinatorical puzzles and graphs and so on.

Before anyone says it, sure, there is a discussion to be had about AI code quality and the negative effects of all this. A bad engineer can use it to ship slop to production. Nobody is denying that. But I think that’s a separate set of questions.

Finally, I’m not sure painting is the best analogy. Most of us are not creating works of high art here. It’s a job, to make things for people to use, more akin to building houses than painting the Sistine Chapel. Please don’t sneer at use if we enjoy finding ways to put up our drywall quicker.

Hi! Thanks again for writing that first Emperor Has No Clothes blog post; like I said, it really inspired me and made everything click early on when I was first dipping my toes into the world of agents. Whenever I teach this stuff to other engineers, I often think back to that moment of realizing exactly how the exchange between LLM, tool call requests, tool functions, and agent code works and I try to get that across as the central takeaway. These days I usually add diagrams to get really clear on what happens on which side of the model api.

I do wonder whether the path here was:

1) You wrote the article in April 2025

2) The next generation of LLMs trained on your article

3) The author of TFA had a similar idea, and heavily used LLMs to help write the code and the article, including asking the LLM to think of a catchy title. And guess what title the LLM comes up with?

There are also less charitable interpretations, of course. But I'd rather assume this was honestly, if sloppily, done.

You're correct that the culture of mathematics has changed a lot, and has become much more collaborative. The rise of the modern doctoral training system in Germany later in the 19th century is also relevant. So really Gauss's example points primarily to how much mathematics has changed. But at the same time, I think you could reasonably take Gauss to task even applying the standards of his own era - compare him with Euler, for example, who was much more open with publication and generous with his time and insights, frequently responding to letters from random people asking him mathematical questions, rather like Tao responding to random comments on his blog (which he does). I admire Euler more, and he was born 70 years before Gauss.

Of course, irascible brilliance and eccentricity has an honorable place in mathematics too - I don't want to exclude anyone. (Think Grigori Perelman and any number of other examples!)

One of the things I admire about many top mathematicians today like Terence Tao is that they are clearly excellent mentors to a long list of smart graduate students and are able to advance mathematics through their students as well as on their own. You can imagine a half-formed thought Terence Tao has while driving to work becoming a whole dissertation or series of papers if he throws it to the right person to work on.

In contrast, Gauss disliked teaching and also tended to hoard those good ideas until he could go through all the details and publish them in the way he wanted. Which is a little silly, as after a while he was already widely considered the best mathematician in the world and had no need to prove anything to anyone - why not share those half-finished good ideas like Fast Fourier Transforms and let others work on them! One of the best mathematicians who ever lived, but definitely not my favorite role model for how to work.

Agree, the RLVR tasks are probably long series of tool calls at this point doing complex tasks in some simulated dev environment.

That said, I think it's hard to say how much of a difference it really makes in terms of making Claude Code specifically better than other coding agents using the same LLM (versus just making the LLM better for all coding agents using roughly similar tools). There is probably some difference, but you'd need to run a lot of benchmarks to find out.

This is a great point, although I would add that Anthropic has a possible slight advantage, as they can RLVR the Claude LLMs themselves on Claude Code tool calls and Claude Code tasks. Having said that, it's not clear how much that really matters at all for making the Claude Code CLI specifically better-performing than other coding agents using the same LLM (the tool calls are fairly generic and the LLMs are good at plenty of tool calls they weren't RLVRed on too).

The other advantage Anthropic have is just that they can sell CC subscriptions at lower cost because they own the models. But that's a separate set of questions that don't really relate to technical capabilities.

Anyhow, to follow up on your point, I do find it surprising that Claude Code is still (it seems?) definitively leading the pack in terms of coding agents. I've tried Gemini CLI and Codex and they feel distinctly less good, but I'm surprised we haven't seen too many alternatives from small startups or open source projects rise to the top as well. After all, they can build on all the lessons learned from previous agents (UX, context management, features people like such as Skills etc.). Maybe we will see more of this in 2026.

Yeah, there is definitely some RLVR training going on for the Claude LLMs to get them good at some of the specific tool calls used in Claude Code, I expect. Having said that, the string replacement tool schema for file edits is not very complicated at all (you can see it in the tool call schema Claude Code sends to the LLM), so you could easily use that in your own 200-300 line agent if you wanted to make sure you're playing to the LLM's strengths.

It's in TFA or in the https://ampcode.com/how-to-build-an-agent article I linked? Or is that not what you're looking for?

It's a great point and everyone should know it: the core of a coding agent is really simple, it's a loop with tool calling.

Having said that, I think if you're going to write an article like this and call it "The Emperor Has No Clothes: How to Code Claude Code in 200 Lines of Code", you should at least include a reference to Thorsten Ball's excellent article from wayyy back in April 2025 entitled "How to Build an Agent, or: The Emperor Has No Clothes" (https://ampcode.com/how-to-build-an-agent)! That was (as far as I know) the first of these articles making the point that the core of a coding agent is actually quite simple (and all the deep complexity is in the LLM). Reading it was a light-bulb moment for me.

FWIW, I agree with other commenters here that you do need quite a bit of additional scaffolding (like TODOs and much more) to make modern agents work well. And Claude Code itself is a fairly complex piece of software with a lot of settings, hooks, plugins, UI features, etc. Although I would add that once you have a minimal coding agent loop in place, you can get it to bootstrap its own code and add those things! That is a fun and slightly weird thing to try.

(By the way, the "January 2025" date on this article is clearly a typo for 2026, as Claude Code didn't exist a year ago and it includes use of the claude-sonnet-4-20250514 model from May.)

Edit: and if you're interested in diving deeper into what Claude Code itself is doing under the hood, a good tool to understand it is "claude-trace" (https://github.com/badlogic/lemmy/tree/main/apps/claude-trac...). You can use it to see the whole dance with tool calls and the LLM: every call out to the LLM and the LLM's responses, the LLM's tool call invocations and the responses from the agent to the LLM when tools run, etc. When Claude Skills came out I used this to confirm my guess about how they worked (they're a tool call with all the short skill descriptions stuffed into the tool description base prompt). Reading the base prompt is also interesting. (Among other things, they explicitly tell it not to use emoji, which tracks as when I wrote my own agent it was indeed very emoji-prone.)

There’s Grouped Query Attention as well, a different activation function, and a bunch of not very interesting norms stuff. But yeah, you’re right - still very similar overall.

Thanks! Good to know I’m not missing something here. And yeah, it’s always just seemed to me better to frame it as: let’s find a mathematical structure to relate every embedding vector in a sequence to every other vector, and let’s throw in a bunch of linear projections so that there are lots of parameters to learn during training to make the relationship structure model things from language, concepts, code, whatever.

I’ll have to read up on merged attention, I haven’t got that far yet!

This is really useful, thanks. In my other (top-level) comment, I mentioned some vague dissatisfactions around how in explanations of attention the Q, K, V matrices always seem to be pulled out of a hat after being motivated in a hand-wavy metaphorical way. The kernel methods treatment looks much more mathematically general and clean - although for that reason maybe less approachable without a math background. But as a recovering applied mathematician ultimately I much prefer a "here is a general form, now let's make some clear assumptions to make it specific" to a "here's some random matrices you have to combine in a particular way by murky analogy to human attention and databases."

I'll make a note to read up on kernels some more. Do you have any other reading recommendations for doing that?

Sure! I don't think the linear algebra pre-req is that hard if you do need to learn it, there's tons of material online to practice on and it's really just basic "apply this matrix to this vector" stuff. Most of what would be in even an undergrad intro to linear algebra course (inverting a matrix, determinants, whatever) is totally unnecessary.

Oh yes! That's probably more important, in fact.

It helps if you have some basic linear algebra, for sure - matrices, vectors, etc. That's probably the most important thing. You don't need to know pytorch, which is introduced in the book as needed and in an appendix. If you want to really understand the chapters on pre-training and fine-tuning you'll need to know a bit of machine learning (like a basic grasp of loss functions and gradient descent and backpropagation - it's sort of explained in the book but I don't think I'd have understood it much without having trained basic neural networks before), but that is not required so much for the earlier chapters on the architecture, e.g. how the attention mechanism works with Q, K, V as discussed in this article.

The best part about it is seeing the code built up for the GPT-2 architecture in basic pytorch, and then loading in the real GPT-2 weights and they actually work! So it's great for learning but also quite realistic. It's LLM architecture from a few years ago (to keep it approachable), but Sebastian has some great more advanced material on modern LLM architectures (which aren't that different) on his website and in the github repo: e.g. he has a whole article on implementing the Qwen3 architecture from scratch.

This is ok (could use some diagrams!), but I don't think anyone coming to this for the first time will be able to use it to really teach themselves the LLM attention mechanism. It's a hard topic and requires two or three book chapters at least if you really want to start grokking it!

For anyone serious about coming to grips with this stuff, I would strongly recommend Sebastian Raschka's excellent book Build a Large Language Model (From Scratch), which I just finished reading. It's approachable and also detailed.

As an aside, does anyone else find the whole "database lookup" motivation for QKV kind of confusing? (in the article, "Query (Q): What am I looking for? Key (K): What do I contain? Value (V): What information do I actually hold?"). I've never really got it and I just switched to thinking of QKV as a way to construct a fairly general series of linear algebra transformations on the input of a sequence of token embedding vectors x that is quadratic in x and ensures that every token can relate to every other token in the NxN attention matrix. After all, the actual contents and "meaning" of QKV are very opaque: the weights that are used to construct them are learned during training. Furthermore, there is a lot of symmetry between Q and K in the algebra, which gets broken only by the causal mask. Or do people find this motivation useful and meaningful in some deeper way? What am I missing?

[edit: on this last question, the article on "Attention is just Kernel Smoothing" that roadside_picnic posted below looks really interesting in terms of giving a clean generalized mathematical approach to this, and also affirms that I'm not completely off the mark by being a bit suspicious about the whole hand-wavy "database lookup" Queries/Keys/Values interpretation]

Although interestingly, as that wikipedia article also points out, people did go down into the 40s quite a bit during the Age of Sail (the famous clipper route), because the strong prevailing winds meant it was the fastest way to get around the world. This comes up quite often in the Aubrey-Maturin novels by Patrick O'Brian.

If you're not a sailing ship, you don't benefit from the winds, so those latitudes are pretty empty nowadays.

This is weirdly beautiful, like the maps of undersea internet cables that frequently come up here as well.

You can clearly see:

1) oil flowing out of the Persian Gulf from the Middle East to China

2) ships waiting to get through the Panama and Suez Canals

3) why people talk about “shipping lanes”. There are some obvious tracks everyone follows, because it’s the cheapest way from A to B (e.g. cape of good hope to straight of malacca).

4) why Singapore got to be such an important global hub.

5) why the houthis and the Somali pirates could cause such havoc

6) nobody goes in the southern ocean! (Why would they? Unless you’re bringing supplies to Antarctica…) a few ships drop down to go around Cape Horn but that’s it.

and so much more. I wish it included more up-to-date data…

Right. And same for railways, which had a huge bubble early on. Over-hyped on the short time horizon. Long term, they were transformative in the end, although most of the early companies and early investors didn’t reap the eventual profits.

Thanks for posting this. It's a nice reminder that despite all the noise from hype-mongers and skeptics in the past few years, most of us here are just trying to figure this all out with an open mind and are ready to change our opinions when the facts change. And a lot of people in the industry that I respect on HN or elsewhere have changed their minds about this stuff in the last year, having previously been quite justifiably skeptical. We're not in 2023 anymore.

If you were someone saying at the start of 2025 "this is a flash in the pan and a bunch of hype, it's not going to fundamentally change how we write code", that was still a reasonable belief to hold back then. At the start of 2026 that position is basically untenable: it's just burying your head in the sand and wishing for AI to go away. If you're someone who still holds it you really really need to download Claude Code and set it to Opus and start trying it with an open mind: I don't know what else to tell you. So now the question has shifted from whether this is going to transform our profession (it is), to how exactly it's going to play out. I personally don't think we will be replacing human engineers anytime soon ("coders", maybe!), but I'm prepared to change my mind on that too if the facts change. We'll see.

I was a fellow mind-changer, although it was back around the first half of last year when Claude Code was good enough to do things for me in a mature codebase under supervision. It clearly still had a long way to go but it was at that tipping point from "not really useful" to "useful". But Opus 4.5 is something different - I don't feel I have to keep pulling it back on track in quite the way I used to with Sonnet 3.7, 4, even Sonnet 4.5.

For the record, I still think we're in a bubble. AI companies are overvalued. But that's a separate question from whether this is going to change the software development profession.

Well of course, and the book digs a little into the history as well, and what changed around the 1960s/70s. There is a long section on Robert Moses, for example. He draws a lot of parallels between modern China and the US in the 19th and early 20th centuries - totally different political systems, but similar “breakneck” ability to build.