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
Most AI research sounds confident and is often wrong. I build research graphs that grade every claim as confirmed, alleged, or rumoured, surface what they.
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
Prompt engineering is the instructions you repeat to a model each time. A harness is the tooling around the model that encodes the rules once, so the model.
Treat contradictions as findings, not errors
When two trusted sources disagree, my research graph writes the disagreement down as a Conflict block and opens a question about it, instead of silently.
Every claim should carry its evidence grade
An evidence grade is a required field on every note in a research graph, marking each claim confirmed, alleged, or rumoured. The schema rejects ungraded.
Knowing when to stop is the hard part
An LLM left running on a research task does not stop. It keeps generating plausible-sounding filler. My convergence check stops the machine when new.
LLMs behind typed contracts, not vibes
Putting an LLM behind a typed contract means the model's inputs and outputs are constrained by code (frozen dataclasses, Zod schemas, SQL sandboxes) rather.
Postgres is the spine
Across very different builds Postgres carries the load that matters: pgvector search for RAG, integrity rules enforced inside the database, and atomic.
Why AI projects die after the demo
AI projects die after the demo because a demo only has to work once, on a clean path, in front of an audience. Production has to keep working while payments.
Wikilinks are the product
In a research graph, a wikilink is a claim that two things are related. The web of those claims is the actual output, not the prose around it, and an.
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
Pipe your plan, code, or tests to a second AI from a different vendor for critical review. The findings you'd have missed come from a reader who isn't.
Translating technical fixes for non-technical clients
Every bug-fix update to a non-technical client is two paragraphs, zero jargon, a commit SHA, and a Trello tag. The template that keeps me from leaking.
A file-driven planning framework for AI-assisted coding
Five phases. Each phase reads a file and writes a file. If an AI session crashes mid-phase, you resume from the last file written. Mixed-model workflow,.
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
A Playwright setup that logs in once, never clicks the Wipe All button, and treats a shortcode map as the single source of truth for routes. The specific.
Why Postgres alongside WordPress, not instead of it
Why Postgres alongside WordPress, invariants in plpgsql triggers, operational data that outlives the CMS. A pattern from WeCoza development.
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