Skip to content
Volver a todos los artículos

Herramientas de codificación con IA en 2026: qué cambia en un proyecto de cliente

8 min de lectura
Ilustración isométrica de un asistente de codificación con IA sobre un fondo oscuro: un editor de código con líneas generadas, un panel de autocompletado, un asistente que entiende el contexto, una revisión de diff y un gráfico de "tiempo ahorrado"

Diseño la mayor parte de lo que construyo, y he usado asistentes de codificación con IA en el trabajo con clientes desde que eran un autocompletado con buenos modales. La actualización sincera para 2026 es que se han vuelto lo bastante rápidos como para cambiar cómo se define el alcance de un proyecto, no solo cómo se teclea una función — y lo bastante rápidos como para que los errores que cometen también sean más fáciles de publicar sin darse cuenta.

Esto no es una comparación de herramientas. Es dónde la aceleración es real en un proyecto de cliente remunerado, dónde no lo es, y qué cambió en cómo reviso mi propio trabajo a raíz de ello.

Ahora el andamiaje es rápido; el criterio sigue sin serlo

Pídele a un modelo actual que construya una página de ajustes con un formulario, validación y un estado de guardado, y producirá algo que funciona en menos de un minuto. Antes eso eran veinte minutos de teclear. Lo que no ha cambiado es decidir qué debería contener realmente la página de ajustes, qué pasa cuando la petición de guardado falla y si este es siquiera el patrón adecuado para los datos de este cliente en concreto.

Esa división lo resume todo. Teclear se abarató; decidir qué teclear siguió siendo exactamente igual de caro que siempre, porque depende de un contexto que el modelo no tiene — los usuarios reales del cliente, los casos límite de los tickets de soporte del último trimestre, la restricción que nadie anotó. Vender que "la IA escribe tu aplicación" se salta la mitad del trabajo que nunca fue teclear.

Dónde la aceleración es real

El boilerplate y la repetición son donde esto se amortiza cada vez: un componente que necesita cinco variantes casi idénticas, convertir una hoja de cálculo de textos en objetos de contenido tipados, escribir el test número cuarenta para el trigésimo noveno patrón ya establecido en el código. El modelo tiene contexto local de sobra y la tarea tiene una única forma obviamente correcta.

Las migraciones son la otra victoria clara. Subir la versión mayor de una biblioteca de UI, renombrar una prop en cuarenta usos, convertir componentes de clase en hooks: cambios mecánicos, de gran volumen y poco criterio que antes se comían un día entero y ahora llevan una tarde de generación más revisión.

También es una combinación genuinamente buena para el trabajo de tokens a código: entregar los tokens de espaciado y color de un archivo de Figma y obtener una primera versión de una configuración de tema de Tailwind generada a partir de ellos, y luego corregir los valores a mano, es más rápido que teclear el objeto desde cero.

Dónde cuesta tiempo sin que te des cuenta

Cualquier cosa que toque una base de código que el modelo no ha visto de forma efectiva —un proyecto de cliente heredado, grande e idiosincrásico, una configuración no estándar de gestión de estado, una biblioteca interna con sus propias convenciones— produce código que parece correcto y está sutilmente mal: un hook llamado en el orden equivocado, un tipo que compila pero no coincide con la forma real de la respuesta de la API. Estar equivocado con seguridad es peor que estarlo de forma evidente, porque supera una lectura rápida.

El código sensible en materia de seguridad es el otro lugar donde no delego el primer borrador: comprobaciones de autenticación, cualquier cosa que toque pagos, cualquier cosa que decida lo que un usuario puede ver. El modo de fallo ahí no es un informe de error, es la exposición de los datos de un cliente, y ese no es un riesgo que compense por los minutos ahorrados.

En resumen, en una base de código desconocida o poco habitual, el tiempo de revisión puede superar el tiempo ahorrado en la generación. La herramienta es más rápida precisamente allí donde ya conocías la base de código lo bastante bien como para apenas necesitarla.

La disciplina de revisión cambia, no desaparece

Trato el código generado como trataría una pull request de un desarrollador junior rápido y seguro de sí mismo que nunca ha conocido a este cliente en concreto: leer cada línea antes de que se publique, no dar por hecho que los tests que escribió cubren de verdad el caso que importa, y contrastar el diff con lo que pedía el ticket en lugar de con lo que parece plausible.

El hábito concreto que más me ha salvado: pedirle al modelo que me explique su propio cambio en lenguaje llano antes de aceptarlo. Allí donde la explicación no coincide con lo que hace realmente el diff, esa discrepancia suele ser donde está el bug.

Qué significa esto para los precios y el alcance

Que la generación sea más rápida no significa que el trabajo valga menos; significa que una parte mayor de lo que paga un cliente es criterio, revisión y gusto en lugar de pulsaciones de teclado, y podría decirse que eso siempre fue el verdadero entregable. No he bajado las tarifas porque una herramienta acelerara el tecleo — he usado el tiempo que liberó para dedicar más horas de un proyecto a las partes que aún necesitan a una persona: los estados que nadie especificó, los casos límite que el ticket no mencionó, las pruebas en un dispositivo de verdad.

Donde sí ha cambiado un presupuesto: los trabajos pequeños, bien acotados y mecánicos —una migración, un lote de componentes parecidos— son ahora genuinamente más rápidos de entregar, y los presupuesto en consecuencia en lugar de inflar la estimación hasta un baremo previo a la IA por costumbre.

El stack que combina bien con ello

El código generado es tan bueno como las restricciones que lo rodean. Una base de código fuertemente tipada le da al modelo, y a quien revisa, una comprobación inmediata y mecánica de que un cambio es al menos internamente coherente. Una base de código con convenciones claras y una biblioteca de componentes que el modelo puede ver le da un patrón que imitar en lugar de inventar uno nuevo cada vez.

Next.js y Tailwind combinan especialmente bien con este flujo de trabajo: las clases utilitarias de Tailwind son inequívocas de una manera que los nombres de clases CSS personalizadas no lo son, así que el marcado generado rara vez se aparta de los tokens de diseño, y una interfaz de props tipada detecta una discrepancia de inmediato en lugar de en tiempo de ejecución delante del cliente.