gnat

I'd love to know if people are using CEL, and what for. Any war stories to share?

LA Metro: Ambient turns the Los Angeles rail network into a generative music instrument. Every note you hear is a real train arriving at a real station right now. Each of the six rail lines and two BRT lines has its own synthesizer voice. The piece evolves throughout the day as trains and buses come online and go offline, becoming dense during rush hour and more spacious late at night. The piece is ever changing and no two days are the same.

I haven’t dropped an agent into production yet. This is all internal / PoC work.

Claude / your favourite LLM coding agent can help you design this and will be good at helping you unpack risks and hazards. Good luck!

I’m dealing with invoices and customers and timesheets and tickets. I didn’t want to give an agent SQL access to the database for performance and security reasons, and we don’t have a read only replica (which would have been much more acceptable to give read access to). So my tools are get_invoices etc. and they pull data into the SQLite.

My use case is a short conversation to answer a question like “has all the time from this task been invoiced?” Or “what contributed to the size of this invoice!”. So my agent starts with empty SQLite, fetches the data into SQLite, writes queries to answer the question, then user can continue to interrogate but eventually shuts down.

I don’t have a perpetually running agent so I haven’t had to solve that problem.

What could go wrong? Delete production data. Corrupt production data. Show staff member info they shouldn’t have. Show customer info they shouldn’t have. Rely too much on the LLM doing the right thing, it doesn’t, and the agent presents the wrong information without knowing. Bugger up the security and anyone can use the agent to query production data. … Yeah, be cautious.

Fast is probably going to get in the way of Good, but here are some things to think about.

1. In many businesses, different users of the agent should have different read/write permissions to data.

2. Log everything. There will be problems. You'll need to debug, attribute, defend yourself against accusations that the cockup was your fault, etc.

3. If you're just providing read-only then the more you can enforce that at all layers of the stack (e.g., read-only user in the database).

4. Don't give the agent direct SQL access to the database. Write functions in your favourite programming language, expose them as tools to the LLM.

5. Don't make your LLM do maths in its head, they're crap at it. I had some success giving the agent tools that fetch data from the database (where I control the SQL that runs) into a SQLite in agent memory, then the agent can run SQL against that database. Gives you a chance to put the data into an obvious, easy to query, format rather than whatever arcane historic chaotic state your main schema has evolved to).

Nice! Claude and I made something for my use called 'azdo' that's the 'gh' CLI but for Azure DevOps. I figured agents know how to use gh, so give them what they know. I haven't yet tried aliasing so they don't (at first) know it's Azure DevOps but that's coming ...

I like it a lot. AND it has MCP server so I can point my agent at it to search and research. Very impressive.

Being able to mange context over long running sessions is a function of the harness, not the model. Are you using Claude Code with GPT5.5? Codex? piclaw? They’ll all have different context management strategies to let you keep going when you would otherwise have filled up context and be forced to stop.

This repo's README explains how it works and you can do it yourself. claude looks for environment variables that say which API endpoint to talk to, which key to pass, which model name to use for haiku/sonnet/opus-level workloads, etc.

Forgot to add: I get several benefits from doing this.

1. Specifications that live outside the code. We have a lot of code for which "what should this do?" is a subjective answer, because "what was this written to do?" is either oral legend or lost in time. As future Claude sessions add new features, this is how Claude can remember what was intentional in the existing code and what were accidents of implementation. And they're useful for documenters, support, etc.

2. Specifications that stay up to date as code is written. No spec survives first contact with the enemy (implementation in the real world). "Huh, there are TWO statuses for Missing orders, but we wrote this assuming just one. How do we display them? Which are we setting or is it configurable?" etc. Implementer finds things the specifier got wrong about reality, things the specifier missed that need to be specified/decided, and testing finds what they both missed.

I have a colleague working on saving architecture decisions, and his description of it feels like a higher-abstraction version of my saving and maintaining requirements.

Nice! Your spec-maxxing is very resonant. I've been doing working with explicit requirements: elicit them from conversation with me or introspecting another piece of software; one-shot from them; and keep them up-to-date as I do the "old man shouts at Claude" iterations after whatever one-shotting came up with.

Unlike you, I wish for the LLM to do as much of the work as possible -- but "as possible" is doing a lot of work in that sentence. I'm still trying to get clear on exactly where I am needed and where Opus and iterations will get there eventually.

It has really challenged me to get clearer on what a requirement is vs a constraint (e.g., "you don't get to reinvent the database schema, we're building part of a larger system"). And I still battle with when and how to specify UI behaviours: so much UI is implicit, and it seems quite daunting to have to specify so much to get it working. I have new respect for whoever wrote the undoubtedly bajillion tests for Flutter and other UI toolkits.

I'm not trying to convert you, just want to share process tips that I see working for me and others. We're using agents, not a chat, because they can do complex work in pursuit of a goal.

1. Make artifacts. If you're doing research into a tech, or a hypothesis, then fire off subagents to explore different parts of the problem space, each reporting back into a doc. Then another agent synthesizes the docs into a conclusion/report.

