DEV Community: Valentyn Ivanov

The power of mental models for developers

Valentyn Ivanov — Tue, 08 Sep 2026 13:34:30 +0000

Down the memory lane

Some developers don’t understand memory.
They understand new, delete, or garbage collection. And again — that’s just the surface.

Memory is not a flat, uniform space.
It’s a hierarchy:
• registers
• multiple levels of cache
• RAM
• virtual memory managed by the OS
Each layer has different latency and behavior.

But we usually learn memory management like this:
“allocate object → use it → free it”
So we assume: as long as memory is “managed”, everything is fine.
It’s not.

Performance is often dominated by:
• cache locality
• allocation patterns
• fragmentation
• allocator contention

That’s why two identical algorithms can have wildly different performance
depending on how data is laid out in memory.

Using smart pointers doesn’t mean you understand memory. It means you’ve delegated part of the problem. Which is fine — until it isn’t.

If you care about performance, you need to understand:

how data moves,
how it’s cached, and how it’s allocated.

Because in the end:
It’s not about what your code does.
It’s about how it lives in memory.

Building blocks

Data types are one of the most misunderstood fundamentals.
Because we don’t really learn what they are.

We learn their names: int, float, bool - feel like simple building blocks.
But underneath, they are:
• bit patterns
• rules of interpretation
• operations defined over those bits
Without that model, decisions become guesswork.

Like using signed integers for sizes.
A size is a count. It cannot be negative.

But if your type allows negative values, you’ve already introduced invalid states into your system.
This leads to subtle bugs:
• overflow issues
• signed/unsigned comparison traps
• edge cases that “should never happen” — but do

The deeper issue is this:
A type is not a label. It’s a constraint on reality.

If you don’t understand:
• binary representation
• overflow behavior
• how arithmetic actually works at the hardware level
then you’re not choosing types. You’re guessing.

And sometimes guessing is enough.
Until it isn’t.

We teach developers what to write.
We rarely teach them what it means.

Concurrency

Some developers don’t learn concurrency. They learn async/await or whatever concurrency utilities their favorite language or framework provides. And those are not the same thing.

Threads are not a language feature. They exist at the OS level, run on physical CPU cores, and compete for shared memory and cache.

But many of us first encounter concurrency through: Python, C++, Java, or some framework API.
So our mental model becomes: “this is how concurrency works.”
It’s not.
It’s just how one runtime exposes it.

That’s why things feel unpredictable:
• “Why do I still get race conditions?”
• “Why is my async code slower than sync?”
• “Why doesn’t this scale across cores?”
Because underneath:
• the OS scheduler decides who runs
• context switching is not free
• cores share memory with non-uniform latency
• caches can invalidate each other

If you don’t understand that layer, you’re not really reasoning about concurrency.
You’re just using it.

To be clear — that’s fine at the beginning.
But the moment you care about performance or correctness under load,
you have to go down the stack.

Hardware → OS → runtime → language.
Not the other way around.

Otherwise you’re not solving concurrency problems.
You’re operating an API.

Abstractions are just tools

In previous chapters I talked about:
• concurrency
• memory
• data types

At first glance, these look like different topics.
They’re not.

They all share the same root problem:
We learn abstractions… without understanding what they abstract.

We learn:
• async/await instead of how threads are scheduled
• new/delete instead of how memory behaves
• int/float instead of how data is represented

So our mental model becomes: “this is how the system works”
When in reality: “this is how one layer exposes it”

And most of the time, that’s enough.
Until it isn’t.

The cracks appear when:
• performance matters
• systems scale
• bugs become non-deterministic
• behavior stops matching intuition

That’s when abstraction stops helping and starts hiding the problem.

This doesn’t mean everyone must become a hardware engineer.
But it does mean:
If you want to reason about systems, you need to understand the layers below them.

A simple rule that helped me:
When something feels “weird” or unpredictable — you’re probably missing a layer in your mental model.

Go one level deeper:
hardware → OS → runtime → language.
That’s usually where the answer is.

Abstractions are tools.
But understanding is leverage.

Mental model

A fair question may come up:
“How do I actually learn all these lower layers without going down a 5-year rabbit hole?”

Short answer:
You don’t need to learn everything. You need to learn just enough to build a mental model.

Here’s what actually works.

