Programming Languages for AI Agents

So in terms of the closed loop, how does that, when you start with a spec, I guess, how is that different from what a lot of folks are doing for spec driven development? Like there's frameworks out of AWS, um, like superpowers, Jesse Vincent's framework, I guess, how does your approach to doing that differ or compare?

So there's the part where you take the spec and you break it into sub-pieces, and that's really standard.

There's really no black magic there.

That's pretty much what everybody else is doing.

I think the two things that we're doing differently is, one, because we have used reactive programming approach, We claim, so that claim still has to be measured properly, but we want at least to produce less technical debt when things have to evolve.

And the second angle is we have created this development environment to keep the LLM in a very constrained environment.

So these are the two, I would say, novelties.

So I already spoke a little bit about the development environment.

I can talk a little bit about the reactive programming aspect.

So first what is reactive programming and if you ask you know four people in a room you'll get five different opinions it's one of these things where it's like functional programming no nobody really agrees on what it means um and so reactive programming in in our case what we mean by that is react reactive in the sense of spreadsheet semantics right where you have a program so you can think of it as a spreadsheet right you have a program This program has different pieces of data.

These data, they were computed using some kind of data flow, right? Some kind of formula, right? And when something changes in the graph of computation, you only recompute the pieces that are necessary.

So that's what I mean by reactive.

To some people, reactive means streaming.

We can have endless debates about that, but that's what I mean about it.

So now imagine you have structured a harness and an agent that is structured this way.

They're structured like a graph of computation that is supposed to produce an output.

Now, when the user wants to make a change, things change a lot compared to an existing stack, because in an existing stack, you're going to take the existing code base and you're going to patch it.

And the risk that you're going to have if you keep on doing that over and over again is that you're going to accumulate technical debt.

And, you know, after a couple of months of iteration, you have a Frankenstein of a code base that nobody understands.

So our bet is that if you use reactive programming techniques, basically the goal is to output a program that would have been the program you would have outputted had you started from scratch.

Right.

And so this way, keep the technical debts, uh, to a minimum.

Um, so these are the two, two things that we work on and both, uh, I think are novel, but then the rest is very standard, you know, taking the problems, splitting it up into smaller pieces.

I mean, nothing you understand that.

So how does the reactive paradigm allow you to build a program or code base that would be more similar to if you had engineered it, I guess, by traditional means or what you'd started from, I guess? How do you create, I guess, metrics around that or?