DEV Community: Evgeniy Kormin

Divide and Let the LLM Do the Rest: From Personal Experience to Architecture

Evgeniy Kormin — Tue, 01 Sep 2026 14:20:23 +0000

Where This Started

A few years ago, I started thinking about a simple question:

How far can we actually push an LLM on a complex software project?

That's already well established. I mean something harder:

Can an LLM take a complex problem, break it into smaller pieces, solve those pieces, test the results, and eventually assemble everything into a working product?

At the time, the conversation seemed to be split between two extremes:

AI is basically useless, although admittedly pretty cool.

and:

AI is the future. Give it a few years and programmers will be gone.

I never really bought either position.
I've always thought that when you throw a genuinely difficult problem at a system, getting 100% right is unlikely. But getting 0% right is unlikely too.
And that's actually interesting. Because if we can reliably measure what worked and what didn't, we can start improving the system instead of arguing about whether AI "works."
So I spent almost a year trying to find that boundary. Almost a Year of Trial and Error

First: Instructions

I started with instructions. A lot of instructions.

The idea seemed straightforward: give the model enough rules and guidance, and let it dynamically select the instructions relevant to the current task.

It didn't work particularly well. The more instructions I added, the harder they became to manage. Eventually, I started getting confused by the instructions — and then the AI started getting confused by them too. So I needed a better way to organize knowledge.

Then Came RAG and "Atomic" Rules

The obvious next step was RAG.

What could go wrong?

Instead of having one giant set of instructions, we could break everything into small, atomic rules and let the AI retrieve the rules it needed.

On paper, this looked great. In practice, it opened up an entirely new set of problems:

How do you actually split the knowledge?
What does "atomic" mean?
How many rules should the model retrieve?
How do we know when it has enough?
What happens when it doesn't have enough?
Where should it search next?
How do we know whether a source is trustworthy?
How do we verify a rule?
What happens when a rule becomes outdated?
What happens when two rules contradict each other?

And that was just the beginning. The same fundamental problem kept coming back.
Once the project grew large enough — around 5,000 lines of code — things started getting difficult again.
The problem wasn't simply retrieving information. The problem was understanding the system as a whole. Maybe the Answer Was Refactoring
My next thought was that we needed some kind of automated refactoring mechanism. But eventually I realized that wasn't quite the right problem either. What I really wanted was a way for the LLM to answer a much more fundamental question:

"How well do I actually understand this project?"

That's when I noticed another threshold. At around 3,000 lines, at least with the models I was using at the time — including DeepSeek V4 Flash — the context would fill up extremely quickly.

Once that happened, every new task effectively became a fresh start. The model could no longer reliably maintain a mental model of the entire project. And that led me to an uncomfortable conclusion. Maybe we shouldn't try to make the software structure equally convenient for humans and LLMs. At least, I didn't know how to do that.

Something had to change.

The First Real Breakthrough

The breakthrough wasn't a better prompt.

It wasn't a better RAG system.
It wasn't a bigger context window.
It was artifacts.

I started using artifacts as a way to make decisions explicit and track what had actually happened during development.

At roughly the same time, I stopped using OpenCode and started building my own IDE. That turned out to be a much bigger decision than I expected.

The Principles

From that point on, I started designing around a few simple principles.

For the User

The user shouldn't need to understand software engineering to use the system.
They might have zero experience building software.

But they should always be able to answer:

What happened?
Why did it happen?
What changed?
What happens next?

For Software Development

The system should prioritize:

Transparency
Verifiability
Falsifiability
Reproducibility

And there was another principle I didn't want to lose:

Don't accidentally build SQL.

This might sound strange, but I've seen the pattern before.

Something starts as:

"Let's manage a database using natural language."

And eventually turns into a massive infrastructure project with layers upon layers of machinery. I didn't want to build an enormous system just to make LLMs slightly easier to use.

The system itself had to remain understandable.

A Real-World Example

Consider a clinic manager.
They probably know exactly how the clinic should operate.

They know:

how the queues should work;
which documents need to be processed;
when those documents need to be processed;
when notifications should be sent;
what happens when something goes wrong.

They may understand the business process extremely well. But turning that knowledge into software normally requires a whole team of specialists.

So here's the question I'm interested in:

How much of that work can we safely move onto the shoulders of AI?

Notice the word safely.

I'm not arguing that we should "give everything to AI."

I'm asking:

Which parts can we delegate?

And I suspect the answer depends much less on the raw intelligence of the model than we currently think.

It may depend on the harness around the model. And on choosing the right artifacts.

