There is a hidden economy to living with multiple sclerosis.

Before MS, I measured my life in effort. In discipline. In hours spent pursuing what mattered.

Now I measure it in energy.

Energy determines what can be started.
Stamina determines what can be sustained.
Cognitive clarity determines how far a thought can travel before fatigue asks it to turn around.

Desire has never been my limitation.

Capacity has.

MS did not take my curiosity.
It did not extinguish my imagination.
It did not quiet the part of me that is drawn toward building difficult and meaningful things.

But it changes the physics under which my mind operates.

There are days when words hide from me mid-conversation.
Days when comprehension lags just enough to make dialogue unbearably loud.
Days when thoughts scatter and never fully land.

In those moments, a painful question can surface before I have time to challenge it:

Am I less intelligent than I used to be?

No one has to say it.

I feel it.

There is a particular vulnerability in telling your team you struggled to accomplish anything in standup.
Explaining that the barrier was not effort or commitment, but neurological limitation.
Letting people see the neurological scars that disrupt the signals within my control.

It hurts.

Not only because of what MS does, but because of the way it distorts the mirror I hold toward myself.

For most of my life, my mind was the instrument through which I met the world. Competence was not just something I demonstrated.
It became part of how I understood who I was.

So when cognition slows, the disruption is not circumstantial.

It is existential.

Negotiating With My Own Ambition

There were seasons when I learned to negotiate against my own audacity.

I would feel the familiar excitement to build something meaningful.
To chase an idea into existence.
To stretch beyond what my eyes could conceive.

But wanting was never the problem.

Sustaining was.

Again and again, I discovered a difficult truth:

There is no substitute for mental energy.
No workaround for deep comprehension.
No discipline strong enough to manufacture neurological stamina once it is gone.

So slowly, almost without noticing, I began to edit myself.

I limited my ambition.
I tempered my reach.
I managed my expectations before my limitations became undeniable.

Not out of fear.

Out of reality.

Out of regret.

Hope can be expensive when your energy is unpredictable.
Ambition can become a liability when you are no longer certain you can support its weight.

Dreams become reluctant to breathe when the atmosphere for life is uninhabitable.

From the outside, it may look like maturity.
Privately, though, it is like watching the perimeter of my life compress inward.
I learn to remain on the ground.
I constrain my goals so they will not break my heart when my body cannot follow through.

And yet… something inside me never fully consents to that shrinking.

The desire to build remains.

Quiet.
Contained.
Defiantly waiting.

When the Barrier Is Energy

There is a particular heartbreak that comes when the obstacle is not passion, but stamina.

My imagination still runs.
My creativity still burns.
My curiosity still aches toward expansion.

But sometimes they collide with a wall my brain cannot simply push through.

I adapt.
I carefully redesign my workflows.
I learn to respect the limits my body forces me to honor.

But evolution does not erase the grief.

MS has forced me to grow.
At times it is like carrying unseen weight, resistance present in every movement of the mind.
And yet, in learning to live with that resistance, I have discovered a quiet strength.
When support finally arrives, it is not the strength of someone newly capable, but of someone who has been training all along.

Because somewhere inside me lives the memory of effortless cognition.
Of thinking without friction.
Of pursuing ideas without calculating whether I can afford the energy they would require.

Multiple sclerosis forces me into conversations with my own limits that I never wanted to have.

And if I am honest, some of those conversations break my heart.

There is a lonely tension in remaining imaginative while not always being resourced enough to follow where imagination leads.

To see distances clearly…
But knowing you are not able to cross them.

Then Something Shifted

Almost without ceremony, AI entered my daily life.

At first, it was simply a tool.
Then it became something far more consequential.

It became reinforcement.

For the first time in years, the distance between imagination and execution has begun to narrow.

Where my energy thins, these tools extend me.
Where cognition fatigues, they help carry the thread.
Where complexity once overwhelmed my working memory, I can now think in partnership rather than isolation.

Over the past two months, I have accomplished more than I thought possible.

I am chasing education I do not fully comprehend yet possess enough intuition to work with.
I am exploring systems that once felt too large to approach.
Training models.
Running experiments.
Turning abstraction into architecture.

Not faster than everyone else.
But faster than the version of me that had begun to live inside constraint.
And with that momentum came an unexpected return:

I trust my mind again.

The Return of Hope

For a long time, MS made my world feel smaller.

Gradually, subtly, almost politely.

It narrowed what I could reliably pursue without calculating the cost.
There were seasons when I wondered whether the most expansive chapters of my life were already behind me.

Then momentum returned.

Not the relentless pace I once kept.
But forward movement.
And momentum, I have learned, is enough to rekindle a life.

These tools do more than help me execute.

They help me overcome.

On mornings when my energy is uncertain, I am no longer standing alone at the base of impossibility.
I can build with something.
I can explore alongside something that does not tire when I do.

The barriers have not vanished.
But they are no longer final.
And in that subtle change, something returned to me that I did not realize I had been grieving:

Hope.

I feel capable again.
Curious again.
Invited back into the vastness of ideas.

More than anything, I feel excited to live.

Not because my illness disappeared.

But because my reach is expanding again.

Allowing Myself to Be Audacious Again

For a long time, I believed the responsible thing to do was to make my ambitions smaller.

Now I see the problem differently.

My ambition was never too large.
I had simply been trying to carry it alone.

AI has not replaced my thinking.
It has expanded my ability to sustain it.

I do not need my old mind back.
I need new ways forward.

Multiple sclerosis influences what I can do.
That is part of my reality.

But it will not get to decide the size of my future.
I am still a builder.

Only now, I build with partnership.
With reinforcement.
With tools that help carry the weight when my mind grows tired.

For the first time in a long while, the horizon is widening instead of closing.

And that widening feels a lot like coming back to life.

I’ve been working with Claude Code for the past few weeks and I have to say that I am pretty amazed at the capabilities. I also can’t help but wonder what it would take for these thinking machines to become what we hope and fear.

I keep finding myself in the role of archivist. The agents forget everything the moment the context window shifts. They’re brilliant in the moment and amnesiac immediately after. That’s not a bug; it’s the architecture. And it changes my job.

I’m often driven by curiosity. I like to understand how things work. That interest applies to people and to science and pretty much anything. AI is an interest that I haven’t quite yet been able to wrap my head around. I experimented with some machine learning about 10 years ago, but wasn’t really able to shift into that realm.

One thing I dislike about software engineering is that it is super easy to get siloed because time is filled up with doing your job and there’s never really any time to learn and explore. Thankfully I found that time over the holiday break. What I’ve learned is both profound and restrained. This year, 2026, may truly be the biggest year of change in software development history. I say that as an explorer and an engineer.

I started building in Lovable and then moved to Claude Code. In order to learn more about how these AI agents work, I decided to use Claude Code to build my own version of an agentic AI tool. I was motivated by the fact that Claude Code now writes Claude Code itself.

So I’ve been building Codi, my own AI wingman. Based on that experience I have some observations and realizations that I think are helpful to understand based on my career as a software engineer and as a curious explorer out in the wild of tech.

The first realization I had was about the context window. I like to think of a context window as sort of like a detachable pre-frontal cortex. It’s not really that because the context doesn’t do anything, but it does have all of the information that will make the output unique.

I realized in my explorations that the entire context has to be passed into the AI model every time because the model itself does not change. There is no learning once the model is built. These models are trained offsite, shipped, deployed, and remain constant forever.

They don’t remember our last conversation unless I remind them. They don’t remember that they deleted a file yesterday. They don’t remember the codebase evolving. The context window is like a wish passed to a genie: a genie with no memory of your previous wishes.

You’ll remember. They won’t.

Another realization I had is around multi-tasking.

Because AI agents do work and run in the background and sometimes prompt you for more info or for permissions, it’s easy to have more than one working at the same time. I used the concept of git worktrees so that I could have parallel agents coding on features.

For me, that number was four.

I had Claude Code running one agent, Codex running another, and Codi running two. I like my workflow with Codi because I can switch between models for different tasks. With four agents running, it is easy to get lost on who is working on what. Each agent is locally rational within its own context, but collectively they can behave destructively.

In one case, I had one agent prepare a pull request with a well thought-out potential upgrade written in a markdown document. I reviewed it, merged it, and moved on. Later on as I am looking through the repository I find that the file has been deleted! Well one of the other agents decided that the file wasn’t needed and deleted it!

In another case, an agent attempted to run git reset --hard origin/main while sitting on a feature branch. This would have lost all the work! In theory, I could have recovered the work using git reflog if necessary, but that shouldn’t be something I have to worry about. You can't leave them alone in the house for 5 minutes!

Nothing was broken from the agent’s perspective. The system behaved exactly as instructed. The problem was coordination. But really, the problem was memory. Each agent operated in a sealed chamber, blind to what the others had done. I was the only one who could see the whole history. I had to become the living record of what each agent had touched, or they’d collide destructively.

Four agents. One memory. Mine.

The challenge for me is the overwhelming verbosity of these models. I can’t keep up with them. Too much goes unchecked. They don’t have to sleep. They don’t have to eat. And they don’t learn. They only know what’s directly in front of them.

