Why I decided to create my own programming language, and how artificial intelligence is helping me make it a reality
Protos did not begin as an attempt to solve a particular problem in a software project. Nor was it an exercise in creating yet another programming language for the sake of it.
It was an idea I had been carrying around for a long time.
Over the years, I have worked with many different technologies and watched programming languages, tools, and software platforms evolve. Each has its strengths, compromises, and history. Many of their design decisions make sense when viewed in that context.
But one question has always interested me: what would a programming language look like if I could design it from its foundations?
I was not particularly interested in inventing different syntax for familiar operations. What interested me was something more difficult: finding a small set of concepts that fit together naturally and could support simple programs, complex applications, and concurrent systems without constantly forcing programmers to adopt a different mental model.
That idea gradually took shape, but turning it into a real language was another matter entirely.
Designing a language is already a substantial undertaking. Implementing it, testing it, optimizing it, documenting it, and building the surrounding tools requires an enormous amount of work—especially as a personal project.
What changed was artificial intelligence.
For the first time, I felt that I could realistically approach a project of this scale without having an entire development team working alongside me.
That is how Protos began.
The language I wanted to build
The main motivation behind Protos is coherence.
Programming languages naturally accumulate features as new requirements emerge. This is often necessary, but it can also produce systems in which different capabilities seem to belong to entirely separate worlds.
With Protos, I want to explore the opposite approach: begin with a small number of fundamental mechanisms and discover how far they can go through composition.
Protos is a prototype-based object-oriented programming language. It has no classes or class hierarchies. Objects relate to one another through delegation. They contain slots, communicate through messages, and use closures as executable values.
I also want execution contexts, concurrency, and communication between components to fit into a recognizable design, rather than becoming independent systems layered on top of one another.
This does not mean forcing everything into a single abstraction. Executing a task, making use of multiple CPU cores, and building an actor-based system involve genuinely different concerns. Hiding those differences does not make them disappear.
The goal is to introduce each concept when it solves a real problem, without making simple programs carry the conceptual weight of complex ones.
One principle captures much of this philosophy: start small, grow through composition, and pay for complexity only when the problem requires it.
Protos is not trying to minimize the number of keywords at any cost. It is trying to minimize the number of independent rules a programmer must understand.
That distinction matters. A language can have very little syntax and still be difficult to reason about if it is full of exceptions. I would rather have one well-defined general rule than a collection of special cases.
What artificial intelligence changed
For a long time, the main obstacle was not imagining the language. It was finding the resources to build it.
A programming language is much more than an interpreter capable of evaluating a few expressions.
It needs a grammar, precise semantics, an execution environment, error handling, libraries, tests, and a way to ensure that every design decision continues to work when combined with the others.
Then come performance, concurrency, developer tooling, debugging, compatibility, distribution, and maintenance.
It is entirely possible to spend years on a project like this without ever producing something sufficiently complete to use.
Artificial intelligence has not removed that complexity, but it has fundamentally changed how I can approach it.
I can now investigate an alternative, compare it with existing implementations, turn a design decision into a specification, prepare an implementation, review it, and examine test results in much shorter cycles.
That makes it possible to explore directions I might previously have abandoned simply because they required too much time.
There is, however, something I want to make clear: Protos is not a language I asked an AI to invent for me.
The decisions about what the language should be, which rules it must follow, and which compromises I am willing to accept remain design decisions.
AI helps me research, compare, implement, and identify mistakes. It does not remove the need to judge whether the result makes sense.
Sometimes the most important part of the process is telling the AI that its proposed solution is not acceptable.
How I actually work with AI
Over time, I have developed a fairly specific working method.
It is not based on writing a vague request and accepting whatever code comes back.
I separate two activities that I consider fundamentally different: reasoning about a problem and implementing its solution.
I use ChatGPT as a technical thinking partner, primarily for research, comparison, and design discussions.
When a question arises, I can examine how other languages approach it, what consequences different choices have, and whether those choices fit the principles behind Protos.
I am not interested in copying a solution merely because a well-known language uses it. I want to understand why it works there, which problem it solves, and whether its assumptions also apply to Protos.
This research often involves other programming languages, object models, actor systems, and execution technologies.
I also study implementations built on GraalVM and Truffle, particularly when I need to understand how they address a specific runtime or performance problem.
Once the problem has been investigated and a decision has been made, I prepare concrete implementation instructions.
That is where Claude Code comes in, acting as a programming agent inside Visual Studio Code.
Its role is to work with the repository: locate the relevant files, edit the code according to specific instructions, and help address problems that emerge during implementation.
This separation is deliberate. It lets me spend one part of the process understanding and defining the problem, and another translating an agreed design into working code.
The process does not end when the code compiles.
Tests, observed behavior, regressions, and performance measurements feed back into the discussion.
If something fails, I want to understand why. If an optimization improves performance but violates a language rule, that conflict must be identified and addressed explicitly.
And when the available evidence is insufficient to reach a reliable conclusion, I prefer leaving a question open to pretending it has been resolved.
A project governed by rules, not a sequence of prompts
One of the most important lessons I have learned from working with AI agents is the need for discipline.
It is easy to appear to make rapid progress. It is also easy to accumulate code, contradictory documentation, and decisions whose original reasoning has been forgotten.
To avoid that, Protos is organized around specifications, design questions, implementation tasks, bug reports, tests, and recorded evidence.
Specifications define the language's behavior. Research compares alternatives and records arguments. Important design decisions are approved before implementation. Tests help establish whether the resulting code behaves as intended.
The repository also contains instructions governing how work should be carried out: what may be changed, how changes should be validated, and how research differs from implementation.
I do not regard these rules as unnecessary bureaucracy.
They are a way to maintain control over a project that can evolve very quickly, particularly when AI tools perform a substantial part of the implementation work.
They also force important distinctions.
An attractive idea is not necessarily an approved design. An existing implementation is not necessarily a completed feature. A passing test does not automatically prove that an architectural decision is sound.
Speed is valuable only when we can trust what we are building.
From an idea to an executable language
Protos is no longer just a collection of ideas.
It now has a reference implementation under active development, an interpreter built on GraalVM and Truffle, command-line tools, libraries, conformance tests, and technical documentation.
The language includes its object and delegation model, executable closures, concurrency mechanisms, actors, and a growing set of capabilities introduced through a controlled design process.
Much of the work involves discovering how these ideas behave in practice.
A feature must do more than look elegant in a specification. It must be implementable, interact correctly with existing features, and produce the expected results.
Then there is performance.
Working with Truffle means investigating how programs are represented and executed, what the compiler can optimize, and which runtime costs arise from particular design choices.
Sometimes a seemingly minor difference in implementation has major consequences for execution performance.
That is why I compare behavior, inspect internal representations, run tests, and use other language implementations as reference points.
The objective is not to turn Protos into a copy of those languages. It is to learn from the engineering experience accumulated by projects that have spent years solving similar problems.
This is one of the aspects of Protos that interests me most: discovering whether a conceptual idea can become a real, efficient, and internally consistent system.
What AI makes possible—and what it does not solve
I do not want to suggest that developing software with artificial intelligence is automatic.
It is not.
Models make mistakes. They misunderstand requirements, propose unnecessarily complicated solutions, and sometimes introduce regressions while trying to fix unrelated problems.
The larger the project becomes, the more important it is to detect those failures.
There is also the practical question of cost. I have experimented with different tools, models, and ways of working to find an arrangement that makes sense for a personal project.
My current approach is to use ChatGPT for research and reasoning, while Claude Code acts as the implementation agent in my development environment.
This is a practical division of responsibilities, not a claim that any one tool is perfect for every task.
I tell the story of the experiments, usage limits and costs that led me here in What It Cost Me to Learn How to Spend Less on AI.
AI has removed an enormous barrier in terms of time and effort. It has not removed the need for technical knowledge, judgment, patience, and verification.
In fact, the easier it becomes to produce code, the more important it becomes to understand what code should be produced.
Why I keep going
Protos remains an experimental programming language, and its design is still evolving.
There are open questions, known limitations, and a great deal of work ahead.
I have no intention of presenting an unfinished project as something complete.
I also do not know how far Protos will ultimately go.
What I do know is that I can now devote real effort to an idea that, for a long time, seemed too large to pursue on my own.
For me, that is already an extraordinary change.
Protos is an opportunity to explore how I believe a programming language should work, learn from decisions made by other projects, and test my own hypotheses through real code.
It is also an experiment in a way of developing software that would have been difficult to imagine only a few years ago: one person retaining technical direction while using artificial intelligence to expand their ability to research and implement.
What matters most is not how many features I can add or how quickly the version number changes.
It is whether Protos can continue to grow while remaining faithful to the idea that inspired it.
And after thinking about that idea for so long, finally being able to watch it execute is a powerful motivation to keep going.