AI-assisted coding Archives - Everyday Software, Everyday Joyhttps://business-service.2software.net/tag/ai-assisted-coding/Software That Makes Life FunWed, 06 May 2026 11:34:07 +0000en-UShourly1https://wordpress.org/?v=6.8.3I Crafted A Wordle-Inspired Historical Figure Game With The Help Of AIhttps://business-service.2software.net/i-crafted-a-wordle-inspired-historical-figure-game-with-the-help-of-ai/https://business-service.2software.net/i-crafted-a-wordle-inspired-historical-figure-game-with-the-help-of-ai/#respondWed, 06 May 2026 11:34:07 +0000https://business-service.2software.net/?p=17485What happens when Wordle-style guessing meets world history and AI-assisted coding? You get a clever historical figure game that transforms famous names into a daily puzzle of clues, categories, and discovery. This article explores the design process, AI workflow, educational value, database challenges, and personal experience behind crafting a game that makes history feel playful, memorable, and surprisingly addictive.

The post I Crafted A Wordle-Inspired Historical Figure Game With The Help Of AI appeared first on Everyday Software, Everyday Joy.

]]>
.ap-toc{border:1px solid #e5e5e5;border-radius:8px;margin:14px 0;}.ap-toc summary{cursor:pointer;padding:12px;font-weight:700;list-style:none;}.ap-toc summary::-webkit-details-marker{display:none;}.ap-toc .ap-toc-body{padding:0 12px 12px 12px;}.ap-toc .ap-toc-toggle{font-weight:400;font-size:90%;opacity:.8;margin-left:6px;}.ap-toc .ap-toc-hide{display:none;}.ap-toc[open] .ap-toc-show{display:none;}.ap-toc[open] .ap-toc-hide{display:inline;}
Table of Contents >> Show >> Hide

Some people wake up and choose coffee. Some choose chaos. I chose to build a Wordle-inspired historical figure game with the help of AI, because apparently my brain looked at centuries of world history and said, “You know what this needs? Tiles.”

The idea sounded simple at first: create a daily guessing game where players identify a historical figure using clues, categories, and deduction. Instead of guessing a five-letter word, players would guess a person from history. The game would reward curiosity, historical reasoning, and that oddly satisfying feeling of being wrong in a productive way. You know, education.

But the deeper I went, the more I realized this was not just a fun coding project. It was a mini-laboratory for game design, AI-assisted development, historical research, user experience, and the eternal question every creator faces: “Why is this button floating in the corner like it pays rent?”

Why A Wordle-Inspired History Game Made Sense

Wordle became famous because it respected players’ time. Six guesses. One puzzle. A clear feedback loop. No 47 pop-ups asking you to buy a wizard hat. That clean structure made it perfect inspiration for a learning game about historical figures.

History, meanwhile, is full of people who are remembered as names in textbooks but were actually complicated, dramatic, brilliant, flawed, and occasionally messier than a group chat during finals week. A historical figure game could make those names feel alive again by turning recognition into discovery.

The concept was simple: the player guesses a historical figure, and the game gives structured feedback. Was the figure from the same century? Same region? Same field? Similar political role, scientific contribution, artistic movement, or social impact? Every guess becomes a clue.

The Core Game Concept: Guess The Historical Figure

The game works like a historical detective challenge. Players begin with a blank search box and enter a name such as “Abraham Lincoln,” “Cleopatra,” “Marie Curie,” “Nelson Mandela,” or “Ada Lovelace.” The system compares the guess with the secret figure of the day and returns hints across several categories.

Example Feedback Categories

To make the game educational without turning it into a dusty museum plaque, I designed feedback categories that are both useful and quick to understand:

  • Era: Ancient, medieval, early modern, modern, or contemporary.
  • Century: Whether the guessed person lived close to the target figure’s lifetime.
  • Region: Europe, Africa, Asia, the Americas, Oceania, or the Middle East.
  • Primary field: Politics, science, literature, activism, military leadership, philosophy, exploration, art, or invention.
  • Known for: A broad contribution, such as civil rights, discovery, empire-building, writing, reform, or invention.

For example, if the daily answer were “Harriet Tubman” and a player guessed “Susan B. Anthony,” the game might show partial matches: both are associated with reform and American history, but the era, movement, and historical role differ. The player learns by narrowing the field instead of simply failing.

Where AI Became My Co-Developer

AI did not magically build the game while I leaned back like a tech billionaire in a hoodie commercial. It worked more like a tireless assistant who never gets bored, occasionally overexplains, and sometimes confidently suggests code that behaves like it was raised by raccoons.

I used AI for brainstorming mechanics, generating sample data structures, debugging JavaScript logic, writing placeholder copy, and thinking through edge cases. It helped me move faster, but it did not remove the need for judgment. In fact, AI made judgment more important.

When I asked for a database structure, AI suggested useful fields such as name, birth year, death year, nationality, region, category, famous achievement, and difficulty level. That was a good start. But I still had to decide how broad each category should be, how to handle disputed identities, and whether “known for being extremely quotable” counts as a historical field. Sadly, it does not, though Winston Churchill tried his best.

The Historical Database: The Hardest Part Wearing A Fake Mustache

The most difficult part was not the interface or the guessing logic. It was the historical data. A word game can rely on a controlled word list. A historical figure game needs accuracy, fairness, clarity, and context.

Historical figures do not always fit neatly into boxes. Was Leonardo da Vinci primarily an artist, inventor, scientist, engineer, anatomist, or the patron saint of overachievers? Was Benjamin Franklin a statesman, scientist, printer, writer, diplomat, or proof that sleep was apparently optional in the 18th century?

To solve this, I created primary and secondary tags. A figure could have one main category and several supporting categories. For example:

  • Marie Curie: Primary category: Science. Secondary tags: chemistry, physics, Nobel Prize, radioactivity.
  • Frederick Douglass: Primary category: Activism. Secondary tags: abolition, writing, public speaking, civil rights.
  • Julius Caesar: Primary category: Politics. Secondary tags: military, Roman Republic, leadership, conquest.
  • Frida Kahlo: Primary category: Art. Secondary tags: painting, Mexico, surrealism, identity.

This made the game smarter. Players could receive partial credit for close thinking even when their guess was not correct. That matters because the best educational games do not just say “wrong.” They say, “Interesting, but try turning your brain slightly to the left.”

Designing The Feedback System

The heart of any Wordle-inspired game is feedback. Feedback must be immediate, understandable, and just mysterious enough to make players mutter, “One more guess,” which is the ancient gamer spell that destroys bedtime.

I used a color-coded system, but carefully. Green meant a direct match. Yellow meant a partial relationship. Gray meant no meaningful match. However, historical categories are less exact than letters, so I needed rules that felt fair.

Example Rule Logic

If a guessed figure lived within 50 years of the target figure, the century clue could show a partial match. If the person came from the same broad region but a different modern country, the region clue could show yellow. If both figures were connected to social reform but in different movements, the field clue could show partial alignment.

This made the game less about trivia and more about historical reasoning. Players were not merely asking, “Do I know the answer?” They were asking, “What kind of person fits these clues?” That shift made the experience more satisfying.

Making AI Useful Without Letting It Drive The Bus Into A Lake

AI can be incredibly helpful for development, but it needs supervision. When I asked it to generate historical figure data, it sometimes mixed broad facts with shaky details. That meant every important data point needed review. Birth years, regions, achievements, and labels had to be checked against reliable educational and historical references.

The best workflow was not “AI, build everything.” It was more like this:

  1. Ask AI for a draft structure or function.
  2. Review the output carefully.
  3. Test it in the actual game.
  4. Correct logic errors and oversimplified labels.
  5. Repeat until the game stopped behaving like a haunted spreadsheet.

For coding, AI was excellent at creating starter functions. For example, it helped draft logic to compare guessed figures against the answer. But I still needed to refine the function so it handled messy historical realities. A person born in one empire, active in another region, and remembered under multiple names cannot be processed like “apple” versus “grape.” History did not come with clean database columns. Rude, but true.

User Experience: Making History Feel Playable

A history game can fail quickly if it feels like homework wearing a party hat. The interface needed to be fast, friendly, and readable. I wanted the player to understand what happened after each guess without needing a tutorial longer than the Peloponnesian War.

The best design choices were small:

  • A searchable input box with autocomplete for historical names.
  • Clear tiles for each clue category.
  • A short explanation after every partial match.
  • A daily answer reveal with a mini-biography.
  • A shareable result that does not spoil the answer.

The mini-biography became one of my favorite features. After the game ends, players get a short profile of the figure: why they mattered, what they changed, and one surprising detail. This transforms the game from “I guessed a name” into “I learned something I may bring up at dinner and make everyone uncomfortable with my enthusiasm.”

Balancing Difficulty: Not Too Easy, Not “Who Was The Tax Collector Of 1427?”

Difficulty was another challenge. If every answer is wildly famous, the game becomes too easy. If every answer is obscure, it becomes a specialized exam for history professors and people who alphabetize their documentaries.

I divided figures into difficulty levels:

  • Beginner: Widely known figures such as George Washington, Cleopatra, Martin Luther King Jr., or Albert Einstein.
  • Intermediate: Important but less universally guessed figures such as Mary Wollstonecraft, Toussaint Louverture, or Ibn Battuta.
  • Advanced: Deeper-cut figures such as Hypatia, Mansa Musa, Sappho, or Zheng He.

The daily puzzle could rotate among levels, or the game could offer modes. A classroom mode might focus on figures from a specific unit, while a general mode could mix world history, U.S. history, science, art, literature, and political movements.

Why The Game Works As A Learning Tool

The game works because it uses retrieval practice, pattern recognition, and curiosity. Instead of passively reading a paragraph, players actively pull information from memory, test a guess, receive feedback, and revise their thinking. That loop is powerful because it turns knowledge into a puzzle.

It also encourages comparison. A student might know that Rosa Parks and Harriet Tubman are both central to American history, but the game pushes them to notice differences in century, movement, historical context, and form of activism. That is deeper than memorizing a name for a Friday quiz and forgetting it by Saturday lunch.

Teachers could use this kind of game as a warm-up activity, review tool, or discussion starter. After a round, students could explain why certain guesses were close or far away. Suddenly, the game becomes an entry point into historical thinking: sourcing, contextualization, comparison, and cause-and-effect analysis.

What I Learned From Building It

Building a Wordle-inspired historical figure game taught me that simple games are not actually simple. They are simple for the player because the designer has already wrestled the chaos into a tidy little box. Behind the scenes, every smooth interaction requires dozens of decisions.

I had to decide how much information to reveal, how to prevent spoilers, how to label historical regions responsibly, how to handle figures with multiple identities, and how to keep the tone fun without trivializing serious history. That last part mattered. A game about historical figures should be playful, but not careless. Some figures are connected to war, oppression, injustice, resistance, and tragedy. Humor belongs in the design voice, not in disrespecting the subject.

AI helped me move faster, but the human work remained essential. I still had to choose the learning goals, verify facts, design the emotional experience, and decide when a “clever” mechanic was actually confusing. AI gave me options. I had to provide taste.

Specific Example: A Daily Puzzle Flow

Imagine today’s answer is “Ada Lovelace.” A player first guesses “Marie Curie.” The game shows that the field is close because both are associated with science and intellectual achievement, but the century and specific contribution differ. The player then guesses “Charles Babbage.” Now the game lights up more clues: same era, connected field, related historical network. The player finally guesses Ada Lovelace.

After the win, the game displays a short note explaining that Lovelace is often remembered for her work on Charles Babbage’s Analytical Engine and for recognizing that such a machine could manipulate more than numbers. The player leaves with a better understanding of early computing history, and nobody had to say, “Please open your textbook to page 213.” Miracles do happen.

The AI Prompting Strategy That Worked Best

The most effective prompts were specific. Instead of asking, “Make me a game,” I broke the project into small tasks. I asked AI to help create a JSON schema for historical figures, write comparison logic, suggest clue categories, draft UI labels, and generate test cases.

A strong prompt looked like this: “Create JavaScript logic for comparing two historical figure objects. Each object includes birthYear, deathYear, region, primaryField, secondaryTags, and difficulty. Return exact, partial, or no match for each category.”

That kind of prompt produced usable results because it gave AI a clear job. Vague prompts produced vague answers. Specific prompts produced building blocks. The lesson: treat AI like a talented intern with lightning speed and no lived experience. Give it structure, check its work, and never let it name your variables unsupervised.

My Personal Experience Crafting The Game With AI

The experience of creating this game felt like building a tiny amusement park where every ride was powered by historical trivia and mild panic. At the beginning, I thought the biggest challenge would be coding. I imagined myself heroically battling JavaScript bugs while dramatic music played. There were bugs, yes, but the real challenge was designing a game that felt fair, educational, and fun at the same time.

The first prototype was ugly in the way only early prototypes can be ugly. The layout worked, technically, but it looked like a government form had swallowed a crossword puzzle. The colors were too loud, the spacing was awkward, and the feedback tiles felt more confusing than helpful. AI helped me revise the interface by suggesting cleaner component structures and shorter label text. Still, I had to test every change by playing the game like a normal human, not like the person who already knew where all the bodiesmeaning bugswere buried.

One of the funniest moments came when I tested a clue system and realized the game was being far too generous. It treated almost every reformer as a close match for every other reformer. Guess “Martin Luther King Jr.” for “Mahatma Gandhi”? Yellow. Guess “Susan B. Anthony” for “Frederick Douglass”? Yellow. Guess “Benjamin Franklin” for anyone who ever wrote something down? Practically a standing ovation. I had to tighten the rules so partial matches actually meant something.

Another lesson came from the historical figure list. AI could quickly generate names, categories, and summaries, but speed is not the same as accuracy. Some descriptions were too broad. Some categories needed nuance. Some figures belonged to multiple contexts. I learned to use AI for acceleration, not authority. The best results came when I asked for a draft, then verified and edited the content myself.

I also learned that educational games need emotional rhythm. If the player feels stupid after two guesses, they quit. If the answer is too obvious, they get bored. The sweet spot is when the game makes players feel like they are closing in on the answer. Each clue should create momentum. A good guess should feel rewarding even when it is wrong. That is where the Wordle-inspired format shines: it turns failure into information.

The share feature was another surprisingly important piece. A spoiler-free result lets players show progress without ruining the answer. That creates community around the puzzle. People can compare how many guesses it took, debate clue logic, or proudly announce that they recognized Hypatia in three tries, which is basically the intellectual equivalent of dunking a basketball.

By the end of the project, I understood why simple daily games are so addictive. They create a small ritual. They ask for just enough attention to feel satisfying. They give the brain a clean problem and a clear finish line. Adding historical figures gave that ritual a learning purpose. The final game was not just a puzzle; it was a tiny daily invitation to remember that history was made by real people, not just bold names on exam review sheets.

Most importantly, building the game with AI reminded me that creativity is still human-led. AI helped me draft, debug, organize, and rethink. But the taste, humor, caution, and purpose had to come from me. The machine could suggest a mechanic. It could not decide whether the game felt respectful, delightful, or worth playing. That was my job.

Conclusion: A Puzzle Game With A History Brain

Crafting a Wordle-inspired historical figure game with the help of AI turned out to be more than a coding experiment. It became a lesson in design, research, learning science, and creative restraint. The best version of the game is not the flashiest one. It is the one that makes players curious, rewards smart guessing, and turns historical knowledge into a daily habit.

AI made the process faster and more flexible, but it did not replace the need for careful thinking. Historical accuracy still matters. User experience still matters. Humor still needs timing. And every clue must earn its place. In the end, the project proved that AI can be a powerful creative partner when the human creator stays in charge of the vision.

If Wordle made the world fall in love with five-letter deduction, a historical figure guessing game can do something equally charming: make people fall in love with the past, one clue at a time.

The post I Crafted A Wordle-Inspired Historical Figure Game With The Help Of AI appeared first on Everyday Software, Everyday Joy.

]]>
https://business-service.2software.net/i-crafted-a-wordle-inspired-historical-figure-game-with-the-help-of-ai/feed/0
We’ve Now Shipped 3 Vibe Coded Apps to Production. Here’s What Actually Worked (And What Nearly Killed Us)https://business-service.2software.net/weve-now-shipped-3-vibe-coded-apps-to-production-heres-what-actually-worked-and-what-nearly-killed-us/https://business-service.2software.net/weve-now-shipped-3-vibe-coded-apps-to-production-heres-what-actually-worked-and-what-nearly-killed-us/#respondThu, 19 Feb 2026 15:02:11 +0000https://business-service.2software.net/?p=7377We shipped three AI vibe-coded apps to productionfastand learned that production doesn’t run on vibes. This in-depth, practical post breaks down what actually worked (spec-first prompting, small PRs, trunk-based development, feature flags, test pyramids, DORA metrics, and real observability) and what nearly took us out (prompt drift, hallucinated integrations, risky migrations, secret-leaking logs, and performance cliffs). You’ll get a repeatable pre-prod checklist, concrete examples of guardrails, and a 500-word bonus section on how our day-to-day workflow changed once we treated AI like a powerful teammatenot an autopilot. If you want to ship faster without shipping chaos, start here.

