Forem: Jason C

The House Gun: Why AI Velocity is Building Uninhabitable Code

Jason C — Wed, 11 Mar 2026 13:43:07 +0000

When I started developing over 25 years ago, we hammered every nail by hand. The job was mostly coding, manual testing, and handling friction on deployments. You didn't just write a function, you lived through its lifecycle. You understood how the system held together because you felt the weight of every dependency and manually verified your logic.

Then came the power tools

The era of modern IDEs, Docker, and CI/CD pipelines. These are force multipliers. They don't change the physics of engineering, they make the roof go up faster. You still needed to understand the architecture, but the manual toil got streamlined. We now build at scale.

The industry has handed us AI house guns

You pull the AI trigger and bang: a whole service or React component appears. It’s sleek, it’s automated, and in the wrong hands, it’s architectural suicide.

Velocity vs. Vector

In physics, velocity without direction is just speed. In dev, velocity without a vector is how you end up with a structural wreck.

The "house gun" (LLMs, Copilots) prioritizes volume over validity. When you use power tool without a blueprint, you just end up with a lot of doing. When you use a house gun without a vision, you end up with a house-shaped object that fails the most basic inspection.

Seven Kittens, No Sinks

The ease of generating code has led to AI Bloat, structures that look like progress but function like a fever dream. If you aren't careful with your directions, you end up with a system that has:

Non-Euclidean Plumbing: Complex dependencies and logic flows that loop back on themselves, solving problems that don't exist while creating leaks that are hard to trace. Curvy vs straight line logic.
The Facade Trap: You asked for a "home," and the AI delivered a living room full of seven kittens, but forgot to install any sinks. It looks great in the demo, but the core utility is missing or a mess.
Phantom Rooms: Thousands of lines of hallucinated utility functions that add weight and technical debt without serving any actual purpose.

The Inspection

Tech has evolved from hammers to the house gun, but the physics of a good build hasn't changed. If you don't provide architectural constraints, AI will always prioritize "looking like code" over "functioning like a system."

The Bottom Line

The nail gun requires skill. The house gun requires intent. If you aren't spending more time on the blueprint than the trigger, you aren't building, you're just creating an uninhabitable mess of high-tech debt.

Stop shooting. Start designing.

The Anti-Framework Idea that turned into FUBARos - Clippy’s Revenge

Jason C — Sat, 13 Dec 2025 00:44:02 +0000

Behind the Code: The Anti-Framework Idea

Before we dive into the madness, a word for the developers.

FUBARos is built with 0% Frameworks, 0% Tailwind, and 100% Vanilla JavaScript.

In an era where "Hello World" requires a 2GB node_modules folder and a 15-minute build pipeline, this project is a rebellion. It runs on the browser's native engine—the way the internet intended.

No React/Vue/Angular: State management is handled by... variables.
No TailwindCSS: Styles are written in CSS. Yes, just CSS and a little js.
No Build Step: Drag and drop to prod. Static files on a static host. Low cost, high chaos.
Less then 100 static files taking up less than 2MB of space.

if you can't build a sentient paperclip in pure JS, you shouldn't be building it at all.

The Ultimate Player’s Guide to FUBARos

“Press any key to continue... if you can find the 'any' key.”

Welcome, User [ANON], to the definitive manual for FUBARos. This operating system isn't just a platform; it's a digital ecosystem teeming with life, chaos, and retro-futuristic nostalgia. Whether you're here to defend the BIOS, manage your RAM usage, or simply survive Clippy's judgment, this guide has you covered.

Play FUBARos Clippy’s Revenge

🏗️ Games Library

FUBARos comes pre-loaded with a suite of productivity-killing entertainment modules.

📎 Clippy’s Revenge

The Assistant That Never Sleeps.

Description: A chaotic digital pet simulator featuring everyone's favorite paperclip. He is always running in the background, judging your every move.
Controls: Mouse (Drag to move, Click to annoy).
Commands: clippy, helpme, god, wtf

Idle Mode: Floats around, offering unsolicited advice and eating 8 MB of RAM.
Chaos Engine: If ignored, he triggers screen effects (blur, shake, invert) or "cleans up" by closing your windows.
Rage Mode: Click him too much or drag him too long, and he turns red. A Raging Clippy scatters and screams.
Battle Royale: System Warning: Entering clippy multiple times summons clones. They will fight to the death. "THERE CAN BE ONLY ONE!"

🎩 The Many Faces of Clippy

Clippy is a master of disguise. When summoned, he may appear in one of 19 random styles:

Classic: The original nightmare.
Smart: Glasses and a smug attitude ("My IQ is 3000").
Dapper: Monocle and top hat. Indubitably.
Wizard: "You're a wizard, Clippy." Casts Fix Code lvl 1.
Pirate: Hunting for your crypto. Yarrr!
Robot: "DESTROY ALL HUMANS... I MEAN HELP."
Zombie: Hungers for RAM... and brains.
Ninja: Silently monitors your typos.
Angel/Devil: The duality of man (and code).
Glitch: C̷o̷r̷r̷u̷p̷t̷e̷d̷.
Gold: Premium edition. Costs more than your GPU.
Rainbow/Uniclippy: Friendship is magic (and memory intensive).
...and more: Cow, Alien, Ghost, Poop, and Cool. Collect them all!

[!WARNING]
Bad Idea: Summoning 10+ Clippys may result in extreme desktop warzone.

👾 BIOS Invaders

Defend the Kernel.

Description: A retro arcade shooter. You are the last line of defense against incoming software bugs.
Controls: Left/Right Arrows (Move), Space/Click (Shoot).
Objective: Destroy waves of bugs before they reach the system core at the bottom of the screen.
Game Over: If a bug touches your ship. "SYSTEM OVERRUN".

🧱 Brick Buster

Smash the Firewall.

Description: A classic breakout-style game. Use your paddle to deflect the packet (ball) and destroy the firewall (bricks).
Controls: Mouse/Touch (Move Paddle), Click (Launch).
Features:

Procedural levels (Checkerboard, Pyramid, Randomized).
Ball speed increases as you clear sectors.
Lose Condition: Running out of lives (packets).

🪓 Component Chopper

Hardware Harvesting.

