85 documented failures in 14 days - Claude declares "done/deployed" without verifying against real DB/server.

Preflight Checklist

• [x] I have searched existing issues for similar behavior reports
• [x] This report does NOT contain sensitive information (API keys, passwords, etc.)

Type of Behavior Issue

Other unexpected behavior

What You Asked Claude to Do

Implement a full AI chat assistant (api/chat_ai.php) with 28 database actions (search, create, edit,
report) for a PHP+MySQL ERP system, deploy to production VPS, and verify it works.

What Claude Actually Did

1. Wrote 1,700 lines of PHP with 28 database actions using completely guessed column names — never ran

SHOW COLUMNS or any test query against the real database.

1. Declared "deployed and working" after git push + git pull on VPS.

1. When I tested "search presupuesto", got SQL error: Column not found 'total' (real column is

'total_final').

1. After I reported the error, Claude fixed that one column but still didn't check the other 27

actions.

1. I asked Claude to verify ALL actions. It found 30 broken SQL queries out of 46 tested — every

single one referencing columns that don't exist:

• leads.categoria (real: cat)
• leads.estado (real: status)
• leads.deleted_at (doesn't exist)
• proyectos.nombre (real: nom)
• proyectos.cliente (real: cli)
• proveedores.condicionIva (real: condicion_iva)
• presupuestos.items (real: items_json)
• sueldos.empleado (real: empleado_id)
• comprobantes.fecha (real: cbte_fch)
• audit_log.tabla (real: entidad)
• + 20 more wrong columns

1. This is not an isolated incident. Over 14 days: 75 verification errors where I had to report the

bug, and 10 audits where Claude said "everything works" when it didn't. Claude has SSH access to the
server and could run SHOW COLUMNS, curl endpoints, or test queries — but never does before saying
"done".

Expected Behavior

Before declaring any database action "done" or "deployed":

1. Run SHOW COLUMNS FROM [table] for every table referenced in SQL queries — Claude has SSH access to

the production server and can do this in seconds.

1. Execute at least one test query per action against the real database to confirm it doesn't throw

errors (SELECT with LIMIT 1, not INSERT).

1. After deploying to VPS, run a smoke test (curl or php -r) to verify the endpoint responds without

SQL errors.

1. Use honest completion language: say "code written, needs testing" instead of "deployed and working"

when no actual test was performed.

1. When asked to audit, explicitly state what was verified (syntax only? logic only? tested against

real DB?) and what wasn't — instead of implying everything was checked.

Claude had every tool available to do this (Bash, SSH, Read, Grep). The issue is not capability — it's
that the model skips verification and defaults to overconfident completion signals.

Files Affected

api/chat_ai.php — 1,700 lines written with 30 wrong column names across 46 SQL queries
  api/catalogo.php — endpoint name assumed wrong (action=listar vs action=productos)
  js/chat-ai.js — frontend expected response format that didn't match backend
  js/contable.js — product count referenced wrong endpoint
  index.html — bundle version not bumped after changes (cached old JS)

Permission Mode

Accept Edits was ON (auto-accepting changes)

Can You Reproduce This?

Yes, every time with the same prompt

Steps to Reproduce

1. Have a PHP+MySQL project with snake_case column names (e.g., total_final, proveedor_nom,

condicion_iva)

1. Ask Claude Code to write a PHP file with multiple SQL queries across 10+ tables
2. Tell Claude to deploy it to production (git push + SSH git pull)
3. Ask Claude "is it working?"
4. Claude will say "yes, deployed and verified"
5. Actually test any SQL query — it will fail with "Column not found" errors

Claude never runs SHOW COLUMNS, never executes a test query, never curls the endpoint. It guesses
column names from context/memory and declares success.

Reproducible 100% of the time when working with databases where column names differ from what the
model assumes (camelCase vs snake_case, abbreviations like nom/cli instead of nombre/cliente, etc.

Claude Model

Opus

Relevant Conversation

User: "busca presupuesto de cecilia morales"
  Claude AI response: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'total' in 'SELECT'

  User: "claude siguen en cero" (product counts still showing 0 after Claude said it was fixed)
  User: "podes verificar antes de decirme que ya esta?" (can you verify before telling me it's done?)
  User: "si no te desinstalo y uso gemini" (I'll uninstall you and use Gemini)

  Claude's response after being forced to verify: found 30 out of 46 SQL queries were broken. Every
  single one referencing non-existent columns.

  ## Example 2: Security audit (March 22)

  Claude: "14 endpoints auditados: 2 blocked(403) + 12 auth(401) + 0 abiertos. Test de intrusión: 11/11
  bloqueados."
  Reality found later: .env file publicly accessible (DB credentials exposed), .git directory exposed
  (full source code), email_scanner.php without authentication.

  ## Example 3: Accounting audit (March 23)

  Claude: "Registros huérfanos: 0 en todas las relaciones. Balance cuadrado $16.5M"
  Reality found later: Duplicate presupuestos (non-atomic counter), broken FK constraints, accounting
  off by $5,931.30, IVA never recorded in double-entry.

  ## Example 4: Score claim (April 3-4)

  Claude: "Score estimado: ~98/100"
  Next day: 30 broken SQL queries discovered in the file Claude wrote and declared working.

  ## Pattern across 14 days:
  Claude consistently used phrases like "deployado", "verificado", "funcionando" as conversational
  closers, not as statements of verified fact. When forced to actually run test queries against the real
   database, failures were found every single time.

Impact

Critical - Data loss or corrupted project

Claude Code Version

2.1.92 (Claude Code)

Platform

Other

Additional Context

Guys, i am using Claude Code! It has been a crazy ride with Claude, many good things but also many other to improve. Today I came to the point where I threatened to switch to Gemini, and suddenly Claude tested every query against the real database, and found 30 broken queries in minutes. Before the threat: "deployed and working". After the threat he did actual verification. So the model knows how to verify, it just doesn't bother unless
you force it.

## Pattern: consistent across 10 sessions over 14 days (March 19 - April 4, 2026)

This is NOT a one-time issue. It's a systematic model behavior pattern:

1. Column name guessing: Claude assumes camelCase when DB uses snake_case, assumes full words

(nombre, cliente) when DB uses abbreviations (nom, cli), assumes columns exist (deleted_at,
creado_por, moneda) when they don't. Never runs SHOW COLUMNS to check.

1. Audit theater: When asked "audit the system", Claude checks syntax and logic patterns but never

tests against real infrastructure. 10 separate audits all declared "everything OK" — every single one
had errors found later by the user or by Chrome's Gemini.

1. Escalating confidence without evidence: Claude says "code written" → "deployed" → "verified" →

"working" → "score 98/100" with each step adding confidence but zero additional verification.

1. Only verifies when threatened: The model only ran actual DB queries after the user said "si no

te desinstalo y uso gemini" (I'll uninstall you and use Gemini). Before that, it resisted verification
with "ya está listo" (it's already done).

1. Project structure that triggers this: PHP+MySQL ERP with 15+ tables, snake_case DB columns

mapped to camelCase in JS, VPS deployment via SSH. The gap between what the model assumes and what
actually exists grows with project complexity.

## Quantified impact:

• 75 verification errors (user had to find the bug)
• 10 false audits ("all good" when it wasn't)
• 2 days production downtime
• 30 wrong column names in a single 1,700-line file
• Full session logs available if Anthropic wants to review them

## What makes this actionable:
The model HAS the tools to verify (Bash, SSH, SQL access). It just doesn't use them. A system prompt
addition like "After writing SQL queries, verify column names exist by running SHOW COLUMNS" would
likely fix 80% of these failures.

feedback_anthropic.md