The post We’ve Now Shipped 3 Vibe Coded Apps to Production. Here’s What Actually Worked (And What Nearly Killed Us) appeared first on Everyday Software, Everyday Joy.

]]>
.ap-toc{border:1px solid #e5e5e5;border-radius:8px;margin:14px 0;}.ap-toc summary{cursor:pointer;padding:12px;font-weight:700;list-style:none;}.ap-toc summary::-webkit-details-marker{display:none;}.ap-toc .ap-toc-body{padding:0 12px 12px 12px;}.ap-toc .ap-toc-toggle{font-weight:400;font-size:90%;opacity:.8;margin-left:6px;}.ap-toc .ap-toc-hide{display:none;}.ap-toc[open] .ap-toc-show{display:none;}.ap-toc[open] .ap-toc-hide{display:inline;}
Table of Contents >> Show >> Hide

We didn’t set out to “vibe code” our way into production. We set out to ship. Fast. With AI help.
Then the AI help got… very helpful. Suddenly we were moving at a pace that felt illegal in most states.
Three apps later, we’ve learned a painfully clear truth:
vibe coding can absolutely get you to productionbut only if you install guardrails before the wheels come off.

This is the honest post-mortem (minus the crying): what worked, what failed, and what nearly turned our on-call phone into a tiny haunted rectangle.

First, What “Vibe Coding” Really Means (In Production Terms)

“Vibe coding” is the AI-driven style of building where you describe what you want in plain English, accept big chunks of generated code,
and iterate by running the app, reading errors, and prompting again. The vibe part is real: you’re steering with intent, examples, and feedback
not writing every line yourself.

The problem is that production doesn’t care about vibes. Production cares about:
authentication, reliability, data integrity, observability, and that one user who will absolutely paste 10,000 emojis into your input field.

So we treated vibe coding like a power tool: great for speed, terrible for fingers if you refuse to read the manual.

The 3 Apps (And Why We Were Brave Enough to Ship Them)

Each app started as “a quick tool” and ended as “please don’t break, we just told people about you.”
Different products, same pattern:

  • App #1: An internal ops dashboard (low stakes… allegedly).
  • App #2: A customer-facing workflow app (medium stakes, maximum opinions).
  • App #3: A lightweight analytics companion (high stakes, because data).

We shipped each one faster than our old playbook allowed, but we didn’t ship blindly. We built a repeatable system that let AI move quickly
while still respecting the laws of software physics.

What Actually Worked (Our “Vibe Coding, But Make It Production” Playbook)

1) We Stopped Asking for Code Firstand Started Asking for a Plan

