Artículo
Linux Foundation: productividad con IA
Linux Foundation anunció el 20 de octubre de 2026 un informe sobre IA generativa y desarrollo de software libre.
Escribir una solución y entregar una mejora que otra persona pueda usar son avances distintos. Un equipo puede producir código con rapidez y seguir esperando revisiones, corrigiendo errores o resolviendo incompatibilidades. Para decidir dónde aporta una herramienta de IA, conviene mirar el recorrido completo y definir qué significa terminar. Esta lectura separa los resultados atribuidos a una encuesta de una propuesta editorial para evaluar el trabajo propio.
Qué informa la encuesta
La encuesta web de Linux Foundation Research reunió 234 respuestas cualificadas, con 45 preguntas y campo entre abril y junio de 2026. Se distribuyó por canales de la fundación y socios. Declara ±6,41% al 95% de confianza. Sus figuras informan: 52% menos tiempo estimado de autoría de código (n=96; figura 19, p. 23); media estimada del 25% de PR con IA de baja calidad (n=111; figura 2, p. 10); y 21% que declara tardar más en tareas complejas (n=136; figura 21, p. 25).
Son autoinformes retrospectivos, no un experimento ni una auditoría de repositorios. La captación y el margen declarado no prueban representatividad. La tabla metodológica revisada, p. 29, no detalla países ni ponderación; no se afirma su ausencia del informe completo.
Un PR, o solicitud de incorporación de cambios, permite proponer código para su revisión antes de integrarlo. Quien evalúa una propuesta necesita entender qué resuelve, cómo se comprobó y qué podría romper. Por eso, en nuestro criterio de evaluación, producir más propuestas no equivale a entregar más mejoras. El trabajo que llega a revisión también consume atención de otras personas.
Define el final antes de medir el comienzo
Una definición de terminado puede exigir que la necesidad esté resuelta, que las comprobaciones pertinentes pasen y que exista una persona responsable de aceptar el resultado. Debe escribirse antes de comparar herramientas. Si una versión se considera terminada cuando genera código y otra sólo después de probarse, se están comparando fronteras diferentes.
Separar fases ayuda a encontrar dónde cambia el esfuerzo. La autoría produce la propuesta inicial. La revisión examina intención, claridad y riesgos. El retrabajo corrige lo que no cumplió el encargo. La integración comprueba que el cambio encaje con el sistema y pueda entregarse. Una mejora en una fase merece atención, pero no permite omitir las demás del balance.
También conviene distinguir esfuerzo y espera. Los minutos que una persona dedica a revisar no son lo mismo que las horas transcurridas hasta que alguien puede hacerlo. Reducir trabajo activo puede ser valioso aunque el plazo siga igual; acortar la espera puede mejorar el plazo sin reducir el esfuerzo. Registrar ambas magnitudes por separado evita sumar tiempos incompatibles.
Un único caso hipotético con el mismo criterio
Imaginemos un equipo que mantiene un catálogo y necesita corregir la validación de un formulario. Todo el caso, incluidos sus tiempos, es ficticio: no describe una prueba realizada, no reproduce los porcentajes del estudio y no estima el resultado de ningún producto. Las dos columnas representan formas propuestas de completar la misma tarea.
El criterio de aceptación es idéntico: el formulario admite los datos válidos, explica los errores previstos y conserva el comportamiento que ya funcionaba. El responsable revisa los cambios y comprueba esos recorridos. El reloj de esfuerzo cuenta el trabajo de todas las personas participantes; no incluye tiempos de espera ni permite contar un mismo minuto en dos fases.
| Fase | Referencia ficticia | Con asistencia ficticia |
|---|---|---|
| Autoría | 60 minutos | 30 minutos |
| Revisión | 20 minutos | 35 minutos |
| Retrabajo | 10 minutos | 20 minutos |
| Integración | 10 minutos | 15 minutos |
| Total | 100 minutos | 100 minutos |
La autoría baja de 60 a 30 minutos: una reducción ficticia del 50%. Sin embargo, revisión, retrabajo e integración suman 30 minutos adicionales: 15 más, 10 más y 5 más, respectivamente. El total permanece en 100 minutos; la reducción del esfuerzo completo es cero. El cálculo ilustra por qué hay que declarar la frontera medida, no que la asistencia produzca necesariamente este resultado.
La siguiente pregunta sería qué exigió esa revisión adicional. Podrían faltar explicaciones, haberse ampliado el alcance o aparecer cambios innecesarios. Son hipótesis para investigar en el mismo caso, no causas demostradas. Antes de cambiar de herramienta, el equipo puede revisar el encargo y la forma de presentar la propuesta. Cualquier comparación posterior necesitaría registros propios y criterios consistentes.
Busca el cuello de botella sin esconder el trabajo
Si la revisión limita la entrega, aumentar propuestas pendientes puede cargar aún más a quien revisa. Una intervención razonable sería reducir el tamaño de cada cambio, explicitar sus riesgos y aportar comprobaciones que respondan a la necesidad. Un revisor debería poder decidir qué aceptar o corregir sin descifrar una solución entera desde cero.
El criterio no debería ser aceptar todo lo generado ni rechazarlo por su origen. Conviene pedir la misma evidencia de calidad a cualquier propuesta y ajustar la revisión al riesgo del cambio. Una modificación de permisos merece controles distintos de un ajuste de texto. Generar más comprobaciones tampoco sustituye comprobar que sean pertinentes para el comportamiento esperado.
Al registrar el trabajo, conserva las correcciones y las propuestas descartadas. Excluirlas del cómputo haría parecer más eficiente un recorrido que consumió recursos sin llegar a una entrega aceptada. Del mismo modo, el tiempo de una persona que ayuda o revisa sigue formando parte del esfuerzo del equipo, aunque no aparezca en la sesión de quien escribió el código.
Diseña una comparación que sirva para decidir
Antes de comenzar, anota tarea, alcance, criterio de aceptación y fases que vas a observar. Registra por separado esfuerzo, espera, defectos detectados y resultado aceptado. Conserva quién revisó y qué quedó pendiente. No conviertas dos tareas de dificultad distinta en una comparación causal sólo porque se completaron en semanas consecutivas.
La lectura sobre Mercury y la velocidad con criterio permite continuar esta distinción entre rapidez técnica y resultado útil. Nuestra propuesta es decidir por una combinación de calidad, esfuerzo completo y capacidad de revisión. Si falta evidencia, corresponde conservar la duda y mejorar el registro, sin proclamar ahorro ni fracaso general.
Preguntas frecuentes
¿Cómo registro una tarea que todavía no se acepta?
Como pendiente, con el esfuerzo ya consumido y el motivo de bloqueo. No la cuentes como entrega terminada ni borres sus intentos. Separar trabajo en curso de entregas aceptadas permite revisar dónde se acumulan las dificultades.
¿Qué hago si cambia el alcance durante la comparación?
Anota el cambio y conserva las condiciones anteriores. Puedes separar el tramo adicional o declarar que los resultados ya no son comparables directamente. Corregir una necesidad nueva no debe confundirse con retrabajo por un fallo del encargo original.
¿Quién debería aceptar el resultado?
Una persona con responsabilidad sobre la necesidad y criterio para revisar sus riesgos. Definir ese rol antes del trabajo evita que el autor y el revisor utilicen finales distintos. La aceptación debe referirse al comportamiento acordado, no sólo a que exista código.
Visita la Comunidad IA.