Learn one layer below your current work
If you’re writing application code → learn runtime behavior
If you’re using runtime features → learn OS basics
If you’re already there → peek into hardware
Don’t jump straight into CPU manuals. Go one step down.
Learn through problems, not theory
Don’t start with textbooks.
Start with questions like:
• “Why is this slower than expected?”
• “Why does this break under load?”
• “Why does this behave differently on another machine?”
Then dig until you hit the real cause. That’s where learning sticks.
Build small, focused experiments
You don’t need big projects.
Try things like:
• write a tiny thread pool
• measure cache effects with different data layouts
• intentionally create a race condition and observe it
• compare contiguous vs scattered allocations
You’ll learn more from one experiment than from hours of passive reading.
Use tools that show reality
Start simple:
• profilers (CPU, memory)
• timing measurements
• system monitors
Look at what the system is actually doing — not what you think it’s doing.
Accept partial understanding
You don’t need to master everything.
If you walk away knowing:
• caches exist and affect performance
• threads are scheduled, not “run” by your code
• memory is not uniform
you’re already ahead of most developers.
Go deeper only when it pays off
Not every problem needs low-level knowledge.
But when something feels:
• slow
• unpredictable
• “magical”
that’s your signal to go down a layer.

You don’t need to become a systems expert.
But you do need to know when the abstraction stops being enough.
That’s the real skill.

Embedding a web UI into a native desktop application comes with a price

Valentyn Ivanov — Mon, 07 Sep 2026 12:45:20 +0000

I thought embedding a web UI into a native desktop application would be the easy part.
After all... macOS has WebKit. Linux has GTK WebKit. Windows has WebView2.

One API per platform, smaller installers, native look & feel. Sounds perfect.
Then reality arrived.

macOS 🍎

Honestly, this was the easiest platform.
System WebKit is there.
It behaves consistently.
No additional runtime.
No installer surprises.
Exactly what you'd expect from a platform component.
10/10

Linux 🐧

Things became... more interesting.
GTK WebKit works, but suddenly packaging starts to matter.
An AppImage built on one distribution may refuse to start on another because some required WebKitGTK library isn't available.
Your application itself is perfectly fine.
The user's system just doesn't happen to provide exactly the version your build expects.
You quickly discover that "works on my machine" has many regional dialects.
7/10

Windows 🪟

This one surprised me the most.
Unlike macOS, the web view isn't really just "there."
Using WebView2 means depending on the Edge WebView runtime.
If the runtime isn't installed, congratulations—you now need another installer.
So your installer may install something whose purpose is to allow your application to display HTML.
Not exactly the dependency story I was hoping for.
2/10

Meeting in the middle

At some point I asked myself:
Why am I spending time debugging operating-system packaging instead of building my application?

So I tried CEF (Chromium Embedded Framework).
Yes...
The application becomes larger.
Quite a bit larger.

But in exchange:
• Same rendering engine everywhere.
• Same JavaScript engine everywhere.
• Same debugging experience.
• Same HTML/CSS behavior.
• No Linux WebKit dependency lottery.
• No separate WebView runtime installation on Windows.
• One code path across all desktop platforms.
Ironically, shipping your own browser turned out to be simpler than relying on the browser already "provided" by the operating system.
It's one of those engineering decisions that looks wasteful on paper but ends up reducing complexity everywhere else.
Sometimes carrying the extra megabytes is cheaper than carrying platform-specific surprises.

Curious what others have settled on.

Are you using native web views, CEF, or something else for cross-platform desktop applications?

A Generative UI approach for Human/AI interaction

Valentyn Ivanov — Thu, 03 Sep 2026 12:27:25 +0000

The "Gulf of Execution" in AI chat is real - and it’s exhausting.

Staring at a blank prompt box, trying to engineer the perfect text, and back-and-forth messaging just to tweak a setting? That’s not productivity. That’s friction.
Chatting about work isn't the same as doing work.

The fix? Generative UI.

Instead of forcing users to type everything out, AI should build the interface on the fly:
Card-based UI: Quick, scannable micro-actions over walls of text.
Auto-generated forms: Pre-fill what the AI knows; let the user tweak the rest in two clicks.
Custom applets: Drop mini interactive tools right into the thread when visuals or calculators matter.

If I ask an AI to configure a project, compare several options, review a diff, or choose from a tree of files, why should it respond with another wall of text?

The model can decide to create a form, table, selector, confirmation dialog, diff view, etc. — without being specifically trained for GUI generation.
The UI is retained locally, so sliders, checkboxes, typing, and other low-level interaction don’t require another LLM call. Only meaningful events such as Submit, Confirm, or Explain go back to the model.

