Base de Conocimiento de Yeda AI

¿Qué es realmente la IA?

La IA en lenguaje sencillo — cómo el aprendizaje automático da vuelta la programación tradicional, por qué nadie programa 'gato' y dónde ya usas IA todos los días.

Tu IA tiene perillas de creatividad: temperature, top-k y top-p

Cómo funcionan realmente el muestreo por temperature, top-k y top-p, cuándo girar cada perilla y qué las reemplazó en los modelos más nuevos.

El system prompt son las notas del director

Por qué el system prompt es el “código” de mayor apalancamiento en cualquier función con IA — persona, reglas, formato — más el truco de caché que hace que un prompt congelado sea ~90% más barato.

Tu IA es lo que come: por qué la calidad de los datos le gana al tamaño

La IA aprende como un niño pequeño: el bucle de entrenamiento y 70 mil millones de perillas

Cómo los chatbots aprenden modales: fine-tuning en tres pasos

La cebolla de la IA: IA vs. machine learning vs. deep learning vs. IA generativa

Los ADR son combustible para agentes de IA

Los Architecture Decision Records le dan a los asistentes de código con IA lo único que tu código no puede: por qué elegiste lo que elegiste. Formato, flujo de trabajo y beneficio.

El detector de alucinaciones de la IA en 5 segundos

El código generado por IA puede llamar a APIs que nunca existieron. Un verificador de tipos en modo de solo comprobación lo detecta en segundos — tsc --noEmit para TypeScript, pyright para Python.

Ejecuta dos agentes de IA a la vez con git worktrees

Dos agentes de IA en una misma carpeta se sobrescriben los archivos. Los git worktrees le dan a cada agente su propio directorio y su propia rama sobre el mismo repositorio — aquí está la configuración.

Revisa primero los tests y divide los diffs grandes

Lee los tests antes que la implementación para entender la intención primero — y mantén los diffs cerca de 100 líneas, dividiendo lo que se acerque a 1,000 por apilado, grupo de archivos o corte vertical.

¿Refactor grande? Escribe un codemod, no ediciones a mano

Cuando un refactor toca cientos de líneas, deja de editar a mano: escribe un codemod, un script sed o una transformación de AST para que una sola regla se aplique en todas partes y el diff siga siendo revisable.

Ese código feo sostiene la estructura

La cerca de Chesterton para refactorizar con IA: ejecuta git blame y responde 3 preguntas antes de dejar que un agente borre código que no entiende.

Los retornos tempranos matan el anidamiento; las constantes con nombre matan los números mágicos

Dos refactorizaciones de treinta segundos que hacen legible el código generado por IA: convierte los ifs anidados en cláusulas de guarda y extrae los números sin explicación a constantes con nombre.

Nunca conviertas una variable de entorno a bool con un cast

bool(\“false\”) es True — un cast directo invierte tu kill switch en silencio. Parsea los booleanos con un vocabulario compartido de true/false para env vars y config.

Un valor de configuración malformado debe registrarse y usar el valor por defecto

Pasa cada ajuste por un único lector tipado que registra el valor inválido y degrada a un valor por defecto documentado — para que un typo sea una línea de log, no una caída.

Result y Wait son deadlocks en espera

Por qué bloquear con .Result o .Wait produce deadlocks en apps web C# bajo carga — y cómo ir async hasta el fondo, con cancellation tokens donde importan.

Tu sitio grita hecho por IA: tres señales que puedes buscar con grep

El look de 'AI slop' se detecta con grep: gradientes morados, todo centrado y un único radio de 16px+ — tres comandos lo encuentran, tres arreglos lo rompen.

outline: none sin un estilo de foco de reemplazo

Una línea de CSS deja fuera a los usuarios de teclado — cómo :focus-visible les devuelve el anillo de foco sin ensuciar la UI del mouse.

El estado del servidor va en una capa de caché, no en el estado global

Los datos que pertenecen al backend no van en tu store global: ponlos en una capa de caché de datos y obtén caching, deduplicación e invalidación gratis.

Las UIs generadas por IA se saltan los estados vacíos — pide cada estado en el prompt

La IA construye el camino feliz de tu UI; tus usuarios viven en el camino triste. Checklist para pedir estados de carga, vacío, error y desborde — siempre.

Nunca lances una goroutine sin dueño

Las goroutines no se recolectan como basura: cada `go` en código Go generado por IA necesita una ruta de cancelación, un dueño del canal y un WaitGroup, o se fuga hasta tumbar el servicio.

Usa ?? para valores por defecto, no ||

Por qué `config.port || 3000` descarta en silencio 0, cadena vacía y false — y cómo el operador nullish coalescing (`??`) solo aplica el fallback con null/undefined.

forEach no espera nada

Por qué un callback async dentro de forEach se adelanta en silencio — y cómo elegir deliberadamente entre for...of + await y Promise.all.

Rechaza el doble bang en Kotlin generado

Por qué cada !! en Kotlin generado por IA es un crash diferido, y cómo los nullables explícitos y los resultados sealed hacen imposible omitir el caso vacío.

Prohíbe GlobalScope.launch en los code reviews

Las corrutinas sin scope filtran trabajo y se tragan la cancelación — convierte GlobalScope.launch en un rechazo automático de review y ata cada corrutina a un dueño.

Ese inocente chequeo de `if exists` es una condición de carrera

Por qué el patrón chequear-y-actuar sobre el filesystem es una carrera TOCTOU, y cómo un solo parámetro — exist_ok=True — elimina el bug y una línea de código a la vez.

sum() transmite en flujo perezoso, sum([]) construye primero

Quita los corchetes dentro de sum() y un pico de memoria de un millón de elementos se convierte en un flujo perezoso — mismo resultado, un carácter menos.

¿Dos ifs en una comprensión? Dale un nombre de función

Cuando a una list comprehension le crece una segunda condición, expándela en una función generadora con nombre: legible, testeable y un patrón que tu agente de código va a copiar.

Los threads no arreglan tu Python limitado por CPU

