DEV Community: Jonas Gauffin

Who Pays for the AI Boom?

Jonas Gauffin — Sun, 25 Oct 2026 00:00:00 +0000

The main bottleneck for AI replacing white-collar work at scale is that the best models are large and expensive to run. Every step up in capability costs a lot more compute, both in training and in inference. You can distill or quantize a model into something smaller and cheaper, but you lose reliability, and reliability is exactly what you need before a model can replace an employee instead of assisting one.

At the same time, the models are getting good at research. In October, OpenAI released 372 results on open mathematical problems, produced with an average of three hours of ChatGPT Pro compute each. One of them targets part of Hilbert's sixteenth problem, which has been open since 1900. Mathematicians are still reviewing the results and some won't hold up, but even if only a fraction survive, a model is now doing original research on problems humans have left unsolved.

The labs use their best models to build the next generation. It's only a matter of time before that loop produces architectures that fundamentally change how models are built. It has happened before: in 2017 the transformer replaced recurrent networks such as the LSTM, which had been the go-to architecture for sequence modelling for 20 years. When the next shift comes, it will move very fast, because the compute to exploit it is already racked in the data centres.

Blue-collar work is next. My guess is that jobs like warehouse work, factory work and tyre fitting go first. Robots taking them over face two blockers: unit cost, and models that can handle the physical world, which requires training data from real robots. Given how robotics has progressed over the past year, cost is on its way to being solved, and every robot put into production generates more training data. It's a flywheel.

The money behind it

AI capex is now one of the largest private investment waves in US history. By most estimates, only the railroad boom of the late 1800s (peak years at around 5–6% of GDP) and residential investment before the financial crisis (6.6% of GDP in 2005) were larger. The telecom and fibre build-out of the dot-com era, around 1.2% of GDP, is already well behind.

What's different this time is concentration. The railroads were built by hundreds of companies; AI infrastructure is being built by a handful of hyperscalers and labs. The largest tech companies' capex from 2023 through their 2026 budgets comes to roughly $1.5–1.6 trillion, and consensus expects hyperscaler capex alone to stay at about 3% of US GDP every year from 2027 to 2029.

So ask yourself: how do the investors expect to get a return on that? Through new services that benefit everyone, or through cost savings, which in practice means headcount reductions and wage pressure?

We need laws and regulation that protect people, not just the return on capital.

Tips to junior developers, now that a coding agent writes the code

Jonas Gauffin — Thu, 22 Oct 2026 00:00:00 +0000

In 2017 I wrote four tips to junior developers. Your application is never done. Don't judge other people's code. Never fix a bug until you understand why it happens. Fast programmers aren't necessarily better programmers.

They still hold. But every one of them was about the code you type yourself, and today a coding agent does most of the typing. It writes faster than any of us ever did, and it never gets tired of boilerplate. So the question for a junior is no longer how to write the code. It's how to tell whether the code that was written is any good, and how to build a code base where the coding agent finds its own mistakes.

That takes a different set of skills. Here they are.

Learn architecture before syntax

A coding agent can write a function in any language you ask for. What it can't do on its own is decide where that function belongs.

That's architecture: which part of the system owns a concept, what may depend on what, and where the boundaries go. Get it right and a change touches one folder. Get it wrong and every feature is an edit across ten files, which the coding agent will happily make, and which nobody can review.

So learn to read a structure, not a line. Why is business logic kept apart from data access? Why organise by feature instead of by technical layer? What happens to a code base when everything can call everything? A junior who can answer those questions can review a coding agent's work. A junior who only knows the syntax can check that it compiles, and the compiler already does that.

Learn how the whole solution fits together

Above the code base sits the solution: the services, the database, the queue, the third-party API, the background job. Most production problems live in the seams between them. A timeout nobody chose. A message processed twice. A database transaction that commits after the response was already sent.

A coding agent writes each piece correctly in isolation and has no idea how they behave together under load or failure, unless someone designed for it. Learn what happens when each piece is slow, down or answers twice. That is where your judgement is needed, because it's exactly where the coding agent has none.

Know what every pattern costs

When I started, learning a pattern felt like collecting a tool. Repository, unit of work, inheritance, events, dependency injection. The more you knew, the better.

Patterns aren't free. Each one buys something and costs something, and the cost usually shows up later, in someone else's hands. A generic repository saves a few lines and leaks the database into the domain. A base class saves duplication and forces every reader to open two files to understand one. Events decouple senders from receivers, and make it impossible to see from the code what happens when you send one.

A coding agent knows every pattern, and has no opinion on when one is a mistake. Ask it for a clean architecture and it will give you one with all the layers, whether your problem needs them or not. Your job is to know the consequences: what a principle protects you from, and what it costs when there is nothing to protect.

Learn to measure quality

"It works" is the only thing a coding agent's output reliably is. Whether it's maintainable is another question, and you can't answer it with a feeling.

So learn how quality is measured. How complex a function is, and when it's too complex to follow. How big a file or a type may grow before nobody can hold it in their head. Which duplication actually costs you and which is harmless. And above all, what a test proves: a test written from the code asserts what the code already does and breaks on every refactoring, while a test written from a business rule fails exactly when the rule breaks. I wrote more about that in How do you know the agent isn't quietly rotting your codebase?

Numbers don't replace judgement, but they tell you where to point it.

Learn error management, properly

This is the one I would put first.

When I coded everything myself, every reported error hurt. It interrupted what I was doing, it usually came with too little information, and I had to dig through logs and a debugger to work out what happened. It was tempting to make errors go away: catch the exception, log something vague, return a default and move on.

With a coding agent, that changes completely. Every error that is reported is a gift. The coding agent reads the message, finds the line and fixes it, often in the same run. An error that is swallowed is the opposite: the coding agent can't see it, so it can't fix it, and it carries on building on top of a broken assumption.

Compare these two:

InvalidCastException: Unable to cast object of type 'System.Int64' to type 'System.Int32'.


Column 'age' is Int64, not Int32.

The first one sends the coding agent guessing through every cast in the file. The second one names the column and the types, and the fix is one line. The difference isn't the coding agent. It's the person who designed the error.

So learn what exceptions are for, and be strict about them:

Fail when a function can't do what its name promises. Don't return null or a default and hope the caller checks. A failure that happens far from its cause is the most expensive kind to find.
Fail early. Check arguments and state where they enter, not three calls later where they blow up.
Put the context in the message. Which value, which entity, what was expected. Write it for a reader who sees nothing but the message, because the coding agent is exactly that reader.
Never swallow an exception. An empty catch block is a bug. If you can't recover, let it pass.
Only catch where you can do something. Recover, or add context and pass it on. Everything else is caught once, at the top, and reported.
Keep the original. Wrap it as the inner exception, so its stack trace survives.

I wrote about this more than ten years ago, in What are exceptions?, How to design exceptions and Throwing exceptions. Back then, strict error handling saved you hours of debugging. Now it decides whether a coding agent can fix its own mistakes, or has to wait for you to find them.

The old tips, revisited

Your application is never done. Still true, and it changes faster than ever. A code base that a coding agent changes every day needs boundaries that hold, or it decays one reasonable change at a time.

Don't judge other people's code. Still true. Now some of that code is the coding agent's, and judging it is your job. Judge it against rules you can name, not against taste.

Never fix a bug until you understand why it happens. Still true, and now it's also about the system. If you had to dig to find the cause, the next bug will hide the same way. Fix the bug, then fix the error that should have told you.

Fast isn't better. The coding agent is fast. Your value is in knowing where it's going.

The new four

If I had to put it on a sticky note today:

Learn where code belongs, not just how to write it.
Know what every pattern costs before you use it.
Measure quality instead of feeling it.
Make every error loud, early and precise. A reported error is the fastest feedback a coding agent can get.

ADO.NET, the right way (reloaded)

Jonas Gauffin — Wed, 21 Oct 2026 00:00:00 +0000

In 2013 I wrote ADO.NET, the right way. The point was that plain ADO.NET, with a couple of extension methods, is a fine alternative to an ORM. I still think so. But the code in that post was written for a human who runs the app, steps through it in a debugger and remembers how the pieces fit.

Today, much of my data access code is written by a coding agent. A coding agent reads files and greps names. It rarely runs the app, and it never watches the console. Everything it learns comes from the code it opened, the compiler and the test run. So I went back to the old article and asked one question of every piece: when the coding agent gets this wrong, who tells it?

This article is about the foundation: the part of a Data project everything else builds on. How to run SQL, read results, own the transaction, where the abstractions go and how to test it. Queries versus commands, and where repositories fit, come in the next articles.

You don't need to know ADO.NET to follow along. The comments in the code explain its quirks as they come up.

ADO.NET in one paragraph

ADO.NET is the database API built into .NET. Every database has a provider (Npgsql for PostgreSQL, Microsoft.Data.SqlClient for SQL Server, and so on) that implements the same abstract classes from System.Data.Common: a DbConnection to the database, a DbTransaction on it, a DbCommand holding SQL and its parameters, and a DbDataReader to walk through the rows a query returns. Write your code against those base classes, and only the line that picks the provider knows which database you use. That's all of ADO.NET this article needs.

The Data project

MyApp.Domain/ business rules, and the interfaces they need from storage (next article)
MyApp.Data/
    Foundation/ the extensions and the request transaction (this article)
    Users/ the SQL for users, one folder per feature
MyApp.Data.Tests/ tests against a real database
MyApp.Web/ picks the provider, registers everything, commits the request

Three guidelines decide what goes where.

The Data project references no provider and no ASP.NET Core. It uses System.Data.Common, which is part of .NET, and the dependency injection abstractions. The web project picks the provider and owns the commit filters. The C# stays provider-neutral; the SQL doesn't, and there's no point pretending otherwise.

No abstractions over ADO.NET. No IDbConnectionFactory, no IUnitOfWork, no generic IRepository<T>. DbTransaction and DbCommand are already abstract classes, so wrapping them in interfaces adds a layer the coding agent must open without adding anything it can check. The seam for unit tests is somewhere else: the interfaces the domain declares for what it needs from storage, implemented in the Data project. Business logic is unit tested against fakes of those. The Data project itself is tested against a real database.

Organize by feature, not by layer. Users/ holds every SQL statement about users. Foundation/ is the only folder every feature uses.

The API

Eight extension methods. That's the whole foundation:

// Commands
DbCommand CreateCommand(this DbTransaction transaction, string sql)
void AddParameter(this DbCommand command, string name, object? value)

// Columns
T Get<T>(this DbDataReader reader, string column)
T Get<T>(this DbDataReader reader, int ordinal)

// Rows
Task<List<T>> ToList<T>(this DbDataReader reader, Func<DbDataReader, T> map)
IAsyncEnumerable<T> ToEnumerable<T>(this DbDataReader reader, Func<DbDataReader, T> map)
Task<T?> FirstOrDefault<T>(this DbDataReader reader, Func<DbDataReader, T> map)

