00Software engineer / 2026

From idea
to system.

I'm Andrew. I build complex software end to end, and I'm shaping how engineers build with agents.

INTERFACES → SYSTEMS → AGENTS

GitHub ↗LinkedIn ↗Email ↗

FIG. 00One idea. Every layer. A better way to build.

FIG. 01Separate layers. Connected decisions.

Build from durable data to the interface, then follow a request through the system.

01Software architecture

Start with the
whole picture.

A useful product starts with a person trying to do something. I follow that thread through the interface, the API, the data, and the work happening behind the scenes.

Building across those layers lets me make the tradeoffs together: what should feel immediate, what can happen in the background, and where a simple boundary will save complexity later.

How I design systems

I make service boundaries, data ownership, and failure paths explicit. APIs give each part a clear contract; background jobs keep longer work separate from the request.

I consider performance and scale alongside maintainability. Queue behaviour, database access, and compatibility across releases shape the design.

02Verification

Give agents room.
Keep judgment.

Agents change how much work an engineer can set in motion. They also make the shape of that work matter more: a clear goal, a bounded responsibility, and a way to check the result.

I design workflows where independent work can happen in parallel, then come back together through tests and review. I stay responsible for the decisions and the software we ship.

Where engineering judgment lives

I decide what to build, where to draw the boundaries, and what evidence would make a change acceptable. An agent needs that context as much as another engineer does.

Tests catch specific failures. Review asks whether the change solves the right problem and fits the surrounding system. Both belong in the workflow.

FIG. 02More work in flight. A clear way to accept it.

Send three bounded tasks along separate routes, then bring the work together for verification.

FIG. 03Keep the progress. Resume the unfinished work.

Two steps are saved. Interrupt the worker and watch the remaining step recover.

03Reliable execution

Expect interruption.
Build a way back.

Once work crosses services, failure becomes part of the design. A worker can disappear after doing the work but before reporting it. A retry can arrive while the first attempt is still running.

I use durable state, clear ownership, and repeatable operations to make recovery understandable. The next attempt should know what already happened and what remains to do.

How I handle interruption

A checkpoint records completed work. A lease establishes who owns the next step. A stable operation key lets a retry recognize an existing result instead of creating it twice.

I also account for mixed versions during releases. Compatibility checks and repeatable migrations make those transitions easier to reason about.

FIG. 04Inspect the pattern. Rerun the change.

Scan the task grid to reveal a pattern of passes and failures. Illustrative results.

04Learning from results

Make the result
teach us something.

A convincing answer is only the beginning. I look at the patch, the checks, and the work that actually happened. Did the agent satisfy the requirement? Did its tests exercise the behavior that matters?

Repeatable evaluations turn those questions into feedback. I inspect the failures, change the workflow, and run the same tasks again so I can see what improved and what still needs attention.

How I learn from a run

I start comparisons from a known revision, give runs the same task, and check the resulting patch. Critical requirements and verification matter alongside the outcome.

Traces connect model steps, tool calls, errors, and delivered results. They also show when evidence is incomplete.

05Engineering practice

Build the software.
Improve how we build.

That brings me back to the engineer using the system. I want the next person to understand the boundaries, trust the checks, and pick up the work without reconstructing every decision.

My work connects those two concerns: software that holds together from interface to infrastructure, and agent workflows that help engineers build it with clarity and control.

How I make the process reusable

I make useful context part of the handoff: the goal, the decisions, the actual change, and the evidence behind it.

The result is something another engineer can inspect, continue, and improve.

From ideato system.

Start with thewhole picture.

Give agents room.Keep judgment.

Expect interruption.Build a way back.