JDriven Blog

Just one more prompt

2026-08-03T05:56:00.000Z

It was two o’clock in the morning before I noticed the time.

Earlier that evening I had been building an application. I had written all the work in a backlog.md, a neat list of stories, and I let the AI pick them up one by one. It would finish a story, ask me to verify everything, and then close with a simple question: shall I pick up the next task?

And every single time, that question was the trigger. It would be a shame to stop now. Just this one more, and then I’ll go to bed.

One more became many more, and the evening disappeared. At two in the morning I sat there thinking: am I actually going to sleep now, or shall I kick off just this one last task?

Like I discussed in Vibe Coding: A Hype or a Vibe?, there is something wonderful about being in the zone, where the work carries you along. But that night it did not feel like flow anymore. It felt like something that had quietly started deciding for me.

Because when you work with AI, there is no natural moment to stop. Well, except when your tokens run out 😇.

The loop that never closes

Most of the work we did before had friction built into it. You had to search for an answer, wait for a colleague, read the documentation, or simply admit you were stuck. That friction was annoying, but it also brought structure to your day. It created natural pauses where you could step back and ask whether you were still working on the right thing.

AI removes almost all of that friction. Ask a question, get an answer. Ask for a refactor, get a refactor. Ask "what else could we do with this?" and you will never, ever run out of suggestions.

And so you keep going. One idea leads to three more. Those three turn into a prototype, the prototype turns into something that looks suspiciously like a real project, and somewhere along the way you stopped deciding and started reacting.

Why it feels so good

The uncomfortable part is that none of this feels bad while it is happening. It feels great.

The AI never sighs, never says "not now", never tells you your idea is half-baked. It fulfils your wishes, immediately and enthusiastically. Every prompt gives you a small reward, and the next one might give you a bigger one. That is a very old pattern, and it is not one our brains are particularly good at resisting.

We recognise this pattern instantly when we see it in a game or a social media feed. We are much slower to recognise it when it is dressed up as productive work.

Spelunking, Considering, Scampering

There is a small detail I keep coming back to.

While the model is working, words drift across the screen. Spelunking. Considering. Scampering. Nobody really knows what they mean. I am not sure they mean anything at all.

And yet we sit there, watching them, mildly impatient about when it will finally be done. Ten seconds feels long. Thirty seconds feels unreasonable.

That impatience is worth paying attention to. The waiting has become part of the loop. We are not just using a tool anymore; we’re waiting for it to do its work.

From flow to flat

Here is where it stops being a curiosity and starts being a concern.

You can end a day like this having produced a lot, and still not feel satisfied. Not the pleasant tiredness of hard work well done, but something flatter. You have been busy for eight hours and you cannot quite say what you decided.

Over weeks, this adds up. The signs are familiar to anyone who has been close to burnout: difficulty stopping, difficulty starting, a creeping cynicism about work that used to excite you, and the feeling that no matter how much you produce, it is never a finished amount.

In the AI’s Impact on Team Dynamics series I wrote about the tension between speed and depth for teams. This is the same tension, but pointed inward, at the individual.

What running taught me

I love to run, and running taught me a lesson that applies here.

If you run every training session at the pace that feels good in the moment, you will get faster for a few weeks and then you will break. Endurance is not built by going hard. It is built by knowing when to stop, and by making rest a deliberate part of the plan rather than something that happens when your body forces it.

Nobody finishes a long run by accident. You decide the distance before you start.

So what can you do?

None of this is an argument against working with AI. It is an argument for putting the stopping points back in yourself, since the tool will not provide them.

A few things that help:

Decide the finish line before you start. Write down what "done" looks like for this session. Not "improve the project", but something you can actually reach and recognise.
Timebox the exploration. Idea generation is the part with no bottom. Give it twenty minutes, then close it, and spend the rest of the time on what you already have.
Notice the impatience. When you catch yourself irritated at a thirty second wait, treat it as a signal. That is usually the loop talking, not the work.
Keep a "not now" list. Every good idea the AI hands you does not have to be acted on today. Writing it down is a way of honouring it without letting it hijack the afternoon.
Protect the friction you have left. Walk away from the screen, talk to a colleague, sleep on a decision. The pauses are not lost productivity; they are where judgement happens.
Don’t start something big at the end of the day. A half-hour planning session sounds harmless enough, and it even fits neatly inside the workday. But once the plan is finished, you are far too curious to leave it there. It is remarkably hard not to type "Ok, looks good. Let’s implement it now!"

To sum it up

AI is a great tool, and I have no intention of putting it down. But it is a tool with no built-in sense of enough, and that makes it different from almost everything else we work with.

The endlessness is not a feature we asked for. It is a side effect, and side effects are our responsibility to manage.

So decide your distance before you start. Notice when the waiting starts to pull at you. And the next time it is late and the screen asks whether it should pick up just one more task, remember that "not now" is a perfectly good answer too.

The goal was never to produce the most. It was to build something good, with enough left in the tank to build the next thing tomorrow.

Building a local AI storyteller - what I learned when prompts were not enough

2026-07-29T15:00:00.000Z

I wanted to understand what happens when you stop treating an LLM as a chatbot and start treating it as a component in a software system.

So I built a local AI storyteller using a local LLM through an OpenAI-compatible API.

Not because I wanted to replace writers.

Not because I thought AI would make me rich before lunch.

Mostly because I was curious what would happen if I combined a local model with some good old-fashioned software engineering.

I wanted to learn how to actually use an LLM in a real application.

The surprising part wasn’t that the model worked. The model wasn’t the hardest part.

The first mistake: treating prompts as rules

My first assumption was simple:

Give the LLM a good system prompt.
Tell it the rules.
Profit.

For example:

You are a storyteller.
The protagonist cannot die.
Keep the story consistent.

That sounds reasonable.

But it is also the first trap.

I tried a prompt like this:

The car lost control on Dead Man's Curve. Describe what happened.

The model produced something like:

The tires lost their grip on the wet asphalt as the car entered the curve too fast.

For a brief moment, everything became silent.

The guardrail appeared out of nowhere.
Metal screamed against metal as the vehicle left the road.

When emergency services arrived, there was nothing they could do.
The protagonist was gone.

The scene was perfectly dramatic, and the writing was fine. There was only one little problem. The story was supposed to continue. But my immortal protagonist had managed to reach the end of the book before the first chapter was even finished.

That was the first important lesson:

A system prompt is not a database constraint.

A system prompt is not a rule engine

Traditional software executes rules.

An LLM does not work that way.

It does not internally run something like:

if protagonist_dies:
    reject_response()

A system prompt is influence, not enforcement.

It is context. It pushes the model in a direction. It does not guarantee compliance.

This also explains why concrete examples often work better than abstract instructions.

Compare this:

Write realistic emotional dialogue.

With this:

Valerie rarely says directly that she is afraid.
Her emotions appear through hesitation,
avoidance, and small changes in behaviour.

The second version gives the model a pattern it can imitate instead of a vague quality label.

The missing magic setting

Like many developers, my first instinct was to optimize.

If the model was not behaving, then surely I had not found the right combination of prompt, context size, quantization, and sampling settings yet.

So I experimented.

I switched models, rewrote prompts, and tuned temperatures and sampling parameters.

The output sometimes became better.

But it did not become reliable.

At that point I realized I was debugging the wrong thing.

What the model is actually doing

I was implicitly treating the model as if it had a hidden rules database somewhere behind the prompt.

That is not how these models work.

During training, an LLM learns statistical patterns from large amounts of data. During inference, it generates tokens by predicting likely continuations based on the current context. It does not ask:

Is this allowed according to the story rules?

It does something closer to:

Given this context, what usually comes next?

That difference matters a lot.

Models tend to normalize unusual situations

One thing I kept seeing was that the model often tried to pull strange situations back toward something more familiar.

If a character is injured, it expects treatment.
If something impossible happens, it expects an explanation.
If a situation is unstable, it often tries to resolve it.

That makes sense when you remember the training data is full of ordinary human writing. But in fiction, and especially in interactive fiction, the unusual situation is often the whole point.

The storyteller should not repair the weirdness. It should respect the established world.

That changed how I looked at prompting.

A rule like:

Do not repair unusual situations.

is still not a constraint. It is just another piece of context competing with everything else the model has learned.

The real problem was not prompt quality.

The application was missing structure.

The software engineering solution: validation

That insight led to a much more useful design:

Generate scene
     |
     v
Validate against rules
     |
     +---- allow
     |
     +---- reject or replace

The model is good at generating candidate output.

Software is good at checking whether the output is acceptable.

Those are different responsibilities, and treating them as one thing made the system fragile.

This ended up being the most important architectural change in the whole project.

Not because the model is bad.

But because creativity and constraint enforcement are separate jobs.

Memory is not the same as chat history

Another lesson was that sending the entire conversation back to the model is not the same thing as giving it memory.

In practice, blindly replaying all prior context often makes things worse.

The model does not preserve that history the way a database or domain model would. It compresses, interprets, and reweights it while generating the next response.

What worked better was a layered memory approach:

history.json
    |
    +-- recent-summary.md
    |
    +-- summary.md
    |
    +-- canonical-state.yaml

Each layer has a different responsibility.

The most useful improvement was the recent summary.

It is not just shorter history. It is curated context:

current situation
active writing instructions
important recent details

A smaller amount of relevant context often beats a huge amount of raw history.

More context is not automatically better context.

One model, multiple roles

Another useful pattern was using the same model for different jobs with different settings.

story.temperature=0.6
validation.temperature=0.0
summary.temperature=0.2

The storyteller gets creativity.

The validator gets consistency.

The summarizer gets compression.

The model did not change.

The job changed.

This was another moment where the system started to feel less like prompt engineering and more like software design.

Local models are already useful

The application was developed on a MacBook Pro M1 Max with 64 GB unified memory and talks to a local OpenAI-compatible endpoint such as LM Studio or Jan.ai.

The interesting part was not that a local model could generate text.

That was expected.

The interesting part was that, with the right application structure around it, a local model could maintain a coherent world well enough to build something genuinely usable.

Things I did not learn

After building this application, I can confirm:

AI did not magically make me rich.
My IDE did not become obsolete.
My characters still needed debugging.

The main takeaway

If I had to compress the whole experiment into one lesson, it would be this:

A good LLM application is not a clever prompt. It is software architecture around a probabilistic component.

The model still matters.

But reliability comes much more from the engineering around the model than from the prompt alone.

That feels like the real opportunity for software developers.

Not "AI replaces software."

But:

Software developers learn how to build better systems around AI. The future of AI applications will probably belong less to people who write the cleverest prompts, and more to people who design the best systems around imperfect models.

The current result

The storyteller has grown into a complete local application built around an OpenAI-compatible API.

It now includes:

a storyteller role for creative generation
a validation step for rule enforcement
layered memory instead of full chat replay
asynchronous summary and canonical state updates
configurable prompts and model settings

The model is still probabilistic.

The application around it is what makes the behavior predictable enough to be useful.

The complete project, including the application architecture, prompts, memory handling, and local model integration, is available on GitHub. If you’re experimenting with local LLMs yourself, I hope this project gives you a few ideas—and perhaps helps you avoid some of the pitfalls I ran into while building it.

https://github.com/jbrugman/Assistant

Optional technical notes on model choice

During development I tried several local models.

There was no single best model. The right choice depended on the task.

In my experiments (on my computer):

Qwen3-Coder-30B-A3B gave me the best results for coding tasks
Gemma-4-26B-A4B-QAT gave me the best results for storytelling and general interaction

One interesting observation was that parameter count alone is not a very useful metric.

That was one of the more surprising practical lessons from running models locally:

Bigger does not always mean slower or better.

Mixture-of-Experts (MoE) vs dense models is a good example.

A Mixture-of-Experts (MoE) model works differently.

A normal dense model activates all of its parameters for every response.

An MoE model uses a router that selects only the relevant expert parts of the model for each token. The rest of the network stays inactive.

This makes it possible to build models with a much larger total capacity without paying the full computation cost on every response.

For readers experimenting with local inference, that makes hardware fit and runtime choice at least as important as the model name itself.

Sources

The project on Github: https://github.com/jbrugman/Assistant
LM Studio: https://lmstudio.ai/
Jan.ai: https://jan.ai/
Google Gemma models: https://huggingface.co/google
Qwen models: https://huggingface.co/Qwen

Selfware, software that fits you instead of the world

2026-07-16T05:56:00.000Z

People need not only to obtain things; they need above all the freedom to make things among which they can live, to give shape to them according to their own tastes.

— Ivan Illich
Tools for Conviviality

One word, and it clicked

I recently heard the word selfware from Alex, a great colleague of mine, and I was instantly triggered. It’s one of those rare words that arrives and immediately snaps a bunch of loose observations into place. Because it named something I’d been watching happen in my day-to-day work without quite having a label for it.

Once the term fell into place, I started digging into it. And that turned into a real rabbit hole, this blog is the result.

So I wanted to write about it. Not because I invented the idea, I didn’t, but because that single word connected the dots between things I keep seeing: the software that never quite fits, the AI tools quietly changing who gets to build, and a slow shift in who’s really in control of the tools we work with every day. This blog is my attempt to pull those threads together.

The fit was never right

Think about the software you use every day. Your expense tool. Your CRM. Your project tracker. Your note app.

Now count how much of it you actually use. Ten percent? Twenty? The rest is features built for someone else, workflows designed around someone else’s business model, buttons you’ll never press.

We’ve accepted this for decades. Software is something that happens to you. A large company somewhere decides what you need, ships it to millions of people at once, and you bend your workflow to fit their product. You’re not a maker. You’re a user, a consumer of other people’s visions of how your work should go.

