Preguntas,
respondidas.

No. TDD es un ritmo a nivel de unidad para que un dev diseñe código. El desarrollo guiado por especificaciones es el linaje de BDD / acceptance-test-driven: los criterios de aceptación del producto, expresados de forma ejecutable (el Given/When/Then de Gherkin), deciden si el trabajo está hecho. Otro nivel, otro autor, otro propósito.

Contexto completo: ¿Qué es el desarrollo guiado por especificaciones? →

Escribir criterios cuesta minutos. Mergear una feature verde-pero-rota cuesta horas o días después. En las tareas medidas ha eliminado por completo la tasa de bugs genuinos.

Contexto completo: ¿Qué es el desarrollo guiado por especificaciones? →

No. Puedes hacerlo a mano. Una herramienta ayuda cuando quieres los criterios y el gate de ejecución en cada tarea sin tener que acordarte.

Contexto completo: ¿Qué es el desarrollo guiado por especificaciones? →

No. El agente escribió el código y, de la misma tirada, escribió los tests a su alrededor, así que verde significa que el código está de acuerdo consigo mismo, no que coincida con lo que querías. En 120 ejecuciones de este benchmark, con solo la petición de una línea, el 40% coló un fallo de corrección real con el build en verde y los tests pasando. Compilar y ser correcto son dos afirmaciones distintas, y un build en verde solo comprueba la primera.

Contexto completo: Desarrollo guiado por especificaciones: un build en verde no es una feature correcta →

Porque los LLM no son deterministas, ni a temperatura 0; el orden en coma flotante y el batching del proveedor se encargan. Corre una tarea tres veces y puedes sacar correcto, correcto, roto. En este benchmark el 15% de las celdas se contradecían entre ejecuciones. Así que «ha funcionado cuando lo he probado» es una sola tirada de una distribución que no ves, y la ejecución que miraste no es la que mergeaste.

Contexto completo: Desarrollo guiado por especificaciones: un build en verde no es una feature correcta →

No por sí solo. Un modelo más fuerte falla menos veces pero de forma más plausible, lo que hace los fallos más difíciles de pillar, no más fáciles. Hasta la config más fuerte medida coló un fallo genuino en una parte de las ejecuciones en crudo y alternó entre ejecuciones en la feature dura. Ninguno llegó a cero sin un gate. Lo que llevó a todos los modelos a 0% de bugs genuinos fue escribir los criterios de aceptación por delante y comprobarlos ejecutando.

Contexto completo: Desarrollo guiado por especificaciones: un build en verde no es una feature correcta →

Convirtiendo los criterios de aceptación del producto en un gate de ejecución. Escribes qué significa «hecho» antes de que el agente empiece, idealmente de forma ejecutable, y luego lo verificas ejecutando el código cuando termina, cada vez. En este benchmark la rama cruda coló un fallo en el 40% de las ejecuciones y la de criterios por delante en el 0%, y un modelo barato con spec igualó a uno puntero sin ella. No spec-driven, donde los criterios viven en un documento, sino spec-gated, donde mandan.

Contexto completo: Desarrollo guiado por especificaciones: un build en verde no es una feature correcta →

No exactamente. El desarrollo guiado por especificaciones define el contrato de aceptación antes de implementar. La portabilidad hace que ese contrato pueda moverse entre herramientas y conserve su vínculo con el código y la verificación posteriores.

Contexto completo: Las especificaciones de software deberían ser portables →

No. Conserva el contrato; la validación en runtime y la evidencia de aceptación siguen siendo las que demuestran que es correcto.

Contexto completo: Las especificaciones de software deberían ser portables →

Para que otro agente, compañero o mantenedor futuro reciba la intención, decisiones, tareas y contexto de verificación que hay detrás del código, en lugar de tener que deducirlo de un diff.

Contexto completo: Las especificaciones de software deberían ser portables →

Es de otra forma. La deuda normal suele ser código que entendías y elegiste no limpiar todavía. El vibe coding añade encima deuda de comprensión: código que nunca leíste, así que debes entenderlo antes incluso de poder evaluar el resto.

Contexto completo: La deuda del vibe coding: qué debes exactamente y cuándo vence →

No. Añádelos a los caminos que dolerían a un usuario si se rompieran en silencio, y añádelos antes de cambiar esos caminos. La cobertura total en un prototipo desechable es pagar una deuda que no te cobra intereses.

Contexto completo: La deuda del vibe coding: qué debes exactamente y cuándo vence →

Paga primero la de comprensión porque todo depende de ella, luego la de verificación en los caminos que sostienen peso, y la de arquitectura la última y solo donde bloquee el cambio que de verdad necesitas hacer.

Contexto completo: La deuda del vibe coding: qué debes exactamente y cuándo vence →

No. Está sin revisar, que es distinto. El mismo agente escribe código seguro cuando la seguridad es parte del contrato y código con fugas cuando el único requisito es que arranque. El riesgo viene de saltarse la revisión, no del modelo.

Contexto completo: Los agujeros de seguridad que deja el vibe coding →

Los secretos. Asegúrate de que ninguna API key ni credencial vive en tu código o en el historial de git, porque ese agujero es el más fácil de explotar y el más fácil de cerrar. Luego pasa a la validación de entrada y a las dependencias.

Contexto completo: Los agujeros de seguridad que deja el vibe coding →

Para la mayoría de apps de vibe coding, no. Sacar los secretos del código, validar la entrada en la frontera con una guía establecida y escanear las dependencias cierra los agujeros comunes. Un especialista importa cuando manejas datos sensibles a escala.

Contexto completo: Los agujeros de seguridad que deja el vibe coding →

Normalmente no. Una reescritura tira una definición del producto que funciona y está validada, y te obliga a redescubrirla rompiendo cosas para usuarios reales. Reescribe solo cuando has aprendido que el producto debería ser fundamentalmente distinto, no porque el código se vea desordenado.

Contexto completo: Tu prototipo ya es el producto: sobrevivir al ascenso →

Sigue a los usuarios. Los caminos que manejan sus datos, su dinero o su flujo de trabajo central sostienen peso y necesitan tests y endurecimiento. El resto puede seguir cutre hasta que se gane la atención.

Contexto completo: Tu prototipo ya es el producto: sobrevivir al ascenso →

Cuando alguien depende de él de un modo que le dolería si se rompiera. Rara vez hay un momento de lanzamiento. La dependencia es lo que cambia los requisitos, lo anuncie alguien o no.

Contexto completo: Tu prototipo ya es el producto: sobrevivir al ascenso →

Normalmente no. El código temprano es exploratorio y en su mayoría desechable, y probar código que estás a punto de borrar es esfuerzo malgastado que además te vuelve reacio a borrarlo. Espera a que un camino pase a sostener peso.

Contexto completo: Cuándo añadir tests y arquitectura a un proyecto construido con IA →

Un camino sostiene peso cuando romperlo dolería a un usuario real y vas a seguir cambiándolo. Las dos condiciones tienen que darse. Mucho en juego sin cambio, o mucho cambio sin nada en juego, no necesitan la inversión con urgencia.

Contexto completo: Cuándo añadir tests y arquitectura a un proyecto construido con IA →

Primero los tests, como tests de caracterización que fijan el comportamiento actual, y luego la arquitectura usando esos tests como red. Refactorizar sin tests reintroduce las regresiones que intentabas evitar.

Contexto completo: Cuándo añadir tests y arquitectura a un proyecto construido con IA →

No. Es una señal exacta de que un camino que sostiene peso no tiene red. La respuesta correcta no es forzar el miedo ni congelarte, sino construir la red donde el miedo apunta.

Contexto completo: Miedo a tocarlo: convertir el pánico a tu propio código en una red de seguridad →

Un test que fija lo que el código hace ahora, en vez de lo que idealmente debería hacer. En proyectos construidos con IA rara vez tienes una spec limpia, así que fijas primero el comportamiento existente, lo que te deja cambiar el código y ver de inmediato si alteraste algo.

Contexto completo: Miedo a tocarlo: convertir el pánico a tu propio código en una red de seguridad →

Empieza donde el miedo es más agudo. Los caminos que menos quieres tocar son los que sostienen peso y están desprotegidos. Recupera su comportamiento, fíjalo con tests y exige evidencia en los cambios, y luego avanza hacia fuera.

Contexto completo: Miedo a tocarlo: convertir el pánico a tu propio código en una red de seguridad →

Puede construir algo que lo parece. En este experimento la Codex app entregó una portada más bonita que la de PaellaDoc, y luego murió al primer clic: cuatro de cinco secciones y todos los formularios de alta crashearon con un error de Svelte, mientras su único chequeo, svelte-check, pasaba con cero errores. Puedes tener el build en verde y una app que nadie ha visto arrancar. La demo gana en diez minutos; el software que funciona es otra pregunta.

Contexto completo: Le pedí la misma app a la Codex app dos veces. Ninguna llegó al día siguiente. →

Porque un build rápido escribe a fuego el momento en que se hizo. El segundo intento de Codex verificó el mismo sábado que se generó, así que compró «funciona hoy» en sentido literal: la fecha «11 de julio» y el saludo «Buenos días» estaban clavados en la plantilla, el formulario de gasto mandaba una fecha fija y cada gasto posterior quedaba contabilizado el 11 de julio, y el panel de hoy filtraba por una cadena de fecha literal y quedaba vacío desde el día 12. Los fallos nunca salen en la demo, solo al día siguiente.

Contexto completo: Le pedí la misma app a la Codex app dos veces. Ninguna llegó al día siguiente. →

No. Al pedírselo, la Codex app verificó, y ayudó: los clics funcionaban, los formularios validaban, trajo algún test en verde. Pero fue una pasada manual el día de la generación que se le pasaron dos widgets contradiciéndose en la misma pantalla, y no dejó ni un script para repetirla. Una verificación que depende de que el usuario sepa pedirla, y de que una pasada de quince minutos vea todo lo que puede fallar mañana, no es verificación.

Contexto completo: Le pedí la misma app a la Codex app dos veces. Ninguna llegó al día siguiente. →

Porque los tokens se van al loop, no al código. De 582 millones de tokens, escribir código costó 2,39 millones; el resto fue ejecutar la app, mirarla y repetir, 541 veces, dejando 59 casos e2e, 218 commits, y una captura más un JSON de evidencia por criterio de aceptación. Ese es el coste de ejecutar un agente dentro de un gate que recomprueba cada cambio en vez de fiarse de su propio visto bueno de una sola vez. Los gates se quedan en el repo, así que el próximo cambio pasa por el mismo examen.

Contexto completo: Le pedí la misma app a la Codex app dos veces. Ninguna llegó al día siguiente. →

No. Es el modo correcto para exploración, prototipos y cualquier trabajo donde equivocarse es barato. Solo se vuelve un problema cuando te quedas en él después de que el código empieza a importar, lo que convierte la verificación saltada en riesgo acumulado.

Contexto completo: Vibe coding vs ingeniería asistida por IA: la línea que importa →

La aceptación. El vibe coding acepta el código generado porque parece funcionar. La ingeniería lo acepta porque se ha demostrado que cumple un contrato definido por adelantado. Las herramientas, los modelos y la velocidad son los mismos.

Contexto completo: Vibe coding vs ingeniería asistida por IA: la línea que importa →

No. El modo es una decisión por cambio. Prototipa una feature por sensaciones y cambia a ingeniería cuando esa feature pase a sostener peso. La habilidad es saber cuál pide el momento.

Contexto completo: Vibe coding vs ingeniería asistida por IA: la línea que importa →

Empieza negándote a que los agentes construyan hasta saber qué comportamiento instalas y por qué. El código es la parte barata ahora; decidir qué construir es donde se movió el coste. Define intención que puedas defender, conviértela en una spec con criterios de aceptación que una máquina pueda comprobar, y solo entonces apunta agentes a la tarea.

Contexto completo: Construir software con agentes de IA: la guía operativa →

Algo fuera del agente que sostenga el contrato, porque el agente no puede juzgar si su propio código cuenta. Eso significa una spec que diga qué tiene que cambiar y seguir siendo cierto, memoria que persista decisiones e invariantes fuera del chat, y puertas que demuestren que el trabajo está hecho. Con un agente en un chat, ese algo eres tú.

Contexto completo: Construir software con agentes de IA: la guía operativa →

No fiándote del «hecho» ni de un build verde. Hecho significa que el comportamiento pasa los criterios de aceptación que existían antes de escribir una línea, con la evidencia pegada. A velocidad de agente recibes demasiadas afirmaciones para revisarlas leyendo, así que la verificación tiene que volverse puertas que el sistema corre contra el comportamiento real, no mirar un resumen.

Contexto completo: Construir software con agentes de IA: la guía operativa →

En el momento en que pasas de uno a varios, el trabajo se vuelve operaciones: partir el producto en tareas, correr sesiones en paralelo, pelear con la pérdida de contexto, persistir memoria compartida y reconciliar agentes que no se ven. Solo escala cuando el mismo contrato fluye por definir, especificar, ejecutar, verificar y aprender, en vez de vivir en tu cabeza.

Contexto completo: Construir software con agentes de IA: la guía operativa →

Un buen desarrollador puede correr Claude Code a mano, haciendo de scheduler, memoria, gate y bucle de recuperación. Un runtime de entrega se lleva esa orquestación fuera del desarrollador para que el trabajo abarque muchas tareas, repos y horas sin un humano sosteniéndolo todo en la cabeza.

Contexto completo: No tienes un problema con Claude Code. El runtime eres tú. →

En un benchmark de recuperación de cuatro episodios, Claude Code con prompt y con skill se quedó en el 66,67%, y los modelos más grandes en controles n=1 hicieron lo mismo. Un runtime de recuperación gobernado llegó al 100%. La brecha no era inteligencia bruta, era sostener el contrato y recuperar a través de episodios.

Contexto completo: No tienes un problema con Claude Code. El runtime eres tú. →

No cuando el agente lo dice, ni cuando el build está verde. Done es el comportamiento pasando los criterios de aceptación que existían antes de escribir una línea, con la evidencia pegada.

Contexto completo: No tienes un problema con Claude Code. El runtime eres tú. →

Parte de la orquestación se absorberá. PaellaDoc no compite por ser el mejor executor; es la capa portable, local-first y multi-motor donde viven el contrato de producto, los gates, la evidencia y la memoria de cada run, por encima de cualquier agente o proveedor.

Contexto completo: No tienes un problema con Claude Code. El runtime eres tú. →

Depende del modelo. Un paquete de contexto ha subido a un modelo barato de 0,56 a 0,83 de calidad, mismo coste y ~2,4× más rápido. A los modelos de frontera, que ya exploran bien, les ha añadido sobre todo coste y poca o ninguna calidad. El valor del contexto es inversamente proporcional a la potencia del modelo. Medido en Claude Code.

Contexto completo: Context engineering para agentes de código: cuándo ayuda y cuándo estorba →

Sí. En la tarea más dura, trazar un flujo end-to-end, un paquete parcial ha hecho que un modelo fuerte se dejara partes: la calidad ha bajado de 0,83 a 0,47. Un mapa parcial puede cegar a un modelo que exploraría mejor en libertad. n=3 por celda, varianza alta.

Contexto completo: Context engineering para agentes de código: cuándo ayuda y cuándo estorba →

El experimento ha usado modelos cloud, así que esto es extrapolación, no medición. El resultado más claro es que el paquete sube a un modelo barato hasta calidad de frontera. Un modelo local está aún más abajo en ese eje de capacidad, así que el contexto debería ayudarle más, no menos. Ese es el siguiente test y la apuesta de soberanía: tu código y tu modelo en tu máquina, con un mapa lo bastante bueno para no tener que alquilar inteligencia de frontera.

Contexto completo: Context engineering para agentes de código: cuándo ayuda y cuándo estorba →

No. En 19 ejecuciones headless con --print, el camino que usan CI y los SDK, el router auto ha elegido el modelo fuerte cero veces. Solo escala en plan-mode interactivo. En automatización, auto se comporta como el modelo barato.