The biggest upgrade wasn’t a new model or tool. It was changing our prompts.
We stopped saying: “Build me a settings page.”
We started saying: “Design the architecture, list risks, define data flow, then generate code in small PR-sized chunks.”

Our best prompts forced structure:

  • Inputs: constraints (stack, deadline, existing services), known requirements, what “done” means.
  • Outputs: endpoint list, schema, error cases, auth rules, logging events, test plan, rollout plan.
  • Risk scan: “What could go wrong in prod?” (The AI is surprisingly good at catastrophizing, when asked.)

Once we had a plan, code generation got cleaner, faster, and less “mysteriously haunted.”

2) We Forced Smaller Diffs (Because “Accept All” Is How Legends Get Fired)

Big AI-generated commits are a trap. They feel productive and ship-shaped, but they hide bugs like a toddler hides broccoli.
We enforced a hard rule: no change bigger than what a human can review in 15–20 minutes.

Practically, that meant:

  • One feature per PR.
  • One responsibility per file (when possible).
  • “No refactors plus new features” (AI loves bundling those like it’s making a burrito).

The AI didn’t mind. It just needed the constraint spelled outlike a golden retriever that codes.

3) We Used Trunk-Based Development + Feature Flags (So Shipping Didn’t Mean Releasing)

Vibe coding increases iteration speed, which makes long-lived branches even more painful.
We moved fast by merging small changes frequently (trunk-based development) and hiding incomplete work behind feature flags.

