no necesitas un modelo más inteligente, necesitas ser más inteligente

Capítulos

Voy a empezar confesando un vicio mío: durante meses, cada vez que un proyecto se trababa, mi primera reacción era cambiar de modelo. ¿DeepSeek alucinó? Probemos Gemini Flash. ¿Flash se puso tonto en contexto largo? A probar GPT 5.5. ¿El 5.5 se comió mi cuota? Está Luna, hay promo, hay cuota gratis aquí y allá. Coleccionaba LLMs como quien colecciona destornilladores creyendo que el problema es la herramienta — cuando en realidad intentaba armar un mueble sin leer el manual. Que yo mismo nunca había escrito.

Este texto es un rant, pero un rant con cariño. Porque yo era exactamente la persona a la que aplica.

El síntoma: cambiar de modelo

Fíjate en el patrón: el código sale mal, y la conclusión es “necesito un modelo más inteligente”. Casi nunca es “necesito pensar mejor lo que estoy pidiendo”. Un modelo débil con un proyecto bien pensado produce más que un modelo fuerte pastando en un repositorio sin rumbo. Lo sé porque probé de las dos formas, varias veces, y el segundo escenario me hizo perder más tiempo del que me gustaría admitir.

Funciona así: sin requisitos claros, sin arquitectura, sin contexto, el agente — cualquier agente, el más barato o el más caro — rellena los huecos con adivinanza estadística. Y adivinanza estadística sobre un proyecto confuso genera código confuso con mucha confianza. Entonces cambias de modelo y obtienes una versión distinta del código confuso. Parece progreso. No lo es.

La pregunta que cambió mi juego fue simple: ¿y si el cuello de botella no es la inteligencia del modelo, sino la calidad de lo que le entrego para masticar?

Pensar antes de programar

Antes de abrir el editor, hoy me obligo a responder por escrito: qué resuelve este proyecto, para quién, qué queda fuera del alcance, qué fronteras no se pueden romper y cuál es el experimento más pequeño que prueba la idea. Parece burocracia. En la práctica es lo contrario: es lo que me deja programar rápido después, porque las decisiones difíciles ya se tomaron con la cabeza fría.

Cada proyecto mío pagó esa lección a su manera. En Petunia3D, tardé en separar el renderer 3D de la interfaz — y cada semana sin esa frontera generaba acoplamiento que después costaba días deshacer. En HummTube, decidir “local-first, sin cuenta obligatoria” antes del código definió la base de datos, el sync (que no existe) y la mitad de la arquitectura gratis. En TidyFlow, los requisitos de “mostrar lo que pasó, lo que está corriendo y lo que va a correr” se convirtieron en toda la interfaz. Ninguna de esas decisiones vino de un modelo más inteligente. Todas vinieron de pensar antes.

Las tecnologías entran en la misma cuenta. Comparo la opción obvia, una o dos alternativas y algo experimental — y elijo la que encaja en las restricciones de este proyecto, no la “mejor” en abstracto. Stack no es religión, es respuesta a restricciones. Cuando sabes cuáles son tus restricciones, hasta un modelo barato acierta.

Documentación para dos públicos

Aquí va la parte que más me entusiasma: la buena documentación ya no es solo un favor para mi yo del futuro. Alimenta a dos públicos a la vez — humanos y agentes de código. Y lo interesante es que lo que ayuda a uno ayuda al otro: fronteras explícitas, decisiones con motivo registrado, ejemplos pequeños y completos, contratos claros.

Fue en esa senda que Prumo evolucionó. La idea central — repositorio como fuente de verdad, estado canónico en Markdown y Git, adapters por herramienta — creció mucho cuando estudié el ai-memory de Akita. Su proyecto resuelve el mismo tipo de dolor desde otro ángulo: memoria de largo plazo para agentes, handoff entre herramientas distintas, wiki en Markdown puro que se puede leer con grep, sin ceremonia. Ver a alguien con experiencia llegando a conclusiones parecidas (fuente de verdad en archivos comunes, handoff como protocolo y no como convención) me dio confianza de que iba en la dirección correcta — y varias buenas ideas para robar con orgullo citando la fuente, como estoy haciendo ahora.

Arquitectura de proyecto y arquitectura de documentación, para mí, se volvieron la misma disciplina: decidir qué existe, dónde vive, quién puede cambiarlo y cómo se descubre sin preguntar a nadie.

Seis meses de Ori-lang

Nada me enseñó “planificación estratégica primero” como pasar seis meses diseñando un lenguaje de programación. En Ori, cada decisión sintáctica arrastra consecuencias al parser, los tipos, el codegen y el tooling — equivocarse al inicio cuesta meses al final. Me vi obligado a desarrollar el músculo de pensar antes: especificación abierta, manifiesto, cada feature justificada por escrito antes de existir.

El efecto colateral fue genial: ese músculo se filtró a todos los demás proyectos. Hoy me resulta extraño empezar cualquier cosa sin un documento de una página diciendo qué es, qué no es y cómo sabré si funcionó. Hace seis meses pensaba que eso era exquisitez. Hoy creo que es el motivo por el que puedo llevar seis proyectos a la vez sin enloquecer — bueno, sin enloquecer demasiado.

Manual de estrategia de un dev con IA pobre

Vamos a lo práctico, porque rant sin táctica es solo desahogo. Desarrollo gastando lo mínimo posible, y funciona — siempre que la planificación haga el trabajo pesado. El manual, probado a las malas:

Modelo débil + contexto fuerte vence a modelo fuerte + contexto débil. Un DeepSeek Flash o un Gemini Flash con requisitos claros, ejemplos y fronteras definidas entrega más que un tope de gama adivinando. El contexto es el multiplicador; el modelo es solo la base.

Usa cada modelo para lo que hace barato. Borradores y exploración en los baratos y en las cuotas gratis; revisión y decisión final donde vale gastar. Corro el grueso en lo barato y guardo los créditos para los momentos que de verdad necesitan fuerza bruta.

Aprovecha todo lo gratis sin culpa. Cuotas de OpenCode, freebuff, Antigravity, promos de planes, tiers gratuitos — todo eso es presupuesto de experimentación. El truco es experimentar barato y decidir caro: probar ideas en lo gratuito, consolidar en lo pago cuando (y solo cuando) la idea probó valor.

Documentación es ahorro directo. Cada decisión registrada es una ida y vuelta menos con el agente. Cada ejemplo canónico es un prompt menos que escribir. Pago minutos escribiendo contexto y ahorro horas — y dólares — de generación.

Prototipo desechable antes del camino oficial. Antes de comprometer la arquitectura, un experimento pequeño y jugable responde más que diez discusiones. Barato de correr, barato de tirar.

Nada de esto exige el modelo del momento. Exige pensar antes — que, por suerte, sigue siendo gratis.

Akita ya avisó

Si algo aquí te sonó familiar, es porque Akita lleva años martillando estas ideas: aprender a aprender, no tercerizar decisiones, soportar la incomodidad en vez de cazar fórmulas mágicas. El video de abajo es su famoso rant sobre el tema — una hora de regaño necesario (en portugués), y una de las inspiraciones para dejar de buscar atajos y empezar a construir cimientos:

Al final, todo el rant cabe en una frase, y es el título del texto: no necesitas un modelo más inteligente. Necesitas llegar al modelo — cualquier modelo — ya siendo más inteligente sobre tu propio proyecto. Planifica primero, documenta siempre, decide con trade-offs sobre la mesa. Lo demás es consecuencia. Y si duele un poco al inicio, genial: como diría Akita, si no duele, no estás intentándolo con suficiente fuerza.