Donde la IA me ahorra tiempo y donde me ralentiza

Uso la IA todos los días y no querría volver atrás.

Probablemente esa sea la forma más sencilla de empezar. La IA me ha hecho más rápido, me ha ayudado a aprender más rápido y ha hecho que áreas enteras de la ingeniería parezcan más accesibles de lo que solían ser. Ha cambiado mi forma de empezar a trabajar, de buscar contexto, de escribir código, de probar y de moverme por partes de la arquitectura que antes me resultaban desconocidas.

En Webflow, hemos reflexionado mucho sobre dónde encaja la IA en el flujo de trabajo de ingeniería. No solo como generador de código, ni como un atajo para evitar el criterio propio, sino como una forma de ayudar a las personas a avanzar en el trabajo real de producto con más contexto y menos fricción.

Esa distinción es importante para mí porque los flujos de trabajo con IA más útiles rara vez consisten solo en escribir código más rápido. Se trata de conectar al asistente con el contexto, los sistemas y las restricciones adecuadas para que el trabajo comience más cerca de la realidad.

Pero la IA no ha hecho que la ingeniería sea mágicamente fácil.

El trabajo tedioso no desapareció. En algunos casos, solo se cambió de ropa y volvió con un currículum mejor.

Para mí, el mayor cambio es este:

La IA hizo que iniciar y ejecutar el trabajo fuera mucho más rápido.

La parte más lenta es todo lo que sucede después: revisar el resultado, entender las suposiciones, mantener las solicitudes de extracción (PR) lo suficientemente pequeñas para revisarlas, fusionar los cambios en el orden correcto y asegurarme de que todavía pueda explicar el código dos semanas después.

Ahí es donde reside el verdadero compromiso.

Antes del primer borrador

Antes de que la IA formara parte de mi flujo de trabajo diario, gran parte de la ingeniería consistía en buscar contexto.

Un día normal empezaba en lugares conocidos. Slack. Jira. Tareas asignadas. Confluence. Documentación interna. Documentación de herramientas. Documentación de frameworks. Luego, dependiendo de qué tan rápido se complicaran las cosas, Google, Stack Overflow, Reddit, GitHub Issues y, finalmente, algún compañero que quizás hubiera visto lo mismo antes.

A veces eso se convertía en programación en pareja. A veces en una sesión de depuración. A veces en dos horas probando cosas distintas y describiendo después el proceso como "investigación", lo cual es técnicamente cierto y emocionalmente generoso.

Eso fue especialmente cierto al principio de mi carrera, cuando me centraba principalmente en la ingeniería frontend. Pasar del frontend al backend, las bases de datos y el trabajo full-stack requería tiempo de verdad. Tenía que aprender nuevos sistemas, nuevos frameworks, nuevos modos de fallo y nuevos tipos de contexto.

React cambiaba. Las herramientas cambiaban. Las librerías cambiaban. Los paquetes de NPM no se instalaban por razones que se sentían personales.

Gran parte del trabajo no era solo escribir código. Era obtener el contexto suficiente para escribir el código correcto.

Y a veces, la parte más lenta de la tarea era todo lo que sucedía antes de la primera línea de código real.

La velocidad al empezar

La IA ha cambiado ese primer paso drásticamente.

Hoy, con MCP y herramientas conectadas, puedo obtener contexto relevante mucho más rápido. En lugar de saltar manualmente entre Slack, Confluence, Jira, documentos internos, documentación web y el código fuente, puedo pedirle a la IA que me ayude a recopilar y sintetizar esa información.

Esta es también la razón por la que MCP resulta interesante más allá del caso de uso de "la IA escribe código". MCP ofrece a los asistentes una forma más estructurada de trabajar con las herramientas y sistemas donde ya ocurre el trabajo real. Por ejemplo, la plataforma para desarrolladores de Webflow es compatible con MCP para que los agentes puedan trabajar con los flujos de trabajo de Webflow desde herramientas como Claude, Cursor, Postman u otros clientes compatibles con MCP.

Para mí, esa es una versión de la IA mucho más útil que un cuadro de chat vacío. No es solo un asistente que adivina desde fuera. Es un asistente que puede operar más cerca del flujo de trabajo real, con un contexto más claro y acciones más relevantes.

Si voy a empezar una nueva funcionalidad, puedo pedir el contexto sobre el ticket, conversaciones relacionadas, implementaciones similares, archivos relevantes, decisiones previas y las limitaciones que debería conocer antes de tocar el código.

Eso no elimina la necesidad de pensar.

Elimina gran parte de la búsqueda manual antes de que pueda empezar a pensar.

Esa diferencia importa. Hay mucho tiempo invisible en la ingeniería que no es exactamente programar, pero tampoco es exactamente planificar. Es el tiempo que se pasa intentando entender qué pasó antes, qué quiso decir alguien en un ticket, por qué un sistema funciona de cierta manera o si lo que estás a punto de construir ya existe bajo otro nombre.

La IA es muy buena reduciendo esa fricción.

Puede resumir hilos largos. Puede explicar rutas de código desconocidas. Puede comparar enfoques. Puede ayudar a convertir un contexto disperso en un primer mapa útil.

Aun así, tengo que revisar el mapa. Pero al menos no empiezo en medio de la nada con un ticket de Jira y un sueño.

Cuando la ejecución se vuelve más fácil

El siguiente gran cambio es la ejecución.

La IA hizo que sea mucho más fácil pasar de "no tengo ni idea de por dónde empezar" a "tengo un primer borrador funcional".

Ese primer borrador podría ser la implementación de una funcionalidad, una prueba, una consulta de base de datos, un script, una migración, un panel de Splunk o un cambio relacionado con AWS. Podría ser frontend, backend, infraestructura, observabilidad o alguna combinación extraña de todo ello, porque el software tiene sentido del humor.

Esto ha cambiado el tipo de trabajo que puedo asumir.

El trabajo full-stack parece más accesible. El trabajo de infraestructura parece menos intimidante. Las migraciones parecen más fáciles de razonar. Los paneles, las consultas y los sistemas desconocidos ya no parecen muros que tengo que escalar antes de poder avanzar.

La IA no te da experiencia por arte de magia. Pero puede acortar la distancia entre estar bloqueado y ser útil.

Eso ha sido especialmente valioso para mí, como alguien que empezó en frontend y evolucionó hacia un trabajo full-stack más amplio. Antes, entrar en un área nueva a menudo significaba pasar mucho tiempo solo aprendiendo el vocabulario del problema. Ahora puedo hacer mejores preguntas antes. Puedo obtener ejemplos más rápido. Puedo generar una primera versión, inspeccionarla, cuestionarla y aprender de ella.

La curva de aprendizaje sigue ahí.

La IA simplemente hace que sea menos solitaria.

Las pruebas son un buen ejemplo. No quiero que este artículo se convierta en una carta de amor a las pruebas, porque eso sería sospechoso. Pero la IA ha hecho que escribir pruebas sea más rápido y depurarlas más sencillo. Puede generar simulacros, sugerir casos que quizás no haya considerado, actualizar pruebas existentes y ayudar a razonar ante los fallos.

Aun así, debo asegurarme de que las pruebas tengan sentido. Un conjunto de pruebas que pasa solo es útil si está evaluando el comportamiento correcto. Pero la IA ha agilizado la mecánica, lo que me da más margen para pensar en la cobertura en lugar de pelearme con la forma de un objeto simulado durante media tarde.

Una pequeña victoria, pero una real.

Después del primer borrador

El problema es que la ingeniería de software no termina en el primer borrador.

Ahí es donde suelen empezar los problemas interesantes, esperando tranquilamente detrás de un conjunto de pruebas superadas y un asistente muy confiado.

Aquí es donde la IA empieza a ralentizarme.

Una solución generada puede parecer correcta. Puede compilar. Puede pasar las pruebas. Incluso puede estar escrita de forma limpia. Pero eso no significa automáticamente que sea la solución adecuada para el código, el producto o el equipo.

El modelo puede hacer suposiciones. Puede pasar por alto una restricción. Puede elegir un patrón que parezca razonable de forma aislada pero que no encaje con el funcionamiento real del sistema. Puede resolver un problema mayor que el que yo tenía. Puede introducir una abstracción que hoy parece elegante y el jueves resulta innecesaria.

Antes de la IA, gran parte de mi tiempo se iba en crear la primera versión: buscar, leer, preguntar, probar, depurar y reescribir.

Ahora la IA puede comprimir esa primera versión drásticamente.

Pero luego tengo que verificarla.

Tengo que leer el código generado como si estuviera revisando el trabajo de otra persona. Necesito entender por qué tomó ciertas decisiones. Debo comprobar los casos límite. Tengo que asegurarme de que las pruebas no solo pasen, sino que sean útiles. Debo confirmar que la implementación encaja en la arquitectura existente. Tengo que eliminar los cambios innecesarios.

Debo preguntarme si esta es la solución más pequeña y razonable, o si el asistente intentó remodelar la cocina solo porque le pedí que cambiara una bombilla.

Ese trabajo de revisión es importante.

Si me lo salto, la IA no me ahorra tiempo. Solo crea trabajo futuro con mejor formato.

El nuevo cuello de botella

La IA traslada el tiempo de la creación a la verificación.

Ese puede ser un buen intercambio. En muchos casos, lo es. Prefiero pasar más tiempo evaluando una solución que quedarme mirando una página en blanco o buscando entre seis pestañas tratando de recordar qué problema de GitHub coincidía con mi mensaje de error.

Pero la verificación sigue siendo trabajo.

Requiere criterio, contexto y disciplina. Requiere saber qué es lo que está bien hecho. Requiere entender el sistema lo suficiente como para decidir si la solución generada encaja ahí.

El código más rápido de generar no siempre es el más rápido de mantener.

Esa se ha convertido en una de las lecciones más importantes para mí. Si no puedo explicar el código, realmente no es mío. Si no puedo defender la decisión técnica, no debería publicarlo. Si no puedo depurarlo más tarde, entonces la IA no me ahorró tiempo. Le pidió tiempo prestado al futuro, y a mi "yo" del futuro rara vez le impresiona ese trato.

Esta es la parte de la ingeniería asistida por IA que parece menos glamurosa que las demostraciones.

La demostración termina cuando aparece el código.

El trabajo continúa cuando alguien tiene que mantenerlo.

Empezar demasiado

Hay otro cuello de botella que no esperaba: el trabajo en curso.

La IA hace que sea más fácil empezar a trabajar. Mucho más fácil. Puedo explorar una idea, generar una primera implementación, crear pruebas y abrir una solicitud de extracción (PR) más rápido que antes.

Eso es muy potente.

Pero empezar un trabajo no es lo mismo que terminarlo.

Cuando crear trabajo se vuelve más barato, es más fácil crear demasiado. De repente, hay más ramas, más PRs, más solicitudes de revisión y más cambios que dependen de otros cambios. Algunas PRs deben integrarse en un orden específico. Algunas necesitan contexto que reside en otra rama. Algunas son lo suficientemente pequeñas por sí solas, pero juntas crean una cola que el equipo todavía tiene que revisar, entender y fusionar.

El cuello de botella se desplaza de "¿Puedo construir esto?" a "¿Podemos absorber esto de forma segura?".

La IA puede acelerar la ejecución individual, pero el software sigue siendo un producto de equipo.

Eso significa que la coordinación sigue siendo importante. La revisión sigue siendo importante. La secuenciación sigue siendo importante. Mantener las PRs pequeñas sigue siendo importante. De hecho, puede que importe más ahora, porque el coste de generar demasiado trabajo ha disminuido.

Este es uno de los efectos más extraños de la IA. Puede hacerme sentir más productivo mientras, al mismo tiempo, genera más trabajo sin terminar a mi alrededor.

Más movimiento no siempre significa más progreso.

A veces, el progreso consiste en PRs más pequeñas, una secuencia más clara, menos ramas paralelas y la disciplina suficiente para terminar lo que ya empecé antes de pedirle a la IA que me ayude a empezar tres cosas más.

¿Qué ha cambiado realmente?

La IA me ahorra tiempo cuando me ayuda a encontrar contexto, sintetizar información, estructurar una solución o ejecutar la primera versión de un trabajo.

Esa es también la versión de la IA que mejor encaja con lo que estamos construyendo en Webflow: una IA conectada a flujos de trabajo reales, interfaces de producto reales y sistemas de publicación reales. El valor no reside solo en que un asistente pueda generar algo rápidamente. El valor está en que ayuda a las personas a pasar del contexto a la creación y a la publicación con menos carga manual, dejando espacio para el criterio y la responsabilidad humana.

Me ralentiza cuando la parte difícil ya no es escribir código, sino verificarlo, secuenciarlo, revisarlo y hacerme responsable de él.

Ese intercambio merece la pena.

Soy mucho más rápido con la IA que sin ella. Puedo trabajar en más áreas de la pila tecnológica. Puedo desbloquearme más rápido. Puedo construir cosas que antes me habrían llevado mucho más tiempo. Paso menos tiempo buscando contexto y más tiempo tomando decisiones.

Pero la IA no eliminó las partes difíciles de la ingeniería.

Las desplazó.

El trabajo consiste menos en empezar desde una página en blanco y más en saber qué es lo que está bien. Se trata menos de ensamblar manualmente cada pieza de contexto y más de validar si el panorama resultante es correcto. Se trata menos de escribir cada línea uno mismo y más de hacerse responsable de cada línea que se publica.

Esa es la versión de la IA en ingeniería que me parece real.

No es magia. No es un reemplazo. No es un atajo para evitar el criterio propio.

Es un asistente muy rápido que me ahorra mucho tiempo, siempre y cuando recuerde que sigo siendo el ingeniero responsable del resultado.