[GN] No desarrollador + Claude en producción durante 238 días — ¿qué funcionó y qué no?

(chajooin.com)

7 puntos por workdriver 2026-04-12 | 5 comentarios | Compartir por WhatsApp

Soy el operador que creó chajooin.com. Terminé la preparatoria, llevo 8 años en camiones de carga (desde 2017). Sin saber escribir ni una sola línea de código, hice mi primer commit con Claude el 16 de agosto de 2025. Han pasado 238 días, y hoy este servicio recopila datos automáticamente todos los días y publica reportes.

Este texto no es el registro de "lo hice", sino de "lo hice y lo sigo operando". Hay muchas reseñas de prototipos hechos con vibe coding, pero son raras las experiencias de mantener una operación en producción, así que por eso lo escribo. No es una historia de éxito, sino un registro honesto de lo que funcionó y lo que no.

Contexto

Dominio: comparación de precios de mercado de camiones de carga (mercado de 17 billones de wones, sin registro oficial de precios reales de transacción)
Intento anterior: en 2024, outsourcing llave en mano por 30 millones de wones → lo abandoné porque el control de las modificaciones estaba del lado del proveedor
Cambio: 2 meses aprendiendo IA en julio de 2025 → primer commit el 16 de agosto

Stack

Frontend    Vite + React + TypeScript + Tailwind  
Backend     Node.js + Express + Prisma  
DB          PostgreSQL (Railway managed)  
수집        Playwright (headless) + 46 parsers por fuente  
ML          LightGBM (Python, 75 features)  
배포        Railway (Docker)  
자동화      Node scheduler + alertas por Telegram  
AI 협업     Claude (desarrollo principal) + GPT-4o (guiones de shorts/prompts)  
인증        Naver/Kakao OAuth

No fue que "elegí" el stack. Le pregunté a la IA: "¿qué hay que usar para construir esto?" y usé lo que me dio. Después vi que era una combinación razonable. El valor práctico de un agente de IA: asume por ti la carga cognitiva de tomar decisiones.

Números (2025-08-16 ~ 2026-04-12)

Ítem	Valor
Commits totales	3,493
Días con commits	189 días
Cantidad de archivos de código	aprox. 1,500 (js/ts/py)
Rollbacks	20+
Fallas de despliegue	39 (los dos primeros días de setup en Railway)
Máximo de repeticiones del mismo bug	7 veces (unidad de precio)
Publicaciones activas	aprox. 48,000 unidades
Parsers de fuentes externas	46
CLAUDE.md	187 líneas, 24 reglas absolutas
Archivos de memoria	129

Parte 1. Construcción — 3 cosas que sí lograron hacerlo funcionar

1.1 CLAUDE.md — controlar la IA con reglas

Si el mismo bug explota dos veces, decir "ten cuidado" no sirve de nada. Hay que escribir reglas concretas en un archivo y hacer que la IA las lea al inicio de cada sesión.

"parser=origen → normalización=÷10,000 → DB=10 mil wones. Prohibido ×10,000 sobre valores de la DB"  
"Si falla la extracción del año del modelo en el parser, prohibido asignar getFullYear()"  
"Prohibido agregar kakaotalk al UA rewrite de vercel.json"  
"El valor de setInterval debe limitarse con Math.min(value, 2^31-1)"

Ahora mismo son 24 reglas. Todas nacieron después de incidentes reales.

1.2 Separación de roles — la planificación y el criterio son humanos, la implementación es de la IA

Aunque no pueda leer código, sí puedo juzgar resultados. Si un Porter de 2 toneladas aparece en 5 millones de wones, puedo decir "esto está mal"; si un wing body y un cargo salen con el mismo precio, puedo decir "sepáralos". El sentido del dominio cumple el rol de prueba.

1.3 Archivos de memoria — mantener contexto entre sesiones

Acumulé decisiones, fallos y políticas en 129 archivos de memoria. Cuando se abre una nueva sesión, se leen las memorias relacionadas para mantener criterios del pasado. Es una estructura que compensa los límites de la ventana de contexto de la IA con el sistema de archivos.

Parte 2. Operación — problemas distintos a los de construir

2.1 Cosas que están corriendo automáticamente

Ingesta de publicaciones: el scheduler recopila datos de fuentes externas → quality gate → reflejo en la DB
Reportes de precios de mercado: generación automática diaria → publicación automática en blog/café
Generación de guiones para shorts: GPT-4o genera guiones/prompts para Sora por tonelaje (la composición de video es una etapa aparte)
Reentrenamiento de ML: reentrenamiento semanal del motor de precios con datos nuevos
Monitoreo: alertas por Telegram cuando hay anomalías en el pipeline

Soy el único desarrollador.

2.2 Costos

Infraestructura: Railway (PostgreSQL + Node + Playwright)
API de IA: suscripción a Claude (para desarrollo) + API de GPT-4o (para generar shorts, estimado de alrededor de $1 al mes con base en api_usage_log)
Dominio/OAuth: Naver/Kakao

2.3 Registro de respuesta a incidentes

