DEV Community: vladimir ivanov

Why Curiosity Is a Better Career Strategy Than Planning

vladimir ivanov — Sun, 31 May 2026 08:11:07 +0000

Curiosity Is a Better Compass Than Certainty

I first heard this idea by accident.

On a flight back from Thailand, someone had left a podcast playing. I pressed play without thinking much about it.

A professor was talking about innovation in AI, career decisions, and the uncertainty people face after university.

One idea stayed with me.

When he had no clear idea what to study or what direction to take, he didn’t try to force a plan. He followed his curiosity.

That decision ended up shaping his entire career.

At first, it sounded like simple advice. But the more I thought about it, the more I realised it wasn’t just motivational — it was descriptive.

Curiosity wasn’t just a feeling. It looked more like a signal inside a system that drives attention, learning, and career direction.

So I tried to model it.

What I found was that curiosity is not a single trait. It behaves more like a signal inside a system involving attention, motivation, reward, identity, learning, and feedback loops.

And once you see it that way, “follow your curiosity” stops being vague advice — and starts looking like a practical strategy for navigating uncertainty.

After hearing that story, I became interested in a deeper question:

Why does curiosity have such a strong effect on career direction?

Understanding that system helps explain why following curiosity often leads to surprisingly good outcomes.

Here’s the mental model I ended up with:

1. Attention (the upstream bottleneck)

Before curiosity or motivation can matter, there is attention.

Attention determines what enters awareness in the first place.

Curiosity competes for attention
Motivation sustains attention

If attention is overloaded or hijacked, both curiosity and motivation weaken.

Curiosity pulls attention toward uncertainty
Motivation holds attention on a goal

2. Interest (the stabilised form of curiosity)

Interest is what happens when curiosity repeats.

Curiosity is a spike. Interest is a pattern.

Curiosity: “What is this?”
Interest: “I keep coming back to this”

Interest matters because it:

stabilises exploration
reduces cognitive friction
becomes long-term motivational fuel

Curiosity → repeated curiosity → Interest → sustained motivation

3. Reward (why motivation persists)

Motivation depends on perceived reward.

progress signals
mastery
external outcomes (money, recognition)
internal satisfaction (clarity, completion)

Motivation fades when:

rewards are delayed
progress is invisible
feedback loops are weak

Motivation is maintained by reward feedback loops, not intentions.

4. Uncertainty (the trigger for curiosity)

Curiosity cannot exist without uncertainty.

No uncertainty → no curiosity
Too much uncertainty → avoidance
Moderate uncertainty → peak curiosity

Curiosity is maximised at manageable unknowns.

This explains why:

beginners feel overwhelmed
experts feel bored
the learning zone sits in between

5. Friction (the enemy of action)

Even when curiosity exists, friction can block execution.

complex setup
slow feedback loops
unclear next steps

Often, motivation fails not due to lack of desire, but because:

the cost of action exceeds perceived reward

AI tools reduce friction, which is why they amplify both curiosity and action in practice.

6. Agency (the belief that action matters)

Agency is the belief that your actions can influence outcomes.

Without agency:

curiosity becomes passive consumption
motivation collapses (“why bother?”)

With agency:

curiosity becomes exploration
motivation becomes execution

Engineers often develop strong curiosity loops because systems give immediate feedback between action and result.

7. Competence (what motivation feeds on)

As competence increases:

uncertainty becomes structured
curiosity becomes more focused
motivation becomes easier to sustain
beginner curiosity = broad and chaotic
expert curiosity = narrow and deep

8. Identity (the stabiliser layer)

Identity is the story you tell yourself about who you are.

People are more consistent with identity than with goals.

“I am an engineer”
“I build systems”
“I understand how things work”

Identity affects:

what you become curious about
what you persist in
what you ignore entirely

9. Flow (where the system aligns)

Flow is a state where attention, curiosity, and skill align, making action feel effortless.

Flow happens when:

curiosity is active
motivation is frictionless
challenge matches skill

In flow:

attention locks in completely
time perception fades
effort feels reduced

Flow is the temporary equilibrium of the system.

10. Learning (the output of the system)

Curiosity selects what we explore
Motivation sustains engagement
Feedback refines understanding

