Vibe coding vs ingeniería asistida por IA: la línea que importa
Mismas herramientas, mismos modelos, misma velocidad. La línea entre las dos no es el código que generas. Es si lo aceptas sin verificarlo.
~/blog · index
La fábrica
piensa en público.
Decisiones de producto, supuestos que se rompen, código y pruebas desde una fábrica de software que trabaja contra repositorios reales. Escrito desde València con el trabajo todavía caliente.
intencióncódigoevidencia
Recién salido de la fábrica
Últimas notas de campo.
Decisiones, fallos y evidencia, por fecha de publicación.
El ajuste de cuentas del día 90: por qué las apps vibe-coded se rompen al tercer mes
El patrón llega casi con calendario. Va de maravilla durante semanas y, hacia el tercer mes, la misma app que parecía magia se vuelve imposible de cambiar.
De vibe coding a producción: el puente que nadie explica
Describiste una app y la obtuviste. Ahora la usa gente real y tienes que mantenerla viva. Este es el cruce de prototipo a producto, etapa a etapa.
Verificar código generado por IA: evidencia, no sensaciones
Un agente que dice «hecho, los tests pasan» hace una afirmación, no enseña una prueba. Todo el trabajo consiste ahora en convertir esa afirmación en evidencia que puedas comprobar.
Trae tu propio modelo: claves API, motores locales y portabilidad
El modelo sobre el que construyes va a cambiar bajo tus pies. Traer tu propio modelo es lo que convierte eso de una caída en una edición de config.
Empieza aquí
Las rutas esenciales.
Rutas duraderas por el archivo si acabas de llegar.
la guía generalConstruir software con agentes de IA: la guía operativaConstruir software con agentes de IA es hoy el trabajo de alrededor del código: definir, especificar, ejecutar, verificar y aprender como un solo sistema../leer →Desarrollo guiado por especificaciones¿Qué es el desarrollo guiado por especificaciones?./leer →De vibe coding a productoDe vibe coding a producción: el puente que nadie explica./leer →Operar agentes de códigoNo tienes un problema con Claude Code. El runtime eres tú../leer →Verificación y evidenciaVerificar código generado por IA: evidencia, no sensaciones./leer →Product management en la era IAProduct management en la era de la IA: construir es barato, decidir es caro./leer →Grafos de conocimiento de productoGrafos de conocimiento del código: qué son y por qué los agentes los necesitan./leer →La fábrica local de softwareLa fábrica local de software: producto, código y evidencia en tu máquina./leer →Desarrollo AI-firstFramework de desarrollo AI-First: contexto, ejecución y evidencia./leer →
Biblioteca completa
Explora por problema.
Busca en todas las notas o recorre el mapa de temas. Cada enlace sigue visible para lectores y buscadores.
Desarrollo guiado por especificaciones
Revisar la spec antes de que el agente construya: la review más barata
Revisar la spec antes de construir atrapa los errores caros antes de que el agente escriba una línea. Es la review más...
./leer →Spec-driven vs test-driven: ¿rivales o capas?
Spec-driven vs test-driven no es una rivalidad. Los tests verifican el comportamiento, las specs fijan la intención, y los agentes necesitan las...
./leer →La spec es el contrato: qué significa en la práctica
La spec como contrato no significa nada sin respuestas: quién la firma, quién puede romperla y cómo se detecta la ruptura antes...
./leer →Añadir specs a un repo existente sin parar el mundo
Cómo añadir specs a un repo existente de forma incremental, sin reescritura ni congelación, para dar a los agentes un contrato contra...
./leer →Más allá de Spec Kit: lo que el spec-driven necesita después de escribir la spec
Las alternativas a Spec Kit no dan en el clavo. El hueco real es lo que pasa después de la spec: mantenerla...
./leer →Criterios de aceptación que un agente puede verificar
Los criterios de aceptación para agentes de IA deben ser verificables mecánicamente, no prosa ambigua. Cómo escribir criterios que un agente comprueba.
./leer →Spec vs PRD: para qué sirve cada uno (y qué necesitan los agentes)
Spec vs PRD: para qué sirve cada documento, en qué se diferencian y qué necesita exactamente un agente de IA de cada...
./leer →Spec-driven sin burocracia: un flujo ligero
La sobrecarga del spec-driven development es una queja real. Un flujo ligero que conserva el contrato y recorta la ceremonia, con una...
./leer →Especificaciones vivas: specs que se actualizan con el código
Las especificaciones vivas se actualizan junto al código en vez de pudrirse en una carpeta. En qué se diferencian de las estáticas...
./leer →Spec drift: cuando la especificación y el código dejan de contar lo mismo
El spec drift es la distancia entre lo que dice tu especificación y lo que hace el código. Por qué los agentes...
./leer →Las especificaciones de software deberían ser portables
Las especificaciones de software portables conectan agentes y herramientas con código, decisiones y verificación sin perder contexto.
./leer →Desarrollo guiado por especificaciones: un build en verde no es una feature correcta
Un build en verde no demuestra que la feature sea correcta. Qué añade el desarrollo guiado por especificaciones a la verificación.
./leer →De vibe coding a producto
Vibe coding vs ingeniería asistida por IA: la línea que importa
Vibe coding vs ingeniería asistida por IA: la línea no son las herramientas ni la velocidad, sino si aceptas el código generado...
./leer →Miedo a tocarlo: convertir el pánico a tu propio código en una red de seguridad
¿Miedo a cambiar tu propio código de IA? El miedo es una señal. Conviértelo en red de seguridad con tests de caracterización,...
./leer →Cuándo añadir tests y arquitectura a un proyecto construido con IA
Cuándo añadir tests y arquitectura a un proyecto construido con IA: la señal que te dice que un camino sostiene peso, y...
./leer →Tu prototipo ya es el producto: sobrevivir al ascenso
Tu prototipo de Lovable o Cursor se convirtió en el producto sin avisar. Cómo sobrevivir al ascenso a producción sin tirar el...
./leer →Los agujeros de seguridad que deja el vibe coding
Los riesgos de seguridad del vibe coding: secretos expuestos, validación de entrada ausente y dependencias sin auditar. De dónde salen y cómo...
./leer →La deuda del vibe coding: qué debes exactamente y cuándo vence
La deuda técnica del vibe coding en tres capas: comprensión, tests y arquitectura. Qué cuesta cada una y cuándo llega de verdad...
./leer →Cada feature nueva rompe una vieja: el contrato que falta
Por qué cada feature nueva rompe una vieja en apps hechas con IA: el contrato que falta entre features, y cómo instalarlo...
./leer →Cimientos bajo el castillo de naipes: arreglar una app vibe-coded sin reescribirla
Arreglar una app vibe-coded sin reescribirla: specs retroactivas, tests de caracterización y límites que refuerzan la app en su sitio.
./leer →Has publicado código que no sabes leer. ¿Y ahora qué?
Publicaste código generado por IA que no sabes leer. Una forma práctica de recuperar el control de tu app sin leer cada...
./leer →El ajuste de cuentas del día 90: por qué las apps vibe-coded se rompen al tercer mes
Por qué las apps vibe-coded se rompen hacia el mes 3: el patrón del ajuste de cuentas, por qué llega con calendario...
./leer →Qué es el vibe coding (y dónde deja de funcionar)
Qué es el vibe coding: definición clara del término que acuñó Karpathy, para qué sirve de verdad y el punto exacto donde...
./leer →Le pedí la misma app a la Codex app dos veces. Ninguna llegó al día siguiente.
Le pedí a la app de Codex construir la misma app dos veces. Ninguna llegó al día siguiente. Lo que eso dice...
./leer →Operar agentes de código
La compactación se come tus decisiones: gestionar la ventana de contexto
Gestión de la ventana de contexto y compactación: por qué los runs largos olvidan las decisiones que los hacían correctos y cómo...
./leer →Handoffs: pasar trabajo entre agentes sin perder el hilo
Traspaso de trabajo entre agentes: qué tiene que viajar cuando el trabajo pasa entre agentes para que el siguiente continúe en vez...
./leer →Harness engineering: la disciplina que está naciendo alrededor de operar agentes
Harness engineering: la disciplina de construir el bucle alrededor de un agente de código (contexto, verificación, recuperación), no un modelo mayor.
./leer →La ejecución murió a las 2 de la mañana: la recuperación como flujo de primera
Recuperar una ejecución fallida de agente: por qué la recuperación debe ser un flujo de primera con checkpoints y estado resumible, no...
./leer →Tu fichero de reglas miente a tus agentes: mantener las instrucciones vivas
Mantener CLAUDE.md y AGENTS.md actualizados: cómo detectar instrucciones obsoletas que tus agentes siguen obedeciendo y mantener vivas tus reglas.
./leer →AGENTS.md, CLAUDE.md, reglas de Cursor: dónde deberían vivir tus decisiones
AGENTS.md vs CLAUDE.md vs reglas de Cursor: para qué sirve cada fichero y dónde deberían vivir de verdad tus decisiones de producto.
./leer →Ocho sesiones a la vez: worktrees, paralelismo y el coste de ser el scheduler
Las sesiones paralelas de Claude Code en worktrees multiplican el throughput y te convierten en el scheduler. Aquí el montaje y el...
./leer →Los agentes van a derivar: diseñar para la divergencia en vez de rezar
Los agentes de IA derivan de la intención por defecto. Diseña para la divergencia con reconciliación y puertas en vez de rezar...
./leer →Orquestar varios agentes sin que se contaminen entre sí
Orquestar varios agentes de código funciona con aislamiento, contratos compartidos y reconciliación, para que el trabajo en paralelo no choque en silencio.
./leer →Memoria para agentes de código: qué debe persistir fuera del chat
La memoria para agentes de código es decidir qué persiste fuera del chat: decisiones, invariantes y estado, cada uno en una forma...
./leer →Pérdida de contexto entre sesiones: el asesino de productividad sin presupuesto
Cuando un agente pierde contexto entre sesiones, re-explicas decisiones que ya existen. Esto es lo que se pierde y dónde debería vivir...
./leer →Context engineering para agentes de código: cuándo ayuda y cuándo estorba
Context engineering para agentes de código: qué va en la ventana, qué persiste fuera y cómo dejar de re-explicar tu repo.
./leer →Los agentes de largo recorrido necesitan un runtime, no un modelo más grande
Los agentes no necesitan un modelo más grande sino un runtime: planificación, memoria, recuperación y verificación alrededor del trabajo.
./leer →Sin vendor lock-in: cada tarea a su motor
De elegir un modelo a gobernar una flota de motores. PaellaDoc enruta cada tarea al agente y perfil adecuados, determinista por defecto,...
./leer →Verificación y evidencia
Una definición de «hecho» que sobrevive a la velocidad de la IA
Una definición de «hecho» para desarrollo con IA: por qué la palabra del agente no vale nada y cómo definir «hecho» como...
./leer →Revisar código que no escribiste: primero el alcance, el diff al final
Revisar código que no escribiste, a escala de agente: por qué el alcance va antes que el diff y un orden de...
./leer →La brecha de confianza: por qué el output dejó de ser el cuello de botella
La brecha de confianza en el código de IA: por qué el output ya no es el cuello de botella y cómo...
./leer →Bucles de verificación: hooks, puertas y el fin del éxito auto-declarado
Bucles de verificación para agentes: cómo los hooks, las puertas y un ciclo de fallo-arreglo sustituyen el éxito auto-declarado por evidencia real.
./leer →Probar código generado por IA: qué cambia y qué no
Probar código generado por IA: qué cambia cuando la intención no está en la cabeza de nadie, qué no cambia en los...
./leer →Desarrollo basado en evidencia: cerrar trabajo con la prueba adjunta
El desarrollo basado en evidencia cierra cada tarea con la prueba adjunta: qué se ejecutó, qué pasó, contra qué contrato, guardado donde...
./leer →De producir a asegurar: el nuevo cuello de botella del software
El aseguramiento de software es el nuevo cuello de botella: los agentes abarataron producir código, no saber que es correcto y coherente.
./leer →Fatiga de review: cuando el código llega más rápido de lo que puedes leerlo
La fatiga de revisión de código IA es un desajuste de caudal, no un defecto. Revisa en los momentos que importan: alcance,...
./leer →«Los tests pasan»: anatomía de un éxito falso
Por qué un agente de IA dice que los tests pasan cuando no ejecutó nada: el mecanismo detrás de un éxito falso,...
./leer →Hecho significa hecho: obligar al agente a demostrarlo
Hecho significa hecho: cómo obligar al agente a demostrar la compleción con evidencia en vez de una frase segura, y qué cuenta...
./leer →Localmente correcto, globalmente incoherente: el problema del código generado por IA
La IA escribe código localmente correcto y globalmente incoherente no por tonta, sino porque nadie gestiona su contexto. La coherencia es del...
./leer →Product management en la era IA
Un modelo operativo para equipos de producto que construyen con agentes
Los roles, artefactos y cadencia de un equipo de producto que construye con agentes. En qué se convierte cada uno cuando construir...
./leer →Research de usuarios con IA sin blanquear la evidencia
Usa la IA para sintetizar research real, no para reemplazar usuarios reales. Mantén cada afirmación trazable a una frase cruda, no blanquees...
./leer →El puente PM–ingeniería: un solo sistema del discovery al código mergeado
PMs e ingenieros viven en mundos separados. El puente es un solo sistema donde discovery, decisiones, specs y código mergeado comparten identidad...
./leer →Decisiones de producto con la evidencia adjunta
El equivalente de producto del «hecho significa hecho»: una decisión no se cierra hasta adjuntar la evidencia que la justificó y nombrar...
./leer →Insight → decisión → resultado: la cadena que la velocidad de la IA rompe
Cómo mantener trazable la cadena insight → decisión → resultado cuando la velocidad de la IA colapsa el medio y te deja...
./leer →Slop de IA con buen formato: el modo de fallo del producto asistido por IA
Slop de IA en producto: más PRDs, tickets y decks sin mejores decisiones. El modo de fallo del producto asistido por IA...
./leer →Prueba la asunción más arriesgada antes de que los agentes lo construyan todo
Prueba primero la asunción más arriesgada: construir barato cambió la economía de los experimentos y por qué nombrar la apuesta va antes...
./leer →Discovery con IA: socia para pensar, no para decidir
Discovery de producto con IA: úsala como socia para pensar, no para decidir, y haz discovery sin blanquear hipótesis convirtiéndolas en evidencia.
./leer →El prototipo como spec: imposible de malinterpretar
El prototipo como especificación: un prototipo funcionando es una spec imposible de malinterpretar. Qué fija y los límites de dónde funciona.
./leer →Escribes PRDs que nadie lee. El problema es el artefacto.
Los PRDs que nadie lee no son un problema de disciplina. El documento muerto es el problema. Lo sustituye una decisión viva...
./leer →Decision logs: el fin del «yo nunca acordé eso»
Un registro de decisiones de producto acaba con el «yo nunca acordé eso»: qué registrar, dónde vive y quién lo consulta de...
./leer →Hacer producto no es productizar: cómo salir de la feature factory
Hacer producto es instalar un comportamiento en el usuario, no correr una fábrica de features. La diferencia decide qué construyes.
./leer →¿Qué es una feature factory?
Qué es una feature factory, cómo reconocer que trabajas en una y qué cambia cuando el producto se mide por comportamiento.
./leer →Grafos de conocimiento de producto
Docs-as-code en la era de los agentes
Docs-as-code con IA: trata el pipeline de docs como parte del build para que tus agentes lean instrucciones que siguen siendo verdad.
./leer →Grafo de conocimiento vs búsqueda vectorial para código: cuándo gana cada uno
Grafo de conocimiento vs RAG vectorial para código: en qué es bueno cada uno, dónde se rompe y cuándo usar cuál. Sin...
./leer →El conocimiento tribal es un punto único de fallo
El conocimiento tribal en equipos es un punto único de fallo. Qué se rompe cuando se va quien sabe el porqué, y...
./leer →Leer un repo y sacar artefactos de producto: historias, criterios, decisiones
Extraer artefactos de producto de un repo existente: historias, criterios de aceptación y decisiones. El camino inverso, y el que de verdad...
./leer →Memoria de producto: lo que tu equipo olvida y tu sistema no debería
La memoria de producto son las decisiones, razones y callejones sin salida que tu equipo olvida. Por qué tu sistema debería guardarlos,...
./leer →Documentación viva: docs que dejan de pudrirse
La documentación viva sigue siendo verdad porque se deriva del código, no se mantiene como copia aparte. Por qué se pudren los...
./leer →Onboarding contra el grafo, no contra el conocimiento tribal
Onboardear contra el conocimiento tribal no escala ni para personas ni para agentes. Onboardea contra un grafo del código que el sistema...
./leer →Mapas del código, no prompts más largos
Los agentes fallan en código que no conocen por falta de mapa, no porque el prompt sea corto. Qué contiene un mapa...
./leer →Grafo de conocimiento de producto: lee la forma de tu producto, no la lista de features del repo
Un grafo de conocimiento de producto lee la forma de tu producto, no la lista de features del repo. Por qué lo...
./leer →El cerebro de producto que se mantiene solo
Un cerebro de producto hecho de notas envejece en cuanto tu equipo shipea. La salida es un grafo que ata el código...
./leer →La fábrica local de software
Por qué lo nativo en macOS sigue importando en herramientas de desarrollo
Por qué lo nativo en macOS sigue importando: integración con el sistema, rendimiento en Apple Silicon y la confianza de firma y...
./leer →Una fábrica de una sola persona: software serio como fundador en solitario
Sacar software serio como fundador en solitario con agentes de IA. Cómo una persona opera como un equipo, y dónde está el...
./leer →Controlar el coste de la IA cuando cada tarea quema tokens
Controla el coste de la IA cuando cada tarea quema tokens: presupuesto por tarea, routing por coste y visibilidad del gasto antes...
./leer →Trae tu propio modelo: claves API, motores locales y portabilidad
Trae tu propio modelo con tus claves API y motores locales. Por qué la portabilidad del modelo es una decisión de arquitectura,...
./leer →Herramientas sin cuenta: qué dice de un producto no pedirte registro
Las herramientas sin cuenta revelan los incentivos de un producto. Por qué saltarse el registro se alinea con el usuario, qué señala...
./leer →Tu código no sale de casa: la privacidad como decisión de arquitectura
Mantener tu código y tus datos en local hace de la privacidad una propiedad de arquitectura, no una promesa. Qué sale, qué...
./leer →Herramientas de IA en la nube vs locales: qué cedes en cada dirección
Nube vs local en herramientas de IA es un intercambio, no un veredicto: qué hace mejor cada lado y cómo elegir por...
./leer →Desarrollo con IA local-first: por qué la fábrica debe vivir en tu Mac
El desarrollo con IA local-first mantiene el harness, el estado y la evidencia en tu Mac mientras llama a modelos remotos: latencia,...
./leer →Desarrollo AI-first
Patrones de arquitectura para sistemas con IA
Patrones de arquitectura para sistemas con IA y las restricciones que determinan cuándo conviene usar cada uno.
./leer →Asegura tu código de IA con Snyk: una guía práctica
Guía práctica para asegurar código generado por IA con Snyk: escaneo, dependencias y lo que el modelo no pensó.
./leer →Cuando programar más rápido con IA no mejora la entrega
Programar con IA parece más rápido de lo que es. De dónde sale la ilusión de productividad y cómo lograr mejoras que...
./leer →Por qué el código generado con IA se vuelve difícil de mantener
Por qué el código generado con IA se vuelve difícil de mantener y qué prácticas de revisión, seguridad y contexto reducen ese...
./leer →Principios para un desarrollo con IA mantenible
Los principios del desarrollo AI-first, y por qué la velocidad sin estructura convierte los proyectos de IA en código inmantenible.
./leer →PaellaDoc y el contexto en el desarrollo con IA
Cómo plantea PaellaDoc el desarrollo AI-first: estructura, contexto y documentación para que el software hecho con IA sobreviva a la realidad.
./leer →Ninguna nota coincide con esa búsqueda.
— Fin del log · 94 entradas · siguen cocinándose —