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>
vs
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
The later case takes a lot more effort, but it also reduces a Turing complete problem space into a binary decision at this particular step.
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)
This sounds interesting, I am really naive. I don't code in C#, is there an analogy for other programming languages, like GO, or Python or Typescript?
Like are you prompting like:
---
I need code that does X,Y, and Z.
Write it so that the Roslyn compiler on this machine can compile and the code passes the repo's styling and formatting requirements.
---
No, they are talking about refactoring, not adding new functionality to code.
So it would be something like:
Rewrite this Python code to use match/case instead of if/elif/else chains, write a script using the ast module to rewrite the code, do not edit it yourself, also write some tests with clear inputs and outputs I can inspect.
> Rewrite this Python code to use match/case instead of if/elif/else chains
Is this a real example of something people use AI to do? If so, I don't understand why that's difficult, because prompting the AI to do stuff with ASTs etc. seems a bit over the top.
Are people actually using AI to do programmatic refactors over million line codebases directly? That is far more insane.
Using AI to write ruff rules or clang-tidy rules with fixes is literally the same thing and obviously best practice over running AI in a pre-commit hook to do those checks and refactors...
Roslyn API basically lets you plug in to the C# compiler or use parts of it so that you can get the same view of the abstract syntax tree, typechecking, flow analysis, etc. that the compiler does. So it's a way to work with C# code at that level rather than just via textual manipulation. I'm less familiar with other languages but I think many have compilers with analogous capabilities, I know Haskell has the GHC API and I think the LLVM-based Clang (C++) and Rust compilers let you do similar things
Is it open source, can you share? Have been pondering using source generators to achieve a similar effect and have the LLM build the source generator ‘framework’ that code would derive from rather than just generating the code itself, you create the code generation framework.
Thanks, fixed. The runtime[1] and the scripts[2] are the practical ones. I am separating the old repo[3] into submodules since submodule recursion became smooth in Beagle.
I find some of the most interesting, and catastrophic failures in my agent fine-tuning come from the clamping down of non-determinism. It is totally the correct approach, but must be handled delicately. The non-deterministic core remains, but now under bimodal pressure.
I think this is less about clamping down on non determinism and more remembering that a script is much more reliable than having the agent do some things. Think making a number of API requests to get info for context or running a sequence of testing steps to generate a report. Remove easy places where that non determinism rears its head and there is really no need. I talk about what I'm doing with PR review in a other comment, as an example.
In other words, are there places where a one liner for the agent would be more reliable than markdown instructions and crossing fingers?
I look at it this way... I wrote scripts over the years to make my life easier. Do the same for your agents and free their attention for the parts that matter.
So I guess we should ask the agent to write such a script, UNLESS there already exists such a script and we have used it before so we know it worked at least in the past.
Else if the agent creates a new script evry time the non-determinism rears its ugly head again.
But that means we need to know that the existing script is exactly what we want. And that means we need to understand the code, or at least the tested spec of the code, that AI writes for us. AI can't replace humans, humans must remain in control and understand what the code writent by AI exactly does.
We used to (and still do) have things that could run commands and interpret them. These things would sometimes forget key parts to run or even forget to run them at all. So we invented a system where you could give instructions (code) and schedule when they would be run (cron etc). Those things were called humans.
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.
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?
You need to always be looking for what can be done deterministically and what can't. If it can, write a script or whatever is needed to make that happen. Your agent can help you figure this out. The agent becomes a glue layer for all your scripts. Use LLM judgement as an extra layer on top of a mechanical baseline.
> validating that the LLM didn't disable tests it didn't agree with
Provide a test runner and force the agent to call it. Have it emit something if you want evidence.
I know how to write a test that verifies other tests. But I can do that already, I'm wondering what Beagle would add.
I also know that if the meta-test is writable to the agent, it will change it if it feels like it wants to get rid of some other test. Even if it can't change the meta-test, it can hollow out existing tests to make them pass trivially.
I don't think nondeterminism is the problem. The problem is following rules: If I tell the agent not to change tests, it can conveniently "forget" about this. It doesn't much matter if it forgets deterministically. The problem is that it can forget at all.
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.
Problem is, usually describing the problem you want to solve *correctly* using formal tool is a task as hard (and often, equivalent to) the implementation. That said, having a formal description is useful
For some problems, yes. Formal specification is particularly useful in two cases. 1) The problem is simple but an efficient implementation is hard or bug-prone. Examples are garbage collection, file systems, sorts, databases, and tree updating.
2) The inverse of the problem is simpler than the forward operation. Examples include matrix inversion and parsing.
I wouldn’t split it like that. Formal verification is useful in the case that the spec is simpler than the implementation. That’s it.
Coming up with simple specs is not necessarily easy. You could say that is kind of what math is about. That’s how we actually make progress: find those cases where simple specs are possible and build upon them. That’s the kind of library made for eternity.
It could still be useful if the spec is roughly as hard as a simple implementation, in case you have automated methods to find more efficient implementations, guided by the constraints of the spec
Which is still a case of the spec being simpler than the implementation (you are after) ;-)
Very often, the spec is indeed just a very simple implementation. Often you can make the spec especially simple if there are no constraints on the resources it can use, at times even infinite ones.
I was recently doing some work - reasonably repetitive and tedious.
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.
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.
Humans aren't deterministic. Determinism is a red herring. There are lots of other problems with agentic programming, but this is not at the top of the list.
I agree with the humans aren't deterministic, but I feel like that wasn't the scope of the original commentator. Humans are not deterministic, yes. Neither are LLMs. Both should be phased out of processes that need to be deterministic. What do you think?
I don't think processes have to be deterministic. Results should be, in the following sense: Both humans and LLMs should write software that is well-written, well-tested, well-documented, and that meets the spec. But this still leaves a lot of room for creativity (or rolling dice).
"Humans don't always sum two integers correctly. Getting the correct sum is a red herring! There are lots of other problems with my beehive-based calculator [0], but that is not at the top of the list..."
It doesn't matter what we are, what matters is what we want, and whether what we built actually works the way we want it to work.
[0] Discworld's Ponder Stibbons would be rolling in his, grave, or more likely his "Early Death package" pocket-dimension jar.
See my reply to the sibling. Yes, it matters that the outcome is a working system! It doesn't matter whether the system was created by a human pressing keys on a keyboard.
Thats the best description I have heard of the problem so far. I ran into this recently where I automated a ton of stuff and got essentially threatened by leadership for not using AI. My system produces the same output 100% of the time, is free, and scales plus is reliable. Doing what they wanted with an LLM was fragile, didn't always produce the same output and was subject to costs. I don't think they could wrap their brains around it.
> got essentially threatened by leadership for not using AI.
This sounds made up or your workplace is rather odd to say the least. Maybe english isn't your first language and "threatened" is not the correct word?
Directly threatening individuals and teams for petty reasons is sadly common practice in US corporate environments and among the reasons I adopted my current HN username.
They usually do it by saying there's something wrong with your performance. If your technical work is unimpeachable they'll manufacture some "soft skills" issue--like saying there's something wrong with your communication. They can always find fault if they go looking for it.
Actually... yes. I was bracing to be very annoyed with your comment starting with "why is everyone using AI so stupid?!" (I know those weren't your words, but it felt like that kind of post)
And then... yeah. You got it exactly right. Once a problem or process is deterministic, that's the wrong application of an LLM.
But I had never quite thought of it in these exact terms. The way I've been thinking about it up until now is that the very best way to use LLMs is to have them produce tools. The tools get to stay reliable and predictable. They boost your performance. But I think you found the more general abstraction of the same idea. Tool-making is not deterministic. But the tools themselves can be. That's why it fits. Trying to stuff LLMs into what's otherwise a deterministic process is an absurd waste and error-prone.
Just to be clear, software development itself is not deterministic, though? The software developer pushes a given business process from less-deterministic toward more deterministic? When we say we’ve “abstracted LLMs out of a process” we’d also say that we’ve abstracted software developers out that process as well?
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.
There's a Cambrian explosion of promising-sounding AI tools, all of which seem to work reasonably well for their authors, but it's unclear which ones to try. It seems like what we're missing are in-depth product reviews?
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.
The concept of "tool building" is one of the areas my team has spent the most time coaching our less-technical employees on since widespread LLM rollout in our company.
Developers and developer-adjacent, technical people tend to think this way on their own... but every business has dark corners where repetitive, manual things still happen. We're leaning a lot on training and even org-wide LLM instructions to try and let the LLM (by its own assessment) be the vehicle use to codify a process and turn it into some good old-fashioned reviewable, deterministic automation.
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.
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
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.:
vs
The later case takes a lot more effort, but it also reduces a Turing complete problem space into a binary decision at this particular step.
Yea I’ve been warming up to the web mcp after doing more ai browser work and hitting so many pain points: https://developer.chrome.com/docs/ai/webmcp
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)
This sounds interesting, I am really naive. I don't code in C#, is there an analogy for other programming languages, like GO, or Python or Typescript?
Like are you prompting like:
--- I need code that does X,Y, and Z. Write it so that the Roslyn compiler on this machine can compile and the code passes the repo's styling and formatting requirements. ---
Or something else.
Here's the official docs if it helps
https://learn.microsoft.com/en-us/dotnet/csharp/roslyn-sdk/t...
No, they are talking about refactoring, not adding new functionality to code.
So it would be something like:
Rewrite this Python code to use match/case instead of if/elif/else chains, write a script using the ast module to rewrite the code, do not edit it yourself, also write some tests with clear inputs and outputs I can inspect.
Or something.
> Rewrite this Python code to use match/case instead of if/elif/else chains
Is this a real example of something people use AI to do? If so, I don't understand why that's difficult, because prompting the AI to do stuff with ASTs etc. seems a bit over the top.
Why?
Are people actually using AI to do programmatic refactors over million line codebases directly? That is far more insane.
Using AI to write ruff rules or clang-tidy rules with fixes is literally the same thing and obviously best practice over running AI in a pre-commit hook to do those checks and refactors...
Roslyn API basically lets you plug in to the C# compiler or use parts of it so that you can get the same view of the abstract syntax tree, typechecking, flow analysis, etc. that the compiler does. So it's a way to work with C# code at that level rather than just via textual manipulation. I'm less familiar with other languages but I think many have compilers with analogous capabilities, I know Haskell has the GHC API and I think the LLVM-based Clang (C++) and Rust compilers let you do similar things
Is it open source, can you share? Have been pondering using source generators to achieve a similar effect and have the LLM build the source generator ‘framework’ that code would derive from rather than just generating the code itself, you create the code generation framework.
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/
Thanks, fixed. The runtime[1] and the scripts[2] are the practical ones. I am separating the old repo[3] into submodules since submodule recursion became smooth in Beagle.
[1]: https://github.com/gritzko/jab
[2]: https://github.com/gritzko/beagle-ext
[3]: https://github.com/gritzko/beagle
I find some of the most interesting, and catastrophic failures in my agent fine-tuning come from the clamping down of non-determinism. It is totally the correct approach, but must be handled delicately. The non-deterministic core remains, but now under bimodal pressure.
I think this is less about clamping down on non determinism and more remembering that a script is much more reliable than having the agent do some things. Think making a number of API requests to get info for context or running a sequence of testing steps to generate a report. Remove easy places where that non determinism rears its head and there is really no need. I talk about what I'm doing with PR review in a other comment, as an example.
In other words, are there places where a one liner for the agent would be more reliable than markdown instructions and crossing fingers?
I look at it this way... I wrote scripts over the years to make my life easier. Do the same for your agents and free their attention for the parts that matter.
So I guess we should ask the agent to write such a script, UNLESS there already exists such a script and we have used it before so we know it worked at least in the past.
Else if the agent creates a new script evry time the non-determinism rears its ugly head again.
But that means we need to know that the existing script is exactly what we want. And that means we need to understand the code, or at least the tested spec of the code, that AI writes for us. AI can't replace humans, humans must remain in control and understand what the code writent by AI exactly does.
We used to (and still do) have things that could run commands and interpret them. These things would sometimes forget key parts to run or even forget to run them at all. So we invented a system where you could give instructions (code) and schedule when they would be run (cron etc). Those things were called humans.
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
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 am the author. I am trying to limit one post to one page. Most people here are reading reasoning all day, I am afraid. Might get tired.
I also aspire to make one post a day. To be continued.
Thanks! I actually find human-written text very refreshing compared to what I have to read all day. I'll stay tuned.
> Most people here are reading reasoning all day, I am afraid. Might get tired.
This is well-observed.
You need to always be looking for what can be done deterministically and what can't. If it can, write a script or whatever is needed to make that happen. Your agent can help you figure this out. The agent becomes a glue layer for all your scripts. Use LLM judgement as an extra layer on top of a mechanical baseline.
> validating that the LLM didn't disable tests it didn't agree with
Provide a test runner and force the agent to call it. Have it emit something if you want evidence.
I know how to write a test that verifies other tests. But I can do that already, I'm wondering what Beagle would add.
I also know that if the meta-test is writable to the agent, it will change it if it feels like it wants to get rid of some other test. Even if it can't change the meta-test, it can hollow out existing tests to make them pass trivially.
I don't think nondeterminism is the problem. The problem is following rules: If I tell the agent not to change tests, it can conveniently "forget" about this. It doesn't much matter if it forgets deterministically. The problem is that it can forget at all.
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.
Problem is, usually describing the problem you want to solve *correctly* using formal tool is a task as hard (and often, equivalent to) the implementation. That said, having a formal description is useful
For some problems, yes. Formal specification is particularly useful in two cases. 1) The problem is simple but an efficient implementation is hard or bug-prone. Examples are garbage collection, file systems, sorts, databases, and tree updating. 2) The inverse of the problem is simpler than the forward operation. Examples include matrix inversion and parsing.
I wouldn’t split it like that. Formal verification is useful in the case that the spec is simpler than the implementation. That’s it.
Coming up with simple specs is not necessarily easy. You could say that is kind of what math is about. That’s how we actually make progress: find those cases where simple specs are possible and build upon them. That’s the kind of library made for eternity.
It could still be useful if the spec is roughly as hard as a simple implementation, in case you have automated methods to find more efficient implementations, guided by the constraints of the spec
Which is still a case of the spec being simpler than the implementation (you are after) ;-)
Very often, the spec is indeed just a very simple implementation. Often you can make the spec especially simple if there are no constraints on the resources it can use, at times even infinite ones.
Right. Databases can be modeled as linear search over huge arrays, for example.
might be relevant: https://martin.kleppmann.com/2025/12/08/ai-formal-verificati...
Yes. I should have cited that. He has this right.
I was recently doing some work - reasonably repetitive and tedious.
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.
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.
I love the way you put this. Are there any sites or forums or places where people discuss/hash this out?
I've genuinely never considered it from this angle before.
Humans aren't deterministic. Determinism is a red herring. There are lots of other problems with agentic programming, but this is not at the top of the list.
I agree with the humans aren't deterministic, but I feel like that wasn't the scope of the original commentator. Humans are not deterministic, yes. Neither are LLMs. Both should be phased out of processes that need to be deterministic. What do you think?
I don't think processes have to be deterministic. Results should be, in the following sense: Both humans and LLMs should write software that is well-written, well-tested, well-documented, and that meets the spec. But this still leaves a lot of room for creativity (or rolling dice).
Oh yeah totally agree
> Humans aren't deterministic
Thus why we replaced computers (flesh and blood people writing out calculations) with computers (silicon-based number-crunching machines).
"Humans don't always sum two integers correctly. Getting the correct sum is a red herring! There are lots of other problems with my beehive-based calculator [0], but that is not at the top of the list..."
It doesn't matter what we are, what matters is what we want, and whether what we built actually works the way we want it to work.
[0] Discworld's Ponder Stibbons would be rolling in his, grave, or more likely his "Early Death package" pocket-dimension jar.
See my reply to the sibling. Yes, it matters that the outcome is a working system! It doesn't matter whether the system was created by a human pressing keys on a keyboard.
Thats the best description I have heard of the problem so far. I ran into this recently where I automated a ton of stuff and got essentially threatened by leadership for not using AI. My system produces the same output 100% of the time, is free, and scales plus is reliable. Doing what they wanted with an LLM was fragile, didn't always produce the same output and was subject to costs. I don't think they could wrap their brains around it.
> got essentially threatened by leadership for not using AI.
This sounds made up or your workplace is rather odd to say the least. Maybe english isn't your first language and "threatened" is not the correct word?
You sound like someone thats never worked in a corporate environment. No, threatened is the correct word. I don't care if you like that or not.
It is not about me liking it or not. The word threaten comes with implications. This means they acted in hostile manner based on your words.
Directly threatening individuals and teams for petty reasons is sadly common practice in US corporate environments and among the reasons I adopted my current HN username.
They usually do it by saying there's something wrong with your performance. If your technical work is unimpeachable they'll manufacture some "soft skills" issue--like saying there's something wrong with your communication. They can always find fault if they go looking for it.
This is exactly right. Abstracted out of the process, or to a point of most optimal application.
Actually... yes. I was bracing to be very annoyed with your comment starting with "why is everyone using AI so stupid?!" (I know those weren't your words, but it felt like that kind of post)
And then... yeah. You got it exactly right. Once a problem or process is deterministic, that's the wrong application of an LLM.
But I had never quite thought of it in these exact terms. The way I've been thinking about it up until now is that the very best way to use LLMs is to have them produce tools. The tools get to stay reliable and predictable. They boost your performance. But I think you found the more general abstraction of the same idea. Tool-making is not deterministic. But the tools themselves can be. That's why it fits. Trying to stuff LLMs into what's otherwise a deterministic process is an absurd waste and error-prone.
Smart. I like it.
> … deterministic processes…
Just to be clear, software development itself is not deterministic, though? The software developer pushes a given business process from less-deterministic toward more deterministic? When we say we’ve “abstracted LLMs out of a process” we’d also say that we’ve abstracted software developers out that process as well?
I think a big part is the misperception that it’s “easier” and less effort to run stuff through LLM than to design an effective deterministic process.
Would love to know how you’ve managed to counter this as the drive to throw everything at LLMs is driving me insane.
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.
There's a Cambrian explosion of promising-sounding AI tools, all of which seem to work reasonably well for their authors, but it's unclear which ones to try. It seems like what we're missing are in-depth product reviews?
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.
The concept of "tool building" is one of the areas my team has spent the most time coaching our less-technical employees on since widespread LLM rollout in our company.
Developers and developer-adjacent, technical people tend to think this way on their own... but every business has dark corners where repetitive, manual things still happen. We're leaning a lot on training and even org-wide LLM instructions to try and let the LLM (by its own assessment) be the vehicle use to codify a process and turn it into some good old-fashioned reviewable, deterministic automation.
Yeah, I realized this around may 2024 and started to rail models in deterministic workflows and tooling. LLMs are the new CPU.
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.
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
Thanks for posting your ad?