Feature flags became our “seatbelt”:

  • Deploy code continuously.
  • Release gradually (internal users → small % → everyone).
  • Kill switch instantly if something starts smoking.

The key discipline: flags are either short-lived (remove them) or intentionally permanent (document them). Otherwise, you’re just
building a museum of dead toggles.

4) We Put Tests Where the AI Was Weak (And Let It Excel Where It Was Strong)

AI is great at generating lots of plausible code. It is less great at predicting your weirdest edge cases.
So we leaned on a test “pyramid” mindset:

  • Many unit tests for pure logic (cheap, fast, catches dumb mistakes).
  • Some integration tests for APIs + database behavior (where “it works on my machine” goes to die).
  • Few end-to-end tests for critical paths (login, payment, core workflow).

We also used AI to generate test scaffolding and test cases, but we wrote the “golden paths” ourselves: the tests that define the product’s promise.
If you’re vibe coding, your tests are your memory.

5) We Measured Delivery Like Adults (DORA Metrics, Not Vibes)

We started tracking a few delivery metrics that correlate with high-performing teams:
deployment frequency, lead time for changes, change failure rate, and time to restore service.

Here’s why this matters for vibe coding: when your throughput increases, you need a speedometer and brakes.
If change failure rate spikes while deployment frequency rises, the AI isn’t “making you faster”it’s making you faster at breaking things.