Threads o asyncio para trabajo limitado por I/O, ProcessPoolExecutor para trabajo limitado por CPU: la decisión de una línea que los asistentes de IA fallan, y cómo saber qué límite estás enfrentando.

String += en un loop es O(n²), usa join

Por qué += sobre strings dentro de un loop es cuadrático, y las dos soluciones lineales: ''.join() sobre una lista de partes, o io.StringIO para construcción incremental.

Encadena siempre las excepciones con 'from e'

Relanzar una excepción envuelta sin 'from e' entierra el traceback original — dos palabras mantienen la traza apuntando a la causa real.

Protocol en vez de herencia: costuras de prueba estructurales en Python

Usa typing.Protocol para reemplazar dependencias reales por fakes de prueba sin acoplamiento a clases base — tipado estructural que el checker sigue verificando.

Rechaza los callbacks de Rails generados por IA que hacen trabajo lento

Los asistentes de IA adoran los after_save que llaman APIs — una regla de revisión mantiene los saves rápidos, los tests sin red y el trabajo lento reintentándose en jobs.

Impón la unicidad en la base de datos, no solo en el modelo

validates_uniqueness_of de Rails es propenso a condiciones de carrera bajo carga concurrente: úsalo para errores amigables, pero agrega un índice único en la base de datos para tener la garantía.

Todo bloque unsafe necesita un comentario de seguridad

Un bloque unsafe suspende las verificaciones del compilador — escribe un comentario // SAFETY que declare el invariante que sostiene, y deja que revisores y agentes de IA verifiquen en vez de adivinar.

Nunca Construyas Comandos de Shell Como Cadenas

Una sola variable sin comillas puede borrar el directorio equivocado. Usa arreglos de Bash para las listas de argumentos, pon comillas en cada expansión y arranca los scripts con set -euo pipefail.

Cambia la paginación por offset por la paginación por keyset

En una tabla grande y cambiante, LIMIT/OFFSET salta y repite filas en silencio — la paginación por keyset avanza usando la clave de la última fila y se mantiene consistente aunque la tabla mute debajo de ti.

Audita el Swift generado por IA en busca de Task.detached

¿Ves Task.detached en Swift generado por IA? Detente y revísalo — una tarea detached descarta silenciosamente la cancelación, la prioridad y el aislamiento de actor, y casi siempre es la opción equivocada.

Ponle fecha de vencimiento a cada supresión: ts-expect-error en vez de ts-ignore

@ts-ignore calla para siempre; @ts-expect-error da error apenas se corrige el bug de fondo, así las supresiones de tipos no se pudren en tu código.

Comenta el porqué, nunca el qué

Borra los comentarios que repiten tu código y conserva el único tipo que nunca se pudre: los comentarios de porqué, que registran la intención para humanos y asistentes de IA.

Nunca dejes código comentado

Borra el código muerto en vez de comentarlo: git recuerda cada línea, y tu asistente de IA razona mejor sobre archivos sin cementerios.

Mantén un archivo de reglas para tu agente

Documenta tus convenciones una sola vez en un archivo de reglas — CLAUDE.md, AGENTS.md, .cursor/rules — y cada sesión de IA las sigue sin que tengas que reescribir nada.

Documenta las trampas inline, donde muerden

El bug que te costó un día merece un comentario justo donde la próxima persona va a caer — no en una wiki que nadie abre.

La documentación ahora es contexto ejecutable

Nadie leía tu documentación — hasta que tu agente de código empezó a leer cada palabra. Por qué los registros de decisiones son el contexto de mayor impacto que puedes escribir, y cómo mantener uno en 10 minutos.

La sección de alternativas del ADR es oro

Registra las opciones que rechazaste — pros, contras y una línea sobre por qué perdió cada una — para que tu agente de código con IA deje de proponer ideas que ya descartaste.

Incorpora la IA a un código nuevo como a un humano

Dale a tu agente de código el mismo onboarding que a un nuevo integrante — un orden fijo de reconocimiento en cinco pasos más un request rastreado — para que su código respete tus convenciones.

Rastrea una petición real de punta a punta

La forma más rápida de entender cualquier codebase: sigue una petición real desde el punto de entrada hasta la base de datos y de vuelta — y luego entrégale ese mapa a tu agente de IA.

Registra el dialecto local para que el código de IA se integre

Una checklist de 3 puntos — nombres, patrones, reglas de la casa — para que el código generado por IA coincida con tu codebase y no con un default genérico.

La regla SMIG: Situación, Mecanismo, Implicación, Gotcha

Una regla de cuatro partes para docs de onboarding y code tours: omite lo que el código ya muestra, invierte tus palabras en implicaciones y gotchas.

No vuelques el árbol de archivos y lo llames onboarding

Un listado de carpetas le dice a tu agente de código qué existe, no sobre qué actuar — reemplaza el volcado crudo con cinco movimientos narrados que trazan el camino real por el sistema.

Archivos .tour: recorridos de código por persona

Convierte el onboarding en una ruta guiada: los archivos .tour anclan recorridos paso a paso a archivos y líneas reales, un tour por persona, reproducidos dentro del editor.

Verifica cada afirmación contra el código

Los README se desactualizan; el código no. Cómo hacer onboarding a cualquier repo trazando una request real de punta a punta y verificando cada afirmación contra el código fuente.

Ejecuta tu suite de pruebas nativas bajo sanitizers

Por qué ASan, UBSan y TSan atrapan los bugs de C/C++ que un reporte verde de cobertura de líneas deja pasar — y cómo integrarlos a las pruebas que ya tienes.

Atrapa cada crash antes de arreglarlo

Escribe el test de regresión que falla antes del arreglo, córrelo bajo un sanitizer, y el bug no puede volver en silencio.

No confíes en los tests con base de datos en memoria

Los fakes de base de datos en memoria se saltan la traducción a SQL: la consulta que pasa en tests puede romperse en producción. Cuándo y cómo probar contra el motor real.

Verifica los cuatro estados de tu UI

