El código sí es difícil: desarrollador responde a quienes lo minimizan

El desarrollador Senko Rašić publicó una encendida defensa de la profesión de programador, calificando de insulto la creciente narrativa de que ‘el código nunca fue la parte difícil’ en el desarrollo de software. Rašić argumenta que minimizar la habilidad técnica ignora décadas de trabajo, estrés y complejidad, y llama a los programadores a no abdicar su criterio frente a la inteligencia artificial.
***

• Rašić sostiene que si programar fuera fácil, no existirían libros como ‘Clean Code’ ni entrevistas técnicas rigurosas.
• El autor cuestiona por qué los gerentes de producto no son sometidos a los mismos estándares si ‘entender al cliente’ es lo difícil.
• Rašić insta a los desarrolladores a mantener su juicio y empatía, sin externalizar su responsabilidad a la IA.

En medio de la revolución de la inteligencia artificial aplicada al desarrollo de software, ha resurgido una frase que divide a la industria: “El código nunca fue la parte difícil”. Quienes la repiten suelen argumentar que los modelos de lenguaje pueden escribir código funcional, y que lo verdaderamente complejo es determinar qué construir. Sin embargo, el desarrollador Senko Rašić, autor del blog homónimo, ha publicado una respuesta contundente: considera que esa afirmación es un grave insulto hacia todos los programadores.

La publicación de Rašić, fechada el 8 de agosto de 2026, llega en un momento de agitación profesional donde la inteligencia artificial está transformando múltiples aspectos del trabajo, incluida la programación. El autor no niega que el cambio sea profundo, pero rechaza con vehemencia la idea de que codificar sea trivial. A lo largo de su texto, desmenuza las contradicciones lógicas y emocionales de esa postura, mientras ofrece una hoja de ruta para que los desarrolladores prosperen en la nueva era.

Las preguntas incómodas de Rašić

Rašić desafía directamente a quienes minimizan el acto de programar con una serie de preguntas retóricas. “Si programar es fácil, ¿cómo es que los programadores tenían una gran demanda y exigían salarios altos durante años, incluso antes del período de tasas de interés cero?”, se pregunta. También señala el estrés, el exceso de trabajo y el agotamiento que prevalecían mucho antes de que la IA comenzara a generar solicitudes de extracción de 5.000 líneas, lo que indica que la profesión nunca fue sencilla.

Además, el autor recuerda la existencia de libros extensos como Clean Code y The Pragmatic Programmer, así como carreras universitarias enteras dedicadas a la computación. “¿Es The Art of Computer Programming una lectura ligera de verano?”, ironiza. Si el código fuera realmente fácil, no habría necesidad de bootcamps ni de entrevistas técnicas de diez pasos, ni se consideraría genios a figuras como John Carmack o Fabrice Bellard.

Otro punto que levanta es la reacción emocional de los programadores cuando su código es copiado por la inteligencia artificial. “Si programar es fácil, ¿por qué la gente se enoja con la IA (o con cualquier otra persona) que copia su código?”, pregunta. “¿Por qué actúan como si hubieran derramado sudor, alma y una gran cantidad de tiempo en algo tan trivial?” La incongruencia, sostiene, revela que la codificación exige una inversión intelectual y emocional que no puede reducirse a una tarea mecánica.

Finalmente, Rašić apunta a la calidad del software como evidencia de la dificultad: “Si programar es fácil, ¿por qué el software es tan malditamente buggy?” Esta observación conecta con la experiencia cotidiana de millones de usuarios, donde los fallos y las vulnerabilidades son moneda corriente, demostrando que la implementación dista de ser un proceso automático y libre de errores.

Las contradicciones de minimizar el código

El desarrollador también dirige su mirada crítica hacia la otra cara del argumento: la idea de que entender al cliente es la parte realmente difícil. “Si decidir qué construir es la parte difícil, ¿por qué tantos gerentes de producto parecen desorientados?”, cuestiona. Rašić nota que no existen entrevistas rigurosas de diez pasos para ellos, ni suelen ganar más que los desarrolladores, lo que pone en duda la supuesta jerarquía de dificultad.