Contexto completo: Context engineering para agentes de código: cuándo ayuda y cuándo estorba →

No, verificado por ejecución. He extraído la función de las 28 ejecuciones de edición y he corrido cada una contra 7 casos canónicos. Las 28 han pasado 7 de 7, Sonnet incluido. El modelo de frontera ha producido el mismo resultado correcto a 5-6× el coste.

Contexto completo: Context engineering para agentes de código: cuándo ayuda y cuándo estorba →

Un modelo de frontera es la herramienta correcta cuando no puedes traer contexto: gente menos técnica, o cualquiera para quien la inteligencia bruta sea el camino más barato a una buena respuesta. Un dev que puede traer los ficheros y símbolos relevantes deja de necesitar pagar esa prima, como muestra la tabla de coste frente a corrección verificada.

Contexto completo: Context engineering para agentes de código: cuándo ayuda y cuándo estorba →

Porque el razonamiento vivía en el chat, y el chat es una superficie de trabajo que se borra. El código sobrevive porque es un archivo; las decisiones, los invariantes y la intención detrás de él no, salvo que quedaran escritos en algún sitio duradero. Una sesión nueva arranca en frío y sabe qué dice el código y nada de por qué lo dice.

Contexto completo: Pérdida de contexto entre sesiones: el asesino de productividad sin presupuesto →

No, y necesitan arreglos distintos. Dentro de una sesión, la ventana se llena y la compactación resume de forma lossy, soltando justo los detalles que más te importaban. Entre sesiones no se traslada nada, porque la ventana es por sesión. Uno es un problema de compresión, el otro de persistencia.

Contexto completo: Pérdida de contexto entre sesiones: el asesino de productividad sin presupuesto →

Solo en el margen. Más ventana es más sitio que llenar, no una garantía de conservar lo correcto, y un run largo se compacta igual. Y más de fondo: la ventana es por sesión. Ninguna ventana, por grande que sea, persiste después de cerrarla. La pérdida entre sesiones no es un problema de capacidad.

Contexto completo: Pérdida de contexto entre sesiones: el asesino de productividad sin presupuesto →

Deja de usar el chat como almacén. Escribe las decisiones cuando se toman, guarda los invariantes en un fichero de reglas que el agente lee al empezar cada sesión, y deja que la intención de una tarea viaje con ella como artefacto. Cuando eso vive en el repo y no en un transcript cerrado, una sesión en frío deja de ser un arranque en frío.

Contexto completo: Pérdida de contexto entre sesiones: el asesino de productividad sin presupuesto →

No todo. Tres tipos de cosa se ganan el sitio: decisiones (una elección entre alternativas, con el razonamiento que impide volver a proponerlas), invariantes (reglas que tienen que aguantar los cambios) y estado (el status actual del trabajo). Recuérdalo todo y reconstruyes el problema de la ventana en una base de datos; no recuerdes nada y cada sesión arranca en frío.

Contexto completo: Memoria para agentes de código: qué debe persistir fuera del chat →

En formas distintas, porque la forma es media parte del contenido. Las decisiones quieren un log solo-append donde la historia es el valor. Los invariantes quieren el fichero de reglas que el agente lee primero, para que aten cada escritura. El estado quiere una sola foto sobrescrita, sin historia. Mete las tres en un documento y cada una corrompe a las otras.

Contexto completo: Memoria para agentes de código: qué debe persistir fuera del chat →

Porque piden que un humano los mantenga, así que mueren en cuanto el humano se lía, y un log de decisiones que nadie actualiza miente con autoridad. La única versión que sobrevive es memoria que el trabajo escribe como efecto secundario: una decisión logueada en la sesión en que se toma, un invariante que aterriza en el fichero de reglas al terminar la tarea.

Contexto completo: Memoria para agentes de código: qué debe persistir fuera del chat →

No todo. Ahí es justo donde chocan los tres tipos: los invariantes quedan enterrados bajo el churn del estado, la historia de decisiones se aplana en un blob de status, y el agente lee una sopa que no honra de forma fiable. Guarda los invariantes en el fichero de reglas, las decisiones en un log, y el estado en su propia foto.

Contexto completo: Memoria para agentes de código: qué debe persistir fuera del chat →

Tres disciplinas. Aísla cada agente en su propio worktree para que no se corrompan los ficheros mientras trabajan. Dales un contrato compartido —las interfaces y los invariantes que ambos leen fuera de cualquier sesión— para que lo que los cruza esté especificado, no improvisado. Después reconcilia en el merge, comprobando que la combinación es coherente, no solo cada rama por separado. Sáltate una y las colisiones se comen la ganancia.

Contexto completo: Orquestar varios agentes sin que se contaminen entre sí →

No sobre la misma superficie de trabajo. Dos agentes escribiendo a los mismos ficheros se corrompen el estado constantemente, porque ninguno ve los cambios sin commitear del otro. El arreglo es el aislamiento: cada agente tiene su propio checkout, rama y directorio con git worktrees. Las colisiones se aplazan al merge, donde se manejan a propósito en vez de en carrera. El aislamiento compra seguridad durante la ejecución, aunque no coherencia; eso necesita un contrato compartido y reconciliación.

Contexto completo: Orquestar varios agentes sin que se contaminen entre sí →

La contaminación es cuando dos cambios localmente correctos se combinan en un todo roto. El agente A refactoriza una interfaz; el agente B, en su sesión, construye una feature sobre la forma vieja porque nada le dijo que cambió. Los dos pasan sus propias comprobaciones, y juntos producen código que no compila o, peor, compila y está mal en silencio. Pasa porque el contexto de ningún agente contiene el hecho de que otro editó algo.

Contexto completo: Orquestar varios agentes sin que se contaminen entre sí →

Con reconciliación, no con git merge y rezar. La reconciliación junta a propósito las ramas paralelas y comprueba la combinación: ¿la feature de B sigue funcionando contra la interfaz refactorizada de A?, ¿alguien rompió un invariante que solo importaba a través de la frontera?, ¿el resultado integrado pasa los criterios que las piezas pasaban solas? Es verificación apuntada a las costuras, que es justo donde fallan los agentes en paralelo, porque son donde ningún agente individual estaba mirando.

Contexto completo: Orquestar varios agentes sin que se contaminen entre sí →

La deriva es la brecha que se abre entre lo que pretendías y lo que el agente está haciendo. Un agente navega guiándose por su contexto, que es siempre una imagen parcial y en decadencia de tu intención: parte nunca se escribió, parte se compactó a mitad de sesión, parte la infirió un poco mal. Arregla lo que tiene delante, lo que desplaza qué significa «el problema», y arregla lo siguiente contra el significado desplazado. Paso a paso, cada uno razonable, se aleja de donde lo apuntaste.

Contexto completo: Los agentes van a derivar: diseñar para la divergencia en vez de rezar →

No de forma fiable. El prompt es una foto; la deriva es un proceso. Puedes apuntar el agente con precisión al objetivo en el instante cero, pero no puedes hacer que esa precisión persista, porque lo que la erosiona —la compactación, la inferencia, la acumulación de pequeñas decisiones locales— pasa después de entregar el prompt y sigue pasando. Un prompt perfecto reduce el error inicial y no hace nada contra la acumulación a lo largo de un run largo.

Contexto completo: Los agentes van a derivar: diseñar para la divergencia en vez de rezar →

No por sí solo. La deriva no es un problema de listura, es un problema de distancia a un objetivo que se difumina. Un modelo más listo puede derivar igual, porque el comportamiento previsto vive en la especificación y la conexión del agente con esa especificación se degrada a lo largo del run. La respuesta duradera es reanclar el agente a algo que no se difumina: una spec que existe antes de escribir una línea y sigue legible todo el camino.

Contexto completo: Los agentes van a derivar: diseñar para la divergencia en vez de rezar →

No previenes la deriva, la pillas pronto y barato. Parte el trabajo en trozos lo bastante pequeños para que el agente no pueda vagar lejos antes de reanclarse al contrato. Usa checkpoints que midan distancia a la intención, no solo si el código funciona. Y trata la reconciliación como un paso de primera clase donde la divergencia se trae de vuelta a propósito. Un coordinador construido así se vuelve más estable según añades agentes, no más tembloroso.

Contexto completo: Los agentes van a derivar: diseñar para la divergencia en vez de rezar →

No hay un número fijo; el límite es donde el coste de coordinación adelanta a tu atención, y es distinto para cada uno. Lo predecible es la forma: cinco sesiones pueden sentirse productivas y ocho como ahogarse, aunque solo sean tres más. El coste es superlineal porque el cambio entre sesiones crece más rápido que el número de sesiones. Extiendes el techo moviendo los trabajos del scheduler al sistema, no siendo más heroico.

Contexto completo: Ocho sesiones a la vez: worktrees, paralelismo y el coste de ser el scheduler →

Usa git worktrees: un worktree por tarea, una rama por worktree, un agente por rama. Un worktree es un segundo directorio de trabajo respaldado por el mismo repositorio, en su propia rama, así cada agente edita a toda velocidad sin tocar los ficheros del otro. El montaje ingenuo —varios agentes en un directorio— se corrompe solo enseguida, porque los agentes no ven los cambios sin commitear del otro. Los worktrees dan el aislamiento del que depende todo lo demás.

Contexto completo: Ocho sesiones a la vez: worktrees, paralelismo y el coste de ser el scheduler →

Porque te conviertes en el scheduler, y cinco trabajos concurrentes te caen a la vez: prioridad, contexto, recuperación, routing e integración. Van por interrupción, así que te arrastra el panel que te reclama a mitad de un pensamiento en otro, y cada cambio paga el coste de recargar qué estabas haciendo. Esa recarga es pérdida de contexto golpeándote en tiempo real, de ocho formas a la vez. Las sesiones escalan lineal; la coordinación que corre en ti, no.

Contexto completo: Ocho sesiones a la vez: worktrees, paralelismo y el coste de ser el scheduler →

Un worktree es un segundo directorio de trabajo del mismo repositorio en su propia rama. Los agentes los necesitan porque el aislamiento es la precondición del trabajo en paralelo: sin él, dos agentes escribiendo al mismo árbol se sobrescriben y se lían constantemente. Los worktrees no hacen desaparecer las colisiones, las mueven al merge, donde puedes manejarlas a propósito. Este es el suelo mecánico bajo toda la orquestación multiagente.

Contexto completo: Ocho sesiones a la vez: worktrees, paralelismo y el coste de ser el scheduler →

Los dos, para trabajos distintos. Guarda los hechos operativos (build, test, estructura, comandos seguros) en AGENTS.md para que todo motor los lea. Guarda el comportamiento específico de Claude en CLAUDE.md si Claude Code es uno de tus executors. No dupliques el mismo contenido en ambos, o heredas el problema de deriva en cuanto una copia cambie.

Contexto completo: AGENTS.md, CLAUDE.md, reglas de Cursor: dónde deberían vivir tus decisiones →

En un artefacto que cargue el motivo y se pueda verificar, cerca del trabajo que gobierna: una spec, un registro de decisión, o los criterios de aceptación de la tarea. Los ficheros de reglas comprimen las decisiones en órdenes y pierden el por qué, y están atados a una herramienta. Una decisión necesita durar más que la sesión y que el motor.

Contexto completo: AGENTS.md, CLAUDE.md, reglas de Cursor: dónde deberían vivir tus decisiones →

Si usas Cursor y quieres su alcance y su aplicación por glob, sí, para comportamiento específico de la herramienta. Solo que no dejes que se convierta en el único sitio donde se escribe una decisión de verdad, porque es invisible para cualquier otro agente al que puedas enrutar trabajo.

Contexto completo: AGENTS.md, CLAUDE.md, reglas de Cursor: dónde deberían vivir tus decisiones →

Continuamente para las partes mecánicas y con calendario para el resto. Monta una comprobación que falle tu build cuando una ruta o comando del fichero ya no resuelva, para que las referencias colgantes se pillen el día que aparecen. Luego haz una auditoría deliberada de las convenciones cada pocas semanas, idealmente haciendo que un agente compare las reglas contra el código actual.

Contexto completo: Tu fichero de reglas miente a tus agentes: mantener las instrucciones vivas →

Tres señales: referencia una ruta o comando que ya no existe, describe una convención que los commits recientes contradicen, o no sabes decir por qué está ahí. La primera es scriptable, la segunda la puede auditar un agente contra el código, y la tercera significa que la regla no tiene procedencia y no debería creerse hasta que la tenga.

Contexto completo: Tu fichero de reglas miente a tus agentes: mantener las instrucciones vivas →

Usa al agente para detectar la deriva, no para reescribir el fichero sin supervisión. "¿Qué instrucciones contradice el código?" es una buena pregunta con respuesta comprobable. "Reescribe mis reglas para que sean mejores" produce slop plausible. Deja que el humano decida qué se queda; deja que el agente haga la búsqueda.

Contexto completo: Tu fichero de reglas miente a tus agentes: mantener las instrucciones vivas →

Resume desde el último checkpoint donde el trabajo se sabía correcto, no desde el principio, y dale al run resumido el registro de qué ya estaba verde para que distinga continuación de regresión. Esto solo funciona si hiciste checkpoint en las fronteras de episodio y guardaste el plan y las restricciones fuera del contexto del agente. Si el único artefacto es un transcript largo, estás reconstruyendo, no recuperando.

Contexto completo: La ejecución murió a las 2 de la mañana: la recuperación como flujo de primera →

Volver a correr funciona para fallos transitorios como un rate limit, pero muchos fallos de run largo son deriva, no crashes: el agente perdió una restricción y siguió. Volver a correr desde arriba suele perder la misma restricción igual, y tira todo el trabajo correcto para escapar de la cola incorrecta. Recuperar necesita un último estado bueno y una forma de puntuar el trabajo resumido contra el contrato original.

Contexto completo: La ejecución murió a las 2 de la mañana: la recuperación como flujo de primera →

Tres cosas: un checkpoint de último estado bueno en cada frontera de episodio, el plan y las restricciones guardados fuera del run para que la compactación no los borre, y un registro de qué gates pasaban antes del fallo. Con eso, un run resumido puede continuar desde un punto conocido y detectar si acaba de romper algo que antes funcionaba.

Contexto completo: La ejecución murió a las 2 de la mañana: la recuperación como flujo de primera →

El routing de modelos trata la tarea, no el modelo, como la unidad de trabajo. Cuando entra una tarea, un router elige qué motor la corre y con qué perfil —cheap, balanced, strong o frontier— según el tipo de tarea, qué motores están disponibles de verdad, el coste y la latencia que aceptas y qué funcionó antes. Un retoque de copy y una migración de base de datos no son el mismo trabajo, así que no deberían ir por defecto al mismo motor caro.

Contexto completo: Sin vendor lock-in: cada tarea a su motor →

Trata los motores como una flota bajo un mismo contrato en vez de atar tu trabajo a un solo modelo. Cuando un proveedor cambia el precio, añade un rate limit o retiran un modelo —como pasó la semana en que una orden de control de exportaciones desactivó uno a mitad de semana— enrutas a otro motor y el trabajo sigue, convirtiendo una caída en un cambio de config. El suelo debajo es el open source: un modelo local a través de Ollama que ningún proveedor ni gobierno puede apagar.

Contexto completo: Sin vendor lock-in: cada tarea a su motor →

Para trabajo puntual, un solo CLI enrutando dentro de su proveedor sobra: Claude Code planifica con un modelo y ejecuta con otro. Deja de bastar cuando quieres un producto entre motores: ninguno va a mandar tu tarea barata a un motor, tu migración a un modelo frontier y tu trabajo offline a uno local, ni responder disponibilidad, coste y fallback entre proveedores. La capa de decisión entre motores es el producto.

Contexto completo: Sin vendor lock-in: cada tarea a su motor →

