No es una filosofía, es simplemente lo que he aprendido operando siete sistemas en producción casi en solitario.
01 Primero planeo en lenguaje sencillo
Antes de escribir una sola línea de código o un prompt, redacto el plan tal como se lo explicaría a
mi socio: sin jerga, sin arquitectura dada por hecho. Si no puedo describir en oraciones sencillas lo
que un sistema debe hacer, no estoy listo para construirlo. Ese plan se convierte en la especificación
que le entrego al modelo, y es lo primero que reviso cuando algo falla: casi siempre el error está en
que el plan estaba mal, no el código.
02 Delego la investigación, reservo el criterio para lo que importa
Opero la mayoría de mis sistemas con Claude Code, y he aprendido a tratar la elección de modelo como
un presupuesto. Los modelos baratos y rápidos hacen la investigación: revisan sitios web de condados,
resumen páginas extraídas, verifican si el resultado de un scraper se ve correcto. Reservo el modelo
caro, de razonamiento profundo, para las decisiones que de verdad requieren criterio: arquitectura,
compensaciones de calidad de datos, cualquier cosa donde equivocarse salga caro de corregir. Esa
división es lo que le permitió a una sola persona construir y mantener 27 motores específicos por
condado sin quemar tiempo ni dinero sin límite.
03 JSON es la fuente de verdad, los archivos generados son desechables
Cada pipeline que opero guarda su estado real en datos estructurados (JSON, una hoja de cálculo, una
base de datos), nunca en las variables locales de un script de un solo uso. Los scripts, paneles y
reportes se regeneran a partir de esos datos cuando quedan desactualizados; nunca edito a mano un
archivo de salida, porque la siguiente ejecución lo sobrescribiría de todos modos. Esa disciplina es
lo que permite borrar y reconstruir casi cualquier cosa en estos sistemas sin perder información real.
04 Construyo para la persona que no es técnica
Mi socio y los operadores que usan estas herramientas día a día no son desarrolladores, y no deberían
tener que pensar como uno. El pipeline de llamadas está escrito únicamente con la biblioteca estándar
de Python, a propósito, para que una actualización rutinaria de dependencias nunca rompa una
herramienta de la que depende una persona no técnica para hacer su trabajo. Los paneles de leads son
un mapa con toques y clics, no una consola de base de datos. Si una herramienta necesita manual de
uso, para mí eso es un error.
05 Automatizo pensando en la falla, no solo en el éxito
Todo lo que corre sin supervisión eventualmente va a fallar sin supervisión: un sitio cambia su HTML,
una API limita las peticiones, una tarea programada no se dispara y nadie se entera. Diseño para eso
desde el inicio: ejecuciones que se pueden reintentar sin riesgo, registros que dicen lo que realmente
pasó, y tareas programadas que retoman solas en vez de requerir que alguien lo note y las reinicie.
Esa es la diferencia entre una demo y un sistema del que tres personas dependen todos los días.