The System Around the Work: Designing for Continuity and Judgment

AI gives a new project a peculiar kind of confidence. For a while, it feels as if you can do almost anything.

You describe an idea, and something begins to exist. Research gets organized. A prototype starts working. Code appears. You ask another question, try another direction, and the distance between thinking about something and making it real suddenly becomes very small.

There is almost no natural pressure to stop.

That is where I got into trouble.

When I started building the Team Capability Engine, I had no real framework for working with AI. I watched tutorials, borrowed techniques, experimented with different tools, and kept whatever seemed to work.

And a lot of it worked. I built quite a bit.

The failure was quieter, and in some ways worse. As the project grew, I could no longer reliably reconstruct its own history.

A requirement had changed, but the reason was somewhere in a conversation. A decision existed, but I was not always sure whether a later discussion had replaced it. Documentation covered some parts of the project in detail and barely mentioned others. Some rules were written down; others existed because I remembered them.

I had built plenty of output, but I had not built a dependable way for the project to know what it knew.

That was when I stopped looking for another clever prompt and started looking at the work as a system.

What does the project need to know?

The framework that grew from this is still evolving, but its basic shape has become fairly simple:

Context → Decisions → Authority → Verification → Learning

Context gives the work enough history and purpose to make sense. Decisions preserve what we chose and, when it matters, why. Authority defines what AI may do freely and where it must stop. Verification gives us evidence that the work is actually ready. Learning keeps useful mistakes and discoveries from disappearing when the conversation ends.

I write it as a sequence because it is easier to understand that way, but in practice it behaves more like a loop. What the project learns can change its context, decisions, and sometimes even its rules about authority, but only after a person approves the change.

The repository contains far more than these five ideas, but these layers have mattered more to me than any particular folder structure.

Before an agent begins working, I want the project to know what it is trying to accomplish, what has already been decided, what remains open, where the agent has room to move, where a human decision is required, and what evidence will let us call the work complete.

My framework developed through problems like these rather than from some grand methodology. One project exposed a weakness, and I tried to improve the system instead of merely correcting the output. Documentation problems changed how decisions were preserved. Accessibility problems moved accessibility earlier. Agents making sensible but unwanted choices forced me to become clearer about authority.

At the same time, people I work with and mentor kept bringing me their own AI questions. The artifacts varied: research, portfolio projects, product design, prototypes, writing, software, but I noticed that my advice was much the same.

Understand what you are trying to solve before asking AI to produce something. Give it the context it needs. Preserve important decisions. Establish boundaries. Verify the result.

The details change. Those needs do not.

A lesson from design systems

Design systems eventually gave me a useful way to think about one part of this.

A product becomes difficult to manage when every problem is solved locally. A new situation gets a new component. Six months later somebody solves almost the same problem differently. Each decision can be reasonable while the product as a whole slowly becomes incoherent.

AI work can accumulate decisions in much the same way.

Early in this process, I leaned heavily on written documentation. My projects began carrying files such as DESIGN_SYSTEM.md, ACCESSIBILITY.md, REQUIREMENTS.md, and DECISIONS.md as durable context the AI could actually use.

For the design system, the written documentation could be quite detailed. It described foundations, components, governance, when something new could be introduced, what should be reused, and what the agent was not allowed to improvise.

For AI, this worked better than I expected. Text is explicit. The model has less to infer.

For a while, I wondered whether the written version of a design system might actually become more useful to AI than the visual one.

Then the tools changed.

As Figma integrations and MCP access improved, the visual system became much more useful to AI directly. Figma could now provide something Markdown could not: a common visual reference that designers, developers, and AI could inspect together.

The text had not become wrong. The environment had become better.

So the framework changed with it.

That experience reinforced something I now think is essential. A useful framework cannot simply preserve what you knew when you started. It has to provide a way for the project to become wiser while the work is happening.

Your instincts belong here too

There is a danger in making any framework too tidy.

After you have been doing a kind of work for long enough, sometimes you notice a problem before you can explain it. A research conclusion fits a little too neatly. A flow works, but something about it bothers you. A feature makes logical sense, yet experience tells you there is probably trouble underneath it.

We call that instinct. I think of it as experience compressed so tightly that the conclusion arrives before the explanation.

AI has access to patterns at a scale none of us can match. What it does not have is your particular history with this organization, this customer, this project, and the consequences of the decisions that brought you here.

That matters because AI can make a mediocre decision sound beautifully reasoned.

The framework should help you investigate that discomfort rather than train you to suppress it. It should surface the decision, the evidence, and the assumptions so you can understand why your judgment is objecting.

This becomes especially important when we begin talking about systems that learn.

Learning is not authority

Suppose an agent creates a new component when an existing one should have been reused. I can correct it and continue working. Sometimes that is enough.

If it happens again, I become more interested in why.

