La ilusión del Copilot - The Copilot Delusion

 (deplet.ing)
37 puntos por GN⁺ 2025-05-25 | 25 comentarios | Compartir por WhatsApp
  • La creencia de que las herramientas de programación con IA realmente aumentan la productividad del desarrollo es un malentendido
  • Estas herramientas dañan el placer de programar y la profundidad de comprensión humana
  • La IA puede servir para la generación repetitiva de código, pero tiene debilidades en contexto, rendimiento y matices
  • La dependencia excesiva reduce la voluntad de aprender y explorar, y la calidad del código de los desarrolladores
  • Crece el problema de que la esencia de la profesión de programador desaparece gradualmente por la comodidad que ofrece la IA

Introducción: la ilusión sobre las herramientas de programación con IA

  • Este texto aborda la realidad de las herramientas de generación de código con IA a mayo de 2025
  • La discusión sobre la incompetencia de la IA puede perder fuerza con el tiempo, pero se prevé que el problema del deterioro de la esencia y el disfrute de programar se vuelva aún más grave

Capítulo 1: Mi colega, el programador

  • Se pone como ejemplo la experiencia de trabajar con desarrolladores no profesionales que copian y pegan código de forma irresponsable, y se enfatizan los problemas que dejan estos colegas: degradación del rendimiento / bombas de errores / desprecio por la arquitectura
  • Estos colegas modifican código continuamente sin pruebas, profiling ni comprensión del contexto, y al final terminan quitándole al equipo la motivación y las ganas de aprender
  • Mediante la confesión sorpresiva de "Captain Obvious", se revela que en realidad esta descripción es una sátira sobre herramientas de programación con IA como GitHub Copilot, Claude Codex y otras
  • Un verdadero copiloto de avión entiende el sistema completo, colabora y asume responsabilidad. En cambio, los Copilot de IA solo dejan código superficial sin comprensión esencial
  • Tomando prestado solo el nombre de "Copilot", se están imponiendo en los IDE de todos los desarrolladores bajo la fachada de productividad e innovación

Capítulo 2: Ventajas de Copilot

  • Las herramientas de programación con IA no son completamente inútiles
  • Son útiles cuando un principiante solo quiere familiarizarse con sintaxis complejas de lenguajes como C++, o consultar rápidamente algún concepto
  • Para brainstorming, organización del contexto y código de plantilla repetitivo, son más rápidas y cometen menos errores que un practicante humano
  • Está claro que no consideran en absoluto el rendimiento ni la eficiencia, y que existe el riesgo de un desastre en la calidad de producción si se las deja sin supervisión cercana
  • Pueden ofrecer rápidamente scaffolding o código borrador sin contexto, pero el diseño completo y el ajuste fino siguen siendo tarea del desarrollador humano

Capítulo 3: Yo como desarrollador y la IA

  • El autor valora el placer de programar en sí mismo y la satisfacción de construir algo directamente
  • Si se le delega a la IA el código repetitivo (boilerplate) y además se renuncia a implementar por cuenta propia bibliotecas o macros, al final desaparecen la creatividad y la motivación interna del desarrollador
  • La dependencia de Copilot por FOMO (miedo a quedarse atrás) provoca que se produzca rápidamente código tosco y no verificado
  • La dependencia de la IA arrebata oportunidades de aprendizaje real y de comprender el rendimiento de bajo nivel, la estructura y el control de calidad del código
  • El nombre "Copilot" no representa a un colega en igualdad de condiciones, sino que se parece más a la fantasía de un gamer con poca experiencia creyendo que puede pilotar un avión

Capítulo 4: La computadora es una máquina

  • La capacidad de entender la realidad y la estructura de la máquina (hardware), y sus características de rendimiento solo existe en los humanos
  • La IA no tiene intuición ni experiencia directa sobre cache misses reales, layout de memoria, profiling o cuellos de botella de rendimiento
  • Las respuestas que da la IA están desconectadas del contexto y son inútiles en áreas donde se necesita optimización específica
  • Incluso al crear una aplicación CRUD común y corriente, el desarrollador debe tener respeto y responsabilidad hacia los usuarios y el sistema
  • La profesionalidad y el oficio se forman a partir de la experiencia directa, el sufrimiento y la mejora repetida

Capítulo 5: Conclusión

  • Las herramientas de programación con IA y su accesibilidad provocan la desaparición del espíritu hacker
  • Se expresa preocupación por un fenómeno en el que solo quedan en la industria usuarios pasivos sin interés real en el código, la estructura o el rendimiento
  • Antes había curiosidad y creatividad puras, con noches enteras en IRC, experimentos de hardware y exploración de bajo nivel
  • Ahora solo queda un trabajo mecánico y desinterés centrado en repetir la "revisión de parches de IA"
  • Se advierte del riesgo de que la generación de código sin comprensión del contexto ni capacidad real se vuelva el estándar de la industria, y de una realidad en la que los verdaderamente competentes quedan desplazados

