Mark Hingston · Senior Software Engineer

Building reliable software around uncertain systems.

I build backend and AI-enabled systems, with a particular interest in making agentic software reliable: evaluation, context, tooling, orchestration, and simple engineering mechanisms that work.

I’m interested in the engineering required to make LLM-based systems predictable enough to use in real software — where probabilistic reasoning belongs, where deterministic code is better, and how the two can be made to work together.

01 Selected work

Projects

All projects

agent-skills

Active catalogue; used as the main proving ground for reusable agent-engineering workflows.

A catalogue of reusable skills and engineering workflows for coding agents.

Skillet

Runnable v1 single-node vertical slice; intentionally stops short of becoming an execution harness.

A lightweight registry and distribution boundary for reusable agent skills.

Axon

Research candidate: gateway and reproducible pipeline are implemented, but production routing quality is not established.

Research into provider-independent routing of AI requests by capability, reasoning effort, and constraints.

Orchestrator

Working experimental implementation with end-to-end success, failure, and recovery paths.

Experiments in durable coding-agent orchestration using a deliberately small substrate.

02 Working notes

Recent notes

All notes

Deterministic where possible

A useful boundary for AI systems is to keep judgement in the model and move invariants, validation, and repeatable transformations into code.

  • reliability
  • agentic-systems

Evaluation is system design

Evaluation becomes more useful when it is designed with the workflow, not added after the model already appears to work.

  • evaluation
  • llm-systems

Convergence over capability

The next framework, agent, or tool is only useful when it resolves a concrete blockage better than the mechanism already in hand.

  • software-design
  • developer-tooling

03 Working principles

A few defaults

All principles
  1. Prefer the smallest durable solution.

    Solve the current problem in a way that can survive contact with the next one, without building the next five systems in advance.

  2. Use deterministic code where the answer can be deterministic.

    Models are useful for ambiguity and reasoning. Validation, invariants, state transitions, and repeatable transformations usually belong in code.

  3. Treat evaluation as part of the system.

    If a behaviour matters, define how it will be observed, reproduced, and judged before relying on it.

  4. Prefer a working vertical slice over framework comparison.

    A small end-to-end path exposes more useful constraints than an expanding catalogue of plausible technologies.