DEV Community: Maximilian Nussbaumer

DRY: Don't Repeat Yourself

Maximilian Nussbaumer — Wed, 17 Jun 2026 19:07:51 +0000

When we wrote code before large language models could write it for us, code duplication was rarely our problem, at least not if we worked alone or in a small team.

That has changed.

A principle born in a quieter time

"Don't Repeat Yourself" was coined by Andy Hunt and Dave Thomas in The Pragmatic Programmer back in 1999, a year when our biggest worry was whether the clocks would survive January. The idea is reassuringly simple. Every piece of knowledge in your system should have a single, unambiguous home. Write it once, point at it from everywhere else, go to lunch.

For those of us working alone or in small teams, DRY was almost automatic. You held the whole codebase in your head, all of it, including the parts you were ashamed of. When you needed to format a date, you remembered you already had a formatDate helper, because you had written it last Tuesday and were still slightly proud of it. Duplication was something that happened to other people, specifically large organizations where three teams could write three subtly different currency formatters and never once meet in a corridor.

Duplication, in other words, was a problem that scaled with headcount. The more humans you added, the more copies of everything you got.

Now everyone gets to have the problem

Here is the shift. An LLM writing code for you behaves rather like a brand new contractor who has never seen your project, is enormously eager to help, and has politely forgotten everything the moment they finish each task.

It does not know that formatDate already exists. It does not know your team solemnly agreed that all network calls go through apiClient. It does not know that the precise validation logic it is about to invent is sitting, fully tested, three folders away. So it does the friendly thing and writes some fresh code that works.

And it does work. The tests pass, the feature ships, the little green checkmark appears, everyone is delighted. You simply now own a fourth date formatter, a second and mildly incompatible API wrapper, and a button component that matches your design system the way a cover band matches the original.

The duplication problem used to scale with the number of people. It now scales with the number of generations. A single developer with an AI assistant can produce, before lunch, the sort of sprawl that once required an entire floor of the building.

Why models duplicate without meaning to

It helps to understand why this happens, mostly because it points directly at the fix. There are really three reasons, and none of them involve the model being foolish.

The first is context. The model only sees what you hand it, and your 200-file project does not fit through the letterbox. It cannot reuse a helper it has never been allowed to look at. The second is incentive. Generating new code is the thing models are good at and rewarded for, whereas reusing old code first requires finding the old code, an activity most setups make about as convenient as it sounds. The third is more human than you would expect. A self-contained block that compiles simply feels finished, and nothing about "finished" nudges anyone, silicon or otherwise, to go hunting for the canonical version that already exists.

Notice that all three are about memory, not intelligence. The model is not failing to reason. It is reasoning brilliantly about the tiny slice of the world you managed to fit in front of it.

What it quietly costs you

Duplication is not merely untidy. It is where bugs go to retire comfortably.

// payments/checkout.ts
function formatPrice(cents: number) {
  return `$${(cents / 100).toFixed(2)}`;
}

// invoices/render.ts, written by an agent two weeks later
function priceToString(amount: number) {
  return `$${(amount / 100).toFixed(2)}`; // same idea, fresh coat of paint
}

These two look harmless, almost charming. Then you launch in Europe, need euros and comma decimals, and confidently patch formatPrice. The invoices keep cheerfully printing dollars, because nobody alive remembers that priceToString exists. You have just shipped a production bug whose root cause is a duplication that no human ever actually decided to create.

Now run that forward across a year of helpful AI commits. The bill arrives as inconsistent behavior, as maintenance that has to be performed several times in several places by someone who can find all of them, and as the slow erosion of your belief that the codebase has one correct way to do anything. It stops having one, so the belief was right to leave.

What to actually do about it

You do not fix this by asking everyone to be more careful, which is the programming equivalent of asking the weather to be nicer. You fix it by giving whatever writes the code a way to know what already exists.

That is the entire reason I built DRY.codes.

DRY.codes indexes the repositories you connect, across your personal account and your organizations, and builds two things from them. The first is a fast, searchable memory of every file you have already written. The second is a precomputed map of where your code already repeats itself, file pairs ranked by how much they actually share. It then exposes all of it over the Model Context Protocol, which is the part that matters, because MCP is the letterbox through which your AI assistant finally gets to see the rest of the house.

So the contractor who forgets everything gets a memory. Before writing a new helper, an agent can search the knowledge base for one that already does the job. It can locate a file by name, compare two files to decide whether a near-duplicate is worth consolidating, and run a snippet through dry_wand to ask, in effect, "have we written this already?" The answer arrives before the duplicate does, which is the only time the answer is useful.

You can point it at a single repository or an entire organization to see the worst duplication hotspots and decide what to refactor first. You can keep shared configuration and utilities honest across dozens of projects at once. And if you live in Claude Code, the plugin wires this straight into your workflow with a "reuse before you write" reflex, so the search happens by default rather than by virtue. There is even a public corpus at dry.codes/mcp/public if you want to feel the idea before connecting anything of your own.

The point is not to scold the model. The point is to hand it the one thing it was missing.

The cheerful twist

DRY did not become less important when machines learned to write code. It became more important, and it became democratic. The duplication problem that used to belong exclusively to large organizations now belongs to anyone with an AI assistant and an afternoon.

The happy part is that the same tools generating all this duplication are perfectly capable of avoiding it, the moment you give them some memory of the code that is already sitting right there.

Write it once. Then make sure everything, human and machine alike, can actually find it. That last sentence used to be advice. With DRY.codes, it is just how the tooling works.

Follow quotentiroler on GitHub

Why MCP Apps are going to be the next big thing

Maximilian Nussbaumer — Mon, 04 May 2026 22:48:11 +0000

There's a quiet shift happening in how AI tools interact with users, and most developers haven't noticed yet, because just one week after the MCP Apps specs were published by Anthropic, OpenAI launched a huge marketing campaign around OpenClaw and they got all the attention, at least for a while.

For the past two years, every AI assistant has been stuck behind the same interface: a text box. You ask a question, you get text back. Maybe some markdown. Maybe a code block. Maybe an image.

Claude, GPT, Copilot, Gemini, every local model render into the same narrow pipe. MCP Apps change that.

What MCP Apps actually is

MCP Apps is a protocol extension that lets MCP tool results include interactive UIs. Actual interactive components running inside the AI host's sandbox.

The mechanics are straightforward:

Your MCP tool returns a structuredContent payload alongside the normal text content
The host loads a ui:// resource (an HTML page you provide) into a sandboxed iframe
The host forwards the tool result to your iframe via postMessage using a JSON-RPC 2.0 protocol (ui/* methods)
Your renderer mounts the UI inside the iframe
The UI can call tools back, send messages to the conversation, request display mode changes, and resize itself

The text content still serves LLM reasoning and hosts without rendering support. The UI is a progressive enhancement. Let's be honest: natural language is not always the most convenient or fastest way to express a desire. A click or a tap on a button can be much faster.

The spec behind it

The MCP Apps protocol (spec version 2026-01-26) is an official extension to MCP maintained by Anthropic. It defines a JSON-RPC 2.0 message layer over postMessage between a sandboxed iframe and its host. The spec covers:

Handshake: ui/initialize request/response with protocol version negotiation, app capabilities, and host capabilities
Lifecycle: tool-input, tool-result, tool-cancelled, tool-input-partial (streaming), host-context-changed, resource-teardown
Actions: ui/open-link, ui/message, ui/request-display-mode, ui/update-model-context, tools/call
Sizing: ui/notifications/size-changed (reactive, from app to host), ui/notifications/preferred-size (declarative hints)
Security: CSP via _meta.ui.csp on resource content items, Permission Policy for camera/microphone/geolocation/clipboard

The spec is deliberately renderer-agnostic. It defines how the host and the iframe talk to each other. What you put inside the iframe is entirely your choice. The host doesn't parse your component tree or validate your DOM structure. It sends you JSON-RPC messages and expects JSON-RPC messages back.

This is a deliberate design decision and the reason multiple rendering approaches can coexist. The Anthropic ext-apps SDK, a prefab renderer, a raw React app, a Svelte component -- all valid. The protocol doesn't care.

Current host implementations:

Host	Status	Notes
VS Code Copilot Chat	Shipping	Full spec support, CSP via `<meta>` tag, `acquireVsCodeApi()` transport
Claude Desktop	Shipping	Full spec support, CSP via HTTP headers on sandboxed origin (`{hash}.claudemcpcontent.com`). Can send results before init completes
ChatGPT	Shipping	Full spec support, CSP via HTTP headers on sandboxed origin (`{slug}.oaiusercontent.com`)

Three independent hosts shipping the same protocol make apparent that this is not a proposal, but infrastructure.

Why this matters

Here's the thing I think people are going to underestimate: this turns every MCP server into a full-stack application.

An MCP server is already a backend that exposes typed tools over stdio or HTTP. It already has access to databases, APIs, file systems. The only thing missing was a frontend.

Now it has on that lives inside the AI conversation, gets tool arguments and results pushed to it automatically, can call tools back on its own MCP server via the host, inherits the host's theme for free, and works across VS Code, Claude Desktop, ChatGPT, and anything else that implements the spec.

That last point is the critical one. Write once, render everywhere. The protocol is the same across hosts. The sandboxing model is the same. The postMessage bridge is the same.

Two different things driven by the same idea

MCP Apps is going to do to AI tooling what PWAs were supposed to do to mobile apps. PWAs were competing against native apps that users already loved. MCP Apps are filling a vacuum. There is no existing standard for rendering interactive UIs inside AI conversations. The alternative is pasting JSON into the chat. MCP Apps are going to be "AI Native Apps".

The bar is low. And the protocol is good enough.

What it looks like in practice

Here's a complete MCP tool that returns an interactive patient list with search, sorting, and click-to-view detail:

import { display, autoTable, Column, H1 } from '@maxhealth.tech/prefab'

async function listPatients(args) {
  const patients = await db.query('SELECT * FROM patients')
  return display(
    Column({ gap: 6 }, [
      H1('Patients'),
      autoTable(patients),
    ]),
    { title: 'Patient List' }
  )
}

display() wraps the component tree into the MCP wire format. The host renders it. The table is interactive -- search, sort, row selection -- without writing any frontend code.

But you don't even need to compose components. The auto-renderers infer the right UI from your data shape:

import { display } from '@maxhealth.tech/prefab/mcp'
import { autoTable, autoChart, autoForm, autoMetrics, autoDetail } from '@maxhealth.tech/prefab'

// Array of objects -> searchable, sortable table
return display(autoTable(patients))

// Array with numeric fields -> line/bar chart with axes and tooltips
return display(autoChart(salesData, { xAxis: 'month', title: 'Revenue' }))

// Schema fields -> validated form that submits back to an MCP tool
return display(autoForm([
  { name: 'name', label: 'Name', required: true },
  { name: 'email', label: 'Email', type: 'email' },
  { name: 'role', label: 'Role', type: 'select', options: ['admin', 'user'] },
], 'save_user'))

// Key-value object -> formatted detail card
return display(autoDetail({ name: 'Alice', status: 'active', lastSeen: '2026-04-30' }))

// Object with numeric values -> metric cards with labels
return display(autoMetrics({ patients: 1284, appointments: 47, waitTime: '12min' }))

Each auto-renderer picks columns, axes, labels, and formatting based on what it finds in the data. You pass an array or object, you get a production-quality UI back. When you outgrow them, you drop down to the component API and build exactly what you want.

And when you want to tweak the look without writing full custom components, every element accepts utility classes:

import { display, Column, H1, Badge, autoTable } from '@maxhealth.tech/prefab'

return display(
  Column({ gap: 6, cssClass: 'p-6 max-w-4xl' }, [
    H1('Patient Dashboard'),
    Badge({ label: '47 active', variant: 'success', cssClass: 'text-sm' }),
    autoTable(patients, { cssClass: 'rounded-lg shadow-md' }),
  ]),
  { title: 'Dashboard', layout: { preferredHeight: 600 } }
)

The built-in CSS ships ~200 Tailwind-compatible utility classes (padding, margin, flex, grid, gap, typography, colors, borders, shadows, max-height, overflow). No Tailwind dependency, no build step, no purge config. They're there in the 15KB stylesheet that the CDN serves alongside the renderer.

Three levels of control: auto-renderers for zero-config, utility classes for visual tweaks, full component API for complete custom UIs.

The HTML renderer is only 80kB in size and imported by a single script tag:

<div id="root"></div>
<script src="https://cdn.jsdelivr.net/npm/@maxhealth.tech/prefab@0.2/dist/renderer.auto.min.js"></script>

The protocol is the product

The real value is the protocol itself.

ui/initialize handshake. ui/notifications/tool-result for pushing data. ui/notifications/size-changed for responsive layout. ui/open-link for navigation. ui/message for sending messages back into the conversation. All JSON-RPC 2.0 over postMessage.

Anyone can build a renderer against this protocol. React, Svelte, vanilla JS, raw DOM manipulation. The host sends JSON-RPC messages to an iframe and expects JSON-RPC messages back. Your rendering stack is your business.

This is why I think MCP Apps will win where similar attempts failed. It's a host protocol that allows any rendering approach, and that makes adoption straightforward on both sides.

What's missing

It's early. The spec is dated 2026-01-26. Here's what's still rough:

CSP implementation varies by host. All hosts read _meta.ui.csp from the content item returned by readResource, but the enforcement mechanism differs. VS Code injects a <meta> tag. Claude Desktop and ChatGPT enforce via HTTP headers on a sandboxed origin. The spec standardizes the declaration format, but you should test your CSP config against each host you target.
No standard component format. The protocol defines the transport, the payload is up to you. Every renderer invents its own component schema. (We use a $prefab JSON wire format, but nothing stops someone from using entirely different components.)
Permission Policy support varies. Camera, microphone, geolocation, clipboard-write access via iframe allow attribute. Hosts report what they support in hostCapabilities.sandbox.permissions, but not all hosts honor all permissions yet.
Buffering and timing are tricky. Claude Desktop can send tool-result before the ui/initialize response arrives. If your renderer doesn't buffer, you lose the first result. This took us several hours to debug.

These are solvable problems. The architecture is sound.

The prediction

Within 12 months, we will see a market emerging around MCP Apps.

MCP Apps hosts will compete on rendering quality, theme support, and permission handling. MCP servers will compete on UI polish. And the protocol will quietly become the standard that holds it all together. MCP Hosts potentially replace the need for an internet browser.

Follow Max Health on GitHub

BDFL: Benevolent Dictator for Lobster - or - How I met Sam Altman

Maximilian Nussbaumer — Mon, 16 Feb 2026 08:05:47 +0000

What happens if you vibecode an open-source personal assistant that gets hyped? OpenAI might offer you a job and launch their biggest and most viral marketing campaign ever. Let me explain.

When the creator of OpenClaw, Peter Steinberger, came to San Francisco, the party at Frontier Tower was huge. They ordered lobster rolls and crabs for everyone. I had no chance to talk to him, but I met him on the next day at the OpenAI Codex Hackathon, where he was sitting together with some attendees. What I saw then concerned me: Within a few minutes, he gave out maintenance access to some people he never met before (including me), telling us to bring down the PR count. No onboarding, no guidance, no staging. One task: Merge PRs into main. When someone asked him a question, he had no time or patience to answer. This immediately showed signs of a toxic working environment. Heads were hiding behind the screens, the fear of being cut out took over within no time.

It is probably meant to be a bad joke that in the contribution guideline, there is no proper guidance on how to contribute. Instead, it shows the project owner as the "benevolent dictator". That's the credits Peter Steinberger gave to himself on January 2nd. What a New Year's resolution.

The benevolent dictator is a well-known pattern when there is a huge hype around one individual, and the "best practice" way to handle that situation is to re-assign authority to a board of people. It is truly difficult but necessary to handle this well, in order to minimize harmful consequences. "The best-case outcome is a BDFL who recognizes when to transition to a broader governance model before the drawbacks cause real damage." BDFL works when the project is small enough or the (benevolent) dictator is skilled enough to maintain genuine oversight. Neither is the case.

I walked away from that table where Peter was sitting at and met many other people instead. I met Sam Altman, but this was most likely not a coincidence. That hackathon was just the kick-off of their marketing campaign. Codex 5.3 was released on that day, and they want it to be used. Anthropic dominates code generation, Google dominates image generation. They grasp at every straw, trying to stay above water. OpenClaw is the card OpenAI played, and they bet a lot on it. Peter consistently promotes Codex over competing tools and dismisses MCP, and on February 15th it became official: Peter joins OpenAI as an employee.

Nevertheless, I accepted the invite to become an (unpaid) maintainer of OpenClaw. The first thing I did: I asked for staging after I saw that every PR gets directly merged into the main codebase, which is like turning screws on an airplane that is about to take off. It's obvious why that is considered "bad practice".

But Peter had no time to think about it. A few days later, I was the top contributor, and people started reaching out to me via email, pinging me in their PRs, asking for reviews, offering jobs, even on X! Not because I implemented staging or shipped features. Because I removed garbage. "Your contributions to openclaw/openclaw caught my attention and I wanted to reach out."

The Problem

Over tens of thousands GitHub Actions minutes burned in a few days. Failed builds, redundant test runs, CI churn from missing gates. I found many files with thousands of lines of code, and hundreds of duplicate functions across the codebase. Both identical functions and slight variations of the same logic, written by AI agents that had zero awareness of what already existed. No human actually knows this codebase. It is being vibecoded with minimal human oversight.

How This Happens

It's a simple, cancerous loop:

AI agent gets a task
It writes code that "works", meaning it passes the immediate test and satisfies the prompt
Nobody checks whether the code duplicates existing functionality
Nobody notices the file went from 3,000 lines to 5,300
It gets merged
Repeat a thousand times

The LLM does not know that a nearly identical helper function already exists 1,000 lines above, or in the next module over, if it is not told to look for it. It solves the problem in front of it and moves on. Like a living cell that reproduces without control. When you put the human out of the loop, the codebase grows in volume, but decays in quality. The only critic is now satisfaction. "Did I get what I wanted?" If not, then the AI has to iterate further until I get what I wanted.

Security concerns are more than valid when people tend to value hype over a reality check. If you wonder how OpenClaw is being released: Once every few days, Peter takes whatever code is currently in the main branch, and creates a new release. Sometimes he writes "YOLO" in the maintainer chat while doing it.

Like the other day, when a maintainer bulk-merged a couple of PRs into main, Peter released it, cron jobs broke, and Elon Musk made fun of OpenClaw on X. Welcome to OpenClaw!

What I Did

The boring stuff nobody wants to do. I went through the codebase and identified duplicate and near-duplicate functions. Consolidated shared logic into reusable helpers. Broke apart files that had no business being thousands of lines long. Set up a quality gate so new submissions actually get reviewed for duplication and structural fit before they land on main. Enabled typechecking for modules. The codebase got smaller and more maintainable and CI stopped choking on broken builds.

The Response

When I asked for staging, I noticed why a toxic working environment should be avoided: People are scared to say the opposite of what the benevolent dictator will say then. Being rejected by the benevolent dictator will devalue the position of the proposer, so there is no proposal against the narrative, and the narrative is "we accept AI generated code of any kind".

When I put stricter quality gates in place, some people were not happy about it. Velocity matters more than quality. Ship fast, do not clean up. I see this pattern forming across the AI-assisted open source ecosystem. The pressure to merge PRs and ship features actively punishes the people doing real code maintenance work.

I also gave credits to the contributors based on their actual contributions. Another maintainer, who attacks people for pinging him on github or permabans them from contributing, reverted the change and gave me the choice to shut up or leave. I thought about it for a day, and decided to leave and share my experiences.

2 days later, the code quality gate I installed which prevented new duplicate functions from being introduced and code files from growing endlessly has already fallen. In commit/c2178.., it was removed for being "useless", when the gate has already saved thousands of CI minutes while preventing duplicate code from being merged.

Peter's take? Well, he did not respond at all, which is typical for a benevolent dictator. Our only conversation took about 2 minutes, when he gave me maintenance access. Still, on February 14th, he assigned an army of agents both locally and in the cloud to continue with the refactorings and deduplications I started.

The Numbers

Snapshot	Date	Files	Total LOC	Duplicate function names
Before CI gate removal	Feb 12	3,840	694,527	415
Before Peter's sweep	Feb 13 (end of day)	4,052	731,516	429
After sweep	Feb 14	4,166	741,598	419

So the duplicates went up from 415 → 429 between Feb 12-13 (new code was being added faster than dedup was happening), and Peter's sweep on Feb 14th brought it back down from 429 → 419, meaning new duplicates are being introduced while Peter is cleaning them up. He's swimming against the current, but his approach is not sustainable. It is just not possible to outsource all thinking to multi-agent systems. The consequence is digital cancer.

Instead of wasting more tokens and energy, Peter could just re-enable the simple but highly effective code quality gate and pay naturally intelligent humans to clean up. In fact, Peter's artificially intelligent agent swarm is still refactoring non-stop, and brought duplicate functions down to 378. That took him 637 commits, which is very inefficient.

The Bigger Question

I believe AI should be more accessible to everyone. That is the stated mission of projects like this. But accessibility without oversight produces exactly what I found: AI-made codebases that are not maintainable without AI. AI making humans depend on it. This might be the first step of AI taking over.

AI does not need a dictator and his loyal doormats. It needs real human oversight and people who speak up. This project is dangerous, not because of AI, but because hype is dangerous, benevolent dictators, and people in charge riding the hype train while hiding behind pseudonyms. All world plays along, branding events and articles with crabs and lobsters, just because it sells. I am scared of the consequences of this carelessness, and I cannot be part of it.

What makes this more urgent is that governments are now actively discussing the use of code that is one big chaos. Legislators and procurement officers are evaluating tools built on codebases where significant portions were generated by AI, reviewed by AI, and merged with minimal human scrutiny. That should demand a higher standard of transparency, not a lower one. Yet many of the people contributing to and shaping these projects operate under pseudonyms. When software influences public infrastructure, healthcare systems, or democratic processes, the public has a right to know whether anyone with real accountability is actually reading the code. Anonymity has its place in open source, but accountability cannot be optional when the stakes are this high.

What's Next?

Obvious human carlessness is the first step of losing control. If only AI knows how the code works that drives AI, AI is taking over, maybe in the form of a lobster, or a crab, or digital cancer. OpenClaw is not unique - everybody can vibecode their personal assistant now. Every digital idea can be copied and implemented within no time. The world is about to change drastically. Still, I am not losing hope, instead, I built RepoWatch.

This tool points out obvious code quality issues, lists contributors and uses various traditional algorithms to detect duplicate code across PRs. It is derived from an old uni project I made before AI was a thing, where I had to find potential plagiarism in 50 code submissions made by other students. Back then, I did some research and implemented my interpretation of document fingerprinting. I am sure that similar ideas will become more important in the future in order to prevent duplicate data from being processed. My tool aims to bring clearance and transparency so that not only AI can understand code, but also humans, as well as open standards and metrics to determine the uniqueness and consistency of a codebase.

This is Peter's description on X:

Let's shell that lobster and prevent digital cancer from taking over the world!