Engineering standards are part of the architecture

The architecture of a software system includes the decisions that govern how it changes. What makes a change acceptable? What evidence is required before a release? Who has the authority to put it into production?

I treat engineering standards as part of that architecture. They shape the work long before a customer sees the result, and they determine what we can explain about that result afterward.

AI agents make those questions more immediate. An agent can produce a plausible change without knowing the reasoning behind a team's conventions. If that reasoning lives in someone's memory, the team has to supply it again each time the work changes hands.

I use a public KofTwentyTwo standards repository to make that shared reasoning inspectable. It brings policies, engineering rules, configurations, templates and checking tools into the same versioned body of work. The interesting question is how those pieces connect to the decisions people and agents are actually making.

CTO to Human: making judgment visible

Consider the statement, “We review changes before releasing them.” It sounds reassuring. It leaves several important questions open: what the review covers, who can approve it, what happens when a check fails, and whether the release process can proceed without that approval.

Those details determine how much confidence the statement deserves.

A useful standards repository makes them explicit. It gives a team a shared place to explain its expectations, the reasons behind them, and the evidence needed to show that the work met them. Keeping that material in version control also gives changes a history: people can see which expectation changed and review the reasoning.

That matters to someone outside engineering because changing a rule can change the organization's exposure. A new release requirement might affect delivery time. An exception might permit work to proceed while leaving a specific risk unresolved. A shared configuration change might alter what several teams consider acceptable. These deserve identifiable decisions and owners.

With an AI agent, there is an additional distinction. Giving the agent instructions supplies context for its work. Restricting its authority controls what it can do. An organization needs to understand both.

For example, an instruction can tell an agent that publication requires approval. The publishing system can also require that approval before it accepts a request. The second mechanism gives the organization a control it can inspect independently of the agent's explanation of its own behavior.

My expectation of leadership is to connect those layers. People should understand the intent. Engineers should be able to identify the implementation. The person accountable for the decision should know what evidence supports it and what remains uncertain.

The SDLC and WISP give those standards a job

A software development lifecycle (SDLC) describes how an idea becomes a change, how that change is verified and released, and how the software is maintained and eventually retired. A Written Information Security Program (WISP) describes how we protect the information and systems involved: accounts, source, credentials, workstations, build infrastructure, customer data and recovery arrangements.

They meet at the same decisions. The SDLC determines how an agent's change reaches production. The WISP determines which information the agent can access, which systems its credentials can affect, and how we respond if that access is misused. A standards repository gives both programs a shared, versioned home, along with the configurations and checks that implement their requirements.

Layer	Decision it makes explicit	Example evidence
SDLC	What must happen before a change is released?	Reviewed change, test results, identified release artifact
WISP	What are we protecting, and who can affect it?	Access review, scoped identity, incident and recovery records
Engineering standard	How does a project meet that requirement?	Repository rules, pipeline configuration, exercised checks

Consider an agent adding a data-export feature. The SDLC calls for acceptance criteria, design review, tests and a release decision. The WISP raises a different set of questions: which data may leave the system, who may request the export, whether the agent may see real records, and how exported files are retained or deleted. The implementation has to answer both sets of questions.

My public SDLC policy connects planning, threat modeling, review, verification, releases and maintenance. The security program covers the accounts and infrastructure that make those activities possible. The AI-assisted development policy assigns human accountability and defines expectations for agent authority and data handling. These are published requirements; each project still needs evidence that it has implemented them.

For a solo engineer, this is a way to make decisions repeatable when the amount of generated work grows. Adding agents creates more producers of changes. It also creates more places where an assumption, credential or incomplete review can matter. Writing down the lifecycle and security program gives that work boundaries that survive a change of agent or session.

Engineer to Engineer: how that judgment reaches the system

A standard has a version and a consumer

A standards repo becomes useful when a project has an explicit relationship with it. That relationship includes the revision being used, the relevant rules, and the local configuration or process that implements them.

A formatter configuration and a reusable continuous integration (CI) workflow are dependencies. A change to either can change the result of a build or review. Pinning a workflow to an immutable commit makes that dependency identifiable; adopting its next version becomes a reviewable change. A workstation checkout that follows current guidance serves a different purpose. The distinction needs to be visible when explaining which rules and tooling governed a particular piece of work.

The repo also needs room for project-specific decisions. A shared standard can establish an expectation while a repository supplies its actual build commands, framework constraints and approved exceptions. Clear precedence lets an agent resolve those layers. My agent operations standard records that relationship between harness instructions, project instructions and shared guidance.

Instructions and permissions operate at different layers

An agent needs a discovery mechanism: instructions its harness actually loads and a path to the shared material. That mechanism needs verification. A file existing in a repository tells us little about whether a particular session read it or used the expected revision.

Once loaded, the instructions help shape the agent's behavior. Enforcement still belongs in the relevant system: repository rules for merging, CI for required checks, and scoped credentials for access to a publishing or deployment operation.

The important failure mode is a gap between the stated rule and the available operation. If a release requires review but the same credential can publish directly through another route, the instruction and the permission model disagree. A clear document helps reveal that gap. The access boundary and release process have to close it.

This is why I want rules, reusable configurations and checks maintained together. An engineer should be able to follow an expectation to its implementation and identify the parts that still depend on human judgment. The CI standard describes required checks and the controls around running them; a consuming project still has to demonstrate its own adoption.

Evidence has a scope

A successful test establishes something about the behavior exercised by that test. A local conformance check establishes something about the requirements it can inspect. Neither result establishes every property of the release process.

That boundary matters when the rule spans several systems. Reviewing source files cannot by itself prove the live repository's permissions. Reading a workflow cannot prove the credentials supplied to a running job. Each claim needs evidence from the layer that can establish it.

Exceptions need the same precision. A named requirement, a bounded scope, an owner and a review date make a departure visible. They also give the next engineer or agent a way to distinguish an intentional decision from configuration drift.

Publishing the standards makes the reasoning reviewable

Making my standards repo public gives other people something concrete to examine. They can inspect the expectations, question a tradeoff, and compare a checking tool with the requirement it claims to verify.

Publication also separates the shared material from any one agent session. The same source can inform a person doing a review, an agent preparing a change, and the tooling evaluating it. That common reference makes disagreements easier to identify and discuss.

There is still work between publishing a standard and adopting it. A project needs to connect the relevant rules to its own workflow. The checks need to be exercised. The permissions need to match the intended authority. A published document makes the reasoning available; evidence from the actual project tells us what has been implemented.

For me, that is the larger opportunity with agents: make more of our engineering judgment explicit enough to share, review and test. The judgment remains ours. The agent gains a clearer environment in which to contribute.

I want another engineer to be able to trace a decision through the system, and another executive to understand why that decision matters. Explaining the same idea at both levels helps expose what we understand, what we are assuming, and what still needs to be proved.

The technical companions develop this into a working approach: a solo engineer's SDLC for an army of AI agents and a solo engineer's WISP for an army of AI agents.