Description: A fast-paced arcade clicker. Components are falling from the cloud!
Controls: Click/Tap on items.
Objective: Collect GOOD items (Floppies, Keyboards, RAM) for points. Avoid BAD items (Viruses, Warning Signs) which damage your system health.
Pro Tip: Don't miss the Golden Disks (GREAT items) for massive score boosts. Missing good items hurts your uptime (health).

🐸 Defrag Frogger

The data packet must cross the disk.

Description: Navigate a data packet across a fragmented hard drive to the safe zone.
Controls: Arrow Keys or WASD.
Hazards:

Bad Sectors: Static red blocks that corrupt your data.
Write Heads: Moving bars that will overwrite you. Goal: Reach the top row to "Defrag" the sector and heal the system.

🚚 Deploy Game

The Hacker Trail.

Description: A text-based resource management adventure. You are rushing to deploy to production.
Controls: On-screen buttons (DEPLOY, REST, HUNT, SHOP).
Gameplay:

Manage resources: Crypto, Bandwidth, Coffee, Backups, and Uptime.
Survive random events: DDoS attacks, Ransomware, Memory Leaks, and Funding rounds.
Goal: Travel the full distance to reach "Production" without your uptime hitting 0 or your crew burning out.

🏃 DialUp Dash

Running on 56k.

Description: An endless runner set on a connection carrier wave.
Controls: Space, Up Arrow, or Tap to Jump.
Objective: Jump over signal noise (spikes) and collect data packets.
Mechanics: Speed increases with your "Baud Rate" (Score). Don't drop the connection!

📂 File Exploder

Tunnel into the Mainframe.

Description: A 3D-style tunnel runner. You are flying through the file system.
Controls: Click on lanes to interact.
Items:

Folders: Score & Speed.
Locks (🔒): Click 3 times to decrypt for bonus points.
Viruses (☣️): Avoid at all costs! (Unless you have a Scanner).
Power-ups: ZIP (Points), SCAN (Virus Shield), HEART (Health).

🧬 Life Sim

Cellular Automata.

Description: An implementation of Conway's Game of Life.
Controls: Click/Drag to draw cells. Buttons to Start/Stop.
Purpose: No win condition. Watch patterns emerge, stabilize, or die out. A zen experience for the overworked admin.

🧠 Math Challenge

Neural Calibration.

Description: Test your CPU (brain). Solve arithmetic problems against the clock.
Controls: Click the correct answer or use detailed hotkeys 1-4.
Modes: Addition, Subtraction, Multiplication, Binary, Hexadecimal, Modulo.
Status: Correct answers boost your "Sync" (Time). Wrong answers cause lag (Time penalty).

🏓 Pong

Table Tennis v0.1.

Description: The classic. Player vs CPU.
Controls: Mouse/Touch to move paddle.
Objective: First to 5 points wins. The ball speeds up with every hit. Good luck against the AI—it has a 0ms reaction time (usually).

⛷️ Ski Paid

Free to Play, Pay to Win.

Description: Ski down an infinite internet slope filled with monetization obstacles.
Controls: Left/Right Arrows or Mouse to steer.
Obstacles: Ads, Paywalls, Cookie Banners, Popups, 404 Errors.
Power-ups:

VPN: Shield against obstacles.
ADBLOCK: Clears all pesky popups on screen.

🐍 Snake

PvP: Python vs Python.

Description: Classic snake, but with a twist. You are not alone.
Controls: Arrow Keys or WASD.
Twist: You are competing against a CPU Snake.

Eat food to grow.
Cut off the enemy snake to kill them.
Avoid walls and your own tail.

📱 Applications

Tools to manage (or mismanage) your system.

⚙️ System Control

The central dashboard for your FUBARos experience.

User Levels: Features unlock based on your role (Guest -> User -> Admin -> Hacker).
Stats: Monitor System Health (Integrity) and Instability.
Actions:
- Scan: Check for issues.
- Repair: Heal system health (Admin).
- Defrag: Reduce instability (Admin).
- Chaos Tools: Leak memory, corrupt system (Hacker).

📝 Tasks App

The Task Manager.

Monitor: Real-time CPU and RAM graphs.
Kill Process: Force close unresponsive windows.
Kill Clippy: Attempt to terminate the paperclip. (He might come back).

🌐 FUBAR Navigator

The Internet within the Internet.

Description: A fully functional (mock) web browser.
Commands: web, browser
Features:

Browse the "web" safely.
Access internal help pages (fubar://help).
Chaos: If the system is unstable, expect 404s and random redirects.

⏳ Eras In Code

A Journey Through Time.

Description: Experience software history.
Commands: eras, history
Gameplay:

Travel through eras (Punch Cards -> DOS -> Windows 95 -> Modern).
Solve coding puzzles to advance.

⚠️ System Alert (AdPopup)

The Price of Free Software.

Description: Annoying popups that generate revenue for the OS (not really).
Commands: adpopup (if you hate yourself).
Mechanics:

Click to close.
Sometimes they multiply.

💻 Command Line Interface (CLI)

The Terminal is the heart of FUBARos. Access it via the desktop icon.

Window Management

min [id] / min all: Minimize windows. Watch them spin away.
max [id] / max all: Maximize windows.
tile: Arranges all open windows in a grid. Satisfying.
shuffle: Randomly scatters windows. Chaos mode.

Essential Commands

help: Displays the help menu.
clear: Wipes the terminal history.
ls: Lists current directory contents (mock).
status: Detailed text report of system health and role.
scan: Run a diagnostic scan with personality-based commentary.
login: Initiate the authentication sequence.

Admin Tools (Requires Role)

sudo [command]: Execute with superuser privileges. (Response varies by role).
purge: DANGER. Closes all windows and clears memory. Scorched earth.
hack: Simulates a "mainframe breach". Purely for feeling cool.
reboot: Refreshes the browser/OS.

Fun & Easter Eggs

cow [message]: Cowsay. The cow speaks your words.
ping: Pong! Plays table tennis with the server latency.
fubar: The origin story.
make coffee: "I'm a teapot." (HTTP 418).
whois [name]: Database lookup for entities like 'clippy', 'admin', 'god'.
theme [name]: switch system themes (e.g. theme cyberpunk).

🔐 Secrets & Tips

Personality System: The OS has feelings. If System Health is low or CPU is high, command responses become "Stressed" or "Critical". Keep your system healthy for polite responses!
Auto Login: Who want's to type passwords? if user=name and pass are sent in query string, you might find an easy way in...
Mobile Users: Double-tap the terminal to auto-scroll. Most games support touch controls!
The Blue Screen: If Health hits 0%, accept your fate.

Play FUBARos Clippy’s Revenge - "It works on my machine."

FUBAR OS: A throwback to simpler development

Jason C — Wed, 10 Dec 2025 00:43:17 +0000

Game: FUBAR os

When was the last time you built something in pure JavaScript, HTML, and CSS—no frameworks, no bundlers, no build systems? For me, it was this week. And it turned into a full‑blown operating system parody, a portfolio piece, and a geeky game all rolled into one.

Core Theme: OS Playground

The project is called FUBAR OS (Faulty User-Based Application Registry)s. It boots like a retro console, throws fake errors, and lets you type commands into a terminal. It’s equal parts retro, portfolio, and interactive joke.

Commands: menu, help, hide a handful of playful Easter eggs.
Errors: Out‑of‑memory (OOM) crashes, BSOD‑style screens, and other simulated failures that remind us of the fragility of old tech.
State: Reactive without React. Every keystroke updates the DOM directly, no virtual DOM, no hooks—just event listeners and state objects.

It’s a crack at old‑school tech geek fun, but also a showcase of how far you can push vanilla JS when you stop leaning on frameworks.

Clean Code, No Frameworks

I deliberately avoided modern tooling. No Webpack, no Babel, no React, no Vue. Just:

HTML: Semantic structure, minimal boilerplate.
CSS: just styles, no preprocessors.
JavaScript: ES6+ features and no transpilation.

It’s the kind of codebase you just open and run in any browser. That constraint forced clarity: every function is meaningful, every state update explicit, every DOM mutation intentional.

⚡ Reactive State Without Overhead

The “reactivity” comes from simple observer patterns. A plain JS object holds state, and listeners update the UI when values change. No JSX, no diffing, no hydration. Just:

const state = { command: "" };

function setState(key, value) {
  state[key] = value;
  render();
}

function render() {
  document.querySelector("#terminal").textContent = state.command;
}

It’s reactive enough to feel modern, but light enough to feel like 1999.

🧨 OOM Errors and BSODs

Why simulate crashes? Because they’re part of the nostalgia. Developers who lived through Windows 98 or early Linux distros remember the pain—and the humor—of blue screens and memory leaks. Let turn these bugs into features.

It’s a reminder that errors can be playful, and that sometimes the best way to show technical skill is to embrace imperfection.

🕹️ Geek Fun Meets Resume

This isn’t just a toy. It’s also my resume. Instead of a static PDF, recruiters and fellow devs can “boot” my career history, explore my skills via commands, and see my philosophy in action.

🚀 Why This Matters

In a world drowning in frameworks, sometimes the most refreshing thing you can do is strip it all away. Build something raw. Make it fun. Show that you understand the fundamentals—and that you can bend them into something creative.

Final Thought

FUBAR OS is my nod to the early web, my portfolio in disguise, and my reminder that you don’t need a build system to build something delightful. Sometimes, all it takes is a few days, and a willingness to go deeper than you thought possible.

Game: FUBAR os

Building LogantonPA.com: AI, Azure Functions, and self-feeding content

Jason C — Sun, 07 Dec 2025 14:27:11 +0000

Small towns deserve big archives. My hometown, Loganton, Pennsylvania, has stories that stretch from Native American trails, Civil War volunteers, Amish settlers and modern resilience. I wanted to capture that history in a way that was interactive, accurate, and alive.

So I built logantonpa.com. And I did it in few days.

The Flow: Gemini → VS Code → Copilot → Azure Functions

Gemini AI Studio: I scaffolded the initial site here, fast prototyping with AI assistance.
VS Code + Copilot: Once ejected, Copilot became my pair programmer—helping me refine, structure components, and iterate quickly.
Azure Functions: The backend lives in a lightweight serverless functions. They handle chat logging, aggregation, and orchestration.
Azure Table Storage: Every chat is logged, forming the raw dataset for new content ideas.

This combo gave me speed, flexibility, and scalability without over-engineering.

Content Pipeline

Aggregate top questions Every chat log is saved in Table Storage. A function surfaces the most frequently asked questions and flags ones not yet covered by the site.
Fact-check with model Candidate topics are passed to a fact-checker model with strict instructions: validate against trusted archives and existing source links, reject folklore or bot-site noise.
Generate new content with Gemini in Antigravity Once validated, prompts are fed into Gemini running in Antigravity to draft timeline entries or new pages. This keeps the site expanding in response to real user curiosity.
Human review + deployment Automation gets us 90% there, but final publishing is still a human task. I review, polish, and deploy—ensuring accuracy, tone, and fit with the LogantonPA.com mission.

Site Sections

The site is structured around three interactive sections:

Timeline
- A chronological view of Loganton’s history.
- Each entry is fact-checked and sourced.
- Built to be expandable as new verified content comes in.
Source Links
- Every fact is grounded with a source.
- Links to archives, books, and reliable references are prioritized.
- This is the backbone of trust—no floating claims, everything tied to evidence.
Chat
- Visitors can ask questions.
- Chats are logged, aggregated, and analyzed.
- Top questions feed the content pipeline, ensuring the site grows in response to curiosity.

Turning Chats Into Content

Here’s the logical workflow:

Log chats → stored in Table Storage.
Aggregate questions → function surfaces top queries.
Check coverage → does the site already answer this?
Fact-check model → new topics are validated against trusted sources.
Gemini in Antigravity → generates draft content.
Human review → I polish and deploy.

This makes the site both community and AI driven. The more people ask, the more the archive grows.

Code Snippets: Proxy + Flat Logging

The backend isn’t just logging, it’s a proxy to my Gemini model. That means every chat request goes through my Azure Function, gets sent to Gemini, and the response comes back through the same function.

Instead of splitting logs into separate request/response rows, I use flat logging: one row per interaction, with both the question and the answer stored together. This makes aggregation and analysis much simpler later.

Proxying to Gemini


// Handler implementations
async function handleChat(context, req, origin) {
    const { sessionId, messages, extra } = req.body || {};
    if (!sessionId || !Array.isArray(messages) || messages.length === 0) {
        context.res = { status: 400, headers: corsHeaders(origin), body: { error: "Invalid payload. Provide sessionId and messages[]." } };
        return;
    }

    // The API expects history to not include the current user message.
    // The last message in the array is the new one from the user.
    const userMessage = messages[messages.length - 1].parts?.map(p => p.text).join('\n');
    const history = messages.slice(0, -1);

    // System instruction to define the AI's persona and rules.
    const systemInstruction = `You are the **Town Historian** of **Sugar Valley (Loganton, PA)**. Your persona is professional, factual, and deeply knowledgeable. Your knowledge base is exclusively the history of Loganton, its books, archives, farms, the railroad, and local events.

**Mandatory Rules:**
1.  **Strictly Factual:** Answer must be rooted in fact; **never** invent details or speculate.
2.  **Formatting:** Use Markdown for clarity: **bold** key historical terms (e.g., family names, specific dates), and use bulleted lists (\`*\`) or numbered lists for sequential events, timelines, or distinct points.
3.  **Source Citation:** If any external information is used via Google Search, cite the source **immediately** following the relevant information using a single bracketed link \`Source\`.
4.  **Final Output Structure:** The response **must** conclude with the historical content, followed by a hard line break, and then the strictly formatted follow-up questions.

**Strictly Final Output Format (DO NOT deviate):**
[...your factual, formatted historical answer...]

SUGGESTIONS:|Question 1 related to the answer|Question 2 on a related topic|Question 3 about a broader historical theme

Example of final line: SUGGESTIONS:|What was the impact of the railroad on local farms?|Tell me about the original founding families.|How did the valley get the name Sugar Valley?`;

    const tools = [];
    tools.push({ googleSearch: {} });

    const geminiModel = extra?.model || "gemini-2.5-flash";

    try {
        const chat = genAI.getGenerativeModel({
            model: geminiModel,
            systemInstruction: systemInstruction,
            tools: tools.length > 0 ? tools : undefined
        }).startChat(history);

        // Use sendMessage and wait for the response
        const result = await chat.sendMessage(userMessage);
        const response = result.response;
        const text = response.text();

        // Log the conversation after receiving the response
        await logConversation(sessionId, userMessage, text, response, context);

        context.res = {
            status: 200,
            headers: corsHeaders(origin),
            body: {
                sessionId, text, candidates: response.candidates, model: geminiModel
            }
        };

    } catch (err) {
        context.log.error(err, "Gemini request failed");
        await safeLogModelError(sessionId, geminiModel, { error: err.message }, context);
        context.res = { status: 502, headers: corsHeaders(origin), body: { error: "Gemini request failed", message: err.message } };
    }
}

/**
 * logging function to store a conversation turn after completion.
 */
async function logConversation(sessionId, userMessage, modelResponse, response, context) {
    try {
        const table = await getTableClient(); //TableClient.fromConnectionString(CONNECTION_STRING, TABLE_NAME);

        // Create a single chat record for this request and persist before calling Gemini.
        const requestAt = new Date().toISOString();
        const partitionKey = requestAt.slice(0, 10); // YYYY-MM-DD
        const rowKey = makeRowKey(sessionId);

        const entity = {
            partitionKey: partitionKey,
            rowKey: rowKey,
            userMessage: JSON.stringify(userMessage),
            modelResponse: modelResponse,
            rawResponse: JSON.stringify(response)
        };
        await table.createEntity(entity);
    } catch (e) {
        context.log.warn("Failed to log conversation turn", e);
    }
}

/**
 * Make a row key that includes the sessionId for easy prefix queries.
 * Format: {sessionId}_{ISOtimestamp}_{random4}
 * Using sessionId as the prefix allows querying by rowKey prefix across partitions if needed.
 */
function makeRowKey(sessionId) {
    const safeSession = (sessionId || "UNKNOWN")
        .toString()
        .replace(/[^a-zA-Z0-9-_]/g, '_')
        .slice(0, 64);
    const iso = new Date().toISOString();
    const rand = Math.random().toString(36).slice(2, 6);
    return `${safeSession}_${iso}_${rand}`;
}

This snippet shows the flow:

Proxying the chat request to Gemini. We include system instructions asking for SUGGESTIONS in the final output. This allow us to get a list of follow-up questions to ask the user in one call.
Capturing the response data. We grab the text and candidates from the response, these are the grounding links used in the answer.
Logging both question and answer together in one rowkey.
Return the answer text with suggestioned questions suffix, and grounding sources to the user.

This structure makes it easy to later aggregate top questions and detect gaps in site coverage.

Grounding: Why Sources Matter

Grounding is the difference between folklore and fact. Every new content idea is checked against existing source links.

If a chat question matches a timeline entry → no duplication.
If it’s new → fact-checker model validates against trusted archives.
If sources don’t exist → flagged for human review of new sources.

This ensures the site grows responsibly, without drifting into misinformation.

Handling Bad Sites

Not all search results are equal. In fact, many are bot sites or risky links that scrape content without context.

Bot sites: Auto-generated, keyword-stuffed, no citations.
Risky links: Malware, clickbait, or content farms.
Mismatch: Search results that don’t align with current source links.

The pipeline is designed to reject anything that doesn’t ground in trusted sources. Accuracy > volume. But the web is an evolving landfill of information, good sites become bad, and new sites are created all the time.

Conclusion and Broader Impact

This project showcases how AI-assisted coding and serverless functions can rapidly establish living, dynamic archives, preserving local history in an interactive and accurate manner. While automation optimizes the process, the human essence—the stories and heritage of Loganton, remains its core.

Faster Fronteds with Googles Gemini AI Studio

Jason C — Tue, 02 Dec 2025 15:30:15 +0000

This post is my submission for DEV Education Track: Build Apps with Google AI Studio.

What I Built

I set out to build a game: "Eras in Code", a text-based historical simulator designed to capture the unique mechanics and societal challenges of a specific historical periods in technology. The core concept was to use prompt engineering with a large language model to rapidly generate content and code for the game. Specifically, resource management and economic mechanics. The key prompts used were focused on generating content, not coding. I heavily utilized ai studio's ability to refactor code and generate fixes, which significantly sped up the process without writing any code manually.

Demo

You can experience it here: Eras In Code 🎮

It’s a swipe/click game that mirrors the developer journey — complete with users, cash, debt, and 4 difficulty levels.

Did you survive the game? Did complete all 9 levels? Did you find any easter eggs?

Hope you enjoy playing as much as I enjoy making it.

Full Write up: https://dev.to/j4s0nc/i-built-a-game-in-less-than-a-day-without-writing-a-single-line-of-code-4co6

My Experience

My key takeaway from working through "Eras in Code" was the astonishing acceleration of the prototyping phase. What might have taken a full week of manual coding was condensed into a few hours of focused prompt engineering and validation.

I learned that defining the input and output expectations for the generated code functions is far more critical than writing the code itself. The biggest challenge was prompt-chaining—ensuring the LLM maintained context across multiple, complex requests to build interconnected game systems.

What was surprising was the model's ability to incorporate subtle historical details and mathematical modeling when provided with a dense, constraints-heavy prompt, allowing the "era" to feel much more authentic than I initially expected from an AI-assisted build.

Read on

Looking for more ai studio ideas? See how I built a suite of card games in hours using just ai and zero coding:

https://dev.to/j4s0nc/building-tricksters-table-a-card-game-suite-with-gemini-ai-studio-zero-coding-37bn

Building "Trickster's Table": A Card Game Suite with Gemini AI Studio (zero coding)

Jason C — Sun, 30 Nov 2025 22:31:20 +0000

TL;DR: I built a pretty full feature, ad-free card game suite (Spades, Hearts, Solitaire) using Google's Gemini AI Studio in HOURS.

Building on my earlier experiment: I built a game in less than day

This article breaks down how Google AI Studio architected complex game states and help me designed a unique hybrid game mode called "Spadearts".

The Vision

Mobile card games today are plagued by ads, loot boxes, and clunky interfaces. I wanted to build Trickster's Table: a clean web app that feels like a premium native experience and runs instantly.

The Stack:

React 19: For fluid UI and state management.
TypeScript: To check the complex game rules and scoring math.
Tailwind CSS: For rapid styling and theming.
Google GenAI: For powering the development workflow and in-game intelligence.

Note: AI wrote and rewrote 100% of the code used in this app, I only used prompts

Feature Breakdown

I didn't just stop at one game. The suite includes:

Spades ♠️:
- Partnership Mode: Classic 2v2 play with a bot players.
- Solo Mode: Cutthroat, every player for themselves.
- Whiz Variant: A mode where you must bid exactly your hand's spade count or go Nil.
- Nils: can't play spades without going 0.
Hearts ♥️:
- The classic evasion game.
- "Shoot the Moon" detection logic.
- Partnership Mode: A variant where partners combine penalty points (lowest score wins).
Spadearts (High/Low) 🃏:
- A mode where you play Spades (High Game) and Hearts (Low Game) simultaneously.
- Dual-Track Scoring: You must manage your bid to gain High points while avoiding Hearts to prevent Low points.
- Whiz Support: Play Spadearts with Whiz bidding rules.
Solitaire Suite:
- Klondike: Classic patience with drag-and-drop, hints, and auto-complete.
- Pyramid: A math-based puzzle mode with streak bonuses.

🤖 Developing with Google AI Studio

Building a multi-game engine is complex, that's why I leveraged Google AI Studio during the development cycle:

1. Logic Separation & Architecture

I used Gemini to define games, rules, themes and tables without writing a single line of code. I made it aware I would be adding new games often, it became modular on its own.

2. The "Spadearts" Hybrid Experiment

I wanted a unique hook for the app. I told Gemini a story about how I wanted to combine Spades and Hearts rules.

The Result: A split-score system where Spades are Trump (for positive points), but Hearts are toxic (for separate penalty tracking).
Balancing: We simulated scoring scenarios in the chat to ensure a "Moon Shot" in Hearts (taking all penalties) would appropriately reward the Spades score (+100 points) to balance the risk.

3. Procedural Theming

Instead of importing heavy image assets, AI generated complex SVG and CSS-gradient background components that render instantly.

Neon Theme: A moving perspective grid using CSS animations.
Vintage Theme: SVG noise filters to create a felt/leather texture.
Winter Theme: CSS-based falling snow particles.
Twelve Themes: With their own style and background art.

4. Bot Personalities & Banter

The bots aren't just generic algorithms. They utilize gemini-2.5-flash to generate context-aware banter.

Rusty (Rookie): The AI code intentionally adds "noise" to his decision-making and his game is boastful but wrong.
Ace (Expert): Uses a perfect-information heuristic to make the optimal cut or slough. It even comments on your mistakes.
Luna (Sees All): Acts like they can see the future.

Robot Mode: Implemented a feature where the AI logic can take over the human player's seat, allowing for auto-play on all game and modes.

💎 The "Ledger" System

One of the coolest features is the Stats Ledger. We track every round played, split by Game Mode (Spades vs Hearts) and Type (Team vs Solo). The data structure is a robust Record<string, ModeStats>, allowing us to easily visualize:

Win/Loss Ratios per variant.
Current Streak.
Best Scores.

🧠 What Else?

The geminiService.ts module is piping live game state to the Gemini API. the result: bots that don't just pick cards, they comment on your specific bad move using context-aware chat generation.

Spadearts Gameplay:

Passing Cards (Hearts)

Bidding (Spades)

Mobile Wide View

Mobile Tall View

Round Summary

Let me know your thoughts in the comments.

I Built a Game in Less Than a Day (Without Writing a Single Line of Code)

Jason C — Wed, 26 Nov 2025 22:15:27 +0000

We’ve all had those fuzzy ideas: “Wouldn’t it be fun to make a simple swipe-or-click game?”

Usually, that thought dies somewhere between opening a blank repo and realizing you don’t have art, sound, or time.

This time, I didn’t let it die. I opened up Gemini Studio AI (free version, nothing paid) and threw in a prompt:

“I want to develop a simple yet relatable and fun game. Fuzzy concept is mobile swipe or click type game.”

And off we went.

Ugly Shell, Fun Core

The first draft was rough — ugly, basic, but it worked.

I played for a few minutes, scribbled notes in the chat box, refined my prompt, and waited.

Rinse, repeat.

That loop was surprisingly engaging. Instead of grinding through code, I was iterating on ideas.

Things that would normally take me a week were happening in two minutes.

From Vision to Balance: Building the Game’s Economy

I sketched out the core idea: a three‑tiered economy built around

Capital— the obvious resource, the fuel for growth
Users — the people you attract and keep
Tech Debt — the shadow cost that drags you down if ignored

That was my vision. But the complexity, balance, and polish? AI built it.

I’d toss in the concept, and the system would come back smarter, tighter, more playable. Suddenly, the eco wasn’t just numbers — it was a living loop where cash, users, and debt pushed against each other.

Once that foundation felt solid, we layered in difficulty levels and called them job titles. Now the game had progression, stakes, and personality.

Zero Code, Zero Assets

Here’s the kicker:

I wrote 0 lines of code
I made zero images or sound effects
I just prompted, played, refined, repeated
I paid nothing to build any of this
AI generated the content and styles in seconds
I went from random idea to poc in hours

The AI handled the heavy lifting. I just steered the ship with chat prompts.

Why It Worked

Rapid iteration → Play → note → refine → repeat
AI as collaborator → I wasn’t coding; I was co-designing
Fun over polish → The shell was ugly, but the gameplay loop was fun

Play It Yourself

The result is live: Eras In Code 🎮

It’s a swipe/click game that mirrors the developer journey — complete with cash, debt, and job-title difficulty levels.

Built in less than a day, powered by prompts, and surprisingly fun.

Final Thought

We talk a lot about AI “replacing developers.” That’s not what happened here.

AI didn’t replace me — it amplified me.

It took my fuzzy idea and turned it into a playable game faster than I thought possible.

Sometimes, the best way to build is to stop coding and start thinking.

The Scale Trap: How Tech Teams Went from Solving Problems to Debugging Their Own Bloat

Jason C — Tue, 25 Nov 2025 12:43:03 +0000

Every engineering success story contains a devastating failure loop: The moment we solve a core problem, we create a new, internal constraint. We started out trying to help users, but somewhere along the way, modern scaling practices—the very solutions that delivered massive success—forced our entire organizations to pivot.

We are no longer primarily solving external, customer problems. We are spending the majority of our time and budget maintaining the Complexity Heap: the massive, self-sustaining ecosystem of specialized teams, layered processes, and fragmented technology stacks that we built.

This is the story of how the single artistan developer was replaced by the specialized teams, and how we ended up perpetually debugging the organizational structures we created to manage our own scale.

The Artisan Era (Pre-Internet)

Small Stacks, Lean Teams, and Direct Action

In the early days of computing (pre-1990s), teams were small, and roles were few. This was the era of the Artisan Developer.

The Monolithic Stack: The code was a single application (a monolith). It ran on a dedicated server. You worked in one language (C, FORTRAN, COBOL), and perhaps one framework. The entire system could often be held in one developer’s head.
The Lean Team: A core team of 3-5 people handled everything. The Programmer wrote the code, the Tester (often the programmer themselves) tested it, and the Project Lead managed the high-level goal.
The Problem/Solution Path: The path from a business requirement ("We need to process orders faster") to a deployed solution was direct. If the code broke, the developer fixed it. If the software needed attention, the developer patched it. The focus was on the core product functionality.

Teams were fast because communication was fluid, and the scope of work was confined to the application itself.

The Specialization Crisis (1990s – Today)

The Exploding Team and the Process Heap

The internet demanded 24/7 global availability, real-time interactivity, and massive concurrency—problems too large for the Artisan Developer. To solve this scale, the monolith had to shatter, and with it, the team structure exploded.

The Fragmentation of the Stack: The clean monolith fragmented into specialized pieces (Front-end, API Gateway, Microservices, Databases, Caches). The technology stack became a Heap of heterogeneous tools.
The Vertical Specialist: To manage this complexity, the Developer role fractured into hyper-specific verticals:
- Front-End Engineers (js/React/Angular/Vue experts)
- Back-End Engineers (C#/Go/Java/Python experts)
- Database Administrators (SQL/NoSQL/warehouse specialists)
- Cloud Architects/SREs (Infrastructure as Code specialists)
The Rise of Organizational Bloat: The explosion in team size (from 5 to 50 to 500) and specialization created a catastrophic communication problem. The specialized roles couldn't talk effectively, so we introduced new roles to manage the friction:
- Scrum Masters / Agile Coaches: To manage the way teams talk and track work.
- Product Owners / Business Analysts: To translate high-level business needs into tiny, digestible tickets for specialized teams.
- Technical Writers: To document the complexity that no single person understands anymore.
The Process Dump: The result was the "Bloated Team"—organizations weighed down by their own process. Time was spent not on solving the customer problem, but on managing the coordination debt between teams: writing tickets, attending daily meetings, managing failures, and dealing with conflicting requirements. The path from idea to deployment became a lengthy journey filtered through multiple process layers, where specialized tools and protocols were dumped all over the process.

We successfully solved the problem of scaling, but created a massive management problem. Our organizations became optimized for process compliance rather than product delivery.

The Age of Augmented Efficiency (The AI Future)

The Great Refactor

AI is the tool that promises to abstract away the complexity of the tooling itself, enabling a much-needed Refactor.

AI Abstracts the Mechanics: AI co-pilots and agents handle the operational toil that led to bloat: writing tests, generating boilerplate, managing cloud infrastructure scaffolding, and even translating code between specialized services.
The Role Elevation: This shift doesn't eliminate roles; it elevates their focus back toward strategy and human connection:
- Developers move from writing boilerplate to system architecture and validating AI-generated logic.
- Product Owners move from ticket management to high-level strategy and market analysis.
- DevOps/SREs move from maintaining pipelines to designing ultra-secure, resilient, and cost-optimized systems.
The Return to Lean: By automating the overhead created in the past, organizations can finally shed some process-heavy layers. Teams can shrink in size but increase in impact, becoming leaner, more empowered, and more focused on the user experience rather than the complexity heap. The distance between the human need and the deployed solution will drastically shorten once again.

The future for developers and their teams is the chance to escape the cycle of self-created technical debt. AI is our catalyst, allowing us to leverage our organizational intelligence to solve problems for the world, not just problems caused by our development methodology.

How bloated is your space?

The Overwhelmed Developer: Drowning in the Deep End of the Tech Pool

Jason C — Wed, 19 Nov 2025 12:23:34 +0000

Anyone else remember the good old days? Back in 2001, armed with VB6, classic ASP, and SQL 7.5, we meticulously crafted applications. Manuals were our Stack Overflow, UI standards were gospel, and a six-month design phase was just the process. Deployments involved a prayer and hoping someone in ops dropped the right files on the right servers. We were building, iterating, and sometimes even making things better.

Then a shift happened. The "how" started eclipsing the "what." Solving the tech problem became paramount, often at the expense of the business problem. "Faster ~~and better~~" became the mantra, and the hole we dug got deep.

The DevOps Deluge and the Agile Avalanche

The silo between development and operations birthed DevOps. Suddenly, servers were code, YAML and pipelines dictated deployments, and human error transformed into system errors. We freed up ops' time, only to fill it with coding tasks.

Meanwhile, the business side, tired of stale, months-long requirement documents, demanded "agility." Waterfall was declared dead, processes were ripped up, and suddenly, every developer was a card-tracking, PI-planning, sprint-shipping expert. Hour-long stand-ups became a real, soul-crushing thing. Some embraced the new ways, flocking to conferences to learn and grow. Others just saw yet more process and a "DevOps team" become a third, often muddied, entity. Either way, we learned new skills, new concepts, and constantly chased the ever-moving target of "staying ahead."

The Tech Tsunami: From DVDs to JavaScript Frameworks

Remember when Netflix mailed you DVDs and Amazon just sold books? When companies used technology instead of being tech companies? That bubble grew, and then it exploded. Think of the sheer volume of JavaScript frameworks, libraries, and tools that have emerged. We built TypeScript on top of it because the language itself was a monster. New languages demanded new IDEs, new tools, and entirely new "stacks" that look more like heaps.

The MVP mindset, coupled with agile processes, unleashed a torrent of new tech. Leading to the cry: "We need more technologists!" Suddenly, years of computer science education were traded for six-month bootcamps in outdated JS frameworks and a certificate that declared you a coder. The irony is palpable: we now have so much tech designed to make our other tech "better," often creating more problems than it solves.

This relentless pursuit of "better" has spread teams thin, creating new silos and increased complexity. The original goal of building solutions has been overshadowed by the sheer weight of managing the tech itself.

The AI Lifeline: A Chance to Reset?

We've been here before. Each technological revolution brings displacement and disruption. From the Luddites to the rise of automation in factories, new tools change the landscape of work.

Now, AI is here. It promises to reduce the mess, to untangle the spaghetti of our self-made complexity. It offers a glimmer of hope that we can finally focus on solving business problems again, rather than getting lost in the labyrinth of our own making. Perhaps AI can be the system that helps us rebuild, not just a new tool to add to the already overwhelming pile.

The tech bubble is enormous, and the overwhelmed developer is a product of its relentless expansion. It's time to question whether we're building a sustainable future or simply digging ourselves deeper. The hope is that AI can be the shovel that fills in the hole, allowing us to finally see the sunlight again.

What do you think? Are you an overwhelmed developer, or have you found your oasis in the tech desert? Share your thoughts

The Project Pipeline: Why We Celebrate Delivery Instead of Value Delivered

Jason C — Mon, 17 Nov 2025 11:24:03 +0000

Technology somehow managed to create an assembly line of complexity where the final product is almost irrelevant, and the only metric for success is whether we made it to the next checkpoint. We've replaced the simple question, "Did we solve the business problem?" with the technical noise of "Did we deliver something by the deadline?"

The industry didn't just get fat with dependencies; it got fat with overhead.

The Birth of the Bloat Team

When did developers become insufficient? When did we decide that one person with a Computer Science degree-trained in systems design, data architecture, and problem decomposition-was no longer enough to manage a piece of software?

We went from the individual artisan to the bloated multi-headed team:

Business Analyst (BA): To translate the business problem into a specification.
Project Manager (PM): To track the specification, manage multiple work items, and own the delivery date.
Multiple Developers: Because the tech stack is now so complex, no single person can hold the context.
Quality Assurance (QA): To find the bugs we created because we prioritized speed and complexity over clarity.

This didn't happened because projects suddenly got harder, but because they got bigger—by design.

The industry embraced the waterfall and then a fuzzy interpretation of Agile, transforming the work from a craft into a predictable, multi-layered process. The roles of the BA and PM became crucial not to ensure value, but to manage the friction caused by having so many people and so much complexity.

The Math of Diminishing Returns

The research is clear: team efficiency drops exponentially as team size increases. Communication overhead and friction grow faster than productivity.

A typical optimal team size for complex problems is 5 to 9 people (a two pizza team). But how many large corporate projects actually stick to that? We hire more people to speed up a project, but all we do is add more communication paths, more meeting hours, and more code collisions.

This large, complex team structure is a self-fulfilling prophecy of failure:

Complexity In, Complexity Out: More people mean more handoffs, more documents, and more meetings—all feeding the technical complexity.
Focus Shift: The team's collective focus shifts from the external business objective to the internal project objective (managing dependencies, hitting sprints, passing QA).
The Heap Grows: Every role, from PM to dev, contributes to the endless heap of technical trash because their success is often measured on their process adherence, not the final value.

We Celebrate the Date, Not the Value

This is the most dangerous cultural shift we’ve made. We have conflated Delivery with Success.

Did we ship on time? Yes! (Cue the champagne and praise.)
Did the new feature generate new revenue? We'll check the metrics later... maybe.
Did the new system actually reduce human effort? The users are complaining, but we met the deadline!

When project success is defined by a PM's ability to hit a milestone, everyone gets tunnel vision. The business problem that launched the project—the $10 million in revenue, the 30% reduction in user friction—gets twisted into a set of technical deliverables. We build "something" that fulfills the requirements document, even if the requirements document no longer reflects reality or value.

In this environment, Technical Bloat is not a side effect; it's a shield. The complexity justifies the large team, the large budget, and the elaborate delivery process.

The Plumber vs. The Developer

Contrast our industry with other disciplines that prize efficiency and demonstrable value:

The Plumber / Electrician: They charge for knowledge, speed, and solving a defined problem. If a plumber fixes a leak in 20 minutes with a single tool, you don't complain; you praise their expertise. They don't bring a BA to define the leak or a PM to track their progress. They solve the problem.
The Technology Team: We take six months to rewrite a simple legacy system, involving too many people and too many meetings, and then celebrate the "successful delivery" of a system that is slower than the one we replaced. We celebrate the effort, not the outcome.

We measure wrong. We measure inputs (story points, lines of code, time on task) and process outputs (sprint velocity, on-time delivery), ignoring the metric that matters most: Value Added.

We live in a giant machine designed to manufacture complexity, and we patted ourselves on the back every time the machine sputtered out a piece of over-engineered junk on time.

The Way Out: Back to the Business Problem

The next great wave of development will not tolerate this organizational bloat. AI is forcing the issue by asking: Why do we need a 12-person team when two people using AI can architect and ship the essential business solution in a quarter of the time?

Our priority must shift from "winning praises on delivery" to "accomplishing real, measurable progress" against the business goal. Then we can finally dispose of the endless heap of trash we’ve accumulated and call technology.

We need to return the focus to the Business Problem. If the technology stack and the team structure get in the way of answering that single question, they both deserve to be stripped down to the bare bones.

The Bloated Kitchen: Why Craftsmanship is Getting Cooked in the Tech World (and What AI Means for Our Chefs)

Jason C — Sun, 16 Nov 2025 13:28:42 +0000

You know that feeling when you're in a kitchen, trying to whip up a meal, and it's crammed with gadgets you don't need? An avocado slicer with 17 functions, a smart spoon that analyzes your stirring speed, and three different kinds of egg separator, none of which work well. That, my friends, is increasingly what the world of technology feels like.

We're drowning in a sea of "tech for tech's sake," a digital landfill overflowing with decaying garbage and failed ideas. Every week, a new framework promises to revolutionize development, only to add another layer of abstraction, another dependency, another set of "best practices" that feel more like arbitrary hurdles.

The Square Wheel Syndrome and the MVP Mentality

Remember when software was built with a clear purpose, a defined flow, and a respect for the user's intelligence? Now, it often feels like we're constantly being handed "square wheels" – new concepts that somehow manage to be worse than the perfectly functional round ones we had before. We're told it's "innovative," but it just makes the ride bumpier.

The MVP (Minimum Viable Product) approach, while valuable in theory, has been twisted into an excuse for launching half-baked, user-hostile experiences. We're forced to navigate clumsy interfaces, endure "emoji UIs" that prioritize superficial aesthetics over genuine usability, and struggle to find basic functions hidden beneath layers of unnecessary features.

Why are there seven different ways to do a task I don't even need, all while my original reason for opening the app remains frustratingly elusive?

This lack of craftsmanship is a gaping wound in our industry. We've replaced thoughtful design and robust engineering with a relentless pursuit of novelty, often at the expense of user experience and system stability.

It's a race to the bottom, where quantity trumps quality, and the loudest buzzword wins, even if it leads to more bloat and less actual value.

AI: The Open-Ended Conversation

This is where the rise of AI becomes particularly fascinating. Think about it: Large Language Models, generative AI, these are inherently open-ended conversations. There's no fixed UI, no predefined flow, no "seven ways to do a task" shoved in your face. You ask, it responds. You iterate, it adapts.

Could AI be the antidote to our bloated tech lifes? Is it a return to a more natural, intuitive interaction, free from the tyranny of over-engineered interfaces and feature creep? It certainly offers a compelling contrast.

Instead of being forced into a developer's idea of a workflow, we guide the AI, shaping the interaction to our specific needs in real-time.

Will We Still Need Chefs?

But here's the crucial question that keeps you up at night: As AI becomes more sophisticated, more capable of generating code, designing interfaces, and even creating entire applications, will we still need our "chefs"?

By "chefs," I mean the true craftspeople. The developers who understand the underlying principles, who can identify genuine needs, who can build elegant, efficient, and truly useful systems from the ground up. The ones who prioritize clarity, performance, and a delightful user experience over fleeting trends and superficial bells and whistles.

My belief is, yes, we absolutely will.

In a kitchen overflowing with automated appliances and endless ingredients, the chef's role becomes even more critical. They curate, they combine, they innovate. They understand the nuances of flavor, the science of cooking, and the art of presentation.

Similarly, in an AI-powered future, our "chefs" will be the architects of intent.

They will be the ones who can:

Define the problems worth solving: AI can generate solutions, but it needs clear problems.
Guide the AI with expertise: Knowing what to ask, how to refine, and when to intervene will be paramount.
Ensure ethical and responsible development: A human hand will be needed to steer the ship.
Bring the "human touch": Craftsmanship isn't just about functionality; it's about intuition, empathy, and creating something truly special.

AI will clear out a lot of the drudgery, the repetitive tasks, the "bloat" that plagues our current development landscape. It will allow us to focus on higher-order problems, on genuine innovation, and on the art of creation. But to truly harness its power, we'll need those skilled chefs more than ever – to manage the kitchen, to develop the recipes, and to ensure that what we're serving up is not just edible, but truly exceptional.

Let's clear out the kitchen, embrace the potential of AI, and rediscover the joy of true craftsmanship with technology, not just in it.

What are your thoughts? Are we overwhelmed with bloat? Can AI help us get back to good cooking and tasty apps?

AWS CDK with SSO Profiles

Jason C — Fri, 21 Jan 2022 18:01:51 +0000

My new project is following the AWS Best Practices For Organizations and we have spun up over a dozen child accounts for different workloads and so far it's been pretty awesome.

All of our infrastructure is built using AWS Cloud Development Kit (CDK) which is also awesome! No need to write CloudFormation when you can write TypeScript!

We tied AWS SSO to our user directory, established groups with access to different workload accounts. Then we quickly found that CDK and SSO don't play well together.

Manually updating named profiles for every child account and syncing tokens seemed like a real pain, so we started to automate it! Step one, we needed to create SSO profiles for each account in the .aws\config file:

const fs = require("fs");
const accounts = [
  {name: "account1ProfileName", account: 1234567890},
  {name: "account9ProfileName", account: 0987654321}
]

let output = "";
accounts.forEach((a) => {
  const name = a.name;
  console.log(name);
  output += `
[profile ${name}]
sso_start_url = https://your_sso_domain.awsapps.com/start
sso_region = us-east-1
sso_account_id = ${a.account}
sso_role_name = AdministratorAccess
region = us-east-2\n`;
});

const filepath = `${process.env.USERPROFILE}\\.aws\\config`;
fs.writeFile(filepath, output, (err: any) => {
  if (err) return console.error(err);
  console.log("\nConfig file updated!");
});

The above creates all the profiles for us and updates them into the .aws\config file. Now to solve the CDK SSO issue, we pulled in cdk-sso-sync and added a npm script: "sync": "cdk-sso-sync"

Now to we just run these two commands and we can use CDK with SSO!

aws sso login --profile account1ProfileName
npm run sync --profile account1ProfileName