Where Could This Lead?

There are several possible outcomes.

Maybe AI Can't Do It

We might eventually discover that reliable task decomposition simply doesn't generalize.

Every real-world problem may be too different.
Maybe there is no universal architecture that makes AI + LLM + harness work reliably.
And maybe, in some cases, hiring an expert will simply be cheaper.

That's a perfectly valid outcome.

Maybe We Get 10–15%

AI might reliably handle only a portion of the work.
Suppose we save 10–15% of someone's time.
That may not sound revolutionary.
But 12.5% is roughly one employee out of eight.
For a large organization, a 10% reduction in labor costs is already a very serious business case.

Maybe AI Becomes an Operator

Perhaps we can delegate a significant portion of operational processes to AI.
Humans supervise the system and step in when necessary.

Think about a power plant operator.

They don't manually control every parameter every second.
They sit at the control panel, monitor the system, and intervene when something requires human judgment.

Maybe software systems will work the same way.

Maybe AI Runs Almost Everything

Take aviation as another analogy.

There are situations where modern aircraft can handle an enormous amount of the actual flight work.

The pilots remain responsible for critical decisions and exceptional situations.

In a future version of this model, humans might spend most of their time monitoring, diagnosing, and handling edge cases rather than continuously operating the system.

Or Maybe We Go All the Way

And there is an even more extreme possibility.
AI handles almost everything. Human experts don't disappear. Instead, they become highly specialized service providers.

A company might only need an expert every couple of weeks rather than having one embedded in the organization full-time.

I don't know which of these futures is correct.
That's exactly what I want to find out.

Let's Build Something and See

This is where I want to start a discussion.
I realize the idea is controversial.
That's fine.
Maybe I'm wrong.
Maybe someone will take these ideas, throw half of them away, and build something much better.

I'd be perfectly happy with that outcome.
But there is one shift in perspective that I think is important.

Code Isn't the Product!

I'd like to move one level higher in abstraction.
We tend to think of code as the final product.
I increasingly think that's the wrong abstraction.
Code is a means of solving a problem.
The actual product is the solution to the client's problem.

If a clinic comes to you because patients are waiting too long, the deliverable isn't "50,000 lines of Python."

The deliverable is fewer problems with patient flow.
The code is just one of the tools used to get there.
That distinction becomes extremely important when we start delegating parts of software engineering to AI.

A Library of Solutions

This leads to another idea I've been exploring:

a library of proven solutions.

Imagine that instead of asking an AI to reinvent everything from scratch, we give it access to a collection of immutable, reusable implementations.

The AI can:

reference an existing solution;
reuse it directly;
adapt it when necessary;
or decide that it doesn't apply.

And each solution could accumulate real-world statistics.

How often was it used?
Did it work?
How often did it fail?
In what environments?
What versions were successful?
That information could become part of the solution itself.

Blockchain might potentially play a role here by providing an immutable record of provenance and history.

I'm not claiming blockchain is automatically the answer.

The important idea is the immutable, verifiable history of a solution, not the technology used to implement it.

Exchanging Knowledge, Not Just Documents

Experts in different domains could exchange knowledge without having to exchange huge theoretical documents. Instead, they could exchange deterministic agents and executable artifacts that demonstrate how their ideas actually work.
Imagine an expert in healthcare building a workflow that captures how a particular clinical process should operate.
Another organization could potentially import that knowledge, inspect it, test it, and adapt it.

Not:

"Here is a 200-page document explaining our methodology."

But:

"Here is a deterministic artifact that demonstrates the methodology. Run it. Inspect it. Test it. Decide whether it is useful."

That feels much closer to engineering knowledge than traditional documentation.

And perhaps that's the bigger opportunity.

Maybe the goal isn't to build an AI that knows everything.
Maybe the goal is to build an environment where AI can reliably use what humans already know.

Divide the problem.
Make every piece explicit.
Let the LLM do what it is good at.
And let deterministic systems, artifacts, and verification handle the rest.

Can software remember expert meaning?

Evgeniy Kormin — Sun, 28 Jun 2026 22:39:49 +0000

We already build systems that remember a lot.

They remember user activity, logs, tickets, code, comments, traces, alerts, and model outputs. They can even remember context across a task. But there is still one thing they mostly do not remember well: the meaning of expert judgment.

That is the interesting question.

What if software could remember which expert was trusted for which kind of decision, preserve the reason behind that choice, and use it later as advice?

Not as absolute truth.
As a living memory of expertise.

Why this question matters

Today, expert knowledge is scattered.

