Articles
Featured articles
Generated image: Villar David editorial
Articles
The longer stuff, split into chapters.
This is where I go into detail on applied AI, software architecture and technical leadership. Each chapter has its own page, so you can jump straight to the bit you need.
2026
Recovering an automated workflow after a partial failure
If an automated workflow stops halfway through, some of what it did may already be sitting in other systems. Before you restart it, work out what actually finished and which steps are safe to run again.
Budgeting and governing an AI workflow after the prototype
When I budget an AI workflow I start with what the whole thing costs to run: review, support, failed runs and keeping the source data usable. The model call might be cheap, but it sits inside a process somebody has to own once the prototype gets approved.
Managing review when coding agents outpace it
Coding agents can now turn out changes faster than people can properly look at them. This is how I'd work back from that point through the task, the agent's working space and the merge rules so review still means something.
Designing an auditable AI capability assessment
If you let an AI run the conversation in an assessment, I'd keep it well away from the score. Here's how I'd set up the rules, fixtures and audit record so a reviewer can work out exactly how a result was reached.
Releasing a multi-portal platform without losing state between components
These examples are a composite of the late-stage failures that turn up between roles, portals and integrations. Here's how I'd pin each one down so an agent can work on it and a person can review the fix.
2025
Self-hosting an AI agent: architecture, observability and recovery
A self-hosted agent can look perfectly fine while its memory store, tool credentials or job runner is down. I'd start with those half-broken states and build the health checks and recovery tests around them.
Designing an audit trail for tool-using agents
If your agent reads private material or changes things in another system, the chat transcript isn't going to tell you what actually happened. Here's what I'd record, how I'd tie it to a task and how I'd keep the log useful when someone has to review or recover a run.
Long-term AI memory: records, relationships and retrieval
If you want an AI system to know what's still true next week, a saved transcript won't get you there on its own. You need small records that point back to their sources, the links between them and a way to correct them when they're wrong.
Deciding what a tool-using agent can read and change
Pick one task and give the agent only the access that task needs. Here's how I'd work through the permissions, starting with read-only lookups and ending at the action a person has to approve.
Designing resumable large-data pipelines
Say an import stops halfway through a big file. Here's how I'd set up the state and restart rules so you can tell what's already done, set aside the records that failed and carry on without running the whole thing again.
2024
Production readiness for applied AI
The first production question I ask is what happens after a wrong answer reaches the workflow. So this guide starts there and works backwards through detection, recovery, permissions, source checks and the evidence I'd want before launch.
Evaluating an AI workflow before customers depend on it
Before customers lean on an AI feature, I want a test set that looks like the work it'll actually get. Here's how I'd collect the tasks, decide what counts as acceptable, go after the failure modes, measure review effort and make a call on a controlled release.
Building retrieval-augmented generation for real use
A RAG demo can answer a few prepared questions from a tidy folder. Real material brings mixed formats, stale versions, permissions and questions the documents can't answer, so this goes through those problems from ingestion to evaluation.
How technical decisions break down as a team grows
Once a technical team gets bigger, the same decision starts getting made in a few different places at once. This is how I'd work out what needs writing down, what can stay with the team doing the work, and where a review stops two versions of the product from forming.
Map the work before replacing its software
When a team asks me for replacement software, I'd rather start with one real piece of work and follow it from request to done. The missed handoffs and private workarounds usually tell you more than the old feature list does.