Presenting Advanced Research Findings on Programming Language Design in the Age of Advanced Artificial Intelligence

I believe we are approaching a profound shift in software development: creating a programming language tailored to a company’s needs or a particular field could become a practical option that a small team can seriously consider and implement. Developers will gain greater control over the tools through which they express their ideas, extending all the way to the language itself.

We are accustomed to beginning a technical project by asking: Which programming language is best suited to this work? I expect another question to become increasingly relevant as artificial intelligence advances: Can we build a language that fits this work more precisely?

For me, this perspective has a practical foundation. Over the past three months, I have been researching, designing, experimenting, and engaging in extensive technical discussions with AI models. I have tested their output, returned to correct it, and continued developing it. Throughout this journey, I have witnessed remarkable capabilities and encountered real limitations. What I learned from the setbacks was essential to understanding the approach that later began producing successful results.

I started close to the processor. I worked on establishing development tools targeting the x86 architecture, designed my own assembler, and then built a language and a supporting layer of tools above it to facilitate the creation of programming languages. My goal was to establish a foundation I could build upon while controlling the relationship between what a developer writes and what the machine executes.

I then provided these tools to an AI system and began working with it to build a general-purpose programming language.

The attempt continued for approximately a month. Important components were taking shape, problems were being solved, and ideas were becoming implementations. Yet the expanding requirements kept opening new fronts: the type system, memory management, libraries, tooling, compatibility, interactions between features, and edge cases that appear minor until you begin testing them.

Eventually, I reached a dead end for the scope I was trying to achieve through that approach. I retained the work that had been completed and paused to reconsider the direction.

The most important lesson from this stage was that defining a language’s domain changes the scale of the project, the way it is designed, and the prospects of reaching a useful result.

I shifted toward building a language specialized in backend development, drawing on the foundation and tools I had already developed. The requirements became clearer: a language that serves server applications, makes their needs easier to express, and brings the capabilities required for that domain into a coherent development experience.

At this point, the results began to change noticeably.

I was impressed by the capabilities emerging in the language and by how quickly requirements were becoming features I could test. I tried what had been built and found highly encouraging results in both usability and performance. In my initial experiments, performance appeared close to Go in the cases I tested. That observation applies specifically to those experiments; a broader comparison requires published benchmarks under equivalent conditions, covering multiple workloads and scenarios.

Even so, the outcome was sufficient to change my understanding of what could be achieved. I now had practical evidence that focusing the effort on a clearly defined domain could produce a valuable tool in far less time than I had expected.

I then turned to a dream I had carried for twenty-six years: a programming language specialized in multimedia.

I wanted images, sound, motion, and drawing to become natural elements of the programming experience. I envisioned a language that helps developers express the scenes they want to create, gives them clear control over performance and memory, and reduces the distance between a visual or audio idea and its implementation.

Within several days of intensive work, drawing on the tools and experience accumulated during the previous stages, the core of a compiled language began to take shape around my fundamental requirements. The work then expanded to include large drawing surfaces, major image formats, audio, video, animation, text rendering, and graphics elements, along with the means to manipulate them.

I am continuing to develop and test this language, with the goal of reaching an experimental release that can be shared with multimedia enthusiasts. Completing this step requires a genuine examination of what works, what remains missing, and what needs improvement before others can depend on it.

I should emphasize that those few days were an extension of months spent establishing tools and experimenting. Reusing that foundation was an important reason for the rapid progress. I see this as a central principle in the future of language design: a shared technical foundation can support several specialized languages, each with its own vocabulary, libraries, and user requirements.

Domain-specific languages themselves have a history that predates generative AI. Tools such as JetBrains MPS already exist to build languages for particular domains. This places my experience within an established area of software engineering, while advances in AI create the possibility of expanding the community able to participate in it.

Anthropic has also published an experiment in building a C compiler using a group of AI agents, explaining the decisive role of tests, the working environment, and feedback in guiding their work. Such experiments reveal advanced capabilities alongside the substantial engineering effort required to turn code generation into results that can be verified.