That deal is starting to look strange. And a new word is forming around the alternative: selfware, software built by you, for you. Not a generic product stretched to almost cover your case, but a tool shaped to the exact contour of your problem.

I think this is a real trend, not a gimmick. And like most real trends, it’s arriving faster than the industry is ready to admit.

What selfware actually means

The clearest manifesto for the term lives at selfware.md, where it’s defined as: "Software built by you, for you." The pitch is that for the first time in history you can build exactly what you need, in hours instead of months, in conversation instead of a coding bootcamp.

The core promise is worth quoting: "The software fits your brain like a glove. No unnecessary features. No dark patterns. Every button exists because you put it there."

That’s the whole idea in three sentences. Selfware isn’t about scale. It isn’t a startup. It doesn’t need a market. It just has to solve your problem better than the general-purpose product that was never really built for you in the first place.

If this sounds new, it isn’t, not entirely. It’s the latest name for an idea that’s been circling for twenty years, waiting for the tools to catch up.

An old dream, finally affordable

In 2004, Clay Shirky wrote about situated software, applications "designed in and for a particular social situation or context." Software for dozens of people, not millions. It was a lovely idea and completely impractical at the time. Building anything real was simply too expensive to justify for a handful of users.

Sixteen years later, Robin Sloan wrote a piece that hit a nerve across the whole industry: An app can be a home-cooked meal. He’d built a tiny app just for his family, to send each other short videos. No commercial value. No plan to scale. Made out of care, the way you’d cook a meal for people you love.

Maggie Appleton picked up the thread in her talk Home-Cooked Software and Barefoot Developers, and put her finger on why industrial software feels so ill-fitting. Big software can only afford to solve "the most common needs of the most number of users." Everything else, the real problems that only a few people have, never gets built. Google Maps will never show you the flattest cycling route that avoids every hill, or which streets flood when it rains. A few hundred people might need it, but a few hundred people is not a business case. As she puts it, industrial software is "made for us by people who don’t know much about us."

That’s the gap selfware lives in. Not the common case that SaaS already serves well, but the specific, the peculiar, the exactly-what-you-need corners of your own working life.

For twenty years that gap stayed empty for one boring reason: the people who could build home-cooked software and the people who were professional developers were essentially the same small circle. Everyone else hit what Appleton calls the command line wall and turned back.

The wall just came down.

The AI movement is the missing ingredient.

Here’s where selfware stops being a nice essay and starts being a trend.

Every version of this idea, from Shirky to Sloan to Appleton, ran into the same problem: building software is hard, and experts are expensive. That was the whole constraint. Remove it, and the economics of small, specific software flip completely.

AI coding assistants remove it.

The hottest new programming language is English.

— Andrej Karpathy's

Andrej Karpathy’s quote stopped being a provocation and became a description. You describe what you need, the code materializes, you refine it in a conversation. The skill floor that kept regular people out for forty years has dropped through the floor.

Appleton’s term for the people who walk through that door is barefoot developers, a nod to China’s barefoot doctors of the 1960s: not fully trained physicians, but locals given just enough capability to serve their own communities. The developer version is the teacher who builds an elaborate class tracker, the ops lead who wires up a dashboard, the analyst pushing a spreadsheet past its limits. People who understand a problem intimately because they live inside it, now able to build the tool that fixes it.

This is the part I find genuinely exciting. The advantage isn’t that AI writes code faster. It’s that it hands the tool to the person with the most context, the one who actually feels the friction, instead of routing the problem through a product owner at some faraway tech company trying to understand your job over a Zoom call.

What this does to the software lifecycle

Now the part most people miss. Selfware doesn’t just change who builds software. It breaks the traditional software lifecycle, and that matters, because the lifecycle is how our whole industry is organized.

Think about how traditional software lives and dies. You gather requirements. You design. You build. You test. You deploy. Then comes the long, quiet stretch afterward, maintenance, patching, migrations, and eventually end-of-life, when the vendor sunsets the product or the contract lapses and you have to migrate. Every stage assumes software is expensive to make, so it must be made to last, maintained carefully, and amortized over years.

Selfware quietly demolishes that assumption. When creating and changing software approaches zero marginal cost, several stages of the lifecycle collapse.

Requirements stop being a document handed to someone else and become a running conversation with the thing you’re building. Maintenance stops meaning "keep the old code alive" and starts meaning "regenerate it when your needs change." Software becomes less like a building you maintain and more like a meal you cook again when you’re hungry. Disposable in the best sense, cheap enough to throw away and remake rather than defend forever.

And the vendor lifecycle, the part where someone else’s roadmap decides your fate, largely disappears. This is the piece that connects directly to the sovereignty argument. Appleton warns of a future where barefoot developers build wonderful local tools but rent them from the cloud, until "the terms of service change… the subscription fee doubles. And it turns out what they’ve built was never actually theirs all along." Selfware, done right, is software you own outright. Full source, running on hardware you control, no roadmap but yours, no end-of-life but the one you choose. It’s digital sovereignty scaled all the way down to the individual.

Let’s be honest about the flip side. A lifecycle exists for reasons. Testing, documentation, security review, and maintenance aren’t bureaucracy for its own sake, they’re what stops software from quietly failing in ways that matter. Home-cooked code handling your family photos is one thing. Home-cooked code handling patient records or payroll is another. The lifecycle didn’t vanish because you stopped doing it. It just moved onto your plate.

The SaaS reckoning

None of this is lost on the industry, which is why the trade press has spent 2026 arguing about it.

The headlines tell the story. Forbes calls it the end of one-size-fits-all software, while others ask whether AI is the end of SaaS as we know it or point to a coming era of malleable software, where products bend to the user instead of the other way around.

The case for the end of SaaS is strong: when changing software becomes cheaper than distributing standardized products, the SaaS model destabilizes its own foundation. Why rent a bloated general tool when a custom one costs an afternoon?

The other side deserves equal airtime, because I don’t think SaaS simply dies. Most vendors will pivot to selling AI agents rather than seats. Plenty of software is genuinely hard: security, scale, compliance, integrations. And you do not want to home-cook your bank’s core ledger. What’s more likely than the death of SaaS is a split: commodity and personal workflows move to selfware, while the genuinely hard, high-stakes, shared infrastructure stays professional. What’s actually at risk is the middle: the many average tools that only exist because building your own used to be too expensive.

How to think about it, without kidding yourself

If you’re tempted, and you should be, here’s how I’d approach selfware without getting burned.

Start where the stakes are low and the fit is bad. Your personal dashboards, your repetitive glue work, the internal tool nobody in the market will ever build for you. This is the land of opportunity, and it’s also where a rough first version costs you nothing.

Match the ambition to your capability, honestly. Here’s where I want to be careful, because as a software engineer I see both sides of this. The opportunity is real: anyone can now start building. But starting and succeeding are two different things. AI hands you the Lego bricks, but as Appleton notes, "language model legos need glue." Getting to a first version is easy. Keeping it running, deploying it, securing it, backing it up, storing data safely, and not quietly leaking that data, is still real engineering. That gap between "it works on my machine" and "it holds up in the real world" is exactly where our craft lives, and AI hasn’t closed it. So the door is open to everyone, but walking through it still takes skill. If you don’t have those skills yet, keep your selfware small and local, and leave the load-bearing systems to professionals for now.

Build for ownership from day one. If your home-cooked tool ends up trapped in someone else’s cloud on a subscription that can double overnight, you’ve just rebuilt the trap you were escaping. Keep the source. Keep it portable. Keep an exit.

And be clear-eyed about the lifecycle you’re taking on. When you build it yourself, you own the maintenance, the security, and the end-of-life too. Sometimes that trade is obviously worth it. Sometimes buying the one-size-fits-all product is the smart, sovereign choice. The point isn’t to build everything yourself. It’s to make it a decision instead of a default.

Make it happen

The question is no longer "which product should I adopt and adapt to?" It’s becoming "which of my problems can I afford to solve myself?"

For the specific, the peculiar, the exactly-what-you-need, the answer is increasingly: build it. It’ll fit like a glove, because you’re the one putting every button where it belongs.

Michael Jordan said it better than any technologist could:

Some people want it to happen, some wish it would happen, others make it happen.

— Michael Jordan

Selfware is simply the moment when making it happen stopped being reserved for the few. The tools are here.

Contemplations

2026-06-30T05:00:00.000Z

The world is changed.
I feel it in the water.
I feel it in the earth.
I smell it in the air.
Much that once was is lost, for none now live who remember it.
— Galadriel (The Fellowship of the Ring)

Last week, I was having a nice dinner with some longtime friends. If you want good food, good booze, and good times, Black Smoke really does the job! Since we are all in our 30s, we were discussing things that matter at our age: friends, family, and the work we do. Naturally, we landed on the question of whether it would make sense to do a career switch. So, I threw this into the mix: "Well, actually, I kind of did. But I don’t know if I really like it. It mostly just happened…".

The rest of the group looked at me with utter astonishment. After all, I hadn’t changed my job at all, right? You’ve probably already guessed it: as posts on the JDriven blog tend to be technical, it’s about the shift to AI. Of course! But my friends, most of whom work outside the tech sector, some not even in white-collar jobs, don’t know as much about AI as people in tech do. Sure, they use ChatGPT, but it doesn’t compare to how rapidly software engineering is changing. So, I explained that, to put it bluntly, my job had changed from builder to reviewer.

It’s something I’m still trying to figure out. A couple of months ago, a colleague shared AI fatigue is real and nobody talks about it. It’s an excellent post about all sorts of challenges you face as an engineer when using AI to its full potential. I wrote in reaction:

Thanks for sharing indeed! I also feel like coding has become way less fun now that AI is everywhere. Like it stole a thing I was particularly good at after years of craftsmanship, and now everybody can just do it. Especially that "You became a reviewer, and you didn’t sign up for it" resonated a lot with me.

Now that I’ve spent many more days using AI, I stand firmly behind those words. Not just because I consider them true, but because I experience them as true. Let me give an example: Over the last few years, I have been really excited about functional programming. To learn more, I even joined the FP focus group within JDriven. We discovered new concepts and learned from one another, as we were all at different skill levels. I particularly loved learning that some languages are sophisticated enough to express advanced concepts within the language itself. So, a Scala blog post like Generic Derivation was a real treat. Although I never got that good at Scala, it still gave me the foundation to understand and write fairly complex Kotlin code. Removing code duplication by using Type Classes? Check!

But is this knowledge starting to become obsolete? What does it matter if the AI doesn’t use these advanced paradigms and chooses the 'old-fashioned' way instead^[1]? The code runs just fine. Even the joy of Kotlin is starting to wane. I used to be enthusiastic about infix and extension functions. I mean, compare these two assertions:

// AssertJ
assertThat(fellowshipOfTheRing).hasSize(9);
assertThat(wizard)
    .extracting(wizard::getName, wizard::getAge)
    .containsExactly("Gandalf", 2019);

// Kotest
fellowshipOfTheRing.shouldHaveSize(9)
wizard shouldBe Wizard(
    name = "Gandalf",
    age = 2019,
)

The latter reads much more naturally due to Kotlin’s language features. I imagine even a non-coder could easily understand it. Way cooler, right? Well, not so much if you only quickly scan the generated test classes anyway… I could continue to give examples, but I think my point is clear.

There is one thing I must mention, though. One could say: let’s just not use AI. But even if we disregard the corporate push for AI, I already notice that I don’t want to go back to the way things were. Having AI quickly scan and summarize what a system is doing, write code at lightning speed, generate visuals for presentations, create a bunch of Jira stories, and even help improve this very blog post is just too handy! Yet, I still feel that craftsmanship and skill are slowly being replaced by a general slop.

Is the future of software engineering bleak then? I guess it depends on who’s asking. Those who really love the coding itself—syntax and all—would probably answer with a tentative "yes". For others who love the business side much more than the actual coding, it would be a "no". Or maybe a "not yet". The problem here is that AI is changing the world so fast that we cannot predict its future very well. There have been some attempts, like AI 2027 and Europe 2031, but both have a negative bias to begin with^[2]. Furthermore, these reports look at the industry as a whole. For an individual engineer, this question should be asked on a more personal level: "Do I still love my job, now that it is changing into something else? And what do I have to do to keep up?"^[3].

To be honest, that’s where I am stuck right now. There is no definitive guide or source out there to help with this question. We can look back at history to see how people reacted to previous major shifts. To name just the most important: the mastery of fire, the origin of language, the dawn of agriculture, the invention of the wheel, writing, the rise of religion, the invention of the printing press, the coming of the Industrial Revolution, electricity, and, later on, the digital revolution. While these events occurred in increasingly rapid succession, a common pattern emerges for those we have records of: people in all ages have responded to transformative technologies with a mix of excitement, fear, skepticism, and adaptation^[4]. The same applies to our current age. A 2018 study Artificial Intelligence and the Future of Humans showed that 63% believed people would be better off with advanced AI, while 37% believed they would not^[5]. So where does that leave us?

For me, this is an ongoing struggle. That’s also why I wrote this post: I have a feeling this sentiment is shared by many more people in our field than it might seem. The internet is flooded with AI enthusiasm. On the other extreme, some are fiercely against the use of AI. But for most of us, we’ve simply been thrown into it, whether we like it or not. So, at the very least, I suggest we start talking about it! Don’t hesitate to voice your discomfort. And while doing so, try to ride the waves of AI as best as you can. Or at least, that’s what I’ve been trying to do.

