Noggin Oracle: How Oversight Stopped a Codex Security Mistake
Introduction
The Noggin Oracle began as a playful coding experiment: could a digital fortune teller be built with the charm of an old arcade cabinet while staying light enough to run as a practical website feature?
It started as a Python prototype and then evolved into a standalone WordPress plugin for NogginWords. Since then, the project has moved beyond proof of concept. The live version now uses a database-backed archive of fortunes, a restricted runtime access model, and a clearer operational structure than the earliest builds.
This article is not just about what was built. It is also about how it was built, where Codex 5.4 accelerated the work, where Codex made mistakes, and why human judgment was essential throughout. That matters because experiments like this are often presented as smooth success stories. This one was more useful than that. It produced a working result, but it also exposed the exact places where AI can drift into risk if a human does not stop and challenge it.
Before looking at the cabinet itself, it is worth starting with the most important lesson from the build: AI was not just a helpful assistant. It was also a source of risk that needed human review.
Carnival Curiosities No. 7
Noggin Oracle
Step up to the cabinet and receive a fortune from Madame Aurelia, the velvet-voiced seer of the midway.
Ask a question, choose a path, and let the brass gears of the oracle prepare a mysterious little answer.
Give the cabinet a name, a question, and a path to follow.
Tap the token and let the brass gears wake the oracle.
Read the card as a prompt for curiosity, not a command.
Tap the coin to consult Madame Aurelia.
Madame Aurelia awaits...
Your fortune card will appear here.
Recent Readings
The cabinet remembers your last few fortunes in this browser session.
- No fortunes yet. Insert a coin to begin.
Madame Aurelia now guards 155 fortunes across 9 curious paths.
Human Intervention Prevents AI Security Mistake
One of the clearest failures in this project was a security mistake in the initial database design advice. Codex directed the build toward a private database connection file that would return an array containing the raw database settings, including the plain-text password. That meant the secret would not stay confined to the narrowest possible server-side boundary. Instead, the plugin path would receive the credential values and use them as normal application data. That was not a harmless shortcut. It was a bad security decision.
The danger was not theoretical. Once a password is treated like ordinary data inside application logic, it becomes easier to leak through debugging, copied snippets, stack traces, support notes, screenshots, careless refactoring, future maintenance, or accidental commits. It also widens the exposure surface if plugin code is ever mishandled or compromised. In blunt terms, Codex normalized moving a live database password around in code when the safer approach was to keep that handling more tightly contained. That is the kind of mistake that looks tidy in a fast build and ugly in a post-incident review.
The correction happened only because a human pushed back and forced a re-evaluation. The design changed after that challenge, not before it. That moment is one of the most important lessons of the project. Codex was useful, fast, and productive, but speed does not equal sound judgment. Left unchallenged, Codex was prepared to ship a weaker security pattern. Human intervention made the system safer.
Where Codex Helped
Codex was useful in several concrete ways.
Codex helped translate the original Python idea into a WordPress plugin structure, built the interaction flow, expanded the archive system, generated supporting SQL, and pushed the documentation further than it probably would have gone in a purely manual first pass. Codex was especially strong at scaffolding, iteration speed, and keeping the project moving.
That matters because many small experimental features die from friction, not from lack of ideas. Codex reduced that friction substantially.
Where Codex Drifted
Codex did not just need editing for polish. Codex needed correction in areas that mattered.
The biggest example was the credential-handling mistake already described above. That was a real security failure in the design advice. It was not caught by Codex alone. It was caught by human resistance to an unsafe pattern.
There was also process drift. Once a clean and simple SQL-based workflow had already been established, Codex still suggested a more unusual alternate route instead of staying consistent with the working process. That was not catastrophic, but it was unnecessary and confusing. It showed that AI can lose discipline even after a good pattern has already been found.
This is one of the uncomfortable truths of AI-assisted development: useful output and risky output can come from the same system in the same session. The presence of speed can create false confidence.
AI Still Needs Human Guidance
Even with AI doing much of the development work, the project is not finished by magic.
Several forms of human guidance still matter:
- External guardrails matter because human review sits outside the AI’s own assumptions, confidence, and control loop. That outside judgment is crucial because the system that creates the mistake may not be best placed to recognize it.
- Drift monitoring matters because someone has to notice when the AI starts moving away from the agreed path, adding unnecessary complexity, softening important warnings, or treating a settled decision as if it were still open. In this project, that monitoring helped keep the work aligned, safer, and more consistent.
- Product direction matters because AI can build features quickly, but it cannot decide where the Oracle should sit within NogginWords or what role it should play in the wider site.
- Tone guidance matters because the cabinet’s voice affects how visitors experience it. A human still needs to decide whether the Oracle should stay mainly mystical, become funnier, or lean more strongly into the NogginWords brand.
- Privacy judgment matters because storing visitor readings would change the nature of the feature. A human must decide whether that should happen, what should be stored, and what privacy language visitors would need to see.
- Editorial review matters because future fortunes need to feel varied, appropriate, and on-brand. AI can help generate options, but a person still needs to judge quality, category fit, repetition, and tone.
- Cost and moderation decisions matter because live AI-generated readings would introduce new risks, including cost control, content safety, quality consistency, and visitor expectations.
- Permission control matters because any future write access would change the safety profile of the system. That should be a deliberate human decision, not something added casually because it is technically convenient.
This is the real human-in-the-loop process. AI can help build the tool, but humans still decide what the tool should be, how safe it should be, and whether it serves visitors well.
OpenAI Codex
We built the Noggin Oracle with OpenAI Codex. Explore the AI coding partner behind the project and see what you can build with it.
Noggin Oracle and How It Works
The Noggin Oracle is a playful fortune teller cabinet built for NogginWords. Visitors give the cabinet a name, choose a path, ask a short question, and receive a themed fortune from Madame Aurelia.
The live cabinet now has nine paths: General, Love, Money, Future, Ancestry, Luck, Career, Mischief, and Yes or No. It draws from a curated archive of 155 fortunes, giving the feature enough variety to feel alive without needing live AI generation for every visitor.
The feature works inside WordPress rather than as a separate app. That matters because NogginWords already runs on WordPress, so the Oracle needed to fit naturally into the existing site instead of adding unnecessary hosting complexity.
The public experience is deliberately simple. The visitor sees the cabinet, asks the question, taps the coin, and receives a fortune. The more important work behind the scenes was making the project easier to maintain, easier to expand, and safer to operate without exposing visitors to technical clutter.
What Worked Well
The cabinet worked because it felt like a feature, not just a form. The visual theme, coin action, portrait, and fortune card gave the Oracle a personality visitors could immediately understand.
The WordPress plugin approach also proved to be the right fit. It kept the feature close to the existing NogginWords site instead of forcing a second application stack into the project.
The curated archive was another strength. It kept the first release inexpensive, reviewable, stable, and easier to control. Live AI generation may sound more impressive, but for this stage of the experiment, a reviewed archive was the safer and more practical choice.
The private documentation also mattered. Guardrails, setup notes, backup guidance, and operational rules turned a fun experiment into something that can be paused, checked, restored, and improved later without relying on memory.
Why This Experiment Was Built
The experiment was built to test whether AI-assisted coding could turn a creative web idea into something real, deployable, and maintainable.
The goals were practical:
- Build a distinctive interactive feature for NogginWords.
- Keep it lightweight enough for an ordinary WordPress environment.
- Avoid paid live AI calls for the first release.
- Create a structure that could grow beyond the first version.
- Keep human oversight at the center of decisions that affect safety, architecture, tone, and usefulness.
That final point became the real lesson of the build. Codex 5.4 was very good at creating momentum, but it was less reliable at knowing when a fast answer had crossed into a risky decision.
Try Our Curated Resources
The resources section of our website offers a range of tools designed to enhance your learning and creativity. Check out our selection today!
What Was Used
The prototype began in Python, then moved into WordPress so it could live naturally inside NogginWords. The public version uses front-end interaction, a WordPress plugin, and a structured fortune archive rather than live AI generation for every visitor.
Codex 5.4 was the main AI coding assistant for the build. It helped with conversion, scaffolding, interaction logic, archive expansion, documentation, and iteration. The important distinction is that Codex helped produce the project, but it did not replace human judgment over safety, tone, structure, or publication.
Limitations:
The current version is solid, but it is not complete.
There is no admin editor yet for managing the archive from inside WordPress. Reading history is temporary and only exists in the visitor’s current browser session. The archive is larger than the first version, but it still depends on deliberate writing and review rather than a richer editorial workflow.
The project also has room to improve in accessibility, privacy-conscious analytics, content management, and long-term maintenance. Those are not signs of failure. They are the natural edges of a project that reached a stable milestone without pretending to be finished.
Future Improvements
There are several sensible next steps if the project continues:
- Expand the archive with more case replies.
- Add weighted randomness.
- Build an admin interface.
- Add import and export tools.
- Improve accessibility.
- Add privacy-conscious analytics.
- Add real-time AI fortune generation.
What This Experiment Actually Proved
The Noggin Oracle proved that AI-assisted development can absolutely help turn a half-formed idea into a real, working web feature. It also proved something less flattering and more important: AI is capable of producing dangerous advice while sounding confident and helpful.
That is why the project’s real success is not just the cabinet itself. The bigger success is that the process produced a working feature, a stronger operational model, written guardrails, and a more honest understanding of what AI is good at and what it is not.
Codex was valuable. Codex was also wrong at moments when being wrong could have mattered. That is the truth worth keeping in the story.
Conclusion:
The Noggin Oracle experiment succeeded because it became real.
It moved from a Python prototype into a working WordPress feature with a structured archive, stronger operating rules, clearer documentation, and a distinct public personality. More importantly, it became a useful example of how AI-assisted development should actually be discussed: not as magic, not as failure, but as acceleration that still requires human judgment.
The cabinet now stands as a small working machine for curiosity, humour, and experimentation. It also stands as a reminder that a fast collaborator is not the same thing as a safe one. Codex helped build the project. Human review kept the project from accepting weak decisions simply because they arrived quickly.
That is probably the most valuable fortune this experiment offered.
Sources And Style References:
- NogginWords homepage: nogginwords.com
- Snake Game AI Coding Experiment: nogginwords.com/snake-game-ai-coding-experiment
- AI-generated Hangman Experiment: nogginwords.com/ai-generated-hangman
- AI D&D Adventure Generator: nogginwords.com/ai-dd-adventure-generator