Learning is structured change in understanding over time.

Without curiosity → no direction

Without motivation → no persistence

Without feedback → no improvement

Putting it all together

Attention → what enters awareness
Curiosity → what gets explored
Interest → what repeats
Motivation → what continues
Friction → what blocks action
Reward → what reinforces behaviour
Agency → belief that action matters
Competence → ability to reduce uncertainty
Identity → long-term consistency
Flow → aligned execution state

Final reflection

Looking back, the professor’s advice makes more sense now.

Curiosity is not just a feeling — it is a navigation system.

It directs attention toward uncertainty, builds interest through repeated exploration, develops competence through learning, and gradually shapes identity.

We often assume successful people knew exactly where they were going. In reality, many simply followed questions they could not stop asking.

Certainty feels safe.

Curiosity is valuable because it reveals paths that cannot be planned in advance.

The future is too complex to predict.

But it is often possible to notice what genuinely pulls your attention — and take one step further in that direction.

That is usually enough.

You don’t need a perfect plan.

You need a direction that keeps generating curiosity as you move.

From Skills to Systems — How We Package and Control AI Capabilities

vladimir ivanov — Sun, 17 May 2026 20:33:32 +0000

As AI systems move from single models to composable agent and skills ecosystems, the bottleneck is no longer intelligence.

It is control.

Not just what an AI can do — but how capabilities are packaged, deployed, isolated, updated, and safely combined across teams and environments.

This is where “skills” stop being conceptual features and start behaving like software artifacts.

And once that happens, we need to treat them like systems.

1. Skills Are Becoming Deployable Units

A “skill” is no longer just a prompt or function.

It is a packaged capability with behaviour, dependencies, and runtime assumptions.

This changes everything:

It must be versioned
It must be testable
It must be composable
It must fail safely
It must evolve independently

At that point, a skill is closer to a microservice than a prompt.

2. Distributed Skills: Three-Tier Model

Instead of colocation vs separation, skills are better understood by where they belong in the reuse hierarchy — their scope, ownership, and governance.

Tier 1 — Codebase-Local Skills

Skills inside a single project or library.

Highly contextual and tightly coupled
Not reusable
Fast to iterate

Optimised for speed, not portability.

Tier 2 — Company-Shared Skills (Private Registry)

Shared across teams within an organisation.

Reusable internally
Versioned and governed
Encodes company-specific logic

Optimised for consistency at scale.

Tier 3 — Public Marketplace Skills

Reusable across organisations.

Standardised and general-purpose
Discoverable via registries
Ecosystem or vendor maintained

Optimised for interoperability and reach.

3. Skill Packaging Model

A skill is a structured capability, not inline logic.

Typical components:

Interface (inputs/outputs)
Behaviour definition
Dependencies
Policies
Metadata (version, ownership)

This turns skills into deployable units.

4. Registries and Distribution Systems

Skills require a registry (marketplace) for discovery and governance:

Versioned storage
Ownership tracking
Controlled publishing
Cross-system discovery

Skills become managed assets, not scattered logic.

5. Versioning Strategies

Behaviour matters as much as structure.

Major → breaking behaviour change
Minor → added capability
Patch → internal fixes

Behavioural contracts are needed to maintain predictability across versions.

6. Dependency Management for Skills

Skills depend on tools, models, and other skills.

This creates dependency graphs requiring:

Version pinning
Compatibility rules
Conflict resolution
Transitive dependency visibility

Without this, small changes cascade into system-wide effects.

7. Testing: From Unit to Behavioural Evaluation

Testing must extend beyond unit tests:

Unit → deterministic behaviour
Integration → composition with tools/skills
Behavioural → ambiguous real-world cases
System-level → full agent simulations

Most failures appear only in composition.

8. Agent Package Managers

Agents become execution environments for skills.

They handle:

Installation and updates
Dependency resolution
Version locking
Runtime configuration

Similar to package managers, but for behaviour systems.
For example, emerging platforms like Vercel’s AI/agent workflows and Microsoft’s agent frameworks point toward this direction — where capabilities are installed, composed, and managed rather than hardcoded into a single system.

9. MCP as a Distribution Interface

