Lenguajes aburridos para usar IA mejor

Si usas LLMs para escribir código, seguramente ya viste el patrón: a veces te devuelven una solución decente en segundos, y otras veces te entregan algo que compila, pero no encaja con tu base de código, tus convenciones o tus tests. El problema no siempre es la IA. Muchas veces es el contexto. Si tu stack cambia de forma impredecible, si mezclas patrones, si cada servicio tiene una forma distinta de hacer lo mismo, el modelo tiene más superficie para equivocarse.

Ahí entra una idea poco glamorosa, pero muy útil: usar lenguajes aburridos. No aburridos porque sean malos, sino porque son predecibles, estables, fáciles de leer y difíciles de malinterpretar. Cuando reduces rarezas del lenguaje y del stack, también reduces errores humanos, haces más confiables las revisiones y le das a la IA un terreno mucho más claro para trabajar.

Qué significa realmente un lenguaje aburrido

Un lenguaje aburrido no es un lenguaje sin valor. Es uno con sintaxis clara, reglas consistentes, pocas trampas y una comunidad que privilegia la estabilidad sobre la novedad. En la práctica, eso se traduce en menos sorpresas cuando tú lees código y también cuando un LLM lo genera. Si el modelo tiene que adivinar entre cinco formas distintas de hacer lo mismo, la probabilidad de que elija una mala sube rápido.

Piensa en esto con un ejemplo simple. Si tu equipo usa TypeScript con strict activado, interfaces explícitas y un formatter como Prettier, el espacio de soluciones aceptables se vuelve más pequeño. La IA no tiene que inventar tanto. Tú tampoco. Eso no significa que el código sea perfecto, pero sí que hay menos ambigüedad para revisar.

La documentación oficial de TypeScript insiste en que strict activa un conjunto de verificaciones que ayudan a detectar errores antes de tiempo. Puedes verlo en la guía oficial de TypeScript: https://www.typescriptlang.org/docs/handbook/2/basic-types.html y en la referencia de configuración: https://www.typescriptlang.org/tsconfig/#strict. No hace falta memorizar la lista completa para entender el punto: cuanto más explícito sea el tipo, menos margen queda para que la IA improvise.

Lo aburrido suele ser más fácil de revisar

Revisar código generado por IA no es solo leer si “funciona”. También tienes que ver si respeta el estilo del repo, si usa bien las abstracciones existentes, si no mete dependencias nuevas sin necesidad y si maneja errores como lo hace el resto del sistema. Un stack predecible hace que esa revisión sea más rápida.

Por ejemplo, si en tu backend todos los endpoints siguen el mismo patrón de validación, logging y respuesta, un PR generado por IA se vuelve más fácil de auditar. No necesitas descubrir el estilo del proyecto en cada archivo. Puedes concentrarte en la lógica real.

En equipos distribuidos en LatAm esto pesa todavía más. Si tienes personas trabajando desde Quito, Medellín, Lima o Ciudad de México, y cada quien interpreta el código de forma distinta, la revisión se vuelve lenta. Un lenguaje y un stack aburridos reducen esa fricción porque la intención del código se vuelve más evidente.

Por qué los LLMs se benefician de stacks predecibles

Los LLMs no entienden tu proyecto como tú. Predicen tokens a partir de patrones. Eso significa que cuanto más repetible sea tu base de código, mejor puede inferir qué viene después. No es magia, es estadística aplicada a texto técnico.

Si tu proyecto usa una sola forma de estructurar componentes, una sola forma de manejar errores y una sola forma de nombrar archivos, el modelo tiene más señales útiles. Si, en cambio, mezclas estilos de React, patrones de estado distintos y utilidades duplicadas, el LLM recibe ruido. Y cuando recibe ruido, suele compensar con generalidades.

Un stack aburrido también ayuda a que las respuestas sean más verificables. Si el modelo te propone un cambio en un archivo TypeScript y el diff es pequeño, tú puedes validar rápido si encaja con el contrato existente. Si te propone una reescritura grande y llena de abstracciones nuevas, ya no estás revisando una ayuda: estás revisando una migración disfrazada.

Menos decisiones, menos errores

Cada decisión extra que tu equipo toma en un PR es una oportunidad para equivocarse. Eso vale para personas y para modelos. Cuando reduces el número de decisiones, reduces el número de fallos posibles.

Un ejemplo concreto:

1. Definir una sola librería para validación de inputs.
2. Usar un solo formatter y un solo linter.
3. Evitar patrones duplicados para fetch, cache o manejo de errores.
4. Mantener nombres consistentes para funciones, rutas y módulos.
5. Bloquear versiones con lockfiles y revisiones de dependencias.

Con eso no eliminas los bugs, pero sí haces que el código generado por IA tenga menos lugares donde romperse. Si además usas tests automáticos, el margen de confianza sube todavía más.

Cuando el stack es raro, la IA también se confunde

Hay stacks que piden más interpretación que trabajo. Frameworks con convenciones poco claras, wrappers caseros alrededor de librerías conocidas y patrones inventados por el equipo hacen que el modelo tenga que inferir demasiadas cosas. A veces acierta. A veces te devuelve una solución que parece correcta, pero no respeta una regla interna que nadie documentó.

Eso pasa mucho cuando el proyecto creció rápido y cada feature dejó su propia huella. La IA no sabe cuál de tus tres formas de manejar auth es la “real”. Si tú tampoco tienes una fuente de verdad clara, el modelo termina rellenando huecos.

Una buena regla práctica es esta: si no puedes explicar el patrón en dos minutos, probablemente tampoco sea buen combustible para un LLM. Lo que para un humano ya es confuso, para una IA suele ser una apuesta.

Qué lenguajes y herramientas suelen funcionar mejor

No existe un lenguaje perfecto para todo. Pero sí hay lenguajes y herramientas que, por su diseño, tienden a ser más predecibles y más amigables para trabajar con IA. En general, te convienen opciones con sintaxis clara, tipado útil, tooling maduro y una comunidad grande.

TypeScript suele funcionar muy bien para frontend y backend porque combina tipado estático con un ecosistema enorme. Python también es fuerte cuando priorizas legibilidad y velocidad para prototipar. Go destaca por su simplicidad, compilación rápida y convenciones muy claras. Java sigue siendo útil en entornos grandes donde la estructura y la disciplina pesan más que la velocidad de escritura.

La clave no es elegir el lenguaje “más cool”. Es elegir el que te dé menos ambigüedad en el día a día. Si tu equipo ya trabaja con TypeScript y tiene buenas reglas de linting, probablemente sea mejor profundizar ahí que abrir otro frente con un stack exótico solo porque suena interesante.

No se trata de que uno sea universalmente mejor. Se trata de cuánto reduce la incertidumbre en tu contexto. Si el modelo puede inferir con facilidad cómo se organiza tu proyecto, tú recibes respuestas más útiles y menos genéricas.

TypeScript: útil si lo mantienes disciplinado

TypeScript puede ser excelente para trabajar con LLMs, pero solo si no le quitas sus dientes. Si terminas usando any por todas partes, el modelo también aprenderá que la rigidez del sistema es opcional. En cambio, con strict, tipos de dominio claros y componentes pequeños, la IA produce cambios más cercanos a lo que tú esperas.

Además, TypeScript ayuda a revisar. Un PR con tipos explícitos te deja ver más rápido qué datos entran, qué datos salen y dónde hay riesgos. Eso reduce el tiempo de lectura y mejora la calidad del feedback.

Python: bueno para velocidad, malo si lo dejas crecer sin orden

Python es fácil de leer y eso juega a favor. Pero si tu proyecto crece sin estructura, el mismo lenguaje que te ayudó a avanzar rápido puede volverse un cajón de scripts difíciles de mantener. Ahí el problema no es Python; es la falta de convenciones.

Si quieres usar IA con Python, te conviene reforzar el stack con linters, type hints y tests. La combinación de legibilidad más disciplina hace que el LLM tenga menos espacio para inventar nombres, estructuras o flujos raros.

Cómo hacer que la IA escriba mejor código en tu base real

La mejora no viene solo del lenguaje. Viene de cómo preparas el terreno. Si quieres que un LLM te ayude de verdad, tu repo debe parecerse menos a una colección de ocurrencias y más a un sistema con reglas claras.

Empieza por documentar patrones concretos. No un documento largo que nadie lee, sino ejemplos cortos: cómo se crea un endpoint, cómo se valida input, cómo se maneja un error, cómo se escribe un test. La IA responde mucho mejor a ejemplos que a descripciones vagas.

También ayuda mucho usar archivos de contexto o instrucciones del repo. Si tu equipo ya trabaja con herramientas que leen instrucciones locales, ahí puedes dejar reglas como “no agregues dependencias nuevas sin justificación” o “usa este helper para logging”. Eso acota la respuesta del modelo y hace más probable que su salida sea aceptable desde el primer intento.

Un flujo práctico que sí puedes aplicar

1. Define el patrón base del repo en un README corto o en instrucciones locales.
2. Mantén un formatter y un linter únicos para todo el proyecto.
3. Pide al LLM cambios pequeños, no refactors gigantes.
4. Obliga a que cada cambio pase tests unitarios o de integración.
5. Revisa primero la estructura y luego los detalles.
6. Si el modelo inventa una abstracción nueva, pregúntate si realmente la necesitas.

Ese flujo funciona porque limita el espacio de error. El LLM no tiene que resolver la arquitectura completa. Solo tiene que operar dentro de una caja bien definida.

Si quieres una referencia sobre cómo documentar decisiones técnicas sin sobrecargar a tu equipo, la documentación oficial de Python sobre style y typing puede servirte como ejemplo de claridad: https://peps.python.org/pep-0008/ y https://docs.python.org/3/library/typing.html. No porque Python sea el único camino, sino porque muestra cómo una convención clara simplifica la lectura y la automatización.

Lo que gana tu equipo cuando baja la complejidad

El beneficio no es solo técnico. También es operativo. Cuando tu stack es predecible, las PRs se revisan más rápido, el onboarding se acorta y los errores por interpretación bajan. Eso se nota en equipos pequeños y más todavía cuando el equipo crece.

En una startup de LatAm, donde muchas veces una misma persona toca frontend, backend y algo de infraestructura, un lenguaje aburrido puede ser una ventaja real. No porque haga el trabajo por ti, sino porque reduce la carga mental. Si además usas IA para acelerar tareas mecánicas, el combo funciona mejor cuando el sistema no pelea contra ti en cada archivo.

También hay un efecto cultural. Un stack estable empuja al equipo a discutir mejor las excepciones. En vez de debatir cada semana si ahora usaremos otro patrón para lo mismo, puedes concentrarte en problemas de negocio, performance, observabilidad o costos. La IA ayuda más cuando el equipo ya resolvió lo básico.

Tabla resumen

La idea central es simple: si quieres que la IA te ayude a producir mejor código, no le des un entorno caótico. Dale un lenguaje y un stack donde las reglas sean visibles, repetibles y fáciles de validar. Lo aburrido, en ingeniería, suele ser lo que mejor escala.