Las agent skills de Addyosmani volvieron a GitHub Trending, pero los prompts no son el punto

Las agent skills de Addyosmani alcanzaron el séptimo puesto en una lista de tendencias de GitHub el 6 de agosto, pese a que el proyecto tiene varios meses de antigüedad. El repositorio empaqueta prácticas de desarrollo de software en instrucciones que los agentes de programación con IA pueden cargar cuando son pertinentes. Su renovada visibilidad señala la demanda de algo que los modelos aún no tienen: disciplina de ingeniería fiable.

La clasificación procedía de un agregador de terceros y no establece una nueva fecha de lanzamiento. El proyecto subyacente ya era público cuando Osmani lo explicó el 3 de mayo de 2026. Una versión ampliada apareció en O'Reilly el 27 de mayo. Para entonces, dijo que el repositorio había superado las 27.000 estrellas en GitHub.

El repositorio del proyecto mostraba unas 82.000 estrellas, 8.800 forks y 391 commits cuando se revisó el 6 de agosto. Esas cifras pueden cambiar. La disputa importante es más duradera: flujos de trabajo reutilizables frente a prompts improvisados que dependen de que un modelo elija actuar con disciplina cada vez.

El proyecto de agentes de Addyosmani vuelve a ser tendencia, no se lanza hoy

El hecho verificado es la renovada atención sobre un proyecto establecido, no el anuncio de lanzamiento de un producto nuevo.

La entrada de la lista de tendencias identificó a addyosmani/agent-skills en el séptimo puesto el 6 de agosto. No proporcionó una marca de tiempo de publicación fiable ni explicó si el puesto correspondía a un periodo diario, semanal o regional. Las posiciones de GitHub Trending también cambian a medida que los repositorios ganan actividad.

Esa incertidumbre importa porque aparecer en tendencias puede parecer una noticia de última hora sin representar una publicación reciente. En este caso, la cronología subyacente apunta a otra parte. Osmani fechó su ensayo original sobre agent skills el 3 de mayo, casi tres meses antes de la clasificación observada.

El proyecto también atrajo una atención considerable antes. En la versión del 27 de mayo del ensayo de Osmani, escribió que el repositorio había superado las 27.000 estrellas. La página de GitHub del 6 de agosto mostraba aproximadamente 82.000, aunque los contadores de GitHub son registros en vivo, no históricos fijos.

Esa diferencia sugiere adopción continuada, marcadores o redistribución. No demuestra un uso activo en producción. Las estrellas miden interés expresado, mientras que los forks indican copia o experimentación. Ninguna de las dos cifras revela si los equipos ejecutaron los flujos de trabajo, los mantuvieron instalados o mejoraron los resultados de software.

El propio repositorio también ha cambiado desde el ensayo de mayo. Osmani describió 20 skills y siete comandos con barra en el artículo anterior. El repositorio de agosto documentaba 24 skills y ocho comandos que cubrían especificación, planificación, implementación, pruebas, revisión, rendimiento web, simplificación y lanzamiento.

Esa ampliación ayuda a explicar por qué un repositorio más antiguo puede regresar a una lista de tendencias. Se ha convertido en un paquete más amplio, ha añadido integraciones y ha acumulado atención entre varias comunidades de agentes de programación. La actividad se parece más a una distribución continuada que a un único pico del día de lanzamiento.

El repositorio tiene licencia MIT y consta principalmente de instrucciones en Markdown, referencias de apoyo, comandos, hooks y personas de agentes. No es un modelo de IA, un motor de generación de código ni una plataforma de desarrollo alojada. Los usuarios siguen necesitando un asistente de programación compatible y deben decidir qué permisos recibe ese asistente.

Esta distinción cambia la historia. El proyecto no compite con Claude Code, Codex, Cursor, Gemini CLI ni GitHub Copilot como otro agente de programación. Su objetivo es suministrar una capa de proceso reutilizable que puede integrarse en varios de ellos.

El momento también refleja un cambio más amplio en el desarrollo con agentes. Los equipos están dejando atrás la pregunta de qué modelo escribe la mejor función. Cada vez preguntan más si un agente puede mantener el alcance, recopilar evidencias, superar tareas largas y producir cambios que los humanos puedan revisar.

El proyecto de agentes de Addyosmani aborda directamente esas cuestiones operativas. Su regreso a GitHub muestra que los desarrolladores buscan estructuras de control alrededor de modelos capaces, incluso cuando esas estructuras están escritas en Markdown sencillo.

