We are all passionate engineers who love to follow our favorite frontend or backend framework, keeping up with new features, releases, or additions. Using various methods, we like to stay up-to-date, attend conferences, read blog posts, and even engage in communities that revolve around a specific framework. However, most frameworks are also tied to a specific language, a programming language most of us (hopefully) have learned to love and are fluent in.
These circumstances haven’t changed for years, even decades, at least not beyond common tech trends and industry standards in the form of Microservices, Event-Driven Architecture, Domain-Driven Design, Serverless, you name it. Our beloved frameworks and languages eventually adapted to the needs of the industry, and we were able to k…
We are all passionate engineers who love to follow our favorite frontend or backend framework, keeping up with new features, releases, or additions. Using various methods, we like to stay up-to-date, attend conferences, read blog posts, and even engage in communities that revolve around a specific framework. However, most frameworks are also tied to a specific language, a programming language most of us (hopefully) have learned to love and are fluent in.
These circumstances haven’t changed for years, even decades, at least not beyond common tech trends and industry standards in the form of Microservices, Event-Driven Architecture, Domain-Driven Design, Serverless, you name it. Our beloved frameworks and languages eventually adapted to the needs of the industry, and we were able to keep using the tools and languages that we hold dear. Picking a different language or framework with similar features remained a matter of preference and personal bias, about which we have probably all, at some point, spent hours arguing over a hot coffee or cold beer.
Brace yourselves: Changes are coming!
Dark clouds of unknowns emerge and a storm of change is brewing. Visible on our horizon are changes that scare us and threaten our existing ways of working and comfort. It’s not a new language syntax or the 100th web framework that I am referring to, but an established language: English. English?? You might ask yourself: how is that a new programming language? English is the language that makes up the training data of most state‑of‑the‑art large language models (LLMs) (1). It’s one of the languages that every LLM is able to speak, but more importantly, it’s the language spoken and understood by most people in the world (2). It is the language of humans. Why should it not also be the language of developing software?
Programming languages have evolved and changed over the past decades. The overall trend in these developments is an increased level of abstraction. Programming languages opened their doors to wider audiences, requiring less deep technical knowledge in the field of computer science. We usually do not need to worry about low‑level hardware optimization like manual memory management with pointers or hand‑crafting registers and stack frames for function calls. Just like me, you probably last heard all these things in university and did a small demo application on a microcontroller to let some LEDs blink like a Christmas tree, beautiful!
The language used was Assembler, which, by my standards, especially while also learning Java and C# in other lectures, seemed quite cumbersome. That’s just one of the reasons why C and later languages like Java and C#, gained popularity. The profession of a software developer quickly shifted toward being able to focus on solving business problems by writing good and clean code, without worrying too much about the underlying low-level details. Heck, we even call it craftsmanship, that’s how proud we are of our “craft”!
Once again, a new, much more drastic layer of abstraction has emerged: Large Language Models (LLMs)! More specifically, with the tools evolving around using LLMs to support engineers and other professionals to “craft” applications. However, this time the evolution is very different, as we are not only changing our flight level and the level of abstraction. We are also moving sideways into non-determinism at the same time (at least at the moment; there are experiments of LLMs being deterministic (3)).
Determinism, especially, is important for us engineers to ease our logic-oriented minds. Running an instruction twice with different outputs is not something we like. Overall, we have achieved a fair amount of abstraction with various frameworks but have not reached the level of being close to human thinking. This changes if we use our native tongue (for example, English) to express our thoughts and turn them into code.
Illustration: Birgitta Böckeler (source: LLMs bring new nature of abstraction)
AI Coding disappoints us?
Hopefully by now you’ve dipped your feet into AI coding using LLMs to supercharge your development workflow. On one day, you’re one‑shotting results for tasks we expected AI to fail (and that would have taken quite some time if done manually); and on another day, you’re trying to solve what seems (to us) like a pretty obvious bug, but the AI completely derails and suggests bits and bytes of garbage.
Overall, our trust and confidence in AI coding tools is dominated by these pivotal (but sometimes first) impressions. We try to wrap our heads around how “good” or “ready” the AI models are and how mature the tooling that uses LLMs is, when we do this only to give ourselves peace of mind and protect our software engineering craftsmanship. Studies show that at the moment software engineers are even less productive due to a high skill ceiling and the learning required when using AI coding agents (4). I am pretty sure all of us went through the same rollercoaster of emotions, for which I have a good analogy displayed as an illustration below. There are various resources on how to get the best results out of AI coding.
Illustration: Geoffrey Huntley (source: What do I mean by some software devs are “ngmi”?)
However, most of the time the simplest advice is to clearly specify your thoughts by translating them to English as input for an LLM. That’s the point I want to touch on: our abilities as software engineers to express our thoughts and plans in English, to make them understandable.
Various memes make fun of the different languages that software engineers and business speak, often cited as reasons for missed deadlines, failed projects, or abandoned products. To cure this, we came up with Domain‑Driven Design practices to align on a so‑called “Ubiquitous Language” inside a domain or “Bounded Context” of our application and system. While speaking at the same level with business, we as software engineers are still translating the domain models, business rules, and specifications into a different language (hopefully the one we are so passionate about!). Need good startup performance and a low memory footprint? It’s fine, we can use a language that has not been specifically designed for that and adjust it so that we do not need to learn a new language. Worst case, it’s a language we were even arguing about in the past years of our professional life.
Instead of focusing on the mere translation into a more technical language, we often let other aspects like observability, testing, and resilience draw the short straw during prioritization. This leads to them inevitably ending up in the “Do eventually” section of our backlogs.
If you followed the last paragraphs, you’re hopefully asking yourself why we translate from English into Programming Language XYZ. We are aligned with our business on a shared language; we put effort into building our architecture to mirror our product domain. Why do we keep translating? Can’t we develop using only English?
Spec-Driven Development
If you feel your software engineer heart hurt when you hear the term “Vibe Coding,” the next lines are especially for you! By Vibe Coding I am referring to the viral idea of a less technical user quickly building and deploying products by conversing with an AI Agent. Vibe Coding scratches the same no-code-utopia itch that has been promised for a long time: making software development accessible in a reliable and scalable way to a wider and less technical audience. “Build me a chat application” as a command rather than a suitable prompt leaves too many questions unanswered.
However, we all know software engineering usually goes beyond what’s achieved in a simple vibe-coding session. Especially if the product matures from an MVP state to a product that requires maintainability and resilience, Vibe Coding quickly reaches its limits and leads to frustration. Bugs are introduced, fixed and then reintroduced. The application is vulnerable to attacks and proves to be unreliable.
How can we keep the language English and use it to generate software in a more reliable way? That’s where the idea of “Spec-Driven Development” comes in (5)(6). AI is (thankfully) bad at mind reading, so we need to be clear when expressing our intent in terms of technical requirements to fulfill the needs of our application and covering our business/domain rules.
So how do we achieve this?
The key difference is that we no longer separate the language used for describing the specifications and the language we use for implementation; instead, we leverage LLMs to do the translation into code for us. We are in charge of outlining the architecture and implementation details by clearly stating our intent as specifications rather than code. By doing this, we stay true to a real shared language across our product development lifecycle, as well as making sure that the technical requirements are documented in a central place and in the language everyone understands.
We are moving from code being the source of truth to intent being the source of truth, staying truly faithful to Domain-Driven Design.
Instead of “vibing” our applications together in a Ping Pong session commanding a new fancy Agent what to do or playing whack-a-mole on bugs, we want to properly outline the specifications of our application. We need to put our analytical and technical thoughts in words and clearly specify our intent to eliminate any ambiguity. The specifications need to be as clear as code and it is up to us to learn how to write them. We implement new features by adjusting the specifications, no longer by touching the code. In contrast to vibe coding where we usually start hitting walls and move to operate on the code level instead.
How about rewriting your application, or, more likely, a part of your system, to another programming language? If done right, and using Spec-Driven Development correctly, this should, in theory, be effortless, at least on a per-component level. You probably guessed it, but that goes hand in hand with the idea of Test-Driven Development (TDD)! It’s even an abstraction of TDD since we should always check our product against the created specifications and use them as the source of truth! We mix the native-language advantages from vibe coding but enrich our instructions with clear intent and high-level technical details. This in itself requires the experience of software engineers to build a sustainable application or system.
Illustration: Dusan Omercevic (source: Beyond Vibe Coding)
Conclusion
Hopefully, my post inspired you to take a step back from low-level technical details and the specificities of languages or frameworks. We engineers usually have brains more tinkered towards logical thinking, and sometimes we have trouble expressing our thoughts in words. Work on your communication skills and how you express your thoughts in a natural language like English. Bring your technical writing skills to the next level to allow AI Agents to do the language to code translation for you.
Focus on understanding the foundations of crafting reliable applications and systems, and do not get carried away by a new syntax introduced in your favorite language XYZ. Let the LLM, and your development process with linting and tests, worry about that! Focus on what’s important and what your product has to fulfill, and let the LLM pick the suitable language that is created for that purpose. Most important, as you do by keeping up with new framework and language version releases, stay curious and keep learning how to use AI coding best in your position.
Will we see more frameworks and languages doing more or less the same things as existing languages but with a different syntax? Unlikely. Most likely we will use the languages the LLM is fluent in and that fit our specifications in the future, and we will need to look for other technical details to argue over hot coffees and cold beers!
Sources
- https://arxiv.org/abs/2404.11553v2
- https://www.ethnologue.com/insights/most-spoken-language/
- https://thinkingmachines.ai/blog/defeating-nondeterminism-in-llm-inference/
- https://arxiv.org/pdf/2507.09089
- https://github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit/
- https://blog.codeplain.ai/p/beyond-vibe-coding
Disclaimer: An LLM was fed with cookies 🍪 to find typos and generate the header image of this post.