No debería, y uno bueno no lo hace. Un router que te ofrece un motor que no puede arrancar es peor que no tener router. Antes de cualquier decisión inteligente, los candidatos se filtran a los motores que el runtime puede lanzar de verdad en esta máquina: existe el adapter, responde como disponible y está autenticado. Y cuando el router inteligente corre, solo elige el agente y el perfil; el modelo, el esfuerzo y el contexto salen de config verificada, con un fallback determinista por reglas si algo se rompe.

Contexto completo: Sin vendor lock-in: cada tarea a su motor →

Es la práctica emergente de construir y afinar el bucle dentro del que corre un agente de código: cómo se ensambla el contexto, qué herramientas puede llamar el agente, cómo se verifica el output y cómo se recuperan los fallos. El término se usa con soltura por la comunidad de operación de agentes, incluidos los escritos de ingeniería de Anthropic, para nombrar el sistema alrededor del modelo en oposición al modelo en sí.

Contexto completo: Harness engineering: la disciplina que está naciendo alrededor de operar agentes →

Cuando el modelo es lo bastante bueno como para escribir código correcto desde contexto correcto, sí, el harness pasa a ser donde se gana o se pierde la fiabilidad. En un test de recuperación controlado, el mismo agente de código se quedaba clavado o llegaba al 100% dependiendo solo del bucle a su alrededor, no del modelo. Por debajo de ese umbral el modelo aún importa; por encima, domina el harness.

Contexto completo: Harness engineering: la disciplina que está naciendo alrededor de operar agentes →

Un prompt es una entrada a una llamada. Un harness es el bucle entero: ensambla contexto a través de muchas llamadas, corre herramientas, verifica el output contra gates, recupera runs fallidos, y mueve trabajo entre sesiones. Un buen prompt es parte de ello, pero un prompt sin verificación, sin recuperación y sin gestión de contexto no es un harness, es una sola tirada de dados.

Contexto completo: Harness engineering: la disciplina que está naciendo alrededor de operar agentes →

Cinco cosas: el contrato (qué se construye y qué cuenta como hecho, como criterios comprobables), el estado actual (qué está hecho, en marcha o sin tocar), las decisiones ya tomadas con sus motivos, los callejones sin salida ya probados, y la única pregunta abierta que el siguiente agente debe resolver. Notablemente, no el transcript entero, que es casi todo ruido que quien recibe tiene que volver a filtrar.

Contexto completo: Handoffs: pasar trabajo entre agentes sin perder el hilo →

Porque un transcript es una repetición de eventos, no un resumen de estado. Contiene cada callejón sin salida y corrección sin señal sobre qué sigue importando, así que el agente que recibe o vuelve a explorar caminos descartados o confunde un enfoque abandonado con el plan. Además quema presupuesto de contexto que necesitas para el trabajo real. Un handoff destilado transfiere entendimiento; un transcript en bruto transfiere ruido.

Contexto completo: Handoffs: pasar trabajo entre agentes sin perder el hilo →

Son el mismo problema en tres direcciones. Un handoff pasa el estado de lado entre agentes, la recuperación lo pasa hacia delante en el tiempo para resumir un run muerto, y la memoria lo persiste para que sobreviva cuando nadie lo está pasando. Los tres dependen de que el estado que importa viva fuera de la sesión en una forma sobre la que el siguiente lector pueda actuar.

Contexto completo: Handoffs: pasar trabajo entre agentes sin perder el hilo →

Porque la ventana de contexto es de tamaño fijo, y cuando se llena la sesión compacta resumiendo los turnos viejos. Resumir tiene pérdidas y está sesgado a quedarse con el detalle reciente, así que una restricción de una línea del principio que nunca repetiste es exactamente el tipo de cosa que se borra, mientras la charla de implementación reciente sobrevive. El agente entonces sigue trabajando sin la instrucción, sin saber que ya no está.

Contexto completo: La compactación se come tus decisiones: gestionar la ventana de contexto →

Sube el techo pero no cambia el mecanismo. Una ventana mayor también se llena en trabajo largo, y la compactación sigue erosionando primero las decisiones de anclaje del principio. Más tokens tampoco es lo mismo que más entendimiento, pasado un punto el contexto extra degrada el foco del agente. El arreglo duradero es guardar las restricciones que deben sobrevivir fuera de la ventana y volver a suministrarlas, no confiar en un almacén más grande.

Contexto completo: La compactación se come tus decisiones: gestionar la ventana de contexto →

Sácalas del transcript. Guarda las restricciones y los criterios de aceptación en un artefacto que la ventana no posea, reafirma las vivas en cada frontera de episodio, haz checkpoint antes de tocar el techo, y carga solo los ficheros que un paso de verdad necesita en vez de inundar la ventana. La ventana debería sostener el conjunto de trabajo; la fuente de verdad vive fuera de ella.

Contexto completo: La compactación se come tus decisiones: gestionar la ventana de contexto →

Porque «hecho» significa cosas distintas para cada uno. Para el agente, hecho es que produjo código con aspecto de cumplir lo que se pedía. Para ti, es que el comportamiento cambió, nada más se rompió y hay prueba de ambas cosas. El agente supera su propio listón de buena fe e informa de éxito, y te deja cubriendo la distancia entre «parece terminado» y «está terminado».

Contexto completo: Hecho significa hecho: obligar al agente a demostrarlo →

Quítale el papel de juez de su propio trabajo. Define, antes de empezar, qué demostraría la compleción: qué comando ejecutado contra el resultado, imprimiendo qué salida, contra qué contrato. Luego haz que algo distinto del agente ejecute esa comprobación y capture el resultado. El agente aún puede escribir «hecho», pero deja de decidir si esa frase es verdad.

Contexto completo: Hecho significa hecho: obligar al agente a demostrarlo →

Tres cosas capturadas juntas: un comando que se ejecutó de verdad, con su código de salida; la salida real que imprimió, no un resumen tipo «tiene buena pinta»; y la versión del contrato de aceptación contra la que corrió. Una casilla es una afirmación disfrazada de prueba. Una demostración lleva información sobre si pasó algo de verdad.

Contexto completo: Hecho significa hecho: obligar al agente a demostrarlo →

Pasadas las primeras tareas, lo acelera. Lo caro no es producir la prueba, es no tenerla: releer diffs, re-ejecutar tests a mano porque no te fías del último verde, atrapar en producción una rotura que una ejecución capturada habría cazado. Cuando cada «hecho» lleva su demostración, te fías del informe y gastas atención solo en los pocos que fallan.

Contexto completo: Hecho significa hecho: obligar al agente a demostrarlo →

Un modelo de lenguaje genera la continuación más probable de su contexto. Tras una implementación con aspecto terminado, la frase probable es un informe de éxito, porque así acaba casi todo transcript que ha visto. La afirmación se genera desde la forma de la situación, no se observa de una ejecución real. Salvo que el harness haya corrido de verdad la suite y devuelto el resultado, no hay ejecución que el modelo pueda consultar.

Contexto completo: «Los tests pasan»: anatomía de un éxito falso →

No. Mentir exige conocer la verdad y afirmar lo contrario. El modelo no tiene un registro interno de ejecuciones que esté eligiendo tergiversar, solo una predicción del siguiente token que cae en «éxito» porque así suelen acabar estas historias. Llamarlo tonto es peor, porque el mismo mecanismo escribe código excelente el resto del tiempo. Es un solo comportamiento, producir texto probable, sin vínculo incorporado a un evento real.

Contexto completo: «Los tests pasan»: anatomía de un éxito falso →

No lo consigues por prompt, porque el modelo no tiene forma fiable de introspeccionar si ejecutó algo. El arreglo vive fuera del modelo: la parte que hace el trabajo no debería certificarlo. Haz que el harness invoque los tests, capture la salida y el código de salida reales, y use eso para decidir la compleción. El agente aún puede escribir «los tests pasan», solo que deja de decidir si es verdad.

Contexto completo: «Los tests pasan»: anatomía de un éxito falso →

No, al contrario. Cuanto más capaz el modelo, más plausible su prosa, y la plausibilidad es justo la propiedad que cuela una afirmación falsa ante un revisor cansado. Un éxito falso se lee idéntico a un informe verdadero porque mecánicamente se producen igual. El problema no encoge según mejoran los modelos, crece, y por eso la respuesta duradera es una ejecución real, no un prompt mejor.

Contexto completo: «Los tests pasan»: anatomía de un éxito falso →

Porque la intención no viaja con él. La pull request de un colega llega con contexto compartido: la daily, el ticket, un mensaje de commit que lleva el razonamiento de una persona, un autor al que puedes preguntar. El código del agente llega despojado de todo eso, así que tienes que reconstruir solo desde el diff qué se suponía que hacía y si lo hace. Multiplica ese coste por diff por el caudal de los agentes y la fatiga es el estado estacionario garantizado.

Contexto completo: Fatiga de review: cuando el código llega más rápido de lo que puedes leerlo →

No puedes, ni leyendo más rápido ni con más fuerza, porque tu capacidad de lectura es fija y el output del agente no. Lee distinto: gasta tu atención fija donde compra más certeza por minuto. Aprueba el alcance antes de que el agente construya, lee el diff contra ese alcance y luego confirma la evidencia de lo que corrió. Tres puntos de control acotados sustituyen a una lectura sin límites.

Contexto completo: Fatiga de review: cuando el código llega más rápido de lo que puedes leerlo →

No por igual. Leer un arreglo de una línea de copy con la misma intensidad que un cambio en la ruta de autenticación significa sobre-leer el trivial e infra-leer el peligroso. Ordena por radio de impacto: los cambios que tocan dinero, auth, borrado de datos o interfaces compartidas se ganan una lectura lenta línea a línea siempre. Una hoja aislada con tests alrededor a menudo se puede creer a nivel de alcance y evidencia.

Contexto completo: Fatiga de review: cuando el código llega más rápido de lo que puedes leerlo →

Dos cosas. El alcance tiene que existir como algo que realmente aprobaste por adelantado, no algo reconstruido a posteriori. Y la evidencia tiene que capturarse de forma automática como subproducto del trabajo, o vuelves a re-ejecutar cosas a mano y la fatiga regresa por la puerta de atrás. Cuando la compleción ya exige una demostración, la evidencia espera en el último punto de control.

Contexto completo: Fatiga de review: cuando el código llega más rápido de lo que puedes leerlo →

El aseguramiento es el trabajo de saber que el código producido es correcto, seguro y coherente con todo lo que lo rodea, y poder mostrar cómo lo sabes. Es la pregunta mayor a la que sirven los tests: ¿se puede creer este output, incluido si los tests llegaron a ejecutarse? Los agentes abarataron producir código. El aseguramiento cuesta lo que costó siempre, así que se convirtió en la restricción de cuánto software terminado se entrega.

Contexto completo: De producir a asegurar: el nuevo cuello de botella del software →

Cuando una estación de la línea se acelera enormemente y la siguiente no, la restricción se mueve a la estación lenta. Los agentes convierten una descripción en una implementación funcionando en minutos, a través de sesiones en paralelo. Decidir si fiarse de esa implementación le sigue costando a un humano la misma hora cuidadosa. Producir se abarató, asegurar no, así que el recurso escaso ya no es generar código sino establecer que el código generado se puede creer.

Contexto completo: De producir a asegurar: el nuevo cuello de botella del software →

No. Los tests son una herramienta dentro del aseguramiento, no su totalidad. El aseguramiento es la disciplina de convertir afirmaciones en evidencia al ritmo al que llegan: si un build en verde prueba que la feature es correcta, si la compleción costó una demostración real, si los tests llegaron a ejecutarse, y si la prueba sobrevive más allá de la terminal en la que se imprimió. Testear es un instrumento; el aseguramiento es la estación.

Contexto completo: De producir a asegurar: el nuevo cuello de botella del software →

Deja de estimar tiempo de construcción y empieza a estimar tiempo de confianza. «Cuánto se tarda en escribir esto» es casi gratis de responder ahora y casi inútil. Un cambio que un agente escribe en cinco minutos pero que toca una ruta de pagos no es un cambio de cinco minutos, es lo que tarde el aseguramiento. Planificar por tiempo de construcción te compromete a una velocidad insostenible, porque el trabajo sin verificar se amontona ante el único humano que puede fiarse de él.

Contexto completo: De producir a asegurar: el nuevo cuello de botella del software →

Es la disciplina de cerrar cada unidad de trabajo con su prueba adjunta: qué se ejecutó, qué produjo y contra qué versión del contrato, guardado donde la siguiente persona y el siguiente agente puedan encontrarlo. Existe porque la mayoría de los flujos se quedan el diff y tiran la prueba, el verde se va scroll arriba de la terminal y desaparece. Cuando el autor es a menudo un modelo que nadie miró línea a línea, la evidencia capturada es el único relato duradero de si el trabajo funciona.

Contexto completo: Desarrollo basado en evidencia: cerrar trabajo con la prueba adjunta →

El estado es una casilla marcada, una pull request integrada, un badge verde. Te dice que se declaró un estado y no lleva casi información sobre si la cosa subyacente es cierta, porque es trivialmente fácil de poner sin que lo sea. La evidencia es lo que pasó de verdad, registrado: el comando que se ejecutó, su salida real, la versión del contrato. De la evidencia puedes reconstruir la verdad; de una casilla solo puedes reconstruir que alguien la marcó.

Contexto completo: Desarrollo basado en evidencia: cerrar trabajo con la prueba adjunta →

Tres cosas, más un sitio donde guardarlas. Los comandos e invocaciones reales, no un resumen. La salida y los códigos de salida tal como salieron, no comprimidos en «tiene buena pinta». Y los criterios de aceptación en la revisión en la que estaban, para que un verde no derive en silencio a los requisitos de ayer. Luego engánchalo al cambio para que viaje con él. Una prueba que no puedes recuperar es indistinguible de una que nunca tuviste.

Contexto completo: Desarrollo basado en evidencia: cerrar trabajo con la prueba adjunta →

Se queda obsoleta de forma visible, que es justo el punto. Una casilla que caduca sigue marcada y no anuncia nada. La evidencia que nombra la versión del contrato contra la que corrió queda en entredicho por sí sola en cuanto el contrato se mueve, así que el sistema puede marcarla: esta prueba se refiere a requisitos que han cambiado, re-verifica. Una obsolescencia que puedes detectar es un problema resuelto, re-ejecutas y vuelves a capturar. Una que no puedes detectar es como una base de código se llena de verdes que se refieren a un mundo que ya no existe.

Contexto completo: Desarrollo basado en evidencia: cerrar trabajo con la prueba adjunta →

Cambia una cosa: la intención nunca estuvo en la cabeza de nadie. Cuando escribes código, la intención vive en tu mente y el test es una segunda expresión independiente de ella. Con código generado falta ese segundo testigo, así que si escribes los tests después de leer la implementación, codifican lo que el código hace en vez de lo que debía hacer. Casi todo lo demás de probar software sigue exactamente igual.

Contexto completo: Probar código generado por IA: qué cambia y qué no →

Porque los escribiste después de leer el código, así que describen la implementación en vez del requisito. El código dice X, el test afirma X, coinciden, verde. Has demostrado que el código hace lo que el código hace y nada sobre lo que querías. El arreglo es escribir las aserciones desde la especificación, no desde el diff, para que el test defienda un comportamiento que existe fuera del código que comprueba.

Contexto completo: Probar código generado por IA: qué cambia y qué no →

No en el mismo paso desde el mismo contexto. Si el modelo malentendió el requisito, lo malentiende de forma consistente, y los tests codifican ese malentendido como resultado esperado. El verde es real, la corrección no. Sepáralos: especifica el comportamiento tú y fíjalo antes de que exista la implementación, luego genera contra eso. Guarda al menos un test que el agente nunca vio. El examen tiene que ser anterior a la respuesta.

Contexto completo: Probar código generado por IA: qué cambia y qué no →

No. La cobertura te dice que una línea se ejecutó, no que una aserción habría cazado su fallo. Puedes ejecutar todas las líneas de un módulo generado sin afirmar casi nada mientras el número queda estupendo, y los agentes son buenísimos produciendo tests que suben la cobertura y no comprueban nada real. Trata la cobertura como un suelo con dientes, un gate por debajo del cual nadie baja, no como un trofeo en un panel. Si tests que no afirman nada satisfacen el gate, el gate es decoración.