Asimismo, se pregunta por qué los investigadores de mercado, los expertos en usabilidad y los equipos de éxito del cliente no son considerados “rockstars” en una empresa de software. “Si entender al cliente es más difícil, ¿por qué los analistas de negocios son menospreciados como oficinistas?”, agrega. Estas preguntas revelan una inconsistencia en el discurso que eleva una tarea sobre la otra sin sustento práctico.

Rašić subraya otra paradoja: si la implementación es fácil y encontrar la demanda es lo difícil, los programadores no deberían molestarse cuando los vendedores prometen una nueva funcionalidad a un cliente para cerrar la venta. “¡Han encontrado una demanda genuina, algo por lo que la gente pagará!”, ironiza. Sin embargo, la realidad es que los desarrolladores a menudo se quejan de promesas excesivas, lo que indica que la implementación lleva consigo una carga de trabajo considerable.

El autor también descarta la solución simplista de construir diez variaciones de un producto para ver cuál funciona, argumentando que si programar fuera trivial, esa estrategia sería viable. Pero no lo es, porque cada variante requiere tiempo, esfuerzo y conocimiento para ser ejecutada correctamente. La conclusión de Rašić es que ambas dimensiones —la técnica y la de negocio— son complejas y no pueden jerarquizarse a la ligera.

La diversidad de los programadores

Rašić aborda el cliché de que “la mayor parte del trabajo en el desarrollo de software es hablar con las partes interesadas, entender las necesidades del cliente y tener claridad sobre las prioridades”. A lo largo de su carrera, ha conocido a muchos programadores, y muy pocos de ellos quieren hablar con las partes interesadas, y mucho menos con los clientes. Las excepciones, señala, son los freelancers y los fundadores de empresas de desarrollo de software.

Incluso aquellos que afirman “no escribo código, resuelvo problemas del cliente” suelen dar un giro y comenzar a opinar sobre mónadas, seguridad de memoria y principios DRY, mientras que su comprensión del cliente es una “persona de usuario” inventada. Rašić bromea con que a veces piensan que “affordance” es el dinero que tus padres te daban los fines de semana. Esta desconexión interna refleja la dificultad de combinar ambas habilidades en una sola persona.

El autor reconoce que existen desarrolladores que logran equilibrar el arte del código con la empatía hacia el cliente, pero advierte que son raros. Incluso hace una broma autocrítica: “quizás deberían consultar a un profesional sobre un trastorno de personalidad múltiple”. Luego aclara que la frase fue exagerada y que en realidad aboga por ese equilibrio, pero la diversidad de perfiles en la industria hace que sea poco realista esperar que todos los programadores dominen ambas áreas por igual.

Esta variedad, lejos de ser un defecto, es una fortaleza, pero también explica por qué las narrativas simplistas sobre “lo fácil” y “lo difícil” no capturan la complejidad del trabajo. Rašić insiste en que cada programador tiene fortalezas distintas y que la industria necesita reconocer tanto el valor de la excelencia técnica como el de la comprensión del negocio, sin menospreciar ninguno de los dos.

El equilibrio necesario, según Rašić

El desarrollador afirma con claridad que hablar con los usuarios, entender su experiencia, empatizar con ellos y resolver los problemas de los clientes es fundamental para el éxito de un proyecto de software. Pero al mismo tiempo, crear buen código es un oficio que requiere habilidad, paciencia, atención al detalle, experiencia y sabiduría, y que seguirá siendo relevante en el futuro. “¿Por qué no los dos?”, pregunta retóricamente, abogando por una integración en lugar de una competencia entre habilidades.

Rašić sostiene que una comprensión profunda del sistema que se está construyendo, junto con una comprensión profunda de por qué se construye, es lo que realmente distingue a los profesionales. Proclamar que “el código es fácil” o, en el extremo opuesto, que “el código es arte, una expresión humana creativa que no se puede automatizar”, son formas de esconder la cabeza en la arena. “Es una forma de consuelo”, dice el autor, “y no quieres consuelo, quieres prosperar”.

