Saltar al contenido
SwankyForge
SwankyForge
Todos los insights
Artículo9 min de lectura

Con un asistente de IA en cada repositorio, automatizamos las comprobaciones y dejamos cinco decisiones en manos de personas

Cómo trabaja el equipo de ingeniería con asistentes de IA para programar: qué se ejecuta automáticamente en cada cambio, qué decide siempre una persona y qué no hemos medido todavía.

La mayor parte del trabajo de ingeniería en nuestros repositorios empieza ahora con un asistente de IA para programar que escribe un primer borrador. Nada de ello se publica por la palabra del asistente. Esta nota describe la configuración tal como existe en el repositorio que hay detrás de este sitio web, porque es la que podemos mostrar en público. También enumera las decisiones que mantenemos en manos de personas y el número que todavía no podemos darle.

La versión corta, si está comprando

Somos un pequeño laboratorio de dos ingenieros, con especialistas que se suman según el proyecto. Un asistente de IA trabaja junto a ambos. Redacta código, tests, documentación e informes rutinarios. En cada cambio se ejecutan comprobaciones automáticas que bloquean los que rompen una regla. Una persona lee cada cambio antes de que se fusione. Nada llega a producción ni al público sin un sí explícito.

Lo que obtiene con esto: los mismos dos ingenieros cubren más del trabajo rutinario que los equipos pequeños tienden a saltarse, como tests, documentación y comprobaciones de release. Eso deja más presupuesto para las partes que necesitan criterio: elegir la métrica, decidir si vale la pena construir un modelo e integrarlo en su proceso.

Lo que no afirmamos: una cifra de aceleración. No la hemos medido, y la evidencia externa dice que las aceleraciones autodeclaradas no son fiables. Las últimas secciones explican qué mediríamos y qué significa esto para un cliente.

Qué dice la investigación: la herramienta no es la mejora

Cuatro estudios de 2025 determinaron cómo lo configuramos.

  • El programa DORA de Google encuestó a cerca de 5.000 profesionales de tecnología para su informe de 2025. El 90% usa IA en el trabajo, y más del 80% cree que le ha hecho más productivo. Sin embargo, el 30% declara poca o ninguna confianza en el código que genera. La conclusión del informe es que la IA amplifica lo que ya existe: los equipos sólidos mejoran, y los equipos con dificultades ven cómo sus problemas se intensifican.
  • El Technology Report 2025 de Bain encontró que los equipos que usan asistentes de IA para programar obtienen mejoras de productividad del 10–15%. Algunas empresas declaran un 25–30%, pero solo cuando la IA va acompañada de un rediseño de todo el proceso. Una razón por la que la primera cifra es pequeña: escribir y probar código ocupa alrededor del 25–35% del tiempo desde la idea hasta el lanzamiento.
  • La Stack Overflow Developer Survey de 2025 encontró que el 84% de los encuestados usa o planea usar herramientas de IA, y que el 46% desconfía de la exactitud del resultado. La frustración más común era un resultado casi correcto, pero no del todo.
  • METR realizó un ensayo aleatorizado con 16 desarrolladores open source con experiencia sobre 246 tareas reales. Con herramientas de IA permitidas, las tareas tardaron un 19% más. Los desarrolladores esperaban una aceleración del 24% y, después, seguían creyendo que habían sido un 20% más rápidos. Los autores advierten de que el resultado es específico de su contexto: proyectos open source grandes y maduros, y desarrolladores con poca experiencia con la herramienta utilizada.

Leídos en conjunto, los estudios dicen tres cosas. Adoptar un asistente es fácil. La mejora depende del proceso que lo rodea. Y la impresión de nadie sobre su propia velocidad es evidencia. Por eso pusimos el esfuerzo en el proceso (instrucciones, comprobaciones y puntos de aprobación) y no en la elección de herramienta.

Qué hace el asistente en nuestro repositorio

Usamos Claude Code. Cinco piezas hacen predecible su trabajo.

Instrucciones de proyecto. Un archivo en la raíz del repositorio le dice al asistente qué está dónde, qué reglas son estrictas y qué comandos ejecutar. Está versionado como el código, así que un cambio en las reglas aparece en la revisión como cualquier otro cambio. Cualquiera con acceso al repositorio puede leer exactamente qué se le dijo al asistente.

Skills para tareas recurrentes. Una skill es un procedimiento escrito corto que el asistente sigue para un tipo de tarea. Tenemos ocho: redactar un caso de estudio con su registro de evidencia, redactar una nota de ingeniería, redactar una publicación para la página de empresa, generar un perfil para una plataforma externa, revisar textos en busca de nombres confidenciales y datos personales, una auditoría de solo lectura de las señales de confianza del sitio, un informe de estado semanal y la clasificación de las consultas entrantes. Cada skill indica dónde se detiene. Ninguna termina publicando nada.

Hooks. Las acciones del asistente pasan por scripts que escribimos nosotros. Después de que edite un archivo, ese archivo se escanea en busca de nombres confidenciales y datos personales, y un hallazgo devuelve al asistente a corregirlo. Antes de que pueda ejecutar un git commit o push, una protección ejecuta el escaneo de confidencialidad y el lint de afirmaciones sobre lo que está a punto de salir del árbol de trabajo. Cualquier hallazgo bloquea el comando. Un hook pre-commit de git normal aplica las mismas comprobaciones a los commits hechos a mano.

CI en cada push y pull request. El pipeline ejecuta lint, comprobación de tipos y un build, y después tres protecciones:

  • el escaneo de confidencialidad, sobre el código fuente, el contenido y el HTML renderizado. Si falta su configuración, falla en lugar de pasar en silencio;
  • el lint de afirmaciones, que rechaza una lista de superlativos y frases de autoridad prestada;
  • el validador de contenido, que rechaza un caso de estudio sin registro de evidencia, un diseño de referencia que declare números medidos y una cifra de la página de inicio que no enlace al caso del que procede.

Estas reglas son mecánicas a propósito. Un asistente produce texto plausible rápidamente, y lo plausible pero incorrecto es exactamente el fallo que describen las encuestas. Una regla que se ejecuta en cada commit no depende de que nadie, persona o modelo, se acuerde de tener cuidado.

El pipeline de contenido. Todo lo destinado al público pasa por tres carpetas: borradores, aprobado, publicado. Una skill puede escribir en borradores y en ningún sitio más. Solo el propietario ejecuta el paso de aprobación, que vuelve a ejecutar ambos escaneos antes de mover el archivo. La publicación es manual: una publicación aprobada se envía al propietario como texto listo para pegar, y una nota aprobada sale en línea solo con el siguiente push aprobado a main. Esta nota siguió ese camino. Un asistente la redactó a partir de los propios archivos del repositorio, los escaneos se ejecutaron sobre ella y llegó a esta página después de que una persona la aprobara.

Qué nunca delegamos

Cinco decisiones se quedan en manos de personas, hagan lo que hagan las herramientas.

  1. Acordar la métrica con el cliente. Qué número define el éxito, cómo se mide y qué umbral cuenta como terminado. Lo escribimos en el contrato antes de empezar el entrenamiento. Un asistente puede listar métricas candidatas. No puede saber sobre cuál actuará su negocio.
  2. Juzgar si el ML vale la pena. A veces la respuesta honesta es una regla, un informe o un cambio de proceso. «Todavía no haga ML» es una recomendación que hacemos, y es un juicio sobre su situación, no una tarea de generación de texto.
  3. Aprobar releases. Una fusión a main despliega. Nada se sube a main sin un sí explícito del propietario, y los permisos del asistente excluyen el force-push.
  4. Hablar con el cliente. Llamadas, respuestas escritas, malas noticias. Una skill puede redactar una respuesta a una consulta; una persona la lee, la edita y la envía. Ningún script contacta con un lead.
  5. Decidir qué se hace público. Publicaciones, notas, perfiles, casos de estudio y releases de código. El pipeline hace de la publicación un paso deliberado y no un comportamiento por defecto.

El hilo común es la responsabilidad. Cada una de estas decisiones tiene consecuencias de las que alguien debe responder, y ese alguien tiene que ser una persona. En un proyecto, es el único ingeniero con nombre que se queda con el trabajo de principio a fin.

Qué no hemos medido

No tenemos una cifra de antes y después de nuestra propia productividad, y no vamos a citar ninguna. El resultado de METR es el motivo: desarrolladores que eran un 19% más lentos creían ser un 20% más rápidos. Una impresión, incluida la nuestra, no es una medición.

Si publicamos un número, llevará la misma etiqueta de evidencia que nuestros casos de estudio (medido, estimado o ilustrativo), y saldrá de registros como estos, recogidos durante una ventana declarada:

  • el tiempo desde que se abre una incidencia hasta un cambio revisado y fusionado, para tipos de tarea comparables;
  • la proporción de cambios fusionados que se revierten o corrigen en 14 días;
  • los problemas detectados por hooks y CI antes de la fusión, frente a los defectos encontrados después;
  • el tiempo de revisión por cambio, porque la revisión es donde el resultado de un asistente cuesta tiempo a las personas;
  • las horas por hito frente a la estimación de nuestra calculadora.

Hasta entonces, la afirmación honesta es más acotada. Las comprobaciones se ejecutan en cada cambio, y las cinco decisiones anteriores las toman personas.

Qué significa esto para usted

Se hace más trabajo rutinario. Con un presupuesto fijo, los tests, la documentación, la monitorización y las comprobaciones de release son lo primero que recortan los equipos pequeños. Un asistente los abarata, y las comprobaciones hacen difícil saltárselos.

El precio va al criterio. Nuestras tarifas y las horas detrás de cada rol están publicadas en la página de precios, y la calculadora muestra la aritmética. Las horas que más importan son las dedicadas a la métrica, la evaluación y la integración con su proceso: las partes que ningún asistente hace por nosotros. Si no está seguro de que el ML sea la respuesta correcta, el teardown gratuito da un primer veredicto en seis preguntas, y un discovery corto de pago lo resuelve antes de entrenar ningún modelo.

Puede inspeccionar la configuración. El repositorio vive en su organización desde el primer día. Si un asistente trabaja en él, sus instrucciones y comprobaciones también están en ese repositorio, junto al historial de cada cambio, donde puede leerlas.

Haga a cada proveedor las mismas preguntas. ¿Qué herramientas de IA verán su código y sus datos, y en qué condiciones? ¿Qué comprobaciones se ejecutan en cada cambio, y bloquean o solo avisan? ¿Quién aprueba un release? ¿Ha medido el proveedor su propia aceleración, y cómo? Las respuestas le dicen si la IA en su proceso amplifica la disciplina o la falta de ella.

Fuentes

¿Tiene un proceso que cuesta demasiado?

Cuéntenoslo. La primera llamada es gratuita y, si la IA no es la respuesta, se lo decimos.

Hablar de su tarea