Based on my own experience, I believe the most significant change may lie in the cost of experimentation itself. When a developer can test a language design, build parts of its tooling, and revise decisions more quickly, ideas that were once postponed for years become candidates for practical investigation and incremental implementation.

This is where the future I want to explore begins.

I envision some companies establishing teams within their technology departments responsible for developing their internal languages and tools. These teams would begin by understanding what recurs across the company’s products, what consumes developers’ time, and what causes errors. They would then design ways of expressing solutions that more closely reflect the nature of the work.

A multimedia company might need clear language-level concepts for scenes, time, synchronization, and graphics resources. A company operating heavily used backend services might prioritize concurrency, data flow, and request management. An organization with complex business rules might benefit from a language that makes those rules explicit and verifiable.

Some of the organization’s expertise would then become part of its development tools. A type system, compiler, or analysis tool could enforce rules that previously depended on developers remembering them and colleagues checking them during reviews. Every rule that can be expressed precisely and checked automatically creates an opportunity to detect mistakes earlier.

This does not require every company to build a compiler and a library toolchain from scratch. A well-designed library may be sufficient in some cases. A small domain-specific language may be the right solution in others. Performance and control requirements may justify an independent language with a broader toolset. The value of the decision should be measured by the real problems it solves and its ability to remain useful as the team evolves.

As for established programming languages, I expect them to retain important roles in infrastructure, libraries, and existing systems. However, I anticipate that using them directly at every layer of a product will become less necessary, while more room opens above and around them for languages designed to meet particular needs.

This could also change how companies approach updates. A company could determine the pace at which its programming interfaces and internal language evolve according to its products’ requirements, choosing what to add and when to add it. In return, it would assume responsibility for maintaining, documenting, and developing that language, as well as preserving the programs written in it.

Compatibility will remain essential when interacting with operating systems, files, networks, libraries, and external services. Owning the language provides greater control and creates a clearer obligation to protect the company’s software investments from uncontrolled changes.

Another challenge is knowledge transfer. If an internal language depends on one person’s memory or scattered conversations with an AI model, it will become a burden on the organization. A language needs written specifications, correct examples, understandable error messages, and tools that help new team members learn it and use it effectively.

This is precisely where testing the AI itself becomes increasingly important.

It is insufficient for a model to declare that an implementation is correct or to generate tests that merely reflect its own assumptions. There must be defined requirements, expected outcomes, human review, and tests that are as independent as practicable. The model’s ability to fix a defect without breaking another feature must be evaluated, along with its ability to follow the language’s rules without inventing unsupported capabilities and to continue working effectively as the project grows in size and complexity.

Human expertise remains fundamental to this process. The person who defines the requirements, distinguishes a genuine solution from a temporary workaround, and understands why one experiment succeeds while another fails is the person capable of guiding the work toward a dependable outcome.

My experience has deepened my appreciation of this responsibility. AI expands our capacity to implement ideas, but the speed at which it produces code makes design clarity and sound engineering judgment more urgent. The faster we build, the more valuable the direction guiding that work becomes.

For this reason, I believe custom programming language design will become a broader opportunity for developers and companies. Small teams will be able to explore ideas that previously demanded resources beyond their reach. A growing professional specialty may emerge around this opportunity: teams that build languages and tools for specific domains and develop them alongside their users’ needs.

My own experiment is ongoing, and the versions I am working on still require further testing and maturation. Yet the experience has already changed the questions I ask when I encounter a programming problem.

I now ask: How much of the complexity is inherent in the problem, and how much comes from the way we express it through the available tools? Could we design a language that makes the solution clearer, prevents some of its errors, and brings it closer to the developer’s thinking and the nature of the domain?

I believe the time has come to take these questions seriously. The ability to design a language that serves our needs will become an increasingly important part of our ability to build software itself.

I began this journey by exploring what AI could help me build. After three months of work, setbacks, and experimentation, I see a larger opportunity: developers and companies gaining greater power to shape their programming environments, and technical ambitions postponed for years becoming tools that can be built, tested, and placed in people’s hands.