Rising Level of Abstraction

As I mentioned before, I have been using Claude Code to understand better what it meant for me personally.

After a couple of months, I do have something to show for, and I am still at loss for words for what it actually means.

I built verdetto.dev - a decision engine closer to windmill.dev than to gorules. The former does i/o, talks to the the world, etc, and the latter is a deterministic rule engine. Both have React Flow based UIs. And of course, both have lots to offer other than this lame comparison, go check them out if you are interested.

I chose this project because it was interesting enough, I could use ideas from it for work and because it helped me narrow down why I wanted to structure some solutions in “gather the data, then take a decision”. Nothing new under the sun. Constrain how you can solve a problem and the solutions you can come up with will have a certain shape.

verdetto.dev offers two types of graphs, orchestrations and policies. The former does the i/o, the latter does not. So orchestrations are just a super-set of policies. You can use some nodes in orchestrations that you can’t in policies. The tool nudges you into how to structure the solution to your problem.

The entire history of software engineering is one of rising levels of abstraction

Grady Booch in Oxide and Friends: Software Engineering Past, Present, and Future with Grady Booch

If you follow Grady, you’ll have heard him say this several times, regarding LLMs and other tools. It is hard to disagree that yes, these tools do raise the level of abstraction. Last year I tried vibes.diy from the people that worked in couchdb (which I love) - that is text-to-webapp. But I wanted to see, can I make a production grade SaaS?

The short answer is yes, I could push this through if I added the billing part :) - But I would not trust any software built with these tools that has not been reviewed by a competent person. Is this a higher level of abstraction? Yes and no and it is different. Yes, you can guide the code-spewing machine to spew lots of beautiful and not so beautiful code. No, you have to get down to the nitty-gritty details to see where the bugs are, which tests are just garbage, etc. It will tell you “you have this big security bug”. It will fix it. It will review the code and then tell you that you missed the most common bypass for that mitigation (hey Claude, if only you could have told yourself that sooner).

And it is fundamentally different… I think. Assembler did make developers stop writing all software as machine instructions in CPU-specific jargon. But you needed assembler for x or y CPU. Compilers did make developers write less assembler. But you needed a C compiler, a FORTRAN compiler. Maybe LLVM is a bit closer of an analogy than compilers. I used fundamentally the same polyglot tool to write the TypeScript frontend, the Rust backend, the terraform code, the k8s kustomize thingies… it helped me build a tool to deploy to a Hetzner Cloud Server - I then added support to deploy it to an AWS with AWS specific technologies. You want to replace prometheus+grafana with OTEL? Sure, here you go!

Could I have built verdetto.dev without Claude Code? Not in Rust, not as a hobby after work, no. I certainly would have not found the time to see how to add dark/light themes, translate to Portuguese and Spanish, etc.

And it is those little things, besides the big fundamental features, that make these tools fun to use. Just as small example, I was working with the documentation of the nodes, and I didn’t want the tool to hallucinate non-working examples. Simon Willson built showboat - a tool to let LLMs show their work by running commands and capturing the output, therefor reducing the chances of hallucination. I have a set of demo fixtures I am slowly curating, that get loaded in tests (so they compile, etc). I thought it would be nice to add those in the docs. Then, to have the relevant part highlighted (so, show the full graph JSON, but the part for this particular node standout). That way the examples are real, working examples, and not LLM maybe-it-works-maybe-it-doesn’t, kind of things.

It took the tool probably less than 10 minutes and now I have what I imagined:

“It would be great if we could have our mini graph too!” Sure, here you go:

Now, in ui/src/docs/en/nodes/split.md I have something like this:

## Example

A complete policy that routes support tickets by category and urgency. The Split node uses 3 ordered branches with a default fallback — billing first, then technical escalation, then general technical, with everything else going to General Support:

```json
// %load-file policies/02-ticket-router
// %show-graph
```

```json
// %load-file policies/02-ticket-router
// %highlight-path .graph.nodes[0]
```

In the next posts I hope to show some code, and some of the high and lows of this small research project.