AI & apps.
Useful tools. Playful ideas.

My role and the use of AI

I directed the concept, name, features and iteration, using Codex to assist with implementation, question drafting, tests and deployment. I played the game and used that feedback to guide the next changes. AI assistance is part of the development process; no language model runs during a game.

How a round stays fair

A shared server clock advances writing, voting and reveals. The server keeps the answer bank out of the browser and calculates points: 1,000 for identifying the truth and 500 for each player fooled. Computer opponents submit preset decoys and choose eligible answers randomly without consulting the truth flag.

Checks and limits

The 700-question release passed 19 game and content tests, type checking and a production build. A public two-session check verified genre selection and two scored rounds; full five-round local checks covered shared settings and game progression. Phone-sized layouts were inspected separately. These checks are not a large-scale load test. Source links make facts reviewable; reference availability alone does not establish factual accuracy.

Privacy and replay

Players use nicknames and room codes without game accounts. Bluffs are stored on the game server to run the room; this is not browser-only processing. Rooms expire after 24 hours, and expired records are cleaned up when another room is created. Room history avoids repeated questions until the selected pool cycles.

What the model receives

The creator companion sends the user’s dish request and visible preferences. A revision includes the latest complete draft and the requested change. The workflow does not send the entire saved collection or an unlimited chat history.

What it produces

The requested output is a structured recipe: ingredients, quantities, servings, steps and notes. This gives the app fields it can parse and validate instead of treating a free-form answer as a finished recipe. The current provider adapter uses Puter; keeping that adapter separate allows the provider to change without moving ownership of recipe state.

How the app handles the result

The companion parses the response, validates the recipe structure and presents a draft. The user reviews it, names the version and imports it deliberately. Recipe identity and version handling protect the original card; repeated imports of the same formulation should not create duplicate recipes.

Failures and limits

An invalid response or failed request retains the last valid draft. There is no automatic retry; stopping locally ignores late results but does not guarantee a provider request has stopped. Structural validation cannot prove that a dish tastes good, a substitution behaves correctly or dietary advice is appropriate. New recipes remain untested drafts until reviewed and tried. The web creator is published; recipe enrichment and evaluation of generated recipes remain ongoing work.

The model’s job

A local language-model integration interprets a football question and returns an intent, such as lineup, waiver, trade or scoring, plus referenced players. It receives a bounded roster context and the two most recent questions for follow-up references. It is instructed to interpret the request, not generate advice or execute tools.

Grounding the answer

The response must match a defined JSON structure. Allowed intents are enumerated, player references must exist in the supplied roster, and duplicate or unknown references are rejected. Application code then resolves the request against the available data. Lineup and roster comparisons are calculated separately from the language model.

Why data freshness matters

A successful roster refresh does not make a captured projection current. The app preserves the distinction between connected rosters, reviewed imports and missing evidence. A recommendation needs compatible scoring, eligible lineup slots and the relevant player information; fluent model output cannot supply a missing injury report or lineup-lock status.

Failure handling and limits

The local request has a timeout and response-size limit. Invalid structure or invented player references fail validation. The integration treats supplied text as untrusted input, but prompting alone is not a security guarantee—the constrained output and code checks matter. The app remains read-only, with no automated league transactions. Broader current-data coverage and the Android update are unfinished.

What runs today

Quick Apply uses explicit screening rules, duplicate checks and editable templates. Restriction flags point back to evidence in the posting, and drafts draw from recorded profile facts. This is workflow automation, not a model making an eligibility decision.

The analytical decision

Rules are useful when the question is specific: whether a posting mentions office attendance, whether a requisition is already saved, or which resume was used for a submitted application. Missing requirements remain review items. An application is only recorded as submitted when the user confirms that action.

What an AI extension would need

A future model-assisted drafting feature would need a bounded set of approved profile facts, traceable support for each claim and a review step before use. It would also need evaluation against unsupported credentials, ambiguous restrictions and instructions embedded in job descriptions. That is a design requirement, not a feature claimed as implemented.