// The request's transaction
IServiceCollection AddRequestTransaction(this IServiceCollection services)

It is small on purpose. The entire API fits in the coding agent's context next to the code it is changing. Dapper or EF Core can't say that, and a coding agent that knows every method it may call doesn't invent one.

Running the SQL is still plain ADO.NET: ExecuteReaderAsync for rows, ExecuteNonQueryAsync for changes, ExecuteScalarAsync for a single value. Nothing new to learn there.

Using it

This class shows the foundation in use. Whether it should be a query, a repository or something else is the topic of the next article.

public sealed class Users(DbTransaction transaction)
{
    // Map reads by position, so every query it reads selects exactly these columns, in this order.
    private const string Columns = "id, company_id, first_name, age";

    public async Task<User?> Get(int id)
    {
        // The SQL refers to the parameter as @id. Never paste a value into the SQL string:
        // a parameter is sent separately from the SQL, so it can't change what the SQL does.
        await using var command = transaction.CreateCommand($"SELECT {Columns} FROM users WHERE id = @id");
        command.AddParameter("id", id);

        // A reader keeps the connection busy until it's disposed: one open reader per connection.
        await using var reader = await command.ExecuteReaderAsync();
        return await reader.FirstOrDefault(Map);
    }

    public async Task<List<User>> FindByCompany(int companyId, string firstName)
    {
        await using var command = transaction.CreateCommand(
            $"SELECT {Columns} FROM users WHERE company_id = @company_id AND first_name LIKE @first_name ORDER BY first_name");
        command.AddParameter("company_id", companyId);

        // The wildcard belongs in the value, not in the SQL.
        command.AddParameter("first_name", firstName + "%");

        await using var reader = await command.ExecuteReaderAsync();
        return await reader.ToList(Map);
    }

    public async Task<int> Add(int companyId, string firstName, int? age)
    {
        // RETURNING is PostgreSQL; SQL Server writes OUTPUT INSERTED.id. The SQL is per database.
        await using var command = transaction.CreateCommand(
            "INSERT INTO users (company_id, first_name, age) VALUES (@company_id, @first_name, @age) RETURNING id");
        command.AddParameter("company_id", companyId);
        command.AddParameter("first_name", firstName);
        command.AddParameter("age", age);

        // ExecuteScalarAsync returns the first column of the first row, as an object.
        return (int)(await command.ExecuteScalarAsync())!;
    }

    public async Task Update(User user)
    {
        await using var command = transaction.CreateCommand(
            "UPDATE users SET company_id = @company_id, first_name = @first_name, age = @age WHERE id = @id");
        command.AddParameter("company_id", user.CompanyId);
        command.AddParameter("first_name", user.FirstName);
        command.AddParameter("age", user.Age);
        command.AddParameter("id", user.Id);

        // Returns the number of rows changed, which is how you notice an id that doesn't exist.
        await command.ExecuteNonQueryAsync();
    }

    private static User Map(DbDataReader reader) => new(
        reader.Get<int>(0),
        reader.Get<int>(1),
        reader.Get<string>(2),
        reader.Get<int?>(3));
}

(Columns is a constant, which is why it may be interpolated into the SQL. Values never are. The column names are lower case with underscores because PostgreSQL folds unquoted names to lower case. That style works in every database.)

Read it as the coding agent does:

Grep first_name and you land on the column list, the WHERE, the INSERT, the UPDATE and the parameters. Every place the column is read or written.
Add a property to User and its constructor changes, so Map stops compiling. A mapper that sets properties simply forgets the new one.
No base class. Everything the class does is in this file.
The transaction is a constructor parameter. A command can't be created outside it, and there is no Commit to forget.

Commands

public static class DbCommandExtensions
{
    public static DbCommand CreateCommand(this DbTransaction transaction, string sql)
    {
        // A transaction forgets its connection once committed or rolled back.
        var connection = transaction.Connection
            ?? throw new InvalidOperationException("The transaction has already been committed or rolled back.");

        var command = connection.CreateCommand();

        // A command doesn't join the connection's transaction by itself. SqlClient throws when this
        // is missing, Npgsql doesn't need it. Always set it, and the code works with both.
        command.Transaction = transaction;
        command.CommandText = sql;
        return command;
    }

    public static void AddParameter(this DbCommand command, string name, object? value)
    {
        var parameter = command.CreateParameter();
        parameter.ParameterName = name;

        // ADO.NET doesn't send null as NULL. A database NULL is DBNull.Value, both ways.
        parameter.Value = value ?? DBNull.Value;
        command.Parameters.Add(parameter);
    }
}

CreateCommand lives on the transaction, not on the connection. That makes forgetting command.Transaction impossible, which matters because SQL Server and PostgreSQL disagree on what happens when you do.

Reading columns

Get<T> replaces the casts like (int)reader["age"] that ADO.NET code is full of, and is where the coding agent most needs a good error.

public static class DbDataReaderExtensions
{
    public static T Get<T>(this DbDataReader reader, string column)
    {
        int ordinal;
        try
        {
            // Looks the name up among the result's columns, on every call.
            ordinal = reader.GetOrdinal(column);
        }
        catch (IndexOutOfRangeException ex)
        {
            throw new InvalidOperationException($"The result has no column '{column}'. Its columns are: {ColumnsOf(reader)}.", ex);
        }

        return reader.Get<T>(ordinal);
    }

    public static T Get<T>(this DbDataReader reader, int ordinal)
    {
        // A NULL column reads as DBNull.Value, not null, so ask before reading.
        if (reader.IsDBNull(ordinal))
        {
            // Nullable value types and reference types come back as null.
            if (default(T) is null)
                return default!;

            throw new InvalidOperationException($"Column '{reader.GetName(ordinal)}' is NULL. Read it as Get<{NameOf(typeof(T))}?>.");
        }

        // The value comes in the type the provider picked: a PostgreSQL bigint is a long, never an int.
        var value = reader.GetValue(ordinal);
        if (value is T typed)
            return typed;

        throw new InvalidCastException($"Column '{reader.GetName(ordinal)}' is {value.GetType().Name}, not {NameOf(typeof(T))}.");
    }

    private static string ColumnsOf(DbDataReader reader) =>
        string.Join(", ", Enumerable.Range(0, reader.FieldCount).Select(reader.GetName));

    private static string NameOf(Type type) =>
        Nullable.GetUnderlyingType(type) is { } underlying ? underlying.Name + "?" : type.Name;
}

Every failure names the column. A misspelled name lists the columns that do exist. A wrong type says which type the database returned. A NULL in a non-nullable read says exactly what to write instead. The coding agent reads the message and fixes the right line, instead of guessing.

NULL is decided by the type you ask for: Get<int?> and Get<string> return null, Get<int> throws. One method, no GetNullable beside it. The price: string and string? are the same type at runtime, so Get<string> can't refuse a NULL. Let the constructor of your entity refuse it, if that matters.

By name or by position? Reading by position skips the name lookup for every column of every row, which shows in tight loops. The risk is that position couples Map to the order of the SELECT. That's what the Columns constant is for: the order lives in one place, right above the mapper, and every query Map reads uses it. A coding agent reordering a column sees both on the same screen. And when a position is wrong anyway, the error still names the column, through GetName.

Reading rows

Three extension methods take the mapper and do the loop:

public static async Task<List<T>> ToList<T>(this DbDataReader reader, Func<DbDataReader, T> map)
{
    var items = new List<T>();

    // A reader starts before the first row. ReadAsync moves to the next one, and returns false after the last.
    while (await reader.ReadAsync())
        items.Add(map(reader));

    return items;
}

public static async Task<T?> FirstOrDefault<T>(this DbDataReader reader, Func<DbDataReader, T> map)
{
    return await reader.ReadAsync() ? map(reader) : default;
}

public static async IAsyncEnumerable<T> ToEnumerable<T>(this DbDataReader reader, Func<DbDataReader, T> map)
{
    while (await reader.ReadAsync())
        yield return map(reader);
}

ToList is the default. ToEnumerable streams, for results you don't want in memory, and it has a trap the compiler won't catch:

// Compiles. Fails at runtime: the reader is disposed before anyone enumerates.
public async Task<IAsyncEnumerable<User>> All()
{
    await using var command = transaction.CreateCommand($"SELECT {Columns} FROM users");
    await using var reader = await command.ExecuteReaderAsync();
    return reader.ToEnumerable(Map);
}

The method has to be an iterator itself, so the reader lives as long as the enumeration:

public async IAsyncEnumerable<User> All()
{
    await using var command = transaction.CreateCommand($"SELECT {Columns} FROM users");
    await using var reader = await command.ExecuteReaderAsync();
    await foreach (var user in reader.ToEnumerable(Map))
        yield return user;
}

There is a second trap. All commands in a request share one connection, and an open reader blocks it. Run another command while you enumerate, and the provider refuses. (SQL Server allows it only with MARS switched on, PostgreSQL not at all.) So: stream to the response, and do nothing else with the database until you're done.

One transaction per request

Every web request gets one transaction. It's created the first time something asks for it, committed when the request succeeded, and rolled back otherwise.

public sealed class RequestTransaction(DbDataSource dataSource) : IAsyncDisposable
{
    private DbConnection? _connection;
    private DbTransaction? _transaction;
    private bool _committed;

    public DbTransaction Begin()
    {
        if (_transaction != null)
            return _transaction;

        // Connections are pooled: opening one usually takes an idle connection from the pool,
        // and disposing it hands it back. A DI factory can't await, so this is the one synchronous open.
        _connection = dataSource.OpenConnection();
        _transaction = _connection.BeginTransaction();
        return _transaction;
    }

    public async Task Commit()
    {
        if (_transaction == null || _committed)
            return;

        await _transaction.CommitAsync();
        _committed = true;
    }

    public async ValueTask DisposeAsync()
    {
        if (_transaction == null)
            return;

        if (!_committed)
            await _transaction.RollbackAsync();

        await _transaction.DisposeAsync();
        await _connection!.DisposeAsync();
    }
}

public static class RequestTransactionRegistration
{
    public static IServiceCollection AddRequestTransaction(this IServiceCollection services)
    {
        services.AddScoped<RequestTransaction>();
        services.AddScoped<DbTransaction>(provider => provider.GetRequiredService<RequestTransaction>().Begin());
        return services;
    }
}

Classes in the Data project ask for DbTransaction, a type every .NET developer and every model already knows. RequestTransaction is only there so the commit step can ask "did this request touch the database?" without opening a connection to find out. A request that never asks for a DbTransaction costs nothing.

