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

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

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.

There is a great article called "Manual Work is a Bug" [0]. The idea is that you have humans doing a lot of random things so you should:

- first make a list of the things they are doing

- then update the list with the commands they have to run for each step

- some of the steps won't have commands b/c it's things like "ask Bob what the limit should be"

- over time, the commands become scripts

- then the "ask Bob" becomes an API call

- one day, the whole thing is an automated system that runs code

People like to think that LLMs can do all of the above. I don't get this b/c code is deterministic and can be run repeatedly basically "for free" (at least compared to token spend).

I do think that LLMs can greatly accelerate the creation of the code/system etc and can also help with maintaining it but the whole "we will just version control the prompt" was clearly hogwash.

0 - https://queue.acm.org/detail.cfm?id=3197520

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.

I asked Claude to spin up a bunch of agents to do it and after a bit of discussion we ended up writing a bunch of deterministic scripts that ran off the data collated by some “research” agents.

It took a few pilot loops of the process to nail it down, but separating the process into “data collection” and “process the data” has pretty much eliminated the AI step. Once the data has been collected from the random sources and normalised into something sensible we rarely have to do it again.

Even that process has been largely automated, scripts that deterministically scrape data, the AI is only needed for the very difficult parts that need some decisions or interpretation.

Getting the AI to write tools for itself is a great way to work.

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.