A codebase built for vibe coding.

Showing all 84. Click any filter above to narrow.

• FE01No two buttons are the sameFENo two buttons are the sameEach request invents new spacing, new hover states, new disabled treatment. Your UI looks like five different products glued together — and your users notice before you do.
• FE02Accessibility is a coin flipFEAccessibility is a coin flipSome buttons have focus rings. Some don't. Some form fields announce errors to screen readers. Some don't. There's no system enforcing the basics, so the basics get skipped.
• FE03You ship the same primitive 20 timesFEYou ship the same primitive 20 times"Add a date picker" gets a fresh implementation each time. None share state. None handle timezones the same way. You end up with twenty subtly-different versions of the same control. It's a mess.
• FE04There's no upgrade pathFEThere's no upgrade pathWant to change all your buttons to a new design? You can't — they're all bespoke. The "refactor" is twenty files of hand-merging changes that should have been one.
• FE05New engineers make it worseFENew engineers make it worseEvery screen is its own snowflake. There's no canonical reference, no design system doc, no Storybook to point to. The codebase has no center.
• FE06The bundle balloonsFEThe bundle balloonsTwenty implementations of a thing means twenty copies of similar code. Tree-shaking can't help when there's no shared module. Performance degrades quietly, then suddenly.
• FE07Dark mode is half-shippedFEDark mode is half-shippedEach component bakes its own dark treatment — or doesn't bother. Half your app respects the theme; the rest looks broken. You only find out when a user files the bug.
• FE08Forms validate however the agent feltFEForms validate however the agent feltSome fields validate on blur, some on submit, some never. Error messages have five different styles. Every new form throws away whatever convention the last one established.
• FE09Translations hard-code EnglishFETranslations hard-code EnglishStrings live inline in JSX, not in a translation catalog. Localizing for a new market means hunting through every screen and praying you didn't miss one. The "international launch" becomes a quarter of work.
• FE10No one writes tests for any of itFENo one writes tests for any of itEach bespoke component would need its own test scaffold; nobody writes any. The first regression you ship is the first one you find — usually in production, on a Friday.
• FE11Loading and errors are coin flipsFELoading and errors are coin flipsSome screens use spinners, some skeleton blocks, some show nothing. Errors land as toasts, banners, console logs, or silent failures. The user experience is whatever the agent felt like that day.
• FE12Mobile lags desktop foreverFEMobile lags desktop foreverEvery screen gets designed at 1440px and "tested" at 1440px. Mobile breaks in five different ways, gets fixed in twenty different places. The phone experience stays permanently behind the desktop one.
• FE13Empty states are an afterthoughtFEEmpty states are an afterthoughtWhat does the screen look like before any data exists? Vibe-coding's answer is "nothing" or "whatever the LLM felt like." Real users hit those states first, and the first impression is "broken."
• FE14Date handling is a roulette wheelFEDate handling is a roulette wheelEach form parses dates differently. Time zones leak into the UI. Some screens show "2 days ago," some ISO strings, some crash on null. The internationalization story is "we'll fix it later."
• FE15Every screen logs to nowhereFEEvery screen logs to nowhereconsole.log everywhere, real audit trails nowhere. When a customer asks "who changed this, when, and why?", there's no answer. The first compliance review is going to be a long week.
• API01Every endpoint invents its own shapeAPIEvery endpoint invents its own shape`{ ok: true, data: ... }` here, `{ result: ... }` there, plain values somewhere else. Every client gets to handle five different envelope shapes. The shared type definitions everyone wanted are now twenty individual ones.
• API02Auth is different per endpointAPIAuth is different per endpointThis one wants a bearer token, that one needs a session cookie, this one checks an API key, the new one doesn't check anything. Securing the platform becomes an archaeology project.
• API03Error responses are improvisedAPIError responses are improvisedSome errors come back as 200 with `{ error: ... }`. Some as 400 with a message string. Some as 500 with a stack trace. Clients write five-layer fallback parsers and still miss cases.
• API04Pagination is a free-for-allAPIPagination is a free-for-all`?page=`, `?offset=`, `?cursor=`, sometimes nothing at all. Each endpoint picked its own convention on a different day. Aggregating across endpoints is a nightmare.
• API05Versioning never happensAPIVersioning never happensThere's no `/v1/`. There's no `Accept-Version` header. Breaking changes ship into production silently and a partner's integration breaks at 3am on a Saturday.
• API06Validation lives in five placesAPIValidation lives in five placesSometimes in the controller, sometimes in middleware, sometimes in a database trigger, sometimes nowhere. Invalid data slips through wherever the chain is weakest.
• API07Rate limiting is theoreticalAPIRate limiting is theoreticalDiscussed in three architecture meetings, never implemented. One enthusiastic customer's script can take the platform down on a slow Tuesday.
• API08CORS is open or it's brokenAPICORS is open or it's brokenEither `Access-Control-Allow-Origin: *` (security risk) or the wrong origin (working app suddenly stops working). Nobody actually understands the spec; everybody copy-pastes from Stack Overflow.
• API09Stack traces leak to productionAPIStack traces leak to productionDefault error handlers ship full stack traces in the response body. Attackers thank you for the free reconnaissance — your file paths, your framework versions, your internal class names.
• DB01Tables grow without relationshipsDBTables grow without relationshipsEach feature creates its own tables and copies the data it needs from elsewhere. By month six there are four versions of `users` and nobody knows which is canonical.
• DB02Migrations are an honor systemDBMigrations are an honor systemSometimes a `.sql` file in git. Sometimes a Slack message. Sometimes a developer just ran ALTER TABLE in prod. Reproducing the schema in staging is impossible.
• DB03Indexes show up after the fireDBIndexes show up after the fireEvery query is `SELECT *`. Indexes get added the day the API starts returning 504s. Then more get added. Then the table is too big to add more without downtime.
• DB04Naming is a creative writing exerciseDBNaming is a creative writing exercise`userId`, `user_id`, `UserID`, `usr`, `uid` — all in the same database. JOIN performance suffers. Devs spend more time looking up column names than writing SQL.
• DB05Foreign keys are optionalDBForeign keys are optionalMost tables don't enforce them. Orphan records accumulate. Deleting anything is dangerous because nobody knows what depends on what.
• DB06Soft-delete is five different thingsDBSoft-delete is five different things`deleted_at TIMESTAMP`. `is_deleted BOOLEAN`. `status = 'deleted'`. Hard delete from this table but not that one. Restoring a deleted user is a manual ticket every time.
• DB07Timestamps disagree across tablesDBTimestamps disagree across tables`created_at` vs `createdAt` vs `inserted_on` vs nothing at all. Time zones live wherever the developer happened to be that day. Audit reports require three CASE statements per column.
• DB08No audit trail anywhereDBNo audit trail anywhereWhen the regulator asks "who changed this customer's address, and when?", the answer is `we don't know`. Adding it later means a six-week schema migration across every table.
• DB09Multi-tenancy is application-onlyDBMulti-tenancy is application-onlyTenant ID lives in a column that the application 'remembers' to filter by. One missed WHERE clause and customer A sees customer B's data. There's no row-level security as a backstop.
• SVC01Background jobs run on hopeSVCBackground jobs run on hopeEach job has its own ad-hoc retry loop. Some retry forever, some give up silently. Failed jobs disappear from the queue with no dead-letter; you find out from the user that the welcome email never sent.
• SVC02Cron is whatever runs in prodSVCCron is whatever runs in prodThere's no canonical scheduler. One job in a node-cron call, another in a shell script, a third in Azure Scheduler that nobody documented. Migrations drop jobs constantly and nobody notices for a week.
• SVC03Webhooks are fire-and-forgetSVCWebhooks are fire-and-forgetOutgoing webhooks have no retry, no signing, no idempotency key. Receiving webhooks never verify signatures. Both ends pretend HTTP is reliable; both ends get burned when it isn't.
• SVC04Queues exist on three platformsSVCQueues exist on three platformsRedis Streams here, Azure Service Bus there, a homegrown DB-polling queue somewhere else. The operational runbook is one stale Notion page from two engineers ago.
• SVC05Retries are an honor codeSVCRetries are an honor codeEvery service implements retry differently. Some exponential back-off, some immediate, some not at all. When a downstream blips, the system amplifies the failure instead of absorbing it.
• SVC06Secrets live in .env, .env, .envSVCSecrets live in .env, .env, .envEach service reads its own .env from its own folder; the same DB password is duplicated four times. Rotating a secret means tracking down every copy and praying nobody hard-coded one in a script.
• SVC07Health checks ping themselvesSVCHealth checks ping themselvesEvery service exposes /health that returns 200 as long as the process is running. None of them check the database they actually need. Outages stay green on the dashboard while customers fume.
• SVC08No service mesh, just trustSVCNo service mesh, just trustInter-service calls happen over plain HTTP with whatever headers the dev felt like adding. No mTLS, no circuit breakers, no rate limits per caller. One misbehaving service can take everything down.
• SVC09Logs aren't correlatedSVCLogs aren't correlatedEach service writes its own log format to its own destination. Tracing one user's request across three services means grep on five servers, a timestamp prayer, and a guess.
• DEV01Developer biasDEVDeveloper biasEach developer builds screens that look like screens they've built before. The new hire from Stripe makes everything look like Stripe. The next hire makes it look like Linear. Three personalities, one product.
• DEV02Cross-team dev conflictsDEVCross-team dev conflictsA dev who worked on the e-commerce flow imports patterns from there into the admin panel. Another imports patterns from the analytics dashboard back into marketing. Every screen carries baggage from a different codebase.
• DEV03Knowledge silos by screenDEVKnowledge silos by screenWhoever built a screen owns it forever. Asking someone else to touch it means re-reading the whole thing first. People route around screens they don't own; bugs live longer than they should.
• DEV04Works on my machine foreverDEVWorks on my machine foreverEach developer's local setup drifts from the others. The deploy that succeeded yesterday fails today on a different laptop. Standardizing the environment has been on the roadmap for a year.
• DEV05Code review becomes archaeologyDEVCode review becomes archaeologyReviewing a vibe-coded PR requires reading the entire feature from scratch — no shared primitives means no shared mental model. Reviews shrink to 'looks fine, ship it.'
• DEV06Onboarding takes a monthDEVOnboarding takes a monthNew hires can't get productive in week one because every screen is its own snowflake. They spend three weeks reading code and asking questions; by week four they're shipping vibe-coded screens too.
• DEV07Senior devs are bottlenecksDEVSenior devs are bottlenecksEvery decision routes through the two people who remember why the early code looks the way it does. Their 1:1s become technical-debt triage and everyone else waits in line.
• DEV08Tribal knowledge accumulatesDEVTribal knowledge accumulatesThe reason a component does the weird thing it does is 'because Adam built it last summer and Adam knows.' Adam left in February. The component still does the weird thing.
• DEV09Architecture decisions never landDEVArchitecture decisions never landThere's no design doc, no ADR, no architecture review. Big choices get made in PR comments and forgotten the next week. The same debate happens every quarter with different participants.
• DEV10Standups turn into rehashDEVStandups turn into rehash"What did you do yesterday?" never matches the PR. Engineers explain why a 'simple' change took three days because it touched four bespoke implementations. Standup becomes therapy, not coordination.
• DEV11Slack threads replace docsDEVSlack threads replace docsEvery answer lives in a thread from 2022, and the person who knew is gone. New hires re-derive the same patterns three times before someone finally writes them down — until the docs go stale again in a month.
• DEV12The Friday-deploy curseDEVThe Friday-deploy curseNobody pushes after Wednesday because the rollback is hours of guessing, not minutes. Two days a week the team is functionally read-only. Velocity halves and nobody marks it down on the calendar.
• DEV13Hotfix sprints replace featuresDEVHotfix sprints replace featuresHalf the sprint is reactive cleanup — fixing the production weirdness that vibe-coded screens introduced in the last release. The 'feature sprint' on the roadmap quietly becomes a maintenance sprint every other week.
• DEV14Estimates are random numbersDEVEstimates are random numbers'Two days' means anywhere from a day to a month because nobody knows what hidden coupling the change will hit. PMs hedge every commitment; engineers hedge every estimate; the whole planning loop becomes a guess.
• EXEC01Velocity decays after month threeEXECVelocity decays after month threeThe first three months are dazzling. By month six, every feature ships slower than the last. By month nine, the team is in 'cleanup sprints' instead of shipping product. The line on the burndown chart is unmistakable.
• EXEC02More engineers ≠ faster shippingEXECMore engineers ≠ faster shippingAdding the fourth developer makes the project slower, not faster. Onboarding cost + coordination overhead + bespoke-everything multiplies the integration time per feature. Brooks's law, but worse.
• EXEC03Customer NPS dips quietlyEXECCustomer NPS dips quietlyThe product gets less coherent each month. Customers don't file tickets about it — they just rate the experience lower. By the time the NPS dip shows up in the quarterly review, the cause has been compounding for two quarters.
• EXEC04Talent retention suffersEXECTalent retention suffersStrong engineers don't stay in codebases they can't be proud of. The first two senior departures cite 'culture.' The third one says it out loud: the code is unmaintainable and nobody seems to care.
• EXEC05Re-platform budget every 2 yearsEXECRe-platform budget every 2 yearsYear two, somebody pitches the 'great rewrite.' Year three, it's funded. Year four, it ships at half feature parity. Year five, the rewrite has the same problems and someone pitches a new rewrite.
• EXEC06Audit prep becomes a scrambleEXECAudit prep becomes a scrambleSOC 2, PCI, HIPAA — each audit reveals that the things you assumed were standard (audit trails, access logs, encryption-at-rest, deletion policies) aren't, because nobody specced them. Six weeks of all-hands prep per audit.
• EXEC07Strategic features need rewritesEXECStrategic features need rewritesThe new product line you announced on the earnings call requires multi-tenant data isolation. Your existing platform doesn't have it. Adding it is a six-month foundation project before any of the new product can ship.
• EXEC08Due diligence gets brutalEXECDue diligence gets brutalThe acquirer's technical diligence team finds the seams in a day. The valuation discount they apply isn't 5%, it's 30%. The deal closes but the price is what your codebase is, not what you thought it was.
• EXEC09Tech debt eats every 1:1EXECTech debt eats every 1:1Every leadership 1:1 with engineering becomes a status update on remediation work, not product. The product roadmap quietly slips. The board notices.
• EXEC10Roadmap slips become cultureEXECRoadmap slips become cultureEvery quarterly review opens with a slide explaining why dates moved. The team gets numb to it; the board gets concerned. Eventually 'we'll commit to that next quarter' is the only credible answer leadership can give.
• EXEC11Engineering recruiting gets harderEXECEngineering recruiting gets harderStrong candidates ask to see the codebase before signing. The ones worth hiring walk after the technical screen — they recognized the patterns. You end up hiring from a smaller pool that didn't ask.
• EXEC12Outage frequency creeps upEXECOutage frequency creeps upFive-nines was the goal; you're at three nines and trending. Each outage has a different root cause because the infrastructure has no shared shape. SLO conversations become weekly and the dashboards stop matching reality.
• EXEC13M&A integrations stallEXECM&A integrations stallThe acquirer assumes your platform can absorb their codebase. It can't — there's no plug-in point for new modules, no shared auth, no canonical user model. The integration line item in the deal balloons and the timeline doubles.
• EXEC14Compliance becomes the roadmapEXECCompliance becomes the roadmapSOC 2, HIPAA, GDPR, ISO 27001 — each audit forces foundational work that displaces product work. By year three the engineering org spends more time on compliance remediation than on the features the market actually wanted.
• CX01Every release is a mini-launchCXEvery release is a mini-launchEach weekly deploy changes the UI in ways the user didn't ask for. They have to relearn small things constantly. Trust in the product erodes one tiny surprise at a time.
• CX02"Where did that button go?"CX"Where did that button go?"The button moved from the top right to the bottom of the page. Then it changed icon. Then it disappeared entirely and reappeared in a sidebar. Support tickets repeat: "I can't find X anymore."
• CX03Help docs are perpetually wrongCXHelp docs are perpetually wrongScreenshots in the docs show last quarter's UI. Step-by-step guides reference buttons that have moved. Customers stop trusting the docs and ask support directly. Support volume doubles.
• CX04Power users find broken pathsCXPower users find broken pathsThe 5% of customers who actually use the product hard are the first to find the weird state combinations the screens don't handle. They file the bug. Two months later it's still in the backlog because the fix touches six unrelated screens.
• CX05Support tickets repeat themselvesCXSupport tickets repeat themselvesThe same questions come in every week. Onboarding confusion, the same form bug, the same date-formatting issue. Support copy-pastes answers from a Notion doc instead of fixing the underlying product issues.
• CX06Browser-specific failures pile upCXBrowser-specific failures pile upSafari users hit one set of bugs. Edge users hit another. Mobile Safari has its own list. Nobody tests in anything but Chrome, so the support load skews to whichever browser the dev didn't use.
• CX07Trust erodes after a few weird bugsCXTrust erodes after a few weird bugsA power user hits three subtly different versions of the date picker in one workflow and thinks 'is this product actually finished?' They start hedging their commitment, just in case.
• CX08"Is this the same product?"CX"Is this the same product?"A new customer's first impression doesn't match the docs they read before signing. The screens they see don't match the demo they were shown. Sales has to retrain the AE on what to actually demo each quarter.
• CX09Mobile and desktop feel like 2 appsCXMobile and desktop feel like 2 appsThe mobile experience has different navigation, different naming, different button placement, and different bugs. Customers who use both end up with two mental models for the same product.
• CX10Onboarding completion dropsCXOnboarding completion dropsNew users hit the inconsistencies in their first hour. The signup flow uses one date format; the dashboard uses another; the export tool crashes on null. Activation metrics drift down quarter by quarter without an obvious cause.
• CX11Churn shifts to silentCXChurn shifts to silentCustomers don't file a ticket and rage-quit — they just stop logging in. The exit interviews you do run cite 'reliability' and 'polish' more than 'features missing.' By the time the cohort retention chart shows it, the damage is months old.
• CX12Sales demos need disclaimersCXSales demos need disclaimers"Don't click there, it's not done." Every demo path has a known-broken sidetrack the AE memorizes. The Friday demo dance becomes part of the playbook; new AEs need a week of training just on what to avoid showing.
• CX13Renewal calls turn defensiveCXRenewal calls turn defensiveThe CSM spends 25 minutes of a 30-minute renewal call explaining known issues instead of expanding the account. The expansion ARR opportunity gets traded for retention — and retention isn't always enough either.
• CX14Same bug reported a dozen timesCXSame bug reported a dozen timesDifferent users hit the same broken workflow on different days and file the same ticket. The support team pastes the workaround into a Notion doc. The underlying screen never gets fixed because the fix touches six unrelated places.