DEV Community: Jonas Gauffin

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.

No virtual DOM, nothing re-renders: the whole model in four rules

Jonas Gauffin — Tue, 22 Sep 2026 17:45:15 +0000

Third in a series on using @relax.js/core with a coding agent. This one is the model the agent has to hold in its head. It is short on purpose. Every code block below is from a small example app that runs under vitest; nothing here is sketched.

1. A component is a plain custom element

No base class. No decorator that registers it. extends HTMLElement, the native lifecycle, customElements.define at the bottom of the file.

export class ProfileHeader extends HTMLElement {
    private name!: HTMLElement;

    connectedCallback() {
        this.innerHTML = '<header><strong class="display-name"></strong></header>';
        this.name = this.querySelector('.display-name')!;
        document.addEventListener(ProfileSavedEvent.type, this.onProfileSaved);
    }

    disconnectedCallback() {
        document.removeEventListener(ProfileSavedEvent.type, this.onProfileSaved);
    }

    private onProfileSaved = (e: ProfileSavedEvent) => {
        this.name.textContent = e.displayName;
    };
}

customElements.define('profile-header', ProfileHeader);

Why it matters for an agent: the lifecycle is documented on MDN, which the agent has read more of than any framework's docs. And customElements.define('profile-header', ...) is a literal string, so the route table, the test and the HTML that use profile-header are all one grep away.

One trap I hit while writing the example, and it is worth knowing: if a test file imports the class only as a type (navigate<ProfilePage>(...)), the bundler elides the import, the module never runs, and the tag is never defined. Import the module for its side effect: import '../src/pages/ProfilePage'. defineRoutes fails fast with the tag name when this happens, which is how I noticed.

2. The lifecycle is synchronous

connectedCallback returns before anything you await in it has finished. Marking it async compiles, and the browser ignores the promise. This is the first habit an agent brings from ngOnInit and onMounted, where the framework at least knows you started something.

The pattern is: do the synchronous part, kick off the async part, and let the async part update the DOM when it lands. In the example app the profile page does its loading in loadRoute, which the router does await, so it looks like this:

async loadRoute(data: RouteParams) {
    this.userId = String(data.userId);

    this.appendChild(this.template.content);
    this.template.render({ heading: 'Your profile' }, { discard: () => this.load() });

    this.status = this.statusLine({ text: '' });
    this.appendChild(this.status.fragment);

    this.form = FormValidator.FindForm(this);
    this.validator = new FormValidator(this.form, {
        useSummary: true,
        submitCallback: () => this.save(),
    });

    await this.load();
}

Everything above the await is on the page before the request goes out. A test that mounts the component and asserts immediately sees the empty form; one that waits sees the data. There is a helper for the waiting, in the fifth article.

3. Nothing re-renders on its own

There is no reactive state. When data changes, update the DOM at that point. The header above does it with textContent. The page does it with a second, tiny template for the only part that changes after load:

private async save() {
    const profile = readData<Profile>(this.form);
    const response = await put(`/users/${this.userId}`, JSON.stringify(profile));
    if (!response.success) {
        this.validator.addErrorToSummary('Save', `The server rejected the change (${response.statusCode})`);
        return;
    }
    this.status.update({ text: 'Saved' });
    this.dispatchEvent(new ProfileSavedEvent(this.userId, profile.displayName));
}

The form itself is rendered once and never again, because every render writes value back into the inputs and would replace what the user is typing. The native form is the state. readData reads it, setFormData writes it. There is no mirror of the field values anywhere in the class.

This is the rule that costs the most when you come from Vue. It is also the one that makes the diff say what happens. An agent that adds a field to this page has to add the place where the field is updated, and a reviewer sees both in the same hunk.

4. Events are classes

Components do not call each other. The page dispatches, the header listens, and neither imports the other. The thing they share is the event class:

export class ProfileSavedEvent extends Event {
    static readonly type = 'profile-saved';

    constructor(
        public readonly userId: string,
        public readonly displayName: string,
    ) {
        super(ProfileSavedEvent.type, { bubbles: true });
    }
}

declare global {
    interface HTMLElementEventMap {
        [ProfileSavedEvent.type]: ProfileSavedEvent;
    }
    interface DocumentEventMap {
        [ProfileSavedEvent.type]: ProfileSavedEvent;
    }
}

Not CustomEvent with a detail bag. A class with properties, registered in the event map of whatever you listen on, so addEventListener infers the type and e.displayName is checked. I had to add DocumentEventMap while writing this, because the header listens on document; HTMLElementEventMap alone covers elements only. The compiler told me, which is the point.

Grep ProfileSavedEvent and you have every producer and every consumer in the codebase. That is the whole "shared state" story for a small app, and it is the one the first article promised: the connection between two places is a literal name the agent can search for.

What is deliberately missing

No store. No computed properties. No context or provide/inject. If a value is derived, compute it where the source changes and pass the result on. If two components far apart need the same data, the page that owns it places both, through slots, instead of threading it down. The library's docs/WhyRelaxjs.md argues each of these at length; the skill just says "do not".

Four rules. They fit in the core skill with room to spare, and the agent has them loaded before it writes a line. Next: what happens when the line it writes is wrong, and why nothing throws.

Skills, not docs

Jonas Gauffin — Sun, 20 Sep 2026 09:03:09 +0000

Second in a series on using @relax.js/core with a coding agent. The first piece made the argument; this one is about the first thing you do in a project.

Install the rules, not the manual

npx @relax.js/core init-agents

That writes seven files into .claude/skills/, one per area: the core model, then templates, forms, routing, services, testing and setup. Claude Code loads a skill when its description matches what the agent is doing. Other tools without skill support can be pointed at node_modules/@relax.js/core/skills/relaxjs/SKILL.md from their instruction file; the core skill links to the rest.

Each copy is stamped with the package version it came from. Run the command again after an upgrade and it lists the copies that are behind, and leaves them alone unless you pass --force. A skill is a snapshot, and a snapshot that describes an older library is worse than none, because the agent trusts it.

The border

The interesting decision was not to write the skills. It was deciding what does not go in them.

The library has a docs/ folder like any other. An agent could read it, and sometimes it should. But documentation is written for someone who already knows they need this API. It answers "how does this work, what is available".

A skill loads before the agent knows it has a problem. Its job is to overwrite a wrong default and route to the right doc. The skills/README.md in the package states two tests for where a sentence belongs:

Would an agent that never read this produce code that compiles, type-checks and does nothing? Skill. Would it merely not know a name? Docs.

Would the sentence need editing when the implementation changes? Docs. Only when the design changes? Skill.

The two must not overlap. A skill that accumulates examples is turning into a doc, and should hand off to one instead. The only thing a skill repeats from a doc is its filename.

What that looks like

Here is the whole "Do not" section of the core skill:

## Do not

- Reach for a state store, computed properties or a reactive wrapper. Update the DOM where the
  change happens.
- Add a component base class, a render loop or a diffing layer.
- Use `CustomEvent`, or `enum` where a `declare type` string union works.
- Duplicate native HTML. Use `<dialog>`, `<details>`, `<input type="date">` and friends before
  writing a component.
- Swallow errors. An empty `catch` is a bug.

Every line is a habit. None of them is a fact about an API. An agent that never reads this will write a store, a base class and a CustomEvent, and all three will compile.

Compare the forms skill, which opens with the one thing agents get wrong most:

## FormValidator owns the submit event

Its constructor attaches the listener. Do not add your own, and construct one even when you have
no validation rules, because taking over submit is what it is for. Supplying `submitCallback`
suppresses the native submit, so the page never navigates away.

Then a diagnosis, because skills are also loaded when something is already broken:

A form that still navigates away on submit means no `FormValidator` was constructed for it.

And at the bottom, the hand-off:

## Detail

- `@relax.js/core/docs/forms/form-page.md` for the end-to-end shape of an edit page. Start here
- `@relax.js/core/docs/forms/validation.md` for rules, the error summary and every option

init-agents rewrites those @relax.js/core/docs/ references to the real path of the installed package, so the agent can follow them without knowing where node_modules is.

Why the border holds up

I tried the other shape first: one big instruction file with everything in it. It rotted in two ways.

First, every sentence that described how something worked went stale when that thing changed, and there was no signal which sentences. Splitting on "does this change when the implementation changes, or only when the design changes" is exactly the signal: the docs get updated with the code, the skills get updated with the design, and the design changes rarely.

Second, a long file is context spent. A skill that is loaded on every UI task and carries an example of every option costs the same as the code the agent is supposed to be writing. Short skills that route to long docs let the agent spend its context on the problem, and pull the reference in only for the part it is actually touching.

The other consumer

I said in the first piece that greppability matters because agents navigate by search. The skills lean on that. When a skill says "see docs/forms/form-page.md", the agent opens the file. When it says "FormValidator.FindForm(this)", the agent greps it and lands in the source. A skill never describes a mechanism the agent cannot then find by name.

That is also the test I used when writing one. Pick any identifier in the skill and search the package for it. If the search lands on the thing being described, the sentence belongs. If it only lands back in the skill, the sentence is prose about a convention, and conventions are what agents guess at.

Next: the model itself, and why it fits on one page.

Why I stopped handing agents a framework

Jonas Gauffin — Sat, 19 Sep 2026 11:00:44 +0000

I have shipped SPAs in Vue and in Angular. Today most of the UI code in my projects is written by a coding agent, and the library underneath is one I wrote myself: @relax.js/core, a small Web Component library with routing, forms, templates and DI, and no virtual DOM.

That is a strange choice on paper. This series is about why it works, where it does not, and what I had to build to make it work.

The case against me

An agent has seen millions of Vue components and Angular modules in training. Its first draft of a Vue SFC is usually right. Its first draft of a Relaxjs component is usually wrong :O It carries habits over. It marks connectedCallback as async and expects the browser to wait. It reaches for a reactive store. It adds its own submit listener next to the one the library already owns.

The core skill that ships with the library opens with this sentence, because it is the failure mode:

Patterns carried over from React compile, type-check and do nothing.

I have not written React myself, but I have watched agents write it unprompted, and it is what they reach for when nobody tells them otherwise.

There is a second point against me. Angular's compiler type-checks templates. vue-tsc does the same for Vue SFCs. A typo in a template is a build error before anything runs. In a library where the template is a string, {{user.naem}} is just a string until the page renders. I will come back to that in a later article, because it bothered me enough to fix.

So: worse priors, and until recently weaker static checking. Why bother?

What an agent actually has

An agent cannot open a browser. It reads files, greps for names, runs the type checker and runs the tests. That is the whole feedback loop. Anything that is only observable at runtime is invisible to it.

Now think about the bugs I spent the most time on in Vue and Angular, the ones that survived review:

A watch that fired one tick later than I thought, so the DOM showed the previous value.
A computed that never recalculated because the dependency was read behind a condition.
Change detection that did not run because the update came from outside the zone.
An ngOnInit that assumed an @Input that arrives on the next cycle.

None of these are visible in the file where the symptom appears. The cause is in the framework's scheduler, and you find it by opening DevTools, setting a breakpoint and watching. An agent cannot do any of that. It will reason about the file it opened, conclude that the file is correct, and start changing things speculatively. That is the most expensive thing an agent does: producing plausible edits in the wrong place.

Explicit code does not have that class of bug. When the update is this.nameSpan.textContent = user.name at the place where user changed, the update is where the change is. A reviewer can verify it by reading. So can an agent. Nothing decides later whether it ran.

What helps the agent

The usual pitch for a small library is "the whole thing fits in the context window". True, and beside the point. An agent rarely needs to read a framework's source; it needs correct memory of the framework's behaviour, and that memory rots with every major version.

The three properties that matter:

Failure locality. The bug is in the file that shows the symptom. No scheduler, no dependency graph, no zone.

Greppability. A typed event class is one grep away from every producer and every consumer. r-click="save()" in a template is one grep away from save. Agents navigate by search, and a connection that is not a shared literal name is a connection the agent will guess at.

Reviewability. The diff says what will happen. Not what the framework will decide to do with it.

What I had to build

Small and explicit is not enough on its own. Three things turned "an agent can in principle work here" into "an agent does work here":

Skills, not docs. The library ships a set of short files an agent loads before it starts, and every sentence in them is something an agent gets wrong from habit. The docs explain how things work; the skills say what you will get wrong. The border between them is stated, and it is worth reading.
Silence turned into errors. A template that cannot resolve a path renders an empty string. For a human that is a blank spot on the page; for an agent it is a green test. Every such quiet failure now reports through one error channel, and a test helper turns the channel into assertions.
A checker. npx @relax.js/core check resolves every template expression against the TypeScript types at the call site and prints tsc-style lines. That closes most of the gap with Angular's template type-checking, and it does so without a compiler in the build.

Then the test seam: mount(), flush(), fakeServer(), mountRouting(). The agent verifies by running vitest, not by asking me to click.

When I would still pick the framework

If the agent's zero-shot correctness is the whole game, meaning nobody reviews the diff and no skills get loaded, Vue or Angular wins on priors alone. If the app is large with deeply interdependent state, the reactive engine earns its complexity, and I said as much in the library's own README. If you need SSR, there is nothing here for you.

For a small-to-medium SPA where a human reads what the agent wrote, I have found the explicit model cheaper every time, and the rest of this series is the evidence.

Next: what a skill is and why it is not documentation.

Live API specs for coding agents

Jonas Gauffin — Sun, 30 Aug 2026 12:33:00 +0000

Live API specs for coding agents

An agent writing frontend code has to know the backend's API. It has three options. It can read the backend source and work out from scratch what the service already publishes. It can ask you, which promotes you to API documentation. Or it can swallow the entire OpenAPI document in order to use one route out of it.

Then it does the same thing again tomorrow, against a stale swagger.json you exported last week.

docs-mcpserver takes the spec straight from the running service, caches it, and serves it one operation at a time.

The config

{
  "cacheDir": "./cache",
  "libraries": [
    {
      "name": "orders-api",
      "description": "Order handling service",
      "sources": [
        {
          "type": "url",
          "origin": "https://localhost:5001/openapi/v1.json",
          "kind": "schema",
          "name": "orders"
        }
      ]
    }
  ]
}

npm install -g docs-mcpserver
claude mcp add docs -- docs-mcpserver --config /path/to/dev-docs.json

That is the whole setup.

One operation, not the whole spec

The agent lists the definitions in orders, picks the one it needs, and fetches that. For an OpenAPI document the path operations are exposed as definitions named GET /orders/{id}, so it can also search by keyword.

A few hundred tokens for the operation it is writing against, instead of the entire document. That keeps working as the service grows, which a pasted spec does not.

The backend does not have to be running

Every call is answered from the cached spec, never from the network. The fetch happens on startup and then in the background while you work, so an endpoint you added 20 seconds ago is already visible.

Start the backend once, shut it down, and keep building the frontend. The agent still has real routes and real payload shapes. If the service is down, or answers with something that is not a spec, the last known-good copy keeps being served.

Code and issues: github.com/jgauffin/dev-docs-mcp. On npm as docs-mcpserver.

Giving AI agents knowledge they were never trained on

Jonas Gauffin — Thu, 14 May 2026 22:02:53 +0000

I love coding my own stuff, and my clients typically have lots of internal specifications and libraries to use.

But since LLMs haven't been trained on that, it's hard to get them to code accurately using those specs, libraries, or frameworks.

You can, of course, let the agents parse everything, but that wastes tokens and your patience :)

The same goes for well-known libraries, but you are stuck on a specific version that you must follow. You don't want it to guess the API.

docs-mcpserver exists to deal with both.

What it is

It is an MCP server that provides an agent with accurate knowledge of a framework or specification using documentation as the medium. It reads three kinds of docs:

Markdown docs — your *.md files.
API reference — C# XML documentation, or TypeDoc JSON.
Schema — JSON Schema, OpenAPI 3.x, Swagger 2.0.

What the agent gets out of it is the same in every case: the real names, the real
signatures, the real shapes. Sources can come from a
local folder or straight from a GitHub URL. A single
server instance can host several libraries side by side. For instance, your in-house framework, a client's framework, and a specific version of some public library.

The agent picks which one to query.

I personally have used it to code against a specification called DATEX (traffic information for roads), which is HUGE, my own SPA library, and against sound format specifications for a sound app I'm building.

Why not just give the agent the files