Historial de edición del texto

  • Se agregó un descargo sobre la fecha de redacción
  • Reflejando opiniones de HN, se aclaró la postura sobre el alcance de la crítica al rendimiento (sistemas complejos vs. CRUD)
  • Se ajustaron parcialmente el estilo de las oraciones y el uso de símbolos para facilitar la lectura

Lecturas relacionadas

25 comentarios

 
roxie 2025-05-27

El texto es entretenido, pero me está cansando un poco que tantos artículos parezcan resumirse en: “no usar IA no es la solución para todo, pero tampoco está bien confiar ciegamente en ella y dejarse domesticar”..
 
ifmkl 2025-05-26

Los LLM y la IA han ido mejorando con el tiempo. Hace apenas unos meses era difícil esperar algo como consistencia en el código tal como se pedía, pero ahora, si subes como archivos el código solicitado en la configuración inicial dentro de ese espacio y le das instrucciones de que, al escribir código nuevo, siempre respete el estilo del código existente, termina generando código bastante consistente.
 
crawler 2025-05-26

Viendo las publicaciones anteriores del autor, parece que es desarrollador de videojuegos.
Como los LLM no han podido entrenarse masivamente con conocimientos o materiales de desarrollo de videojuegos, a diferencia de los casos de apps CRUD, da la impresión de que el autor del texto percibe mejor las limitaciones de los LLM.

Lo leí completo y, al final, creo que precisamente por esto el autor tiene una perspectiva un poco sesgada.
Claro, hacer las cosas como dice el texto es casi de manual, así que no está mal,
pero creo que la IA ya lo hace suficientemente bien en CRUD y frontend, donde sí hay mucho material para entrenarse.
Parece que hay que aprovecharla lo mejor posible dentro del propio dominio.
 
superscv 2025-05-26

Creo que hay un pequeño malentendido sobre el sentido que quiso dar el autor.
El autor está enfocado en el rendimiento, la estabilidad, y en una arquitectura y consistencia de código que faciliten el mantenimiento del proyecto que él mismo gestiona; y, justamente, la arquitectura y la consistencia del código son una de las áreas en las que los LLM actuales realmente son muy malos.

En particular, en la web entra muchísima gente al desarrollo y está muy arraigada la idea de que “si de alguna forma funciona, ya está”, así que se despliega una enorme cantidad de código de baja calidad. Y como los LLM se entrenan sobre esa base, la calidad de sus resultados cae a un nivel ridículamente bajo.

Simplemente, pídanle a GPT: "Lo voy a usar en el frontend web, así que impleméntame en js un algoritmo de quicksort". Si no pueden encontrar problemas en lo que devuelve, creo que esta conversación no tiene mucho sentido.
 
ohnul 2025-05-26

Hola. Por curiosidad, probé con: "Lo voy a poner en el frontend web, así que por favor implementa el algoritmo quicksort en js". Pero, por lo que veo, me cuesta saber exactamente cuál es el problema. Si me lo pudieran explicar, sería de gran ayuda. Muchas gracias de antemano. https://chatgpt.com/share/68340f9b-b684-8002-8dd5-495d477065cd
 
ohnul 2025-05-26

Parece que algo con el enlace no está funcionando bien, así que lo vuelvo a intentar. https://chatgpt.com/canvas/shared/68341217ae788191b66a523c948b1a8e
 
superscv 2025-05-26

La segunda quickSortInPlace() que adjuntaste también es una implementación lenta.

Prueba ejecutar el código de abajo.

function quickSortInPlace(arr, left = 0, right = arr.length - 1) {
if (left >= right) return;

const pivotIndex = partition(arr, left, right);
quickSortInPlace(arr, left, pivotIndex - 1);
quickSortInPlace(arr, pivotIndex + 1, right);
}

function partition(arr, left, right) {
const pivot = arr[right];
let i = left;

for (let j = left; j < right; j++) {
if (arr[j] < pivot) {
[arr[i], arr[j]] = [arr[j], arr[i]];
i++;
}
}

[arr[i], arr[right]] = [arr[right], arr[i]];
return i;
}

function quickSort(arr) {
if (arr.length <= 1) return arr;

const pivot = arr[arr.length - 1];
const left = [];
const right = [];

for (let i = 0; i < arr.length - 1; i++) {
if (arr[i] < pivot) {
left.push(arr[i]);
} else {
right.push(arr[i]);
}
}

return [...quickSort(left), pivot, ...quickSort(right)];
}

const repeat = 100;
const arrLength = 10000;
const unsortedArray = new Array<number>();
for(let i = 0; i < arrLength; i++)
unsortedArray.push(Math.round(Math.random() * arrLength));

let sorted: Array<number>;

