The TIED methodology incorporates strict TDD to produce the correct code. The primary tasks is now capturing and enforcing the user's intent. See this full article to learn how TIED makes TDD work for agentic programming. Do you trust your TDD-compliant code?

It moves human attention from repeated interpretation and review toward early decisions, risk, and exceptions.

Most software workflows spend human effort reconstructing the same meaning several times:

• What did the request mean?
• Did the design preserve it?
• Did the implementation change it?
• Do the tests prove the same thing?
• Did the code introduce behavior nobody recorded?

TIED — Token-Integrated Engineering & Development — is an attempt to change that allocation of effort.

The claim is not that TIED eliminates engineering work or guarantees lower project costs. The claim is narrower:

>Once the intended meaning is clarified and approved, routine propagation of that meaning can become more mechanical, auditable, and exception-driven.

That changes where developers spend their effort.

The basic idea

TIED gives a behavior-changing request a connected path through the development process:

sponsor language
  -> shared vocabulary
  -> requirement: what must be true and why
  -> architecture: boundaries and trade-offs
  -> implementation pseudo-code: detailed behavior
  -> tests and production code
  -> validation and evidence

The connections are identified with semantic tokens such as [REQ-*], [ARCH-*], and [IMPL-*]. The tokens are not magic labels. They give an approved meaning a stable identity that tools, agents, and developers can follow.

The important distinction is between two kinds of work:

• Semantic work: deciding what a concept means, what the product should do, what risks are acceptable, and what is in scope.
• Translation work: carrying that approved meaning into architecture, implementation logic, tests, code, and evidence.

Humans are needed for the first category. Tools and agents are well suited to help with the second.

Where the effort moves

Without a stable semantic baseline, every layer asks humans to interpret the request again. With one, many downstream questions can be checked repeatedly:

Does the reference resolve?
Does the requirement link to the architecture?
Does the implementation describe the required behavior?
Does the test cover the implementation block?
Does the code match the tested behavior?
Did the declared checks pass?

That does not make review disappear. It changes the default:

repeated interpretation of routine work
  -> early agreement about meaning
  -> machine-assisted propagation and checks
  -> human review when meaning, risk, scope, or evidence changes

The human effort is more front-loaded. Routine downstream review can become more exception-based.

What a TIED workflow looks like

Suppose the request is:

>Add a feature that lets a project resume an interrupted task safely.

That sentence is not yet a complete requirement. “Resume,” “interrupted,” and “safe” may all need clarification.

The workflow first resolves the language and boundaries. It then records:

1. a requirement with observable behavior, rationale, non-goals, and acceptance criteria;
2. an architecture decision with boundaries, ownership, data flow, and rejected alternatives;
3. implementation pseudo-code that describes operational behavior before production code exists;
4. tests derived from that behavior;
5. production code that satisfies those tests;
6. validation and evidence showing what was checked.

The implementation pseudo-code is more than a design note. For a changed procedure, it can specify inputs, outputs, preconditions, postconditions, effects, failure modes, and state transitions. That gives tests and code something more precise to implement against.

Why this matters more for AI-assisted development

An AI coding agent can produce a plausible implementation from an ambiguous request very quickly. That is useful until the agent has made an undocumented assumption about:

• what a word means;
• which behavior is in scope;
• where a module boundary belongs;
• what an error should do;
• whether a test proves the intended behavior;
• whether a code change should also change the written plan.

TIED puts those decisions into a workflow that can be inspected and resumed. The agent performs mechanical recording and propagation, while the user confirms the semantic decisions that should govern the work.

The goal is not to trust the agent more because it sounds confident. The goal is to give the agent less room to silently invent the project’s intent.

Certification has a boundary

When I use the word “certified,” I mean that a defined workflow, repository, revision, toolchain, and evidence set passed its declared checks.

A certified workflow can check things such as:

• referenced tokens exist;
• Vocabulary, token, and record names are consistent;
• REQ, ARCH, and IMPL records link correctly;
• project YAML and detail files are valid;
• implementation pseudo-code has the required structure and traceability;
• tests cover declared implementation behavior;
• modules are validated before composition;
• bindings are tested without hiding wiring defects inside E2E;
• declared quality commands ran and produced bounded evidence;
• specification and implementation divergence was reconciled or explicitly left unresolved.

Those checks do not prove:

• that the original product idea was wise;
• that the tests cover every possible behavior;
• that the software is universally secure or usable;
• that the system is compliant in every jurisdiction;
• that stakeholders will like the result;
• that production behavior is safe outside the declared evidence boundary.

Certification is therefore conformance to an explicit scope, not a universal correctness certificate.

What happens when reality disagrees with the plan?

This is where LEAP — Logic Elevation And Propagation — matters.

If a test or implementation reveals that the pseudo-code was wrong, the workflow does not silently leave the documentation behind. It updates the stack in the safe direction:

implementation behavior changes
  -> update IMPL pseudo-code first
  -> update ARCH if the design boundary changed
  -> update REQ if the intended scope changed
  -> realign tests and production code

The point is not to pretend that divergence never happens. The point is to make divergence visible and recoverable.

The economic trade

TIED spends more effort early:

• clarification takes time;
• REQ/ARCH/IMPL records take time;
• tokenized pseudo-code takes time;
• validation and evidence take time;
• the team must maintain the written stack.

That cost is real. TIED is not automatically appropriate for a throwaway script or a disposable prototype.

The proposed economic benefit is different: less repeated reconstruction of meaning later. In a long-lived project, especially one using multiple developers or AI agents, the cost of ambiguity can appear repeatedly as:

• review comments;
• rework;
• mismatched tests;
• undocumented behavior;
• onboarding time;
• agents rediscovering the same project rules;
• fixes that solve code while leaving the plan wrong.

TIED tries to pay more of the interpretation cost once, then make routine translation cheaper to check. Whether that is a net win depends on the project’s lifetime, risk, change rate, and discipline.

When TIED is probably overkill

I would not use the full workflow automatically for:

• a throwaway experiment with an explicit discard policy;
• a tiny personal script with no maintenance or audit need;
• a one-line documentation correction;
• a prototype where the purpose is to discover the problem rather than preserve a design.

The methodology becomes more interesting when the software is long-lived, risky, regulated, maintained by several people, or implemented with AI agents whose sessions need durable context.

The skeptical version

There are at least three ways this can fail:

1. Documentation theater: a repository can contain impressive records that nobody keeps aligned with code.
2. False confidence: passing structural validators does not establish universal runtime correctness.
3. Too much ceremony: a process can cost more than the uncertainty it removes.

TIED only addresses the first problem partially, through validation and LEAP. It states the second problem explicitly. The third remains a judgment call.

If the team skips the synchronization discipline, tokens become decoration. If the team treats passing checks as proof of everything, certification becomes misleading. If the change is too small to justify the process, a lighter workflow is the better choice.

The short version

TIED does not remove human responsibility. It concentrates human responsibility where machines cannot decide:

• what the product should mean;
• which terms are distinct;
• what risk is acceptable;
• whether the architecture is appropriate;
• whether the tests are meaningful;
• whether the evidence is sufficient;
• whether the product is ready to release.

Agents and tools handle more of the repeatable work:

• recording approved decisions;
• carrying references across artifacts;
• checking structure and consistency;
• deriving tests from implementation behavior;
• finding divergence;
• preserving evidence and history.

So the thesis is not “developers do less.” It is:

>TIED changes where software developers spend their effort — from repeatedly reconstructing routine intent toward deciding meaning early and handling exceptions deliberately.

That is a hypothesis about workflow economics, not a claim that a methodology can replace judgment.

Agile already knows the loop — apply it to meaning, not only code

Agile’s useful habit is not “move fast.” It is closed loops: try something, get evidence, adjust the plan, keep the system coherent. Most teams apply that to backlog and code. Fewer apply it to the words that make the backlog speakable, or to the written intent that is supposed to stay true when the code teaches something new.

That is the pitch: treat shared language, frozen intent, change analysis, and elevation-after-discovery as one feedback system — not a waterfall of documents.

The loop (in agile terms)

Direction	Path
Forward	Shared language → intent (requirements → architecture → impl design) → tests → code
Feedback	Review, use, failures, new insight elevate back through that same chain
Next cut	Analyze change (scope, blast radius, test plan) before inventing the next forward pass

Four pieces, one cycle:

1. Shared language — a living product dictionary (ubiquitous language made explicit): preferred terms, demoted synonyms, naming bridges across UI / config / CLI / tests / code. No algorithms here — only names that later feed acceptance criteria. Authoritative for the increment; provisional when evidence shows the words are wrong.
2. TIED — freeze intent as a linked stack: requirements (what must remain true), architecture decisions (structural how / boundaries), implementation design as step-wise pseudo-code (operational how), then tests and code. Traceability so you can walk obligation → structure → steps → proof. Any team can do this with lightweight docs; the acronym is optional.
3. CITDP — structured change analysis before coding the next cut: current vs desired behavior, non-goals, blast radius, risks, test plan. The inspect-and-adapt step for “what are we actually changing?” so you do not invent scope in the PR.
4. LEAP — when tests or code disagree with the written stack, elevate truth back through the same chain (implementation design → architecture → requirements) in the same work item, and refresh shared language when the concept changed. Delivery evidence updates the plan; the plan does not silently rot while source becomes the only ground truth.

The shared dictionary is one input to that loop — not the star of the show. Without it, requirements argue in false synonyms. Without TIED, language never becomes a testable obligation. Without CITDP, the next increment guesses blast radius. Without LEAP, the first surprising test result orphans the docs.

Two bad extremes (language edition)

One bad answer: “Let everyone use their own words; meaning will emerge in conversation.”

