{"id":14073,"date":"2026-07-16T19:07:59","date_gmt":"2026-07-16T19:07:59","guid":{"rendered":"https:\/\/prizmlaw.com\/site\/?p=14073"},"modified":"2026-08-15T16:59:14","modified_gmt":"2026-08-15T16:59:14","slug":"elementor-14073","status":"publish","type":"post","link":"https:\/\/prizmlaw.com\/site\/2026\/07\/16\/elementor-14073\/","title":{"rendered":"A Better Framework for Tracking Software Development Progress in AI-Assisted Development Environments."},"content":{"rendered":"\t\t
\n\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t

A Better Framework for Tracking Software Development Progress in AI-Assisted Development Environments.<\/h4>\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t

You started with an AI coding agent and a clear idea. Features shipped. Tests passed. Then complexity arrived and could answer the simplest question: “Does the app actually support feature X?” Here’s what I’m learning building a sophisticated document drafting application, and why it might matter for your next serious AI-assisted project.<\/em><\/p>\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t\t\t

A lot of us have used AI coding agents on small projects. But as that project grows in complexity, tracking the functionality of that project (and the gaps in that functionality) becomes more and more difficult.<\/p>

Your development rhythm may look like this: You describe what you want. The agent writes code. You run it. It works. You add the next feature. The agent remembers most of the requirements. The test suite grows. The README gets a bullet point. Maybe you ship something or maybe this experiment ends here.<\/p>

For a todo app, a landing page, or a single-purpose tool, that loop is enough. The product is<\/strong><\/em><\/span> the feature list. “Do it support dark mode?” is a one-line answer.<\/p>

If the project gets large enough, we hit the wall where that stops working. Not because the agents failed, but because the question itself<\/strong><\/em><\/span> got harder.<\/p>\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t

A Little Context: What I’m Building<\/h2>\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t

TrustDrafting<\/strong><\/span> (don’t worry it’s just a temp placeholder name) is an estate planning platform. Think of it as software that helps an attorney move through a client interview to a complete document package: revocable living trust, pour-over will, powers of attorney, health-care directives, and the rest. Currently, it’s meant to be an internal tool for my own practice to replace the stale, expensive 3rd-party tools I’m unhappy with.<\/p>

It’s not a chatbot that drafts a will from a prompt. It’s meant to be a professional instrument: intake captures facts, a configurator records the my decisions regarding document architecture, a sophisticated clause library supplies real trust language (from lawyers, not invented by AI), and a rules engine catches inconsistencies before anything is finalized.<\/p>

Early on, the question was straightforward: “Can I generate a valid, coherent trust?”<\/p>

Eventually the question became: “Can the system generate a complex estate plan documents that handle express disinheritance across both trust and will, validates that the named people match, drafts the right prose for this trust’s voice, and surfaces the gap if it doesn’t have it the right clauses or configuration options without silently pretending it does?”<\/p>

That’s a different kind of question. And my old tools for answering it weren’t built for this kind of analysis.<\/p>\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t

The Feature\/Issue List Stopped Being Enough<\/h2>\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t
\"GitHub<\/div><\/div>\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t

I was originally organizing my todo list of features and bug fixes through GitHub issues on the repository (above). However, this became increasingly inadequate as several things compounded at once…<\/p>

The product became a pipeline, not a screen.<\/strong><\/em> A single outcome, for example, “excluding an estranged child”, touches intake, advisor recommendations, configuration UI, two document generators, validation rules, and cross-document coordination. Checking off that feature as done\/green on one step doesn’t mean green on the whole journey.<\/p>

Correctness became cross-cutting.<\/strong><\/em> I could have a clause in the library, a field in the configurator, and a rule that fires \u00a0and still fail the attorney on a real client because the combination<\/strong> their plan needed wasn’t backed by any specific clause variant. The test suite was green. The demo looked fine. The client was blocked.<\/p>

AI made me faster at building the wrong thing confidently.<\/strong><\/em> Coding agents are extraordinarily good at implementing what you ask for. They are not good at telling you what you forgot to ask for. Speed without a map just gets you to the wrong place faster.<\/p>

I couldn’t distinguish “the platform don’t support this” from “I haven’t looked.”<\/strong><\/em>\u00a0Those sound similar in a backlog. They’re completely different in a product where a silent gap can mean an attorney ships an inconsistent plan.<\/p>

The solution for this became its own development project called Atlas. It wasn’t in the original spec. I didn’t \u00a0sat down day one and design a “Coverage Atlas.” It emerged when I kept having the same internal conversations:<\/p>