Reproduced from what real tools keep writing. Each one demos fine but quickly falls apart in production.
01The god endpoint
Backendapp.post('/api/handler', async (req, res) => {
const { action, payload } = req.body
switch (action) {
case 'login': {
const [user] = await db.query(
`SELECT * FROM users WHERE email = '${payload.email}'`
)
return res.json({ success: true, user })
}
case 'getBookings':
return res.json(await db.query('SELECT * FROM bookings'))
case 'updateRole':
await db.query(
`UPDATE users SET role = '${payload.role}'
WHERE id = ${payload.id}`
)
return res.json({ success: true })
// ...19 more cases
default:
return res.json({ success: true })
}
})
A single endpoint for every action, so nothing can be secured, rate-limited, or tested on its own. User input is inserted straight into queries, a classic SQL injection risk, anyone can list every booking or update roles, and unknown actions still report success.
02The pyramid of doom
Frontendreturn loading ? (
<Spinner />
) : error ? (
<ErrorBanner error={error} />
) : user ? (
user.isAdmin ? (
stats ? (
stats.length > 0 ? (
<AdminDashboard stats={stats} />
) : (
<EmptyState />
)
) : (
<Spinner />
)
) : (
<UserDashboard user={user} />
)
) : (
<LoginPrompt />
)
Every new state adds one more nested ternary. Six levels in, nobody can say which branches are reachable, which spinner is rendered, or where the next feature is supposed to go.
03The initial-commit compose file
Infrastructureservices:
app:
image: node:latest
ports:
- '0.0.0.0:3000:3000'
environment:
DATABASE_URL: postgres://admin:admin123@db:5432/prod
STRIPE_SECRET_KEY: sk_live_definitely_fine_in_git
JWT_SECRET: secret
restart: always
db:
image: postgres:latest
ports:
- '0.0.0.0:5432:5432'
Hardcoded secrets committed straight into git, the production database's connection string visible to everyone, and a floating latest tag that silently changes what ships on every deploy. Written when bootstrapping the app, never read again.
04The copy-pasted guest
Data modelCREATE TABLE bookings (
id SERIAL PRIMARY KEY,
guest_name TEXT,
guest_email TEXT,
guest_phone TEXT,
room_id INT,
checkin DATE,
checkout DATE
);
-- can be a valid approach, but AI tools will often implement
-- patterns like this without considering the tradeoffs
Needlessly denormalized data. No guests table, no foreign key: every booking duplicates the same guest's name, email, and phone. Sometimes a legitimate approach when read performance is critical, but usually we see this pattern implemented without any synchronization mechanism to prevent data from becoming inconsistent.
Look familiar? Decades of experience has taught us to sniff out every one of these anti-patterns, and hundreds more. Get in touch →