Por qué las agent skills están sustituyendo al prompt gigante

Las agent skills separan los procedimientos duraderos del contexto permanente que cada solicitud debe acarrear.

Una skill es un directorio construido alrededor de un archivo SKILL.md. El archivo contiene metadatos YAML e instrucciones en Markdown. Según el formato abierto de skills, junto a él pueden residir scripts, referencias y recursos de apoyo.

El formato parece sencillo porque lo es. Una descripción indica al agente cuándo se aplica la skill. El cuerpo le indica qué secuencia seguir. El entorno circundante decide cuándo cargar las instrucciones y a qué herramientas puede acceder el agente.

Ese diseño difiere de incluir cada política en un enorme prompt de sistema. Un prompt permanente consume contexto durante tareas no relacionadas. También convierte la guía de pruebas, los procedimientos de lanzamiento y las reglas de seguridad en un único bloque indiferenciado.

Las skills usan divulgación progresiva, lo que significa que el entorno carga instrucciones detalladas solo cuando resultan pertinentes. Una tarea de pruebas puede activar la guía de testing. Una solicitud de despliegue puede activar verificaciones de lanzamiento sin arrastrar material de despliegue a cada conversación anterior.

La documentación actual de skills de Anthropic describe la misma ventaja básica. Los cuerpos de las skills se cargan cuando se usan, mientras que las instrucciones persistentes del proyecto permanecen presentes durante toda la sesión. Claude Code puede invocar algunas skills automáticamente y otras solo cuando las solicita el usuario.

La biblioteca de Osmani aplica este mecanismo a un ciclo de vida convencional de software. El repositorio actual asigna ocho comandos a actividades como redactar una especificación, dividir el trabajo en tareas pequeñas, construir incrementos, probar el comportamiento, revisar cambios y lanzar de forma segura.

Esa secuencia es el verdadero producto del repositorio. Las recomendaciones individuales son conocidas. Los ingenieros ya saben que deben ejecutar las pruebas, explicitar las suposiciones y dejar intactos los archivos no relacionados.

El problema es la ejecución bajo presión. Los agentes de programación tienden a optimizar la finalización visible, especialmente cuando una solicitud enfatiza la velocidad. Pueden producir el código solicitado mientras omiten evidencias, límites de revisión o comprobaciones operativas que el usuario nunca indicó explícitamente.

Osmani llama a su respuesta “process over prose”. Una skill útil debe prescribir acciones y definir un criterio de salida. No debería limitarse a ofrecer al modelo un ensayo sobre conductas de ingeniería deseables.

Consideremos el desarrollo guiado por pruebas. Un documento de referencia podría elogiar las pruebas y describir sus beneficios. En cambio, un flujo de trabajo indica al agente que cree una prueba que falle, observe el fallo, implemente el cambio más pequeño, vuelva a ejecutar la prueba y luego refactorice.

Esos pasos crean puntos de control observables. El usuario puede inspeccionar el fallo, la ejecución satisfactoria y el diff resultante. Por tanto, la skill traslada parte del juicio desde el razonamiento interno del modelo hacia evidencias disponibles fuera del modelo.

La biblioteca amplía este patrón con orientación “anti-racionalización”. Estas secciones anticipan excusas habituales, como considerar que una tarea es demasiado pequeña para criterios de aceptación o prometer añadir pruebas más adelante. Las instrucciones responden a esas excusas antes de que el agente las use.

Es una elección de diseño inusual pero práctica. Los modelos de lenguaje generan explicaciones plausibles con facilidad, incluidas explicaciones para evitar trabajo incómodo. Una refutación escrita de antemano hace más explícito el límite deseado, aunque no puede garantizar obediencia.

Para las organizaciones, el atractivo es la consistencia. Un equipo puede codificar una lista de verificación de lanzamiento una vez, versionarla con la base de código y exponerla a varios agentes. La instrucción resultante se convierte en conocimiento organizativo revisable en lugar de un prompt privado guardado por un desarrollador.

También crea una conexión natural con una base de conocimiento consultable. Los equipos siguen necesitando las decisiones de diseño, los runbooks y el contexto técnico que explican por qué existe cada flujo de trabajo. Las skills pueden entonces convertir conocimiento seleccionado en acciones.