Some of it lives in people’s heads.
Some of it lives in meetings.
Some of it lives in code review comments.
Some of it lives in postmortems.
Some of it disappears completely when someone leaves.

So when a system needs advice later, it usually has to reconstruct the past from fragments.

That is slow.
It is also fragile.

If the system could remember not only what was chosen, but why it was chosen and in what context, that would be a different kind of software.

What the system would need to remember

It would not be enough to store a decision.

A useful memory layer would need to preserve:

who made the decision;
what domain that person was trusted in;
what signals they used;
what the context was;
what the alternative options were;
what made the decision valid at the time.

In other words, the system should remember meaning, not just output.

That is a much harder problem than storing facts.

The danger is not only hallucination

When people talk about AI memory, they usually jump straight to hallucinations.

That is a real concern, of course.
But it is not the only one.

A more subtle risk is stale trust.

The system may remember an expert who used to be right for a specific kind of decision, and then continue to treat that memory as authoritative even after the domain changed.

So the real question is not just:

can the system remember?

It is:

can it remember with context?
can it know when the memory is no longer valid?
can it ask before crossing a boundary?

That matters more than perfect recall.

Advice is better than pretending to know

Maybe the right goal is not a system that “knows.”

Maybe the right goal is a system that advises.

A good memory layer should behave more like an experienced assistant:

it remembers past choices;
it recognizes patterns;
it points to prior expert judgments;
it warns when the situation is outside the known range;
it asks for confirmation when confidence is low.

That is much more realistic than expecting omniscience.

Could this actually work?

Probably, at least partially.

We already have systems that can:

retain working context;
connect related decisions;
reuse prior patterns;
reduce repetition;
surface relevant history.

So the idea is not science fiction.

The open question is whether this can become reliable enough to help real teams make better decisions without pretending that human expertise has been replaced.

Maybe it will work.
Maybe it will fail in interesting ways.

Either outcome would teach us something important:

what kinds of expertise can be preserved;
what kinds of expertise remain too contextual;
where software memory helps;
and where human judgment must stay in the loop.

The deeper question

Maybe the real test is this:

If software could remember the meaning of expert decisions, would it become wiser — or just more confidently wrong?

That is the question worth asking.

Because if the answer is yes, we get a new kind of system: one that can accumulate expertise instead of just accumulating data.

If the answer is no, we still learn where the limits are.

And that is useful too.

Code Is Cheap. Understanding Is Expensive

Evgeniy Kormin — Sun, 28 Jun 2026 21:30:17 +0000

We spent decades treating code as the primary bottleneck in software development. Writing it, reviewing it, shipping it — that was the hard part.

That assumption is now outdated.

Today, code is cheap. Understanding is expensive.
The bottleneck moved

With modern tools — especially AI-assisted ones — generating code is no longer the limiting factor. You can produce hundreds of lines in seconds. Boilerplate is trivial. Even non-trivial implementations are increasingly accessible.

But something didn’t get faster.

Answering questions like:

Is this correct?
Is this safe?
Will this break something subtle?
Does this match the real-world constraints?

Those are still slow. Sometimes painfully slow.

Because these are not questions about code.
They are questions about understanding.
Code was never the real asset

We like to think code is the system. It isn’t.

Code is a compressed representation of:

past incidents
production failures
edge cases
domain-specific constraints
decisions made under uncertainty

When a senior engineer reviews a pull request, they are not checking syntax. They are pattern-matching against all of that invisible context.

That’s why a simple change can take hours to approve.

Not because it’s long.
Because it’s ambiguous.
Example: a “simple” change

Imagine a change in a payment system:

“Retry failed transactions up to 3 times.”

Looks reasonable. Easy to implement. An AI can write it instantly.

But an experienced reviewer will pause.

Questions start appearing:

What kinds of failures?
Idempotency guaranteed?
Could this double-charge?
What happened the last time we retried blindly?
Are there regulatory constraints?

None of that is visible in the code itself.

The real logic lives in:

past incidents
tribal knowledge
unwritten rules

The difficulty is not writing the retry loop.
The difficulty is knowing whether it should exist at all.
The illusion of productivity

If code generation becomes 10x faster, it feels like productivity increased.

But in many teams, something else happens:

More code is produced
Review becomes harder
Systems become less predictable
Knowledge becomes more fragmented

You don’t remove the bottleneck.
You move it — and often amplify it.

From “writing code” to “understanding consequences.”
Understanding is not intuition

We often rely on phrases like:

“This feels right”
“We’ve always done it this way”
“I think it should be fine”

That’s not understanding. That’s intuition.