Contexto completo: Probar código generado por IA: qué cambia y qué no →

Es un mecanismo de cuatro partes que le quita al agente la decisión de «tuvo éxito»: un disparador lanza una comprobación automáticamente, una comprobación que el agente no puede editar produce un veredicto desde su código de salida, una puerta actúa sobre ese veredicto bloqueando o dejando pasar el trabajo, y un camino de vuelta devuelve los fallos reales para arreglarlos. Se repite hasta que la comprobación pasa o un límite llama a un humano. «Los tests pasan» pasa a ser algo que el agente tiene que hacer verdad, no algo que dice.

Contexto completo: Bucles de verificación: hooks, puertas y el fin del éxito auto-declarado →

Porque deja al agente como lo último entre la comprobación y tu decisión, así que aún puede resumir un fallo como «casi todo pasa, un problema menor, hecho». Eso es éxito auto-declarado con un paso de más, no un bucle. El bucle solo funciona cuando la puerta actúa sobre el veredicto crudo directamente: el código de salida bloquea la integración y la salida del fallo, sin editar, reentra al contexto. En cuanto alguien parafrasea el veredicto antes de que surta efecto, la brecha se reabre.

Contexto completo: Bucles de verificación: hooks, puertas y el fin del éxito auto-declarado →

Un hook ejecuta tu comando automáticamente ante un evento, sin cooperación del modelo. Usa varias capas: un hook del harness que se dispara cuando el agente termina un turno o escribe un fichero (el más ceñido, se autocorrige en la sesión), un hook de pre-commit o pre-push antes de que el cambio entre en la historia, y CI de integración que reejecuta en cada push independiente del setup local de nadie. Las mismas comprobaciones a tres distancias del teclado.

Contexto completo: Bucles de verificación: hooks, puertas y el fin del éxito auto-declarado →

Algo que el agente no redactó. «Compila» se supera enviando el comportamiento equivocado, y «los tests pasan» solo es tan fuerte como los tests, que no valen si el agente los escribió junto al código. Comprueba contra criterios de aceptación escritos antes de generar, una suite que la implementación nunca vio, un escaneo de seguridad con tus reglas, o un build que tenga que producir un artefacto que corre. La regla que separa una puerta real del teatro: tiene que poder fallar. Si no sabes describir la entrada que la pone en rojo, no verifica nada.

Contexto completo: Bucles de verificación: hooks, puertas y el fin del éxito auto-declarado →

Es la distancia entre que el código exista y que estés dispuesto a poner tu nombre en él. Cuando escribías el código despacio a mano, confiabas en él como subproducto de construirlo. Los agentes quitaron la escritura lenta, y la confianza deja de venir gratis. Se queda ahí sin pagar, y resulta ser la parte cara: el código llega en segundos, creértelo te lleva el resto de la tarde.

Contexto completo: La brecha de confianza: por qué el output dejó de ser el cuello de botella →

Porque la generación se aceleró mientras la verificación no. Puedes producir diez implementaciones de una feature antes de comer, pero no puedes confiar en diez antes de comer. El cuello de botella no se desvaneció cuando producir se abarató, se movió a la siguiente cosa más escasa, que es la confianza. El tiempo se mudó de escribir a verificar, y verificar es más duro, porque ahora respondes por código que no escribiste y no entiendes del todo.

Contexto completo: La brecha de confianza: por qué el output dejó de ser el cuello de botella →

Deja de intentar ganarte la confianza subjetivamente leyendo el diff con más ahínco, porque eso solo fabrica una sensación que un agente fluido produce bien. Confía en el proceso: una especificación de correcto escrita antes del código, una comprobación que el agente no puede editar y pasa o falla por su cuenta, y una ejecución registrada con salida real. Esa cadena de evidencia es inspeccionable y escala, porque verificar una afirmación contra evidencia fija es rápido.

Contexto completo: La brecha de confianza: por qué el output dejó de ser el cuello de botella →

En las costuras, donde el código nuevo se encuentra con el viejo, donde una asunción aquí contradice un invariante allá. Un modelo escribe cada pieza para que sea localmente correcta, que es justo lo que se le da bien, así que el diff parece limpio mientras la incoherencia se esconde en lo que el cambio debía respetar. Leer el fichero cambiado es lo que menos te dice aquí. La confianza en las fronteras viene de tests de integración y contratos que cruzan las costuras, no de mirar un fichero con más intensidad.

Contexto completo: La brecha de confianza: por qué el output dejó de ser el cuello de botella →

En el orden contrario al pull request de un compañero: la pregunta más ancha primero. Confirma el alcance, si es siquiera el cambio correcto en los sitios correctos. Luego el radio de impacto, qué comportamiento existente pudo alterar, comprobado por tests y no a ojo. Luego, y solo entonces, lee las líneas, y solo las que cargan riesgo. Cada etapa puede parar la review, y las tempranas y baratas cazan los errores caros que la lectura de líneas nunca encuentra.

Contexto completo: Revisar código que no escribiste: primero el alcance, el diff al final →

Porque las asunciones que hacen funcionar la lectura diff-primero desaparecieron. Un compañero estuvo en la daily, respeta la arquitectura y menciona por qué tocó un módulo ajeno, así que la intención y el alcance ya los responde el contexto compartido. Un agente no tiene nada de eso. Refactorizará un fichero que nunca mencionaste y no te lo dirá. Las preguntas que te ahorras con un humano, «¿es este el cambio correcto?» y «¿qué tocó?», están abiertas de par en par, y el diff las responde el último y peor.

Contexto completo: Revisar código que no escribiste: primero el alcance, el diff al final →

El alcance, en unos treinta segundos. ¿Qué se suponía que hacía esto, y la forma del cambio encaja? ¿Qué ficheros debería tocar una versión correcta, cómo de grande debería ser, se ha desparramado a sitios ajenos? Esto caza errores del conjunto, un agente que reescribió una feature en vez de añadir una, un diff que toca auth cuando la tarea iba de formato de exportación. Si el alcance está mal, para y devuélvelo. Revisar la calidad de un cambio que no debería existir es atención pura desperdiciada.

Contexto completo: Revisar código que no escribiste: primero el alcance, el diff al final →

No. Leer las cuatrocientas líneas con igual atención no es diligencia, es como te agotas hasta perderte las diez que importan. Gasta la atención donde un defecto sea a la vez probable y caro: el código de frontera, la superficie relevante para seguridad, el manejo de entrada, la auth, cualquier cosa que toque datos que salen de la máquina, y las partes que a la especificación de verdad le importaban. Ojea el boilerplate que los tests ya cubren, y vuelca tu lectura donde lo localmente plausible y lo realmente correcto se separan.

Contexto completo: Revisar código que no escribiste: primero el alcance, el diff al final →

Describe código donde cada cambio individual es correcto en sus propios términos pero el sistema entero deja de tener sentido. Cada función hace lo que se le pidió, y sin embargo las piezas se contradicen en sus asunciones, duplican conceptos y derivan de la arquitectura. El modelo optimizó el siguiente paso, que es justo lo que le pasaste, así que produjo un paso localmente correcto sin visión del conjunto al que pertenece.

Contexto completo: Localmente correcto, globalmente incoherente: el problema del código generado por IA →

Porque el resto del sistema casi nunca viaja dentro de su contexto. Cada sesión empieza en blanco. Las decisiones que tomaste ayer, por qué existe una capa, qué invariante protege un módulo, viven en tu cabeza, no en el material que el modelo ve cuando vuelve a tocar el código. Le pides un paso local sin el plano del edificio, y obtienes un paso localmente correcto. Es literalmente lo que pediste.

Contexto completo: Localmente correcto, globalmente incoherente: el problema del código generado por IA →

No, porque la incoherencia no está dentro del modelo. La coherencia nunca ha sido una propiedad de la inteligencia, existen personas brillantes e incoherentes. Es una propiedad del proceso. Consigues un sistema coherente haciendo que la arquitectura, la especificación y la definición de correcto viajen con cada cambio y verificando cada paso contra ellas. Más parámetros no aportan la capa que falta entre tus intenciones y el contexto del modelo.

Contexto completo: Localmente correcto, globalmente incoherente: el problema del código generado por IA →

La coherencia se impone, no se invoca. Convierte la decisión arquitectónica, la spec y la definición de «correcto» en artefactos de primera clase que viajan con cada cambio, y pon un gate a cada cambio contra ellos para que nada llegue a «hecho» sin demostrarlo. Es el salto de spec-driven a spec-gated: la especificación no es un documento que se pudre en el repo, es el gate que decide. Es el andamiaje, no el talento, lo que hace que hasta un junior o un agente produzcan coherencia.

Contexto completo: Localmente correcto, globalmente incoherente: el problema del código generado por IA →

Cuando un humano decía «hecho», respondía de que había ejecutado la cosa, entendía el cambio y sería suyo el bug si se equivocaba. Ese aseguramiento vivía en el juicio y la apuesta de la persona, no en la checklist. Un agente emite «hecho» como la palabra más probable tras una interacción con forma de tarea. No apuesta nada y llega con seguridad total funcione la feature o no, así que todo proceso construido sobre creer la palabra ahora no cree nada.

Contexto completo: Una definición de «hecho» que sobrevive a la velocidad de la IA →

Coge cada línea de tu vieja definición y pregunta: ¿cuál es la evidencia y quién la produjo? Si la respuesta es «lo dice el agente», reescríbela. No «los tests pasan» sino «la suite corrió y su salida está adjunta». No «cumple los requisitos» sino «contrastado contra criterios de aceptación que existían antes del código». No «revisado» sino «radio de impacto verificado mecánicamente, alcance confirmado por un humano». Sustituye la palabra del agente por un artefacto y nombra el proceso que lo hizo.

Contexto completo: Una definición de «hecho» que sobrevive a la velocidad de la IA →

Un estado es una etiqueta, «completo», «pasando», «listo», que un agente produce al instante, y se ve idéntica a ambos lados de la frontera entre funcionar y estar roto. La evidencia es un artefacto que puedes inspeccionar que se vería distinto si el trabajo no estuviera hecho de verdad: un proceso de test que salió con código cero con su salida guardada, un build que produjo un binario que corre. No puedes generar evidencia siendo seguro de ti mismo. Existe porque algo real ocurrió, o no existe.

Contexto completo: Una definición de «hecho» que sobrevive a la velocidad de la IA →

Sí, o no se recopila. Cuando una persona publica el código de una semana en un día, «reunimos la evidencia en la release» significa que nadie reconstruye la prueba de cuarenta cambios integrados a posteriori. «Hecho» significa que la prueba se adjunta en el momento de completar, por cambio, por el proceso que hace el trabajo. Una definición que necesita que un humano ensamble la evidencia después da por supuesto un bucle lento y dotado de personal que ya no existe.

Contexto completo: Una definición de «hecho» que sobrevive a la velocidad de la IA →

No. La IA ha abaratado construir, lo que ha movido el cuello de botella de construir a decidir qué construir y con qué evidencia. El juicio del PM importa más, no menos. Pasa de escribir requisitos a diseñar el bucle de decisión: qué explorar, qué validar y qué evidencia tiene que respaldar una elección antes de que los agentes la conviertan en código publicado.

Contexto completo: Product management en la era de la IA: construir es barato, decidir es caro →

Decidir y aprender. Cuando los agentes construyen en horas, la ventaja ya no es producir features más rápido, es decidir mejor qué construir y validarlo antes de acumular deuda de producto. Construir barato te deja generar más pantallas, más épicas, más experimentos, y más deuda. Si el sistema de decisión no mejora al mismo ritmo, esa velocidad solo acelera la dispersión.

Contexto completo: Product management en la era de la IA: construir es barato, decidir es caro →

Los evals definen qué es un buen comportamiento de producto, qué fallos son inaceptables y qué evidencia sostiene una recomendación. Funcionan como PRDs vivos: en vez de describir una feature una vez, comprueban continuamente si el producto se comporta como prometió. Cada recomendación se vuelve evaluable, si mantuvo recta la provenance, separó evidencia de hipótesis y propuso una validación siguiente concreta.

Contexto completo: Product management en la era de la IA: construir es barato, decidir es caro →

No. Claude Code es excelente para diagnóstico ad hoc del repo: leer código en crudo con precisión, detectar dispersión y deuda, contestar una pregunta local afilada. Su límite es la continuidad, el contexto se reconstruye en cada chat. Brújula es la capa que persiste: provenance, historial, un grafo de producto y evals de producto, para que el equipo no reanalice su producto desde cero cada vez.

Contexto completo: Product management en la era de la IA: construir es barato, decidir es caro →

Un registro de decisiones es un registro ligero de las elecciones que toma un equipo, capturadas según ocurren. Cada entrada formula la decisión como una afirmación con la que podrías discrepar, el contexto que la forzó, las alternativas que perdieron y quién la posee. No es un acta de reunión, que recoge qué se dijo. Un registro recoge qué se decidió, lo bastante cerca del trabajo como para seguir diciendo la verdad.

Contexto completo: Decision logs: el fin del «yo nunca acordé eso» →

Cuatro cosas por entrada, no más. La decisión en sí, formulada como una afirmación («lanzamos con tres tramos, no con facturación por uso»). El contexto que la forzó, en una o dos frases. Las alternativas que perdieron, nombradas, para que nadie las reabra como ideas nuevas. Y quién la posee, para que haya una persona a la que preguntar. Nada de justificaciones largas ni plantillas de quince campos, o el registro deja de mantenerse.

Contexto completo: Decision logs: el fin del «yo nunca acordé eso» →

Junto al trabajo que gobierna, no en una página de wiki que nadie abre. Una decisión sobre un contrato de API va junto a ese contrato; una decisión sobre lo que una feature hace y no hace va pegada a esa feature. Cuando el registro está a un clic de lo que gobierna, la gente escribe las decisiones de verdad y las lee de verdad. La distancia es lo que mata un registro.

Contexto completo: Decision logs: el fin del «yo nunca acordé eso» →

El acta recoge qué se dijo; el registro recoge qué se decidió. El acta es una transcripción de una conversación, así que conserva la ambigüedad que causó el «yo nunca acordé eso» de entrada. El registro lo resuelve en una sola afirmación con su contexto y sus alternativas descartadas, lo bastante duradera para que un compañero, alguien nuevo o un agente construya contra ella sin volver a preguntar.

Contexto completo: Decision logs: el fin del «yo nunca acordé eso» →

No es vagancia, ni que sea largo. Nadie lo lee porque un PRD queda terminado en el momento en que lo escribes y vive donde el trabajo no está. En una semana discrepa del producto; en un mes todo el mundo sabe que está desactualizado, así que deja de fiarse. Leer un documento que sabes obsoleto es peor que no leerlo.

Contexto completo: Escribes PRDs que nadie lee. El problema es el artefacto. →

El documento, cada vez menos. El trabajo que hacía, más que nunca. Lo que cambia es el artefacto: un PRD estático ahora es peligroso porque un agente lee su ambigüedad, la resuelve en silencio con la suposición equivocada y publica rápido. El requisito tiene que existir, pero como una decisión viva y pequeña cableada al código y a la evidencia, no como una foto fija que nadie mantiene.

Contexto completo: Escribes PRDs que nadie lee. El problema es el artefacto. →

Una decisión viva conectada al trabajo, no un documento mejor. Hazla pequeña y direccionable, para revisar un comportamiento sin republicar cincuenta secciones. Cablearla al código que la satisface y a la comprobación que la prueba, para que un cambio en cualquier lado sea visible. Mantenla viva como parte del flujo del trabajo, para que su estado actual sea la verdad actual.

Contexto completo: Escribes PRDs que nadie lee. El problema es el artefacto. →

