← Back to site

Short course

Architecting High-Assurance Software with LLMs

A two-day, hands-on course on structuring a codebase so that agent-written changes can be trusted — for developers of mission-critical systems, oriented to C++ and other compiled systems languages.

Three cohorts: August 19–20 · September 16–17 · October 14–15, 2026. Two days each, 8:30 am – 4:30 pm Mountain. American Fork, Utah.

Register See what is covered

Audience and prerequisites

This course is designed for developers and technical leads working on systems in which software failure has material consequences: defense, aerospace, automotive systems, industrial control, robotics, infrastructure, medical devices, and finance. Examples are presented in C++, but the principles apply to any compiled systems language, and the course notes explicitly identify which parts transfer to Fortran and which do not.

Prerequisites: working fluency in a large codebase, and comfort working at the command line. No functional-programming background is assumed, and prior experience with coding agents is helpful but not required.

Where the material comes from

The course provides a small supporting library and teaches the necessary concepts as they are introduced; nothing is assumed beyond the two prerequisites above.

The material is drawn from a large, working, agent-developed system, and its case studies include defects as well as successes: a disciplined mechanism that was abandoned because it had been designed to cost more than the undisciplined alternative; an interface boundary declared in three headers but observed by only two of thirty-seven consumers; and a static check that reported zero violations because a regression had emptied the set of files it examined.

The premise

LLMs have changed the economics of software development: code is no longer the scarce resource. Judgment, architecture, verification, and control are. That shift is most difficult in high-assurance environments, where practices built around human-paced implementation and review cannot scale to agent-generated code.

The scale of this shift is worth expressing in numbers rather than adjectives. It is also worth measuring against the most expensive case, so the conclusion does not depend on a favorable discount.

An hour of agent engineering work consumes approximately two million blended tokens. At published list rates for the most expensive model available, with no prompt caching and U.S.-only data routing — the worst configuration you could deliberately choose — that hour costs approximately $31. Under ordinary operating conditions, using a mid-tier model with prompt caching, the cost is closer to $8.

Per hour of engineering work	Cost	Availability
Senior engineer, fully burdened	$150–250	Approximately 2,000 hours per year, after recruiting and ramp-up
Agent — worst case: most expensive model, no caching, U.S.-only routing	~$31	Available 24/7, with no recruiting, ramp-up, or attrition
Agent — typical: mid-tier model with prompt caching	~$8	Available 24/7

How the agent-hour figure is calculated

Source: published Claude API list prices, August 2026 — platform.claude.com/docs/en/docs/about-claude/pricing. No enterprise agreement, volume discount, or batch pricing is assumed anywhere below.

Model	Input / MTok	Output / MTok
Fable 5 — priciest current model	$10	$50
Opus 5	$5	$25
Sonnet 5	$3	$15

2,000,000 blended tokens per agent-hour 1,800,000 input x $10/MTok = $18.00 (90%, and NO caching assumed) 200,000 output x $50/MTok = $10.00 (10% ~ 55 generated tok/sec sustained) ------- $28.00 x 1.1 US-only data routing = $30.80 per agent-hour

Three choices are deliberately stacked against the argument: the most expensive model, no prompt caching — in real agentic work most input is cache reads at a tenth of the input price — and the U.S.-only routing premium. Run the same arithmetic on Opus 5 with caching and it lands near $7.50, which is the figure under ordinary operating conditions.

Two limits, stated rather than buried. Deprecated Opus 4.1 lists still higher rates of $15 / $75 and is not used, because pricing against a model no one would build on would distort the comparison. And these are Anthropic rates only; other vendors are not included.

The ratio is therefore 5–8:1 even at the highest plausible price, and 20–30:1 under normal operating conditions. The cost question is settled. The unresolved question is where the risk went.

It moved into the operating model: how do you allow agents to work continuously against a codebase without degrading it?

A fleet operating around the clock can produce more change in a week than a human team can read in a month. The resulting damage is rarely a dramatic failure that announces itself. More often it is erosion: a boundary quietly crossed, an invariant re-derived slightly differently in five places, a convention followed everywhere except the one file where it mattered, or a check that still passes because it no longer examines anything. Each change is individually plausible. Collectively, the codebase becomes worse.