Model Context Protocol (MCP) acts as a standard interface for exposing skills and tools.

It enables:

Standardised capability access
Plug-and-play integration
Separation of logic and providers

A shift from hardcoded integrations to interoperable systems.

10. Multi-Team and Third-Party Skill Ecosystems

Skills evolve into ecosystems across organisations.

Key challenges:

Governance and ownership
Trust and safety
Compatibility management
Marketplace dynamics

AI systems begin to behave like platforms.

Closing Insight

AI systems are shifting from model-centric design to capability-centric systems engineering.

Skills are no longer prompts or utilities — they are:

Versioned
Distributed
Governed
Composed
Tested at system level

The real challenge is no longer building intelligence, but building safe capability systems at scale.

We’re Repeating Dependency Hell — But Now It’s AI Behaviour, Not Code

vladimir ivanov — Sun, 17 May 2026 20:01:46 +0000

Software engineering already learned a painful lesson once: when dependencies are unmanaged, systems slowly collapse under their own complexity.
Version mismatches, hidden upgrades, and transitive chaos led to what we now call dependency hell.
We solved it with package managers, lock files, and disciplined release cycles.
But in the era of AI systems and agentic software, we are quietly rebuilding the same problem — just at a higher layer.

This time, it’s not code that is changing underneath us.
It’s behaviour. Tools, skills, prompts, and models are evolving in ways that subtly alter how systems think, decide, and act — often without anyone explicitly noticing.

AI Behaviour is a Composed System

AI behaviour is not produced by skills alone. It emerges from the interaction between the underlying model, prompts, and the agent layer that orchestrates actions over time.
Prompts shape interpretation of intent, agents define multi-step reasoning and tool use, and skills provide the external capabilities that can be invoked.

Together, these form a single system where behaviour is not just generated, but executed through a combination of reasoning and action.

What "Skills" Actually Are

To understand why this matters, we need to be precise about what "skills" actually are in modern AI systems.
At their core, they are not magical extensions — they are structured function calls with defined inputs, outputs, and side effects.

A skill might wrap an API request, database query, or external service, but fundamentally it is a callable capability exposed to an agent.

The key difference from traditional software is not their structure, but how they are used.
In conventional systems, functions are invoked explicitly and deterministically by developers.
In agent-based systems, the same functions are selected, invoked, and composed dynamically by a model based on interpreted intent.

This shifts skills from passive utilities into active participants in decision-making.

As a result, skills are not informal integrations — they are production-grade interfaces that require strict contracts, versioning, backward compatibility, and testing.
A change in a skill’s schema or behaviour is equivalent to changing a function signature in a distributed system — except failures are often silent and semantic rather than immediate.

Integration and Systemic Risk

Skills rarely operate in isolation. Agents compose multiple tools within a single workflow, making integration boundaries critical.
A change in one skill can cascade through the system and alter downstream behaviour in unexpected ways.

This is why integration testing across versioned skills is essential — not just validating each skill independently, but validating composed systems such as:

skill A v1.2 + skill B v2.0 + model X

ensuring they still produce stable outcomes.

Without this, the risk is not just broken functions — it is broken reasoning chains.

MCP and the Skill Layer

We are already seeing this shift in systems like MCP (Model Context Protocol), where tools and data sources are exposed to models through standardised interfaces.

MCP effectively formalises skills as discoverable, callable services — closer to APIs in distributed systems than prompts or informal plugins.

This reinforces a key architectural reality: once capabilities are exposed to an agent, they become part of a dynamic execution graph and must be treated as versioned, testable, and composable units.

Installable, Reusable, Distributed Skills

Skills naturally evolve into installable, reusable, and composable components.
Once exposed externally, they can be distributed, installed from registries, and reused across multiple agent systems like packages in traditional software ecosystems.

Unlike traditional libraries, skills are often triggered through plain English intent, where an agent interprets a request and selects the appropriate capability.

But the outputs are not free-form. They are structured results designed for further composition — where one skill feeds another, enabling dynamic multi-step workflows.

This turns skills into building blocks for runtime composition. Systems are no longer pre-wired pipelines, but graphs of reusable capabilities assembled at execution time.