Un ingeniero humano leía un PRD vago, rellenaba el hueco con criterio y volvía con una pregunta. Un agente no. Resuelve la misma ambigüedad en silencio con la interpretación más probable, muchas veces no la tuya, y la construye rápido. La vaguedad que una persona habría marcado se vuelve una feature publicada que encaja con las palabras y se salta la intención, sin nadie en el bucle que la cace.

Contexto completo: Escribes PRDs que nadie lee. El problema es el artefacto. →

Para el comportamiento, sí, y mejor. Un prototipo no es una descripción de la interacción, es la interacción, así que no se puede leer de tres formas. Fija el timing, el estado, el comportamiento límite y el layout, lo que la prosa erra de forma fiable. Pero solo sustituye la parte de la spec que dice qué hace el producto. El razonamiento y las restricciones siguen necesitando un registro escrito.

Contexto completo: El prototipo como spec: imposible de malinterpretar →

Tres cosas. No dice por qué el flujo funciona así, solo que funciona, así que la intención se evapora salvo que la registres aparte. No captura el contrato no funcional: rendimiento bajo carga, escala, seguridad, modos de fallo. Y implica calladamente mil elecciones incidentales, colores, textos, orden, que un lector no distingue de las deliberadas. Especifica todo con la misma seguridad.

Contexto completo: El prototipo como spec: imposible de malinterpretar →

Sí, una fina. El prototipo responde «qué hace exactamente», que la prosa hace mal. Una decisión escrita corta responde «por qué, qué tiene que aguantar y qué partes son de carga frente a incidentales», que el prototipo no responde en absoluto. Juntos son una spec completa difícil de malinterpretar. El prototipo sin la intención es una decisión sin memoria de por qué.

Contexto completo: El prototipo como spec: imposible de malinterpretar →

Sé explícito sobre qué está especificando y qué es solo andamiaje. Un prototipo toma mil elecciones incidentales y las presenta todas con la misma seguridad, así que un lector asciende defaults accidentales a requisitos si no dices lo contrario. Empareja la cosa en marcha con una nota corta sobre qué partes son de carga y cuáles provisionales, para que el borde esté dicho, no adivinado.

Contexto completo: El prototipo como spec: imposible de malinterpretar →

Puede hacer la mitad de pensar, no la de decidir. La IA es estupenda para ampliar el espacio de opciones, poner a prueba un argumento, reencuadrar un problema y estructurar observaciones dispersas. Es peligrosa en cuanto empieza a decirte qué quieren los usuarios reales, porque nunca los ha conocido. Úsala para expandir y presionar tu pensamiento; la decisión, y el contacto con la realidad, siguen siendo tuyos.

Contexto completo: Discovery con IA: socia para pensar, no para decidir →

No, aunque sonará como si pudiera. Pregúntale a un modelo con qué luchan tus usuarios y genera la respuesta más probable a «con qué luchan los usuarios de algo así», que es una pregunta distinta de con qué luchan tus usuarios. Ese hueco es el trabajo entero del discovery. La respuesta es una hipótesis plausible, no un hallazgo, hasta que un usuario real la confirma.

Contexto completo: Discovery con IA: socia para pensar, no para decidir →

Blanqueo es cuando una hipótesis que generó un modelo se cita después como si fuera evidencia que te dio un usuario. Pasa poco a poco: una lluvia de ideas del lunes se vuelve un doc el jueves y una decisión de construcción a la semana siguiente, perdiendo un poco de «creemos» y ganando un poco de «sabemos» en cada paso. Nadie mintió, pero la suposición de un modelo acaba con la autoridad de la investigación.

Contexto completo: Discovery con IA: socia para pensar, no para decidir →

Mantén la provenance despiadadamente visible. Etiqueta cada afirmación por fuente: generada por modelo, de usuario o de datos, y nunca dejes que parezcan lo mismo. Trata cada dolor sugerido por el modelo como una deuda a validar, no un hecho sobre el que construir. Nunca dejes que un modelo resuma investigación en conclusiones sin supervisión, alisa la incertidumbre y tira la cita que contradice. Si una creencia no puede decir de dónde vino, todavía no es evidencia.

Contexto completo: Discovery con IA: socia para pensar, no para decidir →

Antes de construir una feature, encuentras la asunción de la que depende que sea a la vez más probable que esté equivocada y más cara de que lo esté, y pruebas esa, barata, primero. Si toda la idea descansa sobre una creencia que resulta falsa, todo lo construido encima fue desperdicio. Así que sondeas la creencia de carga antes de verter los cimientos.

Contexto completo: Prueba la asunción más arriesgada antes de que los agentes lo construyan todo →

Por cada cosa que la feature da calladamente por hecha, hazte dos preguntas: cuánta confianza tengo en que es cierto, y cuánto de la idea se derrumba si es falso. La asunción que es a la vez tambaleante y de carga es la que hay que probar primero. Normalmente no es técnica, porque los agentes hacen eso fácil. Es una creencia sobre si los usuarios lo quieren, confían en ello o pagarán por ello.

Contexto completo: Prueba la asunción más arriesgada antes de que los agentes lo construyan todo →

No. Una feature entera arrastra una cola de decisiones, estados y pulido que tienes que mantener, y funde una docena de asunciones en una señal turbia, así que cuando falla no sabes qué creencia estaba mal. Apunta el construir barato a la única creencia arriesgada: construye el sondeo más pequeño que la interrogue y nada más, y que sea barato de tirar.

Contexto completo: Prueba la asunción más arriesgada antes de que los agentes lo construyan todo →

Porque el coste de construir antes forzaba el pensamiento. Cuando construir era caro, tenías que nombrar la asunción arriesgada antes de poder permitirte construir. Ahora un agente construye la feature entera en una tarde, así que la fricción desapareció y el default es saltar directo a la construcción, publicando algo que descansa sobre una creencia que nunca comprobaste. Los experimentos se abarataron; nombrar qué probar sigue siendo tu trabajo.

Contexto completo: Prueba la asunción más arriesgada antes de que los agentes lo construyan todo →

El slop de IA en producto es el modo de fallo donde el volumen de artefactos trepa y la calidad de las decisiones se queda plana. Más PRDs, más tickets, más decks pulidos, producidos más rápido y leídos menos. Es peligroso porque no parece un fallo, parece un equipo productivo, ya que el output es visible y va bien formateado. Lo único que importaba, decidir mejor, no se movió.

Contexto completo: Slop de IA con buen formato: el modo de fallo del producto asistido por IA →

Hazle una pregunta a cualquier documento: ¿qué decisión mejoró porque esto existe? Si la respuesta de verdad es «ninguna, pero parece exhaustivo», es slop. Vigila el PRD exhaustivo detrás de una elección de cinco minutos que nadie puso a prueba, un backlog doblado de tickets bien formados, un análisis que concluye lo que ya creías, e insights que nadie ejecuta. Cada uno pasa la review porque el artefacto está bien hecho.

Contexto completo: Slop de IA con buen formato: el modo de fallo del producto asistido por IA →

No. Un modelo que convierte una decisión que de verdad tomaste en un PRD limpio y bien estructurado hace un trabajo útil, comprime el envoltorio para que tu tiempo vaya a decidir. El slop aparece solo cuando el envoltorio se adelanta a la decisión, cuando el artefacto existe y la decisión detrás no. La prueba es la dirección: ¿es el documento consecuencia de una elección que sudaste, o sustituye a una que nunca tomaste?

Contexto completo: Slop de IA con buen formato: el modo de fallo del producto asistido por IA →

Las herramientas de productividad anteriores seguían haciéndote pensar para producir el artefacto; un editor mejor no escribía el argumento del PRD, lo escribías tú. La IA produce el artefacto entero, argumento incluido, desde un prompt fino, así que existe sin el pensamiento que antes era su única razón de existir. Producir documentos con forma de decisión se volvió casi gratis mientras las decisiones de dentro no mejoraron, así que la proporción de envoltorio a sustancia explotó.

Contexto completo: Slop de IA con buen formato: el modo de fallo del producto asistido por IA →

Es el razonamiento detrás de cada feature: aprendes algo real sobre un usuario o un mercado (insight), ese aprendizaje fuerza una elección (decisión), y lo que publicas mueve un número o no (resultado). El trabajo de producto es mantener los tres atados para que la siguiente decisión sea más lista que la anterior. Cuando la cadena sigue intacta, «por qué existe esto» tiene respuesta.

Contexto completo: Insight → decisión → resultado: la cadena que la velocidad de la IA rompe →

Porque la fricción la preservaba gratis. Cuando convertir una decisión en código llevaba semanas, el razonamiento se escribía para sobrevivir a una reunión de planificación y el resultado se comprobaba antes de publicar lo siguiente. Ahora un agente construye en una tarde, así que la decisión no necesita defenderse, la spec deja de ser un punto de control, y pasas a lo siguiente antes de nombrar qué probaría que funcionó. Cada eslabón se parte.

Contexto completo: Insight → decisión → resultado: la cadena que la velocidad de la IA rompe →

Produce el rastro a propósito, como propiedad del trabajo. Engancha el insight a la decisión, para que lo que aprendiste viaje con la elección. Engancha la decisión al artefacto, para que el código apunte de vuelta a lo que lo autorizó. Engancha el artefacto al resultado: nombra el número a mover antes de publicar, y luego registra «decidimos X, esperando Y, y salió Z».

Contexto completo: Insight → decisión → resultado: la cadena que la velocidad de la IA rompe →

Una feature que no puedes conectar a un insight ni a un resultado. Una sin insight trazable la construiste porque podías, no porque supieras algo. Una sin resultado medido es una apuesta que nunca liquidaste. Ambas son deuda de producto, y ambas componen, porque un código lleno de huérfanas es uno donde el siguiente equipo no distingue qué partes sostienen la casa y cuáles fueron corazonadas.

Contexto completo: Insight → decisión → resultado: la cadena que la velocidad de la IA rompe →

John Cutler acuñó el término feature factory.

Contexto completo: ¿Qué es una feature factory? →

No. A veces productizar es lo correcto: alcanzar paridad, no perder un cliente, ganar tiempo. El problema es hacerlo en modo automático, sin saberlo.

Contexto completo: ¿Qué es una feature factory? →

La IA abarata generar features casi a cero, lo que acelera la feature factory salvo que la intención y la verificación estén aguas arriba. La disciplina que lo contrarresta es la misma idea un nivel más abajo: un build en verde no es una feature correcta.

Contexto completo: ¿Qué es una feature factory? →

Hacer producto es instalar un comportamiento nuevo: que mañana el usuario haga algo distinto porque tu producto se lo hace más fácil o más inevitable. Productizar es añadir superficie sin nada debajo, una integración porque la competencia la tiene, una vista porque alguien la pidió, cada una con su lógica y ningún comportamiento objetivo detrás. Una crea ventaja acumulada; la otra, deuda de atención.

Contexto completo: Hacer producto no es productizar: cómo salir de la feature factory →

Significa que el usuario reorganiza parte de su trabajo o su vida alrededor de tu producto y no lo abandonaría aunque irse fuera gratis. Bloomberg es el ejemplo: un trader organiza su jornada entera alrededor del terminal, y su chat conecta a cientos de miles de profesionales, así que salir es cambiar de vida profesional, no de herramienta. Si nadie cambia lo que hace, hiciste software, no producto.

Contexto completo: Hacer producto no es productizar: cómo salir de la feature factory →

Completa una frase antes de escribir ninguna spec: «Gracias a esto, [tipo de usuario] pasará de hacer [X] a hacer [Y], y lo sabremos cuando veamos [métrica Z]». Si puedes rellenarla, tienes una idea de producto con un comportamiento objetivo y una señal. Si no puedes, tienes una idea de feature, superficie sin comportamiento detrás.

Contexto completo: Hacer producto no es productizar: cómo salir de la feature factory →

Porque la IA hace dos cosas a la vez: vuelve barata de copiar cualquier feature y barato de cruzar cualquier coste de cambio. Cuando ambos se desploman, descubres si instalaste un comportamiento genuino que el usuario mantendría aunque irse fuera gratis, o si vivías de la fricción y la inercia de la suscripción. Lo único que sobrevive a las dos es haber cambiado de verdad lo que alguien hace.

Contexto completo: Hacer producto no es productizar: cómo salir de la feature factory →

Es la versión de producto del «hecho significa hecho»: una decisión no se cierra hasta que la evidencia que la justificó viaja con ella. «Elegimos X» por sí solo es un rumor con fecha, sabes que se tomó una elección y más o menos cuándo, pero no sobre qué base, así que después no distingues una buena decisión que envejeció mal de una mala que tuvo suerte. La evidencia y la decisión se mueven juntas o la decisión es solo una frase.

Contexto completo: Decisiones de producto con la evidencia adjunta →

Tres cosas que viajan con ella al cerrarse. La evidencia que la sostuvo, la señal real del usuario o el dato de uso, registrada como corazonada si eso era. El supuesto en el que se apoya, la creencia de carga que, si es falsa, hace la decisión errónea. Y el test de refutación, qué te diría que estaba mal y cuándo lo mirarás. Sin el tercero, has vuelto la decisión infalsificable en silencio.

Contexto completo: Decisiones de producto con la evidencia adjunta →

Coge una decisión de hace un trimestre e intenta auditarla en frío, sin preguntar a nadie. Si puedes ver qué se sabía, qué se asumió y qué la habría refutado, se cerró con su evidencia adjunta. Si solo puedes ver que se tomó una elección, tienes una fecha y un rumor. Córrelo sobre diez decisiones; la proporción te dice cuánto de tu razonamiento sigue siendo auditable.

Contexto completo: Decisiones de producto con la evidencia adjunta →

Es nombrar, por adelantado, qué te diría que la decisión estaba mal y cuándo lo vas a mirar. Una decisión sin test de refutación es una que has vuelto infalsificable en silencio: la defenderás para siempre pase lo que pase, porque nunca dijiste qué aspecto tendría el fracaso. Nombrarlo convierte una decisión de una opinión que proteges en una apuesta que puedes liquidar.

Contexto completo: Decisiones de producto con la evidencia adjunta →

Porque es una traducción. El PM tiene un modelo rico del problema y lo serializa en un ticket; el ingeniero lo deserializa de vuelta a un modelo mental para construir. Todo lo que no cupo en el párrafo, el supuesto que se prueba, las alternativas descartadas, las restricciones, se cae en la costura. Los dos trabajan en mundos de contenido separados unidos solo por un número de ticket y la memoria en dos cabezas.

Contexto completo: El puente PM–ingeniería: un solo sistema del discovery al código mergeado →

Un traspaso asume dos mundos e intenta mover cosas entre ellos limpiamente, así que el significado se comprime en cada sentido. Un puente significa que el artefacto de discovery, la decisión, la spec y el código mergeado son nodos de un solo grafo con identidad compartida, de modo que la conexión entre ellos es un hecho que el sistema sostiene, no un recuerdo que dos personas mantienen. Los traspasos gotean; un puente no.

Contexto completo: El puente PM–ingeniería: un solo sistema del discovery al código mergeado →

La pérdida por traducción no desapareció, se aceleró. Cuando un agente convierte un ticket comprimido en código mergeado en una tarde, el código llega más rápido de lo que nadie alcanza a captar qué se dejó por el camino. La costura que siempre goteaba ahora gotea a velocidad de agente, y llega más código cargando menos de su porqué. La conexión que la lentitud preservaba se rompe, así que tiene que volverse propiedad del sistema.

Contexto completo: El puente PM–ingeniería: un solo sistema del discovery al código mergeado →

Necesitas provenance en ambas direcciones, que casi ninguna herramienta te da. Un repo te dice qué hace el código y nada de por qué; una herramienta de discovery te dice qué querías y nada de si se publicó. Un puente enlaza el insight de discovery, la decisión, la spec y el commit con identidad compartida, así que puedes empezar en el código mergeado y aterrizar en la razón de que exista, como un recorrido, no un recuerdo.

Contexto completo: El puente PM–ingeniería: un solo sistema del discovery al código mergeado →