So the flow becomes:
LLM → UI tools → interactive UI → semantic event → LLM
instead of endless:
LLM → text → user → text → LLM
It feels a little like “Dear ImGui for AI agents.”

Open standards like A2UI (Agent-to-User Interface) are making this seamless - letting agents output clean UI components directly into any app, not just text strings.

The next era of AI UX isn't teaching people to prompt better. It's building interfaces that get out of the way.

Are you still building pure chat, or moving toward Generative UI?

I for one built a small PoC library allowing to expose custom UIs to ChatGPT and similar AIs. Imagine running the whole CAD or 3d slicer or video editor INSIDE the chat window.

You can even play Pong while boss is not looking!

Here's the link to the library: Agent UI

Pong:

Configure CMake UI:

I Tried Needle2 for Local Tool Calling. I Ended Up With llama.cpp + Granite

Valentyn Ivanov — Tue, 01 Sep 2026 19:35:36 +0000

I’ve been working on a small experiment around a semantic shell.

The basic idea is that the user types something like:

copy report.pdf to backup

and a small local model maps that to a known tool:

filesystem.copy

The shell then takes over. It validates arguments, asks for missing ones, shows confirmation UI when needed, and finally executes the operation.

The model is not supposed to generate shell commands. It only needs to understand intent.

That sounded like a very good fit for Needle2.

Needle2 is tiny, focused on tool calling and structured extraction, and designed to run locally. On paper it looked almost purpose-built for what I needed.

So I tried it.

The first version worked. Then I started adding more realistic cases.

And that’s where things became more interesting.

Five tools is very different from fifty

Most examples of tool-calling models are some variation of:

turn on the kitchen light

with two or three tools available.

That’s fine as an API example, but it doesn’t tell you much about how the model behaves in a real application.

Even my first filesystem package already had things like:

filesystem.copy
filesystem.move
filesystem.delete
filesystem.create_file
filesystem.create_directory
filesystem.list_directory
filesystem.navigate
filesystem.current_directory
filesystem.find

Needle2 uses retrieval when the number of tools gets larger. It selects a small candidate set and then resolves the tool from there.

That makes sense.

But it also means there are really two decisions now:

Which tools should be considered?

and then:

Which of those tools is the right one?

If the correct tool does not make it into the shortlist, the second stage never gets a chance.

For many applications that may be perfectly acceptable. In my case I wasn’t comfortable relying on it without knowing more about how often it happens.

I started thinking about bypassing retrieval entirely by dividing tools into groups of five and running all groups.

Needle is small enough that this is not completely ridiculous.

Something like:

group 1 -> result
group 2 -> result
group 3 -> result
...

then take the strongest candidate.

But immediately another question appears.

Are confidence scores from different candidate groups actually comparable?

Maybe they are. Maybe they are not.

I couldn’t find enough information to feel confident about treating them as globally calibrated scores.

That does not make Needle bad. It just means that once you move away from the demo path, you start needing answers that are not obvious from the examples.

Tool descriptions matter a lot

Another thing I learned quickly was how sensitive a small model is to tool descriptions.

A description like:

Moves files from one place to another.

is not enough if the neighboring tools are:

filesystem.copy
filesystem.navigate
filesystem.rename

You need to be explicit.

For example, “move” should probably say that the original item no longer remains at the source, and that this is not the same thing as changing the shell’s current directory.

The descriptions start looking less like documentation and more like a tiny classification dataset written in English.

That was workable, but it changed how I thought about the model.

It is less “small agent” and more “probabilistic semantic parser with a constrained vocabulary.”

Which is actually fine for this use case.

Then I tried the C++ runtime

For the shell itself I wanted native integration.

No Python process on the side, no extra service, and no awkward lifetime management. The C++ library looked like the right way to do it.

This is where I hit the biggest practical problem.

I was developing on an Intel Mac.

The Cactus Engine code contains ARM NEON includes and intrinsics in many places. Not just one isolated backend file, but spread through engine and kernel code.

That surprised me.

If ARM is the main target, this is understandable. iOS, Android, and Apple Silicon are all important platforms.

But from my side it meant x86 support was not just a matter of enabling another optimized backend.

I ended up spending time patching things simply to answer a much more basic question:

Is Needle good enough for my use case to justify carrying this dependency?

At that point I decided to try a different route before spending more time on the port.