This composability increases power — but also risk. Small changes can propagate across reasoning chains in ways that are difficult to predict without strict versioning and integration testing.

Just Chat vs Systems That Actually Execute

In a basic chat system, the model is stateless and general-purpose. It responds using internal knowledge, with no reliable external execution layer or guarantees about how actions are performed.

In contrast, a skill-enabled system orchestrates versioned capabilities. A user request in natural language can trigger specific tools with strict contracts, predictable side effects, and composable outputs.

The system becomes a hybrid:
natural language for intent → structured execution via skills.

This is why skills are not just enhancements — they fundamentally change what the system is capable of doing reliably.

Cost and Scale Implications

At first glance, skills, versioning, and composable tool systems look like overhead. They introduce real complexity: interface design, backward compatibility, integration testing, and registry management.

But in production systems, the real cost is not infrastructure — it is unpredictability at scale.

Unmanaged tool usage leads to:

inefficient routing
repeated model calls
silent failures
expensive debugging cycles

As systems grow, cost increases not linearly, but through accumulated uncertainty.

Well-designed skill systems change this dynamic. They move deterministic work out of the model, reduce redundant reasoning, and enable cheaper execution paths. More importantly, they reduce the hidden operational cost of ambiguity.

Skills and versioning are not just a cost optimisation — they are a mechanism for controlling complexity growth.

Without them, cost does not scale with usage. It scales with entropy.

Closing Insight

The shift is not simply that we are adding tools to AI systems.
It is that we are turning capabilities into software artifacts that directly shape reasoning.

Once that happens, every change becomes meaningful.
A version bump is no longer just a code update — it is a potential change in behaviour, decisions, and system-wide outcomes.

This is why the next evolution of software engineering is not just about writing better functions.

It is about controlling the behavioural surface area of systems that think in language but execute in code.

Mental Algorithms: How AI Changes the Cost of Thinking

vladimir ivanov — Sun, 17 May 2026 09:16:24 +0000

Most people assume the difference between good thinking and bad thinking is intelligence.

It isn't.

More often, it comes down to cost — how much mental effort it takes to arrive at a useful answer. Some answers require slow, deliberate reasoning. Others emerge almost instantly through pattern recognition or experience.

Human thinking isn't a single process. It's a collection of reusable patterns — some fast, some careful, some surprisingly fragile depending on context.

AI doesn't replace these patterns. It changes what they cost to use.

1. Structured Thinking (Slow, Deliberate Reasoning)

This is the kind of thinking people usually mean when they talk about "deep work" or "careful reasoning". It prioritises correctness over speed, and it tends to feel effortful.

Decomposition

Large problems rarely stay large once you start breaking them apart. Splitting something into smaller components makes it easier to understand, reason about, and eventually solve. In software, this is the difference between an overwhelming system and a set of manageable modules.

AI is especially good at this first pass. It can outline a system or break down a problem in seconds — something that would normally take a whiteboard session and some back-and-forth.

Abstraction

Abstraction is the act of ignoring detail on purpose. You don’t need to understand everything to use something effectively — just the parts that matter.

Good engineers instinctively group things that change together and separate things that don't. That decision — what to include and what to ignore — is still very human. AI can assist with structure, but judgment still sits on your side.

Iteration

Most real progress doesn’t happen in one leap. It happens through repeated cycles: try something, observe what breaks, adjust, repeat.

What AI changes here is speed. Iteration cycles that once took hours or days can now happen in minutes. The loop stays the same — it just becomes much cheaper to run.

Hypothesis Testing

Good debugging isn’t guessing randomly. It’s forming small, testable ideas and checking them one at a time.

AI helps by suggesting likely causes or next steps, but the grounding still comes from reality — logs, outputs, behaviour. It can accelerate thinking, but it can't replace validation.

Systems Thinking

At some point, you stop looking at parts and start looking at interactions. Changing one thing affects others in ways that aren’t always obvious — performance, reliability, consistency.

AI can map dependencies reasonably well, but real systems tend to reveal their complexity only when they're running under pressure. That's where intuition still matters.

Edge Cases

Most real bugs don't come from the "normal path". They appear at the edges — empty inputs, failed requests, race conditions, unexpected states.