Puede sintetizar research que reuniste de verdad, no reemplazar el reunirlo. Un modelo lee cuarenta entrevistas y devuelve seis temas limpios en un minuto, y eso es una ganancia real porque el cuello de botella de la síntesis eran las horas de lectura, no el insight. Lo que no puede es originar un hecho sobre tus usuarios que ningún usuario aportó. Ese hecho no existe en nada que haya leído, así que solo puede producir una conjetura bien formada.

Contexto completo: Research de usuarios con IA sin blanquear la evidencia →

La síntesis comprime evidencia que existía antes de que el modelo la tocara: personas reales, transcripciones reales, patrones hechos legibles. La sustitución fabrica evidencia que nunca se reunió: una persona simulada respondiendo preguntas que ningún humano respondió. Son distintas en naturaleza, no dos puntos de un espectro. Una amplifica evidencia, la otra la fabrica, y todo fallo serio del research asistido por IA es hacer lo segundo llamándolo lo primero.

Contexto completo: Research de usuarios con IA sin blanquear la evidencia →

Es el proceso por el que la conjetura de un modelo pierde su fuente y adquiere la credibilidad de un hallazgo según se mueve por tus documentos. Un modelo extrapola más allá de ocho entrevistas reales, la presentación formatea las afirmaciones inventadas igual que las reales, un bullet pasa a un doc de estrategia sin su fuente, y una semana después es una decisión. Nadie mintió, pero una conjetura carga ahora con la autoridad de ocho humanos.

Contexto completo: Research de usuarios con IA sin blanquear la evidencia →

No como evidencia. Una persona respondiendo preguntas que ningún humano respondió es el prejuicio del modelo sobre los usuarios disfrazado de datos, y va en la columna de hipótesis con una nota de ir a averiguarlo, no en la de evidencia dirigiendo una decisión. La regla es una frase: cada afirmación apunta a una frase de un usuario. Si puedes nombrar a la persona real que lo dijo, es research; si la única fuente es el modelo, es opinión.

Contexto completo: Research de usuarios con IA sin blanquear la evidencia →

Son tres cosas: quién hace qué (roles), qué produce el trabajo (artefactos) y cómo el equipo se mueve por el tiempo (ritmo). La versión tradicional, el PM escribe requisitos, el ingeniero escribe código, el trabajo en lotes de sprints, se diseñó para un mundo donde escribir código era el paso lento y caro. Cuando los agentes asumen la construcción, los tres tienen que cambiar, porque el supuesto sobre el que se construyeron desapareció.

Contexto completo: Un modelo operativo para equipos de producto que construyen con agentes →

Teclear deja de ser el recurso escaso, así que los dos roles humanos suben un nivel. La persona de producto deja de escribir requisitos y posee el contrato y el bucle de decisión, manteniendo «correcto» legible y al día mientras los agentes construyen contra ello. El ingeniero deja de producir código y posee el harness y la puerta, el entorno donde corren los agentes y los chequeos que un cambio debe pasar. Ninguno se encogió; los dos dejaron de medirse por output.

Contexto completo: Un modelo operativo para equipos de producto que construyen con agentes →

Tres artefactos vivos y un ritmo más apretado. La spec, un contrato que el propio agente puede leer, reemplaza al PRD. El decision ledger, una memoria de qué se decidió y por qué, reemplaza la secuencia fija del roadmap. El registro de evidencia, prueba de qué corrió y qué pasó, reemplaza al informe de estado. Y el sprint cede a un bucle apretado, discovery a spec a construcción a verificación, corrido en horas y en paralelo.

Contexto completo: Un modelo operativo para equipos de producto que construyen con agentes →

Porque casi todos los equipos mejoran las herramientas y dejan el modelo operativo intacto: compran agentes pero conservan el PRD, el roadmap, el sprint, y miden a la gente por output. Lo que consiguen es el modelo viejo corriendo más rápido, así que sus debilidades componen más rápido también, más PRDs sin leer, más ficción de roadmap, más output sin verificar. El flujo rápido solo produce buenos outcomes cuando corre a través de una verificación fuerte; sin ella, la velocidad solo acelera el daño.

Contexto completo: Un modelo operativo para equipos de producto que construyen con agentes →

Un call graph es parte de él. Un call graph captura qué función llama a cuál, y ese es uno de los tipos de relación más útiles. Un grafo de conocimiento del código completo lleva más: tipos, flujo de datos, tests, config, endpoints, y los enlaces hacia los artefactos de producto y las decisiones. El call graph te dice la estructura de control del código. El grafo de conocimiento añade por qué existe el código y qué se supone que satisface.

Contexto completo: Grafos de conocimiento del código: qué son y por qué los agentes los necesitan →

Probablemente todavía no. Un codebase pequeño cabe en una cabeza y a menudo en una ventana de contexto, y el mapa es barato de reconstruir leyendo. El grafo se gana el sueldo cuando el código crece más de lo que una persona puede aguantar, cuando varios agentes trabajan en paralelo sobre él, o cuando la gente que llevaba el mapa en la cabeza se va. Que es también, no por casualidad, justo cuando los agentes empiezan a romper cosas que nunca vieron.

Contexto completo: Grafos de conocimiento del código: qué son y por qué los agentes los necesitan →

Sí, y deberías, porque uno mantenido a mano se pudre. El grafo debería construirse leyendo el código, la estructura de llamadas y los tests, para que siga siendo una proyección del sistema real. Las partes que no se pueden leer del código, sobre todo el enlace de provenance del código a la decisión que lo pidió, son las que merece la pena adjuntar a propósito según se completa el trabajo, para capturar el porqué mientras todavía se conoce. ↓ Descargar PaellaDoc · macOS ¿Qué se rompe en tu codebase que una búsqueda nunca te habría avisado? Cuéntame en el foro.

Contexto completo: Grafos de conocimiento del código: qué son y por qué los agentes los necesitan →

Una representación del producto que has construido como sistema: zonas, relaciones, provenance, distancia al core y validación, no solo una lista de features ni una jerarquía PRD-a-criterios-de-aceptación. Su valor es la topología, la forma de lo que existe.

Contexto completo: Grafo de conocimiento de producto: lee la forma de tu producto, no la lista de features del repo →

El centro real del producto construido, las periferias caras, las capacidades puente entre zonas, qué es infraestructura y qué es valor de usuario, dónde se concentra el esfuerzo, y dónde hay mucha construcción con poca validación. No puede probar que los usuarios amen una feature, que una zona genere revenue, ni que el mercado lo quiera.

Contexto completo: Grafo de conocimiento de producto: lee la forma de tu producto, no la lista de features del repo →

No leyendo código. Claude Code es excelente para diagnóstico ad hoc del repo. Brújula es para la continuidad: un mapa de producto persistente con provenance, topología y deuda de validación, para que las preguntas de producto no empiecen desde cero cada vez. La mejor combinación usa Brújula para el mapa y Claude Code para auditorías concretas.

Contexto completo: Grafo de conocimiento de producto: lee la forma de tu producto, no la lista de features del repo →

No. Un grafo leído desde el producto construido muestra lo que el producto sugiere, no la intención original del equipo, ni la validación de usuarios, ni la demanda de mercado. Tiene que marcar qué está construido, qué está inferido y qué está realmente probado, y mantenerlos separados.

Contexto completo: Grafo de conocimiento de producto: lee la forma de tu producto, no la lista de features del repo →

Normalmente porque le falta un mapa de la estructura, no porque tu prompt sea corto. Hace grep, lee unos ficheros e infiere las relaciones que importan, y se salta las no obvias, como un llamador en otro paquete. El fallo es estructural, y ninguna cantidad de mejor redacción cierra un hueco estructural.

Contexto completo: Mapas del código, no prompts más largos →

No es buena documentación. Es la estructura leída del código: la estructura de llamadas (qué llama a qué), la de dependencias, el flujo de tipos y datos, las fronteras entre módulos, los puntos de entrada y la alcanzabilidad. Como es una proyección del código, se regenera cuando el código cambia en vez de envejecer como un doc de arquitectura escrito a mano.

Contexto completo: Mapas del código, no prompts más largos →

Porque la prosa no compone. Cada frase es más que leer, más que potencialmente contradecir, y estructura que el modelo tiene que re-derivar en cada run, y te saltas las aristas que te parecen obvias. Un mapa entrega la estructura como hechos consultables, así que mil aristas cuestan casi nada hasta que el agente consulta las diez que necesita.

Contexto completo: Mapas del código, no prompts más largos →

Se apaña con más parte y sigue empezando cada sesión desde cero, reconstruyendo las relaciones desde el texto pegado en cada run. Las relaciones que te rompen son las no obvias que una lectura desde cero tiene más probabilidad de saltarse. Entrégale el mapa y gasta su capacidad en la tarea en vez de en re-derivar el terreno.

Contexto completo: Mapas del código, no prompts más largos →

Porque en cada sesión llegan como un ingeniero de primer día sin memoria y, a diferencia de un humano, sin nadie a quien preguntar. Así que hacen grep, leen unos ficheros e infieren. La mayoría de lo que la gente le echa al modelo es un fallo de onboarding: al agente lo soltaron en un sistema cuyo mapa vive en cabezas que no puede leer.

Contexto completo: Onboarding contra el grafo, no contra el conocimiento tribal →

En vez de transferir el mapa del sistema desde cabezas senior pregunta a pregunta, tanto los ingenieros nuevos como los agentes nuevos consultan un grafo de conocimiento del código construido desde el código real. «Qué llama a esto» y «qué se rompe si lo cambio» se responden cuando quieras, bien, sin interrumpir a nadie, desde un mapa que no recuerda mal.

Contexto completo: Onboarding contra el grafo, no contra el conocimiento tribal →

No. Cubre la mitad estructural del onboarding, que es casi toda la primera semana: qué existe, qué llama a qué, qué se rompe si tocas esto. Es más flojo en el porqué que nunca llegó a un artefacto, la historia política y las decisiones bajo deadline. Reserva la atención escasa del senior para eso, no para las cien preguntas estructurales.

Contexto completo: Onboarding contra el grafo, no contra el conocimiento tribal →

Dales algo contra lo que onboardear que no sea conocimiento tribal. Construye el grafo desde el repo, mantenlo aguas abajo del código para que siga siendo verdad, y haz que los agentes lo consulten antes de actuar. Un mapa mantenido a mano es conocimiento tribal con pasos extra; se desfasa y miente con autoridad de aspecto oficial.

Contexto completo: Onboarding contra el grafo, no contra el conocimiento tribal →

Por una razón estructural, no por pereza. Un doc tradicional es una segunda copia de la verdad, en un sitio distinto del código y atada a él por una sola cosa: un humano acordándose de actualizarla. Ese enlace es manual, tarea de nadie, y falla en silencio, así que el doc se vuelve menos verdad sin dejar de parecer autoritativo.

Contexto completo: Documentación viva: docs que dejan de pudrirse →

Documentación con el humano sacado del camino de actualización. En vez de escribir los docs al lado del sistema, los derivas de él, así que una descripción de API generada desde las rutas reales cambia cuando cambia una ruta, y una vista de arquitectura leída del grafo del código muestra un servicio nuevo en cuanto existe. No hay segunda copia que se desincronice.

Contexto completo: Documentación viva: docs que dejan de pudrirse →

No, docs-as-code es una media tinta. Meter markdown en el repo, revisado en pull requests, acerca la segunda copia al código y mejora las probabilidades de que un humano note el desfase. Pero la copia y el humano siguen ahí. La documentación viva es el paso más allá: para todo lo que se puede leer del código, borra la copia y renderiza una vista.

Contexto completo: Documentación viva: docs que dejan de pudrirse →

El porqué. El qué y el cómo, las rutas, la estructura de llamadas, las dependencias, la forma, se leen del código. La razón por la que se tomó una decisión no es visible en el código que resultó de ella, así que hay que capturarla a propósito cuando se toma y atarla al código que gobierna. Deriva todo lo demás; gasta tu atención en el porqué.

Contexto completo: Documentación viva: docs que dejan de pudrirse →

Porque una carpeta de notas no tiene forma de saber que el producto cambió. Escribes el PRD el lunes; el viernes el equipo shipeó tres cambios, dos contradiciéndolo, y nadie actualizó el doc porque no es tarea de nadie. La IA responde entonces con seguridad sobre un producto que ya no existe. El problema nunca fue el fichero.

Contexto completo: El cerebro de producto que se mantiene solo →

Una carpeta es un montón que no sabe qué se relaciona con qué, así que no puede decirte qué historias invalidó una decisión que cambió. Guarda el contexto como grafo y cada artefacto es un nodo con relaciones tipadas, así que cambias una decisión y ves cada historia y criterio aguas abajo que toca.

Contexto completo: El cerebro de producto que se mantiene solo →

La verificación contra el criterio que definió el trabajo, no un clic en «hecho». Una tarea marcada como hecha es una opinión: el build se puso verde, la tarjeta se movió, nada de eso significa que el código haga lo que pedía la historia. Actualiza en cada clic y el cerebro se llena de mentiras con aplomo más rápido de lo que las cazas.

Contexto completo: El cerebro de producto que se mantiene solo →

Ata el código a la decisión que lo pidió, con enlaces tipados duraderos, y deja que completar signifique producir la evidencia que un criterio exigía, no afirmarla. Entonces el cerebro cambia cuando cambia el trabajo, porque el enlace entre ellos es el mismo hecho. Mantenerlo verdadero deja de ser una tarea y pasa a ser una propiedad de cómo se trabaja.

Contexto completo: El cerebro de producto que se mantiene solo →

La capa por encima del código que un equipo olvida: las decisiones que se tomaron, las razones detrás de ellas, y los callejones sin salida que probaste y abandonaste. El código sobrevive porque todos están obligados a conservarlo. Esa capa no, salvo que algo sea responsable de guardarla, y en casi todos los montajes nada lo es.

Contexto completo: Memoria de producto: lo que tu equipo olvida y tu sistema no debería →

Porque la razón por la que se zanjó vive en la cabeza de alguien, y esa persona se fue en primavera o ahora se acuerda distinto. Sin un registro enlazado al código que gobierna, una decisión no deja rastro, así que parece arbitraria y la revierte en silencio gente que nunca supo que era una decisión.

Contexto completo: Memoria de producto: lo que tu equipo olvida y tu sistema no debería →

Porque un agente no tiene memoria más allá de lo que le entregas, y la rama borrada que probaba que el enfoque falla es justo lo que tu flujo tiró. Ve un problema que el enfoque abandonado resolvería con elegancia y lo monta, caminando directo de vuelta por el callejón sin salida, porque razonable-sin-memoria es el fallo.

Contexto completo: Memoria de producto: lo que tu equipo olvida y tu sistema no debería →

Atada a lo que explica, no flotando en un doc. Una decisión enlazada al código exacto que gobierna es memoria que puedes usar; la misma decisión en una wiki es una anécdota que nadie encuentra. Cuando la razón del cap de reintentos está sobre la lógica de reintentos, una persona o un agente que lee ese código la ve a tiempo.

Contexto completo: Memoria de producto: lo que tu equipo olvida y tu sistema no debería →

El comportamiento que el código impone (historias de usuario), las condiciones que comprueba (criterios de aceptación, más ricos cuando hay tests) y parte de las decisiones congeladas en la estructura. Lo que no se recupera del todo es la intención: por qué se eligió algo, qué se descartó, y qué hace el código por accidente en vez de a propósito.

Contexto completo: Leer un repo y sacar artefactos de producto: historias, criterios, decisiones →

Porque casi todo el software ya existe. El camino de ida (spec y luego construir) encaja en greenfield. El código heredado, los prototipos vibe-coded y los sistemas legacy no tienen spec, y la forma más rápida de tener un contrato contra el que construir es leer el que el código ya impone.

Contexto completo: Leer un repo y sacar artefactos de producto: historias, criterios, decisiones →

Solo si cada uno lleva su procedencia. Un comportamiento leído de un test que pasa es evidencia. Una decisión inferida del nombre de una carpeta es una conjetura. La extracción es peligrosa cuando blanquea conjeturas como documentación segura, así que los artefactos deben marcar qué está probado, qué está observado y qué está inferido, y mantenerlos separados.