2. Require citations. "Use these trusted sources. Cite trusted sources for each claim. Cite with enough context that it's clear your citations supports the claim, and refuse to cite if the citation doesn't support the claim."

3. Review. This lets you then fire off a subagent to review the synthesis. It can have its own prompt: look for confirming and disconfirming evidence, don't trust uncited claims. If you find it making conflation mistakes, figure out at what stage and why, and adjust your process to get in front of them.

4. Manage your context. LLM only has a fixed context size ("chat length") and facts & instructions at the front of that tend to be better hewn to than things at the end. Subagents are a way of managing that context to get more from a single run. Artifacts like notebooks or records of subagent output move content outside the context so you can pick up in a new session ("chat") and continue the work.

It's less fun that just having a chat with ChatGPT. I find that I get much better quality results using these techniques. Hope this helps! If you're not interested in doing this (too much like work, and you already have something that works), it's no skin off my nose. All the best!

We're in the brief window of time when AI's writing style is the weirdness. It's an artifact of the production process, like JPG blur, MP3 distortion, autotune's rigidity. And it didn't take long for those things to become normalized, in fact for them to become artifacts that people proudly adopted and embraced. DJs release tracks built from MP3s samples instead of waves. Autotune is famously a 'sound' that was once something to be subtly added and never confessed to, but which now genres and artists lean into rather than away from.

Long story short: I think emoji in headings and lists, em dashes, and the vile TED Talk paragraph structure of "long sentence with lots of words asking a question or introducing a possibility. followed by. short sentences. rebutting. or affirming." are here to stay. My money is that it gets normalized and embraced as "well of course that's how you best communicate because I see it everywhere."

https://archive.is/2026.01.24-103304/https://www.nytimes.com...

(Hi, Tom!) Reread the article and look for “CPU”. The whole article is about doing deep learning on CPUs not GPUs. Moonshine, the open source project and startup he talks about, shows speech recognition and realtime translation on the device rather than on a server. My understanding is that doing The Math in parallel is itself a performance hack, but Doing Less Math is also a performance hack.

What have you done to make Claude stronger on brownfields work? This is very interesting to me.

I hate its acknowledgement of its personality prompt. Try having a series of back and forth and each response is like “got it, keeping it short and professional. Yes, there are only seven deadly sins.” You get more prompt performance than answer.

Tl;Dr: ThoughtWorks founder is spending his millions portraying Chinese government policies, including Xinjian/Uighurs, in a positive light. His spending his heavily laundered but he’s now based in China, and working in the same offices as a propaganda company.

Calendar was brilliant. I think it was the first time I fully appreciated the misery of the human mind in the face of various orbit periods that aren't simple integer ratios of one another. https://www.bbc.co.uk/programmes/p00548m9

Great Fire of London too. Pepys burying his cheese! https://www.bbc.co.uk/programmes/b00ft63q

Politeness. Social barriers were coming down, you were interacting with people of different rank, how do you not get into a swordfight? Also, the letter from the wife complaining about her husband! https://www.bbc.co.uk/programmes/p004y29m

I think they did all the big interesting things in history and then struggled with a lot of minor events that were hard to find interesting angles on.

Thank you! Worth reading, if only for the phrase “global taint ruler”.

Are you two talking at cross-purposes because you don't have a shared understanding of control and data flow?

The pieces here are:

* Claude Code, a Node (Javascript) application that talks to MCP server(s) and the Claude API

* The MCP server, which exposes some tools through stdin or HTTP

* The Claude API, which is more structured than "text in, text out".

* The Claude LLM behind the API, which generates a response to a given prompt

Claude Code is a Node application. CC is configured in JSON with a list of MCP servers. When CC starts up, CC"s Javascript initialises each server and as part of that gets a list of callable functions.

When CC calls the LLM API with a user's request, it's not just "here is the user's words, do it". There are multiple slots in the request object, one of which is a "tools" block, a list of the tools that can be called. Inside the API, I imagine this is packaged into a prefix context string like "you have access to the following tools: tool(args) ...". The LLM API probably has a bunch of prompts it runs through (figure out what type of request the user has made, maybe using different prompts to make different types of plan, etc.) and somewhere along the way the LLM might respond with a request to call a tool.

The LLM API call then returns the tool call request to CC, in a structured "tool_use" block separate from the freetext "hey good news, you asked a question and got this response". The structured block means "the LLM wants to call this tool."

CC's JS then calls the server with the tool request and gets the response. It validates the response (e.g., JSON schemas) and then calls the LLM API again bundling up the success/failure of the tool call into a structured "tool_result" block. If it validated and was successful, the LLM gets to see the MCP server's response. If it failed to validate, the LLM gets to see that it failed and what the error message was (so the LLM can try again in a different way).

The idea is that if a tool call is supposed to return a CarMakeModel string ("Toyota Tercel") and instead returns an int (42), JSON Schemas can catch this. The client validates the server's response against the schema, and calls the LLM API with

  {
    "type": "tool_result",
    "tool_use_id": "abc123",
    "is_error": true,
    "content": [
      {
        "type": "text",
        "text": "Expected string, got integer."
      }
    ]
  }