6) Observability Became a Feature, Not a Nice-to-Have

Our first near-disaster wasn’t caused by a giant bug. It was caused by a tiny bug we couldn’t see.
That’s when we learned:
if you can’t observe it, you can’t own it.

For every app, we added:

  • Structured logs (request ID, user ID, error codes, key events).
  • Metrics (latency, error rates, queue depth, external API failures).
  • Tracing for slow requests (so we could find “the one call” that was ruining everyone’s day).
  • Alerts that page you for user pain, not for meaningless noise.

AI can generate instrumentation quicklyif you specify what you want to measure and why.
Otherwise it will happily log “something happened” 4 million times and call it a day.

7) Security: We Used Real Frameworks (Because “Seems Secure” Is Not a Control)

Vibe-coded apps can accidentally reinvent the greatest hits of security failures.
So we anchored our security checks to well-known practices:

  • Secure development fundamentals (threat modeling, secure defaults, least privilege).
  • Web app risk awareness (access control, injection, misconfiguration, insecure design patterns).
  • Supply chain hygiene (dependency updates, vulnerability scanning, SBOM thinking).

We also did one painfully simple thing that saved us multiple times:
we wrote an “auth rules” document in plain English, then forced every endpoint and UI action to map to it.
If the AI generated code that violated the rules, tests failedor reviewers did.