DbDataSource is where connections come from. It's the base class of NpgsqlDataSource, and a provider without its own data source gets one from its factory, such as SqlClientFactory.Instance.CreateDataSource(connectionString). The provider is chosen by a line of code you can grep, not by a name in a config file.

Committing

The rule: commit when the handler finished without an exception, the model state is valid and the response isn't an error. Anything else rolls back when the request's services are disposed.

When to commit matters more than it looks. Middleware that commits after await next() is too late: the response may already be on its way, and a client can see success for a commit that then fails. Commit after the handler, before the result is written. That's a filter, and filters belong to the web project.

For minimal APIs, an endpoint filter:

public sealed class CommitRequestTransaction(RequestTransaction transaction) : IEndpointFilter
{
    public async ValueTask<object?> InvokeAsync(EndpointFilterInvocationContext context, EndpointFilterDelegate next)
    {
        // An exception from the handler passes straight through, so nothing is committed.
        var result = await next(context);
        if (result is not IStatusCodeHttpResult { StatusCode: >= 400 })
            await transaction.Commit();

        return result;
    }
}

For controllers, an action filter:

public sealed class CommitRequestTransactionFilter(RequestTransaction transaction) : IAsyncActionFilter
{
    public async Task OnActionExecutionAsync(ActionExecutingContext context, ActionExecutionDelegate next)
    {
        var executed = await next();
        if (executed.Exception != null || !executed.ModelState.IsValid)
            return;

        if (executed.Result is not IStatusCodeActionResult { StatusCode: >= 400 })
            await transaction.Commit();
    }
}

Invalid model state doesn't commit. A form that fails validation is usually shown again with a 200, so the status code alone would let a half-done change through. And an exception that a filter has handled still doesn't commit. Something went wrong, and the data shouldn't pretend otherwise.

Minimal APIs have no model state. Validation that fails there answers with a 400 problem result, which the status check already catches.

Wiring it up

builder.Services.AddSingleton<DbDataSource>(NpgsqlDataSource.Create(builder.Configuration.GetConnectionString("MyApp")!));
builder.Services.AddRequestTransaction();
builder.Services.AddScoped<Users>();

// Minimal APIs
builder.Services.AddScoped<CommitRequestTransaction>();
var api = app.MapGroup("/api").AddEndpointFilter<CommitRequestTransaction>();

// Controllers
builder.Services.AddControllers(options => options.Filters.Add<CommitRequestTransactionFilter>());

"Isn't that invisible magic?" The commit isn't in the code that changes the data, true. But nothing happens behind the scenes: you registered it, on a line you can grep, and the rule fits in a sentence. Compare that with a SaveChanges() call in every service method, where the failure mode is a forgotten call that compiles, passes review and loses data.

Outside a request (a background job, a message handler), there is no filter. Create a scope, do the work, and call Commit() yourself:

await using var scope = services.CreateAsyncScope();
var users = scope.ServiceProvider.GetRequiredService<Users>();
// ...
await scope.ServiceProvider.GetRequiredService<RequestTransaction>().Commit();

Testing it

The Data project is tested against a real database, never against fakes of DbCommand or DbDataReader. A fake reader proves that the fake works. It can't tell you that PostgreSQL returns a long, that your SQL has a typo, or that a column is NULL.

A database for the tests

The test database runs in a container on your machine and in the build. It doesn't have to survive a crash, so switch off everything that makes a database wait for the disk:

docker run -d --name myapp-test-db -p 5433:5432 \
    -e POSTGRES_PASSWORD=test -e POSTGRES_DB=myapp_test \
    --tmpfs /var/lib/postgresql/data \
    postgres:17 -c fsync=off -c synchronous_commit=off -c full_page_writes=off

--tmpfs keeps the data in memory. Nothing touches the disk, and restarting the container gives you an empty database.
fsync=off, synchronous_commit=off and full_page_writes=off stop PostgreSQL from waiting for its log to reach the disk on every commit. In production that would lose data on a crash. In a test database, losing data is fine.

None of this goes in the connection string. How hard a database works to keep its transaction log safe is a setting of the server (PostgreSQL) or of the database (SQL Server), not of the connection. SQL Server can't switch its log off at all, but two settings come close:

docker run -d --name myapp-test-db -p 1434:1433 \
    -e ACCEPT_EULA=Y -e MSSQL_SA_PASSWORD='Test-1234!' \
    mcr.microsoft.com/mssql/server:2022-latest


CREATE DATABASE myapp_test;
-- Simple recovery: the log is reused instead of kept for backups, so it doesn't grow.
ALTER DATABASE myapp_test SET RECOVERY SIMPLE;
-- A commit returns before its log record is on disk.
ALTER DATABASE myapp_test SET DELAYED_DURABILITY = FORCED;

The tests find the database through an environment variable, and skip when it isn't set, so the suite still runs on a laptop without Docker:

MYAPP_TEST_DB="Host=localhost;Port=5433;Database=myapp_test;Username=postgres;Password=test;Include Error Detail=true"

Include Error Detail makes Npgsql put the offending values in its error messages. Leave it off in production, where those values can be personal data. Turn it on in tests, where it's exactly what the coding agent needs to see.

public static class TestDatabase
{
    private static readonly string? ConnectionString = Environment.GetEnvironmentVariable("MYAPP_TEST_DB");

    // One data source for the whole run, so every test reuses the same pool of open connections.
    private static readonly DbDataSource? Source = ConnectionString == null ? null : NpgsqlDataSource.Create(ConnectionString);

    // Never committed: everything a test writes is rolled back when it's disposed.
    public static RequestTransaction Begin()
    {
        Assert.SkipWhen(Source == null, "Set MYAPP_TEST_DB to run the database tests.");
        return new RequestTransaction(Source!);
    }
}

That rollback is the cleanup. Each test runs in its own transaction and never commits, so tests don't see each other's rows and the database never fills up with test data.

[Fact]
public async Task Missing_column_is_reported_with_the_columns_that_exist()
{
    await using var request = TestDatabase.Begin();
    await using var command = request.Begin().CreateCommand("SELECT 1 AS id, 'Jonas' AS first_name");
    await using var reader = await command.ExecuteReaderAsync();
    await reader.ReadAsync();

    var error = Assert.Throws<InvalidOperationException>(() => reader.Get<string>("last_name"));

    Assert.Contains("id, first_name", error.Message);
}

[Fact]
public async Task Updated_user_is_read_back_with_the_new_name()
{
    await using var request = TestDatabase.Begin();
    var users = new Users(request.Begin());
    var id = await users.Add(1, "Jonas", null);

    await users.Update((await users.Get(id))! with { FirstName = "Changed" });

    Assert.Equal("Changed", (await users.Get(id))!.FirstName);
}

Keeping the tests fast

A database test should take milliseconds. When the suite gets slow, it's almost always one of these:

A database per test. Starting a container or creating a database takes seconds. Start one container, and leave it running between runs.
Building the schema per test. Run the migrations once per test run, from the same scripts production uses. That also proves the migrations work.
Cleaning up by deleting. Truncating tables between tests costs more than the tests. The rollback does it for free.
A new pool per test. Creating a data source per test opens new connections every time. Keep one, as TestDatabase does.
Running in sequence. Every test has its own transaction, so they can run in parallel. The catch: two tests that change the same row wait for each other's transaction. So each test inserts the rows it changes, instead of sharing seeded ones.

What to test, and where

The foundation, once, in MyApp.Data.Tests/Foundation. Each Get<T> error (missing column, NULL into a non-nullable type, wrong type). NULL into int? and string. ToList, FirstOrDefault and ToEnumerable on zero, one and many rows. RequestTransaction: a commit is visible from another connection, a dispose without commit leaves nothing behind.
Every SQL statement, in its feature's folder. Write, then read back. A statement no test runs is a statement nobody has seen work.
The commit rule, through the web host. Start the app in memory, against the test database, and check that a successful request commits, and that an exception, a 400 and an invalid form roll back. These tests have to commit, so they use rows nobody else touches and remove them afterwards.
Business logic, not here. It's tested in the domain's tests, against fakes of the domain's own interfaces.

Why not EF Core?

EF Core is a good library, and models have seen a lot of it. But the things that make it productive for a human are the things a coding agent can't see.

The SQL is generated at runtime. A LINQ query that compiles can still fail with "could not be translated" when it runs. Or it runs fine, and fetches the whole table to filter it in memory. The coding agent sees C#; the database sees something else. Here, the SQL in the file is the SQL that runs.
Change tracking is state somewhere else. SaveChanges() writes whatever the context tracked, including an entity loaded three calls away. Reading one method doesn't tell you what it will write. Here, every write is an ExecuteNonQueryAsync in the method that does it.
Mapping is convention. Table and column names come from class and property names, attributes, OnModelCreating and the conventions in between. Grep a column name and you may find nothing. Here, the column is written out next to the code that reads it.
Loading is implicit. Whether a related entity is there depends on an Include, a lazy-loading proxy or what the context happens to track. An N+1 query compiles, passes the tests and shows up in production.
The API is huge, and comes in versions. EF6 and EF Core share names and differ in behavior, and models were trained on both. That's where a coding agent calls a method that existed ten years ago.

The honest counterweight: EF Core gets you running faster, and a coding agent writes plausible EF Core code from training alone. If your data access is simple CRUD and stays that way, that can be worth it. The cost shows when something goes wrong, and then it's the coding agent that has to work out why, with nothing but the files to go on.

What I've learned since 2013

The old version worked, and I shipped code like it for years. But I've learned a lot since, and much of it is about what a reader can't see. Every piece below made sense to me back then; every one of them hides something from a coding agent.

(int)record["Age"]. If the column is a bigint, you get InvalidCastException: Unable to cast object of type 'System.Int64' to type 'System.Int32'. Which column? Which query? The coding agent has no idea, so it starts changing casts until the test goes green.

SELECT * and a Map(record, user) that fills properties. Add a property to User and forget the mapper, and the new property is silently empty. Nothing fails. And SELECT * means a grep for a column name never lands on the query that reads it.

A repository base class. Repository<TEntity> with an abstract Map and a ToList that calls it. One more file to open to understand the one you're editing, for a loop of five lines.

AdoNetContext and its units of work. A command joined the first unit of work in a linked list behind a lock, or no transaction at all when the list was empty. Whether a command ran inside a transaction was decided at runtime by state somewhere else. The file you were reading couldn't tell you.

uow.SaveChanges() in every service method. Forget it, and the change is rolled back without a word.

command.Page(...) rewriting CommandText. The SQL you read was not the SQL that ran.

DbProviderFactories and a provider name in app.config. The driver was chosen by configuration, through a lookup no grep can follow.

The common thread: each of these moves information off the page, or lets a mistake compile and fail later. A coding agent pays for both.

Telling the coding agent

The compiler enforces most of this. What it can't goes in a skill the coding agent loads when it works in the Data project:

# Data access

The Data project uses plain ADO.NET with the extensions in its `Foundation/` folder. No ORM, no
interfaces over ADO.NET.

## Setup

- The Data project references no database provider and no ASP.NET Core. SQL lives in one folder per feature.
- The web project registers the provider as a `DbDataSource` singleton, calls `AddRequestTransaction()`,
  registers each Data class as scoped, and adds `CommitRequestTransaction` (minimal APIs) or
  `CommitRequestTransactionFilter` (controllers).
- Outside a web request, create a scope and call `RequestTransaction.Commit()` when the work succeeded.

## Writing SQL

- A Data class takes `DbTransaction` in its constructor and creates commands with
  `transaction.CreateCommand(sql)`. It never commits; the request does.
- Values always go through `command.AddParameter(name, value)`, never into the SQL string.
- Each class has a `Columns` constant and one `Map` method that reads by position with `Get<T>`.
  Every query that `Map` reads selects `Columns`, nothing else and in that order.
- A nullable column is read as a nullable type: `Get<int?>`, `Get<string?>`.
- Read rows with `reader.ToList(Map)` or `reader.FirstOrDefault(Map)`. Use `reader.ToEnumerable(Map)`
  only inside an `async IAsyncEnumerable` method, and run no other command while it is enumerated.
- Write paging, sorting and filtering in the SQL.

## Test database

- The tests run against a database in a local container, started once and left running. It trades
  durability for speed: PostgreSQL runs with its data on tmpfs and `fsync`, `synchronous_commit` and
  `full_page_writes` off; a SQL Server test database uses simple recovery and forced delayed
  durability. Never point the tests at a database whose data matters.
- The schema is created once per test run, by the same migrations production uses.
- The test connection string turns on the provider's detailed errors (Npgsql: `Include Error Detail=true`).

## Testing

- Every SQL statement has a test in the Data project's test project, in the feature's folder, against
  the real database. Never fake `DbCommand` or `DbDataReader`.
- Start each test with `TestDatabase.Begin()` and never commit: the rollback is the cleanup. The tests
  skip when no test database is configured.
- Each test inserts the rows it changes. Tests run in parallel, and a shared row makes them wait for
  each other.
- A write is tested by reading it back.
- Business logic is tested in the domain's tests against fakes of the domain's interfaces, not here.

The skill is short, because the rest is in the types.

Conclusion

The 2013 version optimized for a developer who knew the codebase. This one optimizes for a reader who only knows what's on the page: the SQL, the mapper and the transaction are all in the file being edited, a wrong mapping doesn't compile, a wrong column fails with a message that names it, and every statement has a test against the database it runs on.

It's also less code than the old one. No context, no unit of work, no base class, no connection factory. Eight methods, one class to own the transaction, and two filters you pick from.

Next: queries versus commands, and where repositories fit.

I built a live ops dashboard with no chart library and no framework

Jonas Gauffin — Tue, 20 Oct 2026 05:35:42 +0000

A dashboard that updates every second usually means a chart library, a state store and a framework to glue them together. This one has none of the three. It's custom elements, one small service and a Server-Sent Events stream.

You can run it yourself: clone relax-js/components and run npm run demo:ops.

The habit

You need one chart, so you add a chart library. Then you need a figure with a trend line, so you add a sparkline package. Then each widget fetches its own data, and you add a store to keep them in step.

Chart libraries earn their place. They draw fifty chart types, zoom, pan and export, and they are battle-tested. If you need that, use one.

But look at what an ops dashboard actually shows: a few figures against a moment ago, a trend, a level not to cross, usage against a limit, and the state of each service. You pay for the fifty chart types anyway. And each chart is styled through its own configuration object instead of CSS, so dark mode becomes a second configuration.

Here is what it costs in bytes. Every component in @relax.js/components, the charts, table, tree view, menus and dialogs included, is 34 KB gzipped. Chart.js 4.4 on its own is 70 KB. (Both measured from jsDelivr's builds. Chart.js does a lot more, which is exactly the point.)

The parts

The overview page is markup:

this.innerHTML = `
    <incident-banners></incident-banners>
    <live-figures class="figure-row"></live-figures>
    <div class="panels">
        <r-card heading="Traffic" lead="Requests per second, the last minute.">
            <live-traffic-chart></live-traffic-chart>
        </r-card>
        <r-card heading="Capacity" lead="Usage against what the fleet has.">
            <capacity-meters></capacity-meters>
        </r-card>
        <r-card heading="Services" lead="Where every service stands right now."
                link-text="Traffic details" href="/traffic">
            <service-health-grid></service-health-grid>
        </r-card>
    </div>
`;

The r- tags come from the library. The others are the app's own small elements, each feeding one library component:

<r-stat-tile>: a figure against an earlier one, with a sparkline of the trend
<r-line-chart>: series over time, including a dashed level not to cross
<r-meter>: usage against a limit, turning to warning and danger tones
<r-status-grid>: one tile per service, coloured by state
<r-card>: the panel around each one

One stream, one service

The tempting way to make a widget live is to let it fetch its own data:

class TrafficChart extends HTMLElement {
    connectedCallback() {
        setInterval(async () => {
            const response = await fetch('/api/telemetry/last-minute');
            this.draw(await response.json());
        }, 1000);
    }
}

Four widgets means four requests a second, four slightly different ideas of "now", and an interval that keeps running after the page is gone.

Instead, one service holds the last minute and tells whoever is watching when it changes:

export class Telemetry extends EventTarget {
    readonly samples: TelemetrySample[] = [];
    private source?: EventSource;

    watch(listener: () => void): () => void {
        this.addEventListener('change', listener);
        this.source ??= this.connect();
        return () => this.removeEventListener('change', listener);
    }

    private connect(): EventSource {
        const source = new EventSource('/api/telemetry');
        source.addEventListener('telemetry-sample', (event) => {
            this.samples.push(JSON.parse(event.data));
            if (this.samples.length > 60) {
                this.samples.shift();
            }
            this.dispatchEvent(new Event('change'));
        });
        return source;
    }
}

export const telemetry = new Telemetry();

One connection serves the whole page, however many widgets show it. The demo uses Relax.js core's SSE client and hands the service out through dependency injection, but EventTarget and EventSource straight from the browser do the same job.

One widget

Here is the traffic chart. It watches the service while it is on the page, and draws every time a sample arrives:

import type { LineChart } from '@relax.js/components';
import { telemetry } from './telemetry';

const capacity = 1800;

class LiveTrafficChart extends HTMLElement {
    private readonly chart: LineChart = document.createElement('r-line-chart');
    private stopWatching?: () => void;

    connectedCallback(): void {
        this.replaceChildren(this.chart);
        this.stopWatching = telemetry.watch(() => this.draw());
    }

    disconnectedCallback(): void {
        this.stopWatching?.();
    }

    private draw(): void {
        const samples = telemetry.samples;
        if (samples.length < 2) {
            return;
        }
        this.chart.data = {
            labels: samples.map((s) => s.at),
            series: [
                { name: 'Requests per second', values: samples.map((s) => s.requestsPerSecond), area: true },
                { name: 'Capacity', values: samples.map(() => capacity), threshold: true },
            ],
            summary: 'Requests per second over the last minute, against capacity',
        };
    }
}

customElements.define('live-traffic-chart', LiveTrafficChart);

area: true shades under the line. threshold: true draws the capacity as a dashed line without markers. That's the whole configuration.

The other widgets follow the same rule as every component in the library: scalars are attributes, lists are properties. A stat tile gets its figures as attributes and its trend as a property:

tile.setAttribute('value', String(latest.p95Ms));
tile.setAttribute('previous', String(halfAMinuteAgo.p95Ms));
tile.setAttribute('better', 'lower');
tile.trend = { labels, series: [{ name: 'p95 latency (ms)', values }], summary: 'p95 latency over the last minute' };

better="lower" matters more than it looks. Latency going up is bad news, so the tile colours the change as bad. A dashboard that shows every rise in green is lying to you.

No reactivity, no store

Does that mean the components re-render when the data changes? No. They redraw when you set an attribute or a property, and at no other time. There is no reactive system to reason about. If the page is wrong, the last thing you set is wrong.

Once a second, sixty points per series, is nothing for an SVG to redraw.

Dark mode and screen readers come with it

The series colours are CSS variables, --series-1 to --series-5, each defined with light-dark(). The cover image of this article is the same page with the operating system set to dark. No second configuration.

A chart drawn on a canvas is an image to a screen reader, and you add the text alternative yourself. Here every chart is a role="figure" named by its summary, with a visually hidden table holding the same figures. You wrote the summary already: it is a required field of the data.

Where it does not fit

Thousands of points per series. SVG redraws the whole chart. For a minute of samples, that's fine. For a day of per-second data, use a canvas-based library.
Exploring the data. There is no zoom, pan, brush or export. The charts answer "where are we now?", not "let me dig".
Chart types. Line, area, bar, heatmap and sparkline. No pie, no scatter.

The takeaway

An ops dashboard needs a handful of figures, trends and states, drawn the same way everywhere, not a chart library. Feed every widget from one service, set attributes and properties when data arrives, and let CSS handle the look.

Next in the series: dark mode, currency formats and Swedish translations, each set in one place.

Server-side paging and sorting for an HTML table, with one async function

Jonas Gauffin — Mon, 19 Oct 2026 05:45:59 +0000

You want a table that pages and sorts on the server. Usually that means state for the page, the sort, the loading flag and the total, plus code that throws away answers that arrive too late. With <r-table> you write one async function, and the table keeps the state.

The habit

Most hand-written server tables look like this:

let page = 1;
let sort = { column: 'orderDate', direction: 'desc' };

async function load() {
    showSpinner();
    const response = await fetch(`/api/orders?page=${page}&sort=${sort.column}&direction=${sort.direction}`);
    const result = await response.json();
    drawRows(result.rows);
    drawPager(result.totalCount);
    hideSpinner();
}

It works on your machine. In production, someone clicks page 2 and then page 3. Page 2 is slow, so its answer arrives last, and the screen shows page 2's rows under a pager that says 3.

It IS a bug, and almost every table I have seen has it. You don't notice it on localhost, because every answer is fast there.

To be fair, fetching it yourself is simple and gives you full control. The fetch is not the problem. The problem is all the state around it, which you write again in every view.

The cure: the table asks, you answer

Declare the columns:

<r-table page-size="15">
    <r-column field="number" sortable>Order</r-column>
    <r-column field="customer" sortable>Customer</r-column>
    <r-column field="orderDate" sortable sort="desc">Date</r-column>
    <r-column field="total" sortable>Total</r-column>
</r-table>

Then give the table a function that loads one page:

import type { Table, TableProvider } from '@relax.js/components';

const loadOrders: TableProvider = async ({ page, pageSize, sort, signal }) => {
    const query = new URLSearchParams({ page: String(page), pageSize: String(pageSize) });
    if (sort[0]) {
        query.set('sort', sort[0].column);
        query.set('direction', sort[0].direction);
    }
    const response = await fetch(`/api/orders?${query}`, { signal });
    return response.json(); // { rows: [...], totalCount: 312 }
};

document.querySelector<Table>('r-table')!.provider = loadOrders;

That is the whole view. The table calls the function for the first page, and again for every click on a header or a page button. Pages are 1-based, and a header click goes ascending, descending, then back to the server's own order.

While a page loads, the table sets its loading attribute and aria-busy, and dims the rows. The pager hides when one page holds every row.

The signal is the important part

Each time the table asks for a page, it aborts the signal of the request before. Pass the signal on to fetch, and the browser cancels the HTTP request the user no longer wants.

And if you forget? The table checks the signal when your answer comes back, and an answer to an aborted request is never drawn. Page 2 can arrive as late as it likes. The screen shows page 3.

Filters: the mistake I made myself

A filter form above the table is the next thing every list view needs. My first version reloaded the table on every keystroke:

form.addEventListener('input', () => table.refresh());

Looks fine. But refresh() loads the page the user is on. Stand on page 7, type a customer name that matches two pages of orders, and you get an empty page 7. (I made exactly this mistake in the demo app for this library. Yes, the app that is supposed to show how it's done.)

So when the filter changes, give the table a new provider for that filter instead:

function ordersMatching(search: string, status: string): TableProvider {
    return async ({ page, pageSize, sort, signal }) => {
        const query = new URLSearchParams({ page: String(page), pageSize: String(pageSize), search, status });
        if (sort[0]) {
            query.set('sort', sort[0].column);
            query.set('direction', sort[0].direction);
        }
        const response = await fetch(`/api/orders?${query}`, { signal });
        return response.json();
    };
}

form.addEventListener('input', () => {
    const data = new FormData(form);
    table.provider = ordersMatching(String(data.get('search')), String(data.get('status')));
});

Setting provider starts at page 1, and aborts the request in flight. Type fast, and every keystroke cancels the request before it. You may still want a debounce to spare your server, but you no longer need one to get the right rows.

refresh() is for when the data changed and the user should stay where they are:

await saveOrder(order);
await table.refresh();

It resolves once the page is drawn, so you know when to close the dialog.

Records you already hold

Small lists don't need a server. Set rows instead:

table.rows = customers;

The table sorts and pages them itself. Under the hood rows is wrapped in a provider with the same contract, so there is one code path for both. When the list outgrows the browser, you swap rows for provider and the markup stays as it is.

In-memory sorting follows the configured locale and compares digits as numbers, so SO-9 comes before SO-10.

When the server fails

A provider that throws while the user pages or sorts does not break the view. The rows shown stay, the pager goes back to the page shown, and the table reports r-table: the provider failed to load page with your error, through the same error channel as the rest of the app. refresh() rejects with the error, so you can tell the user.

If you already use Relax.js core, its DataLoader takes the same request, so it plugs in with one line:

table.provider = (request) => loader.load(request);

Where it does not fit

It sorts by one column. The request carries a list of sort columns, but the table sends at most one.
A cell shows a value, not markup. Numbers are grouped and dates written for the locale, but a status badge inside a cell is not something the table does.
There is no row click event. The table draws plain rows. The demo listens for clicks on the table and maps the row's index back to the record it shows. That works, but it's code you write.
Your server has to count. The pager needs totalCount. On a table with millions of rows, that COUNT(*) is a cost you should know about up front.

The takeaway

The table owns the page, the sort and the race. You own one function that turns a request into rows. Pass the signal on, set a new provider when the filter changes, and the classic "page 2 shows up on page 3" bug cannot happen.

Next in the series: a live ops dashboard with no chart library and no framework.

Your line of business web does not need a framework

Jonas Gauffin — Wed, 14 Oct 2026 20:12:16 +0000

A new business app starts with a question: React, Vue or Angular? The question that rarely gets asked is whether it needs one at all. For a page that lists orders, edits a customer and shows a few figures, the browser now does most of what we once picked a framework for.

This article walks through what frameworks were for, what the browser has taken over, and what is still missing. Then it builds a working order page in one HTML file, with no framework and no build step.

The habit

You start a project. You pick a framework, then a component library for that framework, then a state library, a router and a form library that fit both. By the time the first page shows a table, you have five dependencies that must agree with each other, and each will ship a breaking major version on its own schedule.

None of that is wrong. A framework gives a team one way to do things, and every developer you hire has used one. But it is a choice made by reflex, and the reasons it was the right reflex ten years ago have mostly gone away.

What a framework was for

Frameworks filled holes in the browser. Look at what those holes were, and what fills them today:

You needed a framework for	The browser has
Your own reusable tags	Custom elements
Knowing when a component appears and disappears	`connectedCallback` and `disconnectedCallback`
Modals that trap focus and close on Escape	`<dialog>`
Dropdowns that float above everything	The Popover API
Form validation	Constraint validation: `required`, `min`, `pattern`, `:invalid`
Numbers, amounts and dates per locale	`Intl`
Code split into modules	ES modules, loaded straight from a URL

The big remaining selling point is reactivity: change a variable and the page follows. That solves a real problem in an app where a hundred things depend on each other. A business page is rarely that app. It shows records, lets you change one, and shows the result. The places that change are few, and you know which they are.

What is still missing

The browser has no table that sorts and pages. No tabs, no tree view, no chart. That is what a business page is made of, and it is the real reason teams reach for a framework and its component library.

So that is the gap I filled with @relax.js/components: tables, tree views, tabs, menus, dialogs, charts and meters for business pages. Not a framework. Each one is a plain custom element, and where the browser already has the part, it uses it: the table is a native <table>, menus use the Popover API, the dialog is a <dialog>.

A page with no framework

Save this as a file and open it. No npm install, no bundler:

<!doctype html>
<html lang="en">
<head>
    <meta charset="utf-8">
    <title>Orders</title>
    <link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/@relax.js/components@2.0.0/dist/theme.css">
    <style>
        body { font-family: system-ui; background: var(--surface-bg); color: var(--text-primary); }
    </style>
</head>
<body>
    <r-stat-tile label="Orders"></r-stat-tile>
    <button id="add">New order</button>

    <r-table page-size="10">
        <r-column field="number" sortable>Order</r-column>
        <r-column field="customer" sortable>Customer</r-column>
        <r-column field="total" sortable>Total</r-column>
    </r-table>

    <r-dialog id="new-order" heading="New order">
        <template>
            <form method="dialog">
                <label>Customer <input name="customer" required></label>
                <label>Total <input name="total" type="number" min="1" required></label>
                <button value="save">Save</button>
            </form>
        </template>
    </r-dialog>

    <script type="module">
        import 'https://cdn.jsdelivr.net/npm/@relax.js/components@2.0.0/+esm';

        const orders = [
            { number: 'SO-10001', customer: 'Fjällbo AB', total: 12400 },
            { number: 'SO-10002', customer: 'Kvarnen HB', total: 860 },
            { number: 'SO-10003', customer: 'Ekdahl & Son', total: 3150 },
        ];

        const table = document.querySelector('r-table');
        const tile = document.querySelector('r-stat-tile');
        const dialog = document.querySelector('#new-order');

        function show() {
            table.rows = orders;
            tile.setAttribute('value', orders.length);
        }

        dialog.addEventListener('submit', (event) => {
            const form = new FormData(event.target);
            orders.push({
                number: `SO-${10001 + orders.length}`,
                customer: form.get('customer'),
                total: Number(form.get('total')),
            });
        });

        document.querySelector('#add').addEventListener('click', async () => {
            if (await dialog.open() === 'save') {
                show();
            }
        });

        show();
    </script>
</body>
</html>

You get a figure, a sortable table with grouped numbers and a pager, and a modal form. The form refuses to save without a customer or with a total below 1. That is the browser, not my code and not a library.

Now count what is not there. No state store. No virtual DOM. No compiler. No component tree to keep in your head. The data is an array, and show() is the whole rendering strategy: when the data changed, you tell the page.

"But who keeps the page in sync?"

You do, and that is the point. A framework re-renders when it decides something changed. When it gets it wrong, you debug the framework: why did this render twice, why did that not render at all.

Each component here redraws when you change its attributes, its properties or its content, and at no other time. There is no base class, no reactivity and no hidden scheduler. The lifecycle is the one on MDN. If the table shows old rows, you forgot to set rows, and a breakpoint on that line tells you so.

One rule trips everybody up: records go in a property, not an attribute. Attributes are strings, and a list in an attribute is a JSON string the component would have to parse and keep in sync with the property. So rows, columns and chart data are set from code, and scalars like page-size are attributes.

"But it needs Relax.js core"

Yes. The components have one peer dependency, @relax.js/core, and the jsDelivr link pulls it in for you.

That does not sneak a framework back in. A framework calls your code: it owns the lifecycle, the rendering and the state. Core is a set of libraries your code calls, and you use only the parts you need: typed form reading, routing, dependency injection, translations. The components themselves call it for four things:

translating the words they show (No data, Next)
reporting errors through one channel
formatting values
letting the router open a dialog, and only for a dialog you give a name

When the page above grows into an app with several pages, those same libraries give you a router and typed forms. You add them when you need them, not on day one.

Already on React or Vue?

Then the components still work, because every framework renders HTML and a custom element is HTML. The property rule above is all you need to know. React 19 assigns rows={orders} as a property. In Vue you write :rows.prop="orders" and tell the compiler that r- tags are not Vue components. Events are plain DOM events.

It is a way out as much as a way in. The table you use in React today is the same table in the page that replaces it.

The takeaway

Frameworks were the right answer to a browser that could not do much. The browser caught up. For a page that lists, edits and summarizes records, what is missing is the business components, not a framework. Add those as plain custom elements, write the updates yourself, and you have nothing left to migrate away from.

Next in the series: server-side paging and sorting, with one async function.

I shipped five products with my own AI agent. Then I built what it was missing.

Jonas Gauffin — Fri, 09 Oct 2026 18:11:49 +0000

For the past year my consulting assignment didn't allow AI agents. So I coded with them in my free time instead: evenings, weekends, a lot of hours. Not to see whether agents can write code (they can), but to see whether they could write code I would actually want to keep.

During my thirty years as a dev I've come to care about clean architecture and code quality more than is probably healthy. That turned out to be the whole problem.

What the usual setup gets you

I did what everyone does. A good model, an AGENTS.md with my rules, a set of skills for the things I do often. It worked, in the sense that features appeared. But I kept running into the same three walls.

The agent guessed. A feature description written for a person leaves gaps a person fills from context. The agent filled them with something plausible. The code compiled, its tests passed, and it did the wrong thing.

The rules were requests. "Read a file before you edit it." "Stay inside the workspace." "Don't add that dependency." All of it lived in a prompt, and a prompt is a suggestion. Most of the time the model followed it. Most of the time is not a rule.

I was the only check. Every change ended with me reading a diff, plus a confident summary written by the same agent that wrote the code. The agent was grading its own homework, and I was the bottleneck.

More instructions didn't fix any of this. Each new line in AGENTS.md made the agent slightly better and the file slightly longer. I needed the guarantees to come from somewhere other than the model.

First, measurements the agent couldn't argue with

So I started building my own MCP servers to measure code quality, code duplication and more, so the agent got facts about the code instead of its own impression of it. They're all on GitHub.

Then I built my own agent

It became KiwiPow Agent, a VS Code extension. I kept iterating on it, and every iteration moved a rule out of the prompt and into the code around it.

Plan from intent, not from code. The planner reads the docs and approved specs, never the code, and writes a spec of named rules. A planner that reads the code inherits its bugs as requirements.
Disagreements become decisions. A separate step reads the code and turns every place it disagrees with the spec into a decision. The agent doesn't quietly pick a side; I rule.
Done comes with evidence. Every task names the test that proves each rule it delivers. No test, not done.
Read before write, enforced. A session cannot write a file it has not read, or one that changed since it last looked. Not discouraged: refused.

The results got much better.

Five products in a year

With my MCP servers and later my own agent, in a year, on my own, I shipped five products. Not because I needed five products, but to test the approach across different industries and different
ways of working. They are all online if you search ;)

Ottoweb, homepages for small companies,
the Kiwisonic suite: a DAW, a synth, a drum designer, a bass designer and a vocal transformer,
Bikermike, road-trip planning for motorcyclists,
Sanndir, an AI coach, perfect for venting co-worker troubles ;),
Bankbook, accounting.

One person. A team of agents. Every decision about what got built, approved and accepted was still mine.

This isn't my first time chasing a neglected loop

My first company, Coderr AB, came from the same itch. I kept seeing teams treat errors as a chore, something to clear rather than something to learn from. So Coderr caught errors and collected telemetry automatically, and ranked them by what mattered, such as how many customers each one hit.

Agent-written code has the same problem one step earlier. The loop between what was asked, what was built and what was accepted is the part nobody has time for, so it doesn't happen. The agent writes faster than anyone can check it against the requirement.

From an agent to KiwiPow

An agent works while I sit in a session with it. What the agent taught me is that the important work shouldn't wait for that: requirements and code should keep getting refined in the background, and the people who own the requirement should be part of the loop, not just the developer. Today the
neglected loop runs between what the business asked for, what the agent built, and what someone actually accepted.

So KiwiPow isn't the agent. It's two products built on what the agent taught me.

KiwiPow Server turns an ask into a spec planned from your own documents, with a citation on every behaviour and open questions that block approval. The product owner approves a numbered revision. Approved features wait in a ranked queue: a developer takes the next one, no sprint planning needed.

KiwiPow IDE is the editor where the agent builds exactly the approved behaviours and proves each one with a test. The rules are enforced by the IDE itself, the same on every model, and every tool call is recorded before it is answered. What the agent knows about the code comes from analyzers built on the language's own toolchain, stored per commit, so it doesn't get to invent a call graph. Where the code disagrees with the spec, the decision travels back to the person who owns the requirement. The tester accepts behaviour by behaviour, against the tests.

And more of it runs on its own. Background loops keep refining: the planner critiques specs before anyone reads them, the analysis turns code-health findings into explained work, and what the code teaches flows back into the requirement.

One license instead of a tracker, an editor and a code-quality tool. And KiwiPow is built with KiwiPow: one founder, a team of agents, every decision owned by a person. Same rules for me as for you.

Where it is now

It's not released yet. If you code with agents and want them held to what was actually asked, sign up for the release. Early signups lock the founding price for as long as they stay customers:
https://kiwipow.com/signup.html

I'd also love to hear how you deal with this today. What's in your AGENTS.md or skills that the model still ignores?

tsc looked at my templates and saw a nice string.

Jonas Gauffin — Tue, 06 Oct 2026 16:46:45 +0000

Sixth in a series on using @relax.js/core with a coding agent. This is the piece I said in the first article bothered me enough to fix.

The gap

When I worked in Angular, a wrong property in a template was a build error. vue-tsc does the same for Vue. Relaxjs sells itself on having no compiler, and the price was that a template is a string: {{user.naem}} is perfectly valid TypeScript, because it is text.

The previous two articles are about catching it at runtime, in a test, with the errors captured. That works, and it depends on three things the agent has to remember: write the test, render with a representative model, assert on the captured errors. Forget one and the typo ships.

The rule I keep coming back to, from the design notes I write for agents: an API that makes wrong usage a type error is worth far more than one that makes it a runtime warning, because nobody is watching the console. So the question was whether a library with no build step could have a type check for its templates anyway.

Give the call its types

compileTemplate takes two type parameters: the view model render() receives, and the functions context it receives as its second argument.

interface ViewModel {
    heading: string;
}

interface Handlers {
    discard: () => void;
}

.. and using it like:

this.template = compileTemplate<ViewModel, Handlers>(`
    <form class="form">
        <h1>{{heading}}</h1>

        <label for="displayName">Display name</label>
        <input id="displayName" name="displayName" required>

        <label for="email">Email</label>
        <input id="email" name="email" type="email" required>

        <label for="bio">Bio</label>
        <textarea id="bio" name="bio"></textarea>

        <button type="submit">Save</button>
        <button type="button" r-click="discard()">Discard changes</button>
    </form>
`);

Nothing changes at runtime. The types are there for the checker.

Run it

npx @relax.js/core check

It reads the project's tsconfig.json, finds every compileTemplate call whose template is a literal and every html`…` literal, and resolves each expression against the types with the TypeScript compiler API. Here is the example app's page as an agent might first write it, with two typos and one habit carried over from the other engine:

export const page = compileTemplate<ViewModel, Handlers>(`
    <form class="form">
        <h1>{{heading}}</h1>
        <p>Signed in as {{profile.emial}}</p>
        <button type="button" r-clik="discard()">Discard changes</button>
    </form>
`);

const card = html`<p class="status">{{user.name}}</p>`;
export const status = card({ user: { name: 'Alice' } });

And the output, verbatim:

src/pages/ProfilePage.broken.ts:21:27 - error: Cannot resolve "profile.emial": Profile has no property "emial"
src/pages/ProfilePage.broken.ts:22:39 - error: "r-clik" is not a known event for <button>
src/pages/ProfilePage.broken.ts:26:39 - error: "user.name" is not a property name; html templates take flat names

2 templates checked

Exit code 1. The format is tsc's, one line per expression, column pointing at the expression rather than at the call. Editors and agents already know how to read it.

The third line is the one I like most. The html tag takes flat names; {{user.name}} is looked up as one key, so it is a mistake even though the object has a user. The checker knows the context type without an annotation: it takes it from the bind call, card({ user: ... }), either the immediate call or the first call in the same file of the variable or class field the template was stored in.

What is checked

Every {{path}}, if, unless and handler argument: each segment is a property of the type before it. null and undefined are looked through because the runtime renders them as empty. [0] on an array gives the element type. any ends the walk.
loop="row in rows": rows is an array, and row has its element type inside the element and goes out of scope when the element closes.
{{fn(a, 'x', 1)}} and r-click="fn(row, event)": fn is a property of the functions type with a call signature that accepts the argument count and types. event is Event, in handlers only.
r-<event>: on<event> exists on the element's DOM type, the same test the runtime makes.
Pipes: one of the built-ins, unless the call passes its own registry.
{{ is closed on the same line.

What is skipped, and said so

A template held in a variable, built with ${} substitutions or loaded from a file has no text at the call site. A compileTemplate call without type arguments still gets the syntax, event and pipe checks, but no path resolution. An html bind function that is returned or called in another file has no context type. Each of these is counted in the summary with its reason:

12 templates checked, 2 skipped (1 no type argument, 1 not a literal)

The templates skill puts it as: silence with skipped templates is not green.

Why it will not disagree with the runtime

The obvious risk with a checker is that it drifts from the thing it checks. Two decisions keep that small. The expression grammar ({{expr}}, pipes, loop, function calls) is one module shared by the runtime and the checker, so they cannot parse an expression differently. And the event test is the runtime's test: on<event> on the element type.

What is not shared is the HTML structure. The runtime uses DOMParser; the checker reads the template with a small scanner, because it runs under Node without a DOM. The scanner does not apply the browser's content-model rules, so a <p> closed early by a block element or a <tr> outside a <table> could scope a loop alias differently from how it renders. Keep templates well-formed and the two agree. The doc says this, because a caveat the agent cannot read is a caveat that does not exist.

Make the test suite run it

A command only helps when it is run. The agent runs npm test after every change; it does not necessarily run check. So the example app has this test, and the skill tells the agent to add it if a project lacks one:

const tsconfig = path.resolve(__dirname, '../tsconfig.json');

describe('templates', () => {
    it('every_template_resolves_against_its_view_model', () => {
        const result = checkProject(tsconfig);
        expect(result.diagnostics.map(formatDiagnostic)).toEqual([]);
        expect(result.skipped).toEqual([]);
    });
});

The second assertion is the strict one: no template in this project gets less than a full check. Drop it if you have a legitimately dynamic template somewhere.

typescript is an optional peer dependency. Nothing in the runtime loads it; only check does.

What this gives up and gets back

Angular checks templates inside the compiler, with editor integration and an error on the exact character in the template. This gets the exact character and the tsc format, from a separate command, for templates that are literals with types on the call. It does not get editor squiggles, and it does not see a template you load from a file.

For an agent that is most of what matters. The failure is now a line in the output of a command it already runs, before anything renders, and the message names the type and the property. Next: a full session, prompt to passing tests.

How do you know the agent isn't quietly rotting your codebase?

Jonas Gauffin — Sat, 03 Oct 2026 21:38:18 +0000

The question is not whether coding agents write working code. They do. The question is what a year of it leaves behind.

The decay is quiet because every individual change looks fine. The feature works, the tests are green, the diff was reviewed by somebody who had four other things to do. What accumulates underneath is harder to see: rules nobody agreed to, tests that prove nothing, and files that grew past the point where anyone can hold them in their head.

Four things in Kiwipow Agent are aimed at exactly that, and each one produces evidence you can look at instead of a promise you have to trust.

The intent exists outside the code

Decay starts when the code becomes the only record of what the product does. From then on, every change is planned against the current behaviour, including the parts of it nobody chose.

So the feature planner in the agent cannot read the code. It plans from your docs and from the specs of features planned before, and writes the feature as named rules in the product's language. The code gets its say in a separate pass afterwards, which reports only where it and the spec disagree, and each disagreement is ruled on by a person.

The artefact is a file per feature, in plain language, that a product manager can read and argue with. Not generated from the code, and therefore able to contradict it.

That ability to contradict is the whole point.

So you get to plan next quarter from what the product is meant to do rather than from what it happens to do, and a new developer learns the promises in a morning of reading instead of a month of archaeology.

Every later change is checked against those rules

A spec that is written once and then ignored is decoration. The specs here are read again by every session that changes code: a chat, a planned change, an implementation run. Each one checks the rules covering the area it is about to touch and asks before breaking one. When you agree, the rule is amended in its spec, so the written record moves with the product instead of falling behind it.

Which means a decision stays decided. You hear about a conflict while it is still a question in a chat window, not a year later when a customer finds behaviour nobody chose to change.

The tests come from the rules, not from the code

This is the one I see underrated most often.

A test written from the implementation asserts what the code already does. That is why agent-written suites pass the moment they are written and break the moment anyone refactors. They are snapshots. They catch nothing, and they cost a fortune to maintain, so eventually somebody deletes or regenerates them, and the safety net is gone without a decision ever being made.

A test written from a rule asserts the promise. Refund on cancel fails when cancelling stops refunding, not when a service is split in two. The suite survives the restructuring you will do later, and a red test names the promise that broke rather than the line that changed.

The bookkeeping makes it checkable. The task board is derived from the approved spec rather than written by a model, so every rule is delivered by some task. A task is only finished by naming, per rule, the test that proves it. The spec view shows each rule with its task and its test, or shows the gap. Then the extension runs your test commands with no model involved, over the projects the feature touched, and failures go back for a bounded number of attempts before reaching a person.

That buys back the thing a suite is supposed to give you: freedom to restructure. Green means the promises still hold after the move, red names the promise that broke, and nobody has to rewrite a hundred tests because a class got split in two.

Quality is improved continuously

Passing tests say nothing about whether the implementation left behind a function nobody can follow. So when a feature's tests pass, the files its implementation runs edited are measured: a function against a cognitive complexity limit and a line limit, a type and a file against line limits. Your numbers, in settings, and a limit of zero turns a measure off.

Anything over a limit is listed, and a person chooses: split all of it, split some, later, or skip. If you split, the run works from the size report alone, and afterwards the files are measured again and the tests run again. One pass per feature, never a second. What is still too big is reported and left alone.

The restraint is the point. It does not judge taste: no renaming, no opinions about your abstractions, no discovery that a file "could be cleaner". And it stops: one pass, against numbers you chose, on splits you approved. An agent told to improve code will improve it for as long as you pay, and the second pass over its own work is where it starts moving code sideways.

Which makes the worst outcome a file that is still too big and says so. Not a weekend of unrequested churn through code that already worked, and not a quality step whose cost depends on how much the model felt like rewriting.

What to ask your own team

Whatever tooling you use, the questions are the same, and they are answerable this afternoon.

Where does the agent learn what the product is supposed to do? Point at a requirement from last quarter and ask for the test that proves it. Take a test that failed recently and ask which product promise it was defending. Ask what happens when a change contradicts something agreed six months ago, and who finds out.

If the honest answer to any of them is "the code", you are already paying for this. Just not on a line item.

Kiwipow Agent is a VS Code extension, on the Marketplace; source and issues on GitHub.

How an agent verifies a webpage it can never look at

Jonas Gauffin — Wed, 30 Sep 2026 05:27:21 +0000

Fifth in a series on using @relax.js/core with a coding agent. The previous piece was about seeing errors in a test. This one is about getting the component into a state where there is something to see.

Everything here is from @relax.js/core/testing.

Why plain jsdom is not enough

An agent that knows Web Components will write this and be puzzled:

const page = document.createElement('profile-page');
expect(page.querySelector('form')).not.toBeNull(); // null

connectedCallback only runs when the element is in a document. Created and never attached, it is inert, for reasons that have nothing to do with the component. And once attached, anything it awaits finishes a task later, so asserting right after attaching sees the element before its data arrived.

Two helpers cover this. mount() attaches to document.body and hands back unmount(), which is also how you test disconnectedCallback:

it('stops_listening_once_removed_from_the_page', () => {
    const { element, unmount } = mount('profile-header');
    unmount();

    document.dispatchEvent(new ProfileSavedEvent('42', 'Alice B'));
    expect(element.querySelector('.display-name')?.textContent).toBe('');
});

flush() waits for pending microtasks and the next macrotask, so work started by a lifecycle callback has landed. You will see it after every user action in the page tests below.

Fake the server, not the component

The page loads its data through @relax.js/core/http. fakeServer() replaces the network underneath that module with canned responses and records every request:

beforeEach(() => {
    configure({ baseUrl: '/api' });
    server = fakeServer().on('GET', '/api/users/42', alice);
    routing = mountRouting(routes);
    captured = captureRelaxErrors();
});

afterEach(() => {
    captured.restore();
    routing.unmount();
    server.restore();
});

Paths include the configured base URL and exclude the query string, because that is what a server sees. A request nothing was registered for gets a 404 whose body lists what is registered, and it is recorded like any other, so an unexpected call shows up in server.requests instead of hanging or reaching the network.

The seam is deliberate. Do not stub fetch globally, and do not mock the component's own load() method. The component under test is the real one, and the assertion covers both what it rendered and what it asked for:

it('fills_the_form_from_the_server_when_navigated_to', async () => {
    const page = await routing.navigate<ProfilePage>('profile', { params: { userId: '42' } });

    const email = page.querySelector<HTMLInputElement>('input[name="email"]')!;
    expect(email.value).toBe('alice@example.com');
    expect(server.requests.map((r) => `${r.method} ${r.path}`)).toEqual(['GET /api/users/42']);
    expect(captured.messages()).toEqual([]);
});

A function body is called with the request, which is how a PUT answers with what it was sent:

it('submit_sends_the_edited_form_and_announces_the_save', async () => {
    server.on('PUT', '/api/users/42', (request) => request.json());
    const page = await routing.navigate<ProfilePage>('profile', { params: { userId: '42' } });
    const saved: ProfileSavedEvent[] = [];
    page.addEventListener(ProfileSavedEvent.type, (e) => saved.push(e));

    page.querySelector<HTMLInputElement>('input[name="displayName"]')!.value = 'Alice B';
    page.querySelector('form')!.requestSubmit();
    await flush();

    const put = server.requests.find((r) => r.method === 'PUT')!;
    expect(put.json()).toEqual({ ...alice, displayName: 'Alice B' });
    expect(saved.map((e) => e.displayName)).toEqual(['Alice B']);
    expect(page.querySelector('.status')?.textContent).toBe('Saved');
    expect(captured.messages()).toEqual([]);
});

Note requestSubmit(), not submit(). The latter skips the submit event, and the FormValidator that owns the form never hears about it. When an agent picks the wrong one, the test says so: the PUT is missing from server.requests.

The failure path is one more on() with a status:

it('a_rejected_save_lands_in_the_error_summary_instead_of_throwing', async () => {
    server.on('PUT', '/api/users/42', { message: 'nope' }, 409);
    const page = await routing.navigate<ProfilePage>('profile', { params: { userId: '42' } });

    page.querySelector('form')!.requestSubmit();
    await flush();

    expect(page.querySelector('.status')?.textContent).toBe('');
    expect(page.textContent).toContain('The server rejected the change (409)');
    expect(captured.messages()).toEqual([]);
});

Registration order matters: the first match wins. That is why the PUT is registered per test and not in beforeEach.

Navigate like the app

The page above is reached with routing.navigate(), not mount(). The difference is everything a page depends on: loadRoute() runs with the route parameters before the element is added, the element lands inside <r-route-target>, and routeData is set. mountRouting() registers the routes and puts the targets in the document; its navigate() resolves with the rendered component once it is inside the target, after all of that. No flush() needed for the load itself.

It rejects the way navigate() throws in the application: no route matched, or a guard stopped it. When the component never appears within the timeout, the rejection lists the errors reported meanwhile, so a loadRoute() that threw is named instead of leaving you with an empty target.

The routes it takes are the app's own:

export const routes: Route[] = [
    { name: 'profile', path: '/profile/:userId', componentTagName: 'profile-page' },
];

One thing this exposed while I was writing the example, and I mentioned it in the third article: the test must import the page module for its side effect. A type-only import is elided, profile-page is never defined, and mountRouting throws at once with the tag name.

Reset between tests

Routing targets, the error handler and the fetch replacement are module-level state. Every helper returns the means to undo itself: unmount(), restore(). Call them in afterEach or a finally, so one test's leftovers cannot explain the next test's failure. The afterEach above is the whole ritual.

The page test

Put together: fakeServer() for the data, mountRouting() to reach the page, captureRelaxErrors() to prove the template resolved, flush() after each user action. Four tests cover the example page end to end and finish in milliseconds. That is the loop the agent runs after every edit, and it is the only loop it has.

It still relies on the template being rendered with the right model before a typo shows up. The next article removes that dependency.

Stop counting duplicated lines: I rank copy-paste by what it costs me

Jonas Gauffin — Tue, 29 Sep 2026 21:33:55 +0000

Every CI pipeline I have worked with had a duplication report. I cannot remember the last time I read one.

The number moves from 4.2% to 4.5%, a list of blocks shows up, and half of them are constructors, guard clauses and property mappings that look alike because that is how the language is written. Meanwhile the copy that actually hurt me never made the list: someone (oops, me) copied a function, renamed three variables, and a bug fix later landed in one copy but not the other.

We blame tight deadlines, but can't blame StackOverflow anymore, so maybe it's time to clean the code bases.

So I built dry-mcp, an MCP server that finds duplicated code by meaning instead of by token, ranks it by what it costs to keep, and gives the result to my AI agent instead of a dashboard.

What SonarQube actually measures

SonarQube is good at what it is built for, so let's be precise about what that is. According to its documentation, a block counts as duplicated when there are at least 100 successive duplicated tokens spread over at least 10 lines (Java uses 10 successive statements instead). Differences in indentation and string literals are ignored.

Two consequences follow:

Renamed copies fall through. Indentation and literals are ignored, identifiers are not. Rename a variable every few lines and the run of 100 identical tokens is broken.
Every duplicated line weighs the same. The headline metric is a percentage. It tells you how much duplication there is, not which duplication to fix first.

That is the right design for a quality gate ("new code may not exceed X% duplication"). It is the wrong design for the question I actually have: where is the duplication that is worth an afternoon?

Match by meaning, not by token

Matching runs in two passes.

First, every block is normalized (formatting and comments stripped) and hashed. Identical hashes are exact copies. That is free and never wrong.

What is left is compared using embeddings from jina-embeddings-v2-base-code, a model trained on code. Two blocks that do the same thing land close together even when every name differs. Measured against that model:

Pair of blocks	Similarity
Same logic, every name changed	~0.53
Same logic, different language	~0.87
Unrelated code	≤ 0.22

Yes, the second row means a helper that was ported to another language is still recognized as the same code. I did not set out to build that, but it falls out of matching by meaning.

Rank by cost, not by count

A 60-line block copied four times is a real problem: every change has to be made four times, and one will be forgotten. A 3-line fragment repeated forty times is almost always an idiom.

So the ranking counts block size for more than the number of copies. Want the most-copied code instead? Ask for orderBy: "frequency".

Demote idioms, don't report them

Repetition that is just how the language is written gets demoted instead of ranked:

Small and frequent. Short blocks that show up everywhere.
Spread thinly. The same shape once in each of a dozen unrelated folders is house style, not one copy-paste incident.
Contained in a larger finding. Copying a function also copies the loop inside it. Only the outermost block is reported, so the same work is not counted twice.
Configured exclusions. Paths and patterns the team has decided to accept.

Nothing is thrown away. includeSuppressed: true returns the demoted groups with the reason for each, so the rules can be checked.

Built for an agent, not a dashboard

Devs are lazy, including me. I don't want to read a duplication report. I want my agent to find the worst copy and fix it. That changes what the output needs to carry.

Confidence on every finding. Near-miss matching is deliberately inclusive, because missing a large repeated block is worse than flagging a coincidence. So instead of silently filtering, each finding is marked certain, high, moderate or low, and the reply explains the scale. The agent knows what it can act on and what it has to read first.

Honesty about completeness. Indexing runs in the background (more on that below). Any reply built from an incomplete index says so, with numbers. A partial answer is never dressed up as a full one.

Self-service scope. Without configuration, every source file under the root is analysed. When that looks too wide, the reply says so, names the largest folders, and tells the agent what to write in duplication.config.json. The agent edits the file, and the next question uses the new scope. No restart.

The whole surface is four tools:

Tool	Answers
`detect_duplication`	Where is the duplication, worst first?
`duplication_status`	Is the index ready?
`explain_duplication`	Show me every copy.
`reindex`	Start over.

A trimmed finding looks like this:

duplications:
 - id: 622069fe1577
   occurrences:
    - file: src/analysis/clusterer.ts
      startLine: 58
      endLine: 177
      lines: 78
    - file: src/analysis/duplication-service.ts
      startLine: 322
      endLine: 441
      lines: 81
    # ...three more
   frequency: 5
   medianLines: 81
   removableLines: 324
   severity: 1692.69
   similarity: 0.763
   confidence: high
summary:
 clustersFound: 98
 byConfidence:
  certain: 4
  high: 50
  moderate: 44

The agent picks the top finding, calls explain_duplication with its id to get the source of every copy, and decides how to merge them.

No parser, any language

There is no grammar to install. Block boundaries are inferred from braces and indentation, so C#, TypeScript, Java, Go, Rust, Python, Ruby, PHP, SQL, shell, CSS and friends all work out of the box.

The trade-off: line ranges are approximate. The returned source is authoritative, the numbers around it are a pointer. For an agent, that's not a problem since it will scan all and decide what to fix.

The catch, part 1: it needs a model

The embedding model is not bundled. Even the smallest weights are around 160 MB, which is too much to push through npm install, and a download that arrives unannounced in the middle of a question is worse than being told once to run a command:

node dist/index.js download-model          # int8, ~160 MB
node dist/index.js download-model --fp32   # ~640 MB, for accuracy

int8 is the default because it is the precision CPUs actually accelerate. x86 cores without AVX512-FP16 have no native fp16 compute, so an fp16 model often runs slower than fp32, while int8 uses the VNNI instructions directly.

Without the model the server still starts. Queries return an empty result with the command to run, not an error.

The catch, part 2: the first sync is slow

Everything runs locally on the CPU. No API key, no code leaving the machine. The price is that embedding a whole project takes minutes, not seconds.

It is slower still by design. I typically have several projects open, each with its own server, on the same machine I am compiling on. Left alone, embedding would take every core it can get. So background indexing runs at a 20% duty cycle: it works in short slices and rests in between. All servers together cost less than one core, and a project still finishes within an editor session.

While indexing is in progress, replies carry a progress block:

progress:
 filesInScope: 3510
 filesEmbedded: 1204
 pendingFiles: 2306
 percentComplete: 34

For projects larger than a couple of hundred files, you get only that block until half the project is embedded. A ranking drawn from a third of a codebase is not an early version of the real ranking. The worst duplication is most likely in the part not read yet, while the reply would look like an answer and invite acting on it.

Two things make this bearable:

Scope first. Put an include list in duplication.config.json before the first run. Fewer files, faster sync, and less vendored code in the results anyway.
Only the first sync is slow. Vectors are cached in SQLite keyed by content, not location. Moving a block, re-indenting it or adding a comment reuses the stored vector, identical blocks in twenty files are embedded once, and after a branch switch only what actually changed gets embedded again.

Try it

Node 22.5 or later.

git clone https://github.com/jgauffin/dry-mcp
cd duplication-mcp
npm install && npm run build
node dist/index.js download-model

Add it to .mcp.json in your project:

{
  "mcpServers": {
    "duplication": {
      "command": "node",
      "args": ["/path/to/duplication-mcp/dist/index.js", "."]
    }
  }
}

Optionally scope it:

{
  "include": ["src/**", "lib/**"],
  "exclude": ["**/*.generated.*", "**/migrations/**"]
}

Then ask your agent where the worst duplication is. If it tells you it is still indexing, that is the honest answer. Ask again in a few minutes.

I'd love to hear what it finds in your codebase, and especially where it is wrong.

A blank page and a green test: the bug an agent can't see

Jonas Gauffin — Fri, 25 Sep 2026 10:55:27 +0000

Fourth in a series on using @relax.js/core with a coding agent. This is about the failures that make no noise.

The blank element

A template engine has to decide what to do with {{user.naem}} when user has no naem. Throwing means one typo blanks the whole page, so like most engines this one renders an empty string and moves on. That is the right call for a user in a browser.

It is the wrong default for an agent. The agent's only view of the page is a test. It writes the component, writes the test, runs it, and sees:

it('passes_on_a_blank_element_because_nobody_read_the_errors', () => {
    const { content, render } = compileTemplate('<p>{{user.naem}}</p>');
    render({ user: { name: 'Alice' } });

    expect(content.querySelector('p')).not.toBeNull();
});

Green. The <p> exists. It is empty, and nothing said why. This test is in the example app on purpose, as the thing not to write.

One channel

Every failure the library detects goes through one function, reportError(), which builds a RelaxError with a message and a context object and hands it to whatever handler onError() registered. In the application that handler logs to your service or shows a toast. If nothing is registered, the error is still kept: window.relaxErrors holds the last fifty, and the first unhandled one prints a single line to the console naming that array. Once per page load. It is a signpost, not noise.

The design rule behind it, which the agent-facing docs state outright: diagnostics go in values, not in log lines. A human watches a console. An agent reads what a function returned or what a test printed. An error object with { expression, location } on it is something a test can assert on; twelve console.log lines describing a render are not.

In a test

captureRelaxErrors() from @relax.js/core/testing swaps in a handler that collects instead of throwing, and gives it back with restore():

let captured: CapturedErrors;

beforeEach(() => {
    captured = captureRelaxErrors();
});

afterEach(() => {
    captured.restore();
});

Now the same typo is a failing assertion, with the reason in the message:

it('a_mistyped_path_renders_empty_and_reports', () => {
    const { content, render } = compileTemplate('<p>{{user.naem}}</p>');
    render({ user: { name: 'Alice' } });

    expect(content.querySelector('p')?.textContent).toBe('');
    expect(captured.messages()[0]).toContain('Cannot resolve "user.naem"');
});

The testing skill says to assert captured.messages() is empty even in tests that are about something else, and every test in the example's page suite ends with that line. It is the cheapest assertion in the file and the one that catches the most.

The failures that produced no DOM and no error

Once the channel existed, I went looking for everything that used to fail without going through it. Version 1.8.0's changelog is the list. Four of them are in the example app as tests.

render() compares the context by identity. Mutate the object and render it again and nothing changes, because from the engine's side nothing did:

it('rendering_the_same_object_twice_changes_nothing_and_reports', () => {
    const state = { count: 1 };
    const { content, render } = compileTemplate('<p>{{count}}</p>');
    render(state);
    state.count = 2;
    render(state);

    expect(content.querySelector('p')?.textContent).toBe('1');
    expect(captured.messages()[0]).toContain('render() was given the same context object');
});

An agent coming from Vue writes exactly this and expects reactivity to notice. The message tells it what to do instead: pass a new object, render({ ...state }).

A handler needs parentheses. r-click="save" binds nothing:

it('a_handler_without_parentheses_is_not_bound_and_reports', () => {
    const { render } = compileTemplate('<button r-click="save">Save</button>');
    render({}, { save: () => undefined });

    expect(captured.messages()[0]).toContain('r-click must be a function call, got "save"');
});

The html tagged literal gives one instance per literal. Binding it twice re-drives the first one and returns an empty fragment, so the second card never appears:

it('binding_an_html_template_twice_redrives_the_first_instance_and_reports', () => {
    const { element } = mount(document.createElement('div'));
    const card = html`<p>{{name}}</p>`;
    element.appendChild(card({ name: 'Alice' }).fragment);
    element.appendChild(card({ name: 'Bob' }).fragment);

    expect(element.querySelectorAll('p')).toHaveLength(1);
    expect(element.querySelector('p')?.textContent).toBe('Bob');
    expect(captured.messages()[0]).toContain('This html template was already bound');
});

And a route pointing at a tag that was never defined fails at the moment the routes are defined, not later when someone navigates:

it('a_route_whose_tag_was_never_defined_fails_when_routes_are_defined', () => {
    expect(() =>
        mountRouting([{ name: 'missing', path: '/missing', componentTagName: 'profile-pgae' }]),
    ).toThrow("Component with tagName 'profile-pgae' is not defined in customElements.");
});

That last one throws rather than reports, because at definition time there is no page to keep alive and failing fast is free.

Strict when you want it

The template engine takes { strict: true }, and then every reported template error throws instead. I do not use it in application code, for the reason at the top: one typo should not blank the page for a user. In a test the capture is better than strict, because it collects everything instead of stopping at the first.

The remaining question is the one that bothered me most. Everything above happens when the template renders. The agent still has to write the test that renders it, with the right model, and remember the capture. The sixth article is about catching the typo before anything renders at all. Before that, the rest of the test seam: how the agent gets a page on screen without a browser.