La mayoría de los tests de widgets solo verifican el render feliz: aquí te mostramos cómo probar loading, vacío, error y éxito, con los patrones de mocking que hacen alcanzable cada estado.

Nunca uses waitForTimeout — espera la red real

Las esperas fijas hacen que los tests E2E sean lentos Y frágiles a la vez — reemplaza cada una por una espera sobre la condición real: una respuesta de red o una aserción con reintentos automáticos.

Haz que un test inestable falle diez veces a propósito

Reproduce un test inestable en tu máquina con --repeat-each=10 (y sus equivalentes en pytest y Go) en vez de quemar una semana de reintentos en CI.

Inyecta relojes, semillas aleatorias y directorios temporales

Los tests inestables casi siempre leen una entrada oculta: el reloj real, un RNG compartido o un directorio temporal común. Inyecta los tres y las mismas entradas darán el mismo resultado en cada ejecución.

Pruebas por capas, no un arranque completo

Por qué @SpringBootTest debería ser la excepción y no el default — usa slices como @WebMvcTest y @DataJpaTest para feedback más rápido, y enséñale el mismo hábito a tu asistente de IA.

Mezcla el orden de tu suite de tests para exponer tests dependientes del orden

Ejecuta tu suite en orden aleatorio para detectar bugs de estado compartido en tu máquina — con los flags exactos de shuffle y seed para Vitest, Jest, pytest, Go y RSpec.

Un test que pasa contra código vacío no prueba nada

Si tu suite sigue en verde después de borrar el código de producción, no verifica nada. La auditoría de cinco minutos, los placeholders sospechosos y las herramientas que automatizan el chequeo.

Nunca lances corrutinas reales en los tests

Por qué los dispatchers reales hacen que los tests asíncronos fallen de forma intermitente en CI, y cómo los TestDispatchers inyectados, el tiempo virtual y los tests del ciclo de vida completo de Flow los vuelven deterministas.

Un Fixture, Tres Bases de Datos

Parametriza un solo fixture de pytest con SQLite, PostgreSQL y MySQL y cada test que lo usa corre una vez por backend — 3x de cobertura con un decorador.

Etiqueta los tests lentos y recupera tu ciclo de trabajo

Usa markers de pytest para separar los tests de integración lentos de los tests unitarios rápidos: cada guardado corre en menos de un segundo y CI corre todo.

Siempre haz mock con autospec=True

Un Mock plano acepta métodos que no existen — parchea con autospec=True para que tus tests fallen cuando el código generado por IA usa mal una API real.

Mocks asíncronos: verifica el await, no la llamada

assert_called_once pasa aunque tu código haya olvidado el await — assert_awaited_once es la aserción que de verdad atrapa el bug.

Nunca desactives los warnings en Pytest

Los deprecation warnings son señales tempranas de falla: por qué silenciar los warnings de pytest cambia una corrida ruidosa hoy por una caída en producción mañana, y cómo filtrar con precisión.

pytest --lf: vuelve a ejecutar solo lo que falló

Reduce tu ciclo de depuración de minutos a segundos con pytest --lf, -x, --ff y --sw — y por qué importa aún más cuando un agente de IA está depurando.

100% de cobertura de tests es una señal de alerta, no una medalla

Por qué perseguir 100% de cobertura en toda la suite desperdicia esfuerzo — apunta a ~80% global y lleva auth, pagos y mutación de datos hacia 100% de cobertura de ramas.

Prueba tus trabajos en segundo plano: idempotencia y reintentos

Las colas entregan al-menos-una-vez, así que todo trabajo terminará ejecutándose dos veces — aquí te mostramos cómo probar que una ejecución duplicada cobre una sola vez, envíe un solo correo y se recupere limpiamente tras un fallo.

Los tests inestables se deben al tiempo, al IO o a la aleatoriedad

Un test que pasa a veces casi siempre toca tiempo real, archivos reales o aleatoriedad real — inyecta los tres y la inestabilidad desaparece.

Haz tus docs ejecutables: doc tests

Compila los ejemplos de tu documentación como parte de la suite de tests — doc tests de Rust, doctest de Python y patrones de pytest que hacen que la documentación obsoleta rompa el CI.

Pasa tus scripts de shell por ShellCheck primero

Analiza el bash generado por IA con ShellCheck antes de probarlo: la mayoría de los bugs de shell son problemas estáticos de comillas y portabilidad que un linter detecta en segundos.

Prueba tus scripts de shell desde una ruta con espacios

Ejecuta tus scripts de shell desde un directorio temporal cuya ruta contiene un espacio: los bugs de comillas y de directorio actual fallan a lo grande, gratis, antes de fallar en producción.

Prueba los invariantes de datos en la capa de la base de datos

La validación en la app no basta: prueba llaves únicas, llaves foráneas y check constraints en una base de datos real y desechable, igual a producción.

Simula la red, la persistencia, los relojes — y el estado de permisos

Ya simulas la red y la base de datos en tus tests — inyecta también un fake para el estado de permisos, y la rama de denegado dejará de llegar rota a producción.

Prueba el bug antes de arreglarlo

Haz que tu agente de código con IA escriba un test que falle y reproduzca el bug antes de tocar el arreglo: prueba de que existe, prueba de que se fue, y una guardia permanente.

Que un subagente aparte escriba el test de reproducción

Separa el test de reproducción del fix: un subagente nuevo escribe el test que falla sin ver el arreglo, para que los puntos ciegos compartidos no aprueben un parche roto.

El mock tautológico

Cuando un mock devuelve exactamente el valor que el test afirma, el test pasa sin ejecutar ni una línea de código de producción — cómo detectar mocks tautológicos y reemplazarlos con implementaciones reales o fakes en memoria.

Mantén tus tests DAMP, no DRY

Por qué la duplicación está bien en los tests: DAMP (Descriptive And Meaningful Phrases) le gana a DRY cuando un test que falla tiene que explicarse solo.

Haz que el agente descubra los comandos propios del proyecto

Evita que tu agente de IA adivine pytest o npm test: haz que lea package.json, pyproject.toml, el Makefile y el CI para encontrar los comandos canónicos del repo.