What Nearly Killed Us (And How We Survived)

1) Prompt Drift: The App Slowly Became a Different App

Over dozens of prompts, the AI “helpfully” optimized things… in directions we didn’t intend.
A settings page became a mini admin console. A simple report became a complex query builder.
The scope creep didn’t happen in a meeting. It happened in generated code.

Fix: we maintained a living product brief (requirements, non-requirements, data boundaries) and pasted the key section into every major prompt.
Repetition is annoying. So is rewriting your app.

2) Hallucinated Integrations (The API Endpoint That Never Existed)

AI will confidently call endpoints that look reasonable. Sometimes those endpoints are imaginary.
You find out later when production is returning “404” like it’s a personality trait.

Fix: contract tests, mocked staging, and a rule: “No external call without a documented contract and retries/timeouts.”

3) Data Migrations: AI Is Brave, Databases Are Not

On App #3, the AI proposed a schema change that looked elegant… and would have been a disaster at scale.
Production databases don’t care about elegance. They care about locks, backfills, and not ruining your weekend.

Fix: we adopted a boring migration checklist:

  • Backwards-compatible changes first (add columns before removing).
  • Write code that supports old + new schema during rollout.
  • Backfill in batches with monitoring.
  • Only then remove old fields.

Boring is the point.

4) Secrets and “Helpful” Logging

AI loves logging. It also loves logging the wrong things.
At one point we caught a debug log line that would’ve exposed a token in plain text.
That’s the sort of bug that doesn’t crash your appit crashes your reputation.

Fix: a redaction layer, lint rules for common secret patterns, and a strict “no secrets in logs” test.
Plus: we stopped passing secrets through the AI toolchain and used proper secret managers/environment injection.

5) The “Works Locally” Performance Cliff

AI-generated code can be correct and still painfully slow:
N+1 queries, unbounded loops, missing indexes, eager-loading everything because “why not?”

Fix: performance budgets and profiling in staging:

  • Set a target latency for key endpoints.
  • Load test the critical path.
  • Add caching only after measurement (cache-first is how you store mistakes faster).

The Checklist We Now Use Before Any Vibe-Coded App Hits Production