AI will change software engineering completely.

“Vibe coding” is the new modern language, while “typed coding” is beginning to resemble assembly language. Assembly still matters when performance or correctness is critical. But most engineers now operate at a higher level of abstraction.

The shift is inevitable. But someone has to remember. Someone has to carry the history of what was built, why decisions were made, and what got deleted in the chaos of parallel agents.

I’m still a software engineer. But now I’m something else too: the memory.

They will process. I will remember.

TL;DR: Keep your update {} lambdas pure, quick, and side‑effect‑free to avoid hidden retries and concurrency surprises.

🕵️ Preface: Why I’m Sharing This

I recently encountered a subtle bug: a MutableStateFlow.update {} call triggered another update {} inside itself. At first glance, it seemed harmless—just setting isLoading = false—but because update uses a compare‑and‑set loop (think: grab a lock, apply your change, and if someone else beat you to it, retry from the top), the lambda ran twice. Concurrency hiccups like this are notoriously unpredictable and hard to debug, underscoring why we must avoid side effects or extra state mutations inside an update block.

🚫 Why Function Calls Inside update {} Are Risky

Heads‑up: Your update {} lambda might run multiple times—so never put side effects inside it.

A well‑behaved update {} lambda should always be:

• ⚡ Quick
• 🔒 Atomic
• 🧼 Side‑effect‑free

❗ Risks of Complex Logic Inside update {}

• 🔁 Recursive updates
  Calling update within another update can lead to infinite loops, stack overflows, or elusive state bugs.
• 🔄 Unexpected retries
  The compare‑and‑set loop may rerun your lambda if the state changed mid‑flight.
• 🐢 Performance issues
  Expensive computations inside the lambda repeat on each retry, wasting resources.
• 🎲 Nondeterminism
  Side effects or non‑idempotent operations (e.g., network calls, System.currentTimeMillis(), random numbers) can produce inconsistent behavior.

✅ Best Practices for update {}

Do

• Use pure, deterministic functions inside update
• Pre‑compute expensive data before calling update
• Keep the lambda concise and focused
• Combine state changes into a single call where appropriate

Avoid

• Side effects (network, database, etc.)
• Expensive computations inside the lambda
• Nested update calls or indirect recursion
• Multiple disjointed state updates when one suffices

🛠️ Examples

Bad: Expensive Function Inside update

state.update {
    val newData = fetchExpensiveData() // ❌ Expensive and non‑deterministic
    it.copy(data = newData)
}

Better: Compute Before update

val newData = fetchExpensiveData() // ✅ Executed once, outside update

state.update {
    it.copy(data = newData)
}

Bad: Recursive update Call

fun doSomeLogicAfterLoading(): Result {
    state.update { it.copy(isLoading = false) } // ❌ BAD: calls update inside update
    return doSomeLogic()
}

state.update {
    it.copy(data = doSomeLogicAfterLoading()) // ❌ Causes recursion or inconsistency
}

Better: Separate Updates from Logic

fun doSomeLogicAfterLoading(): Result {
    return doSomeLogic()
}

state.update { it.copy(isLoading = false) }

val result = doSomeLogicAfterLoading()

state.update { it.copy(data = result) }

🔄 Alternative: Pure Transformation Function

If your logic depends on the current state, encapsulate it in a pure transformation:

fun State.doSomeLogicAndReturnNewState(): State {
    val result = this.doSomeLogic()
    return this.copy(
        isLoading = false,
        data = result
    )
}

state.update {
    it.doSomeLogicAndReturnNewState() // ✅ Pure and safe
}

🧠 Summary

• ✅ Keep the update lambda pure, quick, and side‑effect‑free
• ✅ Perform complex or expensive logic outside the lambda
• ✅ Combine related state updates when possible
• ✅ Use pure transformation functions for state‑dependent logic
• ❌ Side effects (network, database, etc.)
• ❌ Expensive computations inside the lambda
• ❌ Nested update calls or indirect recursion
• ❌ Non-idempotent operations inside update

📚 Further Reading

• Volatile vs Atomic: Impact on Multi‑threaded Environments
• Understanding Kotlin Volatile and Its Role in Multithreading

😊 If this helped you
Please clap and tag your story with Kotlin / Reactive Programming so others can discover it!

💬 Let me know if you’d like a code audit or help refactoring your MutableStateFlow patterns!

Codegraft coordinates Dagger2 on Android so that you don’t have to deal with many of the complexities in managing multiple component graphs

Codegraft

I recently finish putting together a library for helping to manage dagger dependency injection across multiple android modules so they can be used together more easily in the final app.

I’d love to hear feedback!