We are writing more and more code whilst creating less and less of actual value. Unpredictable Machine is a platform for the research and development of new tools and approaches to building the next generation of web-based applications. We believe current software development is optimized for maintaining complexity, not reducing it.
Core Thesis: Logic over Boilerplate
Unpredictable Machine explores how web applications should be built when LLMs become part of the development process. We explore and design tools and principles that bring the focus back to core logic and prevent developers from getting lost in tonnes of code handling common routines.
Historical Burden
The web began a trend of shifting tools into online services and client-server applications. Today, we routinely see vast e-commerce platforms and large enterprise solutions running directly in browsers. Modern software is overloaded with dependencies, abstractions, and framework complexity. This significantly increases the cognitive load on the entire development team and forces us to describe business logic using an overwhelming amount of boilerplate code.
The Paradox of Efficiency
With the arrival of language models — no longer mere chatbots recommending dumpling recipes, but powerful agentic systems — the rules of the game are changing. IT companies rejoice at how AI will automate their routines. Most discussions around AI focus on productivity gains, not structural simplification. Yet very few pause to consider whether their underlying infrastructure is sound, or whether they can even navigate it properly.
What is the point of automating a process that could be eliminated entirely?
AI itself does not reduce complexity. It amplifies the quality of the underlying system. If the development process is built around increasing abstraction, excessive dependencies, and task-oriented delivery, AI will accelerate those patterns rather than eliminate them.
Large language models require a different environment. They work best with clear context, explicit boundaries, and predictable architecture — not with sprawling layers of framework-driven complexity.
Used correctly, AI allows developers to focus on business logic and actual product value instead of maintaining infrastructure noise.
We are already seeing the first attempts at AI-driven development defined through skills and agent instructions. What is missing, however, is the foundational element — an architecture to build upon, one that sets clear boundaries for the agent. Skills without architecture are merely better boilerplate. The agent can generate code without understanding the system it modifies.
Shifting the Paradigm
To break this cycle, we must shift our focus from technical implementation back to pure business logic. Convenience has historically won over simplicity, leading the industry into a dead end of over-engineered patterns. We build on a fundamental premise: applications should, above all, be simple. The development team must be empowered to ask what to build, not how to wire it together.
Our approach is defined by three core principles:
Our Principles
1. "What" is more important than "How" (Intent over Implementation)
We believe the development team should define the target state and business logic, rather than spending time writing instructions for machines. If we clearly describe what the application should do, we create the conditions for modern systems to take care of how to execute it technically.
Specification → Schemas → Logical Graph → Interpreter
2. Schema as a Common Language (Human-AI Interface)
The future of development lies in applications defined through intent and schemas understood by both humans and machines. We are moving away from writing thousands of lines of code and towards modelling digital structures. The schema is the source of truth from which AI generates functional interfaces and data layers.
3. Radical Separation (Pure Logic)
We test concepts where the UI and data layer are strictly separated from the core system on the basis of a predefined architecture. There are domains where ignorance of the implementation is a desirable property — security, payments, integrations. A schema-defined component is not a constraint; it is an intentional boundary. Neither the agent nor the developer reaches inside — they simply call its API. Business logic should not be burdened by the framework; the framework's role is to serve as the skeleton of the application, not its dead weight. Only through this clarity can AI work with context effectively.
Intentional Boundary
Consider a straightforward example: user registration and login. A developer has at least three options. Use a third-party library — the agent sees thousands of lines, cryptographic details, edge cases, and this is precisely where mistakes happen. Use a ready-made OAuth server — cumbersome, complex configuration, high cognitive load. Or use a component with a clearly defined schema: register, login, verify. Neither the agent nor the developer needs to know how hashing works — they need to know what the component does. That is the intentional boundary. And within it lies both security and simplicity at once.
Setting Out on a New Path
We stand at a crossroads. We will either use AI to generate increasingly complex software faster, or use it to reduce the amount of software we need in the first place. Let us find the courage together to define effective ways of creating genuine added value in a symbiosis of engineers and machines.
We are building the skeleton — architecture, schemas, and contracts — that gives developers and AI systems a shared foundation for building applications.
The future of software is not more abstraction.
It is less unnecessary complexity.
Continue to Delegating Responsibility to Machines.