AI can suggest some of these, but domain-specific edge cases usually come from experience rather than inference.

2. Fast Thinking (Heuristics and Shortcuts)

Fast thinking is what gets used most of the time in real life. It's not careful — it's efficient. It trades precision for speed.

Heuristics

Rules of thumb like "start simple", "avoid premature optimisation", or "readability over cleverness" exist because they work often enough to be useful.

AI tends to generate a default version of these heuristics, which is helpful — but also risky if you accept them without thinking. The baseline gets easier, but that also makes it easier to stop questioning it.

Satisficing

Most decisions aren't about finding the best option. They're about finding one that's good enough to move forward.

AI lowers the threshold for "good enough" dramatically. That changes behaviour: people stop searching earlier because acceptable solutions appear faster.

Anchoring

The first answer you see tends to shape everything that follows.

With AI, that anchor is often the first generated response — fluent, confident, and structured. That makes it especially sticky, even when it's not optimal.

Availability Bias

We tend to estimate likelihood based on what comes to mind easily.

AI shifts what becomes "easy to recall" toward patterns it has seen most often in its training data. That subtly biases thinking toward common solutions.

Narrative Thinking

Humans like stories. We compress complexity into something linear and understandable.

AI is extremely good at producing narratives, even when reality is messy. That makes explanations clearer — but also sometimes cleaner than reality actually is.

3. Simulation and Future Thinking

Mental Simulation

We constantly run mental "what if" scenarios before acting.

AI expands this space dramatically. Instead of imagining two or three outcomes, you can explore dozens in seconds.

Regret Minimisation

Many decisions are really about avoiding future regret.

When alternatives are easy to generate, comparing outcomes becomes more explicit — and sometimes more overwhelming.

Opportunity Cost

Every decision excludes others, but we don't usually feel that cost clearly.

AI makes execution cheaper, which ironically makes decision-making more important. When doing is easy, choosing becomes the real bottleneck.

4. The Meta Layer — Thinking About Thinking

The hardest shift isn’t technical. It’s awareness.

It’s knowing when you’re reasoning carefully versus when you’re just following a fluent suggestion that feels like reasoning.

AI blurs that boundary. You can easily feel like you’ve thought something through when you’ve actually just selected from a well-phrased option.

That makes feedback loops more important than ever — checking, testing, and re-evaluating what you assume is true.

Closing Thought

Thinking isn’t a single skill. It’s a set of patterns we switch between constantly, usually without noticing.

Most errors don’t come from lack of intelligence. They come from using the wrong pattern for the situation.

AI doesn’t change that.

It just makes every pattern cheaper — and the switching between them less visible.

Which means the real skill is no longer just thinking well.

It’s noticing what kind of thinking you’re doing while it’s happening.

The Silent Knowledge Tax Inside Engineering Teams — And Why It Matters More in the Age of AI

vladimir ivanov — Sun, 10 May 2026 13:45:50 +0000

A look at why engineering knowledge stays locked in individuals—and how AI changes the economics of sharing it.

Most engineering teams don’t struggle because people don’t know enough.

They struggle because most of what people know never leaves their head.

In most organisations, only a small number of people consistently document what they know, share reusable solutions, and help others avoid repeating the same work. Most do not—not because they lack capability, but because knowledge rarely becomes something that is naturally captured, shared, and reused.

The silent knowledge tax

There is a hidden cost inside most engineering teams that rarely gets talked about.

It is not technical debt.

It is a knowledge tax.

When skills remain trapped inside individuals, organisations repeatedly pay for the same problems:

duplicated work
repeated mistakes
slower onboarding
inconsistent implementations
dependency on a few key people

Every time a problem is solved again instead of being reused, the organisation pays that tax again.

The real reason people don’t share knowledge

Most people do not share what they know—not because they are unwilling, but because the immediate personal reward strongly favours building and solving over explaining and documenting.

Writing code, fixing problems, and shipping features provide clear and immediate feedback. Sharing knowledge, by contrast, requires additional cognitive effort and offers delayed, uncertain, and often invisible rewards. As a result, even highly capable engineers naturally prioritise execution over articulation.

The value of the few who do share