El prompt gigante no está desapareciendo por completo. Todo entorno sigue necesitando reglas permanentes sobre límites, convenciones del repositorio y seguridad. La división emergente es más clara: los archivos persistentes contienen hechos siempre aplicables, mientras que las skills contienen procedimientos activados por trabajo específico.

La principal disputa es flujo de trabajo reutilizable frente al juicio del modelo

El repositorio cuestiona la creencia de que un modelo mejor proporcionará de forma fiable un proceso de ingeniería sin andamiaje explícito.

Las mejoras de los modelos siguen siendo importantes. Los modelos más potentes pueden comprender bases de código más grandes, llamar a más herramientas y recuperarse de fallos difíciles. Sin embargo, la capacidad bruta no determina qué pasos elige realizar un agente.

Un modelo puede saber cómo redactar un documento de diseño y aun así omitirlo. Puede entender la revisión de código mientras produce un cambio demasiado amplio para que un revisor lo evalúe. Conocer una práctica es distinto de ejecutarla de forma consistente.

El enfoque de agentes de Addyosmani sitúa un flujo de trabajo reutilizable entre la intención del usuario y la acción del modelo. El modelo sigue razonando sobre los detalles de implementación, pero la skill restringe la ruta. Define fases, puntos de control y condiciones de parada que deberían mantenerse estables entre tareas.

Ese enfoque presiona a los proveedores que dependen de una orquestación propietaria. Si los equipos pueden expresar comportamientos valiosos en Markdown portátil, parte de la diferenciación entre agentes se desplaza de los prompts ocultos hacia bibliotecas de flujos de trabajo transparentes.

El repositorio afirma que sus skills funcionan en más de 70 agentes mediante un instalador compartido. También documenta configuraciones nativas o adaptadas para Claude Code, Cursor, Gemini CLI, Windsurf, OpenCode, GitHub Copilot, Kiro y Codex.

La compatibilidad no equivale a un comportamiento idéntico. Una plataforma puede seleccionar automáticamente una skill a partir de su descripción. Otra puede requerir que el usuario copie instrucciones en un archivo de reglas. Una tercera puede admitir skills, pero interpretar de forma distinta los metadatos adicionales.

La especificación abierta estandariza un núcleo modesto. Requiere un directorio con SKILL.md, además de front matter que contenga un nombre y una descripción. Los scripts, referencias, recursos, notas de compatibilidad y declaraciones de herramientas permitidas son opcionales.

Ese pequeño denominador común es a la vez una ventaja y una limitación. Hace que las skills sean fáciles de crear e inspeccionar. No puede estandarizar cómo cada agente enruta solicitudes, gestiona el contexto, pide aprobación, ejecuta herramientas o demuestra la finalización.

El repositorio de Osmani sortea esas diferencias con directorios específicos por plataforma y documentos de configuración. Claude Code recibe empaquetado de plugins. Gemini CLI obtiene orientación de instalación nativa. Los usuarios de Copilot adaptan el contenido de personas y skills a los archivos de instrucciones del repositorio.

Esta es portabilidad mediante traducción, no equivalencia perfecta en tiempo de ejecución. La intención del flujo de trabajo puede viajar, pero la fuerza de su aplicación depende del entorno de destino. Una comprobación de seguridad tratada como obligatoria en una plataforma puede convertirse en texto orientativo en otra.

El problema se vuelve más agudo cuando un flujo de trabajo invoca herramientas externas. Una instrucción en Markdown puede decirle a un agente que ejecute pruebas o inspeccione el comportamiento del navegador. No puede crear un entorno de pruebas, conceder acceso al navegador ni garantizar que las credenciales estén aisladas.

Por lo tanto, los equipos deben evaluar el entorno completo: modelo, herramientas, permisos, hooks, reglas del espacio de trabajo y registro de auditoría. Una skill bien redactada mejora una capa. No sustituye a las demás.

Esta distinción también separa las skills de la automatización determinista. Una regla de integración continua puede bloquear un merge cuando fallan las pruebas. Una skill puede indicar a un agente que no continúe, pero el modelo o el entorno podrían seguir adelante a menos que otro control imponga la detención.

La arquitectura más sólida combina ambos enfoques. Las skills orientan el juicio flexible allí donde los scripts rígidos tendrían dificultades. Los hooks, los sistemas de permisos, las ramas protegidas y las comprobaciones de CI imponen límites allí donde el cumplimiento no puede seguir siendo opcional.

Ese modelo híbrido presiona a la escuela de despliegue de agentes basada en «simplemente mejorar el prompt». La elaboración de prompts sigue importando, pero el trabajo de producción repetible requiere procedimientos versionados y controles verificables por máquinas. El repositorio en tendencia ofrece una plantilla visible para realizar esa transición.

Lo que realmente imponen las Agent Skills de Addyosmani

La biblioteca convierte hábitos de ingeniería sénior en trabajo secuenciado, pero cada secuencia sigue siendo una instrucción, no una autoridad independiente.

La colección actual abarca todo el recorrido, desde una solicitud poco clara hasta un lanzamiento en producción. Sus skills de especificación piden a los agentes que hagan explícitas las suposiciones, aclaren los objetivos y definan criterios de aceptación antes de comenzar la implementación.

A continuación, la guía de planificación divide la especificación en tareas pequeñas y verificables. Esa estructura limita la cantidad de cambios producidos antes de recibir feedback. También ofrece a los revisores una relación más clara entre un requisito y el código destinado a satisfacerlo.

Las skills de implementación favorecen cortes verticales finos, valores predeterminados seguros, feature flags y cambios fáciles de revertir. El objetivo no es simplemente tener archivos más pequeños. Es reducir la distancia entre un cambio y la evidencia que los usuarios pueden observar.

El flujo de pruebas utiliza las etapas rojo, verde y refactorización. Primero, el agente escribe una prueba que falla por el motivo esperado. Después implementa el comportamiento mínimo necesario para lograr el éxito antes de mejorar el diseño sin cambiar el resultado.

La revisión de código amplía la evidencia más allá de una suite de pruebas en verde. Las pruebas pueden confirmar casos esperados mientras pasan por alto límites de seguridad, interfaces confusas, complejidad excesiva o un alcance no previsto. El flujo de revisión pide al agente que examine esas dimensiones por separado.

El repositorio también incluye material especializado sobre diseño de API, trabajo frontend, seguridad, rendimiento, depuración, desarrollo fundamentado en fuentes, gestión de contexto, desuso y migración. Una meta-skill dirige las solicitudes al procedimiento pertinente.

Su comando de publicación coordina las comprobaciones finales en lugar de tratar el despliegue como una sola acción. Esto refleja el argumento más amplio de Osmani: la ruta más rápida de un agente hacia «hecho» suele excluir el trabajo operativo que hace que la finalización sea fiable.

Muchas prácticas se basan en guías públicas de ingeniería de Google. El repositorio apunta a conceptos como cambios pequeños, pruebas legibles, evolución cuidadosa de las API, validación temprana y comprensión del código existente antes de eliminarlo.

No son principios de ingeniería nuevos. Su valor proviene del empaquetado y del momento. Un agente ve un procedimiento específico cuando está tomando la decisión, en lugar de depender de que un modelo recuerde material general de entrenamiento en el momento adecuado.

Una corrección de bug concreta muestra la diferencia. Sin guía de flujo de trabajo, un agente podría localizar la función sospechosa, modificarla, ejecutar una prueba limitada e informar que tuvo éxito. El parche puede parecer convincente y aun así dejar sin explicar el fallo original.

Con una skill de depuración, el agente debería reproducir el problema, recopilar evidencia, formular hipótesis alternativas, ponerlas a prueba, identificar la causa, añadir una prueba de regresión, implementar la corrección y verificar el comportamiento visible para el usuario. Cada paso reduce el margen para un parche atractivo pero incorrecto.

Una solicitud de funcionalidad plantea otra prueba. El flujo de especificación debería obligar a hacer explícita la incertidumbre antes de modificar el código. Si dos requisitos entran en conflicto, el agente debería detenerse para pedir una aclaración en lugar de elegir silenciosamente la interpretación más sencilla.

Ese comportamiento de detención importa más que un código generado elocuente. Un agente capaz que formula una pregunta necesaria puede ser más seguro que un modelo más potente que construye con confianza la funcionalidad equivocada.

Sin embargo, los archivos de instrucciones no pueden demostrar que esas mejoras se produzcan. La popularidad del repositorio demuestra interés en el patrón. No aporta evidencia controlada de que las 24 skills reduzcan defectos, tiempo de revisión o tasas de incidentes en distintos agentes y repositorios.

El artículo de Osmani de mayo presenta razonamiento de diseño y experiencia, no un benchmark comparativo amplio. Su posterior ensayo sobre flujos de ingeniería explica por qué existen los pasos y cómo reflejan prácticas de software consolidadas.