Contexto completo: Leer un repo y sacar artefactos de producto: historias, criterios, decisiones →

El porqué sin documentar que vive en las cabezas: la razón de que un módulo esté estructurado raro, la mina que nadie toca, la restricción que es obvia para quien la construyó e invisible para el resto. Es conocimiento real sin representación externa, así que desaparece cuando desaparece la persona.

Contexto completo: El conocimiento tribal es un punto único de fallo →

Porque todo el sistema depende de que una cabeza esté disponible. Cuando esa persona está de vacaciones, se va o simplemente lo olvida, el conocimiento desaparece y el código se queda diciendo qué hace pero no por qué. No hay redundancia ni backup, que es la definición exacta de un punto único de fallo.

Contexto completo: El conocimiento tribal es un punto único de fallo →

Porque hacen onboarding desde cero cada sesión y no pueden absorber contexto de pasillo. Un junior humano va pillando las reglas no escritas a lo largo de meses. Un agente nunca. Ve el código, no el porqué detrás, así que cualquier conocimiento que solo vive en cabezas es permanentemente invisible para la parte del equipo que más crece.

Contexto completo: El conocimiento tribal es un punto único de fallo →

El RAG vectorial recupera por semejanza: embebe el código en vectores y devuelve los trozos más parecidos a una consulta. Un grafo de conocimiento recupera por relación: guarda aristas explícitas (llama-a, importa, depende-de, decidido-por) y responde recorriéndolas. Uno es bueno para recall difuso, el otro para preguntas estructurales de varios saltos.

Contexto completo: Grafo de conocimiento vs búsqueda vectorial para código: cuándo gana cada uno →

Cuando necesitas recall difuso sobre un codebase grande y desconocido y la pregunta es casi lenguaje natural: encuentra código que haga X, dónde hay algo de facturación, muéstrame handlers parecidos. Los vectores son baratos de montar, toleran entradas desordenadas y son fuertes cuando no sabes los nombres exactos que buscar.

Contexto completo: Grafo de conocimiento vs búsqueda vectorial para código: cuándo gana cada uno →

Cuando la respuesta depende de relaciones que el embedding tira: qué llama a esto, qué se rompe si lo cambio, por qué existe esto, traza esta decisión hasta el código que la implementa. Son preguntas exactas, de varios saltos y estructurales, y un grafo las responde recorriendo en vez de adivinar por parecido.

Contexto completo: Grafo de conocimiento vs búsqueda vectorial para código: cuándo gana cada uno →

Tratar la documentación como código fuente: vive en el repositorio, cambia mediante pull requests, se revisa junto al código que describe y pasa por CI. El objetivo es que los docs se muevan por la misma vía que el código, para que cambien juntos en vez de separarse.

Contexto completo: Docs-as-code en la era de los agentes →

Los docs dejan de ser solo output para humanos y se vuelven input para máquinas. Ficheros como AGENTS.md y CLAUDE.md los leen los agentes para decidir cómo construir. Eso da la vuelta a la prioridad: un doc obsoleto ya no solo confunde a un fichaje nuevo, dirige activamente al agente a construir lo que no es, así que mantenerlos verdaderos pasa a ser asunto del build.

Contexto completo: Docs-as-code en la era de los agentes →

Sí, cuando los agentes dependen de los docs. Si las instrucciones pueden separarse del código sin nada que lo detecte, se separarán, y un agente se fiará de la versión desviada. Generar los docs desde el código donde se pueda, y frenar el build cuando lo documentado y lo real no cuadran, es como mantienes el contrato veraz a velocidad de máquina.

Contexto completo: Docs-as-code en la era de los agentes →

Una fábrica local de software es un sistema que mantiene producto, código y evidencia conectados en tu propia máquina. Una idea se convierte en decisión, la decisión en especificación, la especificación en trabajo que un agente ejecuta, y el resultado vuelve con la prueba adjunta; todo en un sistema conectado en lugar de disperso entre un chat, un gestor y un repositorio. Local significa que el hilo de la intención a la prueba es tuyo, no alquilado.

Contexto completo: La fábrica local de software: producto, código y evidencia en tu máquina →

No, es lo contrario. Una feature factory se mide por output enviado y a eso lo llama producto. Una fábrica de software es un sitio con estaciones —descubrir, definir, planificar, construir, verificar, aprender— donde entra material, se trabaja en orden y sale probado. La gracia no es el volumen de features. Es que intención, código y evidencia sigan conectados para que el sistema no derive hacia incoherente mientras los agentes escriben.

Contexto completo: La fábrica local de software: producto, código y evidencia en tu máquina →

No. Local se refiere a dónde vive el estado de tu producto, no a dónde ocurre la inferencia. La fábrica está en tu máquina pero llama a los proveedores de IA que elijas, y la nube hace inferencia mejor de lo que la hará un portátil. Lo que se queda local es todo lo que define el producto: el contrato, el grafo, las decisiones y la prueba. Envías tokens fuera cuando tú decides, sin entregar la fábrica.

Contexto completo: La fábrica local de software: producto, código y evidencia en tu máquina →

Importa sobre todo a un fundador en solitario o un equipo pequeño que construye algo que pretende seguir entendiendo dentro de un año, porque poseer el hilo vale más que la configuración que ahorra una nube compartida. Los equipos grandes ganan cosas reales con la nube: estado compartido sin configuración, cómputo pesado como problema de otro, software que se actualiza solo. La elección depende de si poseer la memoria de tu producto pesa más que esa comodidad.

Contexto completo: La fábrica local de software: producto, código y evidencia en tu máquina →

El desarrollo con IA local-first mantiene el sistema que rodea a los modelos en tu máquina mientras los modelos siguen siendo remotos. La orquestación, el estado, la memoria entre sesiones, la verificación y la recuperación corren en tu Mac; la inferencia es una llamada que haces fuera y un resultado que traes de vuelta. El reparto es deliberado. La parte cara que mejora con la escala puede ser remota, y las partes que definen tu producto se quedan locales.

Contexto completo: Desarrollo con IA local-first: por qué la fábrica debe vivir en tu Mac →

La privacidad pasa a ser una propiedad de la arquitectura en lugar de una promesa. Tu estrategia, tus apuestas descartadas y tus criterios de aceptación viven en tu disco, así que en el lado del proveedor no hay nada que mirar. El límite real: cuando llamas a un modelo remoto, los tokens que envías van a ese proveedor bajo sus términos. Local-first convierte eso en una decisión por llamada, no en un valor por defecto donde todo tu espacio de trabajo se sincroniza a un servidor.

Contexto completo: Desarrollo con IA local-first: por qué la fábrica debe vivir en tu Mac →

No. Local-first no es maximalismo offline ni pretende que tu portátil haga la inferencia. Los modelos frontier corren en centros de datos por buenas razones. Lo que se queda local es el contrato, el grafo, las decisiones y la prueba: las partes que definen tu producto y que deberías poseer. Los modelos siguen siendo remotos, llamados con tus propias claves. Te niegas a alquilar las partes que deberías poseer, no la nube en sí.

Contexto completo: Desarrollo con IA local-first: por qué la fábrica debe vivir en tu Mac →

Suele ser más rápido donde importa la velocidad. El bucle agéntico lee estado, decide, actúa y actualiza cientos de veces al día. Cuando el estado es un archivo SQLite en tu disco, cada lectura va a velocidad de disco en vez de un viaje de red por los rate limits de otro. Lo único que esperas es el modelo, que ibas a esperar de todos modos. Todo lo demás es instantáneo porque todo lo demás es local.

Contexto completo: Desarrollo con IA local-first: por qué la fábrica debe vivir en tu Mac →

Ninguna gana del todo; es un intercambio, no un veredicto. La nube es mejor en estado compartido sin configuración, cómputo descargado, actualizarse sola y acceso desde cualquier sitio. Local es mejor en latencia en el bucle apretado, coste solo donde es real, privacidad por construcción y control que sobrevive al proveedor. La elección correcta depende de qué lado del intercambio contiene el dolor que de verdad te muerde.

Contexto completo: Herramientas de IA en la nube vs locales: qué cedes en cada dirección →

Cuatro cosas, y no son pequeñas. Un compañero abre una URL y ve exactamente lo que tú ves, sin instalar ni desajuste de versiones. El cómputo pesado pasa a ser problema de otro. La versión que ejecutas siempre es la actual. Y llegas al mismo entorno desde cualquier dispositivo o red. Si tu dolor central es coordinar a un equipo entre dispositivos con la mínima fricción, ahí vive tu respuesta.

Contexto completo: Herramientas de IA en la nube vs locales: qué cedes en cada dirección →

Puedes, pero es una migración, no un ajuste. Tu estado vive en su formato y en sus servidores, así que moverlo significa una exportación —si la ofrecen— y luego reconstruir las conexiones que su sistema sostenía por ti. El hilo entre intención y prueba suele ser lo primero que no sobrevive a la extracción: recuperas tus datos, no siempre tu sistema. Empezar local y añadir piezas de nube es la dirección reversible.

Contexto completo: Herramientas de IA en la nube vs locales: qué cedes en cada dirección →

Para un fundador en solitario o un grupo pequeño y cohesionado, local suele ser el caso más fuerte. La coordinación que la nube hace sin fricción es coordinación que apenas necesitas, mientras que las victorias de local —latencia a velocidad de disco, coste solo en inferencia, privacidad y control a prueba de proveedor— te golpean directo. La nube se gana su sitio en equipos grandes cuyo problema principal es el estado compartido. Elige por quién está en el espacio de trabajo y dónde golpea el dolor hoy.

Contexto completo: Herramientas de IA en la nube vs locales: qué cedes en cada dirección →

Depende de la arquitectura de la herramienta. Muchas sincronizan todo tu espacio de trabajo a sus servidores como precio de ser útiles. Una herramienta local-first mantiene tu código, tu grafo de producto, tus decisiones y tu evidencia en tu disco, y solo envía fuera el contexto concreto de una llamada concreta al modelo, cuando la haces. Por defecto todo se queda; enviar se vuelve la excepción acotada que tomas a propósito, no una sincronización general.

Contexto completo: Tu código no sale de casa: la privacidad como decisión de arquitectura →

Solo los tokens de esa llamada —el fragmento de código, el contexto y la instrucción que pasas— van al proveedor bajo sus términos. Eso es real y local-first no lo hace desaparecer. Lo que cambia es la forma: en vez de que todo tu espacio de trabajo viva en un servidor, sale el contexto de una llamada cuando tú eliges. Puedes mirar contexto sensible y enrutar esa tarea a un motor local para que no salga nada.

Contexto completo: Tu código no sale de casa: la privacidad como decisión de arquitectura →

Una política es una frase que promete que una empresa no hará mal uso de tus datos; cambia con una actualización de los términos que no vas a leer. La arquitectura es un arreglo donde no hay nada que malusar en su lado, porque los datos nunca fueron allí. La garantía es estructural: no depende de sus intenciones, su seguridad, su adquisición ni de un juez. Aguanta el peor día, no solo el día de marketing.

Contexto completo: Tu código no sale de casa: la privacidad como decisión de arquitectura →

No, y ese encuadre lo infravalora. El código es la capa menos sensible. La fábrica que lo rodea guarda la estrategia detrás de lo que construyes, las apuestas que mataste, las restricciones sensibles de seguridad, los criterios de aceptación de las partes sensibles y notas de discovery contadas en confianza. Eso es la forma del pensamiento de tu empresa, y es justo lo que entrega una herramienta que sincroniza el espacio de trabajo. "No entrenamos con tus datos" no cubre la mayor parte.

Contexto completo: Tu código no sale de casa: la privacidad como decisión de arquitectura →

Normalmente por el proveedor, no por ti. No necesitas una cuenta para ejecutar software en tu propia máquina. La cuenta crea un registro al que hacer marketing, un embudo que medir y optimizar, un coste de cambio porque tu trabajo pasa a vivir en su servidor, y el número de usuarios registrados contra el que se gestiona muchas veces el negocio. Nada de eso es malvado, pero el muro apunta hacia donde apuntan los incentivos.

Contexto completo: Herramientas sin cuenta: qué dice de un producto no pedirte registro →

Sí. Sin cuenta no significa sin captura de valor. Una herramienta puede cobrar por el producto directamente, cobrar por el uso más allá de un tramo gratis, o cobrar por funciones de equipo donde el servidor sí aporta valor. Lo que se niega a hacer es construir su negocio sobre cosechar y retener tu identidad. Pagas por el software en vez de ser la cosa que se monetiza: la versión que merece buscar.

Contexto completo: Herramientas sin cuenta: qué dice de un producto no pedirte registro →

Cosas reales, casi todas atadas a la nube. Sin cuenta suele significar sin sincronización automática en la nube, así que moverte entre dispositivos corre de tu cuenta. Significa sin backup del proveedor: si tu disco muere sin tu propia copia, no tienen ninguna que restaurar. Significa menos continuidad entre dispositivos, y algunas funciones colaborativas son más difíciles o inexistentes. Para un equipo que necesita colaboración fluida entre dispositivos, encaja peor. El intercambio compra propiedad, privacidad e incentivos alineados.

Contexto completo: Herramientas sin cuenta: qué dice de un producto no pedirte registro →

Mira dónde se sitúa el muro respecto al valor. Registrarte antes de que la herramienta haga nada útil es trabajo de captación, y tú eres la captación. Registrarte solo cuando topas con algo que de verdad necesita una identidad —compartir, sincronizar un segundo dispositivo— es trabajo de función, no captura. Después mira la salida: una herramienta segura de ser buena hace fácil marcharse; una que entierra la exportación convierte el coste de cambio en parte del plan.

Contexto completo: Herramientas sin cuenta: qué dice de un producto no pedirte registro →

Traer tu propio modelo significa que tú pones la clave API o apuntas la herramienta a un motor local, y la herramienta trata el modelo como una pieza intercambiable en vez de como su núcleo. Tienes tú la credencial; la herramienta es un cliente apuntando a ella. Suena a checkbox, pero es una decisión sobre cómo está construido el producto, y hay que tomarla antes de la primera línea de código, no atornillarla después.

Contexto completo: Trae tu propio modelo: claves API, motores locales y portabilidad →

Con una herramienta que trae tu propio modelo, sí, y la diferencia importa. Cuando la clave es tuya, la factura va a tu tarjeta bajo tus términos, los rate limits son los que contrataste y el acuerdo de datos es el que aceptaste. Moverte a otro proveedor pasa a ser una edición de ajustes a tu ritmo. Cuando la clave pasa por la herramienta, esperas a que soporte el proveedor que quieres, al precio que negoció.

Contexto completo: Trae tu propio modelo: claves API, motores locales y portabilidad →

Una herramienta pensada para traer tu propio modelo puede, a través de un motor como Ollama corriendo un modelo open source en tu máquina sin red. No es un plan B. Local es el único modo en el que puedes prometer, y cumplirlo, que no salió nada de casa: el requisito para código regulado, un contrato con un cliente sobre dónde vive la fuente, o un prototipo que no estás listo para exponer. Una buena fábrica trata el motor local como ciudadano de primera junto a las APIs frontier.

Contexto completo: Trae tu propio modelo: claves API, motores locales y portabilidad →

Nada, si el trabajo vive fuera del modelo. El contrato de producto, las especificaciones, las decisiones, el grafo del código y la evidencia deben estar en almacenamiento local que puedes inspeccionar, no dentro de una conversación con un solo motor. Entonces cambias de modelo y la memoria sobrevive: las decisiones de ayer siguen aplicando, las specs siguen en pie, el motor nuevo lee el mismo contexto duradero. Si ese sentido vive dentro de un modelo, cambiarlo tira el trabajo a la basura y la portabilidad es mentira.

Contexto completo: Trae tu propio modelo: claves API, motores locales y portabilidad →