False consensus. Two people say “command,” one means open-a-file, another means run-a-process, a third means capture-stdout-at-snapshot. Agreement lasts until implementation splits three ways.

The other bad answer: “Define the glossary once and enforce it forever.”

Fossilized bias. Sponsor language hid two user jobs; the old architecture shaped the nouns; enforcement without revision freezes the first author’s framing into the contract.

The agile answer is the same as for code: make the choice explicit, use it for the increment, test it against reality, revise through the loop.

What each stage feeds back

• Requirements — Can this term express a testable obligation? Paragraphs of exceptions around one word usually mean the word hides multiple concepts.
• Architecture — Does one term cover two modules, owners, or lifecycle states?
• Implementation design — Step-wise pseudo-code forces actions, states, order, inputs, outputs. Prose that felt fine often fails at named branches.
• Tests — Same term, different tests → meaning was never shared.
• Code — Adapters, comment-crutches, and qualifier-stuffed names are naming friction signals.
• Review and use — Users bounce off team jargon; avoided synonyms sometimes name a real distinction.

None of those layers automatically define product meaning. They supply evidence. Humans still decide; the loop makes the decision visible and propagates it on purpose.

How the cycle stays coherent (not chaotic)

Intake (CITDP + language): Resolve sponsor words against current preferred terms; flag unclear mappings; write the change analysis before inventing behavior in chat or source.

During the increment (TIED): Prefer terms in acceptance criteria and named design steps; record new concepts and naming bridges while the reason they differ is still remembered.

When mismatch appears (LEAP): Propagate changed meaning through requirements, architecture, impl design, tests, code. If tests/code found it first, elevate in reverse order. Update the dictionary when the concept itself moved — not every time a symbol is renamed for taste.

Before done: Same concept, same name, everywhere the contract depends on it. Keep old words as avoided/legacy with an explicit replacement — search and migration matter.

Bias is inspectable design input

Every prescribed vocabulary carries bias: sponsor authority, incumbent architecture, legacy code, UI metaphor, platform jargon, whoever wrote the first glossary. Pretending otherwise only hides the force.

Make the framing an artifact the team can review: Whose distinction is this? What did it exclude? Does implemented behavior still justify it? User concept, implementation accident, or org habit?

That is the agile interest. Inspect and adapt applies to meaning, intent, and change analysis — not only to velocity charts. Freeze long enough to coordinate. Reopen when evidence changes what the words (and the obligations) should mean.

The dictionary is the agent — not the model

A conversation without a shared dictionary drifts into misunderstanding. That is not a documentation tip. Establishing a common dictionary is the essence of communication: until the same words mean the same things, you are not agreeing — you are hoping parallel interpretations converge later.

The dictionary facilitates the contract

Sponsor and builder need a contract: what must stay true, what we will build, how we will prove it. Requirements can freeze that obligation. They cannot create shared meaning. Words that aren’t shared don’t bind. False synonyms look like agreement until they ship as three different behaviors under one label.

The dictionary makes obligation speakable. One preferred term per concept. Synonyms demoted. The same idea mapped across UI label ↔ YAML key ↔ CLI flag ↔ code symbol. No algorithms in the glossary — only the names that later feed acceptance criteria and implementation block names. The contract freezes intent; the dictionary is what lets both sides mean it.

Who is the agent?

In the usual AI story, the model is “the agent.” That story is incomplete.

Between humans, and between human and LLM, the shared glossary is the intermediary that carries agreement across the gap. It is the agent of understanding. The model is a powerful executor after terms are settled. Give it a clear dictionary and it amplifies precision. Give it mush and it amplifies mush — fluently.

So: the dictionary is now the agent. Not instead of the model. Ahead of it.

Outsourcing naming is irresponsible

Assuming the agent will work out all ambiguities abdicates the work of naming. Ambiguity does not disappear; it gets implemented as a confident guess. The cost is silent drift: wrong column, wrong behavior, wrong obligation — each with a coherent rationale attached.

That is irresponsible in roughly the same way as assuming a junior engineer will infer product meaning from chat slang. Inference is not a substitute for a dictionary.

What facilitation looks like

On Indescript (a macOS markdown host), markdown files fences list paths and optional row actions. In chat, “command,” “open,” “live,” and “derived” collapse into mush. A short glossary forces the distinctions first:

• Open column — button opens the file
• Action command column — button runs a Process; output goes to logs
• Derived command column — same argv rules, but stdout is captured at snapshot and shown as cell text

Rejected alternates stay explicit. Preferred terms then show up in requirement criteria and block names. The glossary never becomes a second copy of the algorithm — only the names that make the contract testable.

When those terms are agreed, you freeze intent (requirements, architecture, implementation pseudo-code, tests, code). When they are not, no amount of model fluency repairs the misunderstanding.

Close

Name first. Then freeze the contract. Do not outsource the dictionary to inference.

The model can write the code. The dictionary is what makes the agreement real.