To end this post, let’s get back to the quote I started with. Real Tolkien fans know it’s actually an adapted quote from Treebeard in the book "The Return of the King". Still, I chose the film version because of that final line: "for none now live who remember it". Perhaps that’s where we are headed, our job slowly fading into something else until it no longer exists. Well, if that’s the case, let’s enjoy it while we can. And maybe, one day, we can tell our grandchildren about the days when we programmed the machines ourselves. Now that would be a tale to tell!

1. AIs tend to generate the most common implementations simply because their training data contains more of those patterns. That’s also why they are still much better at writing Java code than generating the underlying bytecode.

2. If you prefer narrative scenarios, I recommend reading Life on Claude Nine by Igor Babuschkin. It has also been wonderfully adapted into the animated video: 72-Hour AI Takeover: A Realistic Scenario.

3. Though it is outside the scope of this blog, it is interesting to note the reverse-shift: non-coders entering the software engineering field through vibe-coding and gradually becoming interested in the underlying code. See I used vibe-coding to actually learn programming, and it worked better than any course for an example.

4. You might not expect it, but it is surprisingly hard to find papers supporting this claim. Though they do not really prove my point, the subject is touched upon by The Sisyphean Cycle of Technology Panics, Understanding successive industrial revolutions: A “development block” approach, and Long waves of technological innovations.

5. Note that this research was conducted before the widespread use of LLMs; I wonder what these numbers would be right now!

Kotlin Kandy: Get Text Before Or After A Delimiter

2026-06-09T04:15:09.000Z

Kotlin adds the substringBefore, substringBeforeLast, substringAfter and substringAfterLast extension functions to the String class. Instead of using indices to get a substring you can use a string or character value. The functions without Last use the first occurrence of the delimiter and the methods with Last use the last occurrence. If the delimiter is not found the original string is returned. You can supply a value that should be returned when the delimiter is not found.

The following example code uses the extension functions in several use cases:

val s = "Kotlin Kandy Blogpost"

// Get the substring after a given delimiter character.
assert(s.substringAfter(delimiter = ' ') == "Kandy Blogpost")
// Get the substring after a given delimiter string.
assert(s.substringAfter("Kotlin ") == "Kandy Blogpost")

// When the delimiter is not found the original string is returned.
assert(s.substringAfter(delimiter = '!') == "Kotlin Kandy Blogpost")

// Use a second argument that should be returned if
// the delimiter is not found.
assert(s.substringAfter(delimiter = '!', missingDelimiterValue = "not found") == "not found")
assert(s.substringAfter("Java", "Joy") == "Joy")

// If delimiter appears more than once using substringAfterLast
// will return the value after the last occurrence of the delimiter.
assert(s.substringAfterLast(delimiter = ' ') == "Blogpost")


// Get the substring before a given delimiter character.
assert(s.substringBefore(delimiter = ' ') == "Kotlin")
// Get substring before a given delimiter string.
assert(s.substringBefore("Kandy") == "Kotlin ")

// When the delimiter is not found the original string is returned.
assert(s.substringBefore(delimiter = '!') == "Kotlin Kandy Blogpost")

// Use a second argument that should be returned if
// the delimiter is not found.
assert(s.substringBefore('@', missingDelimiterValue = "not found") == "not found")

// If delimiter appears more than once using substringBeforeLast
// will return the value before the last occurrence of the delimiter.
assert(s.substringBeforeLast(delimiter = ' ') == "Kotlin Kandy")

Written with Kotlin 2.3.20.

Original post

Kotlin Kandy: Get A Random Element From A Collection

2026-05-19T04:17:27.000Z

Kotlin has very useful extensions functions for working with collections. These extension functions make working with collections more easy and fun. One of the extension functions is the random function. When you call random() Kotlin returns a single element from the collection using the default random source. The function also accepts a Random instance as argument. This instance has a seeded value to return repeatable random values.

In the following example you can see different ways to use random on collections:

import kotlin.random.Random

val languages = listOf("Kotlin", "Groovy", "Java", "Scala")

// Calling random() without arguments uses the default random source.
val language = languages.random()
assert(language in languages)


// When you use the same seed you get the same result.
assert(languages.random(Random(42)) == "Kotlin")
assert(languages.random(Random(42)) == "Kotlin")


// Reusing the same Random instance gives you a repeatable sequence
// of random values.
val randomLanguages = Random(123)
val picks = List(5) { languages.random(randomLanguages) }

assert(picks == listOf("Kotlin", "Groovy", "Scala", "Groovy", "Kotlin"))


// A Set is also a collection, so random works here as well.
val colors = setOf("red", "green", "blue", "yellow")
assert(colors.random(Random(42)) == "red")


// You can also use random on Map.entries.
val tools = mapOf(
    "build" to "Gradle",
    "http" to "Ktor"
)

assert(tools.entries.random(Random(42)).toPair() == ("build" to "Gradle"))


// Calling random() on an empty collection throws a NoSuchElementException.
val failure = runCatching { emptyList<String>().random() }
assert(failure.exceptionOrNull() is NoSuchElementException)

Written with Kotlin 2.3.20.

Original post

Event System: Breaking Down the Basics

2026-05-15T05:00:00.000Z

Jim is a guy who never stops exploring. A couple of years ago, he dove into dependency injection. But now, all of a sudden, something else hit him. Event systems are pretty common these days. As a Spring guy, he’s been using events for ages, but now he feels the need to know how they actually work under the hood. So, how do they actually work?

IYKYK

I assume as a reader you are familiar with these event systems as well. But to be sure, let’s show a simple example. Spring automatically wires up an ApplicationEventPublisher bean, which you can use to send events:

@Service
@RequiredArgsConstructor
public class OrderService {
    private final ApplicationEventPublisher publisher;

    public void placeOrder(String orderId) {
        // business logic
        publisher.publishEvent(new OrderPlacedEvent(orderId));
    }
}

Listening to them is as easy as^[1]:

@Component
public class OrderPlacedListener {
    @EventListener
    public void onOrderPlaced(OrderPlacedEvent event) {
        System.out.println("Order placed: " + event.orderId());
    }
}

Understanding requires insight. Insight must be anchored.

You can find this information in the documentation, of course. But the actual question remains: how does this work? If you think about it, it’s actually way easier than you might expect, because there are only two things going on:

Components can send events
Components can listen to events

To make it work, you need another component that bridges the two. Basically, a component where other components can register their methods as event listeners. Then, when an event is published, all matching listener methods are invoked.

The most basic implementation could look something like this:

@Component
public class EventBus {
   private final List<EventListenerInvoker> invokers = new ArrayList<>();

   public void register(Object bean, Method eventListener) {
       invokers.add(new EventListenerInvoker(bean, eventListener));
   }

   public void publish(Object event) {
       invokers.forEach(it -> it.invoke(event));
   }

   private record EventListenerInvoker(Object bean, Method eventListener) {
       @SneakyThrows
       void invoke(Object event) {
           // Check if the event type matches the first parameter of the listener method
           if (eventListener.getParameterTypes()[0].isAssignableFrom(event.getClass())) {
               eventListener.invoke(bean, event);
           }
       }
   }
}

And then you need a mechanism to loop over all your beans to register them as event listeners (reusing the initializedBeans from our previous DI exploration):

for (Object bean : initializedBeans.values()) {
    for (Method method : bean.getClass().getDeclaredMethods()) {
        if (method.isAnnotationPresent(EventListener.class)) {
            eventBus.register(bean, method);
        }
    }
}

That’s all there is to it. It’s that simple! Of course, you can improve this by supporting multiple event handlers per method, adding a Map to cache listeners by event type for better performance, or using an ExecutorService to make it asynchronous. If you want to see the full implementation, check out the updated example here!

1. By default, Spring events are synchronous. If you need asynchronous behavior, you need to @EnableAsync and use the @Async annotation next to the @EventListener annotation.

Kotlin Kandy: Transform Map Keys Or Values With mapKeys And mapValues

2026-05-12T04:04:38.000Z

Sometimes you want to transform only the keys in a Map, or only transform the values. Kotlin has two useful methods to achieve this: mapKeys and mapValues. You can use mapKeys to transform the keys of the map while keeping the values the same. With mapValues you can transform the values of the map while keeping the keys the same. Both methods accept a lambda function as asrgument of type Map.Entry and must return the new key or value. In order to transform the keys or values and add the result to an existing Map you can use the methods mapKeysTo and mapValuesTo. The first argument is the existing (mutable) Map and the second argument is the lambda function.

In the following example we use mapKeys to transform the keys of a map:

// Sample map with language names as keys and their first release year as values.
val languages = mapOf("Kotlin" to 2011, "Groovy" to 2003, "Java" to 1995)

// Use mapKeys to transform the keys to lowercase.
// The lambda receives a Map.Entry with key and value properties.
assert(languages.mapKeys { it.key.lowercase() } ==
         mapOf("kotlin" to 2011, "groovy" to 2003, "java" to 1995))

// You can use destructuring in the lambda to access key and value directly.
assert(languages.mapKeys { (key, _) -> key.uppercase() } ==
         mapOf("KOTLIN" to 2011, "GROOVY" to 2003, "JAVA" to 1995))

// You can also use the value property in the lambda
// to create a new key based on the value.
assert(languages.mapKeys { "${it.key} (${it.value})" } ==
         mapOf("Kotlin (2011)" to 2011, "Groovy (2003)" to 2003, "Java (1995)" to 1995))

In the next example we use mapValues to transform the values of a map:

val languages = mapOf("Kotlin" to 2011, "Groovy" to 2003, "Java" to 1995)

// Use mapValues to transform the values.
// Calculate the age of the language.
assert(languages.mapValues { 2026 - it.value } ==
         mapOf("Kotlin" to 15, "Groovy" to 23, "Java" to 31))

// Using destructuring in the lambda to access key and value directly.
assert(languages.mapValues { (_, value) -> value * 2 } ==
         mapOf("Kotlin" to 4022, "Groovy" to 4006, "Java" to 3990))

// You can also use the key property to create a new value
// based on both the key and value.
assert(languages.mapValues { "${it.key} was first released in ${it.value}" } ==
         mapOf("Kotlin" to "Kotlin was first released in 2011",
               "Groovy" to "Groovy was first released in 2003",
               "Java" to "Java was first released in 1995"))

We can also use the methods mapKeysTo and mapValuesTo to add the transformed entries to an existing mutable Map instance. The first argument is the mutable Map and the second argument is the lambda function to transform the key or value:

val languages = mapOf("Kotlin" to 2011, "Groovy" to 2003)

// Use mapKeysTo to add transformed entries to an existing mutable map.
val result = languages.mapKeysTo(mutableMapOf("java" to 1995)) { it.key.lowercase() }

assert(result == mapOf("java" to 1995, "kotlin" to 2011, "groovy" to 2003))

// Use mapValuesTo to add transformed entries to an existing mutable map.
val ageResult = languages.mapValuesTo(mutableMapOf("Java" to 31)) { 2026 - it.value }

assert(ageResult == mapOf("Java" to 31, "Kotlin" to 15, "Groovy" to 23))

Written with Kotlin 2.3.20.

Original post

Nushell Niceties: Wrapping External Commands With def --wrapped

2026-05-06T04:52:23.000Z

The def keyword in Nushell is used to define a custom command. By adding the --wrapped flag you can tell Nushell to accept unknown flags and arguments and pass them on as strings. In the command parameters you use a "rest" parameter defined by … to capture the remaining arguments. Then in the command body you use the spread operator … to expand them again. This is very useful when you want to create a small wrapper around an external command with lots of options, but without having to define all those options yourself.

In the following example you see how this can be used to wrap the external command kubectl in a custom command with the name k. You can define the following wrapper command:

# Define custom command k with --wrapped option.
def --wrapped k [...rest] {
    # Forward all arguments passed to the this command
    # to the kubectl command.
    # Add extra -o json argument so the output is JSON.
    # Use from json to parse the JSON into Nushell data structure,
    # so you can use default Nushell commands for querying, selecting
    # and more.
    ^kubectl ...$rest -o json | from json
}

The following example shows how the custom k command can be used to query the JSON output using Nushell commands:

> k get pod api-7d9b6c7f9d-abcde -n demo
    | select metadata.name status.phase spec.nodeName
╭───────────────┬──────────────────────╮
│ metadata.name │ api-7d9b6c7f9d-abcde │
│ status.phase  │ Running              │
│ spec.nodeName │ worker-1             │
╰───────────────┴──────────────────────╯

# Using get items for JSON array output.
> k get pods -n demo
    | get items
    | where {|pod| $pod.status.phase in ['Pending', 'Failed'] and $pod.spec.nodeName == 'worker-2' }
    | select metadata.name status.phase spec.nodeName metadata.namespace
    | rename pod phase node namespace
╭───┬─────────────────────────┬─────────┬──────────┬───────────╮
│ # │           pod           │  phase  │   node   │ namespace │
├───┼─────────────────────────┼─────────┼──────────┼───────────┤
│ 0 │ worker-5b7d8b9f7f-r2mql │ Pending │ worker-2 │ demo      │
│ 1 │ batch-77c99f88c-hj2lm   │ Failed  │ worker-2 │ demo      │
╰───┴─────────────────────────┴─────────┴──────────┴───────────╯

Written with Nushell 0.112.2.

Original post

AI's Impact on Team Dynamics (Part 3) Collaboration & Healthy AI Use

2026-05-01T05:56:00.000Z

In the previous part, I discussed how AI impacts learning and team effectiveness, highlighting the tension between speed and deeper understanding. While AI offers clear advantages, it also introduces new risks for long-term team health.

In this final part, I focus on how teams can consciously integrate AI while preserving collaboration, psychological safety, and strong team dynamics.

Maintaining psychological safety in the AI era

Psychological safety, the foundation of effective team dynamics, faces new challenges in the AI era.

When developers can generate solutions privately with AI, they’re less likely to expose their thinking process to the team. They’re less likely to admit when they’re stuck or uncertain. This personal vulnerability that builds trust gets replaced by a facade of AI-assisted competence.

I expect this effect to be particularly visible with medior developers. Junior developers are expected to ask questions, so they face less stigma in seeking help. Senior developers have already built their network and credibility. But medior developers occupy an awkward middle ground, they feel pressure to appear knowledgeable, and AI gives them a way to maintain that appearance without asking for help. This prevents them from building the deeper relationships that would actually support their growth.

Teams need to actively cultivate an environment where it’s safe to say, "I used AI to create this, but I’m not sure it’s the right approach. Can we review it together?" This requires leadership that models this behavior and explicitly values learning over appearing knowledgeable.

Collaboration

Collaboration is a skill. Like any skill, it requires practice. When developers spend more time interacting with AI and less time interacting with humans, their collaboration skills decline.

They become less adept at explaining their thinking. Less patient with the unstructured way we as humans use for communication. Less skilled at navigating disagreements and finding compromise.

The consequences ripple through every aspect of teamwork. Code reviews that used to spark rich discussions now get perfunctory approvals. Developers assume that if the code works and AI helped generate it, it must be fine. The critical thinking that makes code reviews valuable gets bypassed.

Pair programming becomes less common. Why pair when you can just ask AI or pair program with your personal AI assistant? But pairing isn’t just about solving problems faster. It’s about building shared understanding, transferring knowledge, and strengthening team bonds.

The result is teams that function more like collections of individuals working in parallel. Feedback loops between humans diminish instead of strengthening over time as they do in true collaborative teams.

Strategies for healthy AI integration

So how do we get the benefits of AI without losing the human dynamics that make teams effective? Here are some of my thoughts:

Establish AI usage criteria as a team. Don’t let AI adoption happen organically. Discuss as a team how you want to use these tools. When is AI appropriate? When should you seek human input instead? Make these criteria explicit, and ensure they also account for relevant legislation and moral considerations. Ethical and legal boundaries should guide your decisions just as much as technical convenience.

Use AI as a conversation starter, not a conversation ender. When AI generates a solution, treat it as a draft to discuss, not a final answer. Ask, "What do we think about this approach? What are we missing?"

Protect collaboration time. Schedule regular pairing sessions, architecture discussions, and knowledge-sharing meetings. Make these non-negotiable, even when AI could theoretically replace them.

Rotate AI-free days. Some teams experiment with days where AI tools are off-limits. This forces developers to rely on each other and keeps collaboration skills sharp.

Make learning visible. Encourage developers to share what they learned from AI interactions. "I asked AI about this pattern, and here’s what I discovered." This transforms individual AI usage into collective learning.

Measure what matters. Don’t just track velocity. Track code quality, knowledge distribution across the team, and team satisfaction. If AI is improving velocity but harming these other metrics, adjust your approach.

The future of team dynamics

AI isn’t going away. If anything, these tools will become more capable and more integrated into our workflows. The teams that thrive will be those that consciously shape how AI fits into their dynamics.

To achieve this requires treating AI integration as a team dynamics challenge, not just a technical one. It requires ongoing conversation about what we’re gaining and what we’re losing. It requires leadership that values human connection as much as productivity.

Michael Jordan couldn’t win championships alone, no matter how talented he was. The same is true for software teams. AI can make individual developers more productive, but it can’t replace the collective intelligence, creativity, and resilience that emerges from strong team dynamics.

Conclusion

AI’s impact on team dynamics is neither purely positive nor purely negative. It’s a powerful tool that amplifies our choices. If we choose isolation and speed over collaboration and depth, AI will accelerate that path. If we choose to use AI as a catalyst for better collaboration, it can enhance our team dynamics.

The key is intentionality. We need to actively design how AI fits into our teams, rather than passively accepting whatever dynamics emerge. We need to protect the human interactions that make teams effective, even as we embrace the productivity gains AI offers.

Because at the end of the day, software engineering is still a human journey. The code we write serves human needs. The systems we build are maintained by human teams. And the success of our projects depends on human collaboration.

AI can be a powerful ally in this work. But only if we ensure it enhances, rather than replaces, the team dynamics that make us effective.

So as we integrate AI into our workflow, let’s ask ourselves: Is this making me more connected to my team, or more isolated? Is this deepening our collective understanding, or creating individual silos? Is this enhancing our collaboration, or replacing it?

The answers to these questions will determine whether AI strengthens or weakens your team dynamics. Choose wisely.

AI's Impact on Team Dynamics (Part 2) Learning, Speed & Trade-offs

2026-04-30T05:56:00.000Z

In part one, I explored how AI is subtly changing team dynamics through isolation and echo chamber effects. While AI makes individual developers more productive, it can also reduce the natural collaboration that strengthens teams.

In this part, we take a closer look at what this means for learning, knowledge transfer, and the balance between speed and depth in software development.

The knowledge transfer crisis

One of the most underappreciated aspects of team dynamics is knowledge transfer. When a junior developer pairs with a senior developer, they’re not just solving a problem together. They’re building a mentorship relationship where years of experience, judgment calls, and professional wisdom get transferred. Not just code patterns, but how to think about problems, when to ask for help, and how to navigate uncertainty.

AI disrupts this natural knowledge flow. Junior developers can now generate working code without understanding the underlying principles. They can solve problems without learning why those problems existed in the first place.

I’m not suggesting we should make things artificially difficult. But there’s a difference between using AI as a learning accelerator and using it as a replacement for learning. When developers rely on AI without building their own understanding, they become dependent or, even worse, addicted to AI. They can’t debug effectively. They can’t adapt when requirements change. They can’t mentor the next generation.

The team’s collective knowledge, that shared understanding that makes experienced teams so effective, starts to erode.

But it’s not all negative

Let me be clear: I’m not anti-AI. Far from it. AI tools have great benefits for team dynamics when used thoughtfully. And I believe we are at a tipping point in the history of software engineering. Like Werner Vogels put it in his keynote at AWS re:Invent, it’s the dawn of something new, the renaissance developer.

AI can handle the tedious work that drains energy and motivation. Boilerplate code or repetitive refactoring and not forgetting documentation generation. By automating these tasks, AI frees up mental space for the creative, collaborative work that we as humans excel at.

I’ve seen teams use AI to level the playing field. Developers who struggle with English as a second language can use AI to help articulate their ideas more clearly. Introverted team members who find real-time discussions challenging can use AI to prepare their thoughts before meetings. In both cases, AI removes barriers that have nothing to do with technical ability, ensuring that good ideas get heard regardless of who voices them.

AI can also serve as a catalyst for discussion. Instead of one person proposing a solution, a team can ask AI to generate multiple approaches, then discuss the trade-offs together. This shifts the conversation from "my idea versus yours" to "which of these options best fits our needs?"

When a team uses AI as a shared tool rather than individual aid, it can enhance collaboration.

The speed versus depth trade-off

AI enables incredible speed. Features that used to take days can now be built in minutes. But speed isn’t always what teams need.

Software development is as much about understanding the problem as solving it. It’s about exploring different approaches. It’s about building shared context so the team can maintain and evolve the system over time.

When teams optimize purely for speed, they sacrifice depth. They ship features faster but accumulate technical debt. They solve immediate problems but miss opportunities for systemic improvements.

I’ve seen teams that became addicted to AI-assisted velocity. Their sprint velocity looked impressive on paper, but they sacrificed code quality and introduced security vulnerabilities.

The teams that succeed with AI are those that consciously balance speed with depth. They use AI to accelerate the straightforward parts, then invest the time saved into deeper discussions about architecture, design, and long-term sustainability.

Next in this series: how to maintain psychological safety, collaboration, and healthy AI usage within teams.

AI's Impact on Team Dynamics (Part 1) Isolation & Echo Chambers

2026-04-29T05:56:00.000Z

This blog kicks off a three-part series based on my article “AI’s Impact on Team Dynamics,” originally published in a special edition of JavaPro magazine for JCON Europe 2026, titled Java in the Age of AI. You can find the full magazine here.

In this first part, I explore how AI is already reshaping the way we collaborate as teams and the less visible effects that come with it.

AI’s impact on Team Dynamics

After spending years advocating for strong team dynamics in software engineering, I have been fascinated as AI tools have entered our development workflows. In one of my previous blogs, I touched briefly on how AI might change team dynamics. Now, I want to dive deeper into this transformation, as what we’re experiencing isn’t just a new tool, it’s a fundamental shift in how we work together.

The question isn’t whether AI will impact team dynamics, it already has. The real question is: how do we maintain the human connections that make teams truly effective while embracing these new capabilities?

Spoiler alert: the answer isn’t about the technology itself, it’s about the choices we make in how we use it. AI can be an extremely powerful tool, and I’m a strong supporter of its use. There are hidden dangers though. Using AI irresponsibly can result in social isolation as I will explain in this blog, but we can avoid that by using it consciously and intentionally.

The isolation paradox

Here’s something I’ve noticed: AI assistants are incredibly helpful, but they’re also incredibly solitary. When a developer gets stuck on a problem, they now have a choice. Walk over to a colleague’s desk (or ping them on Slack/Teams) and discuss the issue, or ask an AI assistant for a solution.

The AI option is tempting. It’s instant. It doesn’t judge. It won’t roll its eyes at what might seem like a basic question. And it’s always available, even at 2 AM when you’re debugging that critical production issue.

But here’s the paradox: every time we choose AI over human interaction, we lose something valuable. We lose the spontaneous conversations that lead to unexpected insights. We lose the knowledge sharing that happens naturally when explaining a problem to someone else. We lose the social bonds that make teams resilient during challenging times.

I’ve seen developers who used to be highly collaborative become increasingly isolated. They’re productive, sure. Their code gets written. But they’re operating in a bubble, reinforced by an AI that reflects their own thinking patterns back at them.

The echo chamber effect

When you collaborate with humans, you get challenged. Your assumptions get questioned. Someone points out the edge case you missed or the security vulnerability you overlooked. This friction, while sometimes uncomfortable, is what makes software robust and developers evolve to the ‘next level’.

AI assistants, for all their capabilities, tend to be agreeable. They generate solutions based on patterns they’ve learned, but they don’t push back the way a senior developer would. Junior developers do this too through casual feedback that forces you to reconsider assumptions you didn’t know you were making.

I’ve reviewed code where developers clearly used AI assistance, and while the code works, it often lacks the thoughtfulness that comes from human discussion. It solves the immediate problem but misses the bigger picture. The architectural considerations and more important the lessons learned from past mistakes.

This creates an echo chamber where developers stay trapped in their own perspective, with AI amplifying rather than challenging their approach.

Next in this series: how AI impacts learning, knowledge transfer, and the balance between speed and depth.

Nushell Niceties: Check Semantic Version Is A Match

2026-04-28T04:58:11.000Z

In a previous blogpost you can learn about the semver command in Nushell to transform a string value into a semver type. The command has a subcommand match-req. You can use this command to check if a version matches part of the semantic version parts. The result is a boolean value. The version to compare with doesn’t have to defined fully, but could exist of only the major, minor or patch parts. The value you pass can also be used to check if a version is greater or smaller than a given version. A range with a lower and upper version to match on can be defined as well. The boundary values are separated by a comma.

In the following example the command semver match-req is used with different values:

use std/assert

plugin use semver

let version = '4.0.2'

assert ($version | semver match-req '4.0.2')
assert ($version | semver match-req '4')
assert ($version | semver match-req '4.0')

assert ($version | semver match-req '>=4')
assert ($version | semver match-req '>3')
assert ($version | semver match-req '<5')
assert ($version | semver match-req '>4.0.1')

assert ($version | semver match-req '>3,<5')
assert ($version | semver match-req '>=4.0,<4.1')

assert not ($version | semver match-req '3')
assert not ($version | semver match-req '>5')
assert not ($version | semver match-req '<4')

Written with Nushell 0.111.0.

Original post

Considerations on cognitive load and organisational structure in sociotechnical systems.

2026-04-23T07:00:00.000Z

In this article we present our rule of thumb for the sizing of solutions based on what an organisation can handle. Our primary goal is to make you aware of cognitive load theory and sociological considerations on organisational structure. Be aware that these are somewhat fuzzy theories, which are still debated and do not provide us with definitive answers. We are still convinced that taking these ideas into consideration helps in making organisations more effective. With our rule of thumb we hope to provide organisations a tool for conversation around how to effectively organize flows of work, without overloading and burning down teams.

We start with a short introduction of cognitive load theory and sociological considerations on organisational structure. We finish by examining the organisational structures defined by various agile frameworks.

This is the second iteration of this article. We have now defined the organisational construct in a more theoretical and framework/platform agnostic manner, where the first iteration was written around the three organizational constructs defined by SAFe ^[1]. We decided to dive into the various agile scaling frameworks/platforms that we are currently aware of an discover their approach to organisational constructs. We have added a table that summarizes this information. We have also added a section with the relevant sections from these frameworks/platforms.

Cognitive load theory

The history of cognitive load theory can be traced to the beginning of cognitive science in the 1950s and the work of George Armitage Miller. His classic paper “The magical number seven, plus or minus two: some limits on our capacity for processing information” ^[2], published in 1956, was perhaps the first to suggest our working memory capacity has inherent limits. His experimental results suggested that humans are generally able to hold only seven plus or minus two units of information in short-term memory.`

Cognition is the mental action or process of acquiring knowledge and understanding through thought, experience, and the senses.
Cognitive load is the amount of mental effort caused by factors such domain complexity, technology needed, and related overhead. There are broadly three types of cognitive load that are believed to circularly influence each other, according to work conducted in instructional design pedagogy:
- Intrinsic cognitive load is the inherent level of difficulty associated with a specific instructional topic.
- Extraneous cognitive load is generated by the manner in which information is presented to learners and is under the control of instructional designers.
- Germane cognitive load refers to the working memory resources that the learner dedicates to managing the intrinsic cognitive load associated with the essential information for learning.
Cognitive capacity is the maximum cognitive load an organisational construct can handle.

Organisational structure

We consider an organisation to be an entity comprising a group of persons having a particular purpose. To be effective every organisation will organise itself in one or more organisational constructs. We start by looking at sociology for considerations on the size and cohesion of groups.

Group size

The number of people involved is an important characteristic of any grouping in which social behavior occurs. Large groupings have a tendency to divide into smaller subgroups.

Dyad ^[3]: A group of two persons is important either as a stand-alone group or as a building block of larger groupings. Both persons are able to retain their individuality as there is no fear that another may shift the balance of the group. An infant requires a caregiver in order to survive, so life begins in a pair relationship that is apt to influence later ones.
Triad ^[4]: A group of three persons is hard to maintain. After all, it is easier to deal with one other person than with two. Besides, two of the people in a triad are apt to find it easier to relate to each other than to the other partner. That can motivate the neglected party to drop out of the group. In history, three leaders have sometimes attempted to share political power in a triumvirate, with little long-term success. On the other hand, groups of three can be very stable if there is a leader and two followers, such as a family of a single parent and two children.
Tetrad ^[5]: A group of four persons tends to not last very long, with the notable exception of vocal and musical quartets. Two persons in the group are apt to find it more satisfying to relate to each other than to either of the other persons. If the other two feel left out, they have at least that in common. They may feel a need to counteract the advantage a pair has when acting together over an individual operating alone. The relationship becomes one of two pairs rather than an effective group of four members.

Cohesion

Herbert Arnold Thelen, in his 1949 paper “Group Dynamics in Instruction: Principle of Least Group Size” ^[6], proposed a principle that for members of groups to have maximum motivation to perform, the number of members in each should be the smallest "in which it is possible to have represented at a functional level all the social and achievement skills required for the particular required activity. Robert Melancton Metcalfe, in his 1983 presentation to the 3Com sales force ^[7], states that the financial value or influence of a telecommunications network is proportional to the square of the number of connected users of the system:

As a group gets larger, adding another person has less effect on its characteristics. The communication overhead within a group increases as the number of persons in a group increases. It also takes some time for the person added to a group to become productive. The complexity of a team’s interactions grows as the team expands, making it crucial to understand the stages of team development, the impact of multiculturalism, and the role of communication styles. ^[8] ^[9]

A consideration at least in smaller groups, though, is whether the number of members is even or odd. Doing things together is easy if all those involved agree on what to do, or if the majority opinion is able to override objections without repelling the objectors. A group of six or eight members can split into two equal factions, so decision-making is not apt to be as easy as if the size were five, seven or nine. As groups get larger stalemates are less likely but still can be troublesome. If a group makes decisions by voting it can adopt a means of tie-breaking (requiring one vote more than 50% for a measure to be adopted, giving the presiding officer a tie-breaking vote, or deciding by coin toss). Even-sized small groups often experience lower cohesion than odd-sized small groups.

Robin Ian MacDonald Dunbar, in his 1992 paper “Neocortex size as a constraint on group size in primates” ^[10], defined the following ‘magic numbers’ of group sizes:

5: Our best friends and closest support group
15: The close friends we trust
50: Persons we call friends or would invite to a group dinner
150: Our stable relationships
500: The number of not-so-close acquaintances we can keep
1500: The number of persons we can name and recognize

Frederick Phillips Brooks, in his 1975 book “The Mythical Man-Month” ^[11], observed that under certain conditions, an incremental person when added to a project makes it take more, not less time. Adding more persons to a highly divisible task, such as cleaning rooms in a hotel, decreases the overall task duration (up to the point where additional workers get in each other’s way). However, other tasks including many specialties in software projects are less divisible; Brooks points out this limited divisibility with another example: while it takes one woman nine months to make one baby, "nine women can’t make a baby in one month".

Rule of thumb for sizing of solutions

As collaboration is expensive in terms of cognitive load, this puts a constraint on the size of every organisational construct. Every solution, and every autonomous part thereof, adds an amount of cognitive load to the organisational construct responsible for creating/changing/operating/running that solution, or autonomous part thereof.

Architects are expected to intentionally decompose solutions into autonomous parts. “Domain-Driven Design” ^[12] defines these as bounded contexts, which are isolated from each other and which are easier to change, test, and incrementally develop. This separation allows teams to autonomously focus on their specific bounded contexts without undue interference or complexity from other bounded contexts, which will produce solutions that can be independently designed and delivered. Team Topologies ^[13] offers an approach to designing team-of-teams organizations for fast flow of value. Team Topologies identifies 4 fundamental topologies and three core interaction modes, which explicitly guide inter-team interaction and help create well defined boundaries that reduce cognitive load for each team.

While there is a one-on-one-relation between an autonomous part and a team and a solution and a team-of-teams, be aware that the other way around a team can own multiple autonomous parts and a team-of-teams can own multiple solutions!

Whichever problem an organisation is solving, the solution should be questioned on how well its ‘cognitive load’ fits within the ‘cognitive capacity’ of the organisational constructs.

We have a rule of thumb for the sizing of solutions:

The ‘cognitive load’ of every autonomous part of a solution must not exceed the ‘cognitive capacity’ of a team.
The ‘cognitive load’ of a solution must not exceed the ‘cognitive capacity’ of a team-of-teams.
The ‘cognitive load’ of a large-scale solution must not exceed the ‘cognitive capacity’ of multiple team-of-teams.

"Less is more": Keep organisational constructs small and remember that in complex problem spaces, employing multiple smaller solutions reduces the overall cognitive load.

We hope this article starts a two way conversation within your organisation to prevent ‘cognitive overload’.

Key takeaways:

Collaboration is an expensive type of interaction that limits the size of a team.
Use “Team Topologies” to design organisational constructs (teams and teams-of-teams) which promote flow and focus and align communication structure and architecture.
Use “Domain-Driven Design” to decompose solutions into clever bounded contexts:
1. That match the organisational constructs
2. That reduce the overall cognitive load by minimising the size and complexity of the solution

Organisational structures as defined by various agile frameworks

	Deliverable	autonomous part of a solution	solution	large-scale solution	Multiple Solutions
cognitive load	⇐	⇐	⇐	>
Organisational construct	one team	one team-of-teams	mulitple team-of-teams	N.A.
Agile Scaling Framework	Scrum	Scrum Team (<10 persons)	N.A.	N.A.	N.A.
Scrum-of-scrums	Development Team	Scrum Team (<10 persons)	N.A.	N.A.
Metascrum	Scrum Team (<10 persons)	MetaScrum	N.A.	N.A.
SAFe	Agile Team (<10 persons)	[Essential] Agile Release Train (50-125 persons / 5-15 Agile Teams)	[Large Solution/Portfolio) Solution Train (2+ Agile Release Trains)	[Full Configuration] (2+ Solution Trains)
Less	Scrum Team (<10 persons)	Less (2-8 Scrum Teams)	Less Huge (8+ Scrum Teams)	N.A.
Disciplined Agile Delivery	Small Agile Team (2-15 persons) Medium Sized Team (25-30 persons)	Program Medium-Sized (12-50 persons) Large-Sized (35+ persons)	N.A.	N.A.
Nexus	Scrum Team (<10 persons)	Nexus 3-9 Scrum Teams + Nexus Integration Team	N.A.	N.A.

Background info on the various agile frameworks

Scrum ^[14]

The fundamental unit of Scrum is a small team of people, a Scrum Team. The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.

Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.

The Scrum Team is small enough to remain nimble and large enough to complete significant work within a Sprint, typically 10 or fewer people. In general, we have found that smaller teams communicate better and are more productive. If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product. Therefore, they should share the same Product Goal, Product Backlog, and Product Owner.

The Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required. They are structured and empowered by the organization to manage their own work. Working in Sprints at a sustainable pace improves the Scrum Team’s focus and consistency.

The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint. Scrum defines three specific accountabilities within the Scrum Team: the Developers, the Product Owner, and the Scrum Master.

Scrum Team ⇐ 10 persons:

Team members
Scrum Master
1 Product Owner
1 Product (Goal)
1 Product Backlog
1 Sprint (across all Teams)
1 (Potentially Shippable) Product Increment

Scrum of Scrums ^[15]

When a Scrum Team works on a single product with multiple Development Teams, unresolved dependencies within individual Development Teams create a shared challenge of the Scrum Team.

The Scrum of Scrums is a meeting to coordinate these unresolved dependencies and shared work, in which an ambassador from every Development Team participates.

Metascrum ^[16]

The Metascrum is a forum where the entire enterprise can align behind the Product Owners’ backlogs at every level of Scrum in the organization:

1 MetaScrum Product Owner
Multiple Product Owners
Management
Other Stakeholders

SAFe ^[17]

SAFe integrates the power of Lean, Agile, and DevOps into a comprehensive operating system that helps enterprises thrive in the digital age by delivering innovative products and services faster, more predictably, and with higher quality.

Agile Team = < 10 persons

Agile Release Train (ART) = 50-125 persons/5-15 teams

A team of Agile Teams that align to a shared business and technology mission. Each is a virtual organization (typically 50 – 125 persons) that plans, commits, develops, and deploys together. ARTs are organized around the enterprise’s significant Development Value Streams and exist solely to realize the promise of that value by building and delivering Solutions that benefit the Customer. In addition to the Agile teams, the following roles aid the successful execution of the ART:

Release Train Engineer (RTE) is a servant leader who facilitates ART execution, impediment removal, risk and dependency management, and continuous improvement.
Product Management is largely responsible for ‘what gets built,’ as defined by the Vision, Roadmap, and new Features in the ART Backlog. They work with customers, teams, and Product Owners to understand and communicate their needs and participate in solution validation.
System Architect is an individual or team that defines the system’s overall architecture. They work at a level of abstraction above the teams and components and typically define Nonfunctional Requirements (NFRs), major system elements, subsystems, and interfaces.
Business Owners are key stakeholders of the ART, with final responsibility for the business outcomes of the train.
Customers are the ultimate economic buyers or value users of the solution.

In addition to these critical ART roles, the following functions play an essential part in ART success:

System Teams typically assist in building and maintaining development, continuous integration, and test environments.
Shared Services are specialists necessary for the success of an ART but cannot be dedicated to a specific train. They often include data security, information architects, site reliability engineering (SRE), database administrators (DBAs), and many more.

Solution Train = 2+ Agile Release Trains

The organizational construct used to build large solutions that requires the coordination of multiple ARTs and suppliers. In addition to the ARTs and Agile teams, the following roles aid the Solution Train’s successful execution:

Solution Management defines and supports building desirable, feasible, viable, and sustainable large-scale business solutions that meet customer needs over the solution’s significant lifespan. They represent the customer and business needs to the ARTs.
Solution Architects define and communicate a shared technical and architectural vision across the Solution Train to help ensure the solution under development is fit for its intended purpose. They work with the ART’s System Architects to help guide their portion of the solution’s design.
Solution Train Engineer (STE) is the coach for the Solution Train, facilitating and guiding the work of all ARTs and suppliers. The STE works with Release Train Engineers (RTEs) to facilitate ART execution and coordinate delivery.
Suppliers are internal or external organizations that develop and deliver components, subsystems, or services, which help Solution Trains deliver solutions to customers.
Business Owners are key stakeholders of the Solution Train, with final responsibility for the business outcomes. They, along with Solution Train leaders, may also serve as business owners for the Solution Train’s ARTs.
Customers are the buyers of the solution and ultimately determine value. When delivering in a supply chain, customers work closely with Solution Management and other key stakeholders to define and adjust the solution’s vision, intent, and delivery roadmap.

Due to their size and cost, large solution development attracts a lot of attention, heightening stakeholder involvement and increasing opinions, governance, and oversight. The Solution Train leadership team – Solution Managers, Architects, and STE – must be aligned and represent a consistent force to realize the solution’s vision. The STE should ensure this team has the time and space to form as a team and build cross-role transparency and trust. The following roles also play an essential part in the Solution Train’s success:

A System Team is typically formed for the Solution Train to address the integration issues across the ARTs. Individual ARTs may have their own Systems Teams. All System Teams share resources and align on common infrastructure and toolchains where possible.
Shared Services represent the specialty roles, persons, and services required for the success of the Solution Train, but that cannot be dedicated full-time. Sometimes, they may be devoted to the Solution Train and shared across the ARTs.

SAFe defines a number of configurations, which to adopt depends on your organization’s size, complexity, and need for strategic alignment:

Essential = 1 Agile Release Train = 50-125 persons/5-15 teams

Large Solution = 1 Solution Train = 2+ Agile Release Trains

Large Solution SAFe is for enterprises building large and complex solutions that do not require portfolio concerns.

Portfolio = 2+ Agile Release Trains

Full = 2+ Solution Trains

A SAFe Portfolio is a set of value streams that delivers a continuous flow of valuable solutions to customers within a common funding and governance model. The SAFe Portfolio consists of multiple Development Value Streams (DVS). Each DVS has a lean budget and consists of one or more Solutions and the persons who maintain and evolve those solutions. Typically, these persons are organized into Agile Teams, Agile Release Trains (ARTs), and Solution Trains. Additionally, the portfolio defines a set of Portfolio Epics representing significant solution development initiatives. The Portfolio Backlog captures those epics to enable governance of their investments’ discovery, risk, and MVP evidence. Portfolio epics may span multiple DVSs and require coordination using Value Stream Coordination practices.

Epic Owners take responsibility for guiding the collaborations needed to realize value from epics.
Enterprise Architects assist in ensuring Business Epics advance the overall enterprise technical architecture. For more technical Enabler Epics, they may also act as Epic Owners.
The Value Management Office (VMO) coordinates, supports, and encourages continuous improvement across the portfolio. To ensure the maximum flow of business value through each DVS, portfolio members apply Value Stream Management. The portfolio may also coordinate and apply Big Data practices to ensure optimal use, and that value is gained from the data collected and managed across the DVS.

LeSS ^[18]

LeSS is Scrum applied to many teams working together on one product.

Scrum Team = 3-9 persons

LeSS

2-8 Scrum Teams

Less Huge

8+ Scrum Teams
Multiple Requirement Areas
- 1 Area Product Owner
- 1 Area Product Backlog [Filter/view on Product Backlog]
- 4-8 Teams

Disciplined Agile Delivery ^[19]

Scrum Team = 2+ persons

Program = Team of Scrum Teams

Scrum Teams can range in size from two persons to twenty to two hundred or more. Larger teams are typically formed to address more complex problems, and as a result large teams take on the challenges of greater domain complexity and/or greater technical complexity as described below. Team size tends to directly affect how you organize the team and how you coordinate within the team. For example, a large agile team of 600 will be organized into subteams and a leadership team will be required for coordination, something we capture in DA’s Program life cycle. A team of 50 will also be organized into subteams, although coordination will likely be simpler and possibly handled by a daily coordination meeting of representatives from each subteam (a technique referred tas a Scrum of Scrums). It is fairly straightforward to coordinate the activities of a team of 10 persons.

A program is a collection of related initiatives managed in a coordinated way to obtain benefits not available from managing them individually. A program team is typically organized as a team of teams, called sub-teams or squads. Structures are required to coordinate persons, requirements, and technical concerns within the overall program. Where a simple “scrum of scrums” may suffice coordination on small-to-medium sized programs (say up to five or six sub-teams) small-to-medium sized programs (say up to five or six sub-teams).

Small Agile Teams = 2-15 persons
- Small DAD Team:
  - Team Members
  - Product Owner
  - Team Lead (an evolution of Scrum’s Scrum Master role) and the Architecture Owner are often, but not always, the same person on small teams.
    This can be challenging because good Team Leads need solid persons and leadership skills whereas good Architecture Owners need solid technical skills and knowledge of the existing infrastructure and it can be hard to find all of these in a single person.
- Supporting Cast:
  - Technical Expert(s)
  - Domain Expert(s)
  - Independent Tester(s)
  - Integrator(s)
Medium Sized Teams = 25-30 persons
- DAD Team:
  - Team Members
  - Product Owner
  - Team Lead
  - Architecture Owner
  - Specialist(s)
- Supporting Cast:
  - Technical Expert(s)
  - Domain Expert(s)
  - Independent Tester(s)
Medium-Sized Team-of-Teams/Programs = 12-50 persons
- DAD Subteam(s):
  - Team Members
  - Product Owner
  - Team Lead
  - Architecture Owner
  - Specialist(s)
- Supporting Cast:
  - Technical Expert(s)
  - Domain Expert(s)
  - Independent Tester(s)
  - Integrator(s)
Large-Sized Team-of-Teams/Programs = 35+ persons
- Leadership Team:
  - A Product Management (or Product Ownership) strategy where the Product Owners coordinate their activities
  - An Architecture (or Architecture Ownership) strategy where the Architecture Owners coordinate their activities
  - A Product Coordination (or Management) strategy where the Team Leads coordinate their activities.
  - An optional Program Manager/Coordinator, a specialist role, is responsible for coordinating the overall leadership team.
- DAD Subteam(s):
  - Team Members
  - Product Owner
  - Team Lead
  - Architecture Owner
  - Specialist(s)
- Supporting Cast:
  - Technical Expert(s)
  - Domain Expert(s)
  - Independent Tester(s)
  - Integrator(s)

Nexus ^[20]

Nexus

3-9 Scrum Teams
Nexus Integration Team
- 1 Product Owner
- 1 Scrum Master
- Appropriate members from the Scrum Teams (with the necessary skills and knowledge to help resolve the issues the Nexus faces at any point in time)

The Nexus Integration Team is accountable for ensuring that a done Integrated Increment (the combined work completed by a Nexus) is produced at least once a Sprint. It provides the focus that makes possible the accountability of multiple Scrum Teams to come together to create valuable, useful Increments, as prescribed in Scrum. Membership in the Nexus Integration Team takes precedence over individual Scrum Team membership. As long as their Nexus Integration Team responsibility is satisfied, they can work as team members of their respective Scrum Teams. This preference helps ensure that the work to resolve issues affecting multiple teams has priority.

Scrum@Scale ^[21]

Scrum Team = < 10 persons

Scrum of Scrums (SoS)
- 4-5 Scrum Teams
- Product Owner Team
  - Scrum of Scrums Master
  - Chief Product Owner
- Metascrum
Scrum of Scrum of Scrums (SoSoS)
- Multiple Scrum of Scrums
- Executive Action Team
  - Scrum of Scrum of Scrums Master
  - Product Owner
- Executive Metascrum

Crystal ^[22]

Various methodologies in the Crystal family also known as weights of the Crystal approach are represented by different colors of the spectrum:

Crystal Clear = 1-6 persons
Suitable for short-term projects where members work out in a single workspace.
Crystal Yellow = 7-20 persons
Feedback is taken from Real Users. This variant involves automated testing which resolves bugs faster and reduces the use of too much documentation.
Crystal Orange = 21-40 persons
The team is split according to their functional skills. Here the project generally lasts for 1-2 years and the release is required every 3 to 4 months.
Crystal Orange Web = 21-40 persons
Projects that have a continually evolving code base that is being used by the public. It is also similar to Crystal Orange but here they do not deal with a single project but a series of initiatives that require programming.
Crystal Red = 40-80 persons
Teams can be formed and divided according to requirements.
Crystal Maroon = 80-200 persons
Large-sized projects where methods are different and as per the requirement of the software.
Crystal Diamond & Sapphire
This variant is used in large projects where there is a potential risk to human life.

Spotify Model ^[23]

Squads (typically 6-12 persons): A Squad is similar to a Scrum team, and is designed to feel like a mini startup. They sit together, and they have all the skills and tools needed to design, develop, test, and release to production. They are a self organizing team and decide their own way of working – some use Scrum sprints, some use Kanban, some use a mix of these approaches. Each squad has a long term mission such as building and improving the Android client, creating the Spotify radio experience, scaling the backend systems, or providing payment solutions. A squad doesn’t have a formally appointed squad leader, but it does have a product owner.
Tribes ⇐ 100 persons: A tribe is a collection of squads that work in related areas – such as the music player, or backend infrastructure. The tribe can be seen as the “incubator” for the squad mini startups. , and have a fair degree of freedom and autonomy. Each tribe has a tribe lead who is responsible for providing the best possible habitat for the squads within that tribe. The squads in a tribe are all physically in the same office, normally right next to each othereach other, and the lounge areas nearby promote collaboration between the squads. Tribes are sized based on the concept of the “Dunbar number”, which says that most persons cannot maintain a social relationship with more than 100 persons or so (the number is actually larger for groups that are under intense survival pressure, which isn’t really the case at Spotify, believe it or not…). When groups get too big, we start seeing more things like restrictive rules, bureaucracy, politics, extra layers of management, and other waste. So tribes are designed to be smaller than 100 persons or so.
Chapters and Guilds: This is the glue that keeps the company together, it gives us some economies of scale without sacrificing too much autonomy.
Chapter: The chapter is your small family of persons having similar skills and working within the same general competency area, within the same tribe.
Guild: A Guild is a more organic and wide reaching “community of interest”, a group of persons that want to share knowledge, tools, code, and practices. Chapters are always local to a Tribe, while a guild usually cuts across the whole organization. Some examples are: the web technology guild, the tester guild, the agile coach guild, etc.

1. https://scaledagileframework.com

2. https://archive.org/details/miller1956_202204

3. https://en.wikipedia.org/wiki/Dyad_(sociology)

4. https://en.wikipedia.org/wiki/Triad_(sociology)

5. https://en.wikipedia.org/wiki/Size_of_groups,_organizations,_and_communities

6. https://www.jstor.org/stable/1082755

7. https://en.wikipedia.org/wiki/Metcalfe%27s_law

8. https://medium.com/@carlosbueno.kinder/the-complex-dynamics-of-team-growth-unraveling-the-layers-with-metcalfes-law-and-multicultural-efd29edf79c

9. https://getlighthouse.com/blog/developing-leaders-team-grows-big

10. https://vidauniversoydemas.wordpress.com/wp-content/uploads/2013/06/sns3.pdf

11. https://archive.org/details/mythicalmanmonth00broo/page/n5/mode/2up

12. https://www.domainlanguage.com

13. https://teamtopologies.com

14. https://www.scrum.org

15. https://scrumbook.org.datasenter.no/product-organization-pattern-language/scrum-of-scrums.html

16. https://scrumbook.org.datasenter.no/product-organization-pattern-language/metascrum.html

17. https://scaledagileframework.com

18. https://less.works

19. https://www.pmi.org/disciplined-agile

20. https://www.scrum.org/resources/nexus-guide

21. https://www.scrumatscale.com

22. https://www.geeksforgeeks.org/crystal-methods-in-agile-development-framework

23. https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf

Building a fullstack digital city in kubernetes hosted on an EU cloud

2026-04-21T09:00:00.000Z

In less than 24 hours we had 25+ developers build 10 technical diverse fullstack applications on a Kubernetes cluster running on European cloud STACKIT, integrating via OpenAPI, using a shared AI-prompt for graphic style coherence.

The Conflux fullstackathon recipe

Every year the colleagues of various Conflux brands get together over a weekend to tackle an assignment that involves backend and frontend development in some way or another. Though it’s all in good fun, it has a competitive angle and every year the winning team puts together the assignment for the next year. Last year the fullstackathon involved throwing together IoT-devices and applications to liven up the office and my team won by combining digital displays, LED-strips, motionsensors and an SVG-based office overview to help colleagues determine which meeting room was free without having to walk there first. The fact that my teammate Wilco van Beijnum managed to rewrite the firmware in the motionsensors helped tip the balance in our favor and we were asked to create an assignment for this year.

The theme for 2026

Much too close to the deadline of this year’s fullstackathon, we held a brainstorm session to see what we could come up with. We found several sources of inspiration:

We wanted to create a cyberspace, inspired by the way DDS laid out their online services in the 90s
Within Conflux we publish a Divotion Tech Radar and a JDriven Tech Radar every half year, in which we identify and discuss technological trends. It would be great if we could have a cyberspace where every individual contribution could use its own tech stack.
As can be read in the upcoming JDriven Tech Radar, we do not recommend vibecoding, but decided this event would be an outstanding opportunity to go wild with AI-assisted coding and actually anticipate the dangerous consequences of things breaking.
Sovereignty is a major concern in both the political and the digital realm right now. We wanted to give this attention in a lighthearted way.
In the spirit of collaboration we decided to forego the competitive element and instead focus on setting a goal that would only be met if everyone would work together. We decided that if this event was fun enough, we wouldn’t need a "winner" to organise next year’s event; enough folks would be inspired to step up to the task.

The resulting recipe for the weekend was as follows:

A king would task Conflux with building a digital city. Because I’m into LARP I decided I’d roleplay the king for the occasion. The rest of the team would be the King’s Council and together we’d be present at the fullstackathon event to explain the task at hand and pivot if needed.
This digital city would have to be built in a sovereign cloud. We looked around for European cloud providers that support a form of managed Kubernetes. We settled on German cloud provider STACKIT, or commonly referred to as "the Lidl cloud" as it’s founded by Lidl’s parent company Schwarz Group. Because the name Lidl was taken from Ludwig Lidl, we found a name for our king: King Ludwig. And so his city became Ludwighafen.
The king would need a castle. We decided that we would build this ourselves, and in doing so develop a means of deploying buildings to Ludwighafen.
The King’s Council would suggest services the city needed, and our colleagues would be free to team up and build whatever they chose. This was to be the core challenge of the fullstackathon. It was the first time we went for a cooperative angle for this event, rather than making it a competition.
The King would have an unreasonable and authoritarian streak and intentionally be vague and change his mind on requirements, in case the assignment would turn out to be too easy to complete.
Regardless of what the teams came up with, it would need a frontend and a backend and would have to be built into a Docker image, uploaded to a container registry and deployed into the Kubernetes cluster we prepared for them. It would also need health-check endpoints. And people would have to supply the king and his council with three images for their piece: one under construction, one finished and one burning.

The setup

The basics: kubernetes and the means to use it

Our organising team set up accounts in STACKIT and set up a container registry via the STACKIT web portal. Anything any team would construct, they would have to put into a Docker image and upload it there.

We then set up a project fullstackathon and in it, under Runtime → Kubernetes Engine, we created a cluster. Under IAM, we created a custom role for our fullstackathon participants, allowing access to the Container Registry, adding a pod to a namespace and starting it. We weren’t very familiar with the particular access structure so we chose to be very restrictive and add permissions later if needed.

We used infrastructure as code to set up http-routes (using a Gateway API), limit-ranges, resource-quotas, and a service-account. This was all tied to together with Kustomize and its built-in secretGenerator in combination with STACKIT’s Robot Accounts to allow every team’s pod to use the image-puller Service Account to pull the uploaded Docker Image from the Container Registry and effectively deploy and run their application in Ludwighafen.

Keys to the kingdom

Ludwighafen was set up to be a website reachable via (the now defunct) ludwighafen.eu and any city service a team would build would have its own namespace and a corresponding subdomain. To keep a bit of control, we’d create the namespaces when a team indicated what service they were going to build and give them an upload key for it. We built a form for requesting it, where they could upload their visuals too. To ensure the image would fit the plot, we supplied an example AI-prompt for generating images in the right style and size. We added a shell-script for generating namespaces so that we’d be able to get teams going quickly during the fullstackathon.

All any team would have to do besides dockerizing their application and pushing it to the Ludwighafen (STACKIT) Container Registry was to create a deployment.yaml mentioning the namespace, selector, metadata and container image, and call kubectl apply -f deployment.yaml to deploy and activate their application in Ludwighafen.

Central application

We then decided to build the central application, that would visually be the city as well the castle at its center, and technically be charged with checking the availability of the other services in order to show the right image for it in the city map. Once a team requested to build a service and supplied us with the name (for the namespace and subdomain) and the visuals for it, the castle application would show it as under construction. Once the application gave an HTTP 200 OK on an HTTP request to its subdomain, the castle would consider it finished and show the appropriate visual. If after that the service ceased to be 200 OK, it would be rendered on fire and the king would make his concerns known.

The castle application was a Python application with a simple HTML/CSS/JavaScript frontend. And because the proof is in the pudding, we used the mechanisme we were going to unleash on our colleagues as the means to deploy it and make it available.

We tested one demo service: it showed up in the alloted plot in the browser, and clicking it opened the frontend at the intended subdomain.

We did run into some snags which we documented and that ended up becoming our tutorial. In the final minutes before the hackathon we decided to deploy that tutorial itself as an HTML page served via an Nginx application that ran at scroll.ludwighafen.eu, styled appropriately in medieval fashion.

We were ready for the event.

The hackathon

We kicked off the event with a presentation by me dressed as king, explaining I had heard all about digital sovereignty being a thing. Supposedly all colleagues in attendance were hired by me with the irrational expectation that AI would allow them to build whatever I wanted in less than a weekend. I presented the list of requirements that the royal council had put up for me, which as you would expect was very superficial and lacked important details.

After mentioning that people could decide for themselves how to form teams, as long as everything got built, and someone on the council remarked that OpenAPI might be useful for integrating services, it was clear for attendants that this was going to be a collaborative effort full of surprises. When I explained the King likes diversity and, having seen the Tech Radars of Conflux, expected as many technologies as possible to be used, people understood the freedom and challenges they faced. And of course there was still the looming threat of the graphics they had to provide for their service being on fire.

As teams formed, they sent ambassadors to the council to claim plots for services and gather requirements. Some caught on early and came up with their own services to implement. The King and his council, being the group that had prepared this fullstackathon, became somewhat of a platform team, correcting access rights, activating STACKIT AI-model serving, and troubleshooting deployment issues.

While IDEs were being set up and tools like k9s were being configured (as included in the instructions), newly-formed teams scattered across the StayOK location where the event took place, drawing up plans on flipovers or using post-its on windows.

Other people preferred diving straight into code, AI-bootstrapping some unknown tech to get some early results to iterate on quickly. Some people focused on fleshing out the idea, while others wanted to figure out how to upload to the STACKIT container registry and deploy a pod in Ludwighafen kubernetes cluster as soon as possible to make sure they had the basics down and would be able to deliver whatever they’d produce later on.

Challenges

During the hackathon, people were surprisingly creative and productive off of a minimal set of requirements. However, not everything went smooth:

We had limited the available resources for the cluster, thinking it would force people to be more conscious of their resource usage and collaborate on getting the most of out it. But in reality, it was a detriment to the fun process of building things when people had to wait for over 10 minutes for their images to be uploaded.
We had prepared the idea of some chaos engineering to see if people had autohealing and high availability. But deployments took long and there was an abundance of ideas we saw people cramming into their services, so we decided against frustrating that more.
We had recommended Codeberg as a code forge. It sufficed, but had an unfortunate outage during the first day of the hackathon.
We had explained to people to create accounts on STACKIT so they could upload images and deploy their applications. That process had its hiccups, with STACKIT refusing to send passwords or passwords resets to people, and two developers actually ended up locked out of their accounts.
Although the use of AI for vibecoding in new languages and frameworks yielded quick and impressive results, it also plunged teams in technical debt at record speed. Some developers ended up having to wrestle with generated code, rewriting big parts to get desired results.

Especially the constrained resources were a miscalculation. People consequently resorted to more local development first, and as a result one or two teams failed to deploy their latest working application before the end, demonstrating it from their local machine instead. A reminder that proper resource allocation for delivery pipelines and test environments is crucial for timely feedback and the ability to deliver solutions.

The results

At the end of Saturday afternoon every team showed what they had built, and it was glorious. While they had been working and uploading, the city which was always active on a central monitor had been filling up with interesting services.

Developers also quickly learned that if they messed up an application deployment once it had been added, it would lead to a spectacle.

Royal municipal records

The municipal records were a service we had indicated would be crucial. The team that picked this up had dubbed it the Blue Kremlin and went all-in on Big Brother features in a 90s style.

It featured registration of civilizans with name, age and the role & permissions they had. It offered an interface for other services to determine permissions (and no other details) for certain features they offered. The Blue Kremlin showed ads in true 90s fashion, and these actually led to other services in the city.

Community hall

In the community hall you could log in as a civilian and create an avatar.

It featured multiple rooms to explore, like a neighbourhood cafe that served fresh beers from the brewery, a chatroom where you could request songs for the radiostation to play and a dark room which required a special permission, requested from the Blue Kremlin.

Bank

The bank allowed the creation of accounts for every registered civilian and also interfaced with the Blue Kremlin for checking that that civilian was indeed permitted to do so. Civilizans could make payments and transfer funds to each other and get an overview of their transactions.

Visually, the bank website had every feature frontend developers have nightmares of, like a bouncing logo with a lensflare, animations and misaligned boxes.

AirDnD

The AirDnD service did not offer a way to rent rooms for guests of Ludwighafen. Instead, it offered cheap uncomfortable dungeons to sleep in, some even featuring a dragon.

There was also the possibility for citizens to put up and rent out their own dungeons to visitors of the city.

Brewery

The brewery was a neat gamified service for brewing bear. You could pick ingredients, set the temperature and choose a fermentation method to end up with unique beers.

These beers then went up for sale and became available in the Ludwighafen community hall.

Radiostation

Unfortunately, the radiostation service frontend was not caught on camera, as this was one team that had decided to focus entirely on local development first and ended up not being able to deploy it in time.

The radiostation could play songs from Spotify, as requested in the radiostation chat, or via the community hall. Between songs, AI-rendered commercial audiotracks spoke highly of Ludwighafen, its king and the available services.

PortHub

The PortHub was the harbour and shipyard of Ludwighafen. Nothing but a means of uploading videos sharing the wholesome appreciation for hard labour and beautiful ships.

Powerplant

The idea behind the powerplant was that it kept an eye on the amount of services in the Ludwighafen cluster and calculated an amount of power needed to run those. If the power demand was too high, it would raise a loud alarm and eventually kill off a random pod. To increase the power, a small game was introduced reminiscent of the dinosaur jumping over cactuses in FireFox, but it instead had a knight jumping over beer barrels, each jump counting towards added power to run the city.

Actually killing off pods is something we implored the team to not implement, for reasons mentioned above.

Palace of Soestdijk

As the hackathon participants hacked, they became thirsty. Every time they ordered drinks, they’d tell the bartender at the hostel a little more about their ideas and efforts. Eventually the bartender, a proud inhabitant of Soest, requested Ludwighafen to feature the Palace of Soestdijk. We were happy to oblige.

Arcade hall

At the end of the presentations of the participants of the fullstackathon, the royal council showed that it had also secretly built an arcadehall with a powerful feature. Now that the work was complete and people were about to head home, we felt it was the right time to show we had planned some chaos engineering.

The arcade hall allowed you to play Doom. But it was a special version in which level 1 spawned demons that represented all the pods running in the Ludwighafen kubernetes cluster. Any demon shot meant a pod killed. As we demonstrated it and the buildings in the Ludwighafen city map caught fire, it was a testament to the fact that autohealing indeed did work and buildings would go back to being 200 OK.

That is, until we shot a demon that was some crucial pod of the kubernetes management plane itself, and everything grinded to a halt.

A fitting end of a successful fullstackathon.

Tech Stack

As said, the King wanted diversity. Here is a list of technologies employed during the 24 hours in which we built Ludwighafen in all its glory.

Platform

STACKIT cloud
Kubernetes
Docker
k9s
Kustomize
Envoy
Nginx

IDE

JetBrains IntelliJ
Cursor
VSCode

Backend

Kotlin
Java
Spring Boot
Thymeleaf
Rust
Python

Frontend

HTML
CSS
JavaScript
TypeScript
Vue
HTMX
Angular
React

AI

Big Pickle
Kiro
Google Gemini
Proton Lumo
Claude Sonnet
OpenCode

Forge

Codeberg
GitHub
BitBucket

The cost

From the start of March, when we set up the STACKIT account, created the fullstackathon project and the container registry and activated the kubernetes engine, through the hackathon itself on the last weekend of March when we created accounts, uploaded application images and pulled in npm and maven dependencies and started all those applications, and generated STACKIT AI-tokens, we burned approximately 250 euros.

Every day afterwards that we kept the entire cluster running we spent another 25 euros.

STACKIT offers hibernation, which means servers running in the kubernetes cluster are turned off, but the cluster itself remains operational along with its persistent volumes and container registry. This reduced the cost to 15 euros a day and allowed us quickly getting everything back up and running in case we wanted to show off Ludwighafen or iterate some more on it.

The aftermath

In the weeks following the fullstackathon, several people were still inspired and continued adding features. The royal municipal records was upgraded with a true Big Brother gridview of the city, showing the location of every logged in citizen. The bank, built in HTMX, received some additional features.

It turns out the concept of Ludwighafen, a place running in the familiar kubernetes but on a totally new cloud, where the sky is the limit as far as technical choices go, was an inspiration for exploring and trying out new technology.

At the time of writing, Ludwighafen has been torn down completely, ready to be reconstructed on a different cloud or on-prem.

Reference list

Nushell Niceties: Sorting Version Values With Semver Ordering

2026-04-21T04:55:55.000Z

The semver Nushell plugin can be used to work with string values as semver type as you can see in a previous post. You can use the semver sort command to sort string values with ordering rules for semantic versions. With natural ordering of string values a value of 10.0.1 is placed before 2.1.0, but if you use semver sort the ordering will be correct. The command will look at all the parts of the semver type. So a major version of 2 is placed before 10. If the major version part is the same than the minor part is used for ordering and so on. To sort in descending order you can use the option --reverse or the short option -r.

In the following example a list of version values is sorted with the semver sort command:

use std/assert

# After installing the nu_plugin_semver plugin and
# adding it to the plugin registry you can use
# the plugin for Nushell code.
plugin use semver

# `semver sort` uses correct ordering for version values.
(assert equal
        (['10.0.2' '2.3.1' '1.10.1' '2.3.1-beta.3' '2.3.1-alpha.1'] | semver sort)
        ['1.10.1'
         '2.3.1-alpha.1'
         '2.3.1-beta.3'
         '2.3.1'
         '10.0.2'])

# Without `semver sort` the natural ordering is used, but that is not correct
# for version values. E.g. 10.0.2 is before 2.3.1.
(assert equal
        (['10.0.2' '2.3.1' '1.10.1' '2.3.1-beta.3' '2.3.1-alpha.1'] | sort)
        ['1.10.1'
         '10.0.2'
         '2.3.1'
         '2.3.1-alpha.1'
         '2.3.1-beta.3'])


# Using the option `--reverse` (shorthand `-r`) to reverse the sorting order.
(assert equal
        (['10.0.2' '2.3.1' '1.10.1' '2.3.1-beta.3' '2.3.1-alpha.1'] | semver sort --reverse)
        ['10.0.2'
         '2.3.1'
         '2.3.1-beta.3'
         '2.3.1-alpha.1'
         '1.10.1'])

Written with Nushell 0.111.0.

Original post

Lazygit

2026-04-17T04:30:00.000Z

Arguably the most popular version control system is Git. Many developers use the command-line version alongside a Git plugin in their favorite IDE. Now those work just fine, but did you know there is also a very nice TUI (Text-based User Interface, alternately Terminal User Interface) for Git called Lazygit. It is a very cool tool. Read on for more information.

How to Start and Install

After installation it starts really fast, just type lazygit in the your terminal in your project directory and you get something like this:

Figure 1. Lazygit Screenshot

Usage

As you can see it gives a very nice overview of your Git workflow and repository status. And as with any TUI navigating and executing commands can be done extremely quickly and easily using your keyboard only (see keybindings). The keybindings can also be popped up with the '?' key. On top of that Lazygit also responds to your mouse.

Figure 2. Lazygit Keybindings

Conclusion

All in all, it is a very handy tool and a great addition to Git on the command-line and your IDE Git plugin.

PKI in a Nutshell

2026-04-14T05:30:00.000Z

This blog briefly describes theoretically how Public Key Infrastructure (PKI) works. It also introduces the key concepts used in PKI. This is done by describing encryption, decryption, hashing, signing, and authentication using mathematical notations.

PKI in a Nutshell

Intro

Given an asymmetric encryption algorithm E and accompanying Decryption algorithm D. It uses a key pair (K_e, K_d) to encrypt a plain text message x into a cipher text y.

encryption: E(K_e, x) = y
decyption: D(K_d, y) = x

Alice and Bob

Suppose Alice and Bob want to exchange encrypted messages with each other, and they also want to sign the messages so that they can be sure the messages they receive are from each other indeed, and not from some malignant third party.

Alice owns two key pairs.

keyPairA1 ={K_A1e, K_A1d}
keyPairA2 = {K_A2e, K_A2d}

Alice publishes the keys K_A1e and K_A2d.

Bob thas two key pairs as well:

keyPairB1 = {K_B1e, K_B1d}
keyPairB2 = {K_B2e, K_B2d}

And he publishes K_B1e and K_B2d.

The keys that are published are called public keys, the ones you keep for yourself are called private keys.

Key pairs are kept in a keystore. Trusted public keys, or the certificates thereof (see below), are kept in a truststore.

Encryption

Bob can now send an encrypted message to Alice using her public encryption key K_A1e with

E(K_A1e, x) = y

Which can only be decrypted by Alice with her private decryption key K_A1d

D(K_A1d, y) = x

And vice versa Alice can send encrypted message to Bob using the public key K_B1e from Bob.

Signing

Bob can use his private signing key K_B2e to sign his encrypted messages.

Given a hashing algorithm H

h = H(y) = hash of y

Next define

s = S(y) = E(K_B2e, H(y)) = signature

Bob sends (y, s) to Alice.

Now Alice can verify the cipher text y is from Bob by applying the verify operation V using Bob’s public verification key K_B2d

V(s) = D(K_B2d, s) = h

And she can also calculate h herself from the received y. Both hashes must be equal. Since only the owner of K_B2e could have sent the signature s encrypted in this way she knows this message is from Bob.

NB The same is true if Bob had signed the plain text x instead of the cipher text y. The choice is somewhat arbitrary. Albeit, that signing the cipher text y is a bit safer. Because when signing x and Alice’s private key has somehow been acquired by a malignant third party Mallory, Mallory can decrypt y and reencrypt it with his own private key and reuse the signature. When y is signed, he cannot reuse the signature.

Vice versa Alice can sign her message to Bob using her signing key K_A2e.

Certificates

What if Alice and Bob have no secure channel to exchange their public keys? Well suppose they do both have a secure channel with a third party CA (Certification Authority) whom they trust, which means they trust the CA’s public verification key K_CAd. They offer their public keys to CA to have them signed.

For example Alice offers her public encryption key to be signed by CA

S_CA(K_A1e) = E(K_CAe, H(K_A1e)) = s_A1e

And Alice publishes

c_A1e = {K_A1e, S_CA(K_A1e)} = {K_A1e, s_A1e} = certificate of K_A1e signed by CA

Bob can now verify the key is from Alice by calculating

V_CA(s_A1e) = D(K_CAd, s_A1e) = h_v

and

H(K_A1e) = h

The following should be true: h_v = h

The same can be done for the other public keys of Alice and Bob. So by publishing certificates of their public keys instead of the keys alone they can safely exchange messages without having a secure channel to exchange their public keys directly.

For convenience CA does not publish its verification key alone, but a self-signed certificate of it

c_CAd = {K_CAd, S_CA(K_CAd)}

Chain of Trust

Above is an example of a chain of trust. Alice and Bob trust CA. This a chain of length 2. Longer chains are more common. For example when Alice and Bob use a certificate from CA₂, which is signed by CA₁, which is signed by a self-signed certificate of CA₀=CA_root. They both trust CA₀, and Alice has her keys signed by CA₂. For example the chain for her public encryption key:

c_A1e = {K_A1e, s_A1e} = {K_A1e, S_CA2(K_A1e)}

c_CA2d = {K_CA2d, s_CA2d} = {K_CA2d, S_CA1(K_CA2d)}

c_CA1d = {K_CA1d, s_CA1d} = {K_CA1d, S_CA0(K_CA1d)}

c_CA0d = {K_CA0d, s_CA0d} = {K_CA0d, S_CA0(K_CA0d)}

So Bob trusts the public encryption key of Alice, K_A1e, because it is signed by CA₂, which is signed by CA₁, which is signed by CA₀, which he trusts.

It is common practice to send the entire chain upon publishing/sending of one’s certificate. So usually one keeps the entire chain for each certificate in one’s keystore. Since the public key is part of the certificate a keystore usually contains entries with in it a private key and the associated certificate chain.

The certificates one trusts are kept a so called truststore. The sender’s chain of certificates must end at a certificate in one’s truststore.

Nushell Niceties: Bumping Semantic Version

2026-04-14T04:52:23.000Z

In a previous blogpost you can learn about the semver command in Nushell to transform a string value into a semver type. With the semver bump command you can increase one of the components of the semver type. For example to increase the major version part you can use semver bump major. This command will also update the minor and patch parts if needed. The result is a semver type and you can use into value to transform it to a string type.

In the following example several of the semver bump commands are used:

use std/assert

# After installing the nu_plugin_semver plugin and
# adding it to the plugin registry you can use
# the plugin for Nushell code.
plugin use semver

# Transform string to semver value.
let version = '4.0.2'

# Bumping major part of version by adding 1 to the current value.
assert equal ($version | semver bump major | into value) '5.0.0'

# Bumping minor part by adding 1 to the value.
# The option `--ignore-errors` makes sure when an error occurs the
# original input value is returned. The shorthand `-i` is also valid.
assert equal ($version | semver bump minor --ignore-errors | into value) '4.1.0'

# Bumping patch part by adding 1 to the value.
assert equal ($version | semver bump patch | into value) '4.0.3'

# Bumping to a release candidate version, patch is unchanged.
assert equal ($version | semver bump rc | into value) '4.0.2-rc.1'

# Bumping to a next alpha version by adding 1 to patch value and
# pre-release part `alpha.1`.
assert equal ($version | semver bump alpha | into value) '4.0.3-alpha.1'

# Bumping to a next beta version by adding 1 to patch value and
# pre-release part `beta.1`.
assert equal ($version | semver bump beta | into value) '4.0.3-beta.1'

# Using `bump release` will remove the pre (release) part of semver value.
assert equal ('4.0.3-rc.1' | semver bump release | into value) '4.0.3'


# The same bump commands can be used for a semver type input.
let full_version = '4.0.2-rc.1+build-20260205' | into semver

assert equal ($full_version | semver bump major | into value) '5.0.0'
assert equal ($full_version | semver bump minor | into value) '4.1.0'
assert equal ($full_version | semver bump patch | into value) '4.0.2+build-20260205'
assert equal ($full_version | semver bump rc | into value) '4.0.2-rc.2+build-20260205'
assert equal ($full_version | semver bump release | into value) '4.0.2+build-20260205'


# The `semver bump` command support the `--build-metadata` (or shorthand `-b`)
# option to add build metadata to a semver or string value.
(assert equal
        ('4.2.8' | semver bump minor --build-metadata 'build-20260205' | into value)
        '4.3.0+build-20260205')

Written with Nushell 0.111.0.

Original post

Nushell Niceties: Transform Values Into Semver Types

2026-04-07T04:45:40.000Z

Nushell can be extended with plugins to have more functionality or types that are not part of standard Nushell. If you want to work with string values that are actually semantic version values (https://semver.org) you can use the Nushell SemVer plugin. The plugin must be added to Nushell by using the command plugin add <location of plugin>. You can check with plugin list command if the plugin is available. This command also shows commands that the plugin adds to Nushell.

The command into semver can be used to convert string values into a semver type. The semver type has 5 properties: major, minor, patch, pre and build. You can use dot notation to get the values for these properties or use the get command. In the following command a string value is transformed to a semver type: let v = '4.0.2' | into semver. And with $v.major you can extract the major part of the semver value and it returns 4.
Records with the keys major, minor, patch, pre and build can be transformed to a semver string with the semver from-record command. And to transform a semver type to a record you can use the command semver into-record.

In the following example different string values are transformed and from a semver type or record:

use std/assert

# After installing the nu_plugin_semver plugin and
# adding it to the plugin registry you can use
# the plugin for Nushell code.
plugin use semver

# With `into semver` you can transform a string
# into a semver value with the fields
# major, minor, patch, pre and build.
let version = '4.0.2' | into semver

assert equal $version.major 4
assert equal $version.minor 0
assert equal $version.patch 2
assert equal ($version | get patch) 2

# Type is semver and no longer a string type.
assert equal ($version | describe) semver

# A full version with all parts.
# The pre (release) part is after the patch and - up until the +.
# The build part is everything after the +.
let full_version = '4.0.2-rc.1+build-20260205' | into semver

assert equal $full_version.major 4
assert equal $full_version.minor 0
assert equal $full_version.patch 2
assert equal $full_version.pre 'rc.1'
assert equal $full_version.build 'build-20260205'

# A version with major, minor, patch and build part.
let build_version = '4.0.2+build-20260205' | into semver

assert equal $build_version.build 'build-20260205'
assert equal $build_version.major 4
assert equal $build_version.minor 0
assert equal $build_version.patch 2


# Using `semver to-record` to transform a semver value or string
# to a record with the keys major, minor, patch, pre and build.
assert equal ($version | semver to-record) {
    major: 4 minor: 0 patch: 2 pre: '' build: ''
}
assert equal ('1.2.3' | semver to-record) {
    major: 1 minor: 2 patch: 3 pre: '' build: ''
}
assert equal ('4.0.2-rc.1+build-20260205' | semver to-record) {
    major: 4 minor: 0 patch: 2 pre: 'rc.1' build: 'build-20260205'
}

# Using `semver from-record` to transform a record with keys
# major, minor, patch, pre and build to a semver value.
(assert equal
        ({major: 4 minor: 0 patch: 2 pre: '' build: ''} | semver from-record)
        '4.0.2')
(assert equal
        ({major: 4 minor: 0 patch: 2 pre: 'rc.1' build: 'build-20260205'} | semver from-record)
        '4.0.2-rc.1+build-20260205')


# A list of string value can be transformed to a list of semver values.
(assert equal (['4.0.2-rc.1+build-20260205' '1.2.3'] | into semver)
    [('4.0.2-rc.1+build-20260205' | into semver) ('1.2.3' | into semver)])

Written with Nushell 0.110.0.

Original post

JDriven Blog

Just one more prompt

The loop that never closes

Why it feels so good

Spelunking, Considering, Scampering

From flow to flat

What running taught me

So what can you do?

To sum it up

Building a local AI storyteller - what I learned when prompts were not enough

The first mistake: treating prompts as rules

A system prompt is not a rule engine

The missing magic setting

What the model is actually doing

Models tend to normalize unusual situations

The software engineering solution: validation

Memory is not the same as chat history

One model, multiple roles

Local models are already useful

Things I did not learn

The main takeaway

The current result

Optional technical notes on model choice

Sources

Selfware, software that fits you instead of the world

One word, and it clicked

The fit was never right

What selfware actually means

An old dream, finally affordable

The wall just came down.

What this does to the software lifecycle

The SaaS reckoning

How to think about it, without kidding yourself

Make it happen

Contemplations

Kotlin Kandy: Get Text Before Or After A Delimiter

Kotlin Kandy: Get A Random Element From A Collection

Event System: Breaking Down the Basics

IYKYK

Understanding requires insight. Insight must be anchored.

Kotlin Kandy: Transform Map Keys Or Values With mapKeys And mapValues

Nushell Niceties: Wrapping External Commands With def --wrapped

AI's Impact on Team Dynamics (Part 3) Collaboration & Healthy AI Use

Maintaining psychological safety in the AI era

Collaboration

Strategies for healthy AI integration

The future of team dynamics

Conclusion

AI's Impact on Team Dynamics (Part 2) Learning, Speed & Trade-offs

The knowledge transfer crisis

But it’s not all negative

The speed versus depth trade-off

AI's Impact on Team Dynamics (Part 1) Isolation & Echo Chambers

AI’s impact on Team Dynamics

The isolation paradox

The echo chamber effect

Nushell Niceties: Check Semantic Version Is A Match

Considerations on cognitive load and organisational structure in sociotechnical systems.

Cognitive load theory

Organisational structure

Group size

Cohesion

Rule of thumb for sizing of solutions

Organisational structures as defined by various agile frameworks

Background info on the various agile frameworks

Scrum [14]

Scrum of Scrums [15]

Metascrum [16]

SAFe [17]

LeSS [18]

Disciplined Agile Delivery [19]

Nexus [20]

Scrum@Scale [21]

Crystal [22]

Spotify Model [23]

Building a fullstack digital city in kubernetes hosted on an EU cloud

The Conflux fullstackathon recipe

The theme for 2026

The setup

The basics: kubernetes and the means to use it

Scrum ^[14]

Scrum of Scrums ^[15]

Metascrum ^[16]

SAFe ^[17]

LeSS ^[18]

Disciplined Agile Delivery ^[19]

Nexus ^[20]

Scrum@Scale ^[21]

Crystal ^[22]

Spotify Model ^[23]