const qb = performance.now();
for(let i = 0; i < repeat; i++)
sorted = quickSort(unsortedArray);
const qe = performance.now();

const rqb = performance.now();
for(let i = 0; i < repeat; i++) {
let copied = [...unsortedArray];
quickSortInPlace(copied);
}
const rqe = performance.now();

console.log(q: ${qe - qb} ::: rq: ${rqe - rqb});
 
superscv 2025-05-26

Básicamente, se puede considerar que es un código que no tiene ninguna sensibilidad respecto a la carga de crear, operar y fusionar colecciones. En el caso de C++, ya hace unos 10 años surgieron propuestas/implementaciones relacionadas con el Move Constructor, y estar siempre muy alerta respecto al costo de la copia de memoria es de lo más básico. quick sort, por su mecanismo, es un algoritmo que puede fijar el índice de todos los valores, y es mejor que cada campo permita acceso aleatorio.

Incluso sin optimizaciones maniáticas, con solo aplicar lo anterior ya hay una diferencia de rendimiento de más del doble frente al método del enlace que compartiste.
 
dudlf016 2025-05-27

Lo ejecuté yo mismo y tiende a ser un poco más lento, pero no creo que llegue a ser 2 veces más lento.

function quickSortInPlace(arr, left = 0, right = arr.length - 1) {  
    if (left &gt;= right) return;  
  
    const pivotIndex = partition(arr, left, right);  
    quickSortInPlace(arr, left, pivotIndex - 1);  
    quickSortInPlace(arr, pivotIndex + 1, right);  
}  
  
function partition(arr, left, right) {  
    const pivot = arr[right];  
    let i = left;  
  
    for (let j = left; j &lt; right; j++) {  
        if (arr[j] &lt; pivot) {  
            [arr[i], arr[j]] = [arr[j], arr[i]];  
            i++;  
        }  
    }  
  
    [arr[i], arr[right]] = [arr[right], arr[i]];  
    return i;  
}  
  
function quickSort(arr) {  
    if (arr.length &lt;= 1) return arr;  
  
    const pivot = arr[arr.length - 1];  
    const left = [];  
    const right = [];  
  
    for (let i = 0; i &lt; arr.length - 1; i++) {  
        if (arr[i] &lt; pivot) {  
            left.push(arr[i]);  
        } else {  
            right.push(arr[i]);  
        }  
    }  
  
    return [...quickSort(left), pivot, ...quickSort(right)];  
}  
  
// =============  
  
function quickSortGPT(arr) {  
    if (!Array.isArray(arr)) {  
        throw new TypeError('quickSort expects an array');  
    }  
    if (arr.length &lt;= 1) return [...arr];  
  
    const pivot = arr[Math.floor(arr.length / 2)];  
    const left = [];  
    const equal = [];  
    const right = [];  
  
    for (const el of arr) {  
        if (el &lt; pivot) left.push(el);  
        else if (el &gt; pivot) right.push(el);  
        else equal.push(el);  
    }  
  
    return [...quickSortGPT(left), ...equal, ...quickSortGPT(right)];  
}  
  
function quickSortInPlaceGPT(arr) {  
    if (!Array.isArray(arr)) {  
        throw new TypeError('quickSortInPlace expects an array');  
    }  
  
    const stack = [[0, arr.length - 1]];  
  
    while (stack.length) {  
        const [lo, hi] = stack.pop();  
        if (lo &gt;= hi) continue;  
  
        const pivotIndex = partitionGPT(arr, lo, hi);  
  
        // Eliminación de recursión de cola: primero apilar la partición más grande  
        if (pivotIndex - 1 - lo &gt; hi - (pivotIndex + 1)) {  
            stack.push([lo, pivotIndex - 1]);  
            stack.push([pivotIndex + 1, hi]);  
        } else {  
            stack.push([pivotIndex + 1, hi]);  
            stack.push([lo, pivotIndex - 1]);  
        }  
    }  
    return arr;  
}  
  
function medianOfThreeGPT(a, b, c) {  
    return (a - b) * (c - a) &gt;= 0 ? a  
        : (b - a) * (c - b) &gt;= 0 ? b  
            : c;  
}  
  
function partitionGPT(arr, lo, hi) {  
    const mid = lo + ((hi - lo) &gt;&gt; 1);  
    const pivotValue = medianOfThreeGPT(arr[lo], arr[mid], arr[hi]);  
  
    while (true) {  
        while (arr[lo] &lt; pivotValue) lo++;  
        while (arr[hi] &gt; pivotValue) hi--;  
  
        if (lo &gt;= hi) return hi;  
  
        [arr[lo], arr[hi]] = [arr[hi], arr[lo]];  
        lo++;  
        hi--;  
    }  
}  
  
function testQuicksort(qs, qsp) {  
    const repeat = 100;  
    const arrLength = 100000;  
    const unsortedArray = new Array();  
    for (let i = 0; i &lt; arrLength; i++)  
        unsortedArray.push(Math.round(Math.random() * arrLength));  
  
    let sorted = [];  
  
    const qb = performance.now();  
    for (let i = 0; i &lt; repeat; i++)  
        sorted = qs(unsortedArray);  
    const qe = performance.now();  
  
    const rqb = performance.now();  
    for (let i = 0; i &lt; repeat; i++) {  
        let copied = [...unsortedArray];  
        qsp(copied);  
    }  
    const rqe = performance.now();  
  
    // hasta 2 decimales  
    const p1 = ((qe - qb) / repeat).toFixed(2);  
    const p2 = ((rqe - rqb) / repeat).toFixed(2);  
    
    console.log(`Quicksort: ${p1} ms, In-place: ${p2} ms`);  
}  
  
function main() {  
    const useGPT = process.argv.includes('--gpt');  
    console.log(`Using ${useGPT ? 'GPT' : 'geekNews'} quicksort implementation.`);  
    if (useGPT) {  
        testQuicksort(quickSortGPT, quickSortInPlaceGPT);  
    } else {  
        testQuicksort(quickSort, quickSortInPlace);  
    }  
}  
  
main();

===
node q.js
Using geekNews quicksort implementation.
Quicksort: 29.55 ms, In-place: 9.94 ms
node q.js
Using geekNews quicksort implementation.
Quicksort: 28.42 ms, In-place: 9.07 ms
node q.js
Using geekNews quicksort implementation.
Quicksort: 26.91 ms, In-place: 9.15 ms
node q.js --gpt
Using GPT quicksort implementation.
Quicksort: 28.73 ms, In-place: 9.22 ms
node q.js --gpt
Using GPT quicksort implementation.
Quicksort: 26.87 ms, In-place: 9.22 ms
node q.js --gpt
Using GPT quicksort implementation.
Quicksort: 27.97 ms, In-place: 9.30 ms
node --version
v22.14.0

bun q.js
Using geekNews quicksort implementation.
Quicksort: 32.05 ms, In-place: 17.39 ms
bun q.js
Using geekNews quicksort implementation.
Quicksort: 30.97 ms, In-place: 17.82 ms
bun q.js
Using geekNews quicksort implementation.
Quicksort: 29.73 ms, In-place: 16.14 ms
bun q.js --gpt
Using GPT quicksort implementation.
Quicksort: 30.61 ms, In-place: 12.63 ms
bun q.js --gpt
Using GPT quicksort implementation.
Quicksort: 31.09 ms, In-place: 12.76 ms
bun q.js --gpt
Using GPT quicksort implementation.
Quicksort: 33.24 ms, In-place: 12.75 ms
bun --version
1.2.14

deno q.js
Using geekNews quicksort implementation.
Quicksort: 32.30 ms, In-place: 6.79 ms
deno q.js
Using geekNews quicksort implementation.
Quicksort: 26.79 ms, In-place: 6.86 ms
deno q.js
Using geekNews quicksort implementation.
Quicksort: 26.09 ms, In-place: 6.85 ms
deno q.js --gpt
Using GPT quicksort implementation.
Quicksort: 27.18 ms, In-place: 7.92 ms
deno q.js --gpt
Using GPT quicksort implementation.
Quicksort: 25.34 ms, In-place: 8.12 ms
deno q.js --gpt
Using GPT quicksort implementation.
Quicksort: 25.39 ms, In-place: 8.09 ms
deno --version
deno 2.3.3 (stable, release, x86_64-pc-windows-msvc)
v8 13.7.152.6-rusty
typescript 5.8.3
 
superscv 2025-05-27

Ah... entendí a qué se refiere. No había entendido qué cosas había que comparar.... el algoritmo quick sort no tiene dos formas de implementación, quicksort e in-place......

Desde el principio, lo que cuestioné fue que se escribieran y se ofrecieran a los usuarios de IA quickSortGPT() y quickSort() del código de arriba (ambos son código generado por GPT), donde la fusión de arrays ya está incorporada.
 
dudlf016 2025-05-27

La respuesta de GPT incluye tanto quickSort como quicSortInPlace, y como en los comentarios señalaron la parte de [...,quickSort(left), ...equal, ...quickSort(right)], entendí que había que comparar quickSort con quickSort y quickSortInPlace con quickSortInPlace, pero parece que no era así.
 
superscv 2025-05-27

La frase "quickSort con quickSort" me hace llevarme la mano a la nuca del puro estrés.
 
superscv 2025-05-27

Por favor, al leer el texto, asegúrense de revisar bien el contexto.

No estoy presumiendo mi nivel de programación. Lo que estoy señalando es que código tan deficiente como quickSort() que se está usando ahora como ejemplo aparece con alta prioridad en las respuestas de GPT.