Maybe the existing component was difficult to discover. Maybe the documentation was ambiguous. Perhaps the rule existed, but nothing enforced it. Or perhaps the new component was legitimate, and the system itself had failed to recognize a new case.

At that point, the mistake has become useful information.

The lesson might improve documentation. If the pattern continues, it might become a rule. Eventually the rule may become a validation check so the project catches the problem without relying on somebody remembering the same lesson again.

This is the kind of self-learning I want: the project should become better because work happened inside it.

But there is a line I do not want it crossing.

If the system discovers a better way of operating, it may preserve the evidence and propose the change. It should not quietly rewrite its own rules or expand its own authority.

Learning is not authority.

A human still decides which lessons become part of the system.

This is larger than software development

I am certainly not the only person working on these problems.

GitHub’s Spec Kit brings structured specifications, planning, implementation, and verification into AI-assisted software development.

OpenAI has described a related practice as harness engineering, where the quality of the environment around the agent documentation, tools, tests, and feedback loops becomes part of the engineering problem.

Anthropic’s work on context engineering looks at another part of the same problem: how to curate the information available to an agent when context and attention are finite resources.

I borrow from all of these ideas, along with AGENTS.md, tool-specific instructions, and other practices emerging around agentic development.

What I needed for my own work was broader scope.

I do not spend all day building software. One project may move through research, product definition, UX, accessibility, a design system, writing, analysis, prototyping, and eventually code. Sometimes the final artifact is not software at all.

The same five layers still travel surprisingly well: context, decisions, authority, verification, and learning.

That is why I ended up building my own version rather than adopting one development framework wholesale. I call the repository AI Project Bootstrap. It is the starting structure I now use and continue to change as these lessons accumulate.

Verification has to produce evidence

Verification is the layer where the framework stops being a collection of good intentions.

What it looks like depends on the work. In software, it may mean automated tests and checks that confirm required documentation, approvals, or project rules are actually present. In design, it may include accessibility checks, design-system validation, and review against requirements. For AI functionality, it can include explicit evidence requirements and the heuristics I use as release gates.

The important part is that the agent cannot simply announce that something is finished and make that statement true. There has to be some proof appropriate to the consequence of the work.

My Eight Heuristics for Generative and Agentic AI Products became part of this layer over time. They began as lenses for examining AI experiences—capability and confidence, provenance, bounded autonomy, recovery, accessibility, inspectability, safety boundaries, and process visibility.

Eventually I started asking why some of those questions should wait until a UX review.

If an AI product cannot adequately explain the provenance of consequential information, that may be more than a design observation. If an important automated action cannot be interrupted or recovered, it may be a reason the work should not move forward.

So, where they apply, some of those heuristics now participate directly in the project gate.

That progression is exactly what I want the larger framework to encourage. Experience produces a useful lens. Repeated use turns the lens into a practice. Once that practice proves durable enough, it can become part of how the project operates.

How would I know this is actually working?

This is something I want to measure more deliberately.

Speed alone is not particularly interesting to me. AI already makes production faster. I want to know whether the structure around that production is getting better.

One measure is how much effort it takes to bring a fresh agent into an existing project before it becomes useful. Another is how often an old decision has to be explained again because the project failed to preserve it. Documentation drift matters. Problems caught before release matter. So does the number of times a human has to make the same correction.

The measure I find most interesting, though, is how often one of those repeated corrections eventually becomes a durable control.

If I have corrected the same mistake six times, the system has not learned very much.

If the first mistake becomes evidence, the evidence becomes a better rule, and eventually the project can catch the problem itself, that is much closer to the kind of learning I want.

I suspect measuring this properly deserves its own experiment, and probably its own article.

You probably have a framework already

If AI has become part of your regular work, you almost certainly have some version of this.

It may be instructions you copy into every project, an AGENTS.md, a checklist, a few documents you always provide first, or simply several rules living in your head because the model has annoyed you enough times to make them memorable.

The interesting question is not whether you have a framework. It is whether you designed it or simply accumulated it.

Look at what it remembers and what it repeatedly forgets. Look at the mistakes that keep returning, the decisions that have to be explained again, and the rules that are still hanging around because they made sense for a tool you stopped using six months ago.

Mine is still evolving, and that is intentional.

AI Project Bootstrap currently lives in a private GitHub repository. If you want to try it, message me on LinkedIn. I can add you so you can clone it, put it against a real project, keep whatever is useful, and change whatever is not.

Or use Spec Kit. Build something smaller. Combine pieces from several approaches.

Mine is not the point.

The models will change. The tools certainly will. Many of the techniques we are learning today will eventually become ordinary or obsolete.

Your accumulated judgment is much harder to replace.

A good framework gives that judgment somewhere to live, and somewhere to keep learning.

“A complex system that works is invariably found to have evolved from a simple system that worked.”— John Gall, Systemantics