Contaminación de datos en 1,138 casos (2/3): se detectó bug en el fallback del año del modelo → parche en la DB + pipeline de reprocesamiento + regla nueva
Alertas de Slack sin funcionar durante 6 meses (detectado el 18/3): problema de variables de entorno/rutas → reestructuración para unificar todo en una sola ruta por Telegram
Overflow de 32 bits en setInterval (10/4): login inutilizado → hotfix + regla de clamping agregada
Pantalla en blanco en KakaoTalk (31/1): el UA rewrite de SEO también atrapaba el navegador in-app de KakaoTalk → corrección de la lista de UA

2.4 Extracto de reglas de operación

CLAUDE.md también incluye reglas desde la perspectiva operativa.

"Después del despliegue, reportar con 3 números: estado del servidor (health 200),  
 cantidad de crawls de hoy (dentro de ±20% de ayer), cantidad de publicaciones activas (sin cambios bruscos)"  
  
"Si se modifican 4 o más archivos, si se conecta al scheduler, si se cambia el esquema de la DB,  
 o si se vuelve a modificar un área previamente revertida → reporte previo obligatorio"  
  
"Los cambios temporales (fallback/TODO/hardcoding) deben registrarse en una bitácora:  
 qué debe revertirse y para cuándo, y qué se romperá si no se revierte"

La IA lee estas reglas cada vez y, cuando se presenta una de esas situaciones, reporta primero antes de trabajar.

Parte 3. Lo que no funcionó

3.1 El mismo bug repetido 7 veces — no ve todo el recorrido de los datos

La razón por la que el bug de la unidad de precio explotó 7 veces: si solo corriges uno de los 6 pasos —recolección → parser → normalización → DB → API → UI— vuelve a aparecer por otra ruta. La capacidad de "ver el sistema completo" es lo que más le falta a la combinación no desarrollador + IA. La IA solo corrige donde se le indica, y la persona ni siquiera sabe que existen otras rutas.

3.2 Contaminación de datos en 1,138 casos — los valores por defecto "amables" de la IA

Cuando el parser no lograba extraer el año del modelo, se metió código que devolvía getFullYear(). Desde la perspectiva de la IA, seguramente pensó que "el año actual es mejor que null". Resultado: Porters modelo 2003 quedaron grabados en la DB como modelo 2026. Si no le escribes explícitamente a la IA "si no sabes, usa null", va a rellenar algo.

3.3 Alertas de Slack sin funcionar durante 6 meses — no vigilar el sistema de vigilancia

La alerta terminaba en fallo, y el propio fallo no quedaba en logs, así que pasaron 6 meses en silencio. Durante ese tiempo hubo varias anomalías en el pipeline, pero yo creía que "no había problema". En un sistema hecho con IA, el estado más peligroso es el que 'parece estar funcionando bien'. Ahora lo simplifiqué a una sola ruta por Telegram.

3.4 Overflow de 32 bits en setInterval — trampa del lenguaje

Si no sabes que setInterval solo acepta int32, no sabes que meter 30 días en milisegundos hace que se ejecute de inmediato. El login dejó de funcionar. La IA no te advierte espontáneamente sobre estos edge cases. La regla de clamping apareció solo después de que explotó.

3.5 Overfitting en ML — MAPE de entrenamiento 8.56% vs 42% en producción real

Con 75 features en LightGBM logré un MAPE de entrenamiento de 8.56% y pensé "ya quedó". En operación real fue 42%. La razón: límites estructurales de los datos de precio de oferta (ausencia de precios reales de transacción, contratos declarados por debajo, margen del dealer). Un experto del dominio lo habría sabido desde el principio, pero yo me quedé atrapado en la idea de que "si el resultado de entrenamiento es bueno, basta".

Reflexión final

Si resumo estos 238 días:

La IA acelera muchísimo la velocidad de implementación. Incluso alguien que no sabe programar puede crear un servicio funcional.
Pero la calidad operativa no viene automáticamente con eso. Los incidentes ocurren sin excepción, y la IA no te advierte por iniciativa propia.
El trabajo del no desarrollador se desplaza de escribir código a diseñar reglas, vigilancia y validación. Juzgar resultados y evitar reincidencias se vuelve el trabajo principal.

Es una producción operada por una sola persona, así que la muestra es n=1. No quiero generalizar. Me interesa saber cómo ha sido la experiencia de otros en condiciones similares.

Enlace

Servicio: https://chajooin.com (comparación y análisis de precios de mercado de camiones de carga)

Agradezco sus comentarios. En especial, me interesa saber cómo vigilan en solitario ese estado que 'parece estar funcionando bien'.

5 comentarios

savvykang 2026-04-13

Creo que el problema de estado que parece estar funcionando bien podría mitigarse hasta cierto punto si se hacen periódicamente simulacros de recuperación ante fallas y se define qué características de los datos se consideran normales.

workdriver 2026-04-13

Sí, gracias por la buena opinión.
Es cierto que, a medida que el sistema crece, se vuelve difícil de administrar.