Esa evidencia es útil, pero limitada. Los equipos que adopten la biblioteca deberían definir sus propias métricas, incluidos defectos que llegan a producción, cambios revertidos, latencia de revisión, variaciones en la cobertura de pruebas, costes de herramientas y frecuencia de detenciones innecesarias de agentes.

También deberían inspeccionar cada skill antes de instalarla. Los archivos de instrucciones pueden solicitar comandos, influir en el uso de herramientas e incorporar material de apoyo al contexto del modelo. Tratar un repositorio popular como una política ejecutable fiable repetiría el mismo atajo que el proyecto busca evitar.

La portabilidad y la verificación siguen siendo los problemas difíciles

La mayor incertidumbre es si una instrucción portátil produce un comportamiento equivalente y exigible en distintos entornos de agentes.

El proyecto presenta un argumento convincente a favor de un flujo de trabajo reutilizable. Presenta un argumento más débil a favor de una ejecución uniforme. Cada plataforma controla de forma distinta el descubrimiento de skills, el ensamblaje de contexto, los permisos de comandos y el manejo de fallos.

El enrutamiento automático es una fuente de variación. La descripción de una skill ayuda a un agente a decidir cuándo activarla. Las descripciones pueden solaparse y las solicitudes de los usuarios a menudo abarcan varias fases. El entorno puede cargar demasiados procedimientos, elegir el equivocado o pasar por alto una skill relevante.

Los límites de contexto introducen otra disyuntiva. La divulgación progresiva reduce el peso permanente del prompt, pero las skills activadas siguen consumiendo atención. Una funcionalidad compleja podría requerir varios flujos de trabajo, referencias de apoyo, instrucciones del repositorio, código, registros y salidas de herramientas en una misma sesión.

Más contexto no es automáticamente mejor. Las restricciones relevantes pueden competir con los detalles de implementación. Los procedimientos extensos también pueden fomentar una finalización superficial de listas de verificación cuando el agente no dispone de suficiente espacio para razonar cuidadosamente sobre el código.

La portabilidad añade deriva semántica. Un repositorio puede copiar el mismo Markdown en Claude Code, Cursor, Gemini CLI y Copilot. Cada modelo y entorno puede interpretar palabras como «debe», «verificar» o «detenerse» con distinta fiabilidad.

La disponibilidad de herramientas cambia aún más el resultado. Un flujo de verificación en navegador no puede inspeccionar una interfaz en ejecución sin acceso al navegador. Una revisión de seguridad no puede validar el resultado de una dependencia si el acceso a la red está deshabilitado y la base de datos local está desactualizada.

Los permisos determinan el límite de riesgo. Un agente con shell sin restricciones, credenciales de producción y acceso de despliegue puede causar daños pese a contar con excelentes instrucciones de proceso. Un agente con permisos limitados sigue restringido incluso cuando malinterpreta una skill.

Por eso las skills deberían complementar los controles deterministas. La protección de ramas puede exigir revisiones. CI puede bloquear pruebas fallidas. Los sandboxes pueden restringir el acceso a archivos y red. Las puertas de aprobación pueden detener despliegues hasta que una persona autorice la acción exacta.

El riesgo de la cadena de suministro merece la misma atención. Un repositorio de skills es una configuración adyacente al código que moldea el comportamiento privilegiado de un modelo. Las actualizaciones pueden cambiar instrucciones, scripts, hooks y archivos referenciados sin alterar el modelo subyacente.

Los equipos deberían fijar versiones revisadas, inspeccionar diffs y limitar las actualizaciones automáticas. Deberían verificar los archivos referenciados y los scripts incluidos en lugar de revisar únicamente el SKILL.md de nivel superior. Un archivo de entrada conciso puede delegar comportamientos importantes en otra parte.

El propio repositorio reconoce una brecha de portabilidad para las instalaciones individuales. Su README advierte que instalar una sola skill puede omitir directorios de referencias compartidas y dejar listas de verificación complementarias sin disponibilidad. Instalar todo el repositorio o copiar las referencias necesarias evita ese problema específico.

Esa advertencia ilustra el desafío más amplio. Una skill puede parecer instalada mientras le falta parte de su contexto operativo. El agente puede seguir funcionando, lo que hace que la degradación silenciosa sea más difícil de detectar que una dependencia convencional ausente.