You could point the agent to the folders and let it read them. The MCP server does a few things that raw file access does not:

It is sandboxed. Each source is scoped, with path-traversal protection. The agent reads what you exposed, nothing else on the disk.
It reads in pieces. Instead of loading a 4000-line reference file, the agent asks for the table of contents, then pulls the one chapter it needs.
It searches properly. Dedicated search tools with regex and glob support, instead of the agent improvising its own grep.
It is self-describing. With several libraries configured, the agent calls one tool to discover what is available. You do not have to spell out every path.
GitHub works without cloning. Give it a repo URL and it handles the rest.

The multi-library part is the point. Instead of running several MCP servers for
documentation, you get one with a small toolset. No token waste.

Setting it up

Install and build:

npm install
npm run build

The quick way, a single folder:

docs-mcpserver ./docs --name "My Docs"

For the real use case — several libraries — use a config file. Here is an
in-house framework served from disk, next to a pinned version of a public
library pulled from GitHub:

{
  "name": "dev-docs",
  "description": "Frameworks the model has not been trained on",
  "cacheDir": "./cache",
  "libraries": [
    {
      "name": "acme-core",
      "description": "Our internal application framework",
      "sources": [
        { "type": "disk", "origin": "./frameworks/acme-core/docs", "kind": "docs" },
        { "type": "disk", "origin": "./frameworks/acme-core/api",  "kind": "api"  }
      ]
    },
    {
      "name": "somelib-3.2",
      "description": "SomeLib, pinned to v3.2.0",
      "sources": [
        {
          "type": "github",
          "origin": "https://github.com/someorg/somelib/tree/v3.2.0/docs",
          "kind": "docs"
        }
      ]
    }
  ]
}

Start it with the config:

docs-mcpserver --config dev-docs.json

And register it with Claude Code:

claude mcp add mydocs -- node /path/to/markdown-docs-mcp/dist/index.js --config /path/to/dev-docs.json

For private GitHub repos, set GITHUB_TOKEN in the environment.

What the agent actually sees

Each library exposes tools based on the kind of its sources:

docs — get_doc_index, get_sub_index, read_doc_file, get_file_toc, get_chapters, search_docs.
api — get_api_index, get_api_type, get_api_member, search_api.
schema — list_schemas, list_definitions, get_definition, search_definitions, search_all_schemas.

A typical run looks like this. The agent calls list_libraries and sees
acme-core and somelib-3.2. It needs to know how acme-core handles
configuration, so it calls search_docs with library: "acme-core", finds the
right file, asks for its table of contents with get_file_toc, then pulls the
one relevant section with get_chapters. It answers the question without ever
loading the whole file.

When multiple libraries are configured, every tool takes a library parameter.
When there is only one, the parameter disappears, and the tools behave like a
plain single-library server.

The same applies to schema sources. For an OpenAPI spec, path operations show up
as definitions named like GET /pets, so the agent can ask for one endpoint
without reading the whole document. Useful when you want the agent to call your
API correctly rather than guess at the shape of it.

Generating the API input

One thing worth knowing up front: the api pipeline does not read source code.
It consumes a generated documentation file.

TypeScript / JavaScript — use TypeDoc's JSON serializer: typedoc --json api.json src/index.ts. Point the source at that .json file. The markdown output from typedoc-plugin-markdown is not supported — it has to be the JSON serializer output.
C# — enable <GenerateDocumentationFile>true</GenerateDocumentationFile> and point the source at the generated *.xml file, or the build output folder that contains it.

What it does not do

It does not read source code. If you want API reference, you generate the doc
file first, as above.

Try it

The code is on GitHub, or on npm as docs-mcpserver.

Feel free to leave feedback, or check my other MCP servers on GitHub.

Exception handling explained

Jonas Gauffin — Thu, 10 May 2018 11:33:24 +0000

This article explains what exception handling is and how it differs from
traditional error handling with error codes. The article does not get
into usage or exception classes, but only to explain their purpose.

Let's start with errors.

A brief introduction to error

From the dawn of programming, error codes have been used to deal with errors in applications. An error code is used to indicate if the
executed function was successful or not.

Here is a simple example:

public bool SaveDefaultAccount(string userName, string accountName)
{
    int userId = GetUserIdFromName(userName);
    if (userId == -1)
        return false;

    int accountId = GetAccountFromName(accountName);
    if (accountId == -1)
        return false;

    return StoreDefaultAccount(userId, accountId);
}

The example illustrates that when you use error codes, it is the API
consumer that must abort if something fails. You might, but how about
the rest of the team, or those who maintained the application before
you? It is like you would retire the entire police force and expect
all citizens to behave and be good law abiding citizens.

One developer could have been lazy and just written (or refactored) the
code as:

public bool SaveDefaultAccount(string userName, string accountName)
{
    int userId = GetUserIdFromName("Arne");
    int accountId = GetAccountFromName("Savings account");
    return StoreDefaultAccount(userId, accountId);
}

The problem is that the code looks perfectly legal, but silently ignores
errors. If you for instance mistakenly add a white space after all
account names on the account selection page, the code above starts to
fail silently. What's worse is that you will not know about it until
code dependent upon the default account starts to fail, and that can be
after a while. Tracking down that subsequent error can be challenging,
primarily if the default account is set in different ways.

Error codes are easy to get started with and can be quite powerful. Even
modern languages like Go-lang uses errors instead of exceptions. Here is
a go snippet:

f, err := os.Open("filename.ext")
if err != nil {
    log.Fatal(err)
}

While errors are easy to understand and use, they have three
significant drawbacks:

They do not convey context

This section is for languages that only uses error codes.

For instance, error code 2 means "File Not Found" in Windows. There is
no way to state which file nor other information that might help you to
understand why the file was missing. Error codes are just that. Codes
that indicate a specific error, without context or clues.

The problem with that is that it is hard to understand why or under what
circumstances that the error occurred. The Windows API solves this by
introducing a method called GetLastError() which is used to get more
information about the error.

OFSTRUCT buffer;
HFILE hFile = OpenFile("d:\\sample.txt", &buffer, OF_READ);
if (hFile == HFILE_ERROR)
{
    // all this is required to get the error message.
    // you typically add it to a separate function

    // Get the error code, as hFile only indicates an error
    // but not which one.
    var errorCode = GetLastError();

    // Get the generic error message which
    // represents the above error code.
    LPVOID lpMsgBuf;
    LPVOID lpDisplayBuf;
    FormatMessage(
        FORMAT_MESSAGE_ALLOCATE_BUFFER | 
        FORMAT_MESSAGE_FROM_SYSTEM |
        FORMAT_MESSAGE_IGNORE_INSERTS,
        NULL,
        errorCode,
        MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),
        (LPTSTR) &lpMsgBuf,
        0, NULL );
}

My point is that an error code is not enough when you want to
solve the error.

The burden is on the function caller

It is safe to say that all applications have errors, it is exceptionally
rare (pun intended) that errors can be ignored. Ignoring errors might
seem to work, but sooner or later consequential problems will surface.
It will be much harder to find the root cause since the found error is
just a consequence of the first one. Any kind of "fix" is just a
workaround which clutters the code base but does not prevent the root
cause from happening again.

It is crucial that all errors are handled in your code. When you use
error codes, it is so easy to ignore or forget errors. Had a tight
deadline? Wrestled with an obscure bug or incomprehensible requirements?
Those situations make it so easy to take a shortcut. If not all
developers on your team have the same discipline, errors will get
ignored.

Enter exceptions

Exceptions are for exceptional situations. If something didn't go as
expected, you got an exceptional situation.

Sounds easy, huh?

But what does that mean?

An exceptional example

If you expect that something can fail, you should guard against that
situation.

Here is an example:

Let's say that you love shopping the newest and hottest technical
gadgets. When the new gadget is released, you want to be first.

Scenario 1

If you are like most of us, you can probably not just go on a shopping
spree. You need to make sure that you have enough money.

Check your bank account.
Go shopping.
Pay

Scenario 2

However, if you are fortunate enough to have plenty of money, you can
go shopping directly:

Go shopping.
Pay

The difference

In the first scenario, we have a known issue that we need to deal with:
A money limit. Therefore, we always need to check that we have enough
money. In the second scenario, we should have enough money.

What happens if someone has hacked us in scenario 2:

Someone hacked us
Go shopping
Pay <-- Failed, no money

In that case, we got an exception, since it is a case that shouldn't
happen since we expect to have enough money.

That is an exceptional situation.

Why can't we always write the code like in scenario 1?

First, it's about communicating intent. We mostly get a set of business
requirements that we should fulfill. They tell us what to expect when
implementing different use cases. If we go and add many checks for
things that might, but should not, happen we lose the connection between
our use cases and the code. It will be hard to tell the intent of the
code, which in turn lead to assumptions and in the end decreased code
quality.

Second, if we add many checks we are coding workarounds as the real
problem is that our account was hacked, not that we could not pay. By
adding checks and abort instead of paying we are hiding that fact.

What exceptions are

Exceptions are for situations that wasn't considered when defining what
the application should do. When writing a messaging library for message
queues you expect to receive complete messages, but when you write one
for TCP you expect to receive partial messages. What's exceptional in
one case doesn't necessarily have to be exceptional in another.

If you would open a file there are several errors that can happen.
Non-existent directory, file is missing, access denied, partial file,
etc. All those errors are known to most programmers, so they are not
exceptions, right?

Wrong. In most cases, they are exceptions. Because you typically do
expect that a file exists and that it's complete and readable. Well, if
you are writing a data forensics application, most of those errors are
expected and should be dealt with (and therefore not exceptional cases).

Exceptions exist to prevent your application from doing something stupid.

It's crucial for you to understand that. Don't think of exceptions as
something you can use to control your application when coding. Think of
exceptions as a mechanism to guard against your application doing
something wrong/unexpected.

Exceptions exist to help you fix problems in the future

Since exceptions are not a flow control mechanism, they do add little
value when executing your code (previously described point excluded).

However, writing informative exception messages makes it much easier to
correct future bugs, since they add context to the error. Always try to
do so, your future self will thank you for it.

Code example

Let's take the same code as was found in the beginning of this article,
but changed to use exception handling instead.

public void SaveDefaultAccount(string userName, string accountName)
{
    int userId = GetUserIdFromName("Arne");
    int accountId = GetAccountFromName("Savings account");
    StoreDefaultAccount(userId, accountId);
}

As you can see, the method now returns void as it does not need to
indicate that everything went successfully. Nor does it need to validate
error codes from the called methods. One can safely assume that an
exception abort the processing if the expected result cannot be
guaranteed.

In fact, in most cases, we do not have to care if exceptions are thrown
at all. Remember, exceptions are used to communicate that something
unexpected happened. If we cannot predict it, how on earth could we be
able to handle the exception?

Let's look at the StoreDefaultAccount method. The most important thing
to understand is that the method says that a default account should be
stored successfully. Since that is the method promise, we must throw an
exception every time we find something that would prevent the default
account from being stored.

public void StoreDefaultAccount(int userId, int accountId)
{
    if (userId <= 0)
        throw new ArgumentOutOfRangeException(nameof(userId), userId,
            "A valid user id must be specified.");
    if (accountId <= 0)
        throw new ArgumentOutOfRangeException(nameof(accountId), accountId,
            "A valid account id must be specified.");

    var account = _accountRepository.GetById(accountId);
    if (account.OwnerId != accountId)
        throw new InvalidOperationException($"User {userId} do not own account {accountId}.");

    var user = _userRepository.GetById(userId);
    user.DefaultAccount = accountId;
    _userRepository.Update(user);
}

The first two exceptions are used to mitigate errors like parse errors
or invalid data.

The third exception is for a business rule. We may only use the user's
own accounts as default accounts.

_accountRepository.GetById(accountId); will in turn throw an
exception if the given accountId do not exist in the database since the
method name states that an account should be fetched.

Summary

The purpose of exceptions is not to allow you to take different actions
depending on if something failed or not. i.e. they are not a flow
control mechanism. Instead, exceptions are used to make sure that your
application delivers the expected result (or die trying).

With that in mind, I hope that you find them as useful as I do. With
the right mindset (and using exceptions) you can save much time since
you do not have to track down why your database has a lot of data
inconsistencies (which leads to bugs later).

This article is part of our exception handling series. To learn more, visit our website.