← 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 21–22, 2026. Two days each, 8:30 am – 4:30 pm Mountain. Attend onsite in American Fork, Utah, or live online — the same instructor, the same labs, the same two days.
Who this course is for
This course is a field report from our own system.
At Six Gates, large teams of AI agents write code day and night. The codebase has to survive them. We learned everything taught here the expensive way: by watching what fleets of agents did to a real codebase over months, then building the mechanisms that kept it coherent.
This is not a survey of the literature or a prediction about where software development is going. It is an account of what failed, what worked, and what continued to work under pressure.
The course is for engineers whose software has real consequences when it fails: defence, aerospace, industrial control, robotics, infrastructure, medical devices, and finance. It is also for researchers and graduate students building systems intended for those environments.
What you need
You need three things:
- C++: enough to read and write it comfortably.
- Command-line confidence: enough to build, inspect, and work with an unfamiliar repository.
- Your own software: a real codebase and one capability you intend to build into it.
That codebase might contain thesis code, a lab simulation, an instrument controller, a project you maintain, or the system your team ships. Its size does not matter. Having something real to apply the course to does.
You do not need a background in functional programming, experience with proof assistants, or prior work with coding agents. The course introduces the concepts it needs as they arise and provides the repository you will build on.
After registering, you will have one preparation task: clone and build the course repository before day one.
A real codebase matters more than seniority. A graduate student who brings thesis code is likely to get more from these two days than a twenty-year veteran who brings nothing to apply them to. A student rate is available.
Structure of the two days
The four hands-on labs are successive passes over the capability you bring. The work accumulates: each principle adds another part of its specification instead of resetting around a new classroom example.
By the end of the second day, you leave with a four-part specification of real work: the guarantee it must establish, the types that determine what may be expressed, the boundary that governs what may be reached, and the authority required to invoke it.
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 lands hardest in high-assurance environments, where practices built for human-paced implementation and review cannot absorb agent-paced output.
An agent-hour consumes roughly two million blended tokens. Even under deliberately conservative assumptions—the most expensive available model, no prompt caching, and U.S.-only routing—it costs approximately $31. Under ordinary operating conditions, using Opus 5 with prompt caching, it costs closer to $8.
| Per hour of engineering work | Cost | Availability |
|---|---|---|
| Senior engineer, fully burdened | $150–250 | About 2,000 hours per year, after recruiting and ramp-up |
| Agent inference, conservative upper bound | ~$31 | Available continuously |
| Agent inference, typical conditions | ~$8 | Available continuously |
These figures compare marginal implementation capacity, not complete teams. The agent figures cover model inference only; fleets still require supporting infrastructure and architectural direction—the scarce resource this course is about.
How the agent-hour figure is calculated
Source: published Claude API list prices, August 2026. No enterprise agreement, volume discount, or batch pricing is assumed.
The conservative case uses two million tokens per agent-hour: 1.8 million input tokens and 200,000 output tokens.
This stacks three choices against the argument: the most expensive current model, no prompt caching, and the U.S.-only routing premium. The same workload on Opus 5 with ordinary caching lands near $7.50.
The calculation uses Anthropic rates only. The more expensive but retired Opus 4.1 is excluded because it is not a model anyone would now build around.
The hourly cost ratio is 5–8:1 even under the conservative model-pricing case and 20–30:1 under normal conditions. Implementation capacity is no longer the economic constraint. The unresolved question is where the risk went.
It moved into the operating model.
At fleet scale, code production and human review no longer exist in the same order of magnitude. In our experience, one experienced software architect directing a fleet of ten agents can produce hundreds of commits a day. By the time a human team has understood the first wave of changes, several more have been produced.
The damage rarely arrives as one dramatic failure. It appears as erosion: a boundary quietly crossed, an invariant re-derived differently in five places, or a check that still passes because it no longer examines anything. Each change looks plausible on its own. Together, they make the codebase worse.
Review cannot close that gap. Reviewers still read at human speed, and these failures often look correct line by line. Slowing the agents merely gives back the advantage.
The cost advantage is public and broadly distributed. The ability to capture it without degrading the codebase is not.
That is the capability this course builds. Its central argument is simple:
Constraint is not the opposite of autonomy. It is the source of autonomy. The engineering task is to convert rules that live in a reviewer’s head into properties the machine can enforce—so invalid changes are rejected before they land.
Four principles
An agent working in a consequential codebase cannot be governed by rules it is merely expected to remember. At each point of change, it must be able to determine what must be true, what may be expressed, what may be reached, and what may be done. Those answers must be encoded in the system itself, so that a violation is refused where it is attempted rather than discovered later in review.
These are not four parallel techniques. The course develops one discipline—evidence must precede permission—at four levels. Owning the truth is the substrate: a claim identifies the theorem that supports it. At the level of the floor, admissible values carry evidence the compiler can check. At the level of shape, architecture rules make reachability a build property. At the level of authority, verified state licenses a capability before the act is allowed. The object changes; the logic does not.
Across two days, 42 topics and four hands-on labs develop that argument from directing individual agent tasks to governing fleet-scale implementation. Each principle is taught, exercised in the course repository, and applied to your own code before the next is introduced.
Expand a block to see the syllabus.
OPENINGDirecting agent workBounded tasks, executable done criteria, and adversarial verification7 topics
- Work units with an exit. Cut work small enough for an agent to finish, and make “done” an observable, testable condition.
- Tests as steering oracles. Give the agent a signal it can follow while it works, not merely evidence inspected afterwards.
- Diagnostics as a repair interface. Return failures in machine-readable form so the agent can locate, interpret, and correct its own work.
- Adversarial verification. Ask agents to refute a result, find counterexamples, and expose missing assumptions—not to confirm the answer you hope is true.
- Disciplined fan-out. Parallelise independent work; recognise when shared state or coupled decisions make more agents worse.
- Characteristic fleet failures. Detect useful lies, residual chasing, and code accretion before they become the operating norm.
- The limit of review. A rule enforced only by a person erodes as quickly as the codebase grows; human review cannot control agent-scale output.
1Owning the truthWhat must be true?An unearned claim cannot ship8 topics
- Verification is not validation. Keep the claims distinct, then make code verification mechanical and continuous.
- Guarantees with full scope. State every quantifier and hypothesis; only a precise guarantee can be checked.
- Claims must cite their proofs. Require each guarantee to name its supporting theorems, and verify those citations mechanically so unsupported correctness claims cannot ship.
- Two cadences of assurance. Check claim structure continuously and the underlying proofs periodically—a division of effort that survives a real delivery schedule.
- A proof kernel as oracle. Identify when it gives an agent a stronger judge than a compiler can provide.
- Formal methods after the economic shift. Examine why they historically failed on cost rather than technical merit—and what has now changed.
- Vacuous truth. Detect a theorem that is valid yet establishes nothing: the defect that returns in each of the other three principles under a different name.
- Honest proof boundaries. State what a proof covers, what it does not, and where residual risk remains.
2Owning the floorWhat may be expressed?The wrong code has no valid expression8 topics
- Code for a local reasoner. Shape code around how an LLM actually reasons and the context it can reliably use.
- Illegal states without a representation. Use sum types, total folds, and closed vocabularies to exclude them.
- Domain omissions as compiler errors. Turn a gap in an agent’s knowledge into an explicit missing case.
- Verified before escape. Use typestate to prevent a value leaving the verification process before the type system permits it.
- Laws paid for once. Prove them per instance instead of rechecking them at every use site.
- Closed vocabularies against invented APIs. Small, finite interfaces leave no room for hallucinated operations.
- Compulsion, not advice. Remove, prohibit, or make costlier the raw idiom; otherwise the model reproduces the median of its training data.
- Functional cores over inheritance trees. Use algebraic data and functional cores, and see why inheritance hierarchies are often the wrong shape for machine-written code.
3Owning the shapeWhat may be reached?The wrong dependency fails the build8 topics
- One front door per tier. Improper crossings fail the build instead of waiting for review.
- Checked dependency direction and typed identity. Make both properties of the system, not conventions.
- Structural encapsulation. A boundary expressed only in prose is already false.
- Architecture tests as law. Code must conform to the rule; the rule is not weakened to admit the code.
- Fast checks for slow codebases. Run structural, contract, and citation checks continuously without requiring a full compile.
- Instruments that prove they work. Inspect the denominator, prefer noisy failure, and use control fixtures to demonstrate that every check can fail.
- Ratchets for legacy systems; hard rules for new ground. Stop further degradation now without pretending a ten-year-old codebase can be converted at once.
- Control at 50× output. Use deletion, dependency control, and explicit ledgers of deferred work to keep growth survivable.
4Governed authorityWhat may be done?An unpermitted act cannot commit7 topics
- One layer may say yes. Place the law, the record, and the seal at a single authority boundary.
- Authority before action. Require it to be claimed first, and keep the code that mints it deliberately small.
- Replay with its law attached. Reconstruct what happened and which rules permitted it, so a later amendment cannot retroactively legitimise an earlier act.
- Attenuated delegation. Every delegate holds strictly less authority and cannot pass on more than it possesses.
- Proof as permission. Construct an authority ladder with every rung supported by a theorem.
- Models propose; admission controls decide. Use provenance and budgets to govern what may enter authoritative state.
- One authoritative state. Keep it distinct from projections, logs, transcripts, and user interfaces.
CLOSINGPutting it to workSenior control over fleet-scale implementation4 topics
- The two-tier pattern. Write specifications a weaker model can execute, and identify the work it will reliably fail to do.
- Review economics at fleet scale. Keep a small number of senior engineers in control of a large volume of generated code.
- One defect at four altitudes. A vacuous theorem, a floor nobody walks on, a gate over an empty population, and a self-approved act are the same failure—named in the first hour and confronted in every principle thereafter.
- The human role after implementation becomes abundant. Direct, specify, constrain, and verify the work agents perform.
The sequence matters because the mechanisms are designed to interlock. A theorem established under Owning the truth can license a capability under Governed authority. Authority is then earned from verified state, not asserted by the component that wants to act.
The authorisation record binds each act to the rule that permitted it. A later amendment may govern future acts; it cannot retroactively legitimise a past decision.
What you leave with
You leave with two things: the four-part specification developed in the labs and a working C++ repository built to enforce the same discipline.
The repository is the principal course artefact. It is machinery you can run, inspect, and build on—not a demonstration you must reconstruct from notes. The project builds, its Lean proofs check, and its gates reject changes that violate its rules.
Access begins before day one and continues after the course under the course licence. You can use the repository as the foundation of a new system or transfer its mechanisms into a codebase you already maintain.
The repository contains three integrated enforcement systems:
- Proof and authority. A compiling Lean library contains proved theorems, the explicit relation between theorem evidence and the capabilities it may authorise, and a citation check that rejects any guarantee whose named theorem cannot be resolved or does not carry the required licensing metadata.
- A constrained C++ floor. Roughly a dozen law-checked constructs—including closed vocabularies, total folds, and typestate—provide a disciplined language for implementation. The set is small enough to inspect and understand as a whole.
- A ratcheted change gate. A server-side push gate rejects a change only when it introduces a new violation. An existing codebase can therefore adopt it without first eliminating every inherited defect. Each rule reports the population it examined and includes a known-bad control fixture that must be detected. A green gate must show both what it checked and that it remains capable of failing.
The foundation is proved, not asserted
The repository is held to the standard it imposes.
Within the supplied formal model, Lean checks the stated algebraic laws for the total fold and the replayable program representation. It also checks two properties of the authority mechanism: that a delegated capability is strictly weaker than the capability from which it was derived, and that the required theorem-to-capability relation holds before authority is granted.
These are deliberately bounded claims about the formal definitions, not a blanket assertion that every C++ program built from the repository is correct. The proof boundary remains visible: what has been established, under which assumptions, and what still has to be trusted.
This is the discipline taught by the course, applied to the thing we hand you.
Repository access, setup, and licence · Private GitHub access is included
Repository access is included with your seat. The repository is private and hosted on GitHub. Your invitation arrives in a separate email shortly after registration, together with the pre-work packet and build instructions.
Clone and build it before day one. Once its dependencies are installed, the project, proofs, and course checks run locally on your own machine without a network connection. Completing the toolchain setup in advance keeps course time available for the engineering itself.
The licence permits use within your own organisation and in work built from the repository, including products. It does not permit redistribution of the repository itself. The full terms in §6 govern.
Working with code you cannot share · Your source remains on your machine
The course does not require you to submit source code, upload completed work, or expose an implementation. You work locally against your own repository. The instructor does not inspect your source, and other participants do not need to see it.
The same rules apply in both formats. Virtual participants are not required to share their screens. Six Gates does not record sessions, and participant recording is prohibited.
The four passes operate at the level of guarantees, types, boundaries, and authority. You can therefore design a capability’s algebra, state its guarantee, define its boundary, and determine who may invoke it without revealing its implementation. This is not a workaround added for sensitive environments; it is the level at which the material itself operates.
You remain responsible for your employer or university policies, non-disclosure obligations, export controls, and classification rules. Choose a capability you are permitted to discuss at the level of interfaces and guarantees. If there is any uncertainty, obtain clearance from your own security office. Do not bring classified information. Any editor, coding agent, or model service you choose to use remains subject to its own data-handling terms; the commitments above apply to Six Gates and the course workflow. See the course terms, §4.
Dates and registration
All three cohorts run Wednesday–Thursday and cover identical material.
| August 19–20, 2026 | September 16–17, 2026 | October 21–22, 2026 | |
|---|---|---|---|
| Onsite | $1,600 | $2,000 | $2,000 |
| Live online | $1,200 | $1,600 | $1,600 |
| Full-time student · live online | $500 | $500 | $500 |
August is the first presentation of the course. Student seats are not capped. All prices are per seat.
Choose your cohort and seat type, then check out online. Your seat is confirmed when checkout is complete.
Stripe accepts cards and bank transfers, including government and corporate purchase cards. Payment details are processed by Stripe and never pass through Six Gates’ servers.
Student checkout asks for your university and university email address. Eligibility is confirmed with your welcome email; if it cannot be confirmed, your payment is refunded in full.
For an invoice, purchase order, W-9, quote, or other procurement documentation, email hello@sixgates.com. Your seat is held from the moment you contact us.
Changes and refunds
- Change cohort or format: No change fee. For standard seats, switching formats adjusts the tuition by $400.
- Cancel at least seven days before your cohort: Full refund.
- Cancel within seven days: Tuition is non-refundable, but you may send a colleague, move to a later cohort, or change format.
- If Six Gates cancels or reschedules: Full tuition refund, including if a cohort does not fill.
Six Gates cannot reimburse airfare or hotels. Onsite participants should buy changeable travel or ask us to confirm that the cohort will proceed before booking. Registration is subject to the course terms.
Logistics
| Duration | Two days · 8:30 am–4:30 pm Mountain Time |
|---|---|
| Format | Onsite in American Fork, Utah · or live online |
| Labs | Four labs, all applied to one capability from your codebase |
| Pre-work | Choose that capability, then clone and build the course repository |
| Coding agent | Use your preferred frontier coding agent · the instructor uses Claude Code |
| Onsite includes | Lunch and refreshments on both days |
Attending live online
The online seat is the complete course delivered live—not a recording or a reduced version. You work locally on your own machine and are never required to share your screen. Six Gates does not record the course, and participant recording is prohibited.
Joining details arrive after registration. There is no travel authorisation or travel spend. If you are outside North America, contact us before registering and we will tell you plainly whether the Mountain Time schedule is workable.
Attending onsite
Onsite sessions are held at the Six Gates Technology offices in American Fork, Utah. The address, parking information, and directions arrive after registration.
Salt Lake City International Airport (SLC) is normally 35–45 minutes away by car. Provo Airport (PVU) is about 25 minutes away but has limited service. Hotels in American Fork, Lehi, and Orem are generally within a 10–15 minute drive; a rental car or rideshare is simplest.
If your organisation requires travel authorisation, begin early. We can provide a supporting letter or itemised quote.
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, and you are never asked to share your screen in either format. When participants describe their capability — in the room or on the call — 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 gets a working repository to build on rather than a reading list — the floor is already written, law-checked, and running, so you start by using it rather than by designing one. Being comfortable in C++ and having something of your own to apply it to matter 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. Travel authorisation used to be the binding constraint here; now it decides your format rather than whether you attend at all. When in doubt book the nearest date — moving to a later cohort is free, and so is switching format if your approval lands late or not at all.
Should I take an onsite seat or a virtual one?
The course is the same either way: same instructor, same four labs, same two days, and you leave with the same capability charter. Take the onsite seat if you want the hallway conversations and the room's full attention for two days — that is genuinely worth something, and it is why it costs $400 more. Take the virtual seat if travel approval is slow or uncertain, if your travel budget is committed elsewhere, or if two days away is the thing that would stop you coming. A virtual seat that you actually attend beats an onsite seat you had to cancel, and you can switch either direction at no charge.
Can my organisation 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 authorisation 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.