Índice de capítulos
Cómo se ve un capítulo
Capítulo de referencia visual. Demuestra el render de markdown (encabezados, listas, código, tablas, citas). Útil para validar que el lector se ve bien antes de publicar un texto.
Detección de cambios en Angular: de Default a Signals
Tu app se vuelve lenta sin un motivo obvio y casi siempre el detector está revisando lo que no toca. Marco práctico para pasar de Default a OnPush a Signals — sin convertirlo en religión.
Pull requests que no necesitan defensa
Si tu PR llega ya explicado, la review pasa de auto-defensa a conversación útil. Cómo se redacta uno que se sostiene solo.
Cuando el LLM te miente con confianza
Alucinaciones plausibles, APIs inventadas, citas inexistentes. Por qué la confianza del modelo no se correlaciona con tener razón.
Cuándo decir no a un workflow nuevo
La presión por adoptar herramientas IA es real. Marco para decir que no sin sonar conservador — ni adoptar por sonar moderno.
Cómo NO usar un LLM para arquitectura
Lo que un modelo te puede ayudar a pensar y lo que tienes que pensar tú. Con ejemplos concretos de cuándo nos hemos equivocado.
Cuándo dejar la deuda y cuándo pagarla
Hay refactors que valen la pena y refactors que destruyen una sprint entera. La diferencia no está en el código — está en el contexto.
Microservicios: la pregunta antes que la respuesta
Antes de partir el monolito, una lista de preguntas honestas. Si ninguna se contesta con "sí, hoy", quizás no es el momento.
La IA acelera. No decide.
El capítulo que da nombre al pilar 03. Por qué la responsabilidad técnica no se delega, aunque el LLM proponga la solución entera.
Estimar sin engañarse (ni a otros)
Las estimaciones no fallan por falta de técnica. Fallan por falta de honestidad sobre lo que no sabemos todavía. Marco práctico.
Tests que valen la pena (y los que no)
No todos los tests son valor neto. Algunos protegen de cambios reales; otros se rompen cada vez que tocas el orden de los argumentos.
Decisiones reversibles y decisiones que no lo son
No todas las decisiones cuestan lo mismo. Distinguir las puertas-de-una-vía de las puertas-de-dos-vías cambia cómo invertir tiempo.
Las palabras que evitamos
"10x", "productividad mágica", "AI-first", "vibe coding". Por qué este sitio no las usa y qué palabras pone en su lugar.
Code review con criterio, no con ego
Las reviews que más rinden no son las que encuentran más bugs — son las que enseñan sin humillar y dejan el repo más legible.
Leer código que no escribiste
Sin esta habilidad, la IA acelera tu equivocación. Cómo abordar un repo nuevo sin perder media semana ni adoptar suposiciones ajenas.
Prompts que no son recetas
Coleccionar prompts es coleccionar muletas. Cómo entender el porqué de un prompt para poder escribir los tuyos cuando cambie el modelo.
Por qué empezar por aquí
El principio rector en una página: el criterio técnico no se delega. La IA acelera, no decide. Lo demás se desprende de eso.
Criterio profesional, en una frase
Si tuviera que reducir todo PulpoCode a una sola frase, sería ésta. Pero hace falta el resto del capítulo para entender por qué.
ADRs que sirven al de dentro de 6 meses
Un ADR no es documentación de proceso. Es una carta al tú del futuro explicándole qué intentabas resolver. Plantilla mínima.
1:1s que no son status
Si tu 1:1 podía ser un Slack, lo hiciste mal. Cómo dejar de gastar 30 minutos semanales repitiendo lo que ya está en el board.
Naming y honestidad
Los nombres que mienten te cuestan más caro que la deuda técnica. Un repaso a los anti-patrones de naming que vemos repetirse.
Auto-completado vs autoría
Aceptar una sugerencia no es lo mismo que escribirla. Y el código que firmas como autor sigue siendo tuyo, lo sugiera quien lo sugiera.
Métricas de productividad con IA: lo medible y lo no medible
Versión inicial reemplazada por una más honesta. Se conserva por trazabilidad — la conclusión a la que llegamos se mantiene.
Cómo se ve un capítulo
Capítulo de referencia visual. Demuestra el render de markdown (encabezados, listas, código, tablas, citas). Útil para validar que el lector se ve bien antes de publicar un texto.
Detección de cambios en Angular: de Default a Signals
Tu app se vuelve lenta sin un motivo obvio y casi siempre el detector está revisando lo que no toca. Marco práctico para pasar de Default a OnPush a Signals — sin convertirlo en religión.
Pull requests que no necesitan defensa
Si tu PR llega ya explicado, la review pasa de auto-defensa a conversación útil. Cómo se redacta uno que se sostiene solo.
Cuando el LLM te miente con confianza
Alucinaciones plausibles, APIs inventadas, citas inexistentes. Por qué la confianza del modelo no se correlaciona con tener razón.
Cuándo decir no a un workflow nuevo
La presión por adoptar herramientas IA es real. Marco para decir que no sin sonar conservador — ni adoptar por sonar moderno.
Cómo NO usar un LLM para arquitectura
Lo que un modelo te puede ayudar a pensar y lo que tienes que pensar tú. Con ejemplos concretos de cuándo nos hemos equivocado.
Cuándo dejar la deuda y cuándo pagarla
Hay refactors que valen la pena y refactors que destruyen una sprint entera. La diferencia no está en el código — está en el contexto.
Microservicios: la pregunta antes que la respuesta
Antes de partir el monolito, una lista de preguntas honestas. Si ninguna se contesta con "sí, hoy", quizás no es el momento.
La IA acelera. No decide.
El capítulo que da nombre al pilar 03. Por qué la responsabilidad técnica no se delega, aunque el LLM proponga la solución entera.
Estimar sin engañarse (ni a otros)
Las estimaciones no fallan por falta de técnica. Fallan por falta de honestidad sobre lo que no sabemos todavía. Marco práctico.
Tests que valen la pena (y los que no)
No todos los tests son valor neto. Algunos protegen de cambios reales; otros se rompen cada vez que tocas el orden de los argumentos.
Decisiones reversibles y decisiones que no lo son
No todas las decisiones cuestan lo mismo. Distinguir las puertas-de-una-vía de las puertas-de-dos-vías cambia cómo invertir tiempo.
Las palabras que evitamos
"10x", "productividad mágica", "AI-first", "vibe coding". Por qué este sitio no las usa y qué palabras pone en su lugar.
Code review con criterio, no con ego
Las reviews que más rinden no son las que encuentran más bugs — son las que enseñan sin humillar y dejan el repo más legible.
Leer código que no escribiste
Sin esta habilidad, la IA acelera tu equivocación. Cómo abordar un repo nuevo sin perder media semana ni adoptar suposiciones ajenas.
Prompts que no son recetas
Coleccionar prompts es coleccionar muletas. Cómo entender el porqué de un prompt para poder escribir los tuyos cuando cambie el modelo.
Por qué empezar por aquí
El principio rector en una página: el criterio técnico no se delega. La IA acelera, no decide. Lo demás se desprende de eso.
Criterio profesional, en una frase
Si tuviera que reducir todo PulpoCode a una sola frase, sería ésta. Pero hace falta el resto del capítulo para entender por qué.
ADRs que sirven al de dentro de 6 meses
Un ADR no es documentación de proceso. Es una carta al tú del futuro explicándole qué intentabas resolver. Plantilla mínima.
1:1s que no son status
Si tu 1:1 podía ser un Slack, lo hiciste mal. Cómo dejar de gastar 30 minutos semanales repitiendo lo que ya está en el board.
Naming y honestidad
Los nombres que mienten te cuestan más caro que la deuda técnica. Un repaso a los anti-patrones de naming que vemos repetirse.
Auto-completado vs autoría
Aceptar una sugerencia no es lo mismo que escribirla. Y el código que firmas como autor sigue siendo tuyo, lo sugiera quien lo sugiera.
Métricas de productividad con IA: lo medible y lo no medible
Versión inicial reemplazada por una más honesta. Se conserva por trazabilidad — la conclusión a la que llegamos se mantiene.
Nada que coincida hoy.
La biblioteca aún es chica. Prueba a quitar algún filtro.