llama.cpp and Granite

So I integrated llama.cpp.

Then I tried Granite 4 350M for the same tool-calling task.

I expected this to be more of a baseline than a solution.

It turned out to work better than I expected.

For the normal cases it selected the tools I wanted.

More importantly, I tried a few deliberately awkward inputs where no good tool really existed, and instead of forcing a call it simply failed to find one.

For my application, that is good behavior.

I would much rather see:

No suitable tool found.

than a confident guess.

The shell can recover from that.

It can ask the user to rephrase, narrow the scope, or choose between two possible interpretations.

A wrong tool call is much harder to recover from once you start dealing with destructive operations.

This changed the architecture less than I expected

The funny part is that switching models did not really affect the shell design.

The important part was already outside the model.

The flow is roughly:

user input
    ↓
intent resolution
    ↓
known semantic capability
    ↓
argument validation
    ↓
ask for missing arguments
    ↓
policy / confirmation
    ↓
execution

If the user says:

copy file

the model only needs to resolve:

filesystem.copy

The shell can notice that source and destination are missing and show proper selectors.

If two tools are plausible, for example copy versus move, the shell can show two buttons.

There is no need to force the model to solve every ambiguity.

That ended up being one of the more useful conclusions from the experiment.

A small local model does not need to be brilliant if the surrounding system is designed to handle uncertainty.

The part I wish documentation focused on more

I still think Needle2 is interesting.

What I missed was more information about the edges.

Not another:

turn on the light

example.

I wanted answers to things like:

how accuracy changes as the tool catalogue grows;
how often retrieval drops the correct tool;
whether confidence remains comparable across different candidate sets;
how similar tools should be described;
what happens on no-match input;
how confidence behaves on incorrect calls;
how much fine-tuning helps with ambiguous tools;
what the realistic native-platform support is.

Those details are not as flashy, but they are what decides whether something works in a real system.

The same applies to structured extraction.

Showing that a model can extract an invoice total is useful.

Showing how it behaves when there are subtotal, tax, total, previous balance, OCR errors, and two dates on the same page is much more useful.

Where I am now

For the moment I’m continuing with:

llama.cpp
Granite 4 350M
typed semantic tools
deterministic argument resolution
small contextual UI
policy-controlled execution

That does not mean Needle2 is a bad model.

It may be an excellent fit for the platforms and use cases Cactus is targeting.

It just stopped being the obvious choice for mine.

And that was probably the main thing I got from the experiment.

A component can look almost perfect from the feature list and still be the wrong foundation once you start testing the boring parts: portability, failure modes, ambiguity, scaling, and integration cost.

For this kind of software, I’m becoming much more interested in how a model fails than in how impressive its best demo looks.

Stop Calling Tribal Knowledge “Collaboration”

Valentyn Ivanov — Fri, 21 Aug 2026 10:45:28 +0000

Developers have a strange relationship with documentation.

We love well-documented libraries.

We appreciate clear APIs, useful examples, configuration references, migration notes, architecture diagrams, and a README that tells us what we actually need to know.

Then we look at our own codebase and suddenly documentation becomes outdated.

“The code should explain itself.”

“If you need to know something, just ask.”

And sometimes teams take this even further.

They turn the lack of documentation into a virtue. The argument goes something like this:

We don’t document everything because we want developers to communicate with each other.

At first, this sounds reasonable. Software development is collaborative. People should talk. Knowledge shouldn’t live in isolated silos.

But there is a problem. Asking the same question for the tenth time is not collaboration. It is a missing database query.

Meet John and Jack

John is working on a service he hasn’t touched before. He sees this in the deployment configuration:

MAGIC_SERVICE_MODE=2

There is no comment. No documentation. No example. No explanation in the repository.

But Jack knows what it means. Jack implemented it three years ago. Unfortunately, Jack lives in another time zone. So John asks him on Slack. Then John waits. Maybe for an hour. Maybe for six.

Eventually Jack wakes up, reads the message, remembers what the variable means, and answers.

John continues working. Problem solved. Except it isn’t.

Two weeks later, Mary encounters the same variable. She asks Jack. A month later, Peter joins the team. He asks Jack. Then a production issue happens and someone from another team asks Jack.

At this point we should stop pretending this is a healthy communication culture.

Jack has become infrastructure.

More specifically, Jack has become a very inefficient distributed database with terrible availability characteristics. And Jack is constantly being interrupted by SELECT queries.

