# what self improving coding should mean

2026-09-30, updated 2026-09-30

A correction should survive the chat where you made it. Here is what Wayari can remember for the next task, and what that does not prove.


You tell an agent to use the repository's existing error format. It fixes the change. A week later,
a fresh session invents a different format, and you give the same correction again.

The correction helped one task. To help the next task, it needs to become something the next agent
can read.

That is the practical meaning of self improving coding in Wayari. Your repository can carry its
instructions and lessons forward. The underlying models do not train themselves, and a finished
job is not proof that the next job will be better.

## keep the rules beside the code

First-use repository setup adds a shared `WAYARI.md` guide, standing orders and a taste file. Existing
agent guides point to the shared instructions. Setup adds its marked blocks without overwriting
what you already wrote.

Standing orders hold decisions that should apply again. For example:

```sh
wayari standing add "Use the existing API error format for new endpoints."
```

Taste holds what the repository's design should feel like. Both are useful because they are explicit
and inspectable. A person can correct a rule instead of hoping the right fragment survives inside
a long conversation.

## keep the observation, too

An instruction tells the next agent what to do. A finding tells it what happened and where to look.

```sh
wayari finding src/api/errors.ts "The new endpoint returned a different error shape from the existing endpoints."
```

The persistent thread keeps the repository's record across sessions. `wayari thread` reads it;
findings stay pinned to paths so later work can find the relevant observation.

Write what was observed. "The test timed out when the service was offline" gives the next task
something to reproduce. "Make the tests better" does not.

## turn a useful lesson into a reusable skill

Some work teaches a procedure worth repeating: how this repository adds an endpoint, checks a
migration, or verifies a visual change.

`wayari promote <channel> --as <name>` can draft a skill from a completed channel. The draft stays
on the channel branch for a person to finish. It is an opportunity to turn a lesson into instructions,
not an automatic endorsement of everything the previous agent did.

A skill should name when to use it, the work it requires and the evidence that says it succeeded.
An anecdote becomes useful only when another session can act on it.

## check whether the next attempt improved

A stored lesson proves that something was remembered. It does not prove that the lesson helped.

For a recurring task, compare the next result with the earlier one: did the same correction recur,
did the check fail again, and how much human intervention did the work need? Wayari records gate
attempts, interventions and routing outcomes that can support that investigation. Keep the sample
size beside any result you report.

The useful promise is that the next agent can read what earlier work learned. A stronger promise,
such as "every PR gets better", needs evidence from repeated work.

You can use those records in [Burst at your desk or Sunrise while you are away](/blog/burst-and-sunrise).
The lessons belong to the repository in both cases, and [the review still comes before the merge](/docs#self-improving).


[HTML version](https://wayari.com/blog/what-self-improving-coding-means)