In every engineering organisation, there are a few people who consistently document what they know, share reusable solutions, and help others avoid repeating the same work.

In doing so, they also help themselves:
they create a record they can return to later, reducing the need to rediscover forgotten knowledge and avoiding the need to reinvent the wheel.

By writing ideas down, they make their thinking explicit and easier to communicate. Once shared, those ideas become open to review, discussion, and refinement—often improving through feedback from colleagues.

Why knowledge stays trapped inside individuals

The problem is not unwillingness or lack of skill. It is a combination of cognitive load, incentives, identity, and visibility.

Sharing knowledge requires switching from “doing” to “explaining,” and most systems are optimised for doing.

Hiring talented people is necessary, but it is not sufficient. Most engineers already have strong ideas, valuable experience, and deep understanding of how problems should be solved. The issue is not capability—it is that very little of that knowledge becomes a shared organisational asset.

This extends far beyond documentation. It includes:

reusable code libraries
architectural patterns
coding standards
prompts and AI workflows
automation scripts
lessons learned from past projects

When these assets are created and shared, they reduce duplication, improve consistency, and allow teams to build on each other’s work instead of starting from scratch.

Why people don’t actively share knowledge

1. Cognitive effort and explanation cost

Explaining ideas requires structured thinking, extra effort, and interruption of workflow.

2. Loss of perceived uniqueness

Some fear that sharing reduces their “edge” or makes their expertise less distinctive within the team.

3. Ownership ambiguity

When knowledge is not clearly owned:

no one is responsible for documenting it
effort feels optional
it becomes invisible work

This leads to diffusion of responsibility—everyone assumes someone else will do it.

4. Low emotional reward (dopamine mismatch)

Coding provides:

immediate progress signals
problem-solving satisfaction

Sharing provides:

delayed, indirect benefits
no immediate “win”

So the brain prioritises execution over documentation.

5. Fear of criticism or being wrong

Shared ideas are exposed to review, discussion, and correction, which can discourage people from publishing imperfect knowledge.

6. Lack of recognition or reward

Knowledge sharing is rarely measured or rewarded, so it is deprioritised compared to visible delivery work.

7. Time pressure and workload

Under delivery pressure, documentation and knowledge sharing are often postponed indefinitely.

8. “I’ll document it later” effect

People assume they will write things down later, but context fades, details are lost, and motivation disappears.

9. Social invisibility of sharing work

In most teams:

writing code is visible
shipping features is visible
sharing knowledge is invisible

As a result, even strong contributors naturally optimise for visible impact.

Why this matters more in the age of AI

As AI becomes embedded in engineering workflows, “knowledge” increasingly includes:

prompts
workflows
automation patterns
tool usage strategies

If this knowledge remains trapped inside individuals, organisations fail to turn AI into a scalable capability.

The real advantage in the AI era is no longer just having smart people, but creating systems where their skills—human and AI-assisted—become shared, reusable, and continuously improved.

From individual knowledge to reusable AI skills

The shift happening with AI is not just that engineers can do more.

It is that skills themselves can now be designed to be reusable.

Traditionally, engineering knowledge has been:

implicit
personal
context-dependent
hard to transfer

Even when documented, it often loses meaning outside the original situation.

But when knowledge is expressed as prompts, workflows, reusable instructions, and structured patterns, it becomes something closer to a portable capability, not just personal understanding.

What changes when skills become reusable

When skills are not reusable, teams scale slowly:

one person learns something
others gradually copy it
knowledge spreads unevenly
mistakes are repeated

But when skills are designed to be shared:

one improvement benefits everyone instantly
workflows become consistent
best practices propagate automatically
learning compounds across the organisation

Instead of knowledge diffusing through people, it becomes embedded in systems.

The real contrast

Traditional engineering teams:

knowledge lives in people → slow transfer → repeated work

AI-enabled teams:

knowledge lives in shared skills and agents → instant reuse → compounding improvement

This is the real shift.

Closing insight

The most valuable engineering teams are not the ones with the best individual engineers.

They are the ones that turn individual knowledge into shared intelligence.

And in the age of AI, the advantage no longer comes from what people know individually.

It comes from what they are able to share, reuse, and scale together.