Abrazando una nueva era de la programación

Si pensabas que cada nueva herramienta solo elevaba un poco la productividad, ya toca cambiar la pregunta. Lo que está ocurriendo ahora no es simple automatización; está cambiando el lugar mismo en el que los desarrolladores invierten su tiempo. Este texto es un registro de cómo he sentido ese cambio en los últimos meses y de los criterios con los que empecé a aceptarlo.

El problema no es la velocidad, sino el desplazamiento del rol.

Yo, hace 3 meses#

Hasta hace apenas 3 meses, veía la IA generativa como poco más que una herramienta de autocompletado muy inteligente.

Cuando usé GitHub Copilot por primera vez, sí me impresionó. Si escribía el nombre de una función o dejaba un comentario, generaba una implementación bastante plausible, y estaba claro que reducía el trabajo repetitivo. Pero hasta ahí llegaba. Pensaba que podía ser una herramienta que mejorara un poco la productividad, no algo capaz de cambiar el rol del desarrollador en sí.

Después probé Gemini CLI. La experiencia de crear y modificar código conversando desde la terminal me resultó bastante fresca. Parecía tener una interacción más natural que Copilot y una mejor comprensión del contexto. Aun así, seguía pensando casi lo mismo. Al final, creía que no dejaba de ser una herramienta más avanzada, y que el diseño real y las decisiones importantes seguían siendo mi responsabilidad.

Luego me encontré con Cursor. La experiencia de ver todo el IDE integrado con IA sí se sentía distinta a lo anterior. Al verlo moverse entre archivos, modificar código, entender en cierta medida la estructura del proyecto y hasta sugerir refactors, sentí que había dado un paso más. Pero incluso entonces pensaba que la lógica de negocio compleja y el diseño de arquitectura debían seguir en manos humanas hasta el final. Si soy sincero, también creía que mi lugar no se iba a mover demasiado.

Mirándolo ahora, en ese momento estaba subestimando por completo la velocidad del cambio. En la práctica, el punto de inflexión empezó a fines de noviembre de 2025, cuando salió Opus 4.5.

Me golpeó de lleno#

La razón por la que cambié de idea no fue nada grandilocuente. El desarrollo y la operación de este mismo blog son la prueba.

El servicio del blog no es, por sí solo, la implementación más difícil del mundo. Aun así, antes habría calculado desde varios días hasta varias semanas entre planear, construir pantallas, pulir la forma de despliegue y ordenar las conexiones pequeñas. Ahora ese tipo de trabajo puede levantarse en muy poco tiempo, más o menos dentro de un día.

La experiencia de llevar el diseño, la implementación, la limpieza y la preparación para la publicación hasta una etapa publicable con apenas unos cuantos prompts se sintió mucho más radical de lo que esperaba.

Lo que hoy me provocan los agentes de código es miedo.

Porque pude sentir que la pericia que acumulé durante años podía comprimirse en otra forma mucho más rápido de lo que imaginaba. Durante todo ese tiempo entendí el avance de las herramientas de IA para programar de manera lineal. De Copilot a Gemini CLI, y de Gemini CLI a Cursor, pensaba que todo simplemente iba mejorando poco a poco. Pero en algún momento el cambio se sintió como si hubiera llenado de golpe una brecha que antes parecía vacía y lejana.

Para quienes todavía no han probado de verdad la combinación de Claude Code con Opus 4.5, este texto puede sonar algo exagerado. Yo mismo habría pensado lo mismo hace unos meses. Pero viéndolo ahora, esto se parece menos a que escribir código se volvió un poco más cómodo y más a un cambio que vuelve a definir en qué debería invertir su tiempo un desarrollador.

Del miedo al criterio#

No creo que haga falta ocultar que la primera emoción que me llegó fue el miedo. A medida que la implementación se acelera, también puede sentirse como si el valor del desarrollador se estuviera reduciendo.

De hecho, en la industria se habla cada vez más de una era en la que personas por cuenta propia, especialmente en roles cercanos a los de application builder, pueden crear productos y lograr resultados mayores con menos gente. Antes, ese tipo de discurso me sonaba algo exagerado. Pero después de sentirlo de primera mano, esas palabras pesan distinto.

Eso no me llevó a una conclusión simple. No creo que el papel humano vaya a desaparecer. Más bien al contrario: cuando menos personas pueden hacer cosas más grandes, la capacidad de criterio y los estándares de revisión de cada persona se vuelven mucho más importantes.

Antes, la velocidad de implementación solía ser la mayor restricción de un equipo. Ahora las preguntas más importantes son qué construir, en qué orden validarlo y dónde controlar el riesgo.

En ese punto, terminé aferrándome a tres criterios.

• Definir el problema con claridad
• Diseñar un contexto que la IA pueda entender
• Hacer que una persona asuma la responsabilidad del resultado final

Cuanto más rápido avanza la tecnología, más peso tienen precisamente estos tres puntos.

La evolución de las herramientas, y Claude Code#

Si resumo de forma simple la trayectoria que he sentido, sería algo así.

• Copilot estaba más cerca del autocompletado. Tú marcabas la dirección y la herramienta aceleraba el siguiente paso.
• Gemini CLI se acercaba más a un asistente conversacional. Hacías preguntas, recibías respuestas y armabas el resultado de forma gradual.
• Cursor se sentía como un pair programmer muy inteligente. Intentaba entender el contexto del proyecto y empujaba la implementación junto conmigo.

En cambio, Claude Code se sintió más como un agente que dio un paso adicional. Si le das un objetivo, revisa los archivos relacionados, entiende la estructura, conecta los cambios necesarios y sigue pensando hasta los puntos que todavía hay que verificar.

Claro, los resultados no siempre son perfectos. Pero la diferencia importante es que me mueve rápido de ser quien escribe cada línea con sus propias manos a ser quien define la dirección, establece los criterios y revisa el resultado.

Por eso ahora mi rol ya no se parece solo al de alguien que implementa, sino más al de un arquitecto y un revisor. Más importante que qué tan rápido escribo código es decidir en qué unidades delegar cada objetivo, qué automatizar y qué revisar personalmente hasta el final.

Yo, ahora#

Hoy desarrollo usando IA de forma activa. Decir que mi productividad subió se queda corto frente a cuánto cambió mi manera de trabajar. Ya no es raro que una función que antes habría tomado varios días empiece a tomar forma dentro de un solo día.

Eso no significa que el papel humano se haya reducido. Al contrario, la seguridad, el manejo de excepciones, la integridad de los datos, la consistencia estructural y el criterio de producto regresaron con una responsabilidad aún mayor.

El cambio interesante es que la velocidad de desarrollo en sí ya no es el cuello de botella. Antes, la restricción central era cuántos días tardaríamos en implementar una función. Ahora importa mucho más si esa función realmente hace falta, con qué criterios la vamos a experimentar y validar, y hasta dónde consideraríamos completa la primera versión del producto. El peso de la calidad del criterio sobre el resultado ha crecido más que el de los límites técnicos.

Por eso, últimamente, antes de empezar a trabajar, primero escribo en frases el propósito de la función, las condiciones de éxito y el alcance excluido. Después divido el trabajo en unidades pequeñas y, al final, separo los puntos que una persona debe revisar directamente. Cada vez siento más que usar bien la IA no consiste en lanzar más pedidos de forma vaga, sino en establecer criterios más claros.

Lo que sigue#

Mi objetivo es claro. Quiero desarrollar servicios de nivel de producción en poco tiempo y convertir ese proceso en algo repetible.

Ahora, para mí, desarrollar ya no es solo escribir código, sino llevar un producto hasta un nivel que pueda sostenerse incluso en un entorno real de operación. Quiero comprobar por mí mismo hasta dónde puede llegar este cambio.

Por eso quiero seguir escribiendo este blog. No será solo un espacio para ordenar resultados, sino un registro de cómo fui incorporando estas herramientas, en qué puntos cambió mi perspectiva y con qué criterios me estoy adaptando. Tenga éxito o fracase, creo que vale la pena dejar constancia de las ideas y la prueba y error de esta etapa.

La nueva era de la programación no está eliminando el rol del desarrollador; lo está comprimiendo y volviendo más nítido. El centro de gravedad se está moviendo desde la época en la que uno escribía cada línea por sí mismo hacia una etapa en la que lo importante es definir bien el problema y verificar el resultado.

Creo que la diferencia que viene no se va a abrir por quién produce más código, sino por quién puede repetir mejores decisiones con mayor rapidez y generar resultados que realmente sean operables.