A dumber but related habit I've gotten into is that if I want to use AI to do some sort of refactoring on a C# codebase, instead of asking it to edit the code directly I ask it to write a code transformation using the Roslyn compiler API, then run that on the code. The result is less likely to have subtle bugs if it appears to work and gets through a light code review on the transformation (i.e., attempts to cheat with weird special-casing are more likely to stand out amongst the Roslyn API code, and if there isn't such weird special-casing but the code is wrong, the result is more likely to be completely broken rather than subtly broken)

I think semi-automation with contextual and domain-specific tooling is the key to the best quality outcomes.

For example, with browser automation, giving the LLM raw access to the literal DOM generally results in disaster for tasks that need to be stable across more than 5-10 interactions. The better approach is to write an intermediate layer that understands each view and can provide a list of tools that are precisely tailored for each case. E.g.:

  https://myapp/Login
  - <raw dom - hundreds of kb>
  - Available Tools: <arbitrary javascript>

  https://myapp/login
  - We detected that this is the application's login page. 
  - It has the following visible elements:
    + Username
    + Password
    + Login Button
  - Available Tools:
    + PerformLogin
    + Quit

Makes sense, I have had the biggest wins with AI by attacking nondeterminism whenever possible.

BTW, you should probably fix the Beagle link on your homepage: https://replicated.live/beagle/

This is a very interesting introduction to a blog post, but... I'm somehow missing the actual blog post. How does this stuff work in practice? What are some concrete examples? How does one get from JavaScript tokenizing things in a commit hook to validating that the LLM didn't disable tests it didn't agree with, or any other helpful property?

I think scaffolds and the app layer are really the two big things needed for the deployment of AI in most use cases. In general, my company says for a given problem, we prefer deterministic software as the solution first, followed by LLMs, followed by humans. That's how we approach pretty much every problem. Yes, there are many things that we do with LLMs that we can eventually get to be done with software, and many things that are done by humans that we can get to be done by LLMs.

This makes sense, although it's not well described here.

Formal methods, as in proof of correctness, have been around for decades (I was doing that stuff in the 1980s) but pushing the proofs through was too laborious. The seL4 verification effort reportedly used over a decade of people time.

The idea is that if you have a formal specification of what you want to happen, you can get a LLM to do the struggling with the proof system to get it right. It's a good task for an LLM, because there's feedback from the prover.

I'd like to see more non-trivial examples of this. People keep republishing verifications of greatest common divisor or stack algorithms, which was done decades ago.

I’ve got a test that checks to see if “Logger” has been imported anywhere in my Elixir project, and if it finds one it prints out an explanation of why this project shouldn’t use Logger and what it should do instead. (Which is— emit OpenTelemetry events.)

Basically what I’ve been saying since OldJob forced LLMs down our throats and pegging performance to usage metrics: why the fuck are we handing deterministic processes to probabilistic systems when it should be the other way around (using probabilistic systems to design deterministic ones)?

LLMS should be abstracted out of a process as soon as practicable, replaced with deterministic processes or procedures. Otherwise you’ve built the world’s most fragile process at the mercy of token cost, vendor hostility, geopolitics, and model deprecation.

As it always is with these articles, that has nothing to do with non-determinism the author is talking about. Model's input is in natural language which isn't formally defined, unlike Ragel's input. This makes it open to interpretation by the model that isn't trained the same way as you, has very limited cognitive capabilities, and must generate something in very limited time by design, even if the result is incorrect. This also makes it not related to determinism in any way. You can make model outputs deterministic, but this won't solve your problem because it's not about determinism. Words have meaning.

Claude or any other model just translates your natural language instructions into formally defined tool calls. You cannot replace this layer with a formal tool like Ragel. You can write code for Ragel directly, in which case the responsibility for this is yours and not Claude's. (duh)

>What about Claude? Well, my instructions say in all caps: DO NOT PARSE ANYTHING MANUALLY, EVER. (...) It tries anyway

This needs a self-verification loop. It still won't guarantee that model's interpretation will match yours, but it will improve the accuracy. Almost every model will know that it went off the rails upon checking what it's trying to do. Harness has to provide the loopback for this, because the transformer architecture doesn't.

I'm seeing tons of blog posts which seemingly amount to having AI write code. It would have never occurred to me to repeatedly invoke an LLM to do what a simple script could, but I guess I shouldn't be too surprised. 20 line bash scripts replacing entire enterprise software stacks was a meme even in the 90s.

Second this, following Cloudflare's post on how they do agentic PR review, I'm working on a script that renders the conext and diff to disk before passing it off to the agent, which generates a jsonl file of comment add/update, which another script will process. Way better than handing it bash and clis so it can fumble about non deterministically