The ZDP Development Protocol is Clint Zehner's framework for working with AI on software projects. It developed over time as he moved between projects, kept what helped, and turned recurring problems into working rules. Its concern is both the software being built and the human effort required to get it built.1

The name is now a recursive backronym: ZDP expands to ZDP Development Protocol. Earlier documents used Zwikipedia Development Protocol and Zwolf Development Protocol. The current name reflects its broader use as the framework for all of Clint's AI development work.1

Learning how to work with the tools

AI made it possible for Clint to attempt projects that would previously have required more programming experience or outside help. It also introduced a different kind of work. A project needed to keep its decisions straight, carry information between sessions, and distinguish a convincing explanation from something that had actually been built and checked.1 2

The ZPI integration with ChatGPT was one of the experiences that contributed to ZDP. Connecting systems added more places for assumptions and remembered details to diverge. The development method needed to make progress understandable and recoverable, including when a conversation ended or a different agent took over.1 2

ZDP grew from that practical work across multiple projects. Its rules are meant to help an AI carry more of the routine work while giving the human a clear account of the decisions, results, and unresolved problems.1 3

Karpathy, Ponytail, and YAGNI

The method combines lessons from those projects with Karpathy-inspired coding guidance, Ponytail, and YAGNI.1

The Karpathy-inspired guidelines emphasize understanding the problem before changing the code, making assumptions visible, keeping changes focused, and defining a result that can be checked. In ordinary terms, the agent needs to know what it is trying to accomplish and how it will recognize that it has worked.4

Ponytail contributes an insistence on looking for the simplest complete solution. Before writing another piece of software, check whether the project already has it, whether a built-in tool handles it, or whether the proposed addition is needed at all. Simplicity still has to preserve the behavior, checks, and safeguards the task requires.5

YAGNI, short for “You Aren't Gonna Need It,” addresses the temptation to build for speculative future needs. A capability can be added when the need becomes real, instead of making the current project carry complexity that may never be useful.6

ZDP brings those ideas into a process shaped around Clint's actual work. The aim is to finish the task with appropriate checks, keep the result understandable, and avoid creating another problem for the person supervising it.1 3

The human part

Human attention is a limited resource. An AI that repeatedly needs the same context, asks for routine confirmations, or leaves the user to move information between tools can consume the time it was supposed to save.3

ZDP therefore treats efficiency partly as a question of human intervention. The agent should handle ordinary inspection and repeatable work, test uncertain dependencies early, and bring back a decision when the answer would materially affect the project. A person should be able to see what changed, what was checked, and what still needs their judgment.2 3

This also shapes progress reporting. Preparing a change, testing it locally, putting it into the main project, and releasing it to the public are different events. The record should make clear which have actually happened.2

Keeping a project coherent

Before substantial work, the task needs a defined purpose, boundaries, and a way to judge success. The agent checks the smallest uncertain part early, implements the change, and runs the checks appropriate to what it touched. Review, release, and closure follow as distinct steps.2

Long work also needs a durable checkpoint: a short saved account of the decisions, completed work, checks, open questions, and next action. A later session checks the actual project against that account before continuing. This reduces dependence on what a particular conversation happens to remember.2

In Zwikipedia development, ZPI holds the tickets and workflow state, while the code repository holds the source and technical history. ZDP provides the process connecting that work. Its wider application across Clint's projects follows the same principle: tools can change, while the need for clear decisions and verifiable progress remains.1 7