Quise trabajar como antes… pero la IA ya cambió todo

Hace unos días decidí rediseñar por completo mi sitio personal.

Como el cambio iba a ser grande, preferí iniciar un proyecto desde cero y conservar únicamente el contenido del anterior. Hasta ahí, una decisión bastante normal. La parte menos normal fue la restricción que me impuse: quería hacerlo sin herramientas de inteligencia artificial.

No porque hubiera dejado de confiar en ellas. Tampoco porque quisiera demostrar que todavía podía escribir un div sin asistencia emocional.

Quería practicar.

Después de meses trabajando con agentes, asistentes y flujos donde buena parte de la implementación puede delegarse, tenía la sensación de que necesitaba volver a construir algo como antes: crear el proyecto, instalar dependencias, configurar las piezas, escribir los componentes y resolver la integración con mis propias manos.

Ejecuté el comando del framework. Agregué dependencias. Configuré la base de datos. Empecé a levantar la estructura.

Un par de horas después tenía… el esqueleto.

No estaba bloqueado. No había aparecido un problema especialmente difícil. Simplemente estaba avanzando a la velocidad normal de una persona ensamblando las bases de una aplicación.

Y esa velocidad, que durante años me habría parecido razonable, empezó a sentirse extrañamente cara.

El diseño ya existía

Unos días antes había usado Stitch para experimentar con el rediseño. Quería probar la herramienta, pero el resultado me sorprendió lo suficiente como para tomarlo en serio.

Ahora tenía dos cosas frente a mí:

• una referencia visual bastante clara de lo que quería construir;
• un proyecto nuevo donde todavía estaba recreando sus fundamentos paso a paso.

La parte que seguía ya no era especialmente creativa. Había que traducir decisiones visuales a un tema, identificar tipografías, superficies, espaciados y colores, convertir patrones en componentes y después aplicar todo eso a las páginas.

Era trabajo real. También era un tipo de trabajo que un agente podía recorrer muchísimo más rápido si le daba la referencia y el contexto adecuados.

Así que abrí Claude desde OpenCode y le pedí que creara el tema a partir del diseño.

Lo hizo en unos minutos.

Después sugirió aplicar el sistema a las páginas existentes.

Acepté.

Mi pequeño experimento de "voy a construirlo como antes para no perder práctica" había durado menos que la configuración inicial del proyecto.

La primera reacción podría ser reducirlo a una comparación de velocidad: unas horas contra unos minutos. Pero esa no fue la parte que más me incomodó.

La parte interesante fue descubrir que yo ya no podía trabajar como antes fingiendo que el resto del proceso seguía igual.

La IA no solo aceleró el mismo trabajo

Cuando hablamos de asistentes de programación suele aparecer una imagen bastante cómoda: la persona sigue realizando el mismo oficio y la IA le ayuda a escribir algunas líneas más rápido.

Autocompletado con esteroides.

En ese modelo, prescindir de la herramienta únicamente significa avanzar un poco más lento. Como apagar el autocompletado del editor para comprobar que todavía recuerdas la sintaxis.

Mi experiencia con el rediseño no se sintió así.

El diseño ya estaba suficientemente definido. El framework ya tenía convenciones. El resultado esperado podía describirse y compararse. La mayor parte de la primera integración consistía en transformar una representación en otra.

En ese contexto, escribir manualmente cada pieza no era necesariamente la actividad donde más criterio estaba aportando. Era el lugar donde más tiempo estaba gastando.

Eso cambia la pregunta.

Ya no es solamente:

¿Cuánto más rápido puedo escribir este código con IA?

Se parece más a:

Si la implementación inicial puede aparecer en minutos, ¿dónde empieza ahora mi trabajo?

La respuesta fácil es "en el prompt".

La respuesta real es bastante menos cómoda.

Cuando el código aparece, empieza la revisión

Hace tiempo escribí sobre un PoC en Python que funcionaba exactamente como lo había pedido y, aun así, estaba mal planteado. Yo venía pensando en patrones de TypeScript; la IA obedeció y produjo una solución llena de metaclasses, introspección y magia que parecía un proyecto de NestJS disfrazado de Python.

La lección entonces fue que cuando el código funciona empieza la ingeniería.

Con agentes capaces de construir una integración completa, esa frontera llega antes y ocupa más espacio.

El agente puede convertir una referencia visual en componentes. Yo todavía tengo que decidir si entendió la jerarquía de la interfaz, si creó una abstracción útil o solo escondió duplicación detrás de un nombre elegante, si respetó las convenciones del proyecto, si el resultado funciona en móvil, si el modo oscuro conserva contraste y si el sitio sigue sintiéndose como el mismo producto.

También tengo que detectar algo más peligroso: una implementación técnicamente correcta que resuelve el problema equivocado.

Esa clase de error no siempre se ve en un build verde.

Una página puede renderizar, sus botones pueden responder y todos los tipos pueden estar satisfechos mientras la navegación rompe la estructura que el resto del producto ya había establecido. Un agente puede cumplir el encargo local y aun así introducir una excepción que nadie pidió.

La velocidad de generación no elimina esas decisiones. Las comprime.

Antes podía descubrir una mala dirección mientras escribía la tercera pantalla. Ahora puedo recibir las tres pantallas terminadas antes de haber formulado del todo por qué la primera se sentía extraña.

La nueva habilidad no consiste únicamente en pedir mejor. Consiste en evaluar antes de que la velocidad convierta una suposición en sistema.

Entonces, ¿estaba dejando de programar?

Esa era la inquietud detrás de mi restricción.

Si delegaba la creación del tema y la adaptación de las páginas, ¿qué estaba practicando yo? ¿Revisar diffs? ¿Escribir instrucciones? ¿Se puede conservar el oficio si cada vez se escriben menos líneas directamente?

Creo que parte del problema está en usar "programar" para describir demasiadas actividades distintas.

Programar puede ser recordar una API, escribir un componente, modelar un estado, encontrar una condición de carrera, diseñar un contrato, depurar una integración, reconocer una abstracción incorrecta o decidir que la solución más sofisticada no debería existir.

La IA reduce de forma brutal el costo de algunas de esas actividades. No reduce todas por igual.

En el rediseño, la parte mecánica de convertir una referencia visual en una primera versión del tema dejó de ser el cuello de botella. En cambio, se volvió más importante hacer explícitas decisiones que antes podían permanecer en mi cabeza mientras avanzaba lentamente:

• qué elementos forman el sistema visual y cuáles son excepciones;
• dónde termina una responsabilidad y comienza otra;
• qué debe ser un componente reutilizable;
• qué comportamiento pertenece a la página;
• cuáles son las condiciones de aceptación más allá de "se parece a la captura";
• qué partes requieren inspección humana porque todavía dependen de gusto, intención o contexto.

Eso también es programar, aunque produzca menos pulsaciones por hora.

No quiero romantizarlo. Revisar código generado no se convierte automáticamente en una actividad superior. Se puede aceptar todo sin entenderlo y terminar como operador de una máquina de deuda técnica extraordinariamente rápida.

Pero escribir cada línea tampoco garantiza comprensión. También es posible pasar una tarde copiando patrones, ajustando clases y conectando componentes sin cuestionar ninguna decisión importante.

El teclado nunca fue una prueba perfecta de criterio. Solo era una prueba muy visible de actividad.

Practicar sigue importando, pero necesita otro espacio

Eso no significa que debamos abandonar la implementación manual.

Sigo necesitando escribir código para mantener intuición sobre costos, límites y posibilidades. Si nunca construyo nada directamente, mi capacidad de evaluar lo generado terminará degradándose. No puedo reconocer una abstracción innecesaria si he olvidado qué problema intentaba resolver.

Lo que cambió para mí fue separar dos objetivos que estaba mezclando:

1. quiero terminar este producto;
2. quiero entrenar una habilidad.

Un proyecto real puede cumplir ambos, pero no siempre tiene sentido imponerle al primero todas las restricciones del segundo.

Si quiero practicar CSS, puedo reconstruir una sección sin ayuda y comparar después. Si quiero entender mejor el sistema de contenido, puedo implementar un componente pequeño, leer su salida y romperlo deliberadamente. Si quiero aprender una API, puedo crear un experimento acotado donde la lentitud sea parte del ejercicio.

Usar todo el rediseño del sitio como gimnasio era posible. También era una forma bastante costosa de fingir que el objetivo principal no era tener un sitio terminado.

Es parecido a decidir que para conservar práctica con bases de datos escribirás SQL a mano, pero además implementarás el driver, el protocolo de red y quizá una pequeña versión de PostgreSQL durante el fin de semana. En algún punto el ejercicio deja de entrenar la habilidad que querías y empieza a defender una ceremonia.

La práctica deliberada necesita fricción.

La producción no necesita fricción por nostalgia.

El cuello de botella se movió

Después de integrar el tema, el trabajo no desapareció. Cambió de forma.

Tuve que leer lo producido, entender cómo había interpretado la referencia, encontrar decisiones que no encajaban, ajustar convenciones y decidir qué quería conservar. La implementación inicial había dejado de ocupar el centro del proceso; el centro era ahora la intención y la evaluación.

Ese movimiento aparece cada vez en más partes de mi trabajo.

Cuando un agente puede recorrer un repositorio, proponer una arquitectura, modificar varios archivos y ejecutar validaciones, mi aporte no puede limitarse a redactar una petición y esperar un resultado bonito. Necesito construir el entorno donde la herramienta pueda actuar sin inventar la organización del proyecto en cada sesión.

Necesita fuentes de verdad. Límites. Convenciones. Criterios verificables. Formas de señalar incertidumbre. Y una persona capaz de distinguir cuándo el resultado cumple el texto de la instrucción pero traiciona su intención.

La IA no volvió irrelevante mi experiencia anterior. La convirtió en el filtro por el que pasan más decisiones en menos tiempo.

Eso tiene una consecuencia incómoda: si antes podía compensar una idea mediocre con muchas horas de implementación, ahora la mediocridad también escala más rápido.

Pero tiene otra bastante más interesante: puedo dedicar menos energía a demostrar que sé ensamblar las piezas y más a decidir qué vale la pena ensamblar.

Ya no puedo volver exactamente a "antes"

Podría terminar el sitio sin volver a abrir un agente. Técnicamente nada me lo impide.

Pero ya conocería el costo de oportunidad.

Cada hora dedicada a una integración que puedo delegar sería una decisión consciente, no la forma inevitable de hacer el trabajo. A veces esa decisión valdrá la pena porque quiero aprender, explorar o disfrutar la implementación. Otras veces solo estaría confundiendo esfuerzo con valor.

Eso fue lo que realmente cambió.

La IA no me quitó la capacidad de trabajar como antes. Me quitó la inocencia de creer que hacerlo era neutral.

Ahora necesito decidir cuándo escribir, cuándo delegar, qué revisar, dónde conservar fricción y cuál parte del oficio quiero practicar deliberadamente.

No terminé concluyendo que debía dejar de programar.

Terminé aceptando que "seguir programando" ya no puede significar simplemente seguir haciendo todo a mano.

Quise construir el sitio como antes para no perder práctica.

Y descubrí que la práctica que más necesitaba era aprender a trabajar después de que el código dejó de ser la parte lenta.