Si haces varias búsquedas en GPT, muchas veces te entrega como resultado una sola función quickSort() y, de nuevo, quickSort() es solo un ejemplo. Cuando le pides código a GPT para trabajo real, con frecuencia genera código de muy baja calidad (hablo desde la experiencia de un usuario de pago), y coincido con la opinión del autor del texto en que, si el desarrollador no tiene la capacidad de distinguir eso por sí mismo, es muy probable que el proyecto avance en una dirección que lo termine arruinando. Ese es el contexto que lleva hasta este punto.

De hecho, a mi alrededor ya siguen aumentando los proyectos cubiertos con este tipo de código tan deficiente.
 
superscv 2025-05-27

Por supuesto, la comparación debe hacerse entre el rendimiento de las dos funciones quickSort() y quickSortInPlace()........
 
superscv 2025-05-27

¿Compartir un resultado donde se ve una diferencia de más del doble, incluso de 3 a 4 veces, y luego decir que no parece llegar al doble?
 
superscv 2025-05-26

return [...quickSort(left), ...equal, ...quickSort(right)];

Piensa bien en esta parte del código.
 
roxie 2025-05-27

Estoy aprendiendo mucho.
 
ohnul 2025-05-26

¡Gracias por tu respuesta!
 
crawler 2025-05-26

Primero, en eso de "usar IA dentro del dominio", por supuesto que el diseño y la coordinación los hace una persona...
En realidad, eso quizá habría que aclararlo antes, pero ahora que todo el mundo conoce las limitaciones de los LLM, se ha vuelto algo tan obvio que ni hace falta decirlo.

En cuanto al caso que mencionaste de gente común sin conocimientos de desarrollo usando LLM,
creo que ni el artículo, ni Hacker News, ni yo hemos dicho eso, pero de todos modos, incluso en ese caso, ya se llegó a un nivel en el que los usuarios pueden quedar satisfechos con los resultados.
Si no fuera así, Bolt.new, v0 e incluso Cursor no tendrían la valoración que tienen hoy.
 
superscv 2025-05-26

Resumen,

Autor: los desarrolladores deben mejorar y conservar sus propias habilidades. Incluso la IA ni siquiera funciona tan bien.

crawler: ¿Eh? A mí sí me funciona bien.

superscv: Tiene muchos problemas...

crawler: Hay que saber ajustarla y usarla.

superscv: Creo que ya nos alejamos demasiado del mensaje que el autor quería transmitir desde el principio...
 
crawler 2025-05-26

Creo que no entendiste bien por qué mencioné el campo del autor ni qué significa eso de tener tu propio dominio.
Delegar todas las decisiones a la IA sin pensar por cuenta propia también me parece una tontería,
pero tampoco entiendo muy bien a quienes están en el extremo opuesto.

Por último, lo que me gustaría preguntarte es cómo piensas que sería bueno usar los LLM para programar, superscv.
 
superscv 2025-05-26

Normalmente no suelo dejar comentarios, pero la razón por la que comenté justamente en este artículo es que coincido bastante con lo que piensa el autor. No es que la IA o los LLM sean lo importante, sino que, sin importar qué clase de entorno llegue, creo que como desarrollador debo estar preparado.

Por las características del código fuente con el que se entrenan, los LLM suelen ofrecer datos cercanos al promedio de los datos en línea repartidos por todo el mundo. (El caso anterior de quicksort en js lo demuestra). Por eso, normalmente los uso mucho para preguntar si, desde el punto de vista de ideas/diseño, algo coincide o se desvía en cierta medida de una perspectiva general, o para consultar cosas sobre las que hasta ahora era ambiguo a quién preguntar.
 
superscv 2025-05-26

Además, no estoy muy seguro de qué sentido tiene seguir conversando más sobre esto.

Si desde el principio la postura era que el código que genera la IA puede tener ciertos riesgos, así que conviene refinarlo bien y usarlo de manera adecuada, entonces parecería suficiente con que se explicara en qué aspecto el texto del autor refleja un sesgo en su forma de pensar. Incluso en el resumen aparece una idea similar: "puede proporcionar rápidamente código scaffold/borrador sin contexto, pero el diseño completo y el ajuste fino siguen siendo responsabilidad de los desarrolladores humanos".
 
superscv 2025-05-26

Aunque el mensaje del autor tiende a ser algo fuerte, si leen bien el texto, no está diciendo "no uses IA". Hay una propuesta sobre cómo aprovecharla, y el punto central es el mensaje de que al propio desarrollador no le puede faltar capacidad.

Si vemos por qué el mensaje del autor se siente tan fuerte, es porque fue construido como una respuesta a la perspectiva de que será posible desarrollar con Copilot (con un matiz de alta dependencia del desarrollo respecto de Copilot). Por eso llevó el mensaje con la forma de no adoptar una postura que dañe, para los desarrolladores, el valor de su propia existencia.

