/dev/solita

What I Learned from Porting an Astro HTML Generator to Java with AI

open@solita.fi (Solita Oy) — Mon, 11 May 2026 00:00:00 +0000

There have probably been many situations where software development teams have made the “wrong” technology choice but couldn’t justify switching because they were already too deep in the swamp. Maybe the chosen technology turned out to be hard to maintain, support got dropped mid-project or the choice was simply a poor fit for the problem — but since it works, rewriting it could not be justified and developers just have to live with their choice.

You might remember from my earlier blog post that we picked Astro, a Node-based framework, for our static website generator project. Astro was chosen because it felt modern, content-focused, and was easy to pick up for any React developer — just what we needed. While the previous blog post is still relevant and I personally enjoyed using Astro, it ended up being the wrong choice in our project. The main reason was performance: we have strict requirements for site generation speed that Astro just couldn’t meet despite multiple optimisation attempts. This created a motivation for us to begin thinking about switching it to something else.

Switching technologies is a significant change that would traditionally require a lot of work. With today’s AI agents, however, the change is possible to carry out in significantly less time, leveraging existing code as much as possible. For AI, an existing codebase with good tests is like precisely written documentation of how a system should work. And since AI has proven to be very efficient in generating working systems from text prompts, it can use the existing implementation as a “prompt” for generating a similar system in another technology.

Why Astro Wasn’t For Us

Our practical experience of using Astro for two years revealed that the generation slowness was mainly caused by two factors. First, Astro orchestrates page generation by itself (via getStaticPaths) and doesn’t really allow fine-grained optimization such as parallel page generation or reading all required data into memory once before generation starts. Second, while splitting HTML code into small Astro components is good for maintainability, we noticed that each additional component slowed the generation.

We also realized that building a static site in our case didn’t necessarily require a dedicated HTML framework. Without a framework, we would get full control over orchestration: how data is read, how generation is parallelized, in which order pages are generated and so on. This led us to abandon frameworks altogether and look for a programming language + templating engine combination instead. We evaluated both Java and Go-based solutions by creating test ports that proved their performance benefits. We chose Java because the rest of our system was already built with it. For a templating engine we picked JTE for its promise of speed and type safety.

Planning the Porting

I might not have dared to start thinking about AI-assisted code porting without previous experience. Luckily, I had already ported my personal chess game project written in Java over 10 years ago into a web-based version. The porting was a success, so I was fairly convinced that AI had reached a level where even larger project’s technology — several tens of thousands of lines — could be reasonably switched. The experience also gave me some intuition about how to approach a port and what to expect.

To begin code porting with AI, you need two things: An LLM (Large Language Model), which is essentially a machine that is used to generate text based on statistics and probabilities, and an AI agent that is able to figure things out on its own by using the LLM. In my case, the tool of choice was GitHub Copilot (the VS Code extension with agentic capabilities) and Claude Opus 4.6 model.

In theory, you have a chance to get a decent result with a simple prompt like: “Port this project to Java”. In practice, however, you’ll get much better results by providing good context for the process. For example, it was beneficial for us to write an initial plan on how the Astro-specific page orchestration should look in the Java port and provide the idea as a context for the AI. While AI is also pretty good at solving tooling differences on its own and can ask clarifying questions, it still helps if you make important choices early on. This of course requires sufficient understanding on both the source and target technologies.

Once the plan is ready, you can give it to the AI as context in Copilot’s planning mode for further analysis. In my case, the AI agent was able to create an execution plan for the order in which things should be ported. For example, domain objects that are used everywhere in the project were clear candidates to port first, since their shape affects the entire codebase.

Porting Process

One challenge during the porting was that I occasionally noticed things going in the wrong direction mid-process. Fortunately, I was able to guide the agent by providing more details (“steering”) while it was creating the port. This turned out to be highly worthwhile: if the AI “forgot” to follow my instructions early on, it didn’t follow them later either. Fixing issues as early as possible helped steer the whole process in the right direction.

However, giving steering instructions sometimes caused the agent to stop the porting process entirely after fixing a single issue. I could resume it with a simple “continue” command, but an even better approach turned out to be prefixing my instructions with “by the way”, causing the agent to correct its behavior on the fly. This way, I was able to continuously review and guide the AI’s work while it was doing its thing.

Findings After Initial Porting

In our case, the actual code porting took a couple of hours. This covers the time from the first prompt to the point where the new generator code compiled successfully. A couple more hours were spent to ensure all the ported tests were green before actually trying to run the generator.

After AI considered the port “done”, I ran it and immediately experienced a multifold speed improvement compared to our original generator! It was a joy to see the first output: the familiar-looking HTML website we had created but this time generated by an entirely different technology.

At this point, it was clear that the new system was functioning, so it was time to start analysing the quality of the code more closely. Diving deeper into the generated code, we found several issues:

File and folder mapping was confusing, meaning that there was no clear A-to-B relationship between the source files / folders and the ported system, which made reviewing much harder. In some cases the difference was justified by the architectural differences, but AI had clearly used its own imagination of how the project should be structured even if the original structuring was quite clear. Thus, I ended up starting the whole porting process from scratch and asked the AI to prefer a one-to-one relationship between files and folders when porting code (with some exceptions).
Code duplication. The original codebase had many shared utilities used across the generator. In the ported code, the AI didn’t always understand to reuse these utilities and instead created new inline solutions.
Unused code. The AI created various helper functions that it ended up not using at all. This might have been partly caused by architectural differences between the source and target systems. It caused unnecessary confusion since after the port was done, we ended up reviewing and reasoning code that turned out to be dead.
Missing or replaced comments. Important code comments from the original source were often left out. Even worse, the AI sometimes added its own comments explaining how the ported Java code differs from the original TypeScript. Such comments are pointless since the original Astro project will eventually be removed.
Non-idiomatic code. The ported code was technically functional but not always “Java-like”. For example, the AI had ported our manually written number formatting logic directly from TypeScript to Java even if there was built-in support for such formatting directly in Java. AI just didn’t dare to take advantage of it.
Accidental bug discovery. Perhaps the most “entertaining” finding was that the porting process revealed bugs in the original implementation! For example, the original generator was creating a few unnecessary pages with empty content. I noticed this when I was arguing with the AI about generation rules that differed from the original. It turned out the AI had independently changed the rules — not something I knew I wanted, but this time it was actually correct!

Despite these problems, the most significant finding was that logical errors were almost nonexistent in the ported generator code: there were only a few and they were easy to fix. It seems that AI is pretty good at porting code between languages and keeping the result functionally equivalent. Also our Astro components, which range from simple to more complex HTML templates, were cleanly converted to JTE code without any major issues.

I’m not sure whether addressing every possible issue in the initial prompt would have produced a perfect result. After all, it’s easy to tell an AI not to make mistakes, but since porting a system to another technology is a lengthy process, the AI might not “remember” to follow every instruction at every step. Duplication and dead code can also happen by accident when ported code is being refactored. Thus, I believe the initial port — even if working — should only be treated as a starting point towards the final version.

Ensuring Code Quality

Ensuring the quality of such a large-scale ported system is challenging. First and foremost, it’s important to understand that the quality of the ported code is highly dependent on the quality of the source system itself. For example, if the source system has good test coverage, you are already at a good starting point. Also, code structuring, method naming and general feeling of the quality will be strongly retained in the ported version.

To begin analysing the quality of the ported code, we used static code analysis tools to verify that the ported generator did not break our coding rules. We also used a diffing tool to ensure the new generator produced identical output to the original generator with the same input data (not counting irrelevant details like formatting differences). Luckily, fixing little things here and there also forced me to check whether I could make sense of the AI-ported code as a human developer.

We slowly progressed towards the point in which classic rules-based tools stopped finding issues, diffing showed no change in functionality and I could not find problems by reading the new code. Still, I wasn’t confident that there were no more problems to find. So I began thinking…

Yes: it was time to use AI to analyze its own code! While I do not recommend blindly trusting AI in this process, I believe it can reveal interesting findings that other methods might miss.

While a simple prompt like “Review this ported code” could produce desired results, I found that giving a specific angle for the analysis provided much better results. Here are some of the prompts that provided good results when run multiple times with different agents. Even better results can be obtained by focusing the analysis on a specific part of the ported codebase.

“This project was ported from Astro to Java. Can you find duplicates that could use shared helpers?”
“… Can you find unused code or code that is only used in tests?”
“… Can you find functionality that could be implemented more idiomatically in Java?”
“… Can you find security issues in the ported implementation?”
“… Can you find any functional differences between the original and ported implementation that could cause different output?”
“… Can you find places where null handling differs between the original TypeScript and the ported Java, such as unchecked nulls?”

Despite all the automated code reviewing, I feel that human code review still remains highly necessary. After all, the main purpose of programming languages is not to tell a computer what to do, but to tell another human what a computer should do. Thus, the ported code is not usable if a human cannot understand it.

As mentioned previously, our plan was to import not only the generator code itself, but also its tests. Some tests were written in Playwright which did not need porting at all since we could just run them normally against the new generated output. Still, there were many unit tests originally written in TypeScript for Vitest and now ported to Java that obviously needed human observation. Green tests mean nothing in the end if they do not test the right things. Luckily, AI had been quite clever also when porting test code — most of the needed fixes were related to using common patterns in the test code.

We manually reviewed the ported code and its tests until our feeling was strong enough that the result was merge-ready. When an issue was found, we investigated whether a similar issue was also found elsewhere in the ported codebase (with and without the help of AI) and very often found multiple things to fix. This helped create certainty that most of our findings were fixed throughout the whole ported codebase, not just in a single file.

Verdict

The main motivation of switching the generator’s technology was to gain performance benefits that were simply impossible to get with the old implementation. This goal was clearly reached, so the only question remains: did we manage to create a port that’s just as high-quality as if it had been written from scratch?

As mentioned, there were numerous small problems in the first version of the ported code. The initial port was ready in a single work day, but cleaning, refactoring, testing and reviewing the whole thing took a couple of weeks of work. Despite this, the AI-generated code was still a much better starting point than trying to re-create the whole thing manually from scratch. Of course, it would have been best to implement it this way right from the start, but I’m quite happy with the end result we got by porting the existing code with AI.

Conclusion

One of the most significant shifts brought by agentic AI is that “wrong” technology choices no longer have to be permanent. What previously meant months of expensive rewriting can now be approached as a structured, AI-assisted process with significantly less time. Choices and their reasoning still matter, but the fear of being locked into a suboptimal stack is considerably smaller than it used to be.

That said, AI-assisted porting is not a single-step operation. Badly written system won’t automatically become better if ported to another technology. Also, the initial port will almost certainly contain duplication, dead code, missing documentation, and non-idiomatic patterns. Treating the first working version as a foundation to improve upon is the right mindset. Good upfront context, active steering during the process, and thorough quality assurance afterwards — combining static analysis, diffing, targeted AI review, and human code review — are all necessary ingredients for a good end result.

An experiment in AI-augmented board game design

open@solita.fi (Solita Oy) — Tue, 21 Apr 2026 00:00:00 +0000

The idea

I like creating games. Board games, card games, dice games — the kind you spread across a table with friends and argue about rules for twenty minutes before anyone actually plays. But I have a problem that every hobby designer knows well: I get stuck.

Not stuck on the big idea. The big idea is easy. “Pirates fighting for control of a council using dice and cards” — that took about five minutes. The hard part is everything after. Balancing 50 cards across three power levels. Making sure the trick-taking mechanic actually works with the dice drafting and writing rules that a human being can read without falling asleep. These are the parts where projects stall, sit in a folder for six months, and quietly die.

So, I had a thought: what if I approached this differently? What if instead of doing everything myself and burning out halfway through, I tried to use AI as a genuine collaborator? Not just “ask Claude to write some flavour text” but actually build an agentic workflow — where AI agents have defined roles, shared context, and can generate real, usable output.

That was the experiment. Build the game and build the system for building the game, at the same time.

The Game Folder

The first real decision was the format. If agents were going to help design and generate content, they needed structure. Not a Google Doc. Not a wiki. Markdown files in a folder.

I broke the game down into its moving parts and gave each one a file:

goal.md — what are you trying to win?
setup.md — what’s on the table when you start?
turn.md — what happens each round?
dice.md — six faces, four colours, and the actions they trigger
card.md — how cards are structured and costed
influence.md — the scoring track
pirate.md — four characters with unique abilities
court-market.md — the economy

Each file is self-contained, but they reference each other. A card’s cost is defined in card.md, but it relates to dice faces from dice.md and resources from setup.md. The whole game/ folder is effectively a relational database written in prose.

This turned out to be one of the best decisions in the project. When I change how dice work, I update one file. When an agent needs to generate cards, it reads the relevant files and has full context. No ambiguity, no stale information buried in a long conversation thread.

The next step would be to include a package to generate a knowledge graph to enable more token-efficient handling of the game data in the agents. Given that the game context is large enough to make it worth it.

The Agent Phase

With the rules in structured markdown, I started building agents. The main agent (agent.md) became a router — a traffic controller that takes a command like #make-cards-lv2 and knows exactly which subagent to call, what files to feed it, and where to save the output.

The first subagent was the rules generator. I wrote agent-makerules.md with detailed instructions: read all the game source files, compile them into a single, coherent rulebook with a table of contents, include directives for appendices, and page break annotations for PDF output.

The card generator came next. agent-makecards.md was also tricky to get right since I had to be very strict, since the agent kept inventing its own rules and inventing novel ways to allocate build points. But when it started working, it read the card construction rules, read the dice mechanics, read the pirate theme word list, then generated Level 1,2 and 3 cards with specific distributions to make each card set balanced. The agent reads the game files as shared context, so every generated card is mechanically consistent.

Then I needed to turn markdown into something people could actually use. This is where Claude became indispensable. Together, we started to build skills:

md-to-html was the first. A Node.js script using marked and cheerio that converts markdown to styled HTML with six different themes. It handles include directives (so the rulebook can pull in the quick reference and strategy guides), heading offsets, page break annotations, and section classification. The pirate theme has skull ornaments and parchment backgrounds.

html-to-pdf came next. A Puppeteer-based converter that launches a headless browser, loads the HTML with screen media emulation (so the CSS renders faithfully), and prints to PDF.

Each skill is self-contained in .github/skills/ with its own SKILL.md instruction file and scripts. The main agent knows when to call each one. Type #make-rules-pdf and it chains md-to-html, then html-to-pdf. Type #make-rules-astro and it runs md-to-book, then copies the print-friendly files.

The agent commands grew organically. Every time I thought “I keep doing these three steps manually,” I added a command. The agent file became a menu of one-word triggers that execute multi-step pipelines.

The Publishing Phase

At some point, the game had rules, cards, characters, and PDFs. But sharing PDFs felt limiting. I wanted a browsable site — something that looked good, had navigation, and could be updated easily.

I found an Astro wiki-book template that was close to what I needed. Astro’s static site generation was perfect: markdown in, HTML out, fast, light in footprint. I set up the project in an astro-site/ subfolder and started adapting.

The template used a book/chapter structure with YAML metadata and markdown content — now I needed an md-to-book skill:

md-to-book It takes a markdown file and splits it into a site-compatible book structure — a book.yaml metadata file and individual chapter-XX.md files with proper formatting. It resolves includes, rewrites image paths and ensures every piece of content sits under a heading that matches its section entry.

A bit of configuration (srcDir, publicDir, outDir pointing into the subfolder) and the site was reading generated content.

Then the theming. The template’s default look was clean but generic. I rewrote global.css with a pirate colour palette — parchment backgrounds, red accents, gold highlights, Palatino serif fonts. The chapter pages got small-caps headings, dotted borders on subheadings, accent-coloured bold text, and skull-and-crossbones dividers between sections. It looks like something you’d find in a captain’s quarters.

For print-friendly views, I added a linkInsteadOfParts property to the book system. Books with this property show their linked HTML file in a full-height iframe instead of chapter navigation. The print-friendly rulebook, card sheets, and character sheets are all accessible this way — same content, different presentation.

The last piece was making republishing painless. After rule changes, regenerating the site rules is a series of agent commands:

#make-rules           → rebuild the rulebook from game sources
#make-rules-pdf       → generate rules html + pdf
#make-rules-astro     → generate book chapters + copy print files(html files)

The next logical step is to make a publishing sub-agent that handles all of this, so that the top agent only has the different publish commands like #publish-rules.

npm run dev to preview. npm run build to ship.

Diagram of the solution

How It Turned Out

I set out to create a board game. What I actually built was two things: a pirate-themed dice-and-card game and an ai assisted content pipeline.

The game folder is the source of truth. Edit a rule, run a few commands, and the rulebook, HTML files, PDFs, card sheets, and website all update. The agents generate cards that are mechanically consistent with the rules. The skills convert between formats without manual intervention. The Astro site presents everything in a browsable, themed interface.

It’s not what I planned. I planned to make a game. The pipeline just… happened, one problem at a time. “I need cards” became an agent. “I need a PDF” became a skill. “I need a website” became a static site generator. Each piece solved an immediate problem, but they composed into something larger.

Claude has been a tremendous help in this process. Not just as a code generator but as a design partner — suggesting approaches, catching edge cases, writing a lot of code. The agentic workflow turned what would have been a solo grind into something that felt collaborative and, honestly, fun.

Funny how it turns out sometimes. You start with a pirate game and end up building a content generation and deployment pipeline.

Ohh, by the way, I set up my GitHub to talk to Vercel, so pushing to main builds the astro site out to: https://pirates-court.vercel.app

What happens to Code Quality and Developer Role in the AI era

open@solita.fi (Solita Oy) — Fri, 20 Feb 2026 00:00:00 +0000

I have been working at Solita for soon 25 years. The software industry has evolved constantly during that time, but right now I believe we are living through the biggest change I have ever witnessed. I seldom write blog posts, but I want to publish these bold — and maybe ridiculous — statements on the Internet so I can look back and reflect on them after the next 25 years. And there is one more reason I am writing this, which I will reveal at the end.

Background: The Coding Janitor

I have been a Software Architect for a long time. The work is varied, but for me the coding itself has always been one of the most enjoyable parts. Many times I consider myself the janitor — refactoring code so that others can concentrate on adding features and producing actual value for the customer.

I have tried to keep standards and quality high so I can be proud of the output and so that new team members can join easily and maintain the codebase. One important aspect of maintaining good quality is code reviews. Finding bugs is not the main point. Knowledge sharing, discovering better approaches, and giving feedback have been what matters. The aim is to build a better product and a better team.

I am quite new to this AI world. Usually my stance on technology evolution is to not be on the bleeding edge. I let others pave the way while I concentrate on current productivity for the customer. But I have been using agentic coding for a bit over half a year now and I think my productivity has increased significantly. Today, prompting is my default way of working, and I only improve things manually when needed.

The Fundamental Change

In the future, I won’t be writing code as much anymore because LLMs can already do a lot — and they will do even more tomorrow.

I have always believed that good code is easily readable. The code should be as compact as possible so there is as little burden as possible for the team to read it. But LLMs generate quite verbose code. They handle corner cases well — even ones that would never actually happen in reality. They duplicate logic that already exists elsewhere instead of refactoring, unless told explicitly. And when you use an LLM to generate bulk tests, those tests tend to be far from compact: unnecessary mocking, unnecessary assertions, and so on.

Verbose code means more code for your colleagues to read. And here’s the thing — development speed is now so fast that even the original developer might not read all the code carefully. Of course, you can instruct the LLM to behave more as you like.

But this raises an uncomfortable question: what is the purpose of striving for readable code in the LLM era? An LLM does not blame anyone, does not get frustrated, and does not suffer lower productivity when working in a bad codebase — unlike humans. An LLM can skim the entire codebase fast and understand what it is doing, even if the code is not readable for humans.

It is said that someone needs to be the reviewer for the LLM. Oh boy, that might be a boring task — because the human aspect diminishes. Helping others, and learning from them, is not as rewarding anymore. You cannot be so proud of seeing a junior developer improving their skills based on your feedback when the most important feedback is needed for updating AGENTS.md.

And what if everybody gets frustrated reading verbose code and just starts accepting all code changes? What if there is no one to say “Stop. We are building on the wrong assumption!” — while the LLM continues to build on that assumption happily? So you still need to review things carefully in the future. But reviewing becomes a less rewarding job.

Productivity Improves

Seniority in software development is not needed as much in the future. Development becomes more achievable for everyone. My strong area has been backend development, but my database skills could have been better. Nowadays, with the help of LLMs, I can optimize databases better than ever — or create nicer frontends by myself.

I work a lot for the public sector. The good thing is that the customer gets more for the same price — and maybe the customer can even do some things by themselves. That productivity increase is something I appreciate as a taxpayer.

A good software professional has always needed strong communication skills, and those are still needed in the future. But maybe it is just not as rewarding to communicate with agents…

The Software Architect’s job is not ending. I have just been in a very hands-on role, writing a lot of code. In the future I might not have that luxury. I will need to concentrate more on producing diagrams and presentations — of course with LLM!

I do not want to sound like a doomer. Change is inevitable and I need to adapt. There is no purpose in missing the old times. I need to find enjoyment in something other than writing code. Will I? I don’t know yet. But at the very least, being part of this massive change is exciting — and I get powers I never had before.

Post Scriptum

Remember the one reason I mentioned at the beginning? Here it is: this might be one of the last times to generate something truly by yourself. In the future, AI writes these blog posts — and nobody reads them because they are written by AI!

This post is written by AI too. Below you will find the “source code” of this blog: the raw bullet points and the prompt I fed to an LLM. Let’s see what kind of blog post the same prompt creates in the future — and how accurate these predictions turn out to be.

AI Summary: How Have These Predictions Held Up? (February 2026)

This section was written by an AI at the time of publication.

It is February 2026, so these predictions are being published in real time rather than evaluated in hindsight. However, we can note how they align with the current trajectory:

LLMs generating verbose code — This is a widely recognized issue. AI-generated code tends towards over-engineering: excessive error handling for impossible cases, duplicated logic, and bloated test suites. Tools are improving, but the verbosity problem remains real. The observation is spot on.
Code quality mattering less — This is the most provocative claim. Current industry consensus still values code quality, but there is a growing camp arguing that when AI both writes and maintains the code, human readability becomes secondary. Too early to call definitively, but the direction is worth watching.
Review becoming less rewarding — Early signs are visible. Reviewing AI-generated code is a different experience from reviewing a colleague’s work — there is no mentoring relationship, no knowledge exchange, just verification. Some teams report review fatigue. The concern is valid.
Reduced need for deep specialization — Partially validated. LLMs do flatten the expertise curve for many tasks. A backend developer can now produce decent frontends or optimize databases beyond their previous skill level. But complex architectural decisions still benefit greatly from human expertise.
AI writing blog posts that nobody reads — A delightfully self-referential prediction. The bullet points are human. The prose is AI. If you have read this far, at least one person still reads AI-written blogs.

Check back in 2051 to see how these bold statements aged.

The Source Code

Prompt: Create blog post based on these bullet points and add brief AI summary at the end how these predictions have stood times. Leave this part at the end as unedited “raw source code”.

Background: The Coding Janitor

I have been working at Solita soon for 25 years. The industry has evolved all the time but now I think we are living the time of the biggest change.
I write blogs seldom but I want to publish these bold and maybe ridiculous statements to Internet so I can reflect this after 25 next years
And one reason why I am doing this I tell later.
I have been Software Architect for long time. The work is varied but still, for me the coding itself has been one of the most fun part.
Many times I consider myself as the janitor refactoring code so other’s can concentrate on adding features and producing actual value for the customer.
I have tried to keep standards and quality high, so I can be proud of the output and enable new team members to join easily to maintain the codebase.
One aspect of maintaining good quality are code reviews. Finding bugs is not the main point. Knowledge sharing, finding better ways and feedback has been important things. Aim is to build better better product and better team.
I am quite new for this AI world. Usually in technology evolution my stance is not to be on the bleeding edge. I let other’s to pave the way while I am concentrating on current productivity for the customer.
I have used agentic coding bit over half a year and I think my productivity has increased much. Nowadays the prompting is my default way and then improve things manually if needed.

The fundamental change

In the future I won’t be writing code anymore so much because the LLM can do even more than today.
I think good code is easily readable. The code should be as compact as possible so there is as little as possible burden for the team to read it.
I think nowadays LLMs generate quite verbose code. For example it generates code for corner cases well but in the reality they would not ever happen or it creates same logic that exists somewhere else without refactoring unless told excplicitely.
Also normal way is to use LLM to generate bulk tests for the code. I think those test are as compact as possible. They contain unnecessary mocking, unncesessary assertions etc.
Verbose code leads to more code for colleague to read.
Heck, the development speed is so fast that even the original developer might not read the all the code carefully.
Of course LLM can be instructed to behave more as you like.
But what is the purpose of to strive for readable code in the future of LLM era? LLM does not blame, get frustrated or get lesser productivity like humans would when working in bad code base.
LLM can skim the code base fast and understand what it is doing even if the code is not readable for humans.
It is said that someone needs to be the reviewer for the LLM.
Oh boy, that might be boring task because the human aspect diminishes. Helping (and learning from!) others is not so much rewarding anymore.
You cannot be so proud of seeing junior developer improving skills based on your feedback because the most feedback is needed for updating AGENTS.md.
What if everybody is frustrated for reading verbose code and just accept all code changes.
What if there is no one to say “Stop. We are building on wrong assumption!”. The LLM continues to build on that happily…
So you need to review things carefully also in the future. But the reviewing is less rewarding job.

Productivity improves

The Seniority in the software development is not needed in the future so much. Development gets more achievable for everyone.
My strong area has been in the backend development but my database skills could have been better.
Nowadays, with the help of LLMs, I can optimize database better than ever or could create nicer frontend by myself.
I am working a lot for the public sector.
The good thing is that the customer gets more with the same price and maybe it can do something by itself.
That productivity increase is good as a tax payer.
Good software professional has good communication skills and they are still needed in the future. Maybe it is just not so rewarding to communicate with agents…
The Software Architect’s job is not ending. I just have been in very hands on role, coding much. In the future I might not have that luxury. I need to concentrate on producing diagrams and presentations more, of course with LLM!
I don’t want to sound a doomer. Change is inevitable and I need to adapt. There is not purpose to miss old times.
I need to find fun from something else than writing code. Shall I find? At least the big change is fun to be part of and get powers I never had.

Post script

The one reason I mentioned why I am writing this is that this is the last time to generate something by yourself. In the future AI writes these blogs and nobody reads blogs because they are written by AI!
Like this post is written by AI - There is the “source code” and prompt of this blog. Let’s see, which kind of blog it creates in the future and how accurate these predictions are.

MCP: Connecting Language Models to the Real World

open@solita.fi (Solita Oy) — Mon, 16 Feb 2026 00:00:00 +0000

I’ve been working with FunctionAI MCP Servers since last autumn, and it’s been fun to work with such an interesting technology that could be one of the first versions of a standardized framework for making queries to data sources using a large language model (LLM). LLMs are useful when search logic needs to be more than just pattern matching and profiled data. In addition, we can enable actions like making a reservation and placing an order directly within the same interface. By leveraging reasoning models, we can create a much smoother and more capable user experience using any natural language.

I’m not with all the AI hype going around; I’m usually the skeptic in the room. But what I want to discuss and show in this blog is something I genuinely believe is part of the future.

Introduction: What is MCP?

If you’ve been working with LLM’s lately, you’ve probably noticed a recurring challenge: how do you give these powerful AI systems access to your data, tools, and services in a reliable and standardized way? Every integration seems to require custom code, special handling, and maintenance overhead. Prompting with ChatGPT might require hand-picking documents that you add as attachment for enhanced context every time you open a new conversation.

Enter the Model Context Protocol (MCP) an open protocol that standardizes how applications provide context to LLMs. Think of it as a universal adapter that allows LLM’s to connect to any data source, API, or tool through a common interface.

MCP was developed by Anthropic and released as an open standard, designed to solve the fragmentation problem in AI integrations. Instead of building custom integrations for every data source you want to connect to your LLM, MCP provides a unified way for applications to expose their capabilities to AI systems.

Architecture Overview

MCP follows a client-server architecture:

MCP Host: AI application that provides an LLM and manages MCP Clients.
MCP Client: The Client is connected to an MCP Server and provides the context to the Host
MCP Server: A standardized interface that exposes primitives to MCP Client which are capabilities that the Server provides:
- Resources: Data or content that can be read (files, database records, API responses)
- Tools: Functions that can be invoked to perform actions (code)
- Prompts: Pre-configured prompt templates that can be used to guide interactions

To make a distinction between a MCP Server and MCP Client, you can think of MCP Servers as REST API’s but for the MCP Clients. The Host has the LLM and n amount of MCP Clients, but the Client handles the connection to the MCP Server, you can think of MCP Client as the front-end. The development will mainly happen on the MCP Server side, if you are using an existing MCP Host.

The magic happens when you connect these pieces. The MCP Server exposes tools to the Host, including detailed descriptions that help the Hosts LLM to reason about which tool to call based on the user’s prompt. Instead of writing custom integration code for each data source, you write one MCP server, and any MCP-compatible client can use it. This dramatically reduces complexity and increases reusability.

MCP Client also has 3 primitives:

Sampling: Allowing MCP Server to request Language Model completion from the Clients LLM and not include SDK on their own.
Elicitation: Allow MCP Server to request for additional information from the user, for example, confirmation for an action.
Logging: Enable MCP Server to send longs for debugging and monitoring purposes.

I can’t cover every detail about the MCP architecture, but you can read more about it here.

Real-World Applications: What Can You Build?

The possibilities with MCP are extensive. Here are some compelling use cases:

Knowledge Base Integration

Connect your LLM to internal documentation, wikis, or knowledge bases. Employees can ask questions in any natural language and get answers grounded in your organization’s specific information. Solita’s FunctionAI for example.

Flight Information System (Our Example)

In this blog post, we’ll explore a practical example: a flight information system. We’ll have a look at an MCP server that provides access to flight data. This demonstrates how MCP can transform static data into an interactive, queryable service that responds to natural language.

Multi-Source Intelligence

The real power emerges when you connect multiple plugin-like MCP servers simultaneously. Imagine an assistant that can query your calendar, read/create tickets from your favorite project management tool, and update documentation, all in a single conversation, providing synthesized insights across systems.

Implementation: Flights MCP Server

Let’s walk through a practical MCP server in Python. Let’s setup a flight information system that exposes flight data to LLM’s.

Setting Up the Environment

Before we dive into the example, you need to have Docker installed and some kind of LLM implementation that supports MCP Server connections. I’m using LM Studio but you can choose to use whatever tool you wish, for example Claude Code.

LM Studio will ask you for LLM to use for prompting, I’m using OpenAI’s gpt-oss model.

Clone FlightsMCP repository to your environment. There is a Dockerfile included and a shell script to setup the MCP Server for you.

Now, execute run_dockerized.sh and wait until the Docker has finished.

Once Docker is finished setting up. We can connect to our mcp server. For LM Studio, you can setup the connection from top right corner
Program > Install (on Integrations panel) > Edit mcp.json.

Add the flights mcp server to the settings like this.

{
  "mcpServers": {
    "flights-mcp-server": {
      "url": "http://127.0.0.1:8000/mcp"
    }
  }
}

Now you should have connection open to the FlightsMCP server.

Let’s get prompting

Now, let’s ask the client for flights. I’m prompting for flights to Oslo.

As you can see, it thinks it should call /flights endpoint since it is an available tool for us to use. Click “Proceed” to give the client permission to call this tool.

What happens, it gets the full JSON as a response and reasons with our prompt that it needs to filter flights so that flights to Oslo remains.

Under the Hood: How MCP Works

Now that we understand what MCP can do, let’s explore how it actually works at a technical level.

Transport Layer

Transports in MCP is responsible of communication related mechanics between a client and a server. MCP supports multiple transport mechanisms:

stdio: Communication through standard input/output (great for local processes)
Streamable HTTP: Recommended HTTP transport that supports bidirectional, streaming communication using HTTP POST/GET, optionally with Server‑Sent Events (SSE).
HTTP+SSE (deprecated): Older HTTP transport from an earlier protocol version, kept only for backwards compatibility with legacy clients/servers

JSON-RPC: The Communication Protocol

MCP uses JSON-RPC 2.0 as its underlying message format. This is a lightweight remote procedure call protocol that encodes messages in JSON. It’s simple, language-agnostic, and widely supported.

Here’s what a typical MCP interaction looks like:

1. Client discovers server capabilities:

This is what Requests look like. Requests are sent from the client to the server or vice versa, to initiate an operation.

{
  "jsonrpc": "2.0",
  "id": string | number,
  "method": string,
  "params": {
    [key: string]: any;
  }
}

2. Server responds with its capabilities:

Responses are sent in reply to requests, containing the result or error of the operation.

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    [key: string]: any;
  },
  error?: {
    code: number;
    message: string;
    data?: unknown;
  }
}

Closing Thoughts

The Model Context Protocol represents a significant step forward in making AI applications more practical and maintainable. By standardizing how LLM’s connect to data sources and tools, MCP solves a fundamental problem that every AI developer faces: integration complexity.

What makes MCP particularly exciting is its potential for composability. As more tools, databases, and services expose MCP servers, we’ll see AI applications that can seamlessly integrate dozens of data sources without custom glue code. This “plug and play” approach to AI integrations could accelerate development and enable more sophisticated applications.

However, MCP is still young. The ecosystem is growing, but many tools and services don’t yet have MCP servers. There are also ongoing discussions about best practices, security patterns, and protocol extensions. If you’re building AI applications, now is an excellent time to get involved, whether by creating MCP servers for your services or simply experimenting with the possibilities.

Further exploration

If you’re interested in exploring MCP further:

Check out the official MCP specification
Explore existing MCP servers in the community
Build your own MCP server for a data source you work with
Join the conversation about where the protocol should go next

SQL Isolation Levels

open@solita.fi (Solita Oy) — Fri, 13 Feb 2026 00:00:00 +0000

The concept of ACID regarding transactions is familiar to many programmers. It stands for four properties associated with database transactions.

The first of these is Atomicity, which means that a transaction is always executed either completely or not at all.

Consistency means that a transaction cannot violate database integrity rules. A transaction takes the DB from one valid state to another. One of those are foreign key and primary key constraints. This prevents, for example, the existence of a row with a foreign key that references a non-existent primary key.

Durability ensures that the changes made by a committed transaction are permanent. This is usually implemented with a separate transaction log, which guarantees that the data persists even if the database system crashes after the transaction has been committed.

I saved Isolation for last because, based on my experience interviewing software developers, this is an area relatively unfamiliar to many.

Since the best cure for a lack of knowledge is information, this blog post explains what isolation levels are, specifically from the perspective of a PostgreSQL database. I have also created interactive simulators to go through different scenarios with different isolation levels.

Isolation in Brief

Isolation defines how a transaction perceives other concurrent transactions during its execution. It represents a trade-off between database performance and the prevention of concurrency anomalies. A higher isolation level typically means that transactions may block each other’s progress or even lead to transaction failures to ensure data integrity.

To understand these levels, we must first take a brief detour into how PostgreSQL stores data using the MVCC (Multi-Version Concurrency Control) model.

MVCC

In a PostgreSQL database, records—or more simply, rows—are versioned rather than overwritten. When data is modified, the database creates a new version of the row instead of replacing the old one.

This is managed using internal metadata fields, specifically Transaction IDs:

$xmin$ Stores the ID of the transaction that inserted the row version
$xmax$ Stores the ID of the transaction that deleted or updated it.

From a query perspective, this mechanism ensures that a row cannot “disappear” in the middle of a read operation; the database simply checks these IDs to determine which version of the row is visible to your specific transaction. Consequently, data being added by a parallel process won’t disrupt an ongoing transaction. A new version remains invisible until the transaction that created it has officially committed.

Understanding this versioning is essential as we move forward to examine the different isolation levels, which we will review from weakest to strongest.

Isolation level 1: Read Uncommitted (Dirty Read)

This one is simple: no sane database — PostgreSQL included — allows a transaction to read uncommitted data. PostgreSQL accepts READ UNCOMMITTED, but it behaves the same as READ COMMITTED.

Isolation level 2: Read Committed

This is the most important level to understand, as it is the default setting in PostgreSQL.

At this level, each query within a transaction sees only the data committed at the moment the query begins. While this prevents “dirty reads,” it allows for two specific anomalies:

Non-repeatable Read: If you read the same row twice within the same transaction, you might get different results if another transaction committed changes to that row in between your two queries.

Phantom Read: This occurs when a query (such as an aggregate or a range scan) returns a different set of rows on a second execution because another transaction committed an INSERT or DELETE in the meantime. A “phantom” row has appeared or disappeared.

Whether these anomalies are a problem depends entirely on your application logic. A typical risk is making a functional decision or a calculation based on data that changes before the transaction finishes.

While there are ways to solve these issues at this isolation level—such as using specific locking clauses—we will return to those at the very end of this post.

To better understand how this works in practice, you can use the following simulator to test how transactions behave when running side-by-side. Keep in mind how Postgresql uses Transaction IDs to check rows visibility in a transaction.

Read Committed: Interactive Demo

Step-by-step visualization of concurrent transactions and MVCC

Transaction A

Transaction B

Row Versions on Disk

Step 1 of 7

Use ← → arrow keys to navigate

3. Isolation level: Repeatable Read

With Repeatable Read, all reads within a transaction see the database as of a single snapshot (a consistent version of data). This prevents non-repeatable reads and, in PostgreSQL, also prevents phantom reads within the transaction. (The SQL standard allows phantoms under Repeatable Read, but PostgreSQL’s implementation does not.)

However, this isolation level changes PostgreSQL’s behavior in an important way: some transactions may fail because PostgreSQL detects that completing them would violate the guarantees of the isolation level. This can happen, for example, when two concurrent transactions attempt to update the same row. In that case, once one transaction commits, the other may be forced to abort with a serialization-related error. The application must be prepared to decide whether the transaction can be retried.

It is useful to compare this with Read Committed. Under Read Committed, concurrent updates are typically resolved by waiting: one transaction waits for the other to commit or roll back, and then proceeds. After the lock is released, the second transaction can apply its update (assuming the update conditions still match).

PostgreSQL’s MVCC model also introduces a related anomaly under snapshot-based isolation: write skew. In write skew, two transactions read overlapping conditions and then perform updates that do not touch the same rows, but together violate a business rule. The database does not necessarily prevent this under Repeatable Read. This is often easiest to understand by testing practical examples.

Repeatable Read: Interactive Demo

Snapshot isolation, serialization failures, and write skew

Transaction A

Transaction B

Row Versions on Disk

Step 1 of 7

Use ← → arrow keys to navigate

4. Isolation level: Serializable

The strongest isolation level is Serializable. It guarantees that concurrent transactions behave as if they were executed one-by-one in some order. In other words, the result must be equivalent to some serial execution; concurrent interleavings must not produce a different outcome.

In PostgreSQL, this is implemented using Serializable Snapshot Isolation (SSI). PostgreSQL tracks read/write dependencies (including predicate-level reads) to detect when concurrency could lead to a non-serializable outcome. When such a conflict is detected, PostgreSQL aborts one of the transactions to preserve serializability.

Serializable provides the strongest safety guarantees, but it is also the most expensive isolation level in terms of overhead and the likelihood of transaction retries. Just like Repeatable Read (and even more so), it requires the application to handle transaction aborts and implement a retry strategy when a serialization failure occurs.

Serializable: Interactive Demo

SSI predicate locking, dependency cycle detection, and true serializability

Transaction A

Transaction B

Row Versions on Disk

Step 1 of 8

Use ← → arrow keys to navigate

Interlude

Hopefully, the sections above explain why developers need to understand the different transaction isolation levels—and when it makes sense to use each of them.

At this point, it’s worth returning once more to the earlier discussion about Read Committed. There are practical techniques that let us keep using Read Committed while still avoiding many of its common pitfalls.

Read Committed and locks

You might be getting a little tired of new concepts by now, but PostgreSQL gives us several tools that can help us avoid moving to higher isolation levels—and, importantly, avoid the transaction aborts that stronger levels (Repeatable Read / Serializable) may require you to handle with retry logic.

If we want to ensure that data we read cannot change during our transaction, we can add a locking clause to the query, such as FOR SHARE.

This prevents the selected rows from being modified while the lock is held. Any concurrent transaction that tries to update or delete those rows must wait until the current transaction completes.

A similar approach is FOR UPDATE, which takes a stronger lock. In addition to blocking updates and deletes, it also blocks other transactions from acquiring certain weaker locks on the same rows (including FOR SHARE-type locks). In other words: FOR UPDATE is more restrictive, and should be used only when you truly intend to update the locked rows (or when you intentionally want to serialize access).

Locks can also be used to prevent phantom reads, but only under specific access patterns. If two transactions protect a shared “guard row” (or some other shared resource) using SELECT … FOR UPDATE, then inserts/updates that would otherwise create phantoms can be forced to wait—effectively serializing the critical section.

It’s also possible to use advisory locks to coordinate application-level critical sections. Advisory locks are powerful, but since they require careful design and consistent usage across the codebase, I’ll leave them as optional further reading.

To better understand how locks behave in practice, you can follow their effects in the interactive simulator below.

Read Committed: Avoiding Anomalies with Explicit Locks

Using FOR SHARE and FOR UPDATE to get stronger guarantees without changing isolation level

Transaction A

Transaction B

Row Versions on Disk

Step 1 of 8

Use ← → arrow keys to navigate

Thanks and further reading

The inspiration for building an interactive simulator came from the TheOtherBrian1 excellent site “Postgres Locks Explained”.

PostgreSQL documentation on isolation levels and locking:

AI tools (Gemini, ChatGPT) were used to improve grammar and clarity of the text. The interactive simulators were built with the help of Claude Code.

Using Generative AI tooling with Clojure

open@solita.fi (Solita Oy) — Wed, 11 Feb 2026 00:00:00 +0000

Clojure is easy to read for humans and AIs

Code written in Clojure is expressive and concise, but is still easy to reason about. In his “History of Clojure” paper Rich Hickey, the original author of Clojure states his motivations for building a new programming language:

“Most developers are primarily engaged in making systems that acquire, extract, transform, maintain, analyze, transmit and render information—facts about the world … As programs grew large, they required increasingly Herculean efforts to change while maintaining all of the presumptions around state and relationships, never mind dealing with race conditions as concurrency was increasingly in play. And we faced encroaching, and eventually crippling, coupling, and huge codebases, due directly to specificity (best-practice encapsulation, abstraction, and parameterization notwithstanding). C++ builds of over an hour were common.”

As a result, Clojure programs are very much focused on dealing with data and do it safely in concurrent programs. We have by default immutable data structures, easy to use literal representations of the most common collection types (lists, vectors, sets and maps) and a very regular syntax. A typical Clojure program has way less ceremony and boilerplate, not to mention weird quirks to deal with compared to many more programming languages such as Java, C#, Typescript or Python.

This means that large language models have less to deal with when reading or writing Clojure code. We have some evidence in Martin Alderson’s article that Clojure is token efficient compared to most other popular programming languages.

When we author code with generative AI tools, a developer reviewing it has less code to read in a format that easy to reason about.

Clojure MCP boosts Agentic development workflows

The REPL driven workflow speeds up the feedback cycle in normal development modes. Read Eval Print Loop is a concept in many programming languages in the LISP family such as Common Lisp, Scheme and Clojure. It allows the developer to tap into and evaluate code in a running instance of the application they are developing. With good editor integration, this allows smooth and frictionless testing of the code under development in an interactive workflow.

With the addition of MCP (Model Context Protocol) agents have gained access to a lot of tooling. In May 2025 Bruce Hauman announced his Clojure MCP that provides agents access to the REPL. Now AI agents such as Claude Code, Copilot CLI and others can reach inside the application as it is being developed, try code changes live, look at the internal state of the application and benefit from all of the interactivity that human developers have when working with the REPL.

It also provides efficient structural editing capabilities to the agents, making them less error-prone when editing Clojure source code. Because Clojure code is written as Clojure data structures, programmatic edits to the source code are a breeze.

We can even hot load dependencies to a running application without losing the application state! This is a SKILL.md file I have added to my project to guide agents in harnessing this power:

---
name: adding-clojure-dependencies
description: Adds clojure dependencies to the project. Use this when asked to add a dependency to the project
---

To add dependencies to deps.edn do the following:

1. Find the dependency in maven central repo or clojars
2. Identify the latest release version (no RCs unless specified)
3. Add dependency to either main list (for clojure dependencies),
   :test alias (for test dependencies) or :dev alias (for development dependencies). Use the REPL and
   `rewrite-edn` to edit the file
4. Reload dependencies in the REPL using `(clojure.repl.deps/sync-deps)`

In my experience, with the Clojure MCP coding agents have a far easier time troubleshooting and debugging compared to having them just analyze source code, logs and stacktraces.

As a developer, we can also connect to the same REPL as the coding agent, making it easy to step in and aid the agent when it gets stuck. In my workflows, I might look at the code the agent produced and test it in the REPL as well, make changes as required and instruct the agent to read what I did. This gives another collaborative dimension to standard prompting techniques that are normally associated with generative AI development.

Getting AI to speak Clojure

Generating and analyzing code with AI tooling is just one way to apply AI in software development. As developers, we should understand the potential for embedding AI functionality at the application level too. LLMs seem to be good at understanding my intentions, even if they don’t necessarily produce the right results. One possibility is to take input provided by a human and enrich it with data so that further processing becomes easier. For the sake of experiment, let’s look at a traditional flow of making a support request.

The user goes to the portal and their first task is to identify the correct topic under which this support request belongs to. They usually have to classify the severity of the issue as well. Then they describe what problem they have and add their contact information. With this flow, there’s a large chance that the user misclassified their support request, causing delays in getting the work in front of the right person, making the user experience poor and causing frustrations in the people handling the support requests. From the user’s point of view they don’t care about which department picks up the request, so this system is pushing the support organization’s concerns to the end user.

What if we could avoid all that and have the request routed automatically to the right backlog? Enter OpenAI’s Requests API which can handle text, image and various file inputs to generate text or JSON outputs. The json_schema response format is interesting in particular because we can express the desired result format in a manner that we can then use to process the response programmatically down the line.

In the Clojure world, we often use Malli to define our data models. We can use malli.json-schema to transform our malli schemas into JSON schema that the endpoint understands, and then use malli.transform to translate the response from JSON back to Clojure data.

A similar idea has been shown previously by Tommi Reiman, author of Malli.

Note that the choice of model can have a big effect on your output!

(require '[malli.json-schema :as mjs])
(require '[malli.core :as m])
(require '[malli.transform :as mt])
(require '[cheshire.core :as json])
(require '[org.httpkit.client :as http])

(defn structured-output
  [api-endpoint-url api-key malli-schema input]
  (let [;; Convert Malli schema to JSON Schema
        json-schema (mjs/transform malli-schema)

        ;; Build request body
        body {:model "gpt-4o" ;; consult your service provider for available models
              :input input
              :text {:format {:type "json_schema"
                              :name "response"
                              :strict true
                              :schema json-schema}}}

        ;; Make HTTP request
        response @(http/post
                   (str api-endpoint-url "/v1/responses")
                   {:headers {"Authorization" (str "Bearer " api-key)
                              "Content-Type" "application/json"}
                    :body (json/generate-string body)})

        ;; Parse response
        parsed-response (json/parse-string (:body response) true)

        ;; Extract structured data from response
        content (-> parsed-response :output first :content first :text)
        parsed-data (json/parse-string content true)

        ;; Decode using Malli transformer
        result (m/decode malli-schema parsed-data (mt/json-transformer))]

    ;; Validate and return
    (when-not (m/validate malli-schema result)
      (throw (ex-info "Response does not match schema"
                      {:schema malli-schema
                       :result result})))
    result))

(structured-output
   (get-base-url)
   (get-api-key)
   [:map
    [:department [:enum :licences :hardware :accounts :maintenance :other]]
    [:severity [:enum :low :medium :critical]]
    [:request :string]
    [:contact-information [:map
                           [:email {:optional true} :string]
                           [:phone {:optional true} :string]
                           [:raw :string]]]]
   "Hi, my laptop diesn't let me login anymore. Can't work. What do? t. Hank PS call me 555-1343 because I can't access email")
; => {:department :hardware,
;     :severity :critical,
;     :request "Laptop doesn't let me login anymore. Can't work.",
;     :contact-information
;     {:raw "Hank, phone: 555-1343, cannot access email",
;      :phone "555-1343"}}

Notice how the model was able to process the human input that contained typos and informal, broken language. One doesn’t usually have to use any of the more powerful and expensive models to do this level of work. The older json_object response format has some capabilities and supports even lighter models. See OpenAI’s documentation for reference.

I think methods like this make it easy to embed LLM-enabled functionality in Clojure applications, giving them capabilities that are normally very hard to implement using traditional methods.

DISCLAIMER

If you were to implement the above example in your application as is, you’d be sending personal data to OpenAI. As developers, we should always consider the larger implications. You can deploy models locally in your region and keep data residency and processing within the EU region for example by using Solita’s FunctionAI in UpCloud or other service providers.

Prompt Engineering 101

open@solita.fi (Solita Oy) — Tue, 10 Feb 2026 00:00:00 +0000

Let’s be honest. Those who have embraced AI as part of their daily development work have noticed significant improvements in both speed and quality (yes, we are not talking about vibe coding). So the question is no longer “Is AI useful for coding?” but rather “How do I get the most out of it?”

Why do some developers see tremendous benefits while others end up with spaghetti code and hallucinations? I took on a challenge at the end of last year to only work by prompting, in order to learn the ins and outs of AI-assisted development.

In this post, I’ll share the key lessons from that journey, and hopefully inspire you to give it (another) try.

So What’s the Problem?

Bad prompt:

My app hangs when users log in but only sometimes and I’ve tried everything, can you fix it?

A common mistake when starting out is selecting the wrong problem for AI to solve. I made this mistake myself and have observed many others doing the same. The workflow typically goes something like this:

There’s an issue to fix.
You try the obvious solution (and it doesn’t work).
You go deeper, read more code, debug, and exhaust all your own resources.
You finally ask the AI for help.

You might get a useful hint, but more often than not, the results miss the mark entirely. So you dismiss the AI and go back to debugging by hand.

Better prompt:

I’m debugging a login issue where the app sometimes hangs.

Look at Services/AuthService.cs, Controllers/AuthController.cs and Middleware/JwtMiddleware.cs to understand the login flow.

Look at Repositories/UserRepository.cs to see how we fetch the user from db.

Here is our logic in the cache layer: Services/TokenCacheService.cs

Analyze the flow and give me suggestions where the issue might be.

When I set the prompting challenge for myself, I quickly realized that using AI effectively requires a mental shift away from thinking of it as an “all-knowing entity” or a sparring partner. Instead, you need to guide the AI like you would instruct a junior developer. Once you are skilled enough in prompting, you can treat it more like a peer at the same level as you. Once I started giving the agent simple and clear tasks, I found it performed remarkably well!

Here’s the thing: if you don’t know how something should be done, the AI doesn’t know either. Or rather, if you don’t know what you want from the AI, how can you expect it to deliver?

AI is fundamentally a guessing machine. Without clear guidance, it will confidently guess and keep guessing. The quality of your output is directly tied to the clarity of your instructions.

Context Is Everything

The key to effective prompting is understanding how AI context works. While the model is trained on vast amounts of data from across the internet, the context provided in your current chat session carries significantly more weight. I initially assumed that since JavaScript dominates AI training data, the model would perform poorly with other languages. This assumption was incorrect. Once you grasp how context influences output, you can achieve excellent results regardless of programming language or tech stack.

Here is another example:

Bad prompt:

Create a new API endpoint for user profiles.

This prompt would likely result in unexpected changes across your codebase and generic code based on common conventions from training data.

Better prompt:

Create a new API endpoint for fetching user profiles.

Look at Controllers/ProductController.cs for reference on how we structure our endpoints and routing attributes.

Look at ClientApp/src/views/UserProfile.tsx and see what placeholders we are using to deduce what fields should be returned.

Follow the same patterns for error handling and response formatting.

The second prompt is more effective because it provides the AI with concrete reference points from your actual codebase. Instead of leaving the AI to guess your project’s conventions, you’re explicitly pointing it to existing implementations. The AI can now read those files, understand your patterns for routing, controller structure, and error handling, and produce code that fits seamlessly into your project.

But what if I told you that even the bad prompt can yield excellent results? Enter Planning mode.

Just Use Planning Mode

I’m a huge advocate of Copilot’s Planning mode. In Agent mode, Copilot eagerly starts executing, often in the wrong direction.

Planning mode, on the other hand, forces the AI to stop, think, and explore the codebase first. It creates a step-by-step plan of what it intends to do and asks for clarifying questions. This simple change makes a massive difference. You can catch misunderstandings early, redirect the approach, or refine your requirements before any code is written. And most importantly, it automatically loads exactly the files and references it needs into context so it can complete the task without going off the rails.

Let’s see how the same “bad prompt” can outperform our carefully crafted “better prompt” when used with Planning mode.

You:

Create a new API endpoint for user profiles.

Planning Agent:

I’ll help you create a new API endpoint for user profiles. Let me first understand your project structure and conventions.

Gathering context…

Reading Controllers/ to understand your controller patterns and routing attributes

Reading Models/User.cs to understand the User entity

Reading Services/ to see how business logic is structured

Reading ClientApp/src/views/UserProfile.tsx to see what fields the frontend expects

⚠️ I noticed something: Some of your GET endpoints use IDistributedCache with a 5-minute TTL. Since user profiles are read frequently but rarely updated, I’ll apply the same caching strategy here.

Here’s my plan:

Create Controllers/UserController.cs following the pattern in ProductController.cs

Add route /api/users/{id} using [Route] and [HttpGet] attributes

Create DTOs/UserProfileDto.cs with fields: Id, Name, Email, Avatar, CreatedAt (based on UserProfile.tsx usage)

Implement Redis caching with 5-minute TTL using IDistributedCache, same as ProductController.cs

Use the same ApiResponse<T> wrapper and error handling as other controllers

Add input validation using FluentValidation

Questions before I proceed:

Should this endpoint require authentication?

Can users view other users’ profiles? If so, should we use a separate DTO that omits sensitive fields like email?

Does this plan look correct?

Now we are cooking! You can see exactly what the agent intends to do before it writes a single line of code. You can answer its questions, refine the plan, and polish it until it’s exactly right. In my experience, the agent often catches details I overlooked (like the caching pattern example above), which would have caused inconsistencies later.

Here’s the magic of context. Once the agent has explored your codebase and built a plan, you don’t need to start from scratch for related tasks. The relevant files are already loaded, and the agent remembers what it just did. Your next prompts can be much simpler:

You:

Update the UI to call the new endpoint and replace the placeholders with real data.

You:

Add unit tests for the new endpoint. Look at ProductControllerTests.cs for reference.

Notice that we still point the agent to the right reference file when needed.

You:

Actually the CreatedAt timestamp is not needed. Remove it from the response dto and from the UI.

You:

When the user id does not exist we hit 404 but in this case we want to redirect to the front page. Look at ProductPage.tsx for example.

A word of warning about context rot. AI memory behaves a lot like human memory: it retains what was discussed at the beginning and end of a conversation, but the middle gets hazy. If you keep going in the same chat session for too long, the agent becomes overwhelmed with too much information and starts getting confused. A good habit is to start a fresh chat session for each new feature, keeping the context focused on the task at hand.

“What about the hard stuff like race conditions, complex state machines, and security edge cases?”

Well… you’re not there yet. Start by automating the easy tasks you already know how to solve. AI performs best when you can clearly describe the outcome. If you know you need to extract logic into a service and refactor 10 files to use it, let the AI do that and save time. You probably would’ve made a copy-paste error anyway, or left a misleading comment in.

But once you’ve built that foundation, the complex problems are exactly where good prompting shines. The AI struggles when you’re vague, but if you can enumerate the edge cases, describe the state transitions, or specify the security requirements, it handles them remarkably well. Complexity isn’t the enemy. Unclear complexity is. AI can solve any complex task, but the challenge is breaking it down into clear, actionable steps. Ask yourself: how would you delegate this task to a junior developer?

Prompting Is a Skill

Once you get the hang of it, this is what “coding” looks like for me now. It’s going back and forth with the AI to refine the plan until it’s right. I get to focus on the big picture and how the pieces fit together. In the end, I design better features, improve the codebase through refactoring, and save time because the code writing is automated.

But getting here wasn’t instant. At first, I felt like an idiot when nothing worked. After my initial attempts, I caught myself thinking “I can code faster by hand than fixing the AI’s mistakes.” It took about two weeks to break even with manual coding, and another few weeks before the new approach finally clicked.

Prompting is a skill just like any other. You have to accept a small ego hit and feel dumb for a bit to make progress. The hardest part is getting started and keeping going. You don’t yet know how to talk to the agent. Your prompts will fail. You’ll redo things. A lot. But with each mistake, you learn what works and what doesn’t.

The point comes eventually when you realize you’ve done a day’s worth of work in minutes without the AI making a single mistake. After that, there’s no going back.

How Not to Get Overwhelmed

The world of agentic coding is evolving way too fast for anyone to stay on top of everything. New concepts emerge constantly: MCP (Model Context Protocol) lets agents connect to databases, APIs, and external tools. Agent Skills give Copilot specialized capabilities for specific tasks. Multi-agent orchestrators like Gas Town let you coordinate 20-30 Claude Code agents working in parallel with persistent work tracking. And custom agents let you create specialized assistants tailored to your workflow.

It can feel overwhelming. If I changed my workflow every time a new tool came up, I wouldn’t get any work done. And it all boils down to context management: these features are just different ways to feed better instructions to the model. That said, model choice does matter. Models have improved dramatically, and in my opinion, Claude Opus 4.5 is currently the best for coding.

My advice is to tune out the noise. First focus on mastering the fundamentals: understanding context, writing clear prompts, and using Planning mode. Once you’ve nailed those, the advanced features will make much more sense.

Conclusion

AI-assisted development isn’t magic, and it’s not going to replace you. It’s a tool that enables you to focus on solving the actual problem and helps you save time by automating the coding part.

Start with Planning mode. Just talk to the agent. Break big problems into smaller ones together with the agent. Accept that there’s a learning curve and your performance takes a hit in the beginning. And when it finally clicks, the bottleneck moves from typing to thinking.

Python in 2026: Popular As Ever, Avoided in Production

open@solita.fi (Solita Oy) — Mon, 09 Feb 2026 00:00:00 +0000

I’m biased toward Python for many reasons. I’m also one of the few who’ve watched my own Python scripts place $1.5M worth of asset orders in my personal brokerage account — but that’s a story for another time. The point is: I trust Python with systems where mistakes are expensive.

In this post, I’ll explain how Python became the world’s most popular programming language, yet is often sidelined in enterprise production. Why? And should it be?

Popularity

Python became the world’s most popular language in 2021, when it left the last two languages (C and Java) in the dust. Thanks to its ease of use and lower friction, it became the primary choice in academia as well as for quick hacks. Harvard, MIT, Princeton, and even my local uni now use Python for their introductory courses. At Google and Amazon, it’s a first-class language, and the other cloud providers (Microsoft, IBM, Oracle, etc.) fully support it for serverless and their other APIs.

For many students and professionals — myself included — the low barrier to entry and high productivity, without any safety net (like type checks), is love at first sight. I really enjoy writing Python code: I’m able to focus on the problem at hand, and can ignore all formalism. And the freedom! Oh boy, the freedom.

For ML and AI tasks, Python is the default language. TensorFlow, PyTorch, Pandas, and scikit-learn all effectively require you to jump through hoops to use anything else.

But what exactly made it a giant in the first place? It’s trivial; just answer this: how many languages do you know of that can open a browser tab for every HTML file in some subdirectory, only using the standard library and a couple of lines of code?

import pathlib, webbrowser

for htmlfile in pathlib.Path(".").rglob("*.html"):
    webbrowser.open(htmlfile.absolute().as_uri())

Some will say that’s compact and convoluted. I say brief and beautiful! But let’s not get bogged down by aesthetics here. No main function. No error checking. No type checking. Just. Make. It. Happen.

Quite the opposite of what an Architecture Astronaut would come up with: this has nothing to add, nothing to subtract, and if you understand those two lines of code, you know everything there is. No interfaces, no objects to orient, no errors to handle, no types to take care of, no main to declare. A noob who sees it can understand it — it’s almost English. And this simplicity, of course, not only applies to browsers and files. For All The Things, Python makes it easier.

And let’s not forget the feeling. I can script anything in a few lines; that’s addictive!

To Use or Not To Use

When building desktop and mobile apps, Python is not where sane people tend to look. Performance is equally off-brand. Even when it comes to web dev, Python still suffers from a bad rep (arguably due to the horrific standard library web server implementation). There have however, been stellar industry-standard web frameworks for 16 years. Assuming you’ve created the app in a couple of lines, this is how easy it is to serve an HTML page:

@app.route("/")
def index():
    return '<a href="https://tinyurl.com/iamdeveloper">Goodnight!</a>'

My two code examples here are not outliers; Python is generally extremely concise and productive, including for web dev.

What’s more, many performance problems are fixable. I’m one of the few who should know, as I’ve written an online 3D game with physics, skinning, and terrain generation. In Python. From scratch. Able to reach 500 FPS on my old junk PC. (That’s a whole ‘nother blog post.) As you see, the performance ceiling isn’t where many think.

In regards to type information, error handling, and hygiene, most risks can be mitigated with a linter and a static type checker (pre-commit time).

If Python can do all these things — and easily too — why is nobody using it for enterprise production?

When its strengths become its weaknesses

Python is made for scripting, and it’s super easy to get started. But if you are used to letting the IDE take care of most problems at the time of writing code, there’s a real risk of runtime problems unless guardrails are put in place. And frankly, most humans are lazy. Good programmers more than most. So while it’s easy to fix, those that don’t know, don’t know — and don’t want to know. An old study from 2015 shows Python to be one of the most concise languages, but also one of the most error-prone. The quick-hack qualities that propelled its popularity also make it easy to misuse at scale, which in turn fuels enterprise distrust.

When it comes to data scientists, analysts, and researchers, they aim for experimentation and insights. Their incentives have nothing to do with long-term maintainability for large teams. So we can’t take their advice on what to code our enterprise systems in.

Half of professional developers (have to?) use Python, but it seems highly disliked by those who don’t take it to heart. Looking at my own employer, only 6% prefer Python over other languages. From talking to developers, I believe that the main reason for the dislike is that people feel it’s “like Java but error-prone and slow.” To which the response should be: if my grandmother had wheels, she would have been a bike.

But of course, there is a kernel of truth to that. On the other hand, nobody avoids knives because “that’s what Jack the Ripper used.” I say: better to learn how to use a knife, and use it with caution. And I realize that no amount of preaching is going to move the needle even one bit. Which also tells me that you, dear choir, who’ve made it this far are part of the few Chosen Ones.

Causality vs. Python: 1–0

We all know Python is used by everyone and their Uber driver. NASA uses it, banks use it, Reddit’s built on it. Everyone from Netflix to Pfizer uses it for orchestration and analysis. But. And there’s a big but. The enterprise adoption has to do with the arrow of time. Let me explain.

Nobody who’s deciding on a language for their platform:

Spends years learning Python,
Discovers how productive it is,
Learns about static type checkers,
Learns how to fix performance bottlenecks,
Builds confidence that it can work in enterprise production,
And then goes back in time to pick Python as their foundation.

By the time you’ve climbed that ladder of understanding, the choices have already been made. Python is the chicken, and nobody’s the egg.

Many people realize Python is highly productive, but very few know it can be highly performant. Most people get off the ladder way before they see that Python can be suitable for production.

Even MSc graduates who’ve used Python a lot for experimentation in small teams have no prior experience in working in large corporations with enterprise solutions. And surely they’ve all made abominable programming mistakes during their years in college, so they’d be the first to admit that Python is too permissive for its own good. And a lab exercise in computer science is a far cry from a 100-person development department where everyone is trying to churn out features.

For the staggering few remaining proponents, there’s one more hurdle: they hear that YouTube, Instagram, and Dropbox rewrote parts of their stack in other languages for performance. Counterfactual reasoning is hard. Would YouTube have been written by 2 people in a small office above a pizzeria if it weren’t for Python? Who knows.

So the enterprise reasoning goes “better safe than sorry.” And truth be told, that might be the right way to go.

Final words on enlightenment

But if you’re the type of company that dares to think different — if you’ve gone all the way up that ladder, eaten the egg, and reversed the arrow of time — then, just like a Buddhist monk, you’ll have focused your ass off for years, just to realize when you pop out at the top of enlightenment, that it was all so easy all along.

And then, just like the monk, you’re in for a really good time. Aesthetically and productively. And more than ever, you’ll be able to focus on the big picture, not on the code.

But definitely don’t take my word for it. Love is blind, you know.

Disclaimer: The content, ideas, and the way they’re expressed in this blog post are entirely my own. However, Solita FunctionAI was utilized for grammar, spelling, and stylistic review, and ChatGPT was used for visualizations.

Decoupling a Legacy Spring Boot Monolith with Branch by Abstraction

open@solita.fi (Solita Oy) — Thu, 08 Jan 2026 00:00:00 +0000

We’ve been developing and maintaining a Java Spring Boot codebase for the past 15+ years. In the beginning, there was one server (let’s call it Foo) and a client UI application. Over the years, this codebase has evolved into a monorepo containing four client UI applications and two server applications (Foo and Bar), all of which share the same database schema.

When Bar was introduced, a decision was made to share code (Spring components) directly from the Foo codebase. Even worse, Bar was directly coupled to Foo database schema. Now the older Foo application is finally near end-of-life and it should be replaced by a new application. However, with Bar directly dependent on Foo’s code and database, the question was: how do we achieve this replacement without breaking everything? To make matters worse, all applications are critical with 24/7 on-call support.

In this post I’ll dive deep into how our team tackled the challenge in decoupling the applications by systematic refactoring. As the work is still ongoing, I’ll focus on changes related to a single business domain. I’ll share lessons learned on managing risk, verifying quality, and keeping developer morale high while making large-scale changes to a critical system.

Here, There, Everywhere

Our initial task was to identify how the business domain (which we’ll call “Product” throughout this post), conceptually owned by the Foo application, was being utilized within Bar. What we quickly uncovered was a sprawling mess: a multitude of Product-related domain objects, DTOs, JPA repositories, Hibernate DAOs, named queries, and various other data access mechanisms, all scattered across both Foo and Bar, accumulated over years of development.

Whenever the Bar application needed to interact with “Product,” it seemingly randomly selected one of these services, repositories, or DAOs. There were no clear boundaries, no separation of concerns, and no unified interfaces. We were looking at hundreds of integration ‘seams’ where the Product entity was accessed, either directly in code or through database queries. Crucially, the Product entity’s influence wasn’t confined to the data access layer; its database identifiers and related logic were pervasive throughout the codebase.

To navigate this complexity, static analysis tools within our preferred editor, IntelliJ IDEA (specifically ‘Find Usages’ of classes and methods, and dependency graphs), proved invaluable. Our ultimate goal was to transition Bar to consume a dedicated ProductAPI, exposed as a new HTTP REST service for all Product information access. But how could we get there? The chasm between our current state and that desired future seemed insurmountable.

Our Strategy: Branch by Abstraction

Martin Fowler defines the Branch by Abstraction pattern as:

…a technique for making a large-scale change to a software system in gradual way that allows you to release the system regularly while the change is still in-progress.

It is especially powerful in critical systems when we must release changes gradually, ensuring the quality of the overall system and allowing multiple implementations to coexist simultaneously in production.

Here’s how Branch by Abstraction typically unfolds through its core phases:

Phase 1: The Starting Point

At the starting point, we have clients calling a poorly behaving supplier:

Phase 2: Introducing the Abstraction and Gradual Migration

We introduce a new abstraction layer (an interface) between the client and the existing supplier. We then gradually migrate client calls to go through this abstraction layer, piece by piece:

Phase 3: Full Abstraction Adoption

Eventually, all client calls have been successfully migrated to go through the abstraction layer:

Phase 4: Building the New Supplier

Next, we build the new, modern supplier, ensuring it fully implements the newly introduced abstraction layer:

Phase 5: Gradual Cutover to the New Supplier

We then start gradually switching clients to use the new supplier’s implementation of the abstraction. This critical phase can often be managed with feature flags or A/B testing:

Phase 6: Removing the Old Supplier

Once all clients have been migrated to use the new supplier, the old, poorly behaving supplier (and its implementation behind the abstraction) can be safely removed:

In the intricate dance of large-scale refactorings, a core challenge lies in balancing delivery speed against the inherent risks of downtime and critical bugs. Given our critical environment with 24/7 on-call support, we deliberately prioritized minimizing risk, understanding that this would inherently mean a more measured pace for feature delivery to production. Branch by Abstraction, coupled with the rigorous quality verification techniques detailed later in this post, became our fundamental approach for ensuring this low-risk posture. This prioritization, however, naturally extended the overall timeline for the full migration, a conscious trade-off we embraced.

With Branch by Abstraction as our guiding principle, our first concrete application began with the ‘Product’ domain, aiming to create that initial abstraction layer.

Introducing the Abstraction Layer: ProductService

To bring structure to this chaos, our first crucial step was to introduce a unified access layer for “Product” data within Foo. This meant defining a new ProductService interface, which would become the sole conduit for Bar’s access to Product information. A key design decision was that this interface must not expose underlying Hibernate-proxied entities, but rather pure ProductDto objects.

We then implemented a FooProductServiceImpl for this interface. Crucially, this implementation still leveraged the existing Foo services, repositories, and DAOs for data access. However, by funneling all Bar’s interactions through the ProductService interface, we effectively decoupled Bar from Foo’s internal implementation details.

To handle the conversion from existing entities to the new DTOs, we integrated the MapStruct library into our codebase. This allowed us to gradually replace direct Product entity access in Bar with calls to the new ProductService interface, returning ProductDto objects. This initial refactoring was relatively straightforward and easy to split into smaller tasks, primarily because the ProductDto objects, at this stage, mirrored the data and fields of the original entities. However, we were able to simplify ProductDto significantly, because there were quite a few fields or methods that the Bar application didn’t need.

It’s important to note that, at this point, we deliberately didn’t over-optimize the ProductService interface’s structure or cohesion. It contained numerous methods with slightly differing parameters for retrieving Product data. The more complex task of rationalizing, removing duplicates, and condensing the interface into a leaner, more cohesive design was deferred to a later project phase.

Finally, to enforce this architectural boundary and prevent regressions, we introduced architecture tests using ArchUnit. These tests ensured that the Bar codebase could no longer directly reference or use the original Product entity, solidifying our new decoupling strategy.

Decoupling Product Data from the Database

Once the ProductService and ProductDto abstraction layers were established, our next major undertaking was to decouple the Bar application’s code from the shared database. At this stage, the ProductDto still contained its internal database identifier, and it often referenced other Foo domain objects (like IngredientDto) using their database identifiers as well. We recognized that relying on such internal database details was not only poor practice but would also be impossible once we transitioned to the new ProductAPI service.

Our solution involved systematically replacing these database identifiers with more stable, business-oriented identifiers. This transition was, once again, implemented gradually within the Bar codebase:

First, the business identifier was introduced into the relevant DTO objects.
Next, Bar’s code was updated to utilize this new business identifier.
Finally, once a database identifier was no longer referenced anywhere in Bar’s code, it could be safely removed.

A second significant challenge was Bar’s direct database access, a consequence of the shared schema. Numerous queries within Bar involved JOINs directly to the PRODUCT table or its related tables. This, too, represented an anti-pattern and would be unsustainable after switching to the new ProductAPI service.

To address this, we systematically refactored Bar’s codebase to route all Product-related data access through the ProductService abstraction layer. The common pattern that emerged involved a Bar service layer first fetching its own Bar-specific domain objects via its repository layer. It would then determine what Product data was needed and subsequently fetch that information using the ProductService abstraction layer, effectively orchestrating data from both sources.

Gradual Switchover to the ProductAPI

With the Bar codebase now entirely decoupled from direct database queries for Product-related data, and our ProductDto and related DTOs cleaned of all internal database identifiers, we were finally ready to introduce a second implementation of the ProductService interface representing our new modern supplier.

This new implementation, aptly named ProductApiServiceImpl, was designed to fetch Product data from the external ProductAPI via its HTTP REST interface. Since the ProductAPI provided an OpenAPI description, we were able to leverage this to automatically generate a robust Java client. This generated client was then injected into ProductApiServiceImpl and further enhanced with Resilience4j features, including circuit breakers and retry functionality, to gracefully mitigate network transient errors and prevent API overload. As before, MapStruct played a vital role in seamlessly converting the data from the generated ProductAPI client classes into our established ProductDto objects.

At this juncture, we had two distinct implementations of the ProductService interface. The existing FooProductServiceImpl (using the old Foo internals) was designated as the default using Spring’s @Primary annotation. To manage the gradual transition, we began switching Bar’s services, one by one, to utilize the new ProductApiServiceImpl by selectively injecting it using Spring’s @Qualifier annotation. This allowed for fine-grained control over which parts of Bar began consuming data from the new API, enabling a safe and incremental cutover.

Quality Verification

When working with critical software that demands 24/7 on-call support, investing in rigorous quality verification is paramount. We were undertaking large-scale changes to the very core of the Bar application, and while most pull requests were of a manageable size, some were substantial. In total, this effort spanned over a hundred Jira issues. The pressing question was: how do we thoroughly verify quality to prevent those dreaded late-night calls to the on-call duty officer?

Our strategy, beyond maintaining good overall test coverage in new code, encompassed feature flags, A/B testing with result verification, and performance testing. We leveraged feature flags to dynamically switch between old and new implementations, for instance, during the migration from database identifiers to business-oriented ones. This mechanism provided a rapid rollback capability in production if any issues emerged, greatly reducing risk.

A/B testing with result verification proved to be another heavily utilized technique. For this, we relied on a custom implementation that was fortunately already available. Our team had previously developed this robust testing facility during an earlier migration from legacy Hibernate code. This A/B testing facility was designed to always return the result of the existing implementation, while simultaneously executing the new implementation and verifying its results against the old. We could precisely control the percentage of requests that executed the new implementation, mitigating potential high-load issues. The facility also supported custom verifiers, which proved essential since simple equality verification wasn’t always feasible. We conducted A/B testing in both our test environments and in production. Once we gained sufficient confidence that no discrepancies existed between the old and new implementation results, the A/B testing harness could be safely removed from the codebase.

For performance testing, we already utilized Locust to simulate the load of tens of client applications. While we didn’t specifically performance-test each new implementation in isolation, we rigorously checked for any regressions in overall performance test results between release candidates.

In addition to verifying functional correctness, our A/B testing facility also proved invaluable for performance analysis. By logging the execution times for both old and new implementation calls, we could meticulously inspect differences in performance. Given that the old implementation relied on direct database access while the new one fetched data over HTTP from an external service, inherent differences in access methods were expected. We observed a mixed bag: some data fetches were surprisingly faster with the ProductAPI implementation, particularly when the old SQL query was complex. However, others — especially for simple SQL queries fetching small datasets — were significantly slower through the ProductAPI. This disparity immediately highlighted the need for a caching solution to prevent Product data access from becoming a performance bottleneck. We began with a simple in-memory cache for each server instance, strategically caching frequently accessed Product instances. This foundational cache is designed for potential future migration to more robust solutions like Redis/Valkey, if needed. Furthermore, we identified opportunities for HTTP-level caching for larger datasets from the ProductAPI, and in some cases, we even refactored data access patterns to proactively gain performance benefits during the migration.

Where We Are Now

We’ve successfully introduced the ProductAPI-based implementation into production for a significant portion of Bar services. While a few issues were inevitably discovered only in production, our robust A/B testing facility proved invaluable. These issues were promptly identified via production logging and monitoring, and crucially, as the facility always returned results from the old implementation, there were no visible problems or service interruptions for our clients.

We acknowledge that a substantial migration effort still lies ahead to transition all remaining Bar services to the new implementation, but we are confident in achieving this goal soon. We anticipate that subsequent service migrations will be relatively more straightforward, benefiting from the lessons learned and issues resolved during the initial cutovers and A/B testing phases. For these later migrations, the need for extensive A/B testing might diminish, allowing for direct migration to the new implementation. This, of course, represents a critical trade-off between delivery speed and risk management, necessitating a careful, case-by-case evaluation.

Throughout this extensive process, celebrating small, yet significant, victories has been crucial for maintaining team morale and momentum. These milestones include:

Ensuring the entire Bar codebase now exclusively utilizes the ProductService abstraction layer.
Implementing architecture tests to prevent the reintroduction of the old Product entity in the Bar application.
Eliminating all direct database queries within the Bar codebase that previously performed SQL JOINs to the PRODUCT table.
The first successful production migration of a Bar service to the ProductAPI.

Key Takeaways and Lessons Learned

Our journey through this large-scale refactoring provided several invaluable lessons that are applicable to similar complex projects:

Branch by Abstraction is Indispensable for Critical Systems: For high-traffic, continuously deployed applications, the incremental, low-risk nature of Branch by Abstraction is a powerful enabler for significant architectural changes without disruption.
Enforcement through Architectural Tests is Key: Tools like ArchUnit are not just helpful; they are essential for preventing regressions and maintaining newly established architectural boundaries. Without them, the carefully built seams can easily fray.
Proactive Resilience Pays Off: Integrating resilience patterns (like Resilience4j’s circuit breakers and retries) from the outset for new external API calls is non-negotiable. It protects the system from transient network issues and external service instability.
Custom A/B Testing Facilities are Strategic Assets: For deep, internal refactoring where external tools might not suffice, investing in a custom, controlled A/B testing harness that can verify results in production while shielding end-users is incredibly powerful for de-risking deployments.
Small Victories Fuel Long Journeys: Large, multi-month projects can be draining. Recognizing and celebrating intermediate achievements, even seemingly minor ones, keeps the team engaged, motivated, and focused on the long-term goal. It can be as simple as bubbles or cinnamon rolls in team retrospective.
Continuous Evaluation of Trade-offs: Even with a clear strategy, the path evolves. Regularly reassessing the risk-vs-speed trade-off (e.g., for subsequent A/B testing) ensures agility and efficiency.

This refactoring has significantly modernized our architecture, improved our data access patterns, and laid a solid foundation for future development, all while maintaining the stability required by a critical 24/7 service.

Disclaimer: The content and ideas expressed in this blog post are entirely my own. However, Solita FunctionAI was utilized for grammar, spelling and stylistic review, and ChatGPT was used for visualizations.

Speed Up Data Processing in Node with p-limit and Worker Threads

open@solita.fi (Solita Oy) — Tue, 18 Nov 2025 00:00:00 +0000

When I started writing this blog post, I realized that Node.js is now a teenager — at that age I was setting up my first website with PHP and only thinking about becoming a software developer. Back then, Node.js was created to let web servers use JavaScript, the same language powering websites. While Node.js is well-suited for I/O driven web servers, it faces challenges with CPU-intensive computations due to its single-threaded event loop. When heavy computations run on the main thread, they can block other events and degrade overall performance.

In this blog post, we’ll explore practical strategies to accelerate a real-world Node application that reads several large JSON files from disk, processes their contents, and outputs the results as a large number of smaller JSON files. We’ll introduce two powerful Node.js tools: p-limit library for managing concurrent I/O operations, and worker_threads for parallelizing CPU-bound tasks. By combining these techniques, we can significantly reduce processing time and make Node applications more scalable.

Limiting Factors in Node

To make sense of how to optimize performance in Node.js, it is essential to first understand the underlying limitations. At its core, Node.js is built on the V8 JavaScript engine, which provides high-speed execution of JavaScript code, but even highly optimized code cannot match the speed of native code. This means that Node.js is hardly the fastest tool available for raw data processing, so why use it for that in the first place? Well, it is a natural choice for handling JSON-based data due to its native support for JavaScript and rich node_modules ecosystem. It’s also a widely used tool and can be easily picked up by virtually any web developer.

Node’s architecture is fundamentally event-driven and single-threaded. This works fine for most web interfaces and servers, but can be seen as a limitation for pure data processing. In simple terms, single-threaded means that only a single JavaScript event or function can be on execution at a time. Even if you put your code in a Promise-returning function, its synchronous parts are still run sequentially and block the event loop from executing other tasks. Luckily, Node.js is still efficient for handling I/O operations such as reading/writing files and handling network traffic. These operations are delegated to run by the underlying system (mainly libuv thread pool) and thus do not overload Node’s main event loop.

To optimize our Node process, we are going to maximize the performance of parallel I/O operations and also parallelize CPU-bound operations. How much of an increase can we expect? It’s difficult to give a precise prediction, as it largely depends on the use case. In our case, we start with a processing time of about 40 seconds. Let’s see how much we can improve it.

Processing Data Overview

Let’s begin with a simple example of processing data and writing the result to the disk:

for (const file of files) {
  const result = await processData(file);
  await fs.promises.writeFile(result.path, result.data); // I/O operation, handled by libuv
}

Each file is processed and written to the disk one-by-one. This is simple and straightforward, and if it’s fast enough for you, you could stop reading here. Otherwise, we can see that this code is not very efficient since we are only either processing data or waiting for the write operation to complete. Let’s improve it by running the write operation in the background:

for (const file of files) {
  const result = await processData(file);
  fs.promises.writeFile(result.path, result.data); // no await here, let it run in background
}

Here we do not wait for file writing to complete, but schedule it and immediately continue processing the next file. However, error checking is still missing and we do not wait for those background operations to complete. Let’s fix it:

const writePromises = [];

for (const file of files) {
  const result = await processData(file);
  const p = fs.promises.writeFile(result.path, result.data);
  writePromises.push(p);
}

// Data processing done, wait for all write operations to successfully complete. This throws an exception if even one write failed.
await Promise.all(writePromises);

This looks better from performance perspective as we are now doing more than one thing at a time, but the gained performance highly depends on how fast processData is compared to file writing. If it’s slow, we might not gain much benefit at all. We also have a potential memory problem since we are queuing up all write operations to libuv at once. If result is large and there are many files to process, this could lead to high memory peaks. While libuv has some limits of how many write operations it does in parallel by default, the remaining operations are still put into queue. Let’s see if we can improve this further using p-limit.

p-limit

p-limit is a lightweight library for controlling concurrency in asynchronous operations. In other words, it can be used to easily limit the number of I/O-bound promises running simultaneously. The emphasis is on the word I/O-bound; p-limit does not help with CPU-bound tasks since it does not magically make JavaScript multi-threaded.

Going back to our previous example, what we actually want to do is to run multiple file write operations in parallel and in the background, but avoid running too many to cause high memory peaks. p-limit solves this for us by allowing to specify the maximum number of concurrently run promises.

The right amount of concurrent operations depends on the use case and the capability of the underlying hardware. I would suggest beginning with a value of 2-6 and finding the sweet spot manually by testing with real-world data.

Let’s take a look at how to use p-limit, first doing it incorrectly.

import plimit from "p-limit";
const limit = plimit(4); // Allow up to 4 concurrent operations
const tasks = [];

// Naive example: assuming that files come from somewhere and `processFile` is implemented somewhere
for (const file of files) {
  const result = await processData(file);
  // BAD! Memory peak can still occur here.
  const task = limit(() => fs.promises.writeFile(result.path, result.data));
  tasks.push(task);
}

// Wait for all writes to complete
await Promise.all(tasks);

In this example, we are limiting the total number of simultaneous file operations, but we are NOT limiting calls to processData. This means that eventually all finished result objects would be queued to p-limit, potentially causing high memory peaks if the result object is large.

The can be solved by limiting both data processing and file writing:

import plimit from "p-limit";
const limit = plimit(4);
const tasks = [];

for (const file of files) {
  const task = limit(async () => {
    const result = await processData(file);
    return fs.promises.writeFile(result.path, result.data);
  });

  tasks.push(task);
}

// Wait for all processing + writes to complete
await Promise.all(tasks);

This is starting to look good as we are now allowing parallel data processing and file writing while still setting a limit of how many result objects can be created at once. Again, the gained performance largely depends on the relative speed of processData and file writing. In our case, this trick decreased the processing time from 40 seconds to about 30 seconds.

p-limit with Pending Queue

Let’s assume there are so many files to be processed that we need to divide them into multiple different processing functions. This would mean that we needed to use p-limit on multiple different places, possibly losing a track of overall concurrency and memory usage. Each plimit instance only controls the tasks submitted to it, not the total number of tasks running across all instances. This can easily lead to more tasks executing simultaneously than intended.

To manage this safely, we could use a single global concurrency limiter that all processing functions use, ensuring the total number of active heavy tasks never exceeds your safe threshold. Note that this method might not give actual performance benefits, but it helps to keep memory usage more predictable across the whole application.

Here is an example of introducing a centralized write queue using a single instance of plimit. When data has been processed, it can be queued for writing via enqueueWriteToFile function. This queue is allowed to hold no more than eight pending write operations, setting a clear limit for memory usage in the whole application. If the pending queue is full, the caller is forced to wait until there is free capacity available. Finally, up to four write operations are allowed to run in parallel.

import { promises as fs } from "fs";

import plimit from "p-limit";

const MAX_ITEMS_IN_PENDING_QUEUE = 8; // Allow up to 8 operations to wait in the queue
const writePool = plimit(4); // Allow up to 4 concurrent operations
const pendingWrites = new Set();

interface DataFile {
  path: string,
  data: string
}

function waitForFreeCapacityInPendingQueue() {
  return new Promise((resolve) => {
    const check = () => {
      if (writePool.pendingCount < MAX_ITEMS_IN_PENDING_QUEUE) {
        resolve(undefined);
      } else {
        // Wait until pending queue is free
        setTimeout(check, 10);
      }
    };

    check();
  });
}

async function enqueueWriteToFile(file: DataFile) {
  // Main thread waits here if pending queue is full
  await waitForFreeCapacityInPendingQueue();
  // Schedule the write operation and continue processing
  const task = writePool(() => fs.writeFile(file.path, file.data));
  pendingWrites.add(task);
  task.finally(() => pendingWrites.delete(task));
}

async function waitForFileWritesToComplete() {
  await Promise.all([...pendingWrites]);
}

async function main() {
  for (const file of importantFiles) {
    const processed = await processFile(file);
    await enqueueWriteToFile(processed)
  }

  for (const file of moreImportantFiles) {
    const processed = await processFile(file);
    await enqueueWriteToFile(processed)
  }

  await waitForFileWritesToComplete();
}

We have now solved the problem of running both data processing and file writing in parallel while also avoiding high memory peaks by limiting the number of pending write operations. However, we are still processing data sequentially, one file at a time. To make this more efficient, we are going to look at worker_threads module next.

Worker Threads

Node.js has worker_threads module, which enables true parallelism by running code inside Workers. This practically frees us from the single-threaded limitation of Node. Hooray, all performance problems solved! But there is a catch: running code in a worker is kind of like running another Node inside Node. Each worker has its own execution context, call stack, heap memory and event loop. This makes worker threads completely separated and also requires some effort to setup.

Since running a task in a Worker requires its own “Node”, initialising a Worker practically requires initialising it with its own script. Here is a simplified example:

First, we create the worker file and import processData from the main application:

// worker_types.ts
interface DataFile {
  path: string,
  data: string
}

// worker.ts
import { workerData, parentPort } from "node:worker_threads";
import { processData } from "data/process";
import { DataFile } from "./worker_types";

async function runWorker() {
  // Params from main thread
  const params = workerData as DataFile;
  const result: DataFile = await processData(params);
  // Send result back to the main thread
  parentPort?.postMessage(result);
}

// Run the worker
runWorker().catch(err => {
  parentPort?.postMessage({ error: err.message });
});

We can compile this worker using esbuild, with a command like this: npx esbuild src/worker.ts --bundle --outdir=dist --format=esm --platform=node.

Finally, we call the worker from the main thread:

// main.ts
import { fileURLToPath } from "node:url";
import { Worker } from "node:worker_threads";
import * as path from "path";

import { DataFile } from "worker_types";
import { enqueueWriteToFile } from "io/write_queue"; // From previous p-limit example

const filename = fileURLToPath(import.meta.url);
const dirname = path.dirname(filename);

function runWorker(params: DataFile) {
  return new Promise((resolve, reject) => {
    const worker = new Worker(path.join(dirname, "worker.js"), {
      workerData: params,
    });

    worker.on("message", async (result) => {
      console.log("Result from worker:", result);
      await enqueueWriteToFile(result);
      resolve();
    });

    worker.on("error", reject);
    worker.on("exit", (code) => {
      if (code !== 0)
        reject(new Error(`Worker stopped with exit code ${code}`));
    });
  });
}

async function main() {
  // Assuming file comes from somewhere
  const workerPromise = runWorker(file);
  
  console.log("Worker started, main thread is still responsive.");

  await workerPromise;
  console.log("Worker finished!");
}

This example shows how to offload a single computation from main thread to a dedicated worker while allowing main thread to be responsive and continue handling other tasks without being blocked. While this method works, it requires us to manually initialise a new Worker every time we want to process something in parallel. Also, the worker must be tuned to handle different data processing tasks. This process can be simplified by using a library called workerpool.

Worker Pool

Here is a simplified example of what workerpool looks like. First, we create a worker file which exposes the functions it can execute:

// worker.ts
import { processData } from "data/process"
import { DataFile } from "worker_types";

const workerpool = require('workerpool'); // Must use require

async function processDataFile(file: DataFile) {
  return await processData(file);
}

// Expose what functions this worker can execute
workerpool.worker({
  processDataFile,
});

Main looks like this:

// main.ts
const workerpool = require('workerpool');
import { DataFile } from "worker_types";
import { enqueueWriteToFile } from "io/write_queue";

const filename = fileURLToPath(import.meta.url);
const dirname = path.dirname(filename);

// Create a worker pool with as many workers as there are logical CPU cores
const pool = workerpool.pool(dirname + '/worker.js', {
  maxWorkers: require("os").cpus().length,
});

async function main() {
  try {
    // Assuming file comes from somewhere
    const result = await pool.exec("processDataFile", [file]);
    await enqueueWriteToFile(result);
  } catch (err) {
    console.error(err);
  }

  // Terminate all workers when everything is done
  pool.terminate();
}

workerpool takes the implementation of creating and calling workers to a higher abstraction level, simplifying code and also making it more efficient since workerpool keeps a pool of workers “warm”, ready to be used for offloading multiple long-running computations in the background. No need to manually create them every time.

In the above examples, we have offloaded only a single data processing task to the worker pool, but naturally we want to process all data in parallel. However, in heavily parallelized applications, we have to be careful of not offloading and queueing too many operations to workers at once and thus (again) introducing potential memory peaks - just like we need to be cautious with queuing too many I/O operations. Thus, I would be careful of calling pool.exec for every file at once since it could cause worker pool queue to overload of file parameters.

Worker Pool with Pending Queue

If one needs to limit the number of worker tasks to be queued, we would need to use some kind of pending queue to force the main thread to wait for a free worker to be available. A simplified example would look something like this:

const pendingTasks = new Set();
let queuedTasksCount = 0;

function waitForFreeWorker() {
  return new Promise((resolve) => {
    const check = () => {
      if (pendingTasks.size < NUMBER_OF_WORKERS) {
        resolve(undefined);
      } else {
        setTimeout(check, 10);
      }
    };
    check();
  });
}

async function enqueueWorkerTask(config: WorkerParams) {
  // Wait until there is a free worker available in the pool.
  await waitForFreeWorker();
  const task = pool.exec(config.task, [config.params]);
  pendingTasks.add(task);
  
  task.finally(() => {
    console.log("Worker task completed:", config.task);
    pendingTasks.delete(task);
  });
}

async function waitForWorkerTasksToComplete() {
  await Promise.all([...pendingTasks]);
  await pool.terminate();
}

By using a worker pool and p-limit together, we were able to reduce the total processing time from original 40 seconds down to about 14 seconds! This is a significant improvement, though it comes with increased code complexity and memory usage since each worker has its own memory space and we are keeping processed results in memory until they are written to disk.

Tips for Working with Workers

Whether you decide to use workerpool or implement your own solutions, here are a couple of tips I wish I had known when I started working with Workers:

You are free to import stuff from your main application code to your worker, but everything you import gets compiled in the final worker.js. This can result in large bundles and potentially unwanted code if not done carefully. For example, if you introduce a worker pool in your main application code, and you accidentally import some code from there in your worker, every worker gets its own worker pool. Probably not what you want. This can be avoided by doing import { isMainThread } from "worker_threads" and checking if isMainThread is false when ever something should never be imported by a worker.
Worker’s JS code must be built separately every time you modify it and always before running tests (I’m not happy remembering spending a day figuring out why some changes in my worker code did not do anything). If you use Vitest, you can use its setup.ts file to run code like execSync("npm run build:worker", { stdio: "inherit" }); to get a fresh worker every time before running tests.
Worker threads have their own isolated memory and cannot reference objects from the main thread (okay, there is SharedArrayBuffer, but it’s a bit advanced concept). When you instantiate a worker and pass in some parameters, these parameters are passed by value (i.e. structured clone), not by reference. Thus, one needs to be careful about high memory peaks when using workers.

Conclusion

Here is a quick summary of the tools we covered:

p-limit is ideal for managing concurrency in I/O-bound tasks, such as reading or writing files and making HTTP requests. By limiting the number of simultaneous operations, you prevent resource exhaustion and avoid hitting system limits. The code is only slightly more complex than standard async code, making p-limit a practical choice for many I/O-heavy workloads.

worker_threads is designed for CPU-bound tasks that would otherwise block the event loop, virtually any heavy data processing. Worker threads run in parallel, leveraging multiple CPU cores for true concurrency. However, using worker threads increases code complexity and memory usage, as each worker has its own execution context. Using it also requires some planning of how to actually divide complex computation into workers effectively and may not be sensible if tasks depend on each other. For heavy parallel data processing, I recommend taking a look at workerpool library.

Both p-limit and worker_threads are powerful tools for improving Node.js performance, but they serve different purposes and come with trade-offs. Even if these tools allow us to maximize performance by running things in parallel, one needs to be mindful of not fulfilling memory with a queue of tasks or cpu with too many simultaneous workers. Using either or both tools always increases code complexity and memory usage, potentially crashing your application if not managed carefully. Thus, it’s important to evaluate whether the performance gains justify these costs for your specific use case.

/dev/solita

What I Learned from Porting an Astro HTML Generator to Java with AI

Why Astro Wasn’t For Us

Planning the Porting

Porting Process

Findings After Initial Porting

Ensuring Code Quality

Verdict

Conclusion

An experiment in AI-augmented board game design

The idea

The Game Folder

The Agent Phase

The Publishing Phase

Diagram of the solution

How It Turned Out

What happens to Code Quality and Developer Role in the AI era

Background: The Coding Janitor

The Fundamental Change

Productivity Improves

Post Scriptum

AI Summary: How Have These Predictions Held Up? (February 2026)

The Source Code

MCP: Connecting Language Models to the Real World

Introduction: What is MCP?

Architecture Overview

Real-World Applications: What Can You Build?

Knowledge Base Integration

Flight Information System (Our Example)

Multi-Source Intelligence

Implementation: Flights MCP Server

Setting Up the Environment

Let’s get prompting

Under the Hood: How MCP Works

Transport Layer

JSON-RPC: The Communication Protocol

Closing Thoughts

Further exploration

SQL Isolation Levels

Isolation in Brief

MVCC

Isolation level 1: Read Uncommitted (Dirty Read)

Isolation level 2: Read Committed

3. Isolation level: Repeatable Read

4. Isolation level: Serializable

Interlude

Read Committed and locks

Thanks and further reading

Using Generative AI tooling with Clojure

Clojure is easy to read for humans and AIs

Clojure MCP boosts Agentic development workflows

Getting AI to speak Clojure

Further reading

Prompt Engineering 101

So What’s the Problem?

Context Is Everything

Just Use Planning Mode

Prompting Is a Skill

How Not to Get Overwhelmed

Conclusion

Python in 2026: Popular As Ever, Avoided in Production

Popularity

To Use or Not To Use

When its strengths become its weaknesses

Causality vs. Python: 1–0

Final words on enlightenment

Decoupling a Legacy Spring Boot Monolith with Branch by Abstraction

Here, There, Everywhere

Our Strategy: Branch by Abstraction

Introducing the Abstraction Layer: ProductService

Decoupling Product Data from the Database

Gradual Switchover to the ProductAPI

Quality Verification

Where We Are Now

Key Takeaways and Lessons Learned

Speed Up Data Processing in Node with p-limit and Worker Threads

Limiting Factors in Node

Processing Data Overview

p-limit

p-limit with Pending Queue