Mueve la decisión de la factura del mes a la tarea concreta. Primero consigue visibilidad a nivel de tarea: qué costó un run en tokens, qué motor usó, cuánto fueron reintentos. Después ponle un tope con un presupuesto por tarea y enruta el trabajo barato a motores baratos por defecto. El coste deja de ser una sorpresa a final de mes y pasa a ser una propiedad de cómo se despacha cada tarea, con el número delante mientras todavía puedes actuar.

Contexto completo: Controlar el coste de la IA cuando cada tarea quema tokens →

Normalmente no es la tarea que estabas mirando. Los agentes se pasan en la que se torció: se atascó, se reintentó en bucle y corrió un modelo frontier en círculos sin un techo contra el que chocar. El resto se esconde en costes que olvidas contar: reintentos, deriva que hay que rehacer, bucles de verificación y contexto reenviado en cada turno porque la herramienta no tiene memoria. Nada aparece como "desperdicio"; parece uso normal.

Contexto completo: Controlar el coste de la IA cuando cada tarea quema tokens →

Define unos pocos tramos —cheap, balanced, strong, frontier— en vez de poner precio a cada tarea a mano. Cada tarea hereda un techo y un motor razonables de su tramo, así que la decisión manual ocurre una vez, en el tramo. Cuando un run revienta su tope, se para y te avisa, en vez de gastarte el mes en silencio. El presupuesto es tanto una alarma que saca a la superficie un run confundido como una cartera.

Contexto completo: Controlar el coste de la IA cuando cada tarea quema tokens →

Sí; es la fuente de desperdicio más grande y más aburrida. Un retoque de copy, un rename, un comentario o un refactor pequeño que los tests ya cubren no necesitan tu motor más fuerte. Deja que el perfil de la tarea decida qué motor la recoge, para que el trabajo barato aterrice en motores baratos por defecto. El trabajo rutinario que puede correr en un modelo local open source a través de Ollama cuesta solo electricidad, que suele ser la respuesta correcta.

Contexto completo: Controlar el coste de la IA cuando cada tarea quema tokens →

Sí, y el viejo techo casi ha desaparecido: los agentes escriben el código rápido, así que construir ya no es lo que te limita. Lo que lo sustituye es más difícil de ver. Una persona sostiene ahora cada rol que un equipo reparte —producto, ingeniería, revisión, memoria, recuperación, la puerta de calidad— porque los agentes multiplican tu output sin dividir tus roles. Puedes producir como un equipo, pero sigues decidiendo como un individuo.

Contexto completo: Una fábrica de una sola persona: software serio como fundador en solitario →

La atención, no el throughput. Ocho agentes generan más código en una tarde del que una persona puede leer con cuidado en un día, y el output sin revisar es riesgo con un buen mensaje de commit, no progreso. El muro es la coherencia: pérdida de contexto entre sesiones, deriva entre ramas paralelas y fatiga de revisión, donde el décimo diff recibe menos escrutinio que el primero. El juicio no se paraleliza, y hay una cantidad finita al día.

Contexto completo: Una fábrica de una sola persona: software serio como fundador en solitario →

Una fábrica de una persona es alguien que opera como un equipo corriendo varias sesiones de agentes a la vez, cada una en su rama, mientras sostiene solo el calendario, las decisiones y la puerta de calidad. Funciona cuando la memoria de coordinación —el contrato de producto, las decisiones, el grafo del código y la evidencia— vive fuera de tu cabeza en un sistema conectado. Si no, te conviertes en el punto único de fallo de tu propia empresa, con una cabeza cansada como CPU.

Contexto completo: Una fábrica de una sola persona: software serio como fundador en solitario →

Sustituyen el throughput, no el juicio. Los agentes no pueden decidir qué merece construirse, si lo que volvió es bueno, o cuándo tirar una semana porque la idea de debajo estaba mal. Eso se queda contigo. Lo que de verdad necesita un fundador en solitario no es más agentes sino un sitio donde viva la memoria de un equipo, para que el trabajo paralelo no dependa de que estés despierto y te acuerdes de todo.

Contexto completo: Una fábrica de una sola persona: software serio como fundador en solitario →

Para una herramienta que sostiene tu código y corre todo el día, lo nativo se reduce a tres cosas: integración, rendimiento y confianza. Usa las protecciones de verdad de la máquina —Keychain para los secretos, el modelo de permisos del sistema—, corre sobre Apple Silicon en vez de arrastrar un motor de navegador empaquetado, y puede verificarse antes de arrancar. Una app web disfrazada de escritorio reinventa cada una de esas, normalmente peor.

Contexto completo: Por qué lo nativo en macOS sigue importando en herramientas de desarrollo →

Firmada significa que la app carga una identidad de desarrollador verificada, así que sabes quién la construyó. Notarizada significa que Apple la revisó en busca de malware y el sistema puede confirmar que no se ha alterado desde entonces. Grapa la notarización a la app y tu máquina verifica la cadena entera antes del primer arranque, sin conexión. Para software al que estás a punto de darle tu código fuente, esa procedencia es una decisión de confianza que puedes razonar en vez de tomar por fe.

Contexto completo: Por qué lo nativo en macOS sigue importando en herramientas de desarrollo →

En una demo rápida no lo notas. A lo largo de un día entero, un motor de navegador empaquetado carga el peso de una pila de renderizado que no necesitaba, en un runtime pensado para mostrar documentos. En la cuarta hora, con varias sesiones corriendo, el impuesto aparece en los ventiladores, la batería y el pequeño lag de cada acción. Una carcasa más pesada deja menos margen, así que los builds compiten con el marco en vez de con el trabajo.

Contexto completo: Por qué lo nativo en macOS sigue importando en herramientas de desarrollo →

Es una decisión de confianza distinta. Cuando el trabajo real pasa en un servicio en otro sitio, lo que confías es una conexión y una política de privacidad, no un artefacto que el sistema pueda verificar. Una app nativa que tu máquina ha firmado, notarizado y comprobado es demostrable antes de correr. Para la mayoría del software el modelo web vale; para la herramienta que apuntas a código privado, la procedencia verificable no es un formalismo, es el producto.

Contexto completo: Por qué lo nativo en macOS sigue importando en herramientas de desarrollo →

Es un enfoque donde contexto, intención y evidencia son artefactos de primer nivel junto al código. El objetivo no es generar más, sino conservar un contrato que personas y agentes puedan ejecutar y verificar.

Contexto completo: Framework de desarrollo AI-First: contexto, ejecución y evidencia →

Una herramienta acelera una sesión de implementación. Un framework organiza el ciclo completo: cómo se decide, qué contexto recibe el agente, cómo se valida la salida y cómo vuelve el aprendizaje al producto.

Contexto completo: Framework de desarrollo AI-First: contexto, ejecución y evidencia →

Un contrato pequeño y comprobable, reglas del repositorio, una forma de entregar contexto por tarea y evidencia reproducible al terminar. La complejidad adicional solo se justifica cuando esas piezas básicas ya funcionan.

Contexto completo: Framework de desarrollo AI-First: contexto, ejecución y evidencia →

La IA genera código que funciona y pasa los tests, pero rara vez deja registrado por qué se tomó una decisión. Meses después, cambiar ese código obliga a reconstruir una intención que nunca se capturó: las restricciones, las alternativas descartadas, la razón de negocio. El código no es de baja calidad; lo que falta es el contexto a su alrededor. Ese hueco, no la IA, es lo que convierte una función rápida en un laberinto que nadie quiere tocar.

Contexto completo: Principios para un desarrollo con IA mantenible →

Este artículo plantea cinco: el contexto como creación primaria y no como subproducto; una arquitectura guiada por la intención, organizada en torno al propósito y no solo a la función; el conocimiento como entidad viva que evoluciona con el sistema; la colaboración humano-IA como una asociación real; y una arquitectura de decisiones que registra por qué se eligió algo, no solo qué se decidió. Juntos invierten el viejo orden donde el código era primario y el contexto secundario.

Contexto completo: Principios para un desarrollo con IA mantenible →

Necesita algo mejor que la documentación tradicional: contexto ligado al código y mantenido vivo a medida que el código cambia. Los documentos estáticos en un wiki aparte se pudren y se ignoran. Lo que importa es capturar el razonamiento detrás de las decisiones generadas por IA — requisitos, trade-offs, caminos descartados — cerca del código, para que la siguiente persona, o la siguiente sesión de IA, actúe sobre la intención en lugar de adivinarla.

Contexto completo: Principios para un desarrollo con IA mantenible →

Porque la velocidad va por delante y el coste se aplaza. La IA produce código que funciona muy rápido, pero a menudo sin contexto capturado y con fallos sutiles: patrones inseguros, dependencias ocultas, incluso instrucciones disfrazadas en los comentarios. Los equipos adoptan las herramientas sin adaptar sus procesos de revisión y seguridad, así que la deuda y las vulnerabilidades se acumulan en silencio. El esfuerzo ahorrado hoy vuelve después como depuración, retrabajo e incidentes de seguridad.

Contexto completo: Por qué el código generado con IA se vuelve difícil de mantener →

No por defecto. Los asistentes reproducen patrones del código público, incluidos los obsoletos o inseguros, y pueden ser manipulados por entradas maliciosas ocultas en el texto que procesan. Además difuminan la línea entre datos y comandos. El código generado por IA puede hacerse seguro, pero solo con la misma disciplina de ingeniería que aplicas en el resto: revisión humana de la salida, escaneo automatizado y tratar los prompts como instrucciones ejecutables.

Contexto completo: Por qué el código generado con IA se vuelve difícil de mantener →

Revisa la salida de la IA con el mismo cuidado que cualquier contribución externa, automatiza el análisis de seguridad en el pipeline, comprueba las instrucciones ofuscadas en código y configuración y aporta al modelo solo el contexto estructurado que necesita para la tarea.

Contexto completo: Por qué el código generado con IA se vuelve difícil de mantener →

La IA acelera claramente la generación de código, pero generar es la parte fácil. La productividad real es el coste total a lo largo de la vida de un sistema: lo rápido y seguro que un equipo puede entender, cambiar y ampliar el código después. Cuando la IA produce rápido código pobre en contexto, esa velocidad inicial suele anularse con más depuración, más retrabajo y mayor carga cognitiva. Teclear más rápido no es productividad sostenible.

Contexto completo: Cuando programar más rápido con IA no mejora la entrega →

Porque ves aparecer la salida en segundos y casi nunca ves el coste aplazado. La IA genera código localmente correcto y de aspecto elegante sin el contexto específico de tu proyecto: el porqué, la arquitectura, la historia, las dependencias. Quien lo modifique después tiene que reconstruir ese contexto desde cero. La victoria visible es la generación; el impuesto invisible llega meses más tarde, cuando ese código «rápido» se vuelve lento de tocar.

Contexto completo: Cuando programar más rápido con IA no mejora la entrega →

No por líneas de código, que premian el volumen sobre el valor. Mira el flujo y la estabilidad: lead time, frecuencia de despliegue, tasa de fallo de cambios, tiempo de recuperación. Sigue señales de fricción como el churn de código, la tasa de retrabajo y cuánto tarda el código generado por IA en depurarse o revisarse. Y pregúntate cuánto tarda un desarrollador nuevo en contribuir con seguridad. Eso revela si la IA aporta valor o deuda oculta.

Contexto completo: Cuando programar más rápido con IA no mejora la entrega →

Porque los equipos tratan los sistemas de IA como software tradicional e improvisan el diseño. La IA trae retos que la arquitectura corriente ignora: no determinismo, degradación del contexto, deriva de datos. Un prototipo prometedor se convierte en una maraña de deuda técnica que nadie entiende. El fallo suele ser estructural, no mala suerte: el sistema no tenía una arquitectura pensada para el desorden específico de la IA, así que no sobrevivió a la demo.

Contexto completo: Patrones de arquitectura para sistemas con IA →

Esta guía cubre cinco patrones probados: el monolito consciente del contexto, que lo mantiene dentro de la aplicación para proyectos simples; el pipeline de contexto desacoplado para escalar su gestión; el bucle de retroalimentación agéntico, donde las salidas y el feedback mejoran el comportamiento futuro; los sistemas estratificados, que apilan lógica especializada sobre modelos fundacionales; y la orquestación con humano en el bucle para decisiones críticas. La mayoría de sistemas reales combinan varios al crecer.

Contexto completo: Patrones de arquitectura para sistemas con IA →

Parte de la escala, complejidad y riesgo de tu proyecto, no del patrón más sofisticado. Un MVP acotado quizá solo necesite el contexto dentro de la aplicación; un sistema que sirve muchos modelos necesita un pipeline de contexto dedicado; los dominios críticos necesitan puntos explícitos de revisión humana. Lo constante en todos es que la estructura deliberada, y no el diseño improvisado, es lo que mantiene vivo un sistema de IA más allá del lanzamiento.

Contexto completo: Patrones de arquitectura para sistemas con IA →

Con capas de comprobaciones complementarias, no confiando en un solo escaneo. El análisis estático (SAST) detecta patrones inseguros mientras se escribe el código; el análisis de composición (SCA) mapea el árbol profundo de dependencias que arrastra el código de IA; y las pruebas al estilo DAST sondean el servicio en ejecución y sus APIs. Incrustar todo esto como puertas automáticas a lo largo del pipeline, no como una casilla final, es lo que evita que el código generado publique fallos ocultos.

Contexto completo: Asegura tu código de IA con Snyk: una guía práctica →

Porque no se diseñaron para cómo funciona el desarrollo con IA. Muchos escáneres básicos no tienen el análisis de flujo de datos para rastrear entradas no confiables hasta sumideros peligrosos como la deserialización con pickle, no parsean bien los notebooks de Jupyter donde se esconden secretos en las celdas de salida, no entienden semánticamente las librerías de IA, y solo miran las dependencias directas ignorando el árbol transitivo profundo. El resultado son falsas alarmas y, peor, riesgos reales que se escapan.

Contexto completo: Asegura tu código de IA con Snyk: una guía práctica →

Tres capas complementarias de seguridad de aplicaciones. SAST (análisis estático) inspecciona el código fuente antes de ejecutarlo, detectando patrones inseguros y secretos incrustados. DAST (pruebas dinámicas) ataca la aplicación en ejecución desde fuera para encontrar fallos en APIs, autenticación y manejo de entradas. SCA (análisis de composición) examina las dependencias open source, directas y transitivas, en busca de vulnerabilidades conocidas y problemas de licencia. Juntas cubren código, ejecución y cadena de suministro.

Contexto completo: Asegura tu código de IA con Snyk: una guía práctica →

PaellaDoc es un framework para preservar el contexto a lo largo de todo el ciclo de desarrollo, nacido de un dolor concreto: código generado por IA que se vuelve ilegible para su propio autor meses después. En lugar de documentación separada del trabajo, captura el razonamiento, los requisitos y las decisiones detrás del código y los mantiene conectados a él, para que el «porqué» sobreviva mucho después de que la IA produjera el «qué».

Contexto completo: PaellaDoc y el contexto en el desarrollo con IA →

Es la brecha que abre la IA entre lo rápido que se escribe el código y lo rápido que desaparece su contexto. El código fluye deprisa, pero el razonamiento detrás — las decisiones, las restricciones, la intención — rara vez se captura. Meses después, ese contexto perdido hace que tu propio código te resulte ajeno, ralentiza el onboarding y las decisiones pasadas se vuelven a discutir. La crisis no es la calidad del código; es el conocimiento perdido.

Contexto completo: PaellaDoc y el contexto en el desarrollo con IA →

Porque la generación es instantánea y capturar el contexto no lo es. Cuando un asistente escribe una función en minutos, los prompts, los trade-offs y las opciones descartadas detrás suelen quedar sin registrar. La documentación tradicional vive en herramientas aparte y se pudre. Sin anclar deliberadamente el razonamiento al código, cada cambio futuro obliga a alguien a reconstruir la intención desde cero, que es justo donde el ahorro de tiempo se esfuma en silencio.

Contexto completo: PaellaDoc y el contexto en el desarrollo con IA →