Writing
Notes on the parts that decide whether a system survives
The arguments behind the case studies, written out properly. Why business data lives in Postgres rather than post meta, why an LLM belongs behind a typed contract, and why most AI projects die after the demo. Positions I hold, with the reasoning and the costs.
Start here
How I build living research graphs you can trust
How I build research graphs that grade every claim as confirmed, alleged or rumoured, and say plainly what they have not found yet.
A research tool that finds its own blind spots
A research graph can find its own blind spots by measuring its structure instead of its prose. A small script flags any note that many other notes point to.
Build the harness, not just prompts
A prompt tells an AI model what to do. A harness is the code around the model that rejects bad output, so the rules hold whichever model is running.
Treat contradictions as findings, not errors
When two trusted sources disagree, my research graph records the conflict and opens a question about it, instead of quietly picking one version.
Every claim should carry its evidence grade
Every note in my research graphs grades its claim as confirmed, alleged or rumoured. The schema refuses an ungraded note, so allegations never read as fact.
Knowing when to stop is the hard part
An LLM on a research task never runs out of words. My convergence check stops the run once new findings dry up, before the model starts padding.
LLMs behind typed contracts, not vibes
An LLM behind a typed contract has its inputs and outputs limited by code, not the prompt. Three examples: frozen dataclasses, Zod schemas, a SQL sandbox.
Postgres is the spine
In three different builds, Postgres does what the app cannot do safely: pgvector search for RAG, integrity rules in the schema, and atomic writes under load.
Why AI projects die after the demo
A demo only has to work once, on a clean input. Production needs logging, idempotency, review stages and fallbacks. Why AI projects die between the two.
Wikilinks are the product
In a research graph, each wikilink claims two things are related, and that web of claims is the real output. An unresolved link marks what to research next.
Ship the feedback loop
Why a one-click feedback widget plus an automatic audit-log bundle is the bit of infrastructure people skip, and how it's wired up in the wecoza-core plugin.
Adversarial review via a second AI model
Before I run a plan, code or tests, I send them to an AI model from a different vendor for review. It has different blind spots, so it finds other problems.
Translating technical fixes for non-technical clients
The two-paragraph template I use to report a fix to a non-technical client, written in their words rather than mine, with the commit it shipped in.
A file-driven planning framework for AI-assisted coding
A five-phase planning framework for AI-assisted coding. Each phase reads a file and writes one, so a crashed session resumes from the last file written.
Building a knowledge-graph research vault
Start with a research brief, end with a navigable Obsidian vault published as a public wiki. The iterative loop between them, with a convergence criterion.
Why I keep LLMs behind typed adapters
LLM calls behind typed adapters, code-level information barriers, external prompts, provider-agnostic transport. An AI-engineering position.
Playwright E2E tests for a WordPress plugin
Playwright end-to-end tests for a WordPress plugin: log in once, never click the destructive admin buttons, and keep every route in one shortcode map.
Connect WordPress and WooCommerce to PostgreSQL
WordPress and WooCommerce do not run reliably on PostgreSQL. What works is MySQL for WordPress, Postgres beside it, and store data copied across.
Why I publish negative results
Why I publish negative results, postmortems as the deliverable when research doesn't pan out. Evaluation discipline across shelved research projects.
Recognise any of this?
If one of these describes a system you are living with, that is usually a good first conversation. A few lines is enough, and I will tell you honestly whether it is a two-week job or a two-month one.
I reply to every enquiry within one business hour.
Prefer email? support@yourdesign.co.za· (+27) 079 177 1970