El autor invita a los desarrolladores a reconocer el cambio tectónico que está ocurriendo en toda la industria, sin caer en el optimismo ciego ni en el pesimismo defensivo. No se trata de subirse al carro de los LLM ni de convertirse en un gestor de flotas de agentes de IA, pero tampoco de luchar contra la IA con uñas y dientes llamándola basura robada. La clave, según Rašić, está en entender qué es probable que cambie y qué nunca cambia.

Este llamado a la adaptación consciente resuena en un momento donde muchos programadores sienten que su identidad y propósito profesional les están siendo arrebatados. Rašić les ofrece una salida: no abandonar la técnica, sino complementarla con una visión más amplia del negocio y del usuario. El objetivo no es sobrevivir, sino prosperar en medio de la transformación.

Lo que cambia y lo que permanece

Rašić enumera varios elementos inmutables del desarrollo de software que seguirán vigentes independientemente de la IA. El software será cada vez más complejo, siempre necesitará mantenimiento, y la erosión digital y la entropía son hechos de la vida. La tecnología avanzará, para bien o para mal, y la torre de abstracciones crecerá cada vez más alto, exigiendo una comprensión cada vez más sofisticada de los fundamentos.

Los usuarios siempre querrán más y estarán dispuestos a gastar menos, y todavía no sabrán cómo comunicar sus necesidades y deseos. Peor aún, no sabrán exactamente lo que quieren, lo que obliga a los equipos a interpretar, negociar y prototipar continuamente. La desconexión entre los clientes que pagan y los usuarios que utilizan el software seguirá siendo una fuente de tensión constante.

En cuanto a lo que cambia, Rašić recuerda que los programadores han estado en el negocio de disrumpir su propia industria desde el principio. Nadie usa tarjetas perforadas, muy pocas personas programan en ensamblador o COBOL, y las habilidades de depuración de memoria en C o C++ son menos relevantes en la era de Rust, Go, Python y JavaScript. El autor mismo recuerda haber usado valgrind y mysql_real_escape_string, tecnologías que ya no necesita.

Esto demuestra que el cambio técnico es constante, y que la supervivencia profesional no depende de aferrarse a un conjunto específico de herramientas, sino de la capacidad de aprender, desaprender y reaprender. Rašić lo plantea como una oportunidad: “Acepta que el cambio ocurre. Sé igualmente curioso y crítico con lo nuevo”. La discriminación entre el bombo y lo que realmente funciona se vuelve una habilidad clave.

Cómo adaptarse según Rašić

Para aquellos que quieren prosperar, el autor ofrece recomendaciones prácticas. Los desarrolladores senior no deben limitarse a profundizar su experiencia técnica, sino también aprender sobre experiencia de usuario, entrevistas con clientes o estrategias de negocio en su dominio. Esto les ayudará a apreciar todo el trabajo que se realiza para poner un software en manos de los usuarios, incluso si nunca tienen que hacer esas otras tareas.

Para quienes están empezando o son juniors, Rašić sugiere invertir en una comprensión profunda de cómo funciona el software. Entender punteros, recursión o jerarquía de memoria será útil incluso para desarrolladores de JavaScript, y conocer protocolos de red y HTTP servirá incluso a quienes construyen plugins de WordPress. Recomienda practicar con algoritmos y estructuras de datos, aunque no se necesiten a diario, y no tener miedo de preguntar “por qué” y “cómo exactamente”.

El autor concluye con una advertencia firme: “Quienquiera que seas, no externalices tu comprensión, juicio, empatía y gusto a la IA. No abdiques de tu responsabilidad. No seas un intermediario de carne”. Esta frase resume el espíritu de su artículo: la IA puede ser una herramienta poderosa, pero el pensamiento crítico y la humanidad del programador son irremplazables. El futuro pertenece a quienes combinen la maestría técnica con una visión estratégica y ética.

La publicación de Rašić ha generado un intenso debate en comunidades como Hacker News y Lobsters, donde muchos desarrolladores han compartido experiencias y definiciones muy variadas de lo que significa codificar, programar, desarrollar e ingeniería de software. Lo que queda claro es que, más allá de las etiquetas, la profesión está en un punto de inflexión, y las voces que defienden la complejidad del oficio merecen ser escuchadas con atención.

ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín