Software engineer
Peter Wilkins
Functional backend engineer for complex regulated domains.
I reduce uncertainty in complex systems: payment systems, billing workflows, immutable data models, executable rules, local-first tools and AI-augmented engineering systems.
My strongest work is at the boundary between domain understanding, communication and architecture: finding the durable facts, separating concerns, making trade-offs explicit, and explaining systems clearly enough that other people can make good decisions.
Highlights
What to remember
- Ten years building backend systems across finance, energy, healthcare, intelligence and SaaS.
- Strongest at reducing uncertainty in complex systems: explicit data, events, boundaries and decisions.
- Functional-programming taste: immutable records, small deterministic cores, composable tools.
- AI-augmented engineering practice: agents accelerate implementation, while human judgement owns direction and acceptance.
Career Evidence
Difficult production problems
These are the production stories behind the headline CV: regulated systems, legacy constraints, ambiguous ownership, real users, and deadlines that did not wait for a clean rewrite.
Funding Circle: Confirmation of Payee
Delivered Confirmation of Payee support from planning and implementation through release and production operations. Designed a background refresh/cache path for awkward provider edge-case data, keeping the payment journey fast while still handling building-society and online-bank exceptions. After release, customer-service calls about fraudulent or erroneous payment setup all but disappeared.
Funding Circle: Kafka operability
Simplified an over-abstracted Kafka integration by replacing a bespoke wrapper with direct Java interop. Reduced hidden behaviour, made JVM/Kafka failures easier to diagnose, and improved the maintainability of backend services.
OVO: billing explainability
Helped design and implement a Kafka streaming service that combined millions of smart-meter readings with account data, tariff data, payment data and customer lifecycle events into coherent billing-domain events. The work supported customer-service explainability, billing and downstream consumers.
Polecat: taxonomy platform rebuild
Took ownership of a Clojure/Datomic area after the original Clojure developers had left. Evaluated and championed Datomic, prototyped the approach, and helped deliver a GraphQL-backed taxonomy system whose temporal model made change detection cheap and UI interactions dramatically faster after peer warm-up. Trade-off understood: better modelling and developer outcomes, more operational moving parts.
Citi: stability under churn
Reverse engineered and maintained a Clojure risk tool for a Tier-1 investment bank while external platform dependencies were being deprecated. The hard part was not simply the port: there was little usable documentation, no clear product ownership, scarce domain access, huge opaque payloads and legacy behaviour that could not automatically be trusted. Substantially implemented a Kotlin port, diagnosed mismatches caused by legacy bugs and inconsistent distributed object stores, and proposed a bounded deterministic design. The experience reinforced a core lesson: once the specification is lost, every future change becomes slower, riskier and more expensive.
Mayden: legacy confidence
Worked in a large NHS patient-management codebase with a decade of evolving PHP styles. Replaced a brittle drag-and-drop configuration workflow with a deterministic spreadsheet importer, removing manual data-entry errors and problem code. Introduced a black-box golden-record regression test suite that exposed long-standing defects and gave the team confidence to modify a decade-old legacy codebase safely.
Professional Experience
Plain work history
Architecture Evidence
Architectures, not just projects
Instead of treating projects as trophies, I use them as evidence of architectural judgement: what I chose to make explicit, deterministic, local, resumable, testable, or human-reviewed.
Architectures I have known and loved
Datomic and immutable data
Temporal queries and immutable facts are a powerful fit for audit, explanation and change detection.
Unix-style composable tools
Small tools with explicit inputs and outputs scale better than clever objects with private moods.
Event streams with domain language
I like evented systems when events are named after real domain happenings, not incidental processing steps.
Local-first replicas
For personal tools, the device needs to keep working and keep evidence even when sync, auth or networks fail.
Painful architecture lessons
Pipeline as source of truth
Recomputed state is useful; it should not silently replace the bounded events that actually happened.
God objects and feature soup
When one surface owns data, workflow, permissions, rendering and side effects, every change becomes political.
Premature cleverness
Any clever tool that has not earned its keep becomes another thing the human has to remember.
AI as engineering loop
WhisperWayland
Capture, VAD, conditioning, chunking and provider choice are separate measurable stages.
Shiny Art Shop
AI image generation is compared against deterministic ImageMagick rendering so design feedback has a stable reference.
CNC Workshop Tools
CAD and CNC experiments are kept simulation-first, with explicit assumptions before anything touches a machine.
Executable rules and field evidence
RegenOS
Grant schemes, evidence requirements and restoration interventions are modelled as explainable work packages.
Foil Board Toolkit
A parametric generator should encode relationships and design intent, not clone existing boards.
AI Engineering
Human-agent engineering
Most of my recent work was built in collaboration with AI agents. I do not treat agents as magic code generators or autonomous replacements for engineering judgement. The useful pattern is symbiosis: agents accelerate research, implementation, test generation and review; I provide product direction, architectural taste, domain judgement, acceptance criteria and the decision about what is actually worth building.
This matters because every useful improvement in the workflow can now become software quickly: a small parser, a regression skill, a status dashboard, a reviewer, a resumability drill, or a better handoff. The loop compounds.
That bootstrapping effect feels like a natural, efficient and true way to work. Nature did not start with a finished ecosystem; small loops made the next loops possible. Computers boot the same way: a tiny trusted program loads a larger one, which loads the useful system. Human-agent workflows can do that for engineering. A tiny improvement becomes a script, then a skill, then part of the environment, so yesterday's friction becomes tomorrow's leverage.
- Grill Me
- Turn fuzzy intent into one-question-at-a-time decisions before implementation.
- Treat Me Like I'm Five
- Reduce setup, hosting and debugging work into one clear path with exact links, values and steps.
- I'm Lazy
- Prefer direct action over advice: automate the small chore, run the check, update the file, then report the result.
- Hickey Decomplex Review
- Separate tangled concepts before an agent turns feature soup into code.
- Cut The Crap
- Delete dead experiments, duplicated surfaces and clever machinery that has not earned its keep.
- Reality Check Docs
- Compare product claims with what the software actually does.
- Bug To Regression
- Recreate vague complaints as tests, then fix the root cause.
- Review Merge
- Treat junior-agent PRs as real engineering work: inspect, test, challenge and merge only when safe.
- Handoff
- Make work resumable when the thread, model or machine changes.
Design Principles
How I tend to shape systems
Real events before derived computations
A real-world event is usually bounded: a payment was requested, a note was captured, a photo was attached. Computations can expand without limit when upstream teams alter floats, recalculate values or reinterpret meaning. I prefer events as source of truth and projections as replaceable views.
Types at the boundary, tests in the core
Clever type systems are most valuable where data crosses trust boundaries. Inside the core, I prefer small functions, simple records and tests that prove the behaviour. Zod is a good fit: validate edges, document shapes and generate confidence without turning the whole codebase into type ceremony.
Architecture first, project names second
The interesting part of a project is rarely the feature list. It is where the boundary sits, which state is authoritative, what becomes deterministic, what remains human-reviewed, and which abstractions survived contact with reality.
Fail early enough to learn cheaply
A stalled project is not always a failure; often it found the missing truth. JobDone taught me that a task app can quietly become WhatsApp with receipts. Field use taught me the divide between programmer workflows and people working in mud, wind, vans, kitchens and fields.
Good, Bad, Ugly
Things learned rather than things done
JobDone: real people do not want software homework
Building JobDone exposed a programmer instinct: model everything, then ask users to comply. In the field, the useful shape looked more like WhatsApp, receipts, photos, voice notes and habit. The product lesson was to meet people where work already happens.
Continuum: source logs are necessary but not sufficient
Continuum keeps returning to the same truth: capture first, then curate. Raw logs preserve evidence, but front-facing material needs edited summaries, redaction and links back to source where appropriate.
RegenOS: language beats dashboards
Farmers and landowners do not start with a database schema. They start with wet corners, ditches, blocked tracks, soil, grants, risk and time. The software has to speak that language before the knowledge graph matters.
AI coding: nice-to-haves become feedback loops
Agentic coding changes workflow economics. A small script, visualiser, skill or status fix no longer has to sit on a backlog for a free afternoon; it can be knocked out, dogfooded and folded back into the way the team works.
Writing
Public notes and selected chat-derived drafts
Old ChatGPT chats are useful raw ore, not finished public copy. The strongest pieces get edited into public-safe notes and linked from here once they say something clearly.
Before You Unleash the AI, De-Complect the Problem
The public version of the Hickey-inspired design gate before agent implementation.
When AI Lets You Hit The Technical Debt Wall Faster
Experience report from JobDone: speed exposed architecture debt earlier.
The Hickeyian Way
Short note on simple-not-easy as a working review skill.
Becoming a Cyborg
Imported ChatGPT draft selected for editing into a public piece about AI workflow bootstrapping.
AI and Human Collaboration
Imported ChatGPT draft selected for editing into a public piece about human-agent symbiosis.
Engineering Philosophy
Simple enough to reason about
My engineering style is strongly influenced by Rich Hickey's emphasis on simplicity, explicit design and separating concerns. I enjoy software that makes difficult domains understandable rather than hiding them behind layers of accidental complexity.
I also care about communication as an engineering skill. Good matrices, named concepts, diagrams, small examples and clear trade-off notes help teams carry ideas without needing the whole system in one person's head.
Rich Hickey
simple versus easy, decomplecting, values, data and time
Matt Pocock
skills, drills, tight feedback loops and AI-assisted software craft
Maciej Szajna
relentless simplicity, cutting dross and refusing to let accidental complexity hide in plain sight
Unix and Clojure
small reusable tools and a small set of functions over simple data
Technical Skills
Tools I use to build these systems
- Main languages
- Clojure, Scala, Kotlin, Python, JavaScript, SQL
- Functional and data systems
- Datomic, Kafka, event streams, immutable records, schema evolution
- Cloud and platform
- AWS, Kubernetes, Terraform, Docker, Linux
- Databases and APIs
- PostgreSQL, GraphQL, Elasticsearch, REST
- AI engineering
- Agent workflows, LLM review loops, transcript pipelines, AI-assisted prototyping
Contact
Get in touch
Email peter.wilkins2 at protonmail.com or see recent public work at github.com/peter-wilkins.