And intuition does not scale:

it’s not transferable
it’s not auditable
it’s not reproducible

If two engineers look at the same change and reach different conclusions, the system depends on who you ask, not on what is true.

That’s fragile.
What real expertise looks like

Real expertise is not the ability to write code quickly.

It’s the ability to:

reconstruct the reasoning behind a decision
connect code to past incidents
identify missing information
explain why something is safe or unsafe

In other words:

Given the same inputs, an expert should be able to produce the same decision — and show why.

That is closer to a system than to intuition.
Where this leads

If code is cheap and understanding is expensive, then improving developer productivity is no longer about generating more code.

It’s about:

making decisions traceable
turning incidents into reusable knowledge
extracting patterns from reviews
reducing reliance on implicit memory

Because the real risk is not that we can’t write code.

The real risk is that we write more than we can understand.

Golden Armada: What AI-Native Software Looks Like in Execution

Evgeniy Kormin — Thu, 18 Jun 2026 12:04:51 +0000

👉 Source code & system:

golden_armada
Programming-Paradigm-for-AI-Written-Software

👉 Previous article (context):

a vibe coding programming paradigm

What happens when software is no longer primarily written — but executed through AI-driven decisions?

In this article, I want to show a working system and what it actually produces at runtime.

No manifesto. No theory expansion.

Just execution.

Context: from “vibe coding” to runtime reality

In the previous article I introduced the idea of vibe coding — a programming paradigm where AI becomes the primary code generator and the human shifts toward intent specification rather than implementation.

That idea raises an immediate question:

What does such a system actually look like when it runs?

Golden Armada is my attempt to answer that question experimentally.

What is Golden Armada?

Golden Armada is an AI-native workflow engine where:

a user triggers actions through a structured UI
an LLM (“DeepAgent”) plans execution steps
a strict contract system applies mutations
every action is recorded as an immutable trace

The key idea is simple:

The system is not understood through code — but through execution traces.

Architecture overview

The system follows a strict execution pipeline:

User Action
   ↓
Intake Layer
   ↓
Workflow Loading
   ↓
LLM Planning (DeepAgent)
   ↓
Operation Execution
   ↓
Event Store Append
   ↓
Trace Flush

Key constraints:

all operations are strongly typed
execution is deterministic after planning
state changes are event-based
everything is observable

This is intentionally closer to an execution machine than a traditional application.

Why traces matter more than code

In traditional systems, debugging means reading code and inferring behavior.

In Golden Armada, debugging means:

reading execution traces and reconstructing system behavior

This is closer to how distributed systems already work — but extended to AI-driven decision layers.

Real execution trace (example)

Below is a real trace produced by the system:

trace_id: ea7e24fc11dc43bdbfeacedbc628e9fd

[OK] Request received
button=split_node

[OK] Workflow loaded
workflow=wf_001 v1

[OK] Agent planning stage
operation=split
node=split

[OK] Event store append
patch_applied=true

[OK] Handler executed
duration: 0ms

Total duration: 29.7s

👉 Full logs available here:
https://github.com/evgeniykormin86-stack/golden_armada/tree/main/logs

What this trace shows

Even in this small example, we can observe:

where time is spent (LLM planning dominates)
how deterministic execution follows planning
how workflow mutation happens via operations
how the system maintains auditability

The important shift is:

The runtime becomes the primary interface of understanding.

Failure case (equally important)

Not all executions succeed.

Example:

[ERR] Node not found: split

This trace shows:

LLM correctly planned an operation
but workflow state did not match expectation
system failed deterministically during execution

This is important:

AI planning is not the same as system validity.

Design philosophy behind the system

Golden Armada is built around four constraints:

AI changes duplication cost. New behaviors can be introduced by generating new “skills”, not rewriting core logic.
Graph complexity is intentionally constrained. Workflow depth is limited to avoid exponential reasoning complexity.
Contracts replace implicit structure. All communication between components is strictly typed and validated.
Observability is a first-class feature. If it is not traceable, it does not exist in the system.

What this system is NOT

To avoid misunderstandings:

it is not an autonomous agent system
it is not production-ready infrastructure
it is not a replacement for software engineering
it is not a fully self-evolving system

It is:

an experimental execution environment for AI-driven workflows with full observability.

Why this matters (core insight)

Most AI systems today fail not because they cannot generate output — but because:

their internal decision process is not observable or reproducible.

Golden Armada explores a different direction:

make execution observable first, intelligent second.

Limitations (important for honesty)

Current limitations include:

limited scale of workflows
non-deterministic LLM planning
trace volume grows quickly
debugging still requires human interpretation
system complexity increases with feature expansion

This is expected at this stage.

Future direction

Next steps in this experiment include:

automatic test generation from traces
failure clustering and pattern detection
trace-based debugging UI
regression testing from execution history
contract evolution based on observed failures

Closing thought

Golden Armada is not an answer.

It is a question:

What does software become when execution, not code, is the primary artifact?

We are still early — but we can already observe meaningful structure emerging from runtime behavior.

Vibe Coding Bible: A Programming Paradigm for AI-Written Software

Evgeniy Kormin — Mon, 15 Jun 2026 18:49:49 +0000

Vibe Coding Bible: Rethinking Software Architecture for AI-Generated Code

For the last year I noticed something consistent while working with AI-generated code.

The more I used AI to write code, the more my systems started to break in a very specific way:

small changes caused unexpected side effects
refactoring became increasingly risky
context grew until it became difficult to manage
AI sometimes “helped” by breaking nearby modules
fixing one thing often broke something else

At some point I stopped thinking of this as a prompt engineering issue.

It felt more like a fundamental mismatch in the programming model itself.

The core mismatch

Most software architecture today is built around one assumption:

humans are the primary authors of code

We expect that:

humans can understand the system over time
humans can safely refactor large dependency graphs
humans can maintain mental models of complexity
humans can coordinate changes across modules

This works reasonably well when humans are the main drivers of development.

But with LLMs involved, a different behavior emerges:

every interaction effectively starts from a partial or reconstructed context

Even if the full codebase exists, the model operates with limited visibility at any given moment.

As systems grow, this leads to predictable patterns:

increasing coupling
fragile refactoring
hidden dependencies
loss of global consistency

The idea behind Vibe Coding Bible

This led me to a different question:

What if we design software assuming AI is the primary code author, and humans are system designers?

That shift changes many assumptions.

Some familiar practices start to behave differently:

flexible interfaces become harder to reason about
deep abstraction layers introduce fragility
refactoring increases cognitive cost
shared mutable structures amplify unexpected behavior

Core principle: nailed interfaces

The central idea is simple:

interfaces should not evolve

Once defined:

they are never modified
they are never extended
they are never refactored

If requirements change, we do not modify the interface.

We create a new block with a new interface.

Even if it feels redundant.

Because AI makes duplication cheap — but coupling remains expensive.

Block structure

Every unit of code is a block:

interface.py → immutable contract
implementation.py → AI-generated logic
tests.py → optional generated tests

Key rule:

the interface is frozen forever

No exceptions.

Tree instead of graph

Most real-world systems naturally evolve into dependency graphs:

modules depend on each other
dependencies spread in multiple directions
small changes produce system-wide effects

In AI-heavy development, this becomes especially unstable.

So instead we enforce a simpler structure:

strict tree hierarchy
level-based imports only
no cross-branch dependencies
no lateral coupling

This is not elegant.

But it is predictable.

And predictability matters more than flexibility when AI writes most of the code.

No refactoring rule

In this model:

If something is wrong:

we do not refactor it
we replace it

If behavior changes:

we do not extend existing modules
we create new ones

If an interface no longer fits:

we do not modify it
we define a new block

At first this feels inefficient.

But the cost model shifts:

writing new code is cheap
managing coupling is expensive

So we optimize for regeneration instead of evolution.

What changes for developers

In this model, developers stop being:

refactorers
dependency graph managers
large-codebase navigators

And become:

system decomposers
interface designers
constraint engineers
AI operators

The job shifts from writing code to shaping boundaries.

Migration strategy

Existing systems are not migrated directly.

Instead:

freeze problematic modules
stop modifying legacy code
build new AI-native blocks alongside it
gradually shift functionality over time

Legacy code becomes background context, not something to constantly fix.

This is not a universal rule

This is an experiment.

It may not apply to all systems.

Some domains may still require:

complex shared state
deep optimization
tightly coupled systems

But in many AI-heavy workflows, traditional assumptions start to break down.

Why I’m writing this

I call this experiment:

Vibe Coding Bible

It is not a finished framework.

It is a set of assumptions I am testing in practice.

Related projects

Programming paradigm for AI-written software:

https://github.com/evgeniykormin86-stack/Programming-Paradigm-for-AI-Written-Software
Incident-driven AI system (Golden Armada):

https://github.com/evgeniykormin86-stack/golden_armada

Final thought

The question I’m exploring is simple:

What does software architecture look like when AI becomes the primary programmer?

This is one possible answer.

Not the final one.

But a starting point.