Kristian Polso, el ingeniero que rechaza la IA al programar

Un ingeniero con 10 años de machine learning deja los LLM

El 8 de noviembre, el desarrollador finlandés Kristian Polso publicó en su blog una decisión poco común en 2026: dejará de usar LLM y agentes de IA en todo su trabajo profesional. No es un recién llegado que desconfía de la tecnología. Polso lleva alrededor de una década construyendo implementaciones de machine learning en producción para clientes, incluyendo modelos de reconocimiento de imágenes con CNN en Keras y modelos de predicción de calidad del aire en TensorFlow.

Su post aterriza en una industria con una contradicción medible. Según una encuesta informal de SD Times a 103 desarrolladores, el 87% ya usa o planea adoptar asistentes de código con IA, pero solo el 31% confía en la exactitud de lo que generan y apenas un 4% declara confianza alta.

Esa brecha entre uso y confianza es la historia real detrás del post. Polso la lleva al extremo: si no confías en el output, ¿por qué delegarle tu trabajo?

Leíste lo que hace la IA. ¿Y en tu negocio?

Un agente de IA puede quedarse con parte de tu día: ordenar lo pendiente y pedirte el OK antes de actuar. El Kit «tu mano derecha con IA» trae un video de 11 minutos y una ficha para dejar al tuyo trabajando. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

Los seis motivos que lo llevaron a decir no

Polso enumera sus «dealbreakers» sin ambigüedad. Estos son los ejes de su argumento:

Impacto cognitivo. Menciona el «LLM brainfog» que escucha entre colegas y cita tres estudios: uno de Microsoft sobre reducción autoinformada del esfuerzo cognitivo en trabajadores del conocimiento, otro sobre la acumulación de «deuda cognitiva» al usar asistentes de IA para escribir ensayos, y un tercero que describe a los LLM como un «virus cognitivo». Su experiencia personal: tras horas de uso, se siente desorientado y confundido.
Calidad del output. Su crítica más concreta apunta al código verboso, lleno de comentarios y tests por todas partes, que «parece impresionante a primera vista». Cuenta que en su trabajo ha tenido que revisar código generado por Claude que construía algo completamente nuevo cuando bastaban unas pocas líneas de cambios de esquema y migraciones. Su conclusión: los LLM exponen la brecha de alfabetización entre programadores buenos y mediocres.
Mantenibilidad. Si todo el código lo escriben agentes, en algún punto ningún humano entiende qué pasa. Su frase textual: «Felicitaciones, dejaste que OpenAI, Anthropic o Elon Musk dicten qué hace tu código y por qué».
Le gusta escribir código. Dice que escribir es parte de su proceso de resolución de problemas, y que leer código ajeno le permite entender cómo piensa la persona detrás.
Ambiente. Apunta al consumo eléctrico de los datacenters de IA y al caso finlandés.
Política y cumplimiento. Le incomoda que su trabajo lo ejecuten empresas estadounidenses, y señala el ángulo de protección de datos: como ciudadano de la UE, recuerda que el CLOUD Act permite a las autoridades federales de EE. UU. acceder a datos almacenados en cualquier parte del mundo, incluso si el proveedor promete que los datos se quedan en la UE.

También reconoce un uso positivo: cuando está completamente atascado en una implementación, articular una pregunta a un agente le da un plan de ejecución coherente. Pero concluye que la ayuda no compensa el resto de los problemas.

¿Una opinión aislada o una tendencia medible?

Los datos del sector sugieren que el malestar de Polso no es una rareza.

La Stack Overflow 2026 Developer Survey, con 30.903 desarrolladores en 169 países, encontró que casi la mitad se declara complaciente en su trabajo actual, un tercio infeliz y apenas algo más del 22% feliz. Entre los complacientes, el agotamiento o la fatiga tecnológica fue la razón principal, citada por el 21%. Casi dos tercios usan asistentes o agentes de IA para programar, y el 62% usa herramientas de chat de propósito general. Entre quienes usan IA a diario, el 31% le dedica cuatro horas o más. Y menos del 10% estaría dispuesto a confiar en la IA para decisiones importantes, mientras casi el 80% considera importante o muy importante la atribución de fuentes al evaluar código generado.

El Linux Foundation, en un informe publicado en octubre de 2026, encontró que la IA generativa mejora la productividad hasta un 50% en tareas de desarrollo open source, pero también que el 25% de los pull requests entrantes se estiman de baja calidad —»AI slop»—, porcentaje que sube al 31% en proyectos grandes.

Ahí está el costo que Polso describe desde la trinchera: la velocidad que gana quien escribe el código la paga quien lo revisa. Y en la encuesta de SD Times, solo el 13% de los desarrolladores cree que los agentes de IA mejoraron la colaboración en equipo, mientras el 58% mantiene una opinión favorable de estas herramientas, una caída frente al más del 70% de años anteriores.

El argumento ambiental y el caso finlandés

Polso menciona que en Finlandia las noticias estuvieron dominadas por Google talando cientos de hectáreas de bosque sin permiso para construir un datacenter. Los hechos documentados son más precisos: las autoridades finlandesas ordenaron a Google detener los trabajos preparatorios en dos sitios de datacenters —Muhos y Otanmäki, en la zona de Kajaani— tras talar grandes áreas de bosque sin completar las evaluaciones de impacto ambiental requeridas. La orden, emitida el 6 de octubre por la agencia LVV, se dirigió a Tuike Finland Oy, la subsidiaria del proyecto.

Según información pública, se talaron unas 740 acres (300 hectáreas) solo en el sitio de Muhos, y reportes que citan a ecologistas de la Asociación Finlandesa para la Conservación de la Naturaleza estiman cerca de 400.000 árboles en ambos sitios. Más de 93.000 personas firmaron una petición pidiendo una regulación más estricta de datacenters. Google había anunciado semanas antes una inversión de al menos 13.000 millones de euros en infraestructura de IA en Finlandia para 2027 y 2028.

El contexto global no ayuda: según CNET, Amazon, Microsoft y Google controlan el 59% de la capacidad de datacenters hyperscale, y Google reportó un aumento del 50% en sus emisiones de gases de efecto invernadero en 2024 para sostener su IA generativa.

¿Qué significa esto para tu startup?

La decisión de Polso es personal, pero las tensiones que describe son operativas. Estas son las que un founder puede medir en su propio equipo:

Mide el costo de revisión, no solo el de los tokens. Si el 25% de los pull requests que llegan son de baja calidad, tu equipo está gastando horas en revisión que no aparecen en ninguna factura de API. Instrumenta cuánto tiempo dedica tu gente a revisar código generado frente a escribirlo.
Define una política de atribución y divulgación antes de que sea un problema. Casi el 80% de los desarrolladores considera importante la atribución de fuentes al evaluar código generado. Si tu equipo no sabe qué partes del código salieron de un agente, tampoco podrá auditarlas después.
Separa velocidad de prototipado de código de producción. Usa IA para explorar y desatascar, pero exige revisión humana explícita en lo que toca seguridad, arquitectura y lógica específica del negocio: son justamente las áreas donde estas herramientas siguen fallando según los propios datos del sector.
No conviertas el uso de IA en una obligación. El agotamiento fue la razón principal de insatisfacción para el 21% de los desarrolladores complacientes. Forzar la adopción sobre un ingeniero senior que prefiere escribir su propio código puede costarte a la persona que mejor entiende tu sistema.
Si operas en la UE, revisa dónde se procesan tus datos. El punto del CLOUD Act que plantea Polso no es menor para startups que venden a clientes europeos y prometen residencia de datos en la región.

Conclusión

El post de Polso no es un manifiesto contra la tecnología: es el testimonio de alguien que la entiende y decidió que el intercambio no le conviene. Lo valioso para un founder no es su conclusión, sino el mapa de costos que deja sobre la mesa: revisión, mantenibilidad, dependencia de proveedor, consumo energético y desgaste del equipo.

La adopción de IA en desarrollo ya no está en discusión —el 87% la usa o planea usarla según SD Times—, pero la confianza sí. Mientras esa brecha siga abierta, la ventaja competitiva no estará en usar más IA, sino en saber exactamente dónde usarla y dónde no.