Field notes from building software in real operational environments.

What "AI-Assisted" Actually Looks Like on BrightBound's Sprint Board

BrightBound's latest sprint shipped a reward-transaction service, an extruded-3D world map upgrade, and a CI fix — with AI assistance on every commit. None of that means the AI was in charge. The sprint tracker, not the model, decided what counted as done, and the diffs are more interesting for what they deliberately left out than for what they added.

Idempotency Was the Actual Requirement

• The new reward-transaction service applies XP, levels, stars, streaks, and unlock detection as one operation — persisted to storage before it returns, so a killed-and-relaunched app replays the same result instead of re-earning anything.
• That constraint — idempotent by outcome ID — was written down before generation started, not discovered by testing the output afterward.
• Migrating existing call sites to the new service was explicitly deferred rather than rushed in the same change, once it surfaced that two screens each ran their own independent achievement tracking for one quiz completion.

Writing Tests Found Three Real Bugs Before Users Did

• Eighteen structural regression tests for the world map screen — three viewports, two themes, three checks each — were written as a safety net before a larger rebuild, not after a bug report.
• Those tests immediately caught a negative-margin assertion crash on keyboard focus, an unconstrained button label overflowing in narrow layouts, and a second overflow in a quest-reward preview row.
• The tests use render-without-exception and content assertions rather than pixel-perfect golden images, because CI runs on Linux and the authoring machine runs Windows — different pixel goldens for reasons that have nothing to do with real regressions is a false signal, not a safety net.

Scope Deviations Were Written Down, Not Hidden

1. The sprint tracker records what shipped, what was deliberately deferred, and why — a structural-tests-instead-of-pixel-goldens call and a service-built-but-call-sites-not-yet-migrated call, both dated and explained rather than silently left out of the summary.
2. A stale documented file path was caught and fixed in the same session it was noticed, instead of being left for the next person to rediscover the hard way.
3. A CI failure — deprecated GitHub Actions versions and a Node version mismatch — was fixed the same day it was observed watching a real deploy run, not filed as a ticket for later.

None of this is exotic. It's the same discipline from Prompt-to-Production applied to a real sprint: name the constraint before generating, verify with tests that would actually catch a regression, and write down what you chose not to do. The AI made the loop faster. It didn't make the loop optional.

Paying Down Architecture Debt on Purpose: Inside OmenCore v4.0.0

OmenCore v4.0.0 is a major version bump with no new fan curves, no new lighting modes, and no new hardware control surface at all. That was the point. Thirteen releases since April had been feature and fix work landing on top of a `MainViewModel` god-object with roughly 40 manually-wired fields and a 27-timer sprawl across three different timer APIs. v4.0.0 is the release where I stopped adding to that pile and started paying it down.

Why a Major Version With Zero Control-Behavior Changes

• A real dependency-injection composition root now owns 19 of roughly 40 previously manually-wired fields, with hardware bring-up — NVAPI, PawnIO, WMI BIOS, capability detection, EC and fan-controller construction — extracted into its own class as a prerequisite for the rest of the migration.
• A shared polling scheduler now drives the tray icon, quick popup, and OSD timers as a first cut at consolidating that 27-timer sprawl — accurate count, corrected from an earlier "21 timers" estimate that turned out to be wrong once I actually counted.
• Roughly 80 lines of dead, orphaned undervolt UI wiring came out — a second, meaningfully-behind copy of logic that already existed correctly elsewhere, bound to a view that was never in the app's visual tree.

Refactoring Found Two Real Safety Bugs

• The sensitive-model startup-restore check had a live, un-updated copy of the exact fragile-string-match bug already fixed elsewhere in v3.8.1 — it could silently skip the extra safety opt-in it exists to enforce.
• The "disable thermal protection" toggle's documented promise — fans will never be automatically overridden — didn't actually hold for custom fan curves, because a separate always-on safety clamp ignored the toggle entirely. The emergency-override temperature was also hardcoded at 95°C; it's configurable now.
• Neither bug was found by looking for bugs. Both surfaced from reading the code closely enough to move it, which is the real argument for doing this kind of pass at all.

What Shipped Alongside the Cleanup