There are plenty of ways for this to go wrong: the client (Claude Code) has to validate; int vs string isn't the same as "is a valid timestamp/CarMakeModel/etc"; if you helpfully put the thing that failed into the error message ("Expect string, got integer (42)") then the LLM gets 42 and might choose to interpret that as a CarMakeModel if it's having a particularly bad day; the LLM might say "well, that didn't work, but let's assume the answer was Toyota Tercel, a common car make and model", ... We're reaching here, yet these are possible.

But the basic flow has validation done in deterministic code and hiding the MCP server's invalid responses from the LLM. The LLM can't choose not to validate. You seemed to be saying that the LLM could choose not to validate, and your interlocutor was saying that was not the case.

I hope this helps!

The newsletter this is from is full of very clear writing about SQL, practically applying theory without getting lost in a tangle of database theory jargon. If you need to read or write SQL then I think you’ll find it as interesting as I have.

From the excellent "Why Nations Fail" by Daron Acemoglu and James A. Robinson:

An example of what could happen if you took your job too seriously, rather than successfully second-guessing what the Communist Party wanted, is provided by the Soviet census of 1937. As the returns came in, it became clear that they would show a population of about 162 million, far less than the 180 million Stalin had anticipated and indeed below the figure of 168 million that Stalin himself announced in 1934. The 1937 census was the first conducted since 1926, and therefore the first one that followed the mass famines and purges of the early 1930s. The accurate population numbers reflected this. Stalin's response was to have those who organized the census arrested and sent to Siberia or shot. He ordered another census, which took place in 1939. This time the organizers got it right; they found that the population was actually 171 million.

Thanks for that. https://archive.is/84YPk for folks without a Bloomberg subscription.

The jobs data comes from surveys of businesses and consumers. Fewer of each category are responding, continuing a long-term trend of declining response rates. Cuts affect their ability to collect data with about 15% of the sample "suspended" -- i.e. not done "to align survey workload with resource levels" in the words of the announcement linked from the Bloomberg article.

"The more data you’re missing and comes in later, the higher the odds the revisions will be much larger," said Omair Sharif, president of Inflation Insights LLC. "Fifty percent is just not enough."

I find the best comments here to be ones where people use their knowledge and experience to discuss the relative strengths and weaknesses of the technology in the post. I see a bunch of short single-sentence comments here that add no value.

For my part, I see this pattern repeatedly at different places. The raw tools in the platforms are too codey and the third-party frameworks like Temporal seem overkill, so you build a scheduler and need to solve the problems OP did: only run once, know if it errored, etc.

But it's amazing how "it's firing off a basic action!" becomes a script, then becomes a script composed of reusable actions that can pick up where they left off in case of errors ... Over time your "it's just enough for us!" feature creeps towards the framework's functionality.

I'd be curious to know how long the OP's solution stays simple before it submits to the feature creep demands. (Long may complexity be fought off, though! Every day you can live without the complexity of full workflows is a blessing)

It tracks operating system calls and creates a package that contains all the binaries, files and dependencies required to run a given command on the author's computational environment (packing step). A reviewer can then extract the experiment in his environment to reproduce the results (unpacking step).

Vagrant and Docker behind the scenes. Very cool, and a welcome step up from a tarball.

I can't speak to tornado warnings, but here in NZ we've been getting tsunami warnings once every year or two and it didn't take long for people to go "yeah yeah yeah" instead of "oh crap".

Ugh. Each of these points is a classic reliability precaution – yet all were missed simultaneously. As one analyst put it, Google had “written the book on Site Reliability Engineering” but still deployed code that could not handle null inputs. In hindsight, this outage looks like a string of simple errors aligning by unfortunate chance.

Yes, that's how major outages happen. By this stage of maturity any single failure generally doesn't break things dramatically. When things go this wrong, it's ALWAYS a combination of failures: failure of recovery system, omission in detection systems, gap in automated review, oversight in ...

The vacuous gotcha language is indicative of the low quality of the whole article. As Metalnem says in comments here, see the official incident report for a better writeup and more insight. https://status.cloud.google.com/incidents/ow5i3PPK96RduMcb1S...

https://archive.is/2025.06.21-100511/https://www.wsj.com/tec...

"I definitely wouldn't want my dentist to take a risky moonshot in pursuit of excellence". Excellent comment.

I was aware as I was writing it that consistent mediocrity is indeed a profitable target. Perhaps we're quibbling over "mediocrity"? Staying within the spec seems enough of the challenge for a grid, I'm not sure that I'd define excellence as narrower and narrower variation around the spec there.

I was making a moral judgement in "unworthy". I like cars to come off the factory floor consistently good. I own a Tesla, this statement has high salience for me. That seems like a challenge. I wouldn't respect the Lada factory for consistently turning out cars that break down or fall apart, just as I don't respect McDonalds for consistently delivering underwhelming food. I acknowledge the consistency, I acknowledge it's profitable, but they're not achieving consistent greatness.