Las habilidades de los desarrolladores de GitHub AI pasan de escribir código a dirigirlo

GitHub actualizó sus recomendaciones profesionales para desarrolladores el 2 de octubre e identificó tres habilidades para desarrolladores de GitHub AI que cobran importancia a medida que los agentes asumen más trabajo de implementación. La empresa sostiene que los desarrolladores deben aprender a dirigir agentes, cuestionar sus primeras respuestas y reservar la atención humana para el criterio técnico. El conflicto es inmediato: producir código es cada vez más fácil, pero demostrar que ese código merece llegar a producción sigue siendo difícil.

El consejo refleja un cambio más profundo en la forma en que GitHub describe una ejecución sólida. Antes, un desarrollador demostraba avance al escribir, probar y enviar una implementación. GitHub ahora plantea un flujo de trabajo en el que varios agentes preparan código, pruebas y documentación, mientras el desarrollador define el problema y revisa el resultado conjunto.

Ese modelo no elimina la responsabilidad de ingeniería. La concentra en los puntos donde la IA sigue siendo menos fiable. Los desarrolladores deben aportar contexto, revelar restricciones ocultas, comparar alternativas y reconocer resultados plausibles pero incompletos.

El argumento también llega en medio de evidencia contradictoria sobre la productividad de la IA. Los desarrolladores informan con frecuencia ganancias de eficiencia personal, pero la investigación controlada y los datos de entrega muestran que una generación más rápida no garantiza una entrega de software más rápida ni más segura. Por eso, GitHub está formulando una afirmación profesional, no simplemente ofreciendo un tutorial de herramientas: la habilidad escasa está pasando de producir código a dirigir y validar un sistema de producción más amplio.

Las habilidades de los desarrolladores de GitHub AI ahora empiezan por dirigir agentes

La afirmación central de GitHub es que la ejecución implica cada vez más definir y coordinar el trabajo, no implementar personalmente cada componente.

La guía profesional de GitHub describe una tarea convencional de autenticación como una secuencia lineal. Un desarrollador crea una rama, escribe el código, ejecuta las pruebas y abre un pull request. Cada paso sigue siendo visible y atribuible a una persona.

Su alternativa basada en agentes es diferente. Un agente prepara la implementación de autenticación, otro redacta la documentación y un tercero construye la suite de pruebas. El desarrollador sigue siendo responsable del resultado, pero se desplaza hacia las etapas iniciales, donde se establecen los requisitos y límites, y hacia las etapas finales, donde se integran y aprueban los resultados.

Esto es más que escribir prompts. Un agente de IA es software que puede perseguir un objetivo mediante múltiples acciones con supervisión limitada. Dirigirlo exige que el desarrollador describa el resultado deseado, proporcione contexto del repositorio, establezca restricciones y defina evidencias de finalización.

Dirigir varios agentes añade otra capa. Sus tareas deben poder separarse, sus supuestos deben seguir siendo compatibles y sus resultados deben converger en la misma arquitectura. La generación en paralelo ahorra poco tiempo si un agente cambia una interfaz que otro espera que permanezca estable.

Por tanto, una especificación sólida se convierte en coordinación ejecutable. Para una función de autenticación, podría identificar los proveedores de identidad admitidos, el comportamiento de sesión, los requisitos de migración, los supuestos de amenazas, las necesidades de accesibilidad y el manejo de fallos. También debería definir qué pruebas deben aprobarse antes de iniciar la revisión.

El desarrollador debe decidir cuánto contexto recibe cada agente. Un contexto insuficiente propicia código genérico que entra en conflicto con las convenciones del repositorio. Demasiado contexto sin filtrar puede ocultar los requisitos pertinentes y aumentar la posibilidad de que un agente siga documentación obsoleta.

Esto hace que el conocimiento del repositorio sea más valioso, no menos. Un ingeniero que comprende los límites de propiedad, las prácticas de despliegue y la historia arquitectónica puede dividir el trabajo de forma segura. Quien carece de esa comprensión aún puede generar código, pero no puede predecir de forma fiable dónde fallará el cambio.

Las nuevas habilidades de programación con GitHub AI también incluyen gestionar las dependencias entre artefactos generados. Las pruebas deben examinar la implementación que realmente llegará a producción. La documentación debe describir el comportamiento real, en lugar del diseño previsto. Los cambios en la base de datos deben alinearse con los procedimientos de despliegue y reversión.

Por consiguiente, la dirección de agentes debe comenzar con la descomposición. Los desarrolladores deben separar las tareas que pueden avanzar de manera independiente de las decisiones que requieren criterio compartido. También necesitan puntos de control explícitos antes de que un agente amplíe el alcance de un cambio.

Un patrón operativo útil consiste en asignar resultados delimitados, en lugar de ambiciones generales. “Implementa la renovación de tokens bajo estas seis restricciones” es revisable. “Mejora la autenticación” invita a un agente a tomar decisiones de producto, seguridad y arquitectura sin autoridad suficiente.

La misma disciplina se aplica a los criterios de finalización. Una suite de pruebas en verde es evidencia, pero no constituye toda la definición de terminado. El desarrollador aún puede tener que evaluar la latencia, la exposición de datos, la compatibilidad hacia atrás, la observabilidad y el impacto en los usuarios.

Por tanto, la primera recomendación de GitHub desplaza la unidad visible de experiencia. La velocidad de escritura y el conocimiento de frameworks siguen ayudando, pero ya no distinguen a los desarrolladores cuando un agente puede generar patrones comunes con rapidez. El factor diferenciador pasa a ser la capacidad de convertir una solicitud ambigua en trabajo acotado y verificable.

Este cambio presiona tanto a ingenieros junior como senior. Tradicionalmente, los desarrolladores junior han fortalecido su criterio al implementar muchos cambios pequeños. Los desarrolladores senior ahora deben preservar esas oportunidades de aprendizaje y, al mismo tiempo, adoptar flujos de trabajo que deleguen la implementación rutinaria.

Las organizaciones tendrán que decidir si la dirección de agentes se convierte en una habilidad individual o en una práctica compartida de ingeniería. Si cada desarrollador inventa prompts, reglas de revisión y formatos de traspaso distintos, los equipos pueden ganar velocidad local mientras acumulan procesos inconsistentes.

Una base de conocimiento de ingeniería consultable puede ayudar a agentes y desarrolladores a trabajar a partir de las mismas decisiones. Sin embargo, la documentación solo ayuda cuando los equipos la mantienen y distinguen las reglas vigentes de las obsoletas.

El consejo de GitHub es más sólido cuando se interpreta como una exigencia de definir mejor los problemas. Los agentes pueden multiplicar la capacidad de implementación. También multiplican las consecuencias de requisitos poco claros, contexto faltante y límites débiles.

La generación más rápida de código presiona a los revisores

El cuello de botella inmediato está pasando de la producción de código a la verificación del código, donde la atención humana sigue siendo limitada.

La segunda recomendación de GitHub es tajante: no confíes en la primera respuesta de un sistema de IA. La empresa ilustra el punto con una consulta SQL que parece correcta hasta que un segundo modelo identifica marcas de tiempo duplicadas, la ausencia de una recomendación de índice y un rendimiento deficiente a escala.

Ese ejemplo refleja el problema central de la revisión. El código generado suele parecer completo porque está pulido sintácticamente y sigue patrones conocidos. Sus defectos pueden residir en supuestos no expresados, en lugar de errores de sintaxis evidentes.

La encuesta de desarrolladores de 2025 de Stack Overflow cuantifica esa tensión. El cuarenta y seis por ciento de las personas encuestadas desconfiaba de la precisión de los resultados de IA, mientras que el 33% confiaba en ellos. Solo el 3% informó un alto nivel de confianza.

La misma encuesta descubrió que el 66% de los desarrolladores se había encontrado con soluciones de IA que eran casi correctas, pero no del todo. El cuarenta y cinco por ciento indicó que depurar código generado llevaba más tiempo. No son quejas aisladas sobre interfaces incómodas. Describen una carga de verificación creada por resultados plausibles.

Los desarrolladores deben revisar el comportamiento, no la presentación. Un diff limpio aún puede manejar mal la concurrencia, los límites de autorización, las entradas malformadas o los fallos parciales. Las pruebas generadas por IA pueden repetir el mismo supuesto incorrecto incorporado en la implementación.

GitHub propone la crítica de un segundo modelo como una defensa. Según se informa, su agente Copilot Rubber Duck utiliza otro modelo para criticar planes, código y pruebas. El enfoque puede revelar problemas que el modelo original pasó por alto.

Un segundo modelo resulta útil, pero no es una prueba independiente. Los modelos pueden compartir patrones de entrenamiento, repetir errores convencionales o aceptar la misma premisa engañosa. Si la solicitud inicial omite una restricción de seguridad, ambos modelos pueden producir respuestas seguras de sí mismas que la ignoren.

Por tanto, el revisor humano debe examinar la premisa antes de comparar respuestas. La primera pregunta no es qué modelo escribió código más limpio. Es si la definición de la tarea recoge los requisitos reales del cliente, el sistema y las operaciones.

La revisión también necesita una profundidad proporcional. Un error tipográfico en la documentación no exige los mismos controles que un cambio de autorización. Los equipos deberían vincular los requisitos de revisión con el riesgo, la sensibilidad de los datos, la reversibilidad y el posible radio de impacto.

Para cambios de bajo riesgo, las pruebas automatizadas y una revisión humana focalizada pueden ser suficientes. Para código de alto riesgo, los equipos pueden requerir modelado de amenazas, pruebas de carga, despliegue gradual, registros de auditoría y la aprobación de un responsable del dominio.

La presión crece cuando los agentes generan múltiples cambios de manera simultánea. La capacidad de revisión humana no escala automáticamente con el volumen de resultados. Un desarrollador que recibe tres ramas terminadas puede afrontar una carga cognitiva mayor que quien escribió una única implementación de forma secuencial.

Los lotes grandes empeoran esta situación. Los revisores deben reconstruir más contexto, seguir más supuestos que interactúan y distinguir los cambios intencionales de los incidentales. La velocidad aparente de la generación puede ocultar una cola de trabajo de verificación sin resolver.

La investigación sobre IA generativa de DORA documentó una brecha relacionada. Sus hallazgos de 2024 asociaron un aumento del 25% en la adopción de IA con una reducción del 1,5% en el rendimiento de entrega y una reducción del 7,2% en la estabilidad de entrega. DORA sugirió que una generación de código más rápida puede producir cambios mayores que tardan más en revisarse y desestabilizan los sistemas.

Estas cifras describen asociaciones, no un resultado universal para todos los equipos. Aun así, cuestionan la idea de que más código generado se convierta automáticamente en más valor entregado. El sistema de entrega debe absorber, evaluar y lanzar ese código de forma segura.

Por consiguiente, las habilidades de los desarrolladores de GitHub AI deben incluir el diseño de evidencias. Antes de que un agente comience, el desarrollador debería determinar qué demostrará la corrección. Esa evidencia podría incluir pruebas basadas en propiedades, umbrales de rendimiento, controles de seguridad o telemetría esperada después del despliegue.

Los desarrolladores también deben preservar la trazabilidad. Los revisores deberían saber qué requisitos determinaron un cambio, qué se pidió hacer a un agente, qué herramientas utilizó y dónde una persona modificó el resultado. Sin ese historial, el diff final puede resultar difícil de interpretar.

La implicación profesional es importante. La revisión de código ya era una responsabilidad relevante de ingeniería. En un flujo de trabajo con gran presencia de agentes, la revisión se convierte en una actividad principal de producción, en lugar de una puerta final tras el trabajo “real”.

Eso significa que las organizaciones deben recompensarla en consecuencia. Si los sistemas de evaluación cuentan las funciones entregadas, pero ignoran los defectos evitados, los desarrolladores sentirán presión para aprobar rápidamente el trabajo generado. La estructura de incentivos entrará en conflicto con el criterio que GitHub afirma que los equipos necesitan.

La carrera profesional avanza hacia el criterio técnico

Cuando la implementación se abarata, decidir qué debe construirse y qué concesiones son aceptables adquiere más valor.

La tercera recomendación de GitHub pide a los desarrolladores usar la IA para problemas más grandes. La empresa sostiene que los ahorros en implementación pueden liberar tiempo para comprender a los clientes, diseñar sistemas, evaluar concesiones y elegir métricas de éxito.

Su ejemplo del modo oscuro divide claramente el trabajo. La IA construye la función, genera pruebas y actualiza la documentación. El desarrollador valida el problema del cliente, examina las concesiones arquitectónicas, verifica la accesibilidad, define el éxito y aprueba la solución.

Esta división pone de relieve el principal antagonista de este cambio: la producción visible de código frente al criterio de ingeniería responsable. El código es fácil de contar. El criterio se manifiesta en errores evitados, alcance acotado, diseños más seguros y decisiones de no construir la funcionalidad equivocada.

El criterio técnico combina conocimiento del dominio con conciencia de las consecuencias. Incluye reconocer cuándo un patrón conocido no encaja, cuándo un requisito entra en conflicto con otro objetivo y cuándo la incertidumbre justifica un experimento más pequeño.

La comunicación pasa a formar parte de la misma habilidad. Los desarrolladores deben explicar por qué un diseño favorece la fiabilidad sobre la velocidad o por qué un atajo genera futuros costes de migración. La IA puede redactar alternativas, pero el ingeniero responsable debe vincularlas con la realidad empresarial y operativa.

Esto cambia lo que debería enfatizar el crecimiento al inicio de la carrera. Memorizar sintaxis importa menos cuando la asistencia está siempre disponible. Comprender el flujo de datos, los modos de fallo, las interfaces, los límites de seguridad y el comportamiento del sistema importa más porque esos conceptos respaldan una evaluación fiable.

Sin embargo, existe un problema de formación. Históricamente, los desarrolladores han desarrollado criterio escribiendo código, depurando fallos y conviviendo con decisiones de diseño anteriores. Si los agentes absorben demasiada implementación demasiado pronto, los recién llegados podrían perder la repetición que desarrolla la intuición.

Los equipos no deberían confundir delegación con aprendizaje. Un ingeniero júnior puede usar un agente y aun así examinar cada supuesto, predecir el comportamiento antes de ejecutar las pruebas y explicar el diseño final. Un flujo de trabajo que acepta código generado sin reconstruirlo ofrece menos valor educativo.

Los ingenieros sénior afrontan un desafío diferente. Su experiencia les proporciona mejores instintos de revisión, pero una gran familiaridad también puede hacer que un agente parezca más lento. Puede que ya sepan dónde debe ir un cambio y cómo funcionan las convenciones del repositorio.

Un estudio aleatorizado sobre productividad de desarrolladores de METR examinó ese escenario en 2025. Dieciséis desarrolladores experimentados de código abierto completaron 246 tareas reales en proyectos maduros que conocían bien, con acceso a IA permitido o no de forma aleatoria.

Antes del estudio, los desarrolladores esperaban que la IA redujera el tiempo de finalización en un 24%. Después, creían que había reducido el tiempo en un 20%. Los resultados medidos mostraron lo contrario: el acceso a herramientas de principios de 2025 aumentó el tiempo de finalización en un 19%.

El estudio tiene límites importantes. Involucró a un grupo pequeño, herramientas concretas, repositorios maduros y desarrolladores con un profundo conocimiento de los proyectos. Los autores no afirmaron que todos los desarrolladores o tareas experimentarían la misma ralentización.

Aun así, la brecha de percepción importa. Los desarrolladores pueden sentirse más rápidos porque la generación reduce el esfuerzo o produce progreso visible, incluso cuando escribir indicaciones, esperar, corregir y revisar prolonga el tiempo total de finalización. El impulso subjetivo no es lo mismo que la entrega medida.

Por eso, el impacto de GitHub en la carrera de los desarrolladores no puede reducirse a «aprender prompting». Una indicación ingeniosa puede mejorar una respuesta. La ventaja duradera proviene de elegir tareas adecuadas, construir ciclos de retroalimentación fiables y detectar cuándo el uso de herramientas añade sobrecarga.

Los desarrolladores más sólidos probablemente alternarán entre modos en lugar de seguir una única doctrina. Delegarán el trabajo repetitivo y bien especificado; colaborarán con un agente en implementaciones inciertas; y trabajarán directamente cuando el conocimiento del repositorio haga ineficiente la asistencia.

Los gerentes también necesitan mejores criterios de evaluación. Las líneas de código y el número de pull requests se vuelven aún menos significativos cuando los agentes pueden inflar ambos. El tiempo de ciclo, los defectos que llegan a producción, los resultados para los clientes, la mantenibilidad y el rendimiento de recuperación aportan señales más útiles.

Los planes de carrera deberían reconocer la calidad de las especificaciones, la efectividad de las revisiones, la prevención de incidentes y las decisiones técnicas entre equipos. De lo contrario, los desarrolladores podrían optimizar la actividad generada mientras la organización depende de un criterio no reconocido.

La guía de GitHub apunta hacia ese futuro sin definirlo por completo. La empresa identifica las habilidades que los desarrolladores deberían reforzar, pero los empleadores deben decidir si los sistemas de promoción y la asignación de proyectos valorarán esas habilidades en la práctica.

La evidencia sobre productividad aún se resiste a una historia simple

La IA puede mejorar tareas individuales y, aun así, hacer que la entrega de los equipos sea más lenta, menos estable o más difícil de comprender.

GitHub cuenta con evidencia considerable del entusiasmo de los desarrolladores. Una encuesta de desarrolladores empresariales de 2024 encargada por la empresa abarcó a 2.000 personas encuestadas no directivas de Estados Unidos, Brasil, India y Alemania.

Más del 97% afirmó haber usado herramientas de programación con IA en el trabajo en algún momento. Según el país, entre el 59% y el 88% informó que sus organizaciones fomentaban o permitían esas herramientas.

Las personas encuestadas también describieron beneficios significativos. Entre el 60% y el 71% afirmó que las herramientas de IA facilitaban adoptar un nuevo lenguaje o comprender una base de código existente. En Estados Unidos y Alemania, el 47% dijo que empleaba el tiempo ahorrado en colaboración y diseño de sistemas.

Estos hallazgos respaldan el argumento de GitHub de que la IA puede liberar atención para un trabajo más amplio. Sin embargo, miden experiencias declaradas, no la entrega integral en condiciones controladas. También procedían de grandes empresas, donde la gobernanza y el acceso a herramientas difieren de las organizaciones más pequeñas.

Los datos posteriores de Stack Overflow ofrecen una imagen mixta. El 52% de los desarrolladores estuvo de acuerdo en que las herramientas o agentes de IA afectaron positivamente a la productividad. Entre quienes usan agentes, cerca del 70% dijo que estos redujeron el tiempo dedicado a tareas específicas, mientras que el 69% informó un aumento de productividad.

Los efectos en los equipos fueron mucho más débiles. Solo el 17% de los usuarios de agentes afirmó que estos mejoraron la colaboración, el impacto peor valorado de la encuesta. Esa brecha sugiere que las organizaciones no pueden asumir que la aceleración individual mejorará automáticamente la coordinación.

La adopción también sigue siendo desigual. Stack Overflow concluyó que el 52% de los desarrolladores no usaba agentes o dependía de herramientas de IA más sencillas. Otro 38% no tenía planes de adoptar agentes.

El contraste importa porque el flujo de trabajo propuesto por GitHub presupone que los agentes son capaces, están disponibles y se integran con los sistemas de ingeniería. Muchos desarrolladores todavía trabajan en entornos donde las políticas, los requisitos de privacidad, las herramientas heredadas o la fiabilidad de los modelos limitan esa configuración.

Las preocupaciones de seguridad y privacidad siguen siendo prominentes. Stack Overflow informó que el 87% de las personas encuestadas estaba preocupado por la precisión de los agentes, mientras que el 81% expresó preocupación por la seguridad y la privacidad de los datos.

Estas preocupaciones afectan a algo más que el código generado. Un agente puede recibir archivos de código fuente, documentación interna, registros de producción, datos de clientes o credenciales mientras realiza una tarea. Dirigir agentes de forma responsable exige controlar a qué datos pueden acceder y qué acciones pueden realizar.

Las herramientas subyacentes también cambian con rapidez. El resultado de METR de 2025 es una instantánea de los sistemas de principios de 2025, no un límite permanente. Modelos más nuevos, una mejor indexación de repositorios, interfaces de agentes mejoradas y una mayor experiencia de los desarrolladores pueden cambiar el equilibrio.

Esa incertidumbre actúa en ambos sentidos. Los equipos no deberían descartar la IA porque un estudio halló una ralentización. Tampoco deberían declarar éxito porque los desarrolladores afirman sentirse más productivos.

La pregunta correcta es si un flujo de trabajo específico mejora un resultado específico bajo restricciones reales. Los equipos pueden comparar tareas similares, seguir el tiempo de revisión, inspeccionar las tasas de defectos y medir el intervalo entre el trabajo aceptado y un despliegue estable.

También deberían separar el tiempo de generación del tiempo total de la tarea. Un borrador de funcionalidad creado en minutos puede requerir horas de aclaraciones, limpieza y revisión. A la inversa, un agente que no produce código puede aun así ahorrar tiempo al localizar una dependencia oculta o resumir módulos desconocidos.

La medición debe incluir el retrabajo. Si la IA aumenta la producción inicial, pero también incrementa los commits correctivos, las rondas de revisión o los incidentes, la ganancia bruta de generación exagera el beneficio.

La calidad del sistema circundante importa tanto como la capacidad del modelo. Documentación clara, cambios pequeños, pruebas fiables, arquitectura modular y despliegues observables facilitan evaluar la producción de la IA. Unas bases de ingeniería débiles dan a los agentes más margen para amplificar la confusión.

Este es el núcleo escéptico del consejo de GitHub sobre carreras. Las tres habilidades recomendadas son plausibles porque los agentes siguen siendo imperfectos, no porque la implementación se haya vuelto completamente autónoma. Dirigir, revisar y juzgar son salvaguardas alrededor de una herramienta cuyo efecto neto todavía depende mucho del contexto.

Por tanto, los desarrolladores deberían resistirse a dos extremos. Tratar a los agentes como autocompletado poco fiable ignora ganancias reales. Tratarlos como ingenieros independientes transfiere decisiones sin transferir la responsabilidad.

Qué demostrará que el modelo de desarrolladores de GitHub funciona

La próxima prueba es si los flujos de trabajo liderados por agentes mejoran el software terminado, no si generan más código.

La primera señal que hay que observar es un rendimiento de entrega medible. Las organizaciones que adopten agentes deberían informar si el tiempo de ciclo, las tasas de fallos de cambios, el tiempo de recuperación y los resultados para los clientes mejoran conjuntamente. Borradores más rápidos con revisiones más lentas debilitarían el modelo propuesto por GitHub.

Un resultado más sólido mostraría que los equipos entregan cambios más pequeños y seguros mientras los agentes se ocupan de tareas de implementación acotadas. Eso sugeriría que los desarrolladores están dirigiendo la capacidad con éxito, en lugar de limitarse a aumentar el tamaño de los lotes.

La segunda señal es cómo las organizaciones de ingeniería revisan sus planes de carrera. El argumento de GitHub gana peso si los empleadores comienzan a reconocer la calidad de las especificaciones, la revisión de IA, el razonamiento arquitectónico y la gestión de riesgos como criterios explícitos de promoción.

Un cambio de título por sí solo demostraría poco. La evidencia significativa aparecería en ejercicios de contratación, evaluaciones de desempeño, programas de mentoría y propiedad de proyectos. Las empresas tendrían que recompensar a los desarrolladores por prevenir trabajo deficiente, no solo por producir artefactos visibles.

La tercera señal es si los sistemas de revisión mantienen el ritmo de la generación. Mejores agentes pueden crear más código candidato, pero los equipos necesitan pruebas más sólidas, una procedencia más clara y controles de aprobación basados en riesgos. De lo contrario, la cola de verificación se convertirá en el factor limitante.

Las críticas de un segundo modelo son un mecanismo útil. El análisis estático, el análisis de seguridad, las pruebas de propiedades, la ejecución aislada y los despliegues escalonados aportan distintos tipos de evidencia. Ningún modelo debería servir a la vez como autor y autoridad final.

Los desarrolladores pueden actuar antes de que lleguen esos cambios organizativos. Empiecen seleccionando una tarea acotada con criterios de aceptación claros. Registren todo el tiempo dedicado a especificar, generar, revisar, corregir, probar y desplegarla.

Comparen ese resultado con trabajo similar completado sin un agente. Examinen la calidad y el esfuerzo, no solo el tiempo de generación transcurrido. El objetivo es identificar dónde la asistencia crea ventaja y dónde introduce un coste de revisión.

A continuación, practiquen explicar cada cambio generado. Si no pueden describir sus supuestos, modos de fallo y concesiones, no están preparados para aprobarlo. Pedir críticas a otro modelo puede ampliar la búsqueda, pero su propio criterio técnico debe cerrarla.

Por último, protejan el ciclo de aprendizaje. Escriban código cuando la implementación les vaya a enseñar algo esencial. Deleguen cuando la tarea se comprenda, esté acotada y sea fácil de verificar. Usen agentes para ampliar el criterio de ingeniería, no para evitar desarrollarlo.

Las habilidades de los desarrolladores de IA en GitHub están pasando a centrarse en la coordinación, la revisión crítica y la toma de decisiones responsable. ¿Qué parte de tu flujo de trabajo actual te aporta pruebas suficientes para confiar en un agente y qué parte sigue dependiendo de conocimientos que solo posee tu equipo?