La evaluación es la brecha final. Los equipos necesitan tareas con resultados esperados conocidos, no solo impresiones subjetivas. Deberían comparar al mismo agente con y sin una skill, y después examinar la corrección, los cambios innecesarios, las llamadas a herramientas, la duración y el consumo de tokens.

La adopción debería comenzar con un problema limitado. Un equipo que sufre parches demasiado amplios podría probar skills de disciplina de alcance y revisión. Otro con regresiones recurrentes podría evaluar el flujo de pruebas frente a bugs históricos.

El resultado debería determinar si el flujo de trabajo entra en la política compartida. La popularidad puede justificar una inspección, pero no puede sustituir la prueba local. La lección más sólida del proyecto es la verificación, y esa lección debería aplicarse al propio proyecto.

Tres señales mostrarán si las Agent Skills se convierten en infraestructura

La siguiente etapa depende de resultados medibles, conformidad multiplataforma y aplicación de controles fuera del propio razonamiento del modelo.

La primera señal es una evaluación comparativa creíble. Esté atento a mantenedores o equipos independientes que publiquen pruebas repetibles en repositorios reales. Las evaluaciones útiles deberían medir tasas de defectos, violaciones de alcance, calidad de revisión, coste y tiempo de finalización.

Un resultado favorable mostraría que las skills seleccionadas mejoran los resultados en múltiples tareas sin imponer demoras ni uso de tokens excesivos. Resultados débiles o incoherentes sugerirían que el éxito depende más del modelo, el repositorio o el evaluador que del texto del flujo de trabajo.

La segunda señal es una conformidad más sólida entre plataformas de agentes. La especificación común define actualmente la estructura de archivos y los metadatos, mientras que los entornos conservan una libertad considerable sobre la activación y la ejecución.

El progreso incluiría pruebas compartidas para descubrimiento, carga de archivos de apoyo, restricciones de herramientas y comportamiento ante fallos. Si la misma skill produce trazas comparables en Claude Code, Codex, Gemini CLI, Cursor y Copilot, la portabilidad se convierte en algo más que compatibilidad de archivos.

Las extensiones divergentes debilitarían esa promesa. Los proveedores pueden admitir el mismo núcleo de SKILL.md y, al mismo tiempo, añadir campos de enrutamiento, semánticas de permisos y sistemas de empaquetado incompatibles. Los equipos terminarían manteniendo varias versiones de un mismo flujo de trabajo.

La tercera señal es la integración con políticas deterministas. Las skills se convierten en infraestructura cuando sus puntos de control se conectan a sistemas que pueden verificar o bloquear acciones. Algunos ejemplos son evidencia de CI obligatoria, aprobaciones firmadas, políticas de sandbox y registros de finalización legibles por máquinas.

Esa integración preservaría la flexibilidad sin pedir a un modelo que se vigile a sí mismo. La skill podría decidir qué vía de verificación se ajusta a la tarea, mientras que los controles externos confirman que existe la evidencia necesaria antes de hacer merge o desplegar.

El proyecto de agentes Addyosmani ya apunta hacia esta arquitectura por capas mediante hooks, comandos, personas y flujos de trabajo centrados en la verificación. Su próximo desafío es demostrar que esas capas funcionan juntas de forma fiable fuera de ejemplos cuidadosamente preparados.

Para los desarrolladores, la acción inmediata es la inspección, no la adopción generalizada. Lean los flujos de trabajo más cercanos a sus fallos recurrentes. Comparen sus puntos de control con los controles de ingeniería existentes. Después prueben uno en trabajo representativo con permisos restringidos.

Para los líderes de ingeniería, el proyecto plantea una invitación a inventariar el criterio no documentado. ¿Qué hábitos de revisión existen solo en la mente de los ingenieros sénior? ¿Qué comprobaciones de lanzamiento dependen de la memoria? ¿Qué excepciones terminan convirtiéndose repetidamente en incidentes?

Convierta uno de esos procesos en un flujo de trabajo breve y revisable. Vincúlelo a una validación externa allí donde un fallo importe. Mida si el agente lo sigue y si el cambio resultante se vuelve más fácil de confiar.

La renovada atención en torno a las habilidades de agente de addyosmani no demuestra que Markdown pueda convertir a un programador de IA en sénior. Demuestra que los desarrolladores ya no aceptan la generación de código como la totalidad del trabajo. La siguiente pregunta es si los flujos de trabajo portátiles pueden generar evidencias lo bastante sólidas como para que los equipos confíen en ellas.