1. A community-contributable model-database pipeline — JSON schema, a dependency-free validator, a PR template, and a CI job — so new hardware support doesn't have to funnel through one person hand-writing every entry.
2. A persistent "Model Capabilities" diagnostics panel showing what your exact model does and doesn't support, and whether that's field-verified or inferred, before you go looking for a setting that was never going to be there.
3. An accessibility labeling pass across five views — roughly 140 previously-silent controls now announce correctly to screen readers.

953 of 953 tests passing, zero build warnings, and not one changed fan curve. Sometimes the release that matters most is the one where nothing visible changes at all.

Building an AI Feature That Isn't Allowed to Lie: PageCue's Spoiler-Safety Validator

PageCue's entire premise — remind a reader what happened in a book up to their current page, without spoiling anything past it — fails the instant a model quietly reaches past the boundary it was given. The fix wasn't a better prompt. It was refusing to trust the model's output at all until a deterministic validator has checked it.

Never Display Unvalidated Model Output

• Every recap — mock or real — passes through the same validator before it reaches the screen, rejecting unknown segments, future-segment references, cross-book segment references, boundary-label mismatches, and unsupported or premature-resolution claims.
• The validator is deterministic code, not another model call asked to grade the first one — asking an LLM to police an LLM just moves the trust problem one layer down instead of solving it.
• The demo content itself is built to make this checkable: six strictly cumulative story snapshots, one per chapter boundary, where later snapshots simply cannot reference anything a reader hasn't reached yet.

The Same Instinct as "Never Fabricate a Zero"

• OmenCore reports a missing sensor as unavailable instead of a misleading 0W. PageCue's validator rejects an unsafe recap instead of silently trimming it and hoping the trim was clean. Same principle: an honest failure beats a confident-looking wrong answer, every time.
• A safe boundary-selection function always resolves to the earlier of two supported boundaries when progress is ambiguous — for example, page-based progress without an exact page map — and labels that choice as approximate instead of pretending precision it doesn't have.
• Zero-credential mock providers make the whole flow, including the validator, testable without an API key — which is also why the validator's test suite runs against real malicious fixtures, not just the happy path.

What This Costs, on Purpose

1. The validator can reject a technically-plausible recap for being unprovable against the confirmed boundary — a false rejection is the safe failure mode here, not a false pass.
2. Every new recap style or provider has to pass through the same validation contract, which is friction by design: the boundary logic is not something any single feature gets to bypass for convenience.
3. None of this is visible to a reader who never hits the edge case. It only matters the one time a model would otherwise have guessed — which, with books, is exactly the moment trust breaks for good.

Filling the Gaps Nobody Else Will Build For

The most useful thing I have shipped this year was a portable app that lets a $12 Bluetooth mouse remember its own name. None of my higher-concept projects have taught me as much about product judgment as the small, unglamorous tools built purely because something kept being annoying.

The Pattern Behind MouseTune, PageCue, and the Steam Launch Scripts

• MouseTune exists because generic Bluetooth mice show up in Windows as "BT 5.2 Mouse" with no vendor app and no DPI control — a real gap between "expensive gaming mouse with software" and "nothing at all."
• The Epic Games and Rockstar Steam launchers exist because launcher-locked PC games actively fight Steam's non-Steam-game model, and the fix requires digging through manifest files most players will never open.
• PageCue started as a bare concept and is now a working Next.js app, because the gap — remembering where you left off in a book without a spoiler-risk web search — turned out to have a settled shape once the spoiler boundary itself became the design constraint.
• NBN Compare exists because Australia's ISP comparison sites are commission-driven, not because the market lacked comparison tools generally.

Why These Projects Are Worth More Than Their Size Suggests

• Big platforms rationally ignore niches this narrow — there is no venture-scale market in Bluetooth mouse naming, and that is exactly why nobody else has fixed it.
• Annoyance is a better product brief than ambition: you already know the exact failure mode, the exact user, and the exact definition of "done."
• Scope discipline gets easier when the tool's job is one sentence long. MouseTune's own README lists what it will never do — vendor integration, RGB, macros, cloud sync — as a feature, not a limitation.
• Shipping something narrow and finished beats shipping something broad and half-working, and it is far easier to actually reach "finished."

