Let’s face it: for developers, the Age of Agents has begun.

Yes, there’s plenty of hype surrounding them, and your boss may be forcing an Agent down your throat, and companies are hiding behind agents to layoff hundreds of thousands of developers, but there are also countless coders who have used an Agent to code something, and enjoyed doing it, and countless more non-coders who have somehow managed to get something working through the use of an Agent.

Something has changed, and there is a societal cost, and an ethical cost, and an environmental cost. But that’s not what I want to discuss in this post.

Agents are a mean to develop applications. So far, means to develop applications have been the realm of the Programming Languages community. So I’d like to take a look at Agents not as a developer, or as someone worried by the implications of Agents on both our industry, education and the entirety of our society, but as a Programming Language designer.

I hope that this will be the first of a series of posts, from which maybe something will grow that could one day look like a programming language adapted to the Age of Agents. We’ll see.

Let’s start with a few assumptions for this project:

Also, a few personal observations of what Agents get right:

…and what they get wrong:

Oh, every project needs a codename, right? Given that I only have questions so far, I’m going to call this project MaieuticsLanguage, aka “Malang”.

So, armed with this name and a few assumptions, let’s start asking questions.

If you’ve ever developed a language, whether a formal language or a programming language, one of the first things you’ve done was probably come up with an early prototype of a syntax. In the early stages, syntax serves as support to define semantics, and to explain the language. Once you have an implementation, well, you need to be able to write in the language, and how would you do this without a concrete syntax?

But Agents are changing how we approach programming. In fact, while you’re using an Agent to code, you’re typically not writing code (although you’re hopefully reviewing the code it produces). So, I’d like to start our questioning with syntax.

Without a concrete syntax, can we even save the code as a file?

Well, yes, we very much can. We could just as well store an abstract format (say S Expressions or some JSON format) and display a concrete syntax only when the developer decides to look at the code. This is what TeXmacs does, letting you write your code and documents with a Lisp-style syntax, an ML-style syntax or an XML-style syntax, storing it in its own format, and letting you see it in any of these three syntaxes. This is also, to some extent, what we did when prototyping binast: provide a storage format for JavaScript that had a 1:1 mapping with (syntactically correct) JS code but stored more information to optimize reading and compilation speed.

There are even (formal) languages without a concrete syntax, such as bigraphs, that are specified by drawings. Reactive programming, which yielded React, is at its core defined by a dependency graph. Many developers using the Entity Component System paradigm write code without having a concrete syntax to declare the entities themselves, but rather trusting the UI of Unity or Unreal Engine to sort these out.

Also, there are other ways to store a language than a flat file, for instance a database, such as GitLab’s Knowledge Graph.

So the answer sounds like “no, code storage doesn’t require a concrete syntax.”

Well, the main point of Agents is that they’re writing the code for us, aren’t they?

So, at least in some circumstances, we can develop applications using Agents without needing a concrete syntax. Let’s see if we can roll with that.

Of course, I don’t trust Agents, and I believe that no user of Malang should trust them entirely, so we will want some kind of syntax for reviewing.

This syntax does not need to be the concrete syntax of the language, though.

If we don’t want to adopt a concrete syntax, I see the following design options:

Let’s take a look at that last option. If you have ever programmed in Rust, for instance, you have probably used the type system, including the typestate pattern, to model the behavior of your data structure within its type signature: once a file has been closed, you can’t use it anymore; you need network access to proceed beyond some point, so the function can only be called by passing a network capability, etc. If you have gone further and programmed in a dependently-typed or adjacent language, such as Coq/Rocq or Idris (or Ur, I believe), you have encoded the entirety of what your function does in its type, leaving the body to specify the how.

In the age of Agents, combining the strong logical foundations of dependently-typed languages and the intuitive developer experience of Agents would be a form of neurosymbolic programming. We could combine this with options 1. or 2., storing the what metadata as part of the concrete syntax, and using either a well-defined subset of English or Agent-issued explanations to surface this what as something understandable by the developer.

I’ll dig in this further once this has decanted a bit in my mind. For the time being, I’ll just be happy to answer that “no, we (probably) don’t need a concrete syntax for reviewing code.”

Without a concrete syntax, how do we look things up in the code?

Yes, we’re used to grepping and looking things up with our eyeballs. But that’s not the only way to look things up. In the age of OG Basic, this was done with line numbers, and in the age of OG Fortran, with punchcard numbers. We don’t want either option, but this shows that code navigation has evolved already, and will undoubtedly evolve further.

In the age of IDEs, I often trust my IDE to bring me to all the points in the code that use my data structures, or my function, or my method, or to bring me to the definition of the function I’m using. If we were to compare our code to a database, that would be more or less akin to using symbols as indices for queries in the code.

In the age of Agents, I found out that Agents are really good at searching. “Show me the code responsible for deciding how often we need to save”, or “where do we use the invariant that i > 0?” Again, if we were to compare our code to a database, that would be more or less akin to a vector search in a graph database.

So… at this stage, I’m tempted to say that we don’t need a concrete syntax for navigating the code. At this point of my thoughts, I feel that we’d want some kind of easy to lookup index (e.g. module names, type/class names, function names, etc.) for quick navigation and when you want to be absolutely certain that the Agent and the Developer are referring to the same part of the code, and the Agent’s ability to lookup content by semantics for everything else.

Some developers believe that Agents can one day grow to replace compilers and that the natural language specifications will be the code.

I don’t share that belief. Having the ability to converse with the Agent in a natural language feels useful, but natural language is, by definition, vague and full of ambiguities, as we can attest whenever we try to get the Agent to fulfill exactly what we want, so this sounds like a good recipe for disaster.

By opposition, I want Malang to have clear semantics. We want to be better than having an Agent write Python (or even Idris), not worse.

For this, I don’t see how we could get away without some kind of abstract syntax.

At this point in time, I believe that Malang doesn’t need a concrete syntax, but I don’t see a way forward without an abstract syntax.

If I were to start prototyping today, I’d probably store Malang’s code as some kind of S Expressions, but claim that it’s an implementation detail. I might, of course, decide to display it or parse it as a different syntax.

I would also very much investigate dependent types as a mechanism to specify what each piece of code does, letting the Agent translate this from and into natural language.

We’re barely started. Among the topics we need to discuss next are:

At this stage, I need to let my thoughts decant a few days.

See you in a bit for Part 2.