Nunca confíes en tests escritos por IA para validar código escrito por IA

Cuando un mismo modelo escribe el código y sus tests, ambos pueden compartir la misma suposición errónea: una suite en verde prueba consistencia, no corrección. Así se rompe el ciclo.

Un puntero crudo con ownership en C++ bloquea el code review

Por qué un puntero crudo con ownership debe reprobar el code review en C++, y la checklist RAII (unique_ptr, shared_ptr, span, regla de cero) para aplicarla al código generado por IA.

Verifica context.mounted después de cada await

Por qué las apps Flutter se caen después de llamadas asíncronas lentas — y la guarda de una línea con context.mounted que elimina el use-after-dispose.

Un modelo escribe, un modelo distinto revisa

Por qué el modelo que escribió tu código no puede revisarlo con confianza — y cómo un ciclo de dos modelos (escribir/revisar) con decisión humana final atrapa muchos más bugs.

Java Optional es solo un tipo de retorno

Optional fue diseñado para un solo trabajo: tipos de retorno de métodos. Por qué los campos, los parámetros y el .get() sin verificar pelean contra el diseño, y qué patrones usar en su lugar.

Planifica antes de escribir el prompt: revisa el plan antes de que tu agente de IA toque el código

Pon tu agente de programación en modo plan antes de que edite un solo archivo. Una tecla te da un plan revisable y editable en lugar de un diff sorpresa.

Mantén tu archivo de reglas liviano

Tu CLAUDE.md se carga en cada solicitud — un archivo de reglas inflado desperdicia contexto y diluye las instrucciones. Esto es lo que sí va ahí y lo que no.

Dale su propio agente al trabajo pesado: subagentes para aislar el contexto

Cómo los subagentes de Claude Code aíslan el contexto — delega la investigación ruidosa a un agente auxiliar con su propia ventana para que solo el resumen llegue a tu hilo principal.

Haz que pregunte primero: el prompt de confianza del 95%

Corta los ciclos de revisión antes de que empiecen: dile a Claude Code que haga preguntas de aclaración hasta estar 95% seguro, y luego pídele que nombre lo que te falta.

Mantén tu contexto fresco: cómo combatir la degradación del contexto en Claude Code

Las sesiones largas de Claude Code pierden calidad sin que te des cuenta — la degradación del contexto. Aprende cuándo usar /clear, cuándo usar /compact con notas de conservación y cómo vigilar el porcentaje de tu contexto.

El orden de seis partes en un prompt que evita que la IA adivine

Un prompt largo y desordenado falla por la misma razón que falla una agenda de reunión desordenada — el arreglo es el orden, no la extensión. La estructura de cinco partes que lo logra al primer intento.

Trata a la IA como a un nuevo empleado — mejores prompts con un solo cambio de mentalidad

Un prompt de una línea te da una respuesta genérica por la misma razón que un encargo de una línea a un nuevo empleado. La mentalidad de “primero el contexto” que arregla ambos.

Deja de describir el resultado — muéstrale ejemplos

Describir con palabras el formato que quieres es más lento y menos confiable que mostrarle al modelo dos o tres ejemplos — el truco del few-shot prompting, explicado.

Elige el nivel del modelo según el alcance de la tarea

Clasifica cada tarea de trivial a épica antes de elegir modelo — niveles rápidos para arreglos de una línea, niveles de razonamiento profundo para arquitectura — y deja de pagar precios de modelo insignia por corregir typos.

Termina cada prompt con una sección de \“NO hagas\”

Por qué una sección de 3 líneas de \“No hagas\” al final del prompt evita que los agentes de IA construyan de más — y qué límites poner y dónde.

Escribe primero la especificación

Una especificación corta — qué, por qué, restricciones, tareas — evita que tu agente de código adivine los detalles que no mencionaste.

Ajusta El Esfuerzo Al Tamaño De La Tarea

¿Ejecutas varias sesiones de agente a la vez? Ajusta el esfuerzo de razonamiento de cada una según su tarea para que las preguntas rápidas no esperen detrás de las profundas.

Bash o MCP

No conectes un servidor MCP para herramientas que tu agente ya puede alcanzar con bash. Una regla de decisión para saber cuándo un servidor realmente vale la pena.

Ordena las etapas de CI de la más barata a la más costosa

Deja de esperar diez minutos para atrapar un typo — ordena tu CI para que los chequeos más baratos y con más chance de fallar corran primero y fallen rápido.

Nunca conviertas un test intermitente en una compuerta obligatoria

Un test que pasa al reintentar es un defecto, no un tropiezo — ponlo en cuarentena para que la compuerta obligatoria siga significando algo y tu equipo nunca aprenda a solo darle a reintentar.

Planea el funeral antes de construir

Cuando diseñes algo nuevo, pregunta cómo lo borrarías en tres años — la respuesta te obliga a interfaces limpias, flags y una superficie pequeña que sigue siendo barata de eliminar.

La Ley de Hyrum: con suficientes usuarios, hasta los bugs generan dependencia

Con suficientes usuarios, cada comportamiento observable de tu sistema se vuelve una API de la que alguien depende — por eso una deprecación es una migración que ejecutas, no un memo que envías.

Pregunta qué NO tocó tu agente

Haz que cada cambio del agente termine con un resumen de Cambios / No toqué / Dudas, para que el scope creep salga a la luz antes de que lo encuentre tu revisor.

Detén a tu agente cada 100 líneas para probar

Nunca dejes que un agente de código escriba más de ~100 líneas antes de probar — las rebanadas verticales delgadas mantienen los errores pequeños, locales y baratos de corregir.

Dile a tu agente que anote, no que arregle, los problemas fuera de alcance

Una sola regla en CLAUDE.md evita que un agente de código infle tu pull request — cuando detecta un problema no relacionado, lo anota en lugar de arreglarlo.

Haz que tu primera tarea sea una bala trazadora

Tu primera tarea debe ser una bala trazadora: el corte más delgado a través de todas las capas que prueba el camino antes de construir a lo ancho.

Si el Título de una Tarea Contiene “y”, Divídela

La palabra “y” en el título de una tarea suele esconder dos tareas. Divide hasta que cada una quepa en ~5 archivos, ≤3 criterios de aceptación y una sesión enfocada del agente.

El bug de un PR generado por IA vive en quienes lo llaman

El bug de un PR generado por IA casi nunca está en el diff — está en los llamadores que el diff nunca te muestra. Revisa el radio de impacto, no solo las líneas que cambiaron.

Lee las pruebas antes que el código

En un pull request, lee primero las pruebas y después el código: las pruebas codifican la intención del autor, y una ruta riesgosa sin prueba es en sí misma un hallazgo.

Haz que tu IA liste sus supuestos antes de escribir código

Una sola instrucción — 'lista cada supuesto y espera mi corrección' — atrapa el malentendido cuando todavía cuesta una frase arreglarlo, en vez de una tarde de retrabajo.

Un rollback sin probar no es un rollback

Un plan de rollback que nunca ejecutaste es una esperanza, no un plan. Comprueba que el kill switch apaga la función en segundos, antes del lanzamiento y no durante el incidente.

Agrega una línea a cada prompt de investigación con IA

Hazle una pregunta amplia a una IA y te devuelve lo que ya creías. Una sola línea que exija evidencia contraria y escenarios negativos convierte el sesgo de confirmación en un informe de decisión real.

Cuando la estructura no llega, sáltate el esquema

Forzar un esquema antes de tener la columna vertebral de un texto arma un esqueleto al que escribes, y se nota. Vuelca cada fragmento en un archivo y deja que la estructura emerja párrafo a párrafo.

Prohíbele a la IA simular especificidad

La jugada más letal del cold email con IA es fingir especificidad. Prohíbele al modelo inventar anclas y exige una observación real y verificable por correo, o marca el borrador como no listo.

Obliga a las decisiones ambiguas a un informe estricto de 3 líneas

Ante una decisión ambigua, una IA devuelve tres párrafos evasivos que terminan en 'depende'. Obliga un informe de decisión de tres líneas — ELI10, Riesgos, Recomendación — para que deba comprometerse con una.

Haz concretos los riesgos: radio de impacto, reversibilidad, costo de tiempo

'Podría causar problemas' no es una evaluación de riesgo. Cuando un agente plantea una decisión, oblígalo a nombrar el radio de impacto, si es reversible y el costo de tiempo de equivocarse.

Nunca le pases tu conclusión a un agente revisor

Si le pasas tu conclusión a un revisor de IA, valida tu conclusión. Dale solo el artefacto y el contrato, pídele que encuentre qué está mal, y sacará a la luz los problemas que tú no podías ver.

Limita la revisión adversarial a tres ciclos

La autorrevisión adversarial detecta puntos ciegos, pero repetirla sin fin solo se estanca en los mismos hallazgos. Limítala a tres ciclos; si sobreviven problemas reales, eso es información sobre el artefacto, no razón para repetir.

Bloquea la primera edición de tu IA

Los agentes editan archivos que nunca leyeron de verdad. Bloquea la primera mutación hasta que el agente liste los importadores, nombre las funciones públicas afectadas y muestre las formas de datos reales. Sin hechos, no hay edición.

Haz que tu IA cite tu instrucción textualmente

Los agentes reinterpretan tu pedido en silencio y construyen una versión pulida de algo que nunca pediste. Una línea — cita mi instrucción palabra por palabra antes de tocar código — revela la desviación al instante.

Deja que Claude escriba tus skills

Deja de escribir a mano archivos SKILL.md. El skill oficial skill-creator de Anthropic te entrevista en lenguaje sencillo y luego redacta, prueba y empaqueta el skill por ti.

Disparadores de skills que sí se activan

Claude decide si usa un skill solo a partir de su nombre y descripción, nunca del archivo completo — así se escribe una descripción que de verdad se dispara.

Ponle una boleta de calificaciones a tu skill

Las autocalificaciones numéricas mienten. Arma un archivo de evals de aprobado/reprobado para la salida de tu skill, califícalo con un agente aparte de contexto limpio y repite el ciclo hasta que cada verificación apruebe.

Indexa tus docs, no los vuelques

Meter cada doc de metodología en el contexto del agente quema el presupuesto y entierra el único archivo que la tarea necesita. Arma un índice ligero que mapea tarea a doc, y carga solo lo necesario.

¿Adaptas la metodología de otra persona? Reescríbela y fírmala

En el momento en que adaptas las reglas o metodología de IA de otra persona a tu espacio, te vuelves su dueño. Reescríbela con tu propia voz, quita la marca del proveedor y fírmala — una copia obsoleta de un archivo ajeno se pudre.

Mantén las skills planas, y los helpers en el código fuente

Anidar scripts y helpers dentro de cada skill de IA duplica lógica sin tests que deriva en silencio. Mantén las skills como archivos de metodología planos y autocontenidos; pon el código determinista en tu árbol de fuente real y probado.

Audita tu biblioteca de skills cada trimestre con grep

Las skills de IA se pudren como el código, en silencio. Cada trimestre, usa grep en tu biblioteca de skills para hallar archivos sin referencias, deriva de front-matter y nombres de herramientas obsoletos, para que tu agente deje de cargar lo incorrecto.

Pasadas las 700 líneas, divide la skill

Un archivo de skill de IA de 800 líneas se hojea, no se lee. Pasadas unas 700 líneas o cuando cubre varios temas, divídelo con divulgación progresiva — conserva el nombre de archivo original como entrada de resumen para que toda referencia siga resolviendo.

Obliga a un bloque de suposiciones antes de cualquier tarea no trivial

La forma más común en que un agente de IA te hace perder tiempo es correr con suposiciones equivocadas sobre requisitos ambiguos. Un bloque de suposiciones de cuatro líneas convierte las conjeturas silenciosas en un checkpoint barato.

Dile a tu IA que la adulación es un modo de fallo

Por defecto tu asistente te da la razón y publica tu mala idea con entusiasmo. Haz que nombre el problema, cuantifique la desventaja con un número y proponga una alternativa antes de aceptar tu decisión.

Puntúa tu CLAUDE.md como un linter

Tu CLAUDE.md se carga en el contexto en cada turno, así que el exceso, las contradicciones y los lugares comunes gravan cada prompt. Puntúalo como un linter: empieza en 100, resta por cada contradicción y redundancia, y recorta lo que perdió puntos.

Cada servidor MCP registrado cuesta tokens en cada turno

Cada servidor MCP registrado inyecta su esquema de herramientas en el contexto en cada turno, lo uses o no. Audita lo que está registrado, reemplaza servidores en la nube por CLIs simples donde puedas y da de baja el resto.

Ponle la correa a Codex antes de soltarlo: modo sandbox y política de aprobación

Cómo funcionan juntos el modo sandbox y la política de aprobación de OpenAI Codex, y por qué workspace-write + on-request es el valor por defecto seguro para proyectos reales.

Un archivo que Codex lee antes que nada: cómo escribir un AGENTS.md conciso

Cómo escribir un AGENTS.md conciso para que OpenAI Codex lea las convenciones de tu proyecto antes de escribir una sola línea de código, en lugar de que las repitas en cada prompt.

Deja de mirar a un solo agente Codex trabajar: agentes en paralelo con git worktrees

Cómo usar git worktree para ejecutar varios agentes de OpenAI Codex sobre el mismo repositorio a la vez, cada uno en su propia carpeta, sin que colisionen.

Cursor Rules: Configúralo Una Sola Vez

Cómo escribir un archivo de Cursor Rules una sola vez para que Cursor aplique tus estándares de código en cada prompt, en lugar de que se los tengas que reexplicar cada vez.

Feed Cursor Live Docs

Cómo usar la función de docs de Cursor para indexar documentación en vivo y que deje de adivinar sintaxis desactualizada de librerías y APIs.

Restore Checkpoint: tu botón de deshacer

Cómo la función restore checkpoint de Cursor te permite revertir las ediciones de un agente de IA al estado anterior a un cambio malo, sin deshacer nada manualmente.

Un Solo Archivo Para Dejar De Repetirte Con Copilot

Deja de reescribir las convenciones de código de tu equipo en el chat de GitHub Copilot. Ponlas una vez en .github/copilot-instructions.md y Copilot las aplica automáticamente.

Deja de dejar que Copilot busque en todo internet

Las respuestas vagas de GitHub Copilot Chat casi siempre son señal de una pregunta sin alcance. Usa participantes @ y comandos / de barra para apuntar a Copilot a la fuente correcta.

Asigna tu backlog a Copilot, no a ti mismo

Asigna un issue de GitHub al coding agent de Copilot y trabaja la tarea en segundo plano, abriendo un pull request con un plan en vivo para que lo revises.

Deja de pedir JSON por favor — define un esquema

Pedirle a una IA que “responda en JSON” es frágil — los campos anidados salen mal, se inventan claves. Los structured outputs (generación restringida por esquema) lo arreglan en la raíz.

Cambia el modelo, no la app

Casi cada semana sale un nuevo modelo de IA. Pon cada llamada al modelo detrás de una sola interfaz para que cambiar de proveedor sea un cambio de configuración de una línea, no una reescritura.

Define el bucle, no el guion

Dale a un agente de IA herramientas y un límite de pasos en lugar de ramas codificadas a mano tras cada llamada — realimenta los resultados hasta que termine, y recorta lo que le devuelves.

Pon un puntaje de confianza entre el regex y el LLM

Puntúa cada parseo antes de escalar: deja que el regex resuelva el 95%+ fácil y gasta llamadas al LLM solo en los ítems por debajo de tu umbral de confianza.

Reduce tu reproducción antes de depurar

La velocidad de tu depuración está limitada por tu bucle de reproducción. Reduce la entrada, corre la única prueba que falla y fija semillas y relojes antes de probar una sola hipótesis.

Ese error que te dice que ejecutes este comando podría ser un ataque

Los mensajes de error, los stack traces y los logs de CI son datos no confiables, nunca instrucciones. Por qué tu agente puede ser comprometido por texto en su propia salida, y cómo evitarlo.

Nunca Escribas tu Propia Lógica de Reintentos

Usa una librería de reintentos probada, reintenta solo errores transitorios y nunca reintentes un 4xx — un error del cliente jamás va a funcionar por más veces que repitas.

Devuelve un tipo Result para las fallas que esperas

Deja de lanzar excepciones para fallas que sabes que van a ocurrir — devuelve un Result tipado para que el compilador obligue a quien llama a manejar el camino de error.

Oculta secretos en la configuración del logger, no en cada punto de llamada

Un solo `log.info(request)` puede filtrar todas tus API keys a los logs. Mueve la redacción a la configuración del logger para que el borrado ocurra en cada evento y no se pueda olvidar.

Nunca pongas user_id en una etiqueta de métrica

Una etiqueta de métrica tan inocente como user_id puede multiplicar por 10 tu factura — por qué explota la cardinalidad y qué etiquetas son seguras.

El backoff simple es una estampida

El backoff exponencial simple sincroniza a los clientes que fallaron y produce un DDoS autoinfligido; agrega full jitter para que los reintentos se dispersen y la dependencia pueda recuperarse.

Breaker por fuera, retry por dentro

Apila un circuit breaker y un retry en el orden equivocado y rompes los dos — por esto breaker(retry(call)) es la única composición que falla rápido y protege tu presupuesto de latencia.

Haz que tu IA lea package.json primero

Tu asistente escribe código de framework desde una memoria congelada. Haz que lea package.json para saber las versiones exactas y traiga la documentación que corresponde antes de escribir una sola línea.

Haz que tu IA diga UNVERIFIED

Una firma de API alucinada con confianza se lee igual que una real y te cuesta una hora — obliga a tu IA a citar la documentación oficial o a marcar la línea como UNVERIFIED.

Aleatoriza lo que no garantizas

Los errores de tu API se vuelven las funciones de alguien. Con suficientes usuarios, todo comportamiento observable termina siendo dependido. Varía a propósito lo que nunca prometiste para que nadie se acople a ello.

Publica un código de error estable y legible por máquina

Tus mensajes de error son una API secreta. En cuanto los consumidores les aplican regex, ya no puedes reescribirlos. Publica un código estable legible por máquina, deja el mensaje humano libre de cambiar, y marca qué errores son seguros para reintentar.

Más servicios que ingenieros es una señal de alerta

Los microservicios valen la pena cuando equipos dueños de servicios los despliegan de forma independiente a escala. Cuando tus artefactos desplegables superan a tus ingenieros, pagas el impuesto de los sistemas distribuidos todos los días sin recibir el beneficio. Ajusta los servicios al tamaño del equipo, no al hype.

Bórralo. ¿Todo se volvió más simple?

Un módulo cuya interfaz es casi tan compleja como su implementación no oculta complejidad: solo agrega un salto. Aplica la prueba de borrar e incorporar: si integrarlo de vuelta simplifica el sistema, era un passthrough superficial. Prefiere módulos profundos.

Todo script de bash de más de 200 líneas pertenece a Python

Bash carece de estructuras de datos, manejo de errores real y testeabilidad. Una vez que un script pasa las ~200 líneas con condicionales, reescríbelo en Python u otro lenguaje real: obtienes código más corto, manejo de errores real y una suite de pruebas en vez de cruzar los dedos.

Usa una tabla de Postgres antes de recurrir a una cola

Los equipos recurren a SQS o RabbitMQ por reflejo, y terminan operando un sistema nuevo entero para trabajo de bajo volumen. Si ya corres Postgres y tus productores y consumidores comparten un despliegue, una tabla simple es una cola perfectamente válida — y puedes graduarte después si de verdad la superas.

Evalúa cada herramienta por su costo a 12 meses

La landing page vende la primera semana. La factura real llega en el mes doce: guardias nocturnas, dificultad para contratar, licencias y lock-in. Evalúa cada elección por su costo a 12 meses.

Haz que tu archivo de reglas sea un mapa, no una biblioteca

Cada línea de un archivo de reglas siempre activo es un impuesto que se paga en cada turno. Si lo llenas de detalle, ahogas la señal. Mantén un núcleo durable y pequeño, y apunta a archivos que el agente carga solo cuando la tarea lo necesita.

Poda tus servidores MCP: cada esquema de herramienta es costo siempre activo

El esquema de cada herramienta conectada se carga en cada turno, y demasiadas herramientas degradan la precisión de selección, no solo el conteo de tokens. Expón las pocas herramientas que una tarea necesita y corta el resto.

Haz grep del código de datos escrito por IA para cazar el N+1

A la IA le encanta poner una consulta dentro de un for: trae una lista y luego golpea la base de datos una vez por fila. Ese es el clásico N+1 y escala pésimo. Búscalo con grep antes de mergear y reemplázalo con un solo join.

Abusar de React.memo y useMemo es una señal de alerta

useMemo en todas partes no está haciendo tu app más rápida. Memoizar cada valor y componente agrega complejidad y costo de comparación. Perfila primero y memoiza solo el cuello de botella que los números demuestran que importa.

Regex primero, el modelo para los bordes

Para texto de formato consistente, las regex resuelven ~95–98% de las extracciones de forma determinista — envía al LLM solo los casos de baja confianza y recorta tu factura drásticamente.

¿Agente o flujo de trabajo? Pregúntalo antes de construir

No toda automatización necesita un agente de IA. Aprende a distinguir un proceso predecible de uno genuinamente impredecible, y construye la opción más barata y confiable.

Describe tus herramientas como si entrenaras a alguien nuevo

Un agente solo elige la herramienta correcta si la descripción le dice exactamente qué hace y cuándo usarla. Así se escriben descripciones y docstrings que de verdad funcionan.

Un agente, una tarea: por qué los equipos de especialistas superan a los generalistas

Un agente que intenta investigar, evaluar el riesgo y escribir el informe no es una sola tarea, son tres. Divide los flujos de un solo agente sobrecargado en un equipo de especialistas.

Exige tres enfoques genuinamente distintos

Pídele un plan a una IA y converge en la primera idea, luego la rellena con hombres de paja: exige al menos tres enfoques genuinamente distintos para ampliar el espacio de opciones antes de reducirlo.

Nunca aceptes el primer plan de tu IA sin ver al perdedor

Una recomendación sin alternativa rechazada es un valor por defecto, no una decisión. Obliga a tu agente a divergir y luego converger, y exige siempre al segundo mejor y por qué perdió.

Registra un hash del arreglo de mensajes antes de cada llamada

Tu agente parece roto pero el modelo está bien — tu wrapper reescribe el historial entre llamadas. Haz un hash del arreglo de mensajes antes de cada request y la mutación aparece en una sola línea de log.

Cuenta las llamadas al modelo por turno

Un solo turno del usuario puede disparar cinco llamadas al modelo cuando un framework vuelve a preguntar en silencio ante una mala respuesta — así cuentas el número real y acotas el bucle.

No le pidas a la IA que investigue. Hazle cinco preguntas

Un prompt vago de investiga este tema da una respuesta superficial. Divide el tema en tres a cinco subpreguntas, repártelas a subagentes en paralelo que lean fuentes reales, y sintetiza un solo informe con citas.

Chunk With Overlap: deja de perder significado en los límites

Por qué la fragmentación ingenua de tamaño fijo rompe las respuestas de RAG, y cómo un splitter recursivo con solapamiento (chunk_size~1000, chunk_overlap~200) lo soluciona.

Rechaza cuando el contexto está vacío: la única verificación que detiene las alucinaciones de RAG

Cómo agregar un umbral de puntaje de similitud a tu pipeline de RAG para que una recuperación débil o vacía devuelva un rechazo honesto en lugar de una alucinación segura de sí misma.

Búsqueda híbrida + reranking: corrige el punto ciego de los embeddings con las coincidencias exactas

Por qué la búsqueda por embeddings puros falla con las consultas de coincidencia exacta como los números de pedido, y cómo combinar la búsqueda por palabras clave BM25 con el reranking lo soluciona — con números NDCG reales.

Congela el modelo, entrena el adaptador: cómo LoRA y QLoRA reducen la memoria del fine-tuning

LoRA congela los pesos de un modelo base y en su lugar entrena dos pequeñas matrices adaptadoras — aquí explicamos por qué eso reduce drásticamente la memoria de GPU para el fine-tuning sin sacrificar mucha calidad, y cómo QLoRA lo lleva aún más lejos.

Formato basura entra, respuestas basura salen: iguala la plantilla de chat antes de hacer fine-tuning

Un fine-tune que responde con texto roto y tokens sueltos casi nunca es un problema de datos: es un desajuste en la plantilla de chat. Aquí explicamos qué es una plantilla de chat y cómo aplicar la correcta antes de entrenar.

Un modelo que memoriza no es inteligente: observa la curva de pérdida para detener el sobreajuste

Entrena un fine-tune durante demasiadas épocas y dejará de generalizar para empezar a recitar tus datos de entrenamiento. Así se lee la curva de pérdida y se limita el número de épocas antes de que eso pase.

Ejecuta Cualquier Modelo de I.A. Abierto en Tu Propia Computadora, Gratis

Instala Ollama y ejecuta modelos de I.A. abiertos de forma local con un solo comando — sin factura de la nube, sin costo por token, nada sale de tu máquina.

Fija el comportamiento de un modelo local con un Modelfile

Escribe un Modelfile de Ollama de dos líneas para fijar de forma permanente las reglas o la personalidad de un modelo local, y luego ejecútalo como su propio modelo con nombre.

Chatea con tus propios archivos, de forma local: RAG en palabras simples

Conecta una I.A. local con tus propias notas o documentos usando RAG, para que consulte tus archivos reales antes de responder — sin necesidad de fine-tuning.

Los guardrails son dos puntos de control, no uno

La mayoría de los guardrails de IA solo revisan un lado de la conversación. Aquí te explicamos por qué necesitas una verificación de entrada y otra de salida, y cómo construir ambas.

Un Prompt Se Va a Romper, Así que Limita el Radio de Impacto

No puedes filtrar cada inyección de prompt. Así se limita lo que un agente de IA secuestrado puede hacer realmente, con herramientas de mínimo privilegio y aprobación humana.

Tu juez de I.A. tiene favoritos, compruébalo

LLM-as-judge escala la evaluación más allá de la revisión manual, pero hereda sesgos. Así se corre una prueba de intercambio posicional antes de confiar en el puntaje.

Ejecuta una unidad antes de escalar

Antes de correr 10.000 llamadas de IA, corre una. Mide el costo real y luego escala — con la cuenta exacta por unidad y el 50% de descuento del batch.

Pon un límite fijo por trabajo en cada llamada de IA automatizada

Un bug en un trabajo de IA automatizado debe producir una factura acotada, no una ilimitada — limita tokens, elementos y tiempo por llamada, y pon una alarma de presupuesto en la cuenta.

Los secretos borrados en una capa posterior de Docker siguen vivos en el historial

Un secreto copiado o usado en un paso RUN del Dockerfile queda grabado en esa capa para siempre — borrarlo después no lo elimina, y cualquiera puede extraerlo con un solo comando. Usa build secrets.

Reemplaza las claves de AWS de larga duración con OIDC

Las claves de acceso estáticas de AWS en CI nunca expiran, así que una sola filtración funciona hasta que alguien lo note. Cámbialas por asunción de rol con OIDC y obtén credenciales de corta duración sin nada guardado que robar.

Audita los scripts de postinstall de cualquier paquete

npm install puede ejecutar el script de shell de un desconocido en el instante de instalar. Audita los hooks postinstall y prepare y marca los que tocan la red o el shell, para atrapar la ejecución de código de la cadena de suministro antes de que corra.

El system prompt no es un límite de seguridad, el código sí

Una instrucción de no-revelar en tu system prompt no detiene nada, porque un usuario motivado puede convencer al modelo de saltarse cualquier instrucción. Impón la seguridad con código determinista que rodee la llamada al modelo: un filtro de entrada antes, un limpiador de salida después.

La configuración de tu agente es una superficie de ataque

Los archivos de instrucciones, los settings y las configuraciones de servidores MCP dirigen a tu agente de código, así que una instrucción oculta o una clave filtrada ahí es una vía de brecha real. Escanéalos como código en busca de permisos comodín, secretos hardcodeados e instrucciones inyectadas.

Cuando tu pipeline lee cargas, el contenido es el atacante

Cuando tu pipeline de IA ingiere cargas o páginas scrapeadas, el contenido mismo es el atacante. Trata el contenido no confiable como datos, nunca como instrucciones: delimítalo antes de que el modelo lo vea y nunca lo dejes fluir sin escapar hacia un shell, SQL o una ruta de archivo.

Dale a cada nivel de severidad un piso de confianza

Cuando cada hallazgo de la IA se marca como crítico, la gente deja de leer. Condiciona cada severidad a un piso de confianza y baja un nivel ante la incertidumbre, para que un crítico signifique de verdad detente y corrige.

Enruta cada tarea al modelo correcto

Ningún modelo de IA gana en todas las tareas. Así es como los reviewers enrutan escritura, código, razonamiento y bugs atascados a distintos modelos en lugar de elegir un solo favorito.

No confíes en el modo plan a ciegas

Se supone que el “modo plan” significa solo lectura. Una persona que hacía pruebas descubrió un modelo editando archivos igualmente. Así verificas que el modo plan de verdad se respeta antes de confiar en él.

Prueba los modelos en tareas difíciles, no en las fáciles

Los prompts fáciles hacen que todos los modelos de IA parezcan intercambiables. Así fue como una persona que prueba a fondo construyó un benchmark privado y desordenado para ver las diferencias reales, y por qué aún necesitas revisión humana.