Communication Has a Cost

There is a tendency in software teams to treat communication as free.

It isn’t.

Every question has at least two costs.

The person asking has to stop what they are doing and wait for an answer. The person answering has to stop what they are doing and reconstruct the context.

Sometimes that cost is tiny. Sometimes it destroys half an hour of concentration. Now multiply this across a team.

“What does this environment variable mean?”

“Which database do we use in staging?”

“Why is this timeout set to 17 seconds?”

“Can I run this service locally?”

“Which of these three endpoints is still supported?”

“Why can’t this component be deployed independently?”

“Who owns this?”

If these questions are asked once, that is normal. If they are asked repeatedly, the problem is not communication. The problem is missing documentation.

Documentation Does Not Replace Communication

This is the part that often gets lost. Good documentation is not an alternative to communication. It creates space for better communication. There are things developers absolutely should discuss.

Should we split this service?

What consistency guarantees does this protocol need?

Should this API be synchronous or asynchronous?

What are the failure modes of this architecture?

How do we migrate this without downtime?

What trade-off are we making between latency and complexity?

These are valuable conversations because the answer does not already exist. The participants are creating something new together.

That is collaboration.

Asking someone what an environment variable means is not collaboration. It is information retrieval. And information retrieval should usually not require another human being.

Tribal Knowledge Feels Fast Until It Doesn’t

A poorly documented team can actually feel very productive for a while. Everyone knows everything. The original developers sit next to each other. Questions get answered in seconds. Decisions happen verbally. Nobody wastes time writing things down. Great velocity.

Then the team grows. People leave. People work remotely. A service moves to another team. Someone goes on vacation. Someone gets sick. A new developer joins. Now the invisible dependency graph becomes visible. Half the system depends on three people remembering why things work the way they do.

The organization discovers that what looked like velocity was actually borrowing against the future.

And now the interest is due.

“The Code Should Be Self-Documenting”

There is some truth in this idea.

Good names matter. Clear abstractions matter. Readable code matters. Comments should not explain what perfectly obvious code already says.

But code can only explain so much.

Code can tell you what it does. It often cannot tell you why it exists. It cannot always explain why another seemingly simpler approach was rejected. It cannot explain operational assumptions. It cannot explain which weird production incident caused that strange validation rule. It cannot tell a new developer which parts of the system are historical leftovers and which ones are intentional architecture.

And it certainly cannot explain what MAGIC_SERVICE_MODE=2 means to someone who does not already know.

The best code and the best documentation solve different problems.

“But Documentation Gets Outdated”

Yes.

So does code. So do tests. So do dependencies. So do deployment scripts.

We do not stop writing tests because they might become outdated. We maintain them because they are useful.

Documentation should be treated the same way.

The real question is not whether documentation can become stale. The question is whether the cost of maintaining it is lower than the cost of repeatedly rediscovering the same knowledge.

For important parts of a system, the answer is very often yes.

And documentation does not need to mean a thousand-page specification. Sometimes the right documentation is five lines next to the configuration. Sometimes it is a short ADR. Sometimes it is a diagram. Sometimes it is a README explaining how to run the service. Sometimes it is one sentence saying: MAGIC_SERVICE_MODE=2 enables compatibility mode for the legacy billing pipeline. Do not change it without coordinating with Billing.

That sentence might save hours of future interruptions.

The Goal Is Not More Documentation

This is important too.

The goal is not to produce documentation for its own sake. Nobody needs another abandoned wiki full of pages nobody reads.

The goal is to remove unnecessary dependence on human memory. Write down the things people repeatedly need. Write down the things that are surprising. Write down decisions whose reasoning will otherwise disappear. Write down operational knowledge that someone will desperately need at 2 AM. Write down information that crosses team boundaries.

And keep it close to the thing it describes whenever possible.

Documentation is not bureaucracy when it prevents the same question from being asked fifty times.

It is a productivity tool.

Let People Talk About New Things

A healthy engineering culture should absolutely encourage communication.

But communication is a limited resource.

Spend it well.

Do not spend your senior developer’s attention explaining for the twentieth time how to start the staging environment.

Do not make a new engineer wait until someone in California wakes up to understand a configuration flag.

Do not confuse access to tribal knowledge with collaboration.

Document the things we already know. Then use the time we saved to discuss the things we don’t know yet.

That is where communication becomes valuable.

Documentation doesn’t replace communication. It buys time for better collaboration.