El futuro de la programación es no programar en absoluto

En 2017, el CEO de GitHub dijo que la programación iba a desaparecer. Tenía razón en algo. Se equivocó en lo que importa.

---

"El futuro de la programación es no programar en absoluto." — Chris Wanstrath, ex-CEO de GitHub, 2017

Business Insider lo publicó en portada. El CEO de GitHub diciendo que la automatización acabaría con la programación tradicional.

En 2017 no existía ChatGPT. No existía Copilot. No existía nada de lo que hoy usamos a diario.

Y aun así, ya lo estaba diciendo.

¿Tenía razón?

Sí y no.

En lo que tenía razón

La forma de programar cambió. Eso es un hecho.

Hoy cualquier persona puede abrir una interfaz, escribir un prompt, y obtener un componente funcional en segundos. Código que hace cinco años habría requerido horas de trabajo aparece en la pantalla antes de que termines el café.

Sobre esto no hay debate. La barrera para generar código se desplomó.

En lo que se equivocó

Programar nunca fue solo escribir código.

Programar es pensar en sistemas. Es decidir qué construir y cómo. Es diseñar soluciones que funcionen hoy y que se puedan modificar mañana sin que todo explote. Es entender por qué una arquitectura aguanta la carga y otra no. Es saber cuándo una abstracción ayuda y cuándo está creando un problema que alguien va a sufrir en seis meses.

Eso no lo hace un prompt.

Un modelo de lenguaje genera código. No razona sobre el sistema. No conoce las restricciones reales del negocio. No tiene que mantener lo que produce ni responder cuando algo falla en producción a las dos de la mañana.

El criterio de ingeniería no se automatiza. Se aplica sobre la automatización.

La ventaja que nadie está viendo del todo

El programador que sabe diseñar software y además sabe usar herramientas de IA como un profesional tiene una ventaja que hoy todavía no está completamente valorada. Pero lo va a estar.

Y acá importa ser preciso, porque hay mucha confusión sobre qué significa "usar IA como profesional".

No hablo de pedirle a ChatGPT que te escriba un componente. Eso ya lo hace cualquiera. Eso es el piso, no el techo.

Hablo de otra cosa. De montar agentes que siguen tus reglas de arquitectura. De encadenar subagentes que manejan partes específicas de un flujo. De definir skills reutilizables y conectar herramientas externas vía MCP. De hacer que la IA trabaje para vos de forma estructurada, con criterio, con guardarraíles de ingeniería reales.

La diferencia entre generar código con un prompt y montar un sistema de IA que hace ingeniería de software es la misma diferencia que hay entre ejecutar un script y diseñar una arquitectura.

Dos caminos

Podés seguir haciendo vibe coding. Generar código, pegarlo, rezar para que funcione, repetir. Muchos lo hacen. El resultado es velocidad aparente y deuda técnica real.

O podés aprender a montar sistemas de IA que apliquen ingeniería de software de verdad. Que sigan principios de diseño. Que generen tests. Que respeten las convenciones del proyecto. Que escalen.

Wanstrath tenía razón en que escribir código manualmente iba a dejar de ser el centro del trabajo. Se equivocó en pensar que eso hacía irrelevante al programador. Lo que hace irrelevante al programador es no entender que su rol cambió.

El rol ahora es dirigir sistemas que producen software. Y para dirigirlos bien, necesitás saber exactamente qué es buen software.

El que no sabe eso, con o sin IA, sigue construyendo lo mismo de siempre.

Solo más rápido.

Tu código limpio ya no te diferencia

Todo lo que aprendiste sigue valiendo. El problema es que ya no es suficiente.

---

Años aplicando SOLID. Code reviews serias. Tests, refactoring, arquitectura limpia. Has pagado el precio que hay que pagar para escribir software de verdad.

Y ahora hay alguien con menos experiencia que está entregando más rápido que tú.

Antes de que eso te moleste, lee: no es porque sea mejor programador. Probablemente ni sabe por qué funciona la mitad de lo que escribe. Pero aprendió algo que tú todavía no has incorporado.

Aprendió a dirigir agentes.

El código limpio sigue siendo necesario. Ya no es suficiente.

Esto no es un ataque a los fundamentos. El código sostenible, los principios de diseño, la capacidad de detectar un code smell antes de que se convierta en un desastre — todo eso sigue importando. Mucho.

Pero dejó de ser lo que te diferencia.

Antes, ser senior era saber escribir buen código. Conocer los patrones. Hacer buenas abstracciones. Eso era el nivel al que llegabas después de años de trabajo real.

Ahora eso es el piso. El punto de partida. Lo mínimo esperado.

Lo que está cambiando la ecuación no es el conocimiento. Es quién está aplicando ese conocimiento, y a qué velocidad.

Lo que está pasando en los equipos ahora mismo

Hay developers que llevan meses trabajando con agentes. No como juguete. Como parte real de su flujo de trabajo.

Le dan al agente sus reglas de arquitectura. Sus convenciones de naming. Sus criterios de testing. Las mismas reglas que tú aplicas en cada PR. Y el agente las ejecuta de forma consistente, en cada archivo, sin que nadie tenga que repetirlas.

El resultado: resuelven los mismos problemas que tú. En menos tiempo.

No porque tengan mejor criterio. Porque aprendieron a convertir su criterio en instrucciones que escalan.

No va a ser la IA la que te desplace. Va a ser un developer que sabe lo mismo que tú pero que lleva meses haciendo ingeniería con agentes mientras tú segues trabajando igual que hace un año.

Y la distancia se alarga cada semana.

Por qué los seniors tienen la mejor posición para esto

Acá está la parte que la mayoría no está viendo.

Los agentes sin criterio son peligrosos. Un developer que no distingue buen diseño de malo, que no entiende por qué una abstracción existe, que no sabe cuándo un test agrega valor y cuándo solo agrega ruido — ese developer con agentes genera deuda técnica a velocidad industrial.

El criterio que tardaste años en construir es exactamente lo que convierte un agente en una herramienta de ingeniería seria. Sin ese criterio, el agente es solo ruido rápido.

Las convenciones que aplicas en cada code review. Los límites de responsabilidad que defiendes en cada diseño. Los patrones que exiges antes de aprobar un PR. Todo eso, que hoy vive en tu cabeza, puede convertirse en reglas que un agente sigue de forma consistente.

Solo tienes que dar ese paso.

La pregunta que vale la pena hacerse

¿Cuánto de lo que sabes está documentado de una forma que un agente pueda seguir? ¿Cuánto sigue atrapado en tu cabeza, disponible solo cuando tú estás en la conversación?

Eso es lo que hay que cambiar. No el conocimiento. La forma en que ese conocimiento se aplica.

El developer que va a seguir siendo relevante en los próximos años no es el que abandona lo que sabe. Es el que aprende a multiplicarlo.

El que no lo haga se va a quedar atrás. No por falta de talento. Por falta de movimiento.

Y eso sí es una decisión.

Refactorizar sin tests es apostar a ciegas

El código limpio que nadie puede verificar es solo código que todavía no ha roto nada.

---

El buen código no es opcional. Eso ya lo sabes. Pero hay algo que mucha gente se deja en el camino.

¿Cómo sabes que tu código "limpio" sigue funcionando después de refactorizarlo?

Imagina esto: es un viernes por la tarde. Te sientas a refactorizar un servicio que lleva meses pidiendo a gritos una limpieza. Renombras métodos, los extraes a un nuevo módulo, introduces abstracciones que antes no existían. Cuando terminas, el código brilla. Es una obra de arte.

Y entonces viene la pregunta incómoda.

¿Cómo sabes que no has roto nada? ¿Que el flujo de pedidos sigue funcionando de extremo a extremo? ¿Que la integración de pagos no se ha roto silenciosamente? ¿Que un cliente todavía puede completar una compra?

No lo sabes. No puedes saberlo, a menos que tengas tests que verifiquen el comportamiento del sistema, no la implementación.

El código sostenible necesita una red de seguridad

Los tests unitarios son rápidos. Te dan feedback inmediato y hacen que refactorizar se sienta seguro. Son el pan de cada día de cualquier desarrollador disciplinado.

Pero incluso los mejores tests unitarios tienen un punto ciego enorme.

Verifican piezas en aislamiento. Mockean la base de datos. Stubean la API externa. Se saltan la serialización. Cuando todos los tests pasan, sabes que la lógica de tu unidad funciona correctamente. Pero no sabes si la lógica del sistema funciona.

Los problemas aparecen en los límites. La consulta que devuelve datos con una forma diferente a la que asumías. La capa HTTP que silenciosamente se come un campo. La integración que funcionaba aislada pero se rompe cuando se encuentra con la realidad.

Los tests unitarios no pueden detectar estos problemas, no porque estén mal escritos, sino porque no están diseñados para eso. Nadie les pidió que lo hicieran.

Los tests de aceptación llenan ese hueco

Los tests de aceptación ejercitan el sistema de extremo a extremo, a través de los mismos límites que tocan tus usuarios reales.

La diferencia con los unitarios no es solo técnica, es conceptual:

• Un test unitario dice: "Esta función calcula el descuento correctamente."
• Un test de aceptación dice: "Cuando un cliente aplica un cupón en el checkout, el precio total se reduce y el pedido se completa."

Uno verifica una pieza. El otro verifica una historia. Uno te dice que la función hace lo que se supone. El otro te dice que el usuario puede hacer lo que necesita.

Ambos son necesarios. Son complementarios, no competidores. Pero el segundo es el que te deja dormir tranquilo después de un viernes de refactoring.

¿Y si tienes un proyecto legacy sin un solo test?

Esta es la pregunta real. La que tienen la mayoría de desarrolladores .NET que trabajan en proyectos con años de historia encima.

Aquí está la trampa en la que caen muchos: intentan escribir tests unitarios primero en código legacy. Es una batalla perdida. El código legacy no fue diseñado para ser testeado en aislamiento. Tiene dependencias estáticas, clases enormes, métodos que hacen diez cosas a la vez.

La estrategia más efectiva es la contraria: empieza por los tests de aceptación.

1. Escribe un test de aceptación que describa un flujo crítico.
2. Hazlo pasar tal cual está el código (sin tocar nada).
3. Ahora tienes una red de seguridad.
4. Refactoriza con confianza.
5. Añade tests unitarios a medida que extraes lógica.

Los tests de aceptación sobre código legacy son feos, lentos, a veces frágiles. No importa. Su trabajo no es ser elegantes. Su trabajo es atrapar regresiones mientras tú limpias el desastre heredado.

Primero pon la red. Luego haz el salto.

La conclusión que no te puedes saltar

Refactorizar código sin cobertura de tests de comportamiento no es "limpiar". Es reorganizar la deuda técnica sin garantías. Puede quedar bonito en el repositorio y estar completamente roto en producción.

El código limpio sin tests es código que todavía no ha fallado en el peor momento. El código con una buena cobertura de aceptación es código que puedes cambiar sin miedo.

Y en este trabajo, cambiar código sin miedo no es un lujo. Es la habilidad que te hace relevante.

Sin Docker vs Con Docker

 

Junior and Senior

 

5 Tips para seguir siendo relevante en la era de la IA

Cada vez se escribe menos código a mano. La pregunta no es si la IA va a cambiar tu trabajo — ya lo está haciendo. La pregunta es: ¿qué valor vas a aportar tú?

1. Aprende a usar la IA — pero sobre todo, entiende lo que genera

Usar GitHub Copilot o ChatGPT para escribir código es fácil. Cualquiera puede hacerlo hoy. El problema es que la IA se equivoca, y se equivoca con mucha confianza. Genera código que compila, que se ve correcto, pero que tiene bugs sutiles, vulnerabilidades de seguridad o que simplemente no escala.

Tu valor como developer ya no está en escribir la línea de código — está en saber si esa línea debería existir, y si está bien escrita. Eso requiere criterio. Y el criterio solo viene de entender profundamente lo que estás construyendo.

Si no tienes el conocimiento para detectar cuando la IA se equivoca, entonces básicamente eres un copypaste humano. Y eso sí lo puede hacer la IA sola.

→ La IA es un amplificador: amplifica a los buenos developers y expone a los que no saben lo que hacen.

2. El conocimiento profundo en tecnología nunca fue tan importante

Paradójicamente, en la era donde la IA "escribe el código por ti", entender los fundamentos de la tecnología se vuelve más importante, no menos. Cuando la IA genera una solución con O(n²) de complejidad donde necesitabas O(log n), ¿lo vas a detectar?

Estructuras de datos, algoritmos, arquitectura de sistemas, patrones de diseño, redes, sistemas operativos. Todo eso que quizás sentiste que podías saltarte porque "igual puedo buscar en Stack Overflow" — ahora es exactamente lo que te diferencia.

La IA puede completar código, pero no puede reemplazar la intuición que te dice que algo está mal diseñado desde la base. Esa intuición se construye con años de estudio y práctica real.

→ Invierte tiempo en entender cómo funcionan las cosas por dentro. Ese conocimiento no se puede generar con un prompt.

3. Sé Full-Stack en el sentido amplio del término

Full-Stack ya no significa solo "frontend y backend". Significa entender el stack completo: desde el código hasta la infraestructura donde corre.

Los developers que más valor aportan hoy son los que pueden razonar sobre DevOps, Cloud, Seguridad, Performance, Bases de Datos, Costos de infraestructura — y cómo todo eso interactúa. La IA puede generar una función, pero no puede diseñar un sistema resiliente con tus restricciones específicas de negocio.

Un developer que entiende que su código va a correr en Kubernetes, que necesita ser idempotente, que tiene un SLA de 99.9% y que debe cumplir con GDPR — ese developer es muy difícil de reemplazar.

→ El developer del futuro es un generalista profundo: sabe de todo y profundiza donde hace falta.

4. No hay sustituto para construir cosas reales

Puedes ver todos los tutoriales del mundo. Puedes tomar todos los cursos de Udemy. Pero hasta que no hayas debuggeado tu propio servidor a las 2am porque se cayó en producción, no entiendes realmente lo que significa construir software.

Empieza a construir proyectos por tu cuenta. No importa que sean pequeños, no importa que nadie los use. Construye una CLI tool, un bot, una API, un side project que resuelva un problema que tú tengas. La experiencia real de tomar decisiones de diseño, gestionar deuda técnica, manejar datos reales — eso no se puede simular.

Además, los proyectos reales te van a enseñar cosas que ningún tutorial menciona: los edge cases, los problemas de integración, los tradeoffs reales entre velocidad y calidad.

→ La experiencia acumulada es un moat que la IA no puede cruzar. Empieza a construirla hoy.

5. Muestra lo que haces y por qué importa

En un mercado donde cada vez más gente puede generar código con IA, la diferencia va a estar en quién puede demostrar que sabe lo que está haciendo y por qué sus decisiones son correctas.

Escribe sobre lo que aprendes. Documenta tus proyectos. Explica las decisiones técnicas que tomaste y las alternativas que descartaste. Comparte lo que construyes en GitHub. Habla en meetups locales. Crea una presencia técnica real que respalde tu trabajo.

No se trata de hacer personal branding vacío. Se trata de que cuando alguien vea tu trabajo, quede claro que detrás hay un developer que piensa, que razona, y que tiene criterio — y que eso vale mucho más que alguien que solo sabe invocar un LLM.

→ Tu portafolio, tu blog, tus contribuciones open source: eso es evidencia de que eres el tipo de developer que la IA no puede reemplazar.

La IA cambia el cómo, no el qué

Seguimos necesitando software que resuelva problemas reales, que escale, que sea seguro, que sea mantenible. Los developers que entiendan eso — y que usen la IA como herramienta, no como muleta — van a ser los más valiosos de la próxima década.

Introbook: Construcción y Despliegue

Esta área se enfoca en la automatización de los procesos de construcción del software, las pruebas y su despliegue en los diferentes entornos. La automatización busca agilizar la entrega, reducir errores humanos y aumentar la frecuencia de las liberaciones.

1. Integración continua

La integración continua (CI) es una práctica de desarrollo de software en la que los desarrolladores integran su código en un repositorio compartido de manera frecuente. Este proceso ayuda a detectar errores y mejorar la calidad del software al permitir una gestión más eficiente del código y permitir pruebas automáticas.

Acciones

• Nivel 1:
• Integración continua con pipeline estándar (que realice la compilación, un análisis estático y ejecute las pruebas unitarias) sobre rama Develop.
• Integración continua con pipeline estándar (que realice la compilación, un análisis estático y ejecute las pruebas unitarias) sobre rama Main.
• Nivel 2:
• Integración continua con pipeline estándar (que realice la compilación, un análisis estático y ejecute las pruebas unitarias) sobre las ramas no principales adoptadas de acuerdo a la metodología.
• Análisis estático configurado en el pipeline. El resultado del Quality Gate se informa en el pipeline o lo deja inestable.
• Análisis en el pipeline de vulnerabilidades en artefactos externos o imágenes de contenedores. Con impacto (fallo/inestable) si se introducen nuevas vulnerabilidades
• El pipeline se impacta (falla/inestable) si no se alcanza el Quality Gate establecido
• Nivel 3:
• La definición del proceso IC está versionada y en el SCV. IC con enfoque as code (Jenkinsfile, yaml, etc)
• Pruebas unitarias automáticas integradas en el pipeline e impacto al no cumplir con el porcentaje de cobertura mínimo.
• Pruebas funcionales ejecutadas automáticamente integradas en el pipeline con impacto y visualización de resultados

2. Estrategia de ejecución del pipeline

Definir cómo se orquestan y ejecutan los diferentes pasos dentro de un pipeline de CI/CD (construcción, pruebas, análisis de seguridad, despliegue, etc.). Esto incluye la definición de los triggers, las etapas, los flujos de trabajo y las herramientas utilizadas en cada fase.

3. Entrega continua

Extiende la integración continua automatizando el proceso de preparación para la liberación del software a los entornos de desarrollo o prueba. Implica que el software está siempre en un estado potencialmente desplegable basado en las ramas de integración definidas.

4. Despliegue continuo

Va un paso más allá de la entrega continua, automatizando el despliegue del software a los entornos de producción después de que ha pasado por todas las etapas de pruebas y validaciones.