How I Decide Something Is Worth Building

1. Has this specific annoyance cost me real time more than once, not just hypothetically?
2. Can I describe the fix in one sentence without a feature list attached?
3. Would a non-technical user actually be able to run it without me standing over their shoulder?
4. Am I willing to explicitly write down what it will not do, and mean it?

Where AI Actually Earns Its Keep in a School Day

Most AI-in-education coverage is either breathless or dismissive. Sitting in senior leadership while also building the software, I see a narrower, less exciting truth: AI earns its place in a school day only where it removes a specific, repeated, low-judgment task — and it stays firmly out of the ones that need a human.

Where It Genuinely Helps

• First-draft communication — turning a pastoral incident's raw notes into a clear, consistent parent-facing summary that a staff member then reviews and personalizes.
• Pattern surfacing across attendance, behavior, and engagement data, so a leader spots a trend a week earlier instead of discovering it at a term review.
• Cutting the admin tax on differentiation — generating a first pass at three difficulty tiers of the same worksheet for a teacher to adjust, instead of building each from scratch.
• Freeing senior leadership time from formatting and compiling so more of it goes to the actual pastoral conversation.

Where It Does Not Belong

• Any decision affecting a specific student's wellbeing outcome — triage, escalation, and duty-of-care calls stay human, full stop.
• Assessment of original student work, where provenance and academic integrity are the entire point.
• Anything that quietly becomes a shadow record-keeping system outside governed, auditable platforms like STARS.
• Communication that pretends to be personal when it was not — parents and staff notice, and trust is expensive to rebuild.

A Simple Filter for Adoption

1. Is the task repeated, well-defined, and low-judgment? If not, it is not a good AI candidate yet.
2. Does a human still review the output before it reaches a student, parent, or record? If not, redesign the workflow first.
3. Does the tool run inside existing privacy and governance boundaries, or does it require a new one? A new boundary is a real cost, not a footnote.
4. Would removing the tool tomorrow break anything beyond convenience? If yes, it has become infrastructure and needs infrastructure-level scrutiny.

Prompt-to-Production: A Checklist for Shipping AI-Generated Code Responsibly

I use AI assistance on nearly everything I ship now, from OmenCore's fan-safety fixes to a weekend Steam launcher script. The output quality is not the risk anymore — the risk is treating a plausible-looking diff as a reviewed one. This is the checklist I actually run before anything AI-assisted reaches a release branch.

Before Generation

• Write the constraint list first — what must never happen — before writing the prompt. OmenCore's "never silently re-apply a GPU overclock on battery" rule exists because that constraint was explicit going in.
• Name the failure mode you are most worried about out loud. If you cannot name one, you are not ready to generate yet.

Before Merge

• Read every line changed, not just the parts that look unfamiliar — familiar-looking code is where generated bugs hide best.
• Check for fabricated certainty: does the code report a value it does not actually have, instead of an honest "unavailable" state?
• Trace the actual data and permission boundaries touched, not just the happy path the prompt described.
• Ask what happens on partial failure — a crash mid-write, a dropped connection, a missing sensor — since generated code often only handles the case it was shown.

Before Release

• Confirm a human can explain why the change works, not just that it passed tests — if you cannot explain it, you cannot maintain it in six months.
• Document the rationale next to the code, especially for any safety or privacy boundary, so the next change (AI-assisted or not) does not quietly erode it.
• Ship it small. A narrow, reviewable diff is easier to hold yourself accountable for than a sweeping one, AI-assisted or otherwise.

Field-Driven Releases: What Six OmenCore Updates Taught Me About Cadence

Since April, OmenCore has shipped six releases — v3.4.0 through v3.8.1 — and almost none of them came from a roadmap slide. Each one traced back to a specific GitHub issue, a specific laptop model, and a specific way the previous build got something wrong. That cadence taught me more about sustainable maintenance than any greenfield rewrite has.

Why Small and Frequent Beats Big and Rare

• Hardware bugs only surface once real laptops with real BIOS quirks report them — you cannot pre-empt every OMEN or Victus variant from a dev machine.
• Bundling fixes into infrequent, large releases means the one model that needs a fix waits months for unrelated work to also be ready.
• Narrow, frequent patches get a fix to the affected hardware fast without forcing everyone else onto unrelated changes.
• A short release-to-release distance keeps each diff small enough to actually review properly.

Telemetry Has to Tell the Truth

• A missing sensor reading is not the same as a zero reading, and control software that conflates the two erodes trust the moment someone notices.
• v3.8.x moved CPU/GPU power and RPM displays from a misleading "0W" or "0RPM" to an explicit unavailable or driver-required state.
• Once telemetry is honest about its own confidence, every other diagnosis a user makes from that data gets easier.

Safety Gates Are Worth the Friction

• A startup GPU overclock restore quietly re-applying an OC increase on battery is not a cosmetic bug — it is a hardware-safety bug wearing a UI bug's clothes.
• Fan, EC, and firmware writes stay blocked until there is model-specific validation, even when that slows a feature down.
• The fix that closes a safety gap matters more than the feature that would have shipped instead that week.

Vibe Coding and Its Rise: Fast Output, Slower Accountability

Vibe coding is everywhere because it feels productive. Prompt, paste, ship. The speed is real, but so is the risk: teams can outsource responsibility faster than they outsource effort.

Why It Is Growing So Fast

• Lower startup friction for greenfield prototypes and small utilities.
• Clear dopamine loop: visible output appears in minutes, not days.
• Language barriers drop, so more people can contribute to technical workflows.
• Tooling quality has improved enough that first drafts often look production-ready.

Where Teams Get Burned

• Generated code arrives without architectural context or operational ownership.
• Security, privacy, and failure-mode thinking are treated as post-processing.
• Review standards become style-focused instead of behavior-focused.
• Maintenance debt compounds because no one truly understands the decision trail.

A Better Pattern

1. Use AI for acceleration, not authority.
2. Pin explicit constraints before generation begins.
3. Run review against behavior, threat model, and maintainability.
4. Document rationale so future changes are intentional, not accidental.

The Power of AI-Assisted Development in VS Code

AI support has shifted my workflow from tool friction to higher-order reasoning. The value is not replacing engineering judgment; it is accelerating disciplined execution.

Where It Helps Most

• Turning architecture intent into clean scaffolding quickly.
• Tracing call paths and side effects during refactors.
• Generating first-pass tests, then tightening coverage manually.
• Reducing context-switching overhead while learning unfamiliar stacks.

What Still Requires Human Ownership

• Defining the problem and selecting meaningful constraints.
• Assessing security and privacy implications of every decision.
• Validating correctness, maintainability, and behavior under load.
• Owning outcomes rather than accepting generated output blindly.

Current Workflow Pattern

1. Clarify objective, constraints, and expected operational behavior.
2. Generate structure and baseline implementation rapidly.
3. Iterate with targeted refactors and explicit test expansion.
4. Document design rationale and unresolved risks before release.

Designing Privacy Into Busy School Workflows

Privacy failures in education are rarely caused by bad intent. They usually come from rushed workflows, unclear access boundaries, and systems that make the wrong path easier than the right one.

Practical Patterns That Work

• Default to least-privilege roles and only elevate when required.
• Design forms around the minimum data needed for a decision.
• Make every sensitive action auditable without adding staff burden.
• Keep exports and sharing controls explicit and hard to misuse.

Maintenance Over Momentum: Why Reliable Beats New

Teams often celebrate velocity while quietly absorbing maintenance debt. Sustainable software delivery comes from reducing cognitive load and making systems easier to operate month after month.

Signals a System Is Becoming Fragile

• Small changes require coordination across too many files or people.
• Incidents recur because root causes remain unaddressed.
• Documentation lags behind actual runtime behavior.
• Only one person can safely release a feature.

Offline-First Is a Pedagogical Decision, Not Just a Technical One

Connectivity constraints change classroom behavior. If software degrades under poor internet conditions, learning time is lost and trust in the tool drops quickly.

What Good Offline Design Looks Like

• Core learning paths stay available with zero network dependency.
• Local storage keeps progress safe until sync is possible.
• Teachers can still monitor essential progress signals offline.
• Sync conflicts are visible and recoverable, not hidden.