WilhamBrodwolf
Systems that hold.
I build software that behaves at 3 a.m. exactly the way it did in the demo — now with AI in the loop and engineers on the hook.
I work where engineering, architecture and leadership overlap.
I lead the development of scalable and reliable systems — helping engineering teams break down complex problems while keeping a hard focus on business impact, operational efficiency and long-term maintainability.
Five years across e-government, e-commerce, payments and insurance. Most of what I ship is the unglamorous kind: reconciliation that has to balance, SLAs that can't slip, pipelines nobody should have to think about.
Data2
API2
Tests2
Eval pass rate per iteration
62% this run
+35 ptssince the first draft
- Unit tests148/148
- Type check0 errors
- Eval suite97%
Agents write the code. Engineering decides what ships.
I use AI the way I use any production system: grounded in real context, checked by tests and evals, signed off by a human.
- 01
Grounded before it writes a line
The agent starts from the ticket, the decision records, the schema and the logs — not a blank prompt. Context is assembled, not improvised.
- 02
A plan you can review in a minute
Work is split into small changes by layer, so the diff is predictable before anything is generated.
- 03
Tests and evals decide, not vibes
Every iteration runs types, unit tests and an eval suite built from real cases. The pass rate has to climb before it earns a human's time.
- 04
Human sign-off, then a careful rollout
A reviewer approves, CI deploys a canary and the same dashboards watch it. If a number moves, it rolls back on its own.
One product, every screen.
You are in the session too: click the screen or change the theme, and the code follows.
One core. Every channel.
Your customer is at a desk, on a phone in the field, and inside someone else's system through an API. Same domain rules, same guarantees — a different surface. I build the core once: typed, tested, observable. Then every channel stays thin enough to change on a Friday afternoon.
Architecture that fits the problem
Not a monolith out of habit, not microservices out of fashion. The shape follows the domain and the team.
Reliability is a feature
SLAs, idempotency, replayable events and dashboards that answer the question before someone asks it.
Leave it documented
Decision records, runbooks and tests, so the team keeps moving after I step out of the room.
Manual work, rebuilt as workflows.
Most teams lose hours copying data between WhatsApp, spreadsheets, email and the CRM. I map the process, then rebuild it in n8n: an LLM where judgement is needed, plain rules where it isn't. Every run is logged, retried and easy to change.
Built to keep serving when a region goes dark.
Health checks, weighted routing and slow start are design decisions, not afterthoughts. This is the failover drill every critical system I lead is built to pass.
What I reach for, and why.
The orbit rests while you aim. Filter by category or pick a logo to see where it fits.
Toolbox
29 tools, 22 in production
Pick a logo to see where I use it. Arrow keys step through them.
22 of 29 connected in totalPick a time.
Thirty minutes, no deck. Tell me what is breaking, or what you are about to build.
wilham@brodwolf.dev30 min.