Process · Delivery · Evidence
From a change
to a verified release.
I make the scope, technical decisions and checks visible so your team can understand a change and maintain it afterwards. The examples below come from my own GeoAtlas product; the release policy and tools are agreed for each project.
Discuss your project ↗
01 / The path of a change
A clear task.
A checkable result.
- Start from the user's task
Describe the scenario, constraints and acceptance checks: for example, find a parcel, compare records or print a page at the right scale.
- Give behaviour a clear owner
Keep domain rules near the product. Extract shared code when a stable contract or real reuse justifies the boundary; a library is a design choice, not a target count.
- Protect the change with useful tests
For behaviour changes, reproduce the problem or new expectation before implementation. Targeted mutation checks verify that a regression would fail the test. Content and visual changes need proportionate review and browser checks.
- Review the implementation and its seams
I inspect the diff, the affected user journey and interactions with neighbouring code. Review includes correctness, accessibility, maintainability and any limits the tests do not cover.
- Run the agreed release checks
Builds and browser suites run on CI. The required gate depends on the change and release policy. A fast gate, a full end-to-end suite and a nightly deployment check serve different purposes.
- Verify the deployed revision
Check that the intended version is serving, exercise the important path and keep reports or traces that make failures diagnosable. Agree on rollback or recovery before a risky release.
- Leave a usable handover
Record the decision, the checks that ran, known limits and remaining work. Documentation supports the next person; it does not replace a conversation when one is needed.
02 / A dated example
CI measurements
from GeoAtlas.
Recorded on 1 October 2026. These are observations from that project and runner, not estimates for your application.
- About 4 minutes for the fast gate: lint, unit tests, coverage, build and release of main. In this setup, a release could precede the full end-to-end result.
- About 15 minutes for the full verification gate, compared with about 31 minutes in the earlier configuration.
- 760 s compared with 1,055 s for the catalog's Playwright suite after moving to six workers. The recorded run had no failed or flaky test; this is not a guarantee for future runs.
- 187 s compared with 1,113 s for application coverage after changing coverage-map collection.
- A nightly deployment check ran both suites against the served revision and retained reports and traces.
The CI article explains the measurements and the trade-off between fast releases and requiring the full gate first.
03 / AI in the engineering process
Defined tasks.
Human responsibility.
I use AI coding agents for specified implementation tasks, evidence collection and named checks. Briefs define scope, files, constraints and the result to verify. Product, architecture and design decisions, substantive review and final acceptance stay with me.
An agent's report is a starting point for verification. I inspect the changes and evidence, including the revision and actual test result. A check that was not run is recorded as missing.
This workflow still needs judgment about the task size, data access and coordination cost. The article on coding agents describes the practical limits as well as the mechanics. The assistant article covers a separate question: how an agent behaves inside the product.
04 / Tools and handover
Evidence your team
can use.
In GeoAtlas, the toolchain includes Angular and Nx, Vitest, Playwright, axe and Jenkins. Versioned releases are activated atomically. Browser reports and traces are retained for diagnosis. Automated accessibility checks cover selected states; keyboard and usability review remain part of the work.
Your team may use different tools. The useful output stays the same: a scoped change, understandable code, relevant tests, written decisions and a clear account of what remains uncertain.
What would help your team deliver?
Describe the application, the bottleneck and the change you need.
contact@clearcraft.dev ↗