The cost advantage of agent engineering is public and broadly distributed. What is not broadly distributed is the capability to run agents continuously against consequential work without allowing the codebase to degrade underneath them.

Why review does not close the gap — and why slowing down does not either

Review does not close that gap, and it cannot. A reviewer reads at human speed regardless of how quickly changes arrive, and the failures described above are precisely the ones that often look correct line by line.

Slowing the agents down does not solve the problem either; it simply gives back the advantage you were trying to obtain.

This has the familiar shape of a high-return position. The payout is not free; it compensates for structural risk. The advantage belongs not to whoever first notices the opportunity — a 20:1 ratio is visible to everyone — but to whoever can hold the position at scale.

That is the capability this course builds, and it develops one central argument from which everything else follows: you can delegate exactly as much as your codebase can refuse on its own. Constraint is not the opposite of autonomy. It is the source of autonomy. The engineering discipline that matters now is the conversion of rules that live in a reviewer's head into properties the machine can hold and enforce — so the failure modes described above stop being errors a person must catch and become errors that cannot be written.

Four principles

An agent encountering your codebase must answer four questions. The course is organized around four principles that answer those questions structurally, each transforming a class of mistakes from discouraged behavior into impossible behavior.

These principles interlock rather than merely accumulate. The connection is most visible when a proven theorem licenses a capability, allowing authority to be earned rather than asserted. It also appears when the system records the rule in force alongside the act it authorized, preventing a later rule change from retroactively justifying a past decision.

What is covered

The course consists of two days, four principles, and four hands-on labs. Each principle is taught, practiced, and applied to your own work before the next principle is introduced. Expand any block for the detail.

OPENINGDirecting agent work7 topics

• Slicing work into units an agent can actually complete — and defining what a meaningful done criterion must say
• Using tests as the oracle an agent steers by, rather than merely as after-the-fact assurance
• Treating machine-readable diagnostics as the interface against which an agent repairs its work
• Practicing adversarial verification by prompting agents to refute rather than confirm
• Knowing when to fan work out to parallel agents and when parallelism makes the problem worse
• Recognizing characteristic failure modes, including useful lies, residual chasing, and code accretion
• Understanding why review does not scale: a rule enforced only by a human erodes as quickly as the codebase grows

1Owning the floorwhat may I write?8 topics

• Why an LLM is a local reasoner and what that implies for the way code should be shaped
• Making illegal states unrepresentable through sum types, total folds, and closed vocabularies
• Turning gaps in an agent's domain knowledge into compiler errors that identify the missing case
• Using typestate to prevent values from escaping before verification, with enforcement provided by the type system
• Proving laws once per instance instead of rechecking them at every use site
• Understanding why small, closed vocabularies eliminate hallucinated APIs
• Applying compulsion: making the raw idiom unavailable, prohibited, or more expensive than the disciplined alternative, because a model reproduces the median of its training data unless the environment prevents it
• Using functional cores and algebraic data — and understanding why inheritance hierarchies are often the wrong shape for machine-written code

2Owning the shapewhat may I reach?8 topics

• Establishing one front door per tier, with improper crossings rejected by the build rather than discovered during review
• Enforcing dependency direction and typed identity as checked properties
• Understanding why encapsulation expressed only in prose is already false — and why the durable solution is structural rather than another written rule
• Treating architecture tests as the rules themselves: rules that must be conformed to rather than weakened
• Building fast checks for slow codebases, including structural, contract, and citation checks that run continuously without requiring a full compile
• Understanding instruments and why they lie: checking the denominator, preferring noisy failures to silent ones, and using control fixtures to prove that a check can actually fail
• Distinguishing ratchets from hard rules, so you can stop the bleeding in a ten-year-old codebase this week without pretending the entire system can be converted at once
• Surviving 50× output through deletion, dependency control, and explicit ledgers of deferred work

3Theorem-carrying codewhat may I claim?8 topics

• Making code verification mechanical and continuous — and understanding why verification is a different claim from validation
• Stating guarantees precisely enough to be checked, including every quantifier and every hypothesis
• Requiring guarantees to identify their supporting theorems and verifying those citations mechanically, so an unsupported claim of correctness cannot ship
• Verifying claim structure continuously while checking the underlying proofs periodically, creating a division of effort that can survive an actual delivery schedule
• Understanding why a proof kernel can be a better oracle for an agent than a compiler
• Examining why formal methods historically failed on economics rather than technical merit — and what has now changed
• Recognizing vacuous truth: a valid theorem that establishes nothing
• Stating the honest limit of a proof: what it covers, what it does not cover, and where residual risk actually remains

4Governed authoritywhat may I do?7 topics

• Establishing one layer that may say yes: the law, the record, and the seal
• Requiring authority to be claimed before action and keeping the minting of authority deliberately small
• Creating replay that establishes not only what happened, but also which rules permitted it, so a later amendment cannot retroactively justify an earlier act
• Applying attenuation so a delegate always holds strictly less authority and cannot pass on more than it possesses
• Using proof as permission by constructing an authority ladder whose every rung is supported by a theorem
• Treating model output as a proposal rather than truth through admission controls, provenance, and budgets
• Separating authoritative state from projections, logs, transcripts, and user interfaces

CLOSINGPutting it to work4 topics

• Applying the two-tier pattern: determining what belongs in a specification that a weaker model can execute and identifying what such a model will reliably fail to do
• Understanding review economics and how a small number of senior people can remain in control of a large volume of generated code
• Recognizing the single defect beneath all four principles: a gate over an empty population, a test that ran nothing, a vacuously true theorem, and a self-approved act are the same failure at four different altitudes
• Redefining the human role when agents perform the implementation

Structure of the two days

Each participant brings one capability they intend to build into a real codebase. Rather than applying the four principles to disconnected classroom examples, participants make four successive passes over the same capability. The resulting output is a four-part specification of that capability: its types, its boundary, its guarantee, and the authority required to invoke it.

What you leave with

• A capability charter for the system you came to build. It will define the capability's algebra, boundary, guarantee, and governance with enough precision for an agent to execute against it and for a review board to evaluate it.
• Working code, depending on what you bring. Participants with narrow capabilities and prepared codebases often leave with a real implementation. Others leave with a complete specification and a clear implementation path.
• A working language floor. You will leave with a foundation on which to build and a method for extracting such a floor from an existing codebase.
• Enforcement patterns you can apply immediately. These include the ratchet discipline for code that cannot yet be fully corrected.
• A catalogue of silent enforcement failures. The examples are drawn from real incidents.
• Four principles you will still be able to recite a month later — and, more importantly, an understanding of how they interlock.

Working with code you cannot share

Nothing you produce is collected, uploaded, or retained. You work on your own machine against your own repository. The instructor does not see your source code, and neither does anyone else.

Each of the four principles operates at the level of interfaces, invariants, claims, and authority. You do not need to reveal an implementation to design its algebra, state its guarantee, or determine who may invoke it. This is not a workaround for sensitive environments; it is the level at which the material itself operates.

You decide what you bring. You know your obligations — employer policy, non-disclosure agreements, export control, classification — and we do not. Please choose a capability you can discuss at the level of interfaces and guarantees. If there is any question about whether you may participate, obtain clearance from your own security office, and do not bring classified information. That determination is yours to make, not ours. See the course terms, §4.

Logistics

Lunch and refreshments are included on both days. Registered participants receive a short pre-work packet on selecting a capability. Choosing well is the most valuable preparation you can do, and it is worth thirty minutes of real thought.

Getting there — airports, hotels, and travel authorization

The course is held at the Six Gates Technology offices in American Fork, Utah, in northern Utah County. The street address, parking and directions arrive with your registration confirmation.

• Salt Lake City International (SLC) is the practical airport — roughly 35–45 minutes north by car, straight down I-15. Provo Municipal (PVU) is about 25 minutes south with limited carrier service; worth a look, but do not plan around it.
• Hotels are clustered along I-15 through American Fork, Lehi and Orem, most within a 10–15 minute drive. A rental car or rideshare is the easiest way to get around.
• If your organization requires travel authorization, begin the process early. At many laboratories and prime contractors, travel approval takes longer than payment processing, and it is the most common reason someone who wants to attend cannot. We can provide a letter or an itemized quote on request. If your approval cannot be completed in time, you may move to a later cohort at no charge — which is why three are scheduled.

Dates and registration

Three cohorts, four weeks apart, all Wednesday–Thursday. The content and labs are identical across all three — choose the one your calendar and your travel approval can actually accommodate, and note that you may move between cohorts at no charge if plans change.

August is the first presentation of this material and is priced at $1,600; September and October are $2,000.

Checkout is hosted by Stripe — pay by card or bank transfer and your seat is confirmed immediately. Card details are never sent to, processed by, or stored on our servers. Government and corporate purchase cards are accepted like any other card. Registration is subject to the course terms.

Invoices and purchase orders. Email hello@sixgates.com with your preferred cohort. We will provide a W-9, a quote, or any other documentation your procurement process requires on the same day. Your seat is held from the moment you contact us.

Cancellation and refunds

• A full refund is available when cancellation occurs at least one week before the first day of your cohort.
• Within that final week, the registration fee is nonrefundable. However, you may send a colleague in your place or move your registration to a later cohort, both at no charge. Just tell us the name or the date.
• If we cancel or reschedule a cohort for any reason, you will receive a full refund — including if we cannot fill the cohort.

Before you book travel: if we cancel, our responsibility is limited to refunding the fee. We cannot reimburse airfare or hotel bookings, so buy changeable tickets or ask us to confirm the cohort is going ahead first — we are glad to confirm. Full details in the course terms.

Questions

Can I bring code I cannot share?

Yes, and the course is designed for exactly that. You work on your own machine; nothing is collected. When participants describe their capability to the room, the rule is shape only, never content — what it is, its algebra, its guarantee, its authority. No source, no numbers, no results. Please choose a capability you can discuss at the level of interfaces and guarantees, and clear your participation with your own security office if there is any question — that determination is yours to make, not ours.

What if I can only use a smaller or on-premises model?

The course works unchanged, and the argument is stronger for you. The principles are properties of a codebase, not of a model. A frontier model can sometimes recover from a loose codebase; a smaller one cannot — so a disciplined codebase is worth more to you, not less. Bring whatever you have access to — exercises use both tiers where you have them, and we supply whatever is missing.

Do I need to know functional programming?

No. The course teaches what it needs as it goes, and each participant receives a small working library to build on rather than a reading list. Comfort with C++ and a large codebase matters far more than prior exposure to type theory.

Which cohort should I choose?

Whichever one you can actually get to. The content is identical across all three, so choose by your calendar and — more often the binding constraint — by how long your organization's travel authorization takes. If you book one and your approval slips, moving to a later cohort is free, so when in doubt book the nearest date. If your process plainly needs longer than the time remaining, register for a later cohort rather than not coming at all.

Can my organization pay by purchase order or invoice?

Yes, and it is a first-class path here. Email hello@sixgates.com with your cohort and say what your process needs — a W-9, a quote, specific invoice terms, or vendor setup — and we send it the same day. Procurement plus travel authorization is usually the long pole, which is part of why three cohorts are scheduled.

Is this about a specific product?

No. The principles are general and the exercises run on your code. Examples are drawn from a real system because real systems are the only place these failures actually show up.

Instructor

Dr. Michael Scott is the CEO and Founder of Six Gates Technology LLC, Chief AI Strategist and Co-Founder of Coreform Inc., and a former tenured faculty member at Brigham Young University. He brings extensive experience in computational science, advanced engineering software, technical leadership, and high-consequence engineering workflows. His current work focuses on governed AI systems for mission-critical technical environments.

Register or email hello@sixgates.com with a question.