I decide what the game is trying to become, what matters now and what is out of scope.
Development transparency · Updated 2026-10-19
Yes. I use AI heavily to build Kernel Panic.
AI is not a hidden helper somewhere at the edge of this project. It is part of the day-to-day development workflow: investigating code, implementing changes, refactoring, debugging, planning, brainstorming, reviewing, testing, auditing UI/UX, analysing gameplay, writing documentation and coordinating multi-agent work.
What that means
AI does real engineering work here.
Some tasks are small and mechanical. Others are broad: an agent may inspect a subsystem, propose a plan, implement it, run tests, review another agent's work or prepare a handoff for the next pass.
I also use multiple agents together. One can investigate, another can implement, another can review the result, and a Prime/orchestrator can keep the work aligned with the actual goal.
That means it would be misleading to present Kernel Panic as a project where AI only helped with autocomplete or a few throwaway snippets.
Workflow
Set direction. Implement. Review. Verify.
The useful part is not asking one model to generate everything and hoping it works. The workflow is structured around evidence and separate checks.
AI agents inspect code, reproduce problems, compare evidence and turn vague requests into testable work.
One or more agents can write or refactor code, UI, tests, docs and tooling.
Separate review passes challenge the change for correctness, UX, regressions and unsupported assumptions.
Builds, tests, captures and platform checks decide whether a result is actually acceptable.
Where AI is used
Across the project, not in one isolated category.
Feature implementation, bug fixes, refactors, integration work and small utilities can all be written with AI assistance.
FrequentAgents inspect logs, reproduce problems, compare code paths and challenge assumptions before a fix is accepted.
FrequentAI is used to audit screens, responsive behavior, input, information hierarchy and gameplay clarity. Suggestions are still judged against the game itself.
FrequentLarge changes are often decomposed into specs and implementation plans so that later agents can work from the same constraints.
FrequentSeparate passes check code, gameplay, visuals, builds and documentation instead of treating the implementing agent as its own final authority.
FrequentHandoffs, plans, release notes and technical explanations are often drafted or reorganized with AI, then checked against the current project state.
FrequentHuman responsibility
AI does not get the final say.
I decide what Kernel Panic should be, which problems matter, what is in scope, which ideas fit the game and whether a result is good enough to keep.
AI output is not treated as correct because it is fluent, compiles or looks confident. Code still needs to survive the actual project: tests, runtime checks, captures, platform constraints and review.
If I accept AI-written code into the project, it becomes my responsibility. “The model wrote it” is not an excuse for a bug, a bad design decision or something I did not understand well enough to maintain.
Limits
AI is useful and still wrong in very normal ways.
It can hallucinate project state.
An agent may confidently describe a feature that only exists in a roadmap, confuse an old handoff with current code or assume a release exists because metadata was bumped.
VerifyIt can optimize the wrong thing.
A technically clean refactor can still damage gameplay, tone, usability or the constraints that made a system work.
JudgeIt can produce convincing slop.
UI, copy and architecture can look polished while feeling generic. I explicitly reject generic SaaS patterns, fake hacker aesthetics and filler that does not belong to the game.
RejectIt needs context.
Agents work much better when the task includes the current code, real constraints, exact screenshots and a review loop instead of a vague “make this better”.
ContextMy personal opinion
Programming is not a typing contest.
I consider AI a legitimate programming tool. I do not think manually typing every line is what makes software legitimate.
What matters to me is whether I understand the system well enough to direct it, debug it, evaluate architecture and trade-offs, test it, reject bad output and take responsibility for what ships.
Using AI does not remove judgment from programming. In my workflow it makes judgment more important, because generating a plausible answer is often the easy part. Knowing whether that answer actually belongs in the project is the work.
Going forward
The policy is simple: use the tool, keep the standard.
I expect AI to remain part of Kernel Panic development. The exact models and workflows can change. The standard does not: evidence over confidence, review over blind trust, and the game itself over whatever an agent thinks a modern project is supposed to look like.