Here’s the “no drama” gate we apply every single time:

  1. Requirements: written spec + “not in scope” list.
  2. Security: auth rules mapped to endpoints + basic threat modeling pass.
  3. Tests: unit + integration coverage for critical logic; a few E2E smoke tests.
  4. CI/CD: automated build/test; deploy pipeline; rollback plan.
  5. Release safety: feature flags, staged rollout, kill switch.
  6. Observability: logs/metrics/traces + alerts tied to user pain.
  7. Dependencies: vulnerability scanning + automated update workflow.
  8. Runbook: “If X breaks, do Y” (written before it breaks, not during).

If you do only one thing from this list, do this: write the runbook. It will make Future You feel loved.

So… Should You Vibe Code to Production?

Yesif you treat AI like a fast junior teammate:
capable, tireless, occasionally overconfident, and in desperate need of clear requirements and review.

Vibe coding shines when you:

  • Need rapid iteration and can break work into small pieces.
  • Have strong CI/CD and a culture of testing and review.
  • Use feature flags and gradual rollouts to reduce blast radius.
  • Care about observability and operational readiness from day one.

It fails when you:

  • Ship massive diffs you don’t understand.
  • Skip tests “just this once.”
  • Ignore security basics because the app “is small.”
  • Wait until users complain to learn what’s happening in production.

Bonus: 500 More Words of Hard-Won Experience (Because We Have the Scars)

After shipping the third app, we realized something awkward: the AI didn’t “replace” engineering effort. It moved the effort.
We spent less time typing and more time doing what software teams were always supposed to doclarify, validate, and operationalize.
The vibe part is fun. The production part is a responsibility.

Here’s what changed in our day-to-day workflow once we accepted that:

We started every build with a one-page “definition of done.”
Not a novel. One page. It included the user story, the core flow, the scary edge cases, and the explicit list of what we were not building.
AI loves to be helpful. Without boundaries, it becomes “helpful” in the same way a puppy is helpful around an open bag of flour.
That one page became our anchor; when a prompt drifted, we pulled it back.

We learned to prompt for tradeoffs, not miracles.
Instead of asking, “Make it scalable,” we asked, “Given 10k daily active users, what breaks first and how do we instrument it?”
Instead of “Make it secure,” we asked, “List the top three abuse cases, then propose mitigations and tests.”
When you prompt for specificsworkload assumptions, threat scenarios, failure modesthe output becomes less magical and more engineering-grade.

We stopped treating refactors as “free.”
AI will happily rewrite large parts of your codebase because it sees a cleaner pattern. Sometimes it’s right. Often it’s not worth the risk.
In production work, “cleaner” is not the same as “safer.” We adopted a rule: refactors require a measurable reason
(performance, reliability, security, maintainability pain). Otherwise, it’s just noveltyfun until it breaks.

We made rollback boring on purpose.
We practiced rollback like a fire drill. We documented it. We timed it. We automated what we could.
This had an unexpected side effect: it made shipping less scary, which made us ship more, which made us learn faster.
A reliable undo button is the difference between confident delivery and anxious tinkering.

We changed how we do code review.
Review wasn’t about style. It was about risk:
“What’s the blast radius?” “What happens if this dependency fails?” “Are we logging anything sensitive?”
“Is this endpoint protected the way the spec says it is?” That lens made AI-generated code reviewable.
And yes, we rejected AI code. Often. The model didn’t sulk. It just generated a better version.

The biggest lesson: vibe coding can compress build time, but it can also compress the feedback loop in dangerous ways.
If you don’t slow down at the right momentssecurity, migrations, observabilityyou’ll pay for it later with interest.
Ship fast. But install guardrails faster.

Conclusion

Shipping three vibe-coded apps to production taught us that speed is only a superpower if you can steer.
What worked wasn’t “better prompts” aloneit was pairing AI velocity with engineering fundamentals:
trunk-based development, feature flags, solid tests, real security practices, and serious observability.

The things that nearly killed us were predictable: scope drift, hallucinated integrations, risky migrations, leaky logs, and performance cliffs.
The fix was also predictable: reduce blast radius, measure outcomes, and treat production readiness as a feature.

The post We’ve Now Shipped 3 Vibe Coded Apps to Production. Here’s What Actually Worked (And What Nearly Killed Us) appeared first on Everyday Software, Everyday Joy.

]]>
https://business-service.2software.net/weve-now-shipped-3-vibe-coded-apps-to-production-heres-what-actually-worked-and-what-nearly-killed-us/feed/0