Como el autor tampoco está dando un mensaje de "no usen IA", al final, si se trata de aprovechar la IA, el punto de equilibrio estará en algún lugar intermedio, así que parece que el mensaje en líneas generales terminó siendo bastante parecido a lo que acababas de responder.

De todos modos, me costó estar de acuerdo con la parte de "perspectiva sesgada" en lo que escribiste al principio, así que por eso quise responder primero.
 
GN⁺ 2025-05-25
Opinión de Hacker News

  • Si quieres crear software que tenga que ser absolutamente robusto, como el que va en un marcapasos, un sistema de guiado de misiles o un tanque M1, mejor haz a un lado a los agentes de codificación con IA y adopta la actitud de aprender por tu cuenta.
    Pero la mayoría no construimos cosas así, sino apps CRUD con requisitos casi idénticos, donde solo cambia un poco el esquema y un poco la forma de integración.
    En la práctica, la mayor parte del software que hacemos no tiene nada nuevo.
    Muchas veces lo mejor es reutilizar conocimiento ya existente.
    Para mí, un agente de código es una versión gigantesca de reutilizar código del pasado.
    Y además, irónicamente, este mismo texto me dio vibra de haber sido escrito por IA.

    • Yo de entrada no quiero escribir código de bajo nivel y de misión crítica.
      No creo que las herramientas de IA sean tan útiles como piensa el autor, pero ya cansa esa discusión de que “si no haces programación de sistemas en C, ni siquiera eres programador”.
      Me gusta hacer frontend.
      Tampoco quiero crear yo mismo una librería gráfica de bajo nivel.
      No soy del tipo que se desvela hackeando de madrugada, pero sí tengo pasión y orgullo por mi trabajo.
      No creo que todos tengan que adoptar la misma postura extrema que el autor.
      Tiene que haber diversidad en el mercado del software.

    • Está bien refutar la postura del autor, pero decir que este texto lo escribió una IA ya es pasarse.
      El autor impregnó todo el texto con su propio estilo, mezclando expresiones muy vivas, metáforas potentes y hasta humor genuinamente gracioso.
      Hoy por hoy, sería realmente difícil que un LLM escribiera algo así.
      Esto no es IA, es un texto bien escrito.
      Estés o no de acuerdo con el argumento, la calidad de la escritura hay que reconocerla.

    • En el texto original también aparece un pasaje así:
      “Probablemente no vayas a escribir tú mismo el código que mantiene aviones en el aire ni el que está ligado directamente a vidas humanas. La mayoría no lo hace. Pero incluso si trabajas en una empresa que solo saca apps CRUD pegadas con cinta, al final sigues teniendo la responsabilidad de tratar a los usuarios con respeto y dignidad”.
      El punto es enfatizar que incluso el software más simple requiere un mínimo de responsabilidad.

    • En realidad, el mismo autor reconoce algunos casos donde la IA sí es útil.
      El problema central para él es que llamamos a la IA “copiloto”, y eso puede hacer que los principiantes confíen demasiado en ella.
      Un copiloto de verdad debería ser un colega experto, pero la IA todavía es, con media probabilidad, un colega bastante malo.
      “Ahora mismo estamos dejando la curiosidad y la iniciativa fuera del sistema. Gente con verdadero potencial de crecimiento se apaga revisando patchsets generados por IA. La terminal se convierte en hoja de cálculo, y el depurador en ataúd”.
      Pero la IA al final no deja de ser otra abstracción.
      Así como a algunos les preocupa que, si la automatización se vuelve tan normal como el GC (recolección de basura), se pierdan los fundamentos, con la IA existe el mismo temor: que desaparezcan habilidades muy básicas de programación y aprendizaje.
      Gracias a las abstracciones, un desarrollador web puede hacer buenos sitios sin conocer a fondo toda la estructura del stack.
      Pero la IA es una abstracción con muchos huecos, y hasta puede funcionar más o menos aunque de verdad no conozcas los fundamentos.
      El problema es que tarde o temprano descubres que hay bugs serios escondidos, y depurar, resolver problemas y aprender por cuenta propia son cosas que la IA no puede reemplazar.
      Por eso preocupa que, si aprender se vuelve demasiado fácil con IA, se terminen omitiendo capacidades básicas importantes.
      Al final, la forma real de aprender es crecer a través de la repetición y de enfrentarte directamente a los problemas.
      Si la IA abstrae hasta el propio “aprendizaje”, a largo plazo debilitará la capacidad de los desarrolladores.
      Claro, no es que por usar solo IA todo el mundo se vaya a volver tonto, y seguirá habiendo gente que aprenda de forma activa.
      Pero es muy probable que, en conjunto, esa proporción disminuya.
      Porque podría desaparecer la experiencia misma de “construir pensando por cuenta propia” para principiantes.
      Y la abstracción llamada IA, al final, está llena de huecos.
      Desde la perspectiva de un principiante, parece que la IA lo hace todo, pero al final sigues necesitando capacidad real de programación y depuración.
      Por eso, si de verdad quieres detectar bien los problemas en código generado por IA, necesitas desarrollar tus propias habilidades.
      Yo también aprovecho bastante bien la asistencia de IA para programar.
      Pero como tiene desventajas, mi conclusión es que no hay que verla como si todo fueran ventajas.

    • Hice un pequeño video cómico con Google Whisk y luego lo subí a TikTok, pero al entrar vi puro contenido hecho por IA o videos que la gente se copiaba entre sí.
      Pensé que habría algo genuino en la “creación original”, pero al final somos demasiado fáciles de reproducir.
      Aunque subiéramos a TikTok videos de nosotros programando todos los días, sería una repetición infinita de las mismas apps.
      Como dice Elon Musk, ya casi da la impresión de que lo único que queda es ir de verdad a Marte.
      Hace dos años también decía que los LLM no “alucinaban” tanto, y todavía hay gente que cree que los humanos son indispensables, pero cada vez siento más que no es así.
      Me gustaría recordar esta conversación dentro de dos años.

  • “La máquina es real. El silicio es real, la DRAM es real, la caché L1 y el false sharing son reales, y también lo es el predictor de saltos lanzando una moneda al aire. Si te interesa, puedes trabajar con todo eso”.
    Hacía mucho que no me parecía tan bella una frase así.

    • Yo sentí exactamente lo mismo.
      El autor escribe con un tono alegre al estilo Dave Barry, y varias veces me sacó una carcajada.
      Me gustó cómo expresó con humor, y de muy buena manera, ideas sobre Copilot con las que me identifiqué.

  • Algo que a menudo falta en las discusiones sobre desarrollo de software es que no todo se reduce al “resultado” de escribir código.
    El recorrido mismo para llegar al resultado, atravesando una enorme cantidad de trade-offs, es importantísimo.
    Basta con construir una sola función junto a un junior dentro de una base de código algo compleja para notar de inmediato qué trade-offs está haciendo inconscientemente un ingeniero experimentado.
    La IA también tiene cierta noción de esos trade-offs, pero en la mayoría de los casos los aprende solo por observación.
    Sí ayuda a “escribir mejor código”, pero al final juzgar y pensar sigue siendo tarea humana.
    Un LLM no “piensa”.
    Y mientras más avance la IA, mayor será el riesgo de que las personas piensen cada vez menos.

  • A mí me hacen sentido tanto las ventajas como las desventajas de Copilot.
    Pero, a diferencia de la “artesanía” hacker de la infancia de algunos, los ingenieros siempre han sido ingenieros.
    Si las tecnologías clave de hoy surgieron con tanto esfuerzo, fue porque en ese momento esas dificultades tenían que resolverse sí o sí.
    Generalizar esa historia dramática como si fuera “la forma en que siempre se hacía” puede llevar a una visión sesgada.

    • Como ingeniero de software que lleva más de 20 años desarrollando por el camino difícil, resolver problemas complejos es un privilegio y una fuente de satisfacción.
      Las actualizaciones CRUD simples son repetitivas y aburridas, pero esos retos ocasionales que te exprimen el cerebro, esos momentos en que aplicas algo que aprendiste en la universidad, y esos casos excepcionales como los algoritmos recursivos, son joyas dentro de una carrera.
      Ojalá los ingenieros de software guiados por IA en el futuro también valoren más ese tipo de experiencias.
      La IA a veces puede dar una respuesta lógica, pero también puede estar totalmente equivocada y de forma peligrosa, así que siempre hará falta alguien que sepa qué hay que hacer en realidad.
      Cuando las IA “alucinen” o falte contexto, siempre habrá situaciones en las que un humano tendrá que resolver el problema.

  • Mi punto de comparación no es la programación en pareja, sino los desarrolladores tercerizados en el extranjero.
    De hecho, Copilot, Cursor y otras herramientas de IA me parecen mucho mejores porque ya no tengo que perder tiempo en llamadas por Zoom con comunicación ambigua, barreras de idioma o diferencias de entendimiento.
    Por ejemplo, esas situaciones tan comunes con outsourcing donde “se agregó una función isChild relacionada con el nodo raíz (devuelve boolean), pero no tiene nada que ver con verificar si existe el padre”, o donde “de repente un parámetro del API ya no acepta arrays”.
    Cuando trabajo con IA, aunque surja un problema así, basta con decirle enseguida que está mal y explicarle por qué, y lo corrige rápido.
    Casi no hay problemas de comunicación, malentendidos ni pérdida de tiempo como sí pasa con personas.
    En cuanto la IA se conecte fácilmente con tickets de Jira, alrededor del 80% del trabajo de desarrollo se va a convertir en redactar tickets y supervisar.
    Claro, eso no significa que desaparezca el rol del ingeniero —el área de negocio jamás va a escribir buenos tickets, y al final alguien tendrá que asumir la responsabilidad final.
    Aun así, muchas organizaciones van a olvidar ese hecho, y eso deja espacio para que ocurra un desastre grande.

  • La parte central que yo me llevé de este texto fue:
    “Vamos a terminar celebrando como lo máximo la realidad atrasada, inflada y excesivamente abstraída del software actual. La cultura de exprimir el rendimiento al límite, o de construir sistemas secos, afilados y claros, quedará solo como una historia del pasado”.
    Me preocupa que las librerías y patrones de arquitectura creados antes de 2023 se solidifiquen como la columna vertebral de los datos con los que entrenan los LLM de ahora en adelante.
    En vez de seguir innovando, podríamos terminar arrastrando para siempre las dependencias y el código desordenado acumulado de los últimos 30 años.
    Me preocupa que incluso Javascript vaya a vivir para siempre.

  • Últimamente siento la presión diaria desde el liderazgo con cosas como “no estamos usando suficiente IA” o “si adoptamos IA podemos cortar a la mitad el cronograma actual”.
    Me obligan a incorporar nuevas herramientas de IA para cumplir KPI, y si no me adapto ya hasta se habla de recorte de personal.
    Siento que el mundo se volvió loco de remate.
    La IA siempre se presenta como “una herramienta para reemplazar el trabajo de otros”.
    En realidad, solo parece buena por eso cuando evalúas trabajos ajenos que no conoces lo suficiente.
    Es como si la gerencia hubiera agarrado el martillo de la IA y ahora quisiera clavar todo lo que existe en el mundo.

    • De verdad hay que pensar cómo reducir de algún modo la estructura directiva y encontrar formas de dedicar más tiempo al trabajo realmente productivo.
      Ojalá hubiera una cultura más enfocada en el trabajo real y en entregar resultados, en lugar de solo presumir uso de IA.

    • Esto en realidad no es más que el patrón típico del “hype cycle” de la industria de IA.
      Cuando las aguas se calmen, solo van a quedar las herramientas y tecnologías que de verdad sirvan, y la mayoría desaparecerá.
      La idea es identificar con inteligencia qué sí va a permanecer en la práctica y, si puedes influir en ese cambio, ahí está el camino para sobrevivir a futuro.

    • Esta presión actual de “adopten rápido” es exactamente lo contrario de lo que yo entendía como la esencia de la ingeniería, el diseño y el trabajo técnico.
      Antes lo normal era evaluar con cuidado si convenía adoptar una herramienta, un lenguaje o un servicio, y justificar por qué encajaba en nuestro caso y cuáles eran sus ventajas y desventajas.
      Un proceso sano de decisión de políticas era preguntarse “por qué necesitamos esto” y “por qué este servicio es más razonable”.
      Existía un proceso para probar si una tecnología realmente hacía falta y, después, evaluar sus resultados o la eficiencia de su adopción.
      Las empresas actuales se están alejando de esa forma sana de trabajar.

    • Está demasiado extendida esa fantasía de que “la IA siempre puede reemplazar el trabajo de otros”.
      Sí, hay muchas tareas simples y repetitivas, pero para hacer bien la mayoría de los trabajos hace falta una sutileza y una fineza propias, y todo eso corre el riesgo de desaparecer en el proceso de automatización.
      No estoy de acuerdo con eso de que “si la IA hace el 80%, ya es suficiente”.
      Los errores afectan al sistema completo, y quienes evalúan casi siempre van a carecer de experiencia real en el terreno.

    • Creo que dentro de poco los puestos de gestión van a desaparecer más rápido.
      Hasta entonces, ánimo para todos.

  • El autor claramente parece desarrollador de C++.
    De hecho, los asistentes de codificación con IA rara vez funcionan bien en C++, y quienes los usan con buenos resultados normalmente los aprovechan más en lenguajes de scripting o en apps CRUD.

    • Si ves publicaciones anteriores del autor, parece que trabaja en desarrollo de videojuegos.
      Como el conocimiento y el material de desarrollo de juegos no han sido absorbidos masivamente por los LLM, a diferencia del caso de las apps CRUD, parece que el autor percibe mejor los límites de los LLM.

  • Hay partes de este texto que se leen con la voz del personaje Bertram Gilfoyle de la serie Silicon Valley.
    Me pregunto si solo me pasa a mí.

  • La clave es conservar siempre la capacidad de “telescopio”.
    Está bien hacer solo trabajo de alto nivel gracias a un agente de codificación, pero para estar a salvo hay que poder meterse a fondo en el código en cualquier momento, entenderlo directamente y corregirlo uno mismo si hace falta.