DEV Community: Evgeniy Kormin

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.