AI Coding on KnightLi Blog

Cómo elegir entre GPT-5.5, GPT-5.4 y GPT-5.3-Codex

Sun, 10 May 2026 08:43:17 +0800

Si solo quieres la conclusión corta, es bastante simple: usa GPT-5.5 por defecto, elige GPT-5.4 cuando el presupuesto y el consumo importen más, y presta especial atención a GPT-5.3-Codex cuando trabajes en tareas de ingeniería de software de larga duración dentro de Codex o necesites funciones como Cloud Tasks y Code Review.

No es solo una impresión subjetiva. A fecha de 2026-05-10, la documentación oficial de Codex sigue diciendo que la mayoría de las tareas deberían empezar con gpt-5.5; si gpt-5.5 aún no está disponible, conviene seguir con gpt-5.4; y para tareas ligeras o subagentes, gpt-5.4-mini encaja mejor.

Diferencias de posicionamiento entre los tres modelos

Primero conviene mirar la posición oficial de cada uno.

GPT-5.5 es el modelo frontier más reciente dentro de Codex, orientado a programación compleja, uso del ordenador, trabajo de conocimiento y flujos de investigación. Funciona como el modelo principal por defecto para análisis difíciles, tareas de varios pasos, cambios en múltiples archivos, diseño de soluciones y trabajo documental más pesado.

GPT-5.4 es una opción más equilibrada y estable. OpenAI lo describe como un modelo que reúne la capacidad de programación de GPT-5.3-Codex con mejor razonamiento, uso de herramientas y flujos agentic. Es decir, no es simplemente una versión más débil de 5.5, sino una opción más balanceada para usar como base a largo plazo.

GPT-5.3-Codex sigue siendo un modelo muy fuerte para código, pero sus ventajas están más concentradas en la ingeniería de software real y en los flujos nativos de Codex. La documentación oficial también deja claro que está optimizado para agentic coding tasks, mientras que GPT-5.4 ya hereda buena parte de esa fortaleza.

Por eso hoy ya no tiene tanto sentido tratar GPT-5.3-Codex como si fuera automáticamente “el mejor modelo de programación”. En la mayoría de escenarios cotidianos de desarrollo, conviene mirar antes GPT-5.5 y GPT-5.4.

Cómo elegir según el tipo de tarea

Si tu trabajo es preguntas frecuentes, explicaciones complejas, síntesis de materiales, análisis de archivos o integración de información extensa, GPT-5.5 es la mejor opción. No solo escribe código bien, sino que también resuelve mejor el trabajo intelectual exigente fuera del código puro.

Si tu trabajo es programación compleja, refactorización, depuración, diseño de arquitectura o cambios en varios archivos, GPT-5.5 sigue siendo la primera elección. Esa es también la recomendación oficial de Codex: cuando gpt-5.5 está disponible, lo normal es empezar por ahí.

Si te importan más el consumo y los límites, y aun así quieres una calidad alta, GPT-5.4 suele ser el valor por defecto más razonable. Para desarrollo habitual, reescrituras normales, traducciones estándar, generación de scripts y corrección de bugs, GPT-5.4 ya es suficientemente fuerte y además consume menos.

Si usas Codex CLI, la extensión de IDE o la app para un trabajo más parecido al de un agente de ingeniería, por ejemplo leer un repositorio durante mucho tiempo, modificar código de forma continua, encadenar tareas, o usar Cloud Tasks y Code Review, GPT-5.3-Codex sigue teniendo peso. No porque sea más avanzado que GPT-5.5, sino porque Cloud Tasks y Code Review de Codex siguen ejecutándose sobre GPT-5.3-Codex.

Cuánta diferencia hay en consumo

La tabla de credits de Codex deja las diferencias bastante claras.

Bajo la tarificación por tokens para Business / New Enterprise:

GPT-5.5: 125 credits / 1M tokens de entrada, 12.5 credits de entrada en caché y 750 credits de salida
GPT-5.4: 62.5 credits / 1M tokens de entrada, 6.25 credits de entrada en caché y 375 credits de salida
GPT-5.3-Codex: 43.75 credits / 1M tokens de entrada, 4.375 credits de entrada en caché y 350 credits de salida

Eso significa que, si solo miras la tarifa nominal, GPT-5.4 cuesta aproximadamente la mitad que GPT-5.5 para cantidades parecidas de entrada y salida. GPT-5.3-Codex es más barato en entrada, pero su salida ya está bastante cerca de GPT-5.4, así que no es una opción “muchísimo más barata” en conjunto.

Hay otro detalle importante. La documentación oficial también dice que GPT-5.5 uses significantly fewer tokens to achieve results comparable to GPT-5.4. En otras palabras, aunque la tarifa unitaria sea más alta, en tareas complejas puede compensar con menos tokens y menos retrabajo.

Sin embargo, en tareas como reescritura de artículos con plantilla fija, traducción o generación de descripciones SEO, donde la longitud de entrada y salida suele ser bastante estable, esa ventaja de “equivocarse menos” se nota menos que en la ingeniería compleja. En la práctica, GPT-5.4 suele seguir siendo la opción más barata, normalmente con un ahorro de alrededor del 45% al 50%.

Diferencias en los límites de uso dentro de Codex

Además del precio, estos modelos no están disponibles exactamente de la misma manera dentro de Codex.

A fecha de 2026-05-10, GPT-5.5 es el modelo recomendado en Codex, pero por ahora solo está disponible cuando inicias sesión en Codex con ChatGPT, y no admite autenticación con API key. GPT-5.4 y GPT-5.3-Codex sí admiten acceso vía API.

Además, GPT-5.5 y GPT-5.4 no soportan actualmente Codex Cloud Tasks ni Code Review. Esas dos funciones siguen siendo terreno de GPT-5.3-Codex. Por eso, si lo que realmente quieres es ejecutar trabajo de ingeniería prolongado dentro de Codex, no basta con comparar cuál modelo es más fuerte: también debes mirar si la función que necesitas sigue dependiendo de GPT-5.3-Codex.

Si solo usas mensajes locales, la ventana oficial de cinco horas del plan Plus es aproximadamente:

GPT-5.5: 15-80
GPT-5.4: 20-100
GPT-5.3-Codex: 30-150

Eso también refleja una diferencia práctica: GPT-5.5 es el más fuerte, pero normalmente te da menos usos dentro de un límite fijo; GPT-5.4 es más equilibrado; y GPT-5.3-Codex puede parecer más resistente en mensajes locales.

Cómo elegir en escenarios comunes

En el trabajo diario hay muchas tareas frecuentes. La forma más útil de comparar estos modelos no es preguntar en abstracto cuál es “mejor”, sino separarlos por escenario.

1. Preguntas diarias, organización de materiales y resúmenes largos

GPT-5.5: La mejor opción. Maneja mejor las solicitudes ambiguas, completa contexto y convierte información dispersa en una salida estructurada.

GPT-5.4: Adecuado para resúmenes normales y trabajo en lote. Cuando la dificultad es moderada y el volumen es alto, suele ser la opción más económica.

GPT-5.3-Codex: No es ideal como opción principal. Puede hacerlo, pero no es donde más destaca.

2. Explicación de conceptos técnicos, lectura de código y proyectos antiguos

GPT-5.5: Mejor para proyectos complejos. Es más fiable cuando hay muchas relaciones entre archivos, cadenas largas de llamadas y mucha deuda histórica.

GPT-5.4: Muy bueno para lectura y explicación normales. Funciona bien para entender funciones, módulos, configuraciones y ponerse al día en un proyecto.

GPT-5.3-Codex: Más orientado a ejecución, no es la primera opción para tareas centradas en explicación.

3. Scripts, herramientas pequeñas, SQL, shell y expresiones regulares

GPT-5.5: Mejor cuando el script forma parte de un diseño de sistema más amplio, conecta varios servicios o tiene restricciones complejas.

GPT-5.4: La mejor opción principal por defecto. La mayoría de scripts, herramientas pequeñas, SQL y trabajo de línea de comandos caben perfectamente dentro de su zona de confort, y además consume menos.

GPT-5.3-Codex: Tiene sentido si el script es solo una parte de un flujo más grande de agente de ingeniería, pero no hace falta priorizarlo para scripting aislado.

4. Corregir bugs, hacer cambios pequeños, añadir tests y desarrollo rutinario

GPT-5.5: Mejor para correcciones algo más complejas, especialmente si primero debe analizar la causa, luego editar varios archivos y finalmente añadir pruebas.

GPT-5.4: El mejor caballo de batalla para el desarrollo diario. En bugs normales, pequeñas funciones, esqueletos de tests, renombrado y limpieza de formato, ofrece el mejor equilibrio entre coste y resultado.

GPT-5.3-Codex: Capaz, pero normalmente no es la primera opción salvo que necesites específicamente Cloud Tasks o un flujo de agente de ingeniería.

5. Refactorización compleja, diseño de arquitectura y depuración difícil

GPT-5.5: La mejor opción. En tareas complejas, lo caro no suele ser una respuesta aislada, sino el retrabajo. GPT-5.5 encaja mejor como modelo principal para resolver problemas difíciles.

GPT-5.4: Bueno para trabajos de complejidad media. Puede encargarse de refactorizaciones y diseño, pero en contextos muy largos, razonamiento de muchos pasos y problemas con alta incertidumbre, suele ser menos estable que GPT-5.5.

GPT-5.3-Codex: Más orientado a ejecución, y no es la prioridad por defecto para trabajo de decisión difícil.

6. Tareas ligeras en lote, trabajo repetitivo y sub-tareas divididas

GPT-5.5: Puede hacerlo, pero normalmente no compensa por coste.

GPT-5.4: La mejor opción. Para editar comentarios en lote, reformatear, generar código de plantilla o hacer cambios repetitivos de contenido, es la más equilibrada.

GPT-5.3-Codex: Tiene sentido si el trabajo ya vive dentro de un flujo de ingeniería de Codex, pero en términos puros de coste-rendimiento suele quedar por detrás de GPT-5.4.

7. Automatización, ejecución de agentes y trabajo continuo sobre repositorios

GPT-5.5: Bueno para diseño inicial, reglas y descomposición de tareas complejas.

GPT-5.4: Bueno para escribir scripts de automatización y completar lógica de flujos de complejidad media, especialmente si importa el acceso por API.

GPT-5.3-Codex: Es el más relevante aquí. Como Cloud Tasks y Code Review de Codex siguen corriendo sobre él, encaja mejor en escenarios donde quieres que el sistema siga trabajando por sí solo.

8. Copy para páginas importantes, presentación de marca y pulido final

GPT-5.5: La mejor opción. Tiene mayor naturalidad, mejor control de estilo y más consistencia en textos largos.

GPT-5.4: Adecuado para la mayoría de páginas normales y actualizaciones diarias. Las páginas importantes pueden partir de un borrador en GPT-5.4 y pulirse después con GPT-5.5.

GPT-5.3-Codex: No encaja como modelo principal de redacción.

9. Reescritura de artículos con plantilla fija, traducción y descripciones SEO

GPT-5.5: Mejor para diseñar la plantilla, hacer el pulido final, cerrar páginas importantes y producir una traducción chino-inglés más natural.

GPT-5.4: La mejor opción para producción en lote. En reescritura de artículos estándar, traducciones con estructura fija, reescritura de copy de producto y generación masiva de meta descriptions, suele ofrecer el mejor equilibrio entre calidad y coste.

GPT-5.3-Codex: No es adecuado como modelo principal de redacción. Es más útil para scripts de procesamiento por lotes, limpieza de HTML, conservación de estructuras de etiquetas y mejora de flujos de publicación.

10. Copy para e-commerce, páginas de categoría y operación masiva de contenidos

GPT-5.5: Bueno para definir reglas, hacer revisiones de muestra y pulir páginas de alto valor.

GPT-5.4: La mejor opción para producción masiva. En títulos de producto, descripciones de categorías, textos de campañas y contenido SEO long-tail, ofrece un equilibrio más práctico.

GPT-5.3-Codex: Bueno para scraping, limpieza, procesamiento en lote y scripts de publicación automática, pero no tanto para el copy principal.

Si comprimes todos estos escenarios en una sola línea:

Trabajo intelectual complejo, análisis complejo y redacción de alto valor: prioriza GPT-5.5
Desarrollo diario, producción en lote y trabajo repetitivo: prioriza GPT-5.4
Agentes de ingeniería en Codex, Cloud Tasks y Code Review: presta especial atención a GPT-5.3-Codex

Recomendación final

Si tu trabajo consiste sobre todo en programación normal, corrección de bugs, preguntas técnicas y documentación de apoyo, GPT-5.4 es un valor por defecto muy sólido.

Si necesitas análisis de proyecto más complejos, cambios en varios archivos, diseño de arquitectura, depuración difícil, o un solo modelo que cubra tanto ingeniería como trabajo intelectual exigente, ve directamente a GPT-5.5.

Si lo que más pesa es el flujo de trabajo de ingeniería dentro de Codex, como Cloud Tasks, Code Review y ejecución prolongada de agentes, entonces GPT-5.3-Codex sigue mereciendo un lugar, aunque ya no tenga demasiado sentido como primera opción por defecto.

Para un sitio con contenido de plantilla fija, una combinación más práctica suele ser:

GPT-5.4 para la producción en lote
GPT-5.5 para diseñar la plantilla, hacer revisiones de muestra y pulir el resultado final
GPT-5.3-Codex para escribir herramientas de automatización en lugar del contenido principal

Resumen

El orden por defecto más razonable hoy es GPT-5.5 primero, GPT-5.4 segundo, y GPT-5.3-Codex reservado para escenarios más ligados a agentes de ingeniería o a funciones específicas de Codex.

Si la pregunta concreta es “¿cuánto ahorra GPT-5.4 frente a GPT-5.5 al reescribir el mismo artículo con plantilla?”, entonces, según la tabla oficial de credits y la estructura típica de tokens de este tipo de tarea, es razonable pensar en un ahorro cercano a la mitad. Para sitios de contenido por lotes, esa diferencia es lo bastante grande como para que la práctica habitual no sea usar GPT-5.5 en todo, sino usar GPT-5.5 para fijar reglas y estilo, y dejar la producción masiva a GPT-5.4.

Cómo elegir planes de AI Coding: los usuarios ligeros priorizan comodidad, los intensivos necesitan flexibilidad

Sun, 10 May 2026 08:20:58 +0800

Los planes de AI Coding han cambiado muy rápido en los últimos seis meses. Muchas herramientas han pasado de un modelo de cobro por mensajes o por uso limitado a uno claramente basado en consumo, los planes baratos y generosos se han ido recortando, y algunos servicios extranjeros han añadido verificaciones de identidad, restricciones regionales y reglas de uso más estrictas.

Para un desarrollador, la pregunta ya no es solo qué modelo es el más fuerte. También importa cuánto vas a gastar cada mes, si la cuota alcanza, si la herramienta resulta cómoda de usar y si podrás cambiar sin demasiado dolor cuando un proveedor suba precios o cambie las reglas de repente.

Una conclusión bastante útil es esta: los usuarios ligeros deberían comprar comodidad, los usuarios intermedios deberían comprar relación calidad-precio y los usuarios intensivos deberían comprar flexibilidad. Cuanto más intensivo sea el uso, menos conviene atar el modelo y la herramienta dentro del mismo plan.

Cuatro cosas que conviene revisar antes de elegir un plan

Antes, al elegir un plan de AI Coding, normalmente bastaba con mirar tres cosas:

Si el modelo era lo bastante fuerte.
Si la velocidad de respuesta era estable.
Si la cuota incluida alcanzaba.

Ahora hay que añadir una cuarta: si el modelo y la herramienta se pueden separar.

El modelo aporta la capacidad de razonamiento, mientras que la herramienta gestiona contexto, edición de archivos, orquestación de Agent y experiencia de flujo de trabajo. Ambas cosas importan, pero es mejor no dejarlas completamente atadas entre sí. Por ejemplo, si te gustan los modelos de Claude, puedes usar el plan oficial o conectar la API a otras herramientas. Y si te gusta un editor o entorno Agent concreto, es preferible que pueda conectarse a varios modelos en lugar de obligarte a usar solo el suyo.

La gracia de esto no es complicarse por gusto. Es reducir riesgos. AI Coding es uno de los segmentos que cambian más rápido. Un plan que hoy parece generoso puede cambiar de precio en dos meses, y una herramienta que hoy parece cómoda puede empeorar después de un cambio en la integración con modelos. Separar modelos y herramientas te deja margen de maniobra.

Los planes extranjeros se están endureciendo

Herramientas como GitHub Copilot, Cursor, Windsurf y Claude Code siguen siendo la base de trabajo de mucha gente, pero la tendencia es cada vez más clara: mantener planes muy baratos con cuotas muy altas es más difícil, y la facturación por uso real es cada vez más común.

Cuando servicios como GitHub Copilot se apoyan más en facturación por uso, el supuesto margen de ahorro de algunos planes cae bastante. Para usuarios ligeros siguen siendo cómodos, pero para quienes usan agentes, contexto largo y tareas complejas de código con mucha frecuencia, el consumo real empieza a parecerse mucho más al coste real de API.

Cursor y Windsurf, en esencia, empaquetan capacidad de modelo dentro de una experiencia de IDE. Su punto fuerte es que funcionan bien desde el primer momento y ofrecen una experiencia de editor madura. Su punto débil es el mayor nivel de dependencia de herramienta. Cuanto más dependas de sus agentes propietarios, sus índices y sus flujos automáticos, más caro será migrar después.

Claude Code sigue siendo atractivo tanto por experiencia como por atención del ecosistema, pero las suscripciones internacionales, la verificación de identidad, las restricciones regionales y la seguridad de los servicios intermedios son riesgos que los usuarios en China necesitan valorar con cuidado. En especial, los relays de terceros pueden mezclar modelos, ser inestables, exponer datos o desaparecer, así que no son una gran base a largo plazo para trabajo importante.

Ventajas y límites de los planes nacionales

Una ventaja de muchos planes nacionales de AI Coding es que suelen ofrecerse en forma de API, lo que hace que queden menos atados a una sola herramienta. Puedes conectarlos a OpenCode, Cline, Continue, tus propios scripts o agentes internos.

El problema también es evidente: si quieres al mismo tiempo un modelo fuerte, buena velocidad y bastante cuota, hay pocos planes que cumplan todo a la vez.

La familia GLM es fuerte dentro del panorama nacional, pero en horas punta el rendimiento puede volverse inestable y las tareas pesadas acaban limitadas por velocidad. Kimi tiene buen nivel, pero sus reglas de precio y cuota hay que seguirlas de cerca, sobre todo la transparencia del límite real. Modelos como MiniMax son más amables en velocidad y cuota, lo que los hace útiles para tareas ligeras del día a día, lotes y ayuda de código no demasiado compleja, aunque pueden quedar un escalón por debajo en razonamiento de ingeniería difícil. DeepSeek puede parecer muy rentable cuando un modelo nuevo está en precio promocional, pero al acabar la promoción toca reevaluarlo con tarifa normal.

Por eso, en muchos casos, las opciones nacionales funcionan mejor como un grupo de modelos disponible para repartir trabajo según la tarea, y no como una apuesta total por un solo modelo y un solo plan.

Usuarios ligeros: elige lo que resulte cómodo y no sobrediseñes

Si solo usas AI para retocar scripts, completar documentación, explicar errores o generar herramientas pequeñas una o dos veces por semana, probablemente no necesitas una configuración complicada.

En este caso importa más la comodidad. Cursor, Windsurf, Trae, CodeBuddy, Tongyi Lingma, GitHub Copilot y herramientas similares son opciones razonables. El objetivo no es perseguir el coste unitario más bajo, sino reducir fricción: algo estable dentro de tu editor, con buenas sugerencias y fácil de revertir cuando se equivoca.

Para usuarios ligeros, construir capas de API, relays y proxys complejos solo para ahorrar un poco de dinero rara vez compensa. El tiempo, el riesgo de cuenta y el coste de depuración suelen costar más que la suscripción que te ahorras.

Usuarios intermedios: mira la relación calidad-precio, pero también la portabilidad

Si usas AI todos los días para programar, modificar proyectos, generar pruebas y preparar documentación, la cuota y el consumo real empiezan a importar mucho más.

En este caso conviene separar la herramienta principal de los modelos de respaldo. Por ejemplo, un plan cómodo de IDE puede servir para el trabajo diario, mientras que una API o plan agregador conectable a varias herramientas puede encargarse de tareas con contexto más largo o flujos de Agent más complejos.

Aquí hay tres preguntas clave:

Si se puede integrar con herramientas de terceros.
Si el consumo de tokens o cuota es visible y entendible.
Si al superar el límite se aplica throttling, degradación, corte del servicio o pura facturación por uso.

Si un plan parece barato pero solo funciona dentro de su propia herramienta, conviene contar también el coste de migrar más adelante. Si cuesta algo más pero puede conectarse a varias herramientas, puede ser mejor como base a largo plazo.

Usuarios intensivos: no bloquees modelo y herramienta juntos

Para los usuarios intensivos, la necesidad principal es la flexibilidad.

Cuando una persona o un equipo usa agentes de AI de forma intensiva todos los días, el consumo crece muy rápido. Búsquedas de repositorio, cambios con contexto largo, depuración en múltiples rondas y reparación automática de pruebas pueden multiplicar el gasto en tokens. Si en ese punto dependes de un solo plan, aparecen tres problemas con facilidad:

La cuota deja de ser suficiente de repente.
La regla de cobro cambia de forma inesperada.
Una herramienta o un modelo deja de estar disponible temporalmente.

La opción más estable es montar una estructura por capas: una herramienta Agent principal, uno o varios endpoints de modelo intercambiables, un modelo barato para tareas simples y un modelo fuerte para tareas difíciles. No conviene mandar todas las tareas pequeñas al modelo más caro, ni depender solo del más barato para las tareas críticas.

Para un usuario intensivo, que las herramientas puedan conectarse a cualquier modelo y que los modelos puedan moverse entre herramientas importa más que ahorrar unas decenas de dólares al mes. Lo realmente caro no suele ser la suscripción. Lo caro es quedar atrapado en un solo ecosistema y tener que reconstruir el flujo de trabajo después.

Una estrategia de combinación más estable

Una forma razonablemente sólida de organizarlo sería esta:

Usa un modelo de bajo coste para tareas ligeras como explicar código, escribir scripts pequeños, formatear y generar documentos simples.
Usa un modelo orientado a valor para tareas intermedias como desarrollo normal de funciones, completar pruebas y sugerencias de refactorización.
Usa un modelo fuerte para tareas difíciles como cambios de arquitectura, correcciones entre varios archivos, bugs complejos y razonamiento con contexto largo.
Mantén abierta la capa de herramientas, eligiendo soluciones que puedan conectarse por API, exportar configuración y cambiar de modelo.
Conserva un camino de respaldo, de forma que si tu plan principal cambia reglas puedas moverte rápido a otra herramienta o modelo.

Puede que no sea la configuración más barata posible, pero sí una mucho más resistente. Los precios y cuotas de AI Coding van a seguir cambiando. Lo valioso a largo plazo no es un plan que hoy parezca muy generoso, sino un flujo de trabajo portable.

Resumen

Los planes de AI Coding no deberían juzgarse solo por el precio mensual. Los usuarios ligeros deberían priorizar simplicidad y comodidad. Los usuarios intermedios deberían fijarse en cuota, consumo y capacidad de migrar. Los usuarios intensivos deberían separar modelos y herramientas para no quedar atrapados en un único ecosistema.

La idea más importante es que los planes cambian, los modelos cambian y las herramientas también. Mantener la capacidad de elegir en tus propias manos es la forma más importante de controlar costes cuando trabajas con AI Coding a largo plazo.

Codex vs Claude Code: cómo elegir entre dos diseños de Subagent

Fri, 08 May 2026 14:14:01 +0800

Las herramientas de programación con IA están prestando cada vez más atención a los subagentes. No es simple moda: un solo agente acaba encontrando límites cuando debe manejar tareas reales de ingeniería.

Si un agente lee código, revisa logs, modifica implementación, ejecuta pruebas, analiza errores y resume resultados a la vez, el contexto principal se ensucia rápido. Resultados de búsqueda, salidas de comandos, logs de pruebas y razonamientos intermedios se mezclan. Las decisiones posteriores se vuelven menos fiables. Además, explorar, implementar, verificar y revisar en un único hilo dificulta el paralelismo.

El objetivo de los subagentes es reducir esa presión. La sesión principal deja de hacerlo todo de principio a fin y pasa a coordinar: define objetivos, asigna trabajo, recibe resultados y los integra. Un subagente se ocupa de una parte local, como exploración, implementación, verificación o revisión, y devuelve una conclusión comprimida.

Un subagente no es “otra copia de mí”. Es una forma de dividir trabajo de ingeniería confuso en roles más claros.

Fundamentos compartidos

Un sistema maduro de subagentes suele necesitar cuatro bases:

Aislamiento de contexto.
Especialización de roles.
Configuración a nivel de proyecto y usuario.
Límites de herramientas y permisos.

El aislamiento de contexto es esencial. En un repositorio real hay mucho material intermedio: búsquedas, logs de pruebas, salidas de comandos. Si todo entra en la sesión principal, el hilo principal se vuelve ruidoso. Un subagente puede digerir ese proceso local y devolver solo las señales útiles.

La especialización de roles también importa. Multi-agent no significa abrir varias copias del mismo modelo. Un rol de exploración debe buscar, leer y resumir. Un rol de implementación debe centrarse en cambios locales. Un rol de verificación debe ejecutar checks, identificar riesgos e informar con claridad.

Los límites de herramientas y permisos determinan si el sistema es seguro. Un subagente no debería heredar automáticamente todas las capacidades de la sesión principal. Un explorer de solo lectura no necesita escribir archivos. Un verifier no siempre necesita modificar implementación.

Codex y Claude Code comparten estas preocupaciones, pero toman caminos distintos.

Codex: delegación explícita

El diseño de Codex es más contenido.

Ofrece un mecanismo de delegación controlado y ligero alrededor de la sesión principal actual. Cuándo delegar, a quién delegar y cuándo recoger resultados son decisiones explícitas. El flujo de control permanece en la tarea actual.

Sus rasgos:

La sesión principal delega explícitamente.
El conjunto de roles se mantiene pequeño.
La sesión principal sabe qué agente hace qué.
Los resultados vuelven a la línea principal.
Los límites de colaboración son transparentes.

Esto encaja con equipos que valoran orquestación manual, previsibilidad y determinismo. Puedes pedir a un explorer que inspeccione una cadena de llamadas, a un worker que haga un cambio acotado y a la sesión principal que integre el resultado.

La contrapartida es que la presión de orquestación sigue en la sesión principal. Debe decidir cuándo dividir, cómo dividir, a quién asignar y cómo fusionar resultados. Para colaboración ligera es cómodo; para flujos largos puede cansar.

Claude Code: agentes como puestos de trabajo

Claude Code toma una ruta más de plataforma.

Trata los agentes como objetos describibles, seleccionables, configurables, con memoria, aislables y capaces de ejecutarse en segundo plano. Un subagente no es solo una ayuda temporal en una conversación; se parece más a un puesto de trabajo dentro de un sistema de ingeniería.

El sistema puede exponer listas de agentes, casos de uso, descripciones y límites de herramientas al modelo, permitiendo que el modelo decida qué rol usar en cada turno. Eso hace la delegación más automática.

Varios elementos definen este enfoque.

Primero, un sistema de roles. Explorer, planner, general-purpose y verifier pueden tener descripción de uso, restricciones de herramientas, modelos por defecto y condiciones de ejecución. Un explorer de solo lectura no edita archivos; un planner diseña; un verifier comprueba.

Segundo, herencia y override. Un subagente no es completamente libre. Hereda los límites grandes de la sesión principal, pero puede ajustar comportamiento local dentro de reglas permitidas.

Tercero, memoria. La memoria no es solo recordar algo. Puede tener alcance: memoria de usuario para preferencias largas, memoria de proyecto para contexto del repositorio y memoria local para estado del entorno.

Cuarto, background y worktree isolation. Algunas verificaciones pueden seguir en segundo plano mientras el hilo principal avanza. Si hace falta aislamiento fuerte, el agente puede trabajar en un worktree separado.

Quinto, ecosistema de plugins. Si los agentes son objetos de primera clase, hay que pensar en distribución, instalación, prioridades, overrides y seguridad. Los plugin agents pueden entrar al sistema, pero campos de alto riesgo como permission mode, hooks o MCP servers deben estar controlados.

Esto hace que Claude Code se parezca más a un runtime de agentes que a una herramienta de colaboración de una sola sesión.

Diferencia principal

Codex se parece a una herramienta de delegación controlada:

Delegación explícita.
Roles ligeros.
Flujo de control claro.
Subtareas centradas en la sesión actual.
Adecuado para trabajo humano-orquestado y determinista.

Claude Code se parece a un sistema de puestos de ingeniería:

Los agentes están modelados formalmente.
Los roles son más sistemáticos.
Memoria, background, aislamiento y plugins forman parte del runtime.
El modelo puede ayudar a elegir roles.
Adecuado para proyectos largos y workflows de plataforma.

La pregunta no es cuál tiene más funciones. Es si quieres que un subagente sea “un ayudante al que llamo explícitamente” o “un puesto permanente dentro del sistema”.

Cómo elegir

Elige el estilo Codex si valoras control explícito, delegación ligera y paralelismo seguro dentro de la sesión actual. Encaja con revisiones, cambios pequeños, tareas claras y flujos donde la persona quiere mantener el ritmo.

Elige el estilo Claude Code si necesitas roles sistemáticos, memoria a largo plazo, ejecución en segundo plano, aislamiento por worktree, plugins y un runtime más completo.

Hazte dos preguntas:

¿Aceptas que el modelo decida quién debe hacer el trabajo?
¿Necesitas un runtime de agentes más completo?

Si la primera te incomoda, la delegación explícita es mejor. Si la segunda es sí, un sistema tipo plataforma encaja mejor.

Consejos prácticos

No trates los subagentes como “más modelos igual a más potencia”.

Define límites de tarea para cada rol.
Limita las herramientas de cada rol.
Pide conclusiones, no logs crudos.
Mantén la decisión final en la sesión principal.
Haz visibles tareas en background y worktrees.
Define límites de seguridad para plugins.

El valor de los subagentes no está en la cantidad, sino en la calidad de la división del trabajo.

Resumen

Codex y Claude Code resuelven el mismo problema: un solo agente no puede cargar cómodamente con todo el trabajo real de ingeniería. Ambos reconocen la importancia de aislar contexto, especializar roles, definir permisos y resumir localmente.

Codex es más contenido y prioriza delegación explícita y control de la sesión principal. Claude Code es más sistemático y trata los agentes como puestos configurables, con memoria, aislamiento, background y ecosistema de plugins.

La elección no depende de qué marca gana, sino de si tu flujo necesita una herramienta de colaboración controlada o un runtime completo de agentes.

9Router: conecta Claude Code, Codex y Cursor a un mismo router de IA

Fri, 08 May 2026 13:41:15 +0800

9Router es un router local para herramientas de programación con IA. Permite conectar Claude Code, Codex, Cursor, Cline, Copilot, OpenCode, OpenClaw y herramientas similares a un único endpoint compatible con OpenAI, y desde ahí enrutar las solicitudes a distintos modelos y proveedores.

No pretende ser otro cliente de chat. Se coloca entre tus herramientas de programación y los proveedores de modelos para resolver problemas prácticos: formatos de API incompatibles, cambios manuales entre proveedores, consumo rápido de tokens por salidas de herramientas, cortes por cuotas agotadas y configuración complicada de varias cuentas.

Según el README, 9Router admite más de 40 proveedores y más de 100 modelos. Incluye RTK Token Saver, fallback automático, seguimiento de cuotas, rotación multi-cuenta, traducción de formatos y registros de solicitudes. Está escrito en JavaScript, usa Node.js, Next.js, React, Tailwind CSS y LowDB, y tiene licencia MIT.

Para qué sirve

9Router tiene más sentido cuando usas varias herramientas de programación con IA y varias fuentes de modelos al mismo tiempo.

Claude Code usa una cuenta de suscripción.
Codex o Cursor necesitan un endpoint OpenAI personalizado.
Cline, Continue o RooCode necesitan una API compatible con OpenAI.
Los proveedores gratuitos sirven para pruebas.
GLM, MiniMax o Kimi funcionan como respaldo barato.
Los modelos de mayor calidad se reservan para tareas difíciles.

Sin 9Router, cada herramienta necesita su propio endpoint, API key, nombre de modelo y estrategia de fallback. 9Router centraliza todo eso en una capa local.

API local:

`1`	`http://localhost:20128/v1`

Dashboard:

`1`	`http://localhost:20128/dashboard`

Instalación rápida

Para uso local:

1
2

npm install -g 9router
9router

Desde el código fuente:

git clone https://github.com/decolua/9router.git
cd 9router
cp .env.example .env
npm install
PORT=20128 NEXT_PUBLIC_BASE_URL=http://localhost:20128 npm run dev

Modo producción:

1
2

npm run build
PORT=20128 HOSTNAME=0.0.0.0 NEXT_PUBLIC_BASE_URL=http://localhost:20128 npm run start

El paquete npm requiere Node.js >=18.0.0. En VPS o Docker, configura JWT_SECRET, INITIAL_PASSWORD, DATA_DIR y API_KEY_SECRET.

Conectar herramientas de programación

Configuración típica:

1
2
3

Base URL: http://localhost:20128/v1
API Key: copiada desde el dashboard de 9Router
Model: nombre de modelo o combo configurado en 9Router

Para Codex CLI:

export OPENAI_BASE_URL="http://localhost:20128"
export OPENAI_API_KEY="your-9router-api-key"

codex "your prompt"

Para Cline, Continue o RooCode, elige OpenAI Compatible:

1
2
3

Base URL: http://localhost:20128/v1
API Key: your-9router-api-key
Model: cc/claude-opus-4-7

Los nombres dependen de los proveedores conectados, por ejemplo cc/, cx/, gh/, glm/, minimax/, kr/ y vertex/.

RTK Token Saver

En programación con IA, muchas veces lo que más tokens consume son salidas de herramientas:

git diff
git status
grep
find
ls
tree
logs
listas largas de archivos

RTK Token Saver comprime esas salidas antes de enviarlas al modelo. El proyecto afirma que puede ahorrar 20%-40% de tokens de entrada en muchas solicitudes.

La ventaja es que no tienes que cambiar de herramienta ni de modelo. Aun así, para logs críticos o contenido completo de archivos, conviene probar primero que la calidad de respuesta no baje.

Fallback automático

Puedes ordenar modelos por prioridad:

1
2
3

1. Modelo de suscripción
2. API barata
3. Proveedor gratuito

Ejemplo:

1
2
3

1. cc/claude-opus-4-7
2. glm/glm-5.1
3. kr/claude-sonnet-4.5

El fallback reduce interrupciones, pero cambia la consistencia de salida. Para refactors grandes, migraciones o tareas sensibles, es mejor fijar un modelo principal.

Cuidado con proveedores gratuitos

Kiro, OpenCode Free y Vertex pueden ser útiles, pero sus reglas cambian. Verifica siempre si el uso es gratuito, si hay límites regionales, si se permite usar herramientas de terceros, si puede haber rate limits o bloqueos, y cuándo caduca la cuota.

9Router enruta solicitudes; no cambia las condiciones del proveedor.

Despliegue local

Para uso personal, basta con escuchar en localhost. Si lo llevas a un VPS o LAN, cambia la contraseña por defecto, configura JWT_SECRET y API_KEY_SECRET, no expongas el dashboard directamente, y exige Bearer API key en /v1/*.

docker run -d \
  --name 9router \
  -p 20128:20128 \
  --env-file ./.env \
  -v 9router-data:/app/data \
  -v 9router-usage:/root/.9router \
  9router

Resumen

9Router es una puerta de enlace local para herramientas de programación con IA. Unifica Claude Code, Codex, Cursor y Cline en http://localhost:20128/v1, y gestiona selección de modelo, traducción de formatos, compresión de tokens, cuotas y fallback.

Es más útil para usuarios intensivos que ya alternan entre varios proveedores. Empieza con una herramienta y un proveedor, y añade combos poco a poco.

Referencias

DeepSeek-TUI: ejecuta un agente de programación DeepSeek en la terminal

Fri, 08 May 2026 13:41:15 +0800

DeepSeek-TUI es un agente de programación con IA que corre en la terminal. Está diseñado alrededor de modelos DeepSeek V4 y se inicia con el comando deepseek. Dentro de una TUI puede leer y editar archivos, ejecutar comandos shell, buscar en la web, gestionar git, conectar servidores MCP y coordinar subagentes.

Es más un espacio de trabajo de terminal que un chat CLI simple. Combina lectura de código, edición de archivos, comandos, diagnósticos, recuperación de sesión y rollback del workspace.

El repositorio está escrito principalmente en Rust y usa licencia MIT.

Para quién es

Sirve para desarrolladores que prefieren trabajar en terminal y quieren usar modelos DeepSeek en tareas locales reales.

Cambios de código y análisis de proyectos.
Trabajo sin abrir un IDE completo.
Lectura y modificación de un workspace local.
Modos Plan, Agent y YOLO.
Guardar y reanudar sesiones largas.
Revertir cambios del workspace.
Integrar MCP, diagnósticos LSP, HTTP/SSE runtime API y skills.

Para preguntas simples, un cliente web o CLI ligero basta. DeepSeek-TUI tiene más sentido cuando el modelo debe formar parte del flujo de desarrollo local.

Instalación

Con npm:

1
2
3

npm install -g deepseek-tui
deepseek --version
deepseek --model auto

El paquete npm es un instalador/wrapper que descarga binarios Rust precompilados. Requiere Node.js >=18.

Con Cargo:

1
2

cargo install deepseek-tui-cli --locked
cargo install deepseek-tui --locked

Con Homebrew:

1
2

brew tap Hmbown/deepseek-tui
brew install deepseek-tui

También hay binarios en GitHub Releases para Linux x64/ARM64, macOS x64/ARM64 y Windows x64.

Docker:

docker run --rm -it \
  -e DEEPSEEK_API_KEY \
  -v "$PWD:/workspace" \
  ghcr.io/hmbown/deepseek-tui:latest

Configurar la API Key

En el primer inicio, DeepSeek-TUI pide la API key y la guarda en:

`1`	`~/.deepseek/config.toml`

También puedes configurarla así:

1
2

deepseek auth set --provider deepseek
deepseek auth status

O usar variable de entorno:

1
2

export DEEPSEEK_API_KEY="YOUR_KEY"
deepseek

Comprueba la instalación:

`1`	`deepseek doctor`

Para borrar la clave guardada:

`1`	`deepseek auth clear --provider deepseek`

Auto mode

`1`	`deepseek --model auto`

En la TUI:

`1`	`/model auto`

Auto mode decide dos cosas:

Modelo: deepseek-v4-flash o deepseek-v4-pro
Thinking: off, high o max

Antes del turno real, hace una llamada pequeña de enrutamiento para analizar la petición y el contexto. Las tareas simples pueden usar Flash con thinking desactivado; tareas complejas pueden subir a Pro o mayor thinking.

auto es local a DeepSeek-TUI. La API upstream recibe el modelo concreto elegido.

Modos

Modo	Uso
Plan	Exploración y planificación de solo lectura
Agent	Modo interactivo con aprobaciones
YOLO	Autoaprobación en workspaces confiables

YOLO es rápido pero riesgoso. Úsalo solo en ramas temporales o directorios de prueba.

Herramientas

Incluye lectura/escritura de archivos, apply patch, shell, git, web search/browse, subagentes, MCP, diagnósticos LSP, guardado/reanudación de sesiones, rollback del workspace, cola de tareas durable, HTTP/SSE runtime API y sistema de skills.

Los diagnósticos LSP ayudan a devolver errores de rust-analyzer, pyright, typescript-language-server, gopls o clangd al modelo después de editar. El rollback usa snapshots side-git y comandos como /restore y revert_turn, pero los commits normales de git siguen siendo importantes.

Comandos comunes

deepseek
deepseek "explain this function"
deepseek --model deepseek-v4-flash "summarize"
deepseek --model auto "fix this bug"
deepseek --yolo
deepseek auth set --provider deepseek
deepseek doctor
deepseek doctor --json
deepseek models
deepseek sessions
deepseek resume --last
deepseek resume <SESSION_ID>
deepseek fork <SESSION_ID>
deepseek serve --http
deepseek serve --acp
deepseek pr <N>
deepseek mcp list
deepseek mcp validate
deepseek update

Zed y ACP

{
  "agent_servers": {
    "DeepSeek": {
      "type": "custom",
      "command": "deepseek",
      "args": ["serve", "--acp"],
      "env": {}
    }
  }
}

El README indica que ACP permite nuevas sesiones y respuestas a prompts, pero la edición con herramientas y la repetición de checkpoints aún no están expuestas.

Configuración y proveedores

Configuración de usuario:

`1`	`~/.deepseek/config.toml`

Overlay de proyecto:

`1`	`<workspace>/.deepseek/config.toml`

Campos como api_key, base_url, provider y mcp_config_path no se permiten en el overlay del proyecto.

Endpoint compatible con OpenAI:

1
2

deepseek auth set --provider openai --api-key "YOUR_OPENAI_COMPATIBLE_API_KEY"
OPENAI_BASE_URL="https://openai-compatible.example/v4" deepseek --provider openai --model glm-5

Ollama:

1
2

ollama pull deepseek-coder:1.3b
deepseek --provider ollama --model deepseek-coder:1.3b

Resumen

DeepSeek-TUI reúne DeepSeek V4, TUI, llamadas a herramientas, diagnósticos LSP, recuperación de sesiones, rollback, MCP y skills en un flujo Rust de terminal. No es el cliente más ligero, pero su valor está en pasar del chat al desarrollo local ejecutable.

Referencias

24 consejos de Claude Code: modo plan, rewind, CLAUDE.md, Skills, Agents y plugins

Fri, 08 May 2026 08:54:14 +0800

Claude Code no es solo una caja de chat. Se parece más a un Agent de programación que puede entrar en un directorio de proyecto, leer y escribir archivos, ejecutar comandos y mantener contexto.

Si solo le das un requisito y esperas código, pronto aparecen problemas: el plan no queda claro, los permisos se repiten, el contexto crece, el resultado no convence, no sabes cómo volver atrás y no hay un lugar estable para reglas del proyecto.

Estos son consejos prácticos para quienes empiezan con Claude Code.

Empieza dentro del directorio del proyecto

Claude Code funciona mejor cuando se inicia dentro del directorio del proyecto, no desde una terminal cualquiera.

Crea una carpeta de proyecto, entra en ella, abre la línea de comandos e inicia Claude Code:

claude

Si al entrar por primera vez pregunta si confías en la carpeta actual, confirma antes de seguir. Así podrá leer archivos, crear archivos y ejecutar operaciones alrededor del proyecto.

Una práctica sencilla es pedirle que cree una web personal de fotógrafo. Es una tarea visual, permite inspeccionar el resultado y sirve para practicar generación de archivos, comandos, rewind y refactorización.

Usa modo plan para aclarar la dirección

Ante tareas complejas, Claude Code puede entrar en modo plan. Su función es discutir requisitos, dividir pasos y pedir aprobación antes de ejecutar.

Tras escribir un plan, suelen aparecer opciones como:

Aprobar el plan y permitir automáticamente herramientas de edición posteriores.
Aprobar el plan, pero pedir confirmación manual para futuras ediciones.
Pausar y seguir discutiendo el plan con Claude Code.

Si la tarea está clara, aprueba y continúa. Si no, pídele que complete el plan: estilo de página, stack técnico, estructura de carpetas, interacciones y criterios de aceptación.

El modo plan reduce retrabajo. Si el Agent empieza directamente, puede crear muchos archivos rápido; si la dirección era incorrecta, luego todo se vuelve más difícil de corregir.

Cambia de modo con Shift + Tab

En Claude Code, Shift + Tab permite cambiar entre modos de trabajo. Se usa a menudo para entrar en modo plan o para cambiar a un modo de aprobación automática de edición.

Hábitos recomendados:

Proyecto nuevo, función nueva o cambio grande: primero modo plan.
Cambio pequeño o arreglo claro: ejecutar directamente.
Borrado, reemplazos masivos o instalación de dependencias: mantener confirmación humana.

En modo plan, Claude Code puede preguntar detalles del proyecto. Usa flechas para elegir opciones y Enter para confirmar. Después de enviar feedback, actualizará el plan.

No abras todos los permisos

Cuando Claude Code ejecuta comandos, edita archivos o inicia programas, puede pedir permisos.

Opciones comunes:

Permitir solo esta vez.
Permitir el mismo tipo de comando en esta sesión.
Rechazar o pausar.

Para abrir una página local, iniciar un servidor de desarrollo o revisar archivos, aprueba según necesidad. Pero no uses durante mucho tiempo un modo de “permitir todo” solo por comodidad.

La aprobación total automática solo tiene sentido en tareas de bajo riesgo, muy claras y con respaldo Git. En el uso diario, conserva confirmación humana para borrar, sobrescribir carpetas, instalar dependencias, usar red, hacer commits o ejecutar scripts.

Ejecuta comandos locales en modo terminal

Claude Code puede entrar en modo de comandos de terminal y ejecutar comandos locales.

Por ejemplo, después de generar una página, puedes abrir un archivo HTML con:

`1`	`start index.html`

start es un comando de Windows para abrir archivos. Es más rápido que buscar el archivo manualmente.

El modo terminal sirve para:

Abrir páginas generadas.
Ver contenido de directorios.
Iniciar servidores locales.
Ejecutar pruebas o builds.

Pero los comandos de alto riesgo siguen requiriendo cuidado: borrado recursivo, mover directorios, sobrescrituras masivas y cambios de entorno.

Usa rewind cuando el resultado se desvía

Si la página o el código que hizo Claude Code no es lo que quieres y cada corrección lo empeora, usa rewind temprano.

Rewind puede devolver conversación o código a un punto anterior. Opciones comunes:

Revertir código y conversación.
Revertir solo conversación.
Revertir solo código.
Comprimir contenido anterior como resumen.
Cancelar.

Cuando la dirección se desvió claramente, conviene volver código y conversación juntos. Así contexto y archivos regresan a un estado más limpio.

Ten en cuenta que el rewind de Claude Code normalmente cubre archivos creados o modificados con herramientas internas. Archivos creados por comandos externos quizá no se reviertan por completo. Para proyectos importantes, usa Git.

Escribe prompts largos en un editor

No metas requisitos complejos en una sola línea.

Si el sistema permite editar un prompt largo en un editor, úsalo, guarda y luego envíalo a Claude Code.

Un prompt largo debería aclarar:

Objetivo.
Stack técnico.
Qué no debe hacerse.
Qué archivos deben conservarse.
Cómo verificar el resultado.
Criterios de aceptación.

Por ejemplo, si quieres refactorizar una página HTML a un stack más moderno, no escribas solo “refactoriza”. Explica estructura por componentes, preservación visual, diseño responsive y pide ejecutar una comprobación de build.

Recupera sesiones después de salir

Si necesitas salir de Claude Code, hazlo normalmente. Luego vuelve al mismo directorio y arranca otra vez:

claude

Si el historial anterior no aparece, usa comandos de historial para ver sesiones recientes y cargar la sesión anterior.

Esto sirve para continuar trabajo interrumpido. Pero no uses el historial como única memoria. Reglas del proyecto, stack, comandos comunes y notas deben estar en archivos del proyecto.

Guarda reglas del proyecto en CLAUDE.md

CLAUDE.md es un archivo de memoria importante para Claude Code. Normalmente está en la raíz del proyecto y registra reglas, stack, estructura de carpetas y restricciones de colaboración.

Puedes inicializarlo con:

/init

CLAUDE.md sirve para registrar:

Objetivos del proyecto.
Stack técnico.
Comandos de inicio, prueba y build.
Estructura de directorios.
Estilo de código.
Acciones prohibidas.
Reglas de commit y despliegue.

En cada conversación, Claude Code puede usar estas reglas como parte del contexto. Piensa en él como un manual del proyecto.

Una prueba sencilla es añadir una regla evidente en CLAUDE.md y luego preguntar algo. Si la respuesta sigue la regla, leyó la memoria del proyecto.

Usa @ para referenciar archivos

En el cuadro de entrada, @ permite seleccionar archivos o Agents y añadirlos al contexto actual.

Sirve para:

Hacer que Claude Code lea un archivo de configuración.
Pedir cambios en una página concreta.
Continuar según CLAUDE.md u otro documento.
Decir explícitamente “mira solo este archivo, no adivines la estructura”.

Comparado con pegar el contenido del archivo, @ es más claro y menos propenso a omisiones.

Revisa y comprime contexto

Tras una conversación larga, el contexto crece. Si se vuelve demasiado largo, el modelo puede ralentizarse o ignorar detalles antiguos.

Usa:

`1`	`/context`

Si el contexto ya es largo, comprime el historial:

`1`	`/compact`

Si aun así el efecto es malo, limpia el contexto actual:

/clear

Después de limpiar, Claude Code todavía puede entender parte del proyecto mediante archivos, CLAUDE.md y el directorio actual, pero no conserva todo el historial de conversación.

Una regla útil: abre una conversación nueva al terminar una tarea, escribe reglas del proyecto en CLAUDE.md, y no acumules discusión temporal para siempre en un solo chat.

Skills: convierte flujos fijos en instrucciones

Skills son instrucciones reutilizables para Claude Code. No son prompts de una sola vez, sino flujos de tarea empaquetados.

Por ejemplo, si generas informes semanales a menudo, crea una Skill de informe semanal con:

Información de entrada necesaria.
Formato de salida.
Tono y estructura.
Qué debe conservarse.
Qué no debe inventarse.

Las Skills suelen contener name, description e instrucciones detalladas. Al instalarlas en el directorio global de Skills, Claude Code puede reconocerlas y cargarlas cuando la tarea encaja.

Candidatos adecuados:

Informes semanales.
Plantillas de revisión de código.
Organización de documentos.
Procesamiento de imágenes por lotes.
Artículos con formato fijo.
Flujos de inicialización de proyectos.

Si copias el mismo prompt muchas veces, conviértelo en Skill.

Agents: delega subtareas a asistentes independientes

Agents no son lo mismo que Skills.

Una Skill es un manual de instrucciones. Un Agent se parece más a un asistente independiente que trabaja fuera de la conversación principal y devuelve resultados.

Su valor está en aislar contexto. Para una revisión de código, puedes crear un Agent de solo lectura que lea el proyecto y entregue un informe sin modificar archivos. Así no contamina la conversación principal y reduce riesgos.

Al crear un Agent, considera:

Si será de proyecto o de usuario.
Si Claude Code debe generar la configuración.
Qué herramientas puede usar.
Qué modelo usará.
Si guardará memoria.
Si el prompt del Agent es claro.

Para Agents de auditoría de código, da solo permisos de lectura. Primero que entregue un informe; luego la conversación principal decide si cambia código.

Plugins: empaqueta Skills, Agents, MCP y Hooks

Los plugins son paquetes de capacidad más completos. Pueden incluir:

Skills
Agents
MCP
Hooks

Frente a una Skill aislada, un plugin sirve mejor para capacidades de conjunto. Un plugin de diseño frontend puede empaquetar estética de página, reglas de layout, hábitos de componentes y Agents relacionados.

Al instalar plugins, suele haber opciones:

Directorio de usuario, efectivo para todos los proyectos.
Directorio de proyecto, compartido con el proyecto.
Directorio local del proyecto, solo efectivo en tu ordenador.

Para capacidades personales frecuentes, usa el directorio de usuario. Para acuerdos de equipo, usa el proyecto. Para pruebas temporales, usa instalación local.

Los plugins mejoran tareas concretas

En generación de páginas frontend, un plugin suele ser más estable que un prompt desnudo.

Por ejemplo, para “crear una web personal de fotógrafo”, un prompt normal puede crear una página aceptable. Si usas explícitamente un plugin de diseño frontend, la estructura, jerarquía visual, espaciado, color y acabado suelen mejorar.

Esto no reemplaza el criterio humano. Lo razonable es dejar que el plugin genere un primer borrador mejor y luego ajustar detalles manualmente.

Un flujo de trabajo más estable

Combinando todo lo anterior, queda un flujo más estable:

Inicia claude dentro del directorio del proyecto.
Discute requisitos primero en modo plan.
Confirma stack y criterios de aceptación antes de aprobar.
Mantén confirmación manual para acciones de alto riesgo.
Usa modo terminal para previsualización y pruebas.
Usa rewind cuando el resultado se desvíe.
Escribe reglas en CLAUDE.md.
Revisa y comprime contexto en conversaciones largas.
Convierte flujos repetidos en Skills.
Delega inspección, investigación y análisis a Agents de solo lectura.
Usa plugins para tareas de dominio específico.
Mantén puntos de commit Git en proyectos importantes.

Así Claude Code será mucho más estable que enviar una frase y esperar generación.

Resumen

La eficiencia de Claude Code no viene solo del modelo, sino también del control del flujo.

El modo plan define la dirección, los permisos controlan el riesgo, rewind reduce retrabajo, CLAUDE.md guarda reglas del proyecto, /context, /compact y /clear gestionan contexto, Skills reutilizan flujos, Agents aíslan subtareas y plugins empaquetan capacidades completas.

La mejor forma de usar Claude Code es dejar que avance dentro de límites claros, no entregarle todo el proyecto de una vez.

opencode, Claude Code y Codex: diferencias y guía de herramientas open source de programación con IA

Fri, 08 May 2026 08:33:37 +0800

opencode es un AI Coding Agent open source de anomalyco. Su posicionamiento es directo: dar a los desarrolladores un asistente de código programable, extensible y capaz de conectarse a varios proveedores de modelos dentro de la terminal.

Si lo comparamos con Claude Code y Codex, los tres resuelven una misma clase de problema: llevar la IA a bases de código reales para entender contexto, modificar archivos, ejecutar comandos y correr pruebas. Pero su orientación de producto es distinta.

opencode pone más énfasis en open source, soporte de múltiples modelos y TUI de terminal. Claude Code enfatiza el ecosistema de modelos de Anthropic y la colaboración de ingeniería local. Codex es el AI coding agent de OpenAI, disponible desde la terminal, IDEs, Codex app y tareas en la nube.

Para quién es opencode

opencode encaja mejor con estos tipos de desarrolladores:

Quienes quieren completar cambios de código, análisis de proyectos y tareas de ingeniería desde la terminal.
Quienes no quieren que su AI Coding Agent dependa de un único proveedor de modelos.
Quienes prefieren herramientas open source y quieren auditarlas, ampliarlas o construir sobre ellas.
Quienes ya están cómodos con Neovim, TUI y flujos de línea de comandos.
Quienes quieren controlar en el futuro el mismo agente de programación desde una app de escritorio, móvil u otros clientes.

Su objetivo no es crear otra ventana de chat, sino poner capacidades de programación con IA dentro de la terminal y los directorios de proyecto que los desarrolladores ya usan.

Instalación

El README oficial ofrece varias formas de instalación.

# Instalación directa
curl -fsSL https://opencode.ai/install | bash

# npm
npm i -g opencode-ai@latest

# Windows
scoop install opencode
choco install opencode

# macOS y Linux
brew install anomalyco/tap/opencode
brew install opencode

# Arch Linux
sudo pacman -S opencode
paru -S opencode-bin

# Otros métodos
mise use -g opencode
nix run nixpkgs#opencode

El README oficial también recomienda eliminar versiones anteriores a 0.1.x antes de instalar, para evitar problemas causados por restos de versiones antiguas.

El script de instalación elige el directorio de instalación con esta prioridad:

$OPENCODE_INSTALL_DIR
$XDG_BIN_DIR
$HOME/bin
$HOME/.opencode/bin

Si necesitas especificar una ruta, puedes usar:

1
2

OPENCODE_INSTALL_DIR=/usr/local/bin curl -fsSL https://opencode.ai/install | bash
XDG_BIN_DIR=$HOME/.local/bin curl -fsSL https://opencode.ai/install | bash

La app de escritorio sigue en Beta

Además de la herramienta de línea de comandos, opencode también ofrece una app de escritorio, actualmente marcada como Beta. Se puede descargar desde GitHub Releases o opencode.ai/download.

La versión de escritorio cubre estas plataformas:

Plataforma	Archivo
macOS Apple Silicon	`opencode-desktop-mac-arm64.dmg`
macOS Intel	`opencode-desktop-mac-x64.dmg`
Windows	`opencode-desktop-windows-x64.exe`
Linux	`.deb`, `.rpm` o `.AppImage`

En macOS y Windows también se puede instalar la app de escritorio con gestores de paquetes.

# macOS
brew install --cask opencode-desktop

# Windows
scoop bucket add extras
scoop install extras/opencode-desktop

Dos modos Agent integrados

opencode incluye dos Agent integrados, que se pueden cambiar con la tecla Tab.

build es el modo predeterminado. Tiene permisos completos de desarrollo y sirve para editar código directamente, ejecutar comandos y avanzar en tareas de ingeniería.

plan es el modo de solo lectura. Es más adecuado para analizar bases de código desconocidas, entender la estructura del proyecto y preparar un plan de cambios. Por defecto rechaza ediciones de archivos y pregunta antes de ejecutar comandos bash.

Además, opencode incluye un sub-Agent general para búsquedas complejas y tareas de varios pasos. Los usuarios pueden invocarlo escribiendo @general en un mensaje.

Este diseño es bastante práctico: antes de actuar, usa plan para entender el proyecto; cuando haga falta cambiar código, cambia a build. En repositorios grandes, separar permisos de lectura y escritura ayuda a reducir errores.

Qué es Codex

Codex es el AI coding agent de OpenAI para ayudar a desarrolladores a escribir código, revisar código, corregir bugs y entregar tareas de ingeniería.

A diferencia de una herramienta simple de autocompletado, Codex se parece más a un Agent capaz de operar sobre una base de código. Puede trabajar contigo en herramientas locales y también puede recibir tareas delegadas para ejecutarlas en la nube. Los materiales oficiales de OpenAI describen Codex como disponible desde varias superficies, incluyendo CLI, IDEs, Codex app y flujos en la nube de ChatGPT/Codex.

Para desarrolladores, Codex tiene varios puntos importantes:

Puede leer bases de código, editar archivos, ejecutar comandos y correr pruebas.
Soporta varias interfaces, incluyendo terminal, IDE, app y nube.
Encaja con corrección de bugs, desarrollo de funciones, refactorización, migraciones, revisión de código y generación de pruebas.
Está más ligado a cuentas, modelos y ecosistema de producto de OpenAI.
Las tareas en la nube sirven para ejecutar en paralelo varias tareas de ingeniería relativamente bien definidas.

Si opencode se parece más a un framework abierto de agente en terminal, Codex se parece más a un banco de trabajo completo de programación con IA ofrecido por OpenAI: colaboración local, delegación en la nube y flujos de ingeniería más largos para equipos.

Diferencias principales

opencode, Claude Code y Codex son herramientas de programación con IA, pero la elección se entiende mejor mirando estas dimensiones.

Herramienta	Posicionamiento central	Ventajas principales	Mejor para
`opencode`	AI Coding Agent open source	Open source, múltiples modelos, TUI, arquitectura cliente/servidor	Desarrolladores que quieren una cadena de herramientas abierta, modelos reemplazables y un flujo centrado en terminal
`Claude Code`	Herramienta de programación de línea de comandos de Anthropic	Experiencia con modelos Claude, comprensión de código, contexto largo, colaboración en tareas de ingeniería	Desarrolladores que ya usan el ecosistema Claude/Anthropic y quieren avanzar tareas de código locales
`Codex`	AI coding agent de OpenAI	CLI, IDE, Codex app, tareas en la nube, flujos multi-Agent	Equipos que ya usan ChatGPT/OpenAI y quieren combinar colaboración local con delegación en la nube

En resumen, las palabras clave de opencode son “apertura y reemplazabilidad”; las de Claude Code son “ecosistema Claude y agente local de ingeniería”; y las de Codex son “ecosistema OpenAI y colaboración desde múltiples entradas”.

Diferencias con Claude Code

El FAQ oficial de opencode lo compara directamente con Claude Code. Ambos son muy parecidos en capacidad, pero las diferencias principales son estas.

Primero, opencode es un proyecto 100% open source, alojado en GitHub y publicado con MIT license.

Segundo, opencode no depende de un único proveedor de modelos. Recomienda los modelos ofrecidos a través de OpenCode Zen, pero también puede trabajar con Claude, OpenAI, Google o modelos locales. Para desarrolladores, esto significa que cuando cambien el costo, la capacidad o la disponibilidad de los modelos, no quedarán atados a una sola plataforma.

Tercero, opencode incluye soporte LSP opcional. Para autocompletado, navegación, diagnósticos y comprensión del proyecto, LSP es una base muy importante.

Cuarto, opencode pone más énfasis en TUI. Está creado por usuarios de Neovim y los creadores de terminal.shop, así que el foco del producto está claramente en la experiencia de terminal.

Quinto, opencode usa una arquitectura cliente/servidor. Esto significa que opencode puede ejecutarse en tu computadora y, en el futuro, controlarse desde una TUI, una app de escritorio, una app móvil u otros clientes. La TUI es solo una de las posibles interfaces.

Cuándo elegir opencode, Claude Code o Codex

Si ya usas Claude Code o Codex, opencode no tiene por qué reemplazarlos de inmediato. Una forma más razonable de verlo es que ofrece una opción abierta, con modelos reemplazables y orientada a la terminal.

Conviene considerar primero opencode cuando:

Quieres que tu herramienta de programación con IA sea lo más open source posible.
No quieres atar tu flujo de trabajo a un proveedor de modelos.
Quieres probar Claude, OpenAI, Google o modelos locales con la misma herramienta.
Te gustan los flujos TUI y no quieres que una app de escritorio o web interrumpa tu flujo principal.
Te interesa el potencial de control remoto de una arquitectura cliente/servidor.

Conviene considerar primero Claude Code cuando:

Usas principalmente modelos Claude.
Te importan el contexto largo, la comprensión de código y la colaboración en tareas de ingeniería complejas.
Quieres avanzar cambios, pruebas y refactorizaciones dentro de un repositorio local.
Confías más en la experiencia predeterminada de Claude Code diseñada por Anthropic.

Conviene considerar primero Codex cuando:

Ya usas ChatGPT o el ecosistema de cuentas de OpenAI.
Quieres un mismo coding agent en terminal, IDE, app de escritorio y tareas en la nube.
Quieres delegar en la nube correcciones de bugs, desarrollo de funciones, migraciones o generación de pruebas relativamente claras, en paralelo.
Necesitas revisión de código, tareas en segundo plano, colaboración de equipo y flujos multi-Agent.

Si priorizas una experiencia oficial de extremo a extremo, configuración predeterminada de modelos, administración empresarial e integraciones listas, Claude Code o Codex pueden ser más cómodos. Si priorizas control, apertura y enfoque provider-agnostic, opencode merece atención.

Puntos a tener en cuenta

opencode, Claude Code y Codex avanzan rápido. Los releases de GitHub, comandos de instalación, nombres de archivos de escritorio, disponibilidad de modelos y permisos de planes pueden cambiar. Antes de instalar o elegir, conviene revisar directamente el README, la documentación y las páginas de releases oficiales de cada herramienta.

Además, la app de escritorio de opencode sigue marcada como Beta, así que no conviene tratarla por defecto como una herramienta estable de producción. Para tareas de ingeniería diarias, la versión de terminal sigue siendo la entrada principal.

Visto como tendencia de herramientas, opencode representa la dirección de cadena de herramientas abierta para AI Coding Agents: modelos reemplazables, clientes reemplazables y una capacidad central de agente lo más abierta posible. Codex y Claude Code se parecen más a modelos convertidos por sus empresas en superficies de producto completas para coding agents. Para desarrolladores, ambas rutas probablemente coexistirán durante mucho tiempo.

Referencias

opencode GitHub: https://github.com/anomalyco/opencode
sitio oficial de opencode: https://opencode.ai
documentación de opencode: https://opencode.ai/docs
opencode Releases: https://github.com/anomalyco/opencode/releases
OpenAI Codex: https://openai.com/codex/
Using Codex with your ChatGPT plan: https://help.openai.com/en/articles/11369540-codex-in-chatgpt
OpenAI Codex CLI Getting Started: https://help.openai.com/en/articles/11096431-openai-codex-ci-getting-started

DeepSeek V4 Flash para una demo de juego en Godot: ¿hasta dónde llegan unos centavos?

Wed, 06 May 2026 09:22:18 +0800

¿Puede DeepSeek V4 Flash encargarse del desarrollo de una demo de juego en Godot?

El foco es simple: ¿puede crear una pequeña demo de Godot que se ejecute, se observe y tenga efectos físicos?

La respuesta corta es sí. La calidad no es comercial, pero ya es suficiente para prototipos de gameplay y demos de interacción física. Más importante aún, el costo es muy bajo, lo que lo hace adecuado para validar ideas rápidamente.

Rendimiento de la demo

El foco de esta demo es la interacción física.

Varios efectos visibles incluyen:

La cuerda puede cortarse.
La caja cae al suelo.
Después de aumentar la masa, las colisiones de la caja se vuelven más contundentes.
La cuerda muestra elasticidad evidente.
Después de ajustar fricción y elasticidad, la caja muestra deslizamiento y rebote claros.

Por lo que presenta, esto ya no es solo “unos scripts de Godot generados”. Es un pequeño prototipo que puede ejecutarse y mostrar comportamiento físico observable.

Usabilidad

El valor de esta demo es que puede ejecutarse, verse y modificarse. No es un juego completo ni un proyecto de ingeniería listo para comercialización directa, pero ya demuestra varias cosas:

DeepSeek V4 Flash puede entender el objetivo básico de una demo de Godot.
Un AI Agent puede convertir requisitos en un proyecto ejecutable.
Tareas no web como interacción física en Godot están entrando en una etapa de prototipado de bajo costo.
Para desarrolladores individuales, puede convertir rápidamente una idea en algo visible.

Si el objetivo es construir un juego formal, claramente no basta. Pero si el objetivo es verificar si una idea de gameplay es interesante o si el efecto físico aproximado puede hacerse, esta demo ya es usable.

Significado del costo

La parte más notable no es lo pulidos que son los visuales, sino el costo.

Si una demo física de Godot puede producir una versión ejecutable con costos de modelo de unos pocos centavos, su significado no es reemplazar el desarrollo profesional de videojuegos. Es reducir de forma drástica el costo de prueba y error de prototipos.

Antes, validar una pequeña idea de juego normalmente requería saber Godot, escribir scripts, configurar escenas y ajustar parámetros físicos. Ahora un AI Agent puede generar primero una versión ejecutable, y los humanos pueden juzgar si la dirección tiene sentido.

Para desarrolladores indie, este tipo de experimentación de bajo costo es útil:

Validar rápidamente conceptos de gameplay.
Generar demos temporales para que otros las vean.
Explorar APIs de Godot y el sistema físico.
Convertir ideas en un primer proyecto ejecutable.
Reducir el costo de código escrito a mano antes de aclarar la dirección.

Rendimiento de DeepSeek V4 Flash

Vale la pena notar que el modelo usado aquí es DeepSeek V4 Flash, no un modelo insignia más caro y pesado.

Funciona bien en el rol de modelo de prototipado de bajo costo. No es el más fuerte, estable ni adecuado para entregar ingeniería de producción, pero resulta atractivo en escenarios sensibles al presupuesto donde el objetivo es probar rápidamente una dirección.

Escenarios adecuados

DeepSeek V4 Flash + Agent + Godot encaja mejor con estas tareas:

Pequeños prototipos de gameplay.
Demos de efectos físicos.
Validación de conceptos de UI o interacción.
Ejemplos de enseñanza.
Ayuda para entender la estructura de proyectos Godot.
Generar un primer proyecto ejecutable.

Es menos adecuado para asumir directamente estas tareas:

Arquitectura de juego grande.
Controladores de personaje complejos.
Sincronización de red.
Código central para proyectos comerciales.
Simulación física de alta precisión.
Envío automático sin pruebas humanas.

En otras palabras, sirve como primer borrador y banco de pruebas, no como responsable de ingeniería de producción.

Qué demuestra esto

Esto muestra que AI coding sigue expandiéndose desde sitios web, scripts y APIs backend hacia desarrollo de juegos y prototipado interactivo.

El desarrollo de juegos solía tener una barrera alta de entrada, especialmente cuando motores, scripts, gestión de assets y sistemas físicos se mezclaban. Los principiantes podían atascarse fácilmente. Ahora modelos más herramientas Agent pueden configurar primero el proyecto, permitiendo a los desarrolladores centrarse en juzgar el gameplay y ajustar efectos.

Esto puede traer tres cambios:

Primero, los prototipos de juegos se vuelven más baratos. Muchas ideas ya no tienen que esperar a un desarrollo completo para validarse; pueden convertirse primero en demos ejecutables.

Segundo, los desarrolladores indie pueden estar más dispuestos a experimentar. Personas que no conocen Godot pueden aun así usar IA para tocar la estructura del proyecto y el flujo básico.

Tercero, la estabilidad del modelo se vuelve más importante. El desarrollo de juegos no consiste solo en que el código corra. El efecto también debe ser razonable, la sensación debe ser normal y los parámetros deben ser controlables. En el futuro, modelos que combinen mejor visuales reales y estado de ejecución serán más adecuados para este tipo de tarea.

Resumen

DeepSeek V4 Flash para una demo de Godot se puede resumir en una frase: no perfecto, pero lo bastante barato, rápido y adecuado para prototipar.

Todavía está lejos de los juegos comerciales, pero si el objetivo es validar una pequeña idea de juego a costo extremadamente bajo, ya tiene valor.

Para desarrolladores individuales, el uso más realista no es entregar todo el juego a la IA, sino dejar que la IA produzca primero un proyecto ejecutable mientras los humanos hacen juicio, compromisos y pulido. Usados así, modelos de bajo costo como DeepSeek V4 Flash se vuelven realmente atractivos.

Guía inicial de Codex App: instalación, sandbox, tareas paralelas, Skills y MCP

Wed, 06 May 2026 08:41:17 +0800

Codex App puede entenderse como un espacio de trabajo de tareas para programación con IA. No es un IDE tradicional ni solo una ventana de chat. Reúne multitarea, gestión de proyectos, permisos de sandbox, Git, ejecución en la nube, plugins, Skills, MCP y automatización en una sola interfaz.

Si ya usas Codex CLI, Claude Code, Cursor u otros coding agents, la parte más interesante de Codex App es que convierte “ejecutar varios agentes en paralelo” en un flujo de escritorio más claro.

Para qué sirve Codex App

El valor central de Codex App no es responder preguntas, sino permitir que la IA ejecute tareas de forma continua dentro de un directorio de proyecto:

Editar código, ejecutar comandos e iniciar servidores de desarrollo.
Gestionar múltiples proyectos y múltiples tareas.
Ejecutar tareas largas localmente o en la nube.
Llamar plugins, Skills y MCP para ampliar capacidades.
Gestionar cambios mediante Git, worktree y flujos PR.

OpenAI también posiciona Codex App como una interfaz para gestionar múltiples coding agents. Es adecuada para personas que necesitan avanzar varias tareas de programación a la vez, especialmente páginas frontend, scripts, apps pequeñas, documentación y flujos de automatización.

Preparación antes de instalar

Antes de usar Codex App, conviene preparar tres herramientas básicas:

Git
Node.js
VS Code o tu IDE preferido

Codex App soporta macOS y Windows. Después de instalar, inicia sesión con tu cuenta de ChatGPT. En el primer lanzamiento, puedes elegir tu escenario principal de uso, como programación o trabajo diario. Codex precargará algunos plugins y Skills según tus elecciones, y luego puedes ajustarlos en configuración y en el marketplace de plugins.

Las funciones principales en Windows y macOS son bastante parecidas, pero algunas capacidades de automatización del ordenador pueden depender de la plataforma y del soporte de plugins. Usa lo que tu versión actual muestre realmente.

Estructura de interfaz: proyectos, tareas y chats

Codex App usa un diseño clásico de tres columnas:

Izquierda: proyectos, tareas, historial de chats, plugins y entradas de automatización.
Centro: ventana de chat actual.
Derecha: archivos, navegador, terminal, resultados de ejecución y otros paneles.

Un proyecto normalmente corresponde a una carpeta local. Puedes abrir varios chats dentro del mismo proyecto, o abrir varios proyectos a la vez para que distintos agentes trabajen en paralelo.

La lista de tareas muestra distintos estados:

Running: el agente sigue ejecutando.
Waiting for approval: debes confirmar permisos, red, instalación de dependencias o una acción de alto riesgo.
Completed: la tarea terminó, y puedes inspeccionar el resultado o seguir preguntando.

Esto es más intuitivo que cambiar entre varias ventanas de terminal, y se adapta mejor a gestionar varias tareas de IA a la vez.

Sandbox y control de permisos

El sistema de permisos de Codex App se construye alrededor del sandbox. Por defecto, la carpeta actual del proyecto se convierte en el workspace principal del agente.

Los límites de permisos comunes incluyen:

Puede leer y modificar archivos dentro del directorio del proyecto.
Por defecto no puede modificar libremente archivos fuera del proyecto.
La red o comandos de alto riesgo están restringidos por defecto.
Cuando necesita acceso elevado, pide aprobación al usuario.

Un modo práctico es “auto review”: las acciones de bajo riesgo se permiten automáticamente, mientras que las acciones de alto riesgo siguen siendo confirmadas por el usuario. Esto reduce ventanas emergentes frecuentes y evita que operaciones peligrosas ocurran en silencio.

“Full access” debe habilitarse con cautela. Es adecuado cuando sabes exactamente qué necesita hacer el agente, el proyecto ya tiene respaldos Git y los archivos importantes tienen copias separadas. No se recomienda como valor diario permanente.

Contexto, modelos y cuotas

Codex App muestra el uso de contexto del chat actual. Cuanto más larga es la conversación y más historial contiene, más contexto necesita procesar el modelo.

Hábitos útiles:

Empezar un chat nuevo después de terminar una tarea.
Los chats largos pueden comprimirse manualmente, pero no trates la compresión como memoria perfecta.
Para tareas complejas, declara claramente objetivos, límites y criterios de aceptación.
No pegues de golpe logs, errores o archivos grandes e irrelevantes en un chat.

Para selección de modelos, ajusta la fuerza de razonamiento según la complejidad de la tarea. Ediciones simples, escritura y tareas repetitivas no siempre necesitan el modelo más fuerte. Migraciones de arquitectura, bugs difíciles y refactors entre archivos encajan mejor con modelos más potentes.

Si la interfaz tiene un modo rápido, recuerda que normalmente consume más cuota. Úsalo cuando la velocidad importe, pero no como valor diario predeterminado.

Generación de imágenes y entradas multimodales

Codex App puede aceptar imágenes y archivos como contexto, y puede llamar generación de imágenes en escenarios adecuados.

Esto es útil para proyectos frontend y de contenido. Por ejemplo, puedes pedir a Codex:

Corregir estilos de página según capturas.
Reemplazar imágenes inadecuadas en una web.
Generar imágenes de producto, imágenes de carrusel o assets de página.
Señalar qué debe cambiarse a partir de una captura de UI.

Un enfoque más eficiente no es decir solo “hazlo más bonito”, sino usar capturas y señalar problemas concretos, como “el espacio en esta tarjeta es demasiado grande”, “esta imagen no coincide con la escena del servicio” o “haz más clara el área del mapa”.

Steer: corregir dirección durante la ejecución

Steer puede entenderse como tomar control de la dirección durante la ejecución. Si el agente ya empezó pero notas que entendió mal, no siempre conviene esperar a que termine para corregirlo.

Puedes usar steering para insertar una nueva instrucción en el flujo de ejecución actual y hacer que Codex corrija el rumbo.

Buenos casos de uso para Steer incluyen:

El agente entendió mal el requisito.
El estilo de página generado es claramente incorrecto.
El plan actual es demasiado costoso o pesado.
Necesitas añadir una restricción clave temporalmente.

En general, mantén el comportamiento predeterminado en cola y usa Steer manualmente solo cuando se necesite intervención. Esto evita interrumpir tareas normales y aun así permite recuperar la dirección en momentos clave.

Modo plan y navegador integrado

Para tareas complejas, empieza con modo plan. En modo plan, Codex no modifica código de inmediato. Primero produce un plan y puede hacer preguntas clave con tarjetas.

Tareas adecuadas para modo plan incluyen:

Migración de frameworks, como pasar un proyecto React a Next.js.
Refactors grandes.
Funciones que involucran bases de datos, autenticación o despliegue.
Requisitos donde aún no has decidido la ruta técnica.

El panel derecho de Codex App puede abrir un navegador integrado para previsualizar el servidor local de desarrollo. Puedes anotar la página y dejar que Codex modifique una ubicación específica de UI. Este flujo de “mirar la página, hacer clic en la posición y pedir a la IA que la cambie” suele ser mejor para depuración frontend que descripciones puramente textuales.

Git, IDE y rollback de código

Codex App no es un IDE completo. Puede ver código y añadir anotaciones, pero la edición manual sigue siendo mejor en VS Code, Cursor, Windsurf u otro IDE.

Todo proyecto de Codex debería inicializar Git temprano:

Pedir a Codex que cree o revise .gitignore.
Hacer un commit al llegar a un estado usable.
Asegurar un punto de commit limpio antes de cada cambio grande.
Volver atrás con Git si no estás satisfecho.

Si haces rollback solo del historial de chat, el código no vuelve automáticamente. Un enfoque más seguro es devolver el chat al punto correcto y luego usar un hash de commit Git para devolver el código al estado correspondiente.

Worktree: desarrollo paralelo en varias direcciones

git worktree es especialmente adecuado para agentes paralelos en Codex App.

Crea varios directorios de trabajo independientes desde el mismo repositorio, cada uno correspondiente a una rama distinta. Esto permite que diferentes agentes trabajen en distintas carpetas al mismo tiempo sin sobrescribirse.

Uso típico:

Un worktree optimiza el componente de reseñas de clientes.
Un worktree ajusta información de tienda y diseño del mapa.
Fusionar ambas tareas de vuelta a main tras completarlas.
Eliminar worktrees temporales después de fusionar.

Esto es mucho más seguro que dejar que varios agentes modifiquen código en el mismo directorio. Si hay conflictos, revísalos y fusiónalos con flujos Git normales.

Entorno de ejecución en la nube

Codex puede trabajar no solo en tu máquina local, sino también en un entorno de nube.

La ejecución en la nube es adecuada cuando:

Estás fuera y solo tienes un teléfono.
Quieres que los agentes ejecuten tareas largas en segundo plano.
El código ya se sincronizó con GitHub y Codex necesita modificar el repositorio remoto.
Quieres revisar y fusionar cambios mediante PRs.

Un flujo típico es: subir el código local a GitHub, dejar que Codex descargue el repositorio en un entorno de nube, ejecutar la tarea, generar cambios y presentarlos como PR o diff para revisión.

Al continuar el desarrollo local, recuerda traer los últimos cambios remotos.

Sistema de memoria: escribe un buen AGENTS.md

Los chats nuevos no tienen memoria histórica completa por defecto. Una vez que un proyecto se vuelve complejo, explicar el contexto repetidamente es ineficiente.

La solución más general es mantener AGENTS.md en la raíz del proyecto. Este archivo puede registrar:

Objetivos del proyecto y stack principal.
Comandos comunes.
Estructura de directorios.
Estilo de código y convenciones de nombres.
Acciones prohibidas, como borrar archivos en masa.
Reglas de pruebas, build y despliegue.

También puedes pedir a Codex que lea el proyecto y genere una primera versión de AGENTS.md, luego revisarla manualmente. Para proyectos complejos, vale la pena mantener este archivo.

Las reglas globales deben usarse con cuidado. Son adecuadas para restricciones universales de seguridad, como “no borrar directorios recursivamente” o “confirmar antes de operaciones destructivas”. No pongas detalles específicos del proyecto en reglas globales, o contaminarán otros proyectos.

Plugins y automatizaciones

Los plugins conectan Codex con servicios externos como GitHub, Gmail, Google Drive, bases de datos y plataformas de despliegue.

Su valor está en reducir copiar y pegar. Por ejemplo, Codex puede:

Revisar tendencias de estrellas de un repositorio GitHub.
Resumir contenido de email y enviártelo.
Ejecutar una revisión recurrente.
Escribir el resultado como resumen.

Las automatizaciones son adecuadas para tareas repetidas. Por ejemplo, revisar datos de un repositorio todos los viernes por la tarde y enviar un informe por email. Las tareas simples de automatización normalmente no requieren el modelo más fuerte; basta un modelo más ligero.

Skills: convertir flujos de trabajo en capacidades reutilizables

Las Skills son “manuales profesionales” para Codex. No son prompts de una sola vez. Empaquetan un flujo de tarea, reglas, scripts y notas para que Codex pueda reutilizarlos de forma fiable después.

Fuentes comunes incluyen:

Skills oficiales.
Skills de terceros.
Skills escritas por ti.

Buenos candidatos para Skills incluyen:

Convertir subtítulos en notas ilustradas.
Escribir informes semanales con formato de empresa.
Procesar imágenes o documentos por lotes.
Revisiones de código con formato fijo.
Inicialización de proyectos para un framework concreto.

Si has copiado y pegado el mismo prompt muchas veces, vale la pena convertirlo en una Skill.

MCP: conectar herramientas externas y bases de datos

MCP puede entenderse como un protocolo estandarizado de herramientas para modelos grandes. Mediante MCP, Codex puede llamar servicios externos para completar tareas más concretas.

Por ejemplo, después de conectar Supabase, Codex puede:

Crear tablas de base de datos.
Leer esquemas de base de datos.
Modificar endpoints backend.
Enviar formularios frontend a la base de datos.
Depurar problemas según el estado de la base de datos.

Esto es poderoso, pero los permisos importan. Bases de datos, entornos de producción, plataformas de despliegue y cuentas de email son recursos de alto riesgo. Al conectarlos por primera vez, usa un proyecto de prueba y una cuenta con pocos privilegios.

Plugins de despliegue

Los plugins de plataformas de despliegue pueden permitir que Codex complete builds y releases directamente, como desplegar un proyecto frontend en Netlify.

Estos plugins son adecuados para sitios pequeños, prototipos, herramientas internas y demos. En uso real, presta atención a:

Ejecutar un build local antes del despliegue.
No escribir variables de entorno directamente en el código.
Comprobar que la página abre normalmente después de publicar.
Mantener revisión humana para proyectos de producción.

La IA puede ayudar a conectar el flujo de despliegue, pero los permisos de despliegue deben gestionarse con cuidado.

Automatización del ordenador

Con plataformas y entornos de plugins soportados, Codex también puede operar navegadores o apps de escritorio, completando tareas más cercanas a RPA.

Ejemplos:

Abrir una app de chat y preparar un mensaje.
Navegar un tablero de proyecto y resumir estado de tareas.
Generar un brief en inglés.
Enviarlo a un destinatario especificado después de tu confirmación.
Convertir el flujo en una automatización programada.

Estas capacidades son imaginativas, pero requieren los límites de seguridad más fuertes. Cualquier operación que implique enviar mensajes, enviar email, enviar formularios, pagos o eliminar datos debe conservar confirmación humana.

Sugerencias de uso

La forma correcta de usar Codex App no es dejarle tomar todo de golpe, sino dividir tareas y permitir que ejecute eficientemente en un entorno controlado.

Hábitos recomendados:

Inicializar Git en cada proyecto.
Usar modo plan para tareas complejas.
Usar worktree para tareas paralelas.
Poner reglas de proyecto en AGENTS.md.
Mantener confirmación humana para acciones de alto riesgo.
Convertir flujos repetidos en Skills o automatizaciones.
Validar plugins y MCP primero en un entorno de prueba.

Referencias

Resumen

Codex App no es “otra ventana de chat con IA”. Su foco es convertir la programación con IA en un espacio de trabajo gestionable, donde proyectos locales, tareas en la nube, Git, worktree, plugins, Skills, MCP y automatización puedan conectarse.

La clave para usarla bien es equilibrar libertad y control. Las tareas pequeñas pueden entregarse a Codex con confianza. Las tareas complejas deben empezar con un plan. Las acciones de alto riesgo deben confirmarse. Usada así, Codex puede convertirse no solo en un asistente que escribe código, sino en una herramienta de ingeniería de largo plazo.

Usar pruebas y descripciones de comportamiento para controlar codigo escrito por IA

Tue, 05 May 2026 14:35:38 +0800

Al escribir codigo con IA, la experiencia mas comun es: al principio todo va rapido, despues se vuelve caotico. Las funciones iniciales se montan muy deprisa, pero cuando el proyecto crece y las modificaciones se acumulan, aparece el patron de arreglar un bug y crear tres mas.

Esto no es solo problema de la IA. Muchas personas tambien programan asi; la diferencia es que la IA escribe mas rapido y los problemas se exponen antes. Para reducir ese descontrol, la clave no es pedir a la IA que “se esfuerce mas”, sino darle limites mas claros: primero definir que resultado cuenta como correcto y luego dejar que escriba la implementacion.

TDD y BDD encajan bien dentro del flujo de programacion con IA. TDD convierte “si esta bien o mal” en pruebas automaticas; BDD convierte “si esto es lo que quiero” en descripciones de comportamiento comprensibles por personas. Combinados, hacen que la IA adivine menos, improvise menos y sea mas facil de revisar.

Que problema resuelve TDD

TDD significa Test Driven Development, desarrollo guiado por pruebas. Su secuencia basica es:

Escribir primero las pruebas.
Ejecutarlas y confirmar que ahora fallan.
Escribir despues el codigo funcional.
Ajustar la implementacion hasta que las pruebas pasen.

Esto es lo contrario de lo que mucha gente acostumbra. Al escribir una funcion de ordenacion, la intuicion suele ser escribir primero la funcion y luego probar algunos numeros a mano. TDD pide escribir antes las expectativas como pruebas: por ejemplo, que con [3, 1, 2] se obtenga [1, 2, 3], que un array vacio devuelva un array vacio, y que una entrada con numeros repetidos tambien produzca un resultado correcto.

El sentido de hacerlo asi es que, antes de empezar a desarrollar, el resultado correcto ya esta definido. Mas adelante, quien cambie el codigo solo necesita volver a ejecutar las pruebas para saber si rompio un comportamiento acordado.

Por que antes costaba mantener TDD

TDD suena muy bien, pero en proyectos reales no es facil sostenerlo durante mucho tiempo.

Primero, va contra la intuicion. Frente a un archivo vacio, muchas personas prefieren escribir la funcion antes que las pruebas. Cuando los requisitos todavia no estan claros, escribir casos de prueba tambien cuesta.

Segundo, los requisitos cambian rapido. Una docena de pruebas escritas hoy con mucho cuidado pueden necesitar reescritura masiva si manana cambia el producto. A corto plazo, parece ralentizar el desarrollo.

Tercero, las pruebas tambien tienen coste. El codigo de pruebas no aparece de la nada: antes lo escribia, mantenia y justificaba el programador. En equipos que solo miran la velocidad de entrega a corto plazo, esto se suele recortar.

Pero la IA cambia esta estructura de costes. Convertir requisitos en pruebas es precisamente una tarea en la que la IA es fuerte. Pedirle que implemente segun pruebas tambien es mucho mas fiable que dejarla improvisar a partir de una descripcion vaga.

Como usar TDD al programar con IA

Al pedir una funcion a la IA, puedes cambiar el prompt de “ayudame a implementar esto” a este orden:

Pedir a la IA que primero enumere casos de prueba segun el requisito.
Exigir que cada caso tenga una explicacion en chino o en el idioma de trabajo del equipo.
Revisar primero si los casos de prueba representan la necesidad real.
Despues de confirmar las pruebas, pedir a la IA que escriba la implementacion.
Pedir a la IA que ejecute las pruebas y corrija segun los fallos.

En ese momento, la persona revisa sobre todo si las pruebas expresan bien el requisito, no una gran implementacion. Los casos de prueba suelen estar mas cerca de “cual es la entrada, cual deberia ser la salida y como se manejan los bordes”, por lo que son mas faciles de leer que la logica interna.

Por ejemplo, puedes pedirlo asi:

1
2
3

Primero no implementes la funcion.
Segun el requisito siguiente, escribe casos de prueba. Cada caso debe incluir un comentario en chino que explique la regla de negocio cubierta.
Cuando confirme las pruebas, implementa el codigo segun ellas.

Este flujo reduce dos problemas comunes: que la IA se desvie del tema y que cambios posteriores rompan funciones antiguas.

TDD no basta

TDD por si solo todavia deja dos huecos.

El primero: que todas las pruebas pasen no significa que el producto cumpla la expectativa. Las pruebas solo demuestran que el codigo cumple las reglas que se escribieron en ellas. Si las pruebas no expresan bien la necesidad del usuario, el codigo puede seguir “haciendo mal lo correcto”.

El segundo: el codigo de pruebas sigue sin ser amable para usuarios no tecnicos. Incluso con comentarios, muchas personas no quieren leer montones de tests unitarios. Cuanto mas orientado a experiencia de producto sea el requisito, mas dificil es confirmar desde pruebas si “esto es lo que queria”.

Ahi entra BDD.

Que problema resuelve BDD

BDD significa Behavior Driven Development, desarrollo guiado por comportamiento. No se centra en como esta escrito el codigo por dentro, sino en que comportamiento debe mostrar el sistema en un escenario determinado.

La forma habitual de describir BDD es Given / When / Then:

Given: dado cierto estado inicial.
When: cuando el usuario o el sistema realiza una accion.
Then: entonces debe obtenerse cierto resultado.

Por ejemplo, un personaje de juego con robo de vida puede describirse asi:

Given hay un vampiro en el tablero con 1 punto de vida restante, 2 de ataque y 5 de vida maxima
And hay una unidad enemiga adyacente con 10 puntos de vida restantes
When el vampiro ataca a esa unidad enemiga
Then la unidad enemiga queda con 8 puntos de vida
And el vampiro se cura hasta 3 puntos de vida

Esto no es codigo, pero es mucho mas preciso que “se cura al atacar al enemigo”. Define estado inicial, accion y resultado; tambien expone preguntas posteriores: si el enemigo solo tenia 1 punto de vida, ¿el vampiro se cura por el dano causado o por su ataque? Si el vampiro ya esta al maximo, ¿que ocurre con la curacion sobrante?

Cuanto antes aparezcan estas preguntas, menos tendra que adivinar la IA despues.

Por que BDD encaja tan bien con IA

Antes, impulsar BDD tambien tenia coste. Requeria que producto, desarrollo y QA hablaran con la misma descripcion de comportamiento, y muchos equipos no tienen ese habito de colaboracion.

En la era de la IA, el coste de BDD baja. Solo necesitas escribir primero una necesidad aproximada, por ejemplo:

`1`	`Despues de atacar a un enemigo, el vampiro recupera una cantidad de vida igual al dano causado.`

Luego pides a la IA que genere escenarios Given / When / Then. Una buena IA agregara casos limite y preguntara por reglas ambiguas. Tu trabajo sera confirmar esas descripciones de comportamiento, no leer directamente la implementacion.

Una vez confirmadas las descripciones, pide a la IA que las convierta en pruebas y finalmente que implemente segun esas pruebas. El camino se vuelve mucho mas claro.

Un flujo mas estable para programar con IA

En la practica, puedes encadenar BDD y TDD:

Escribe el requisito en lenguaje natural.
Pide a la IA que lo convierta en escenarios BDD.
Confirma si Given / When / Then encajan con la expectativa.
Pide a la IA que convierta esos escenarios en pruebas automaticas.
Revisa rapidamente la cobertura de las pruebas.
Pide a la IA que implemente la funcion.
Ejecuta las pruebas; si fallan, pide a la IA que corrija segun los errores.
Haz una aceptacion manual y una revision de codigo final.

La clave esta en el orden. No empieces pidiendo una implementacion completa. Primero haz que la IA convierta el requisito en comportamiento verificable y despues en pruebas ejecutables. Asi su espacio de improvisacion se reduce mucho.

Puedes usar directamente un prompt como este:

Procesa este requisito siguiendo un flujo BDD + TDD.

Paso 1: primero organiza el requisito en escenarios Given / When / Then, sin escribir codigo.
Paso 2: enumera las reglas ambiguas que detectes y preguntame para confirmarlas.
Paso 3: cuando los escenarios esten confirmados, conviertelos en casos de prueba.
Paso 4: cuando las pruebas esten confirmadas, implementa la funcion.
Paso 5: ejecuta las pruebas y corrige segun los fallos hasta que pasen.

Este tipo de prompt no es complicado, pero cambia claramente la forma de trabajar de la IA. Primero acota el requisito y luego entra en implementacion, en vez de escribir desde el principio mucho codigo que parece completo pero resulta dificil de verificar.

Escenarios donde conviene usarlo primero

BDD + TDD no tiene que aplicarse a todo. Para scripts de una sola vez, procesamiento temporal de datos o pequenos ajustes de estilo, el flujo completo puede ser excesivo.

Encaja mejor en estos casos:

Hay muchas reglas de negocio y se entienden mal con facilidad.
Hay muchos bordes y se seguira modificando.
Funciones de logica densa como juegos, facturacion, permisos, maquinas de estado o validacion de formularios.
Hace falta confirmar requisitos entre varias personas.
El codigo se mantendra a largo plazo, no se genera una sola vez.
El proyecto ya muestra el problema de que “cuanto mas corrige la IA, mas se enreda”.

Si solo quieres cambiar el texto de un boton, no hace falta todo el proceso. Pero si vas a crear un sistema de habilidades de personajes, flujo de estados de pedidos, logica de permisos o reglas de puntos, escribir primero comportamientos y pruebas suele compensar.

Que tener en cuenta

Primero, mas pruebas no siempre es mejor. Las pruebas deben cubrir reglas clave y bordes de alto riesgo, no bloquear cada detalle de implementacion. Si no, cualquier cambio menor de requisito convierte las pruebas en una carga de mantenimiento.

Segundo, los escenarios BDD deben ser concretos. No escribas frases como “el sistema deberia funcionar normalmente” o “la experiencia deberia ser fluida”, porque no son verificables. Hay que especificar el estado dado, la accion y el resultado esperado.

Tercero, las personas aun deben revisar. La IA puede generar pruebas y escenarios de comportamiento, pero no sabe cual es tu verdadero criterio de producto. Las reglas limite, en especial, deben ser confirmadas por una persona.

Cuarto, despues de pasar las pruebas hay que ejecutar la funcion real. Las pruebas automaticas ayudan con la logica, pero la experiencia de interfaz, rendimiento, interaccion y sensacion de usuario aun requieren aceptacion manual.

Resumen

La IA escribe codigo rapido, pero rapido no significa estable. Cuanto mas complejo es el requisito, menos conviene depender de un simple “ayudame a implementarlo”. Es mejor dividir primero la necesidad en comportamientos verificables, convertirlos en pruebas ejecutables y finalmente dejar que la IA implemente segun esas pruebas.

TDD le dice a la IA que resultado cuenta como correcto. BDD ayuda a las personas a confirmar si esa funcion es realmente la que quieren. Juntos no agregan ceremonia por la ceremonia, sino que reducen el espacio de adivinacion de la IA y convierten “escribir rapido” en “modificar de forma estable”.

Claude.md no es mejor cuando es más largo: cómo escribir archivos de memoria global para codificación AI

Wed, 29 Apr 2026 21:07:37 +0800

Recientemente vi una discusión sobre archivos de memoria global para codificación de IA: después de que los proyectos agregan archivos como Claude.md o AGENTS.md, los resultados no necesariamente mejoran. En algunos casos, las tasas de éxito pueden incluso disminuir mientras que el costo del razonamiento aumenta.

Al principio, esto parece contradictorio. Generalmente asumimos que si le damos a la IA más antecedentes del proyecto, más reglas y más explicaciones, debería escribir el código con mayor precisión.
El verdadero problema es que Claude.md no es un documento ordinario. Es un archivo de memoria global que se inyecta en el contexto de cada conversación. Cuanto más contiene, más tiene que leer el modelo cada vez; cuanto más vago sea, más juicio tendrá que hacer el modelo; y si contiene flujos de trabajo que no siempre deberían ejecutarse, el modelo puede desencadenar acciones innecesarias en tareas no relacionadas.

Entonces, la parte difícil de escribir Claude.md es no completarlo. Se trata de decidir qué piezas de información merecen ocupar contexto de forma permanente.

¿Qué es Claude.md?

En las herramientas de codificación de IA, archivos como Claude.md y AGENTS.md son esencialmente archivos de memoria global.

La conversación normal entra en el contexto, pero la longitud del contexto es limitada. Una vez que la conversación se vuelve larga, el contenido histórico se comprime y se pierden algunos detalles. Un archivo de memoria global fija reglas importantes para que el modelo pueda verlas al comienzo de cada tarea.

Esto significa dos cosas:

El contenido escrito allí es más difícil de olvidar.
El contenido escrito allí también cuesta algo en cada tarea.

No es como un README que se lee sólo cuando es necesario. Se parece más a un conjunto de limitaciones laborales de larga duración. Una vez que algo se coloca allí, afecta el juicio del modelo por defecto.

Por lo tanto, Claude.md no es una introducción al proyecto, ni una colección de consejos, ni un lugar para deshacerse de cada proceso de desarrollo. Sólo debe almacenar reglas que el modelo probablemente viole repetidamente si no las conoce.

Por qué puede empeorar las cosas

Un archivo de memoria global mal escrito suele provocar tres tipos de problemas.

Primero, consume contexto.

Si Claude.md tiene mil líneas, esas líneas permanecen en el contexto del modelo durante mucho tiempo. Es posible que se reduzcan el código, los mensajes de error y los requisitos que realmente son relevantes para la tarea actual. El contexto no es espacio libre. Cuanto más grande sea el archivo de reglas globales, más fácil será diluir la tarea actual.

En segundo lugar, puede desencadenar comportamientos innecesarios.

Por ejemplo, un archivo global podría decir:

1
2

Before every task, fully read the project directory.
After every change, run a complete end-to-end test.

Estas líneas parecen responsables, pero en un archivo de memoria global se convierten en “hacer esto para cada tarea”. Incluso si la tarea consiste solo en cambiar una línea de copia, el modelo puede realizar exploraciones y pruebas innecesarias debido a estas reglas. El resultado es un trabajo más lento, un costo más alto y, a veces, más interferencia.

En tercer lugar, aumenta la carga del juicio.

Declaraciones como “mantener el código elegante, conciso, mantenible y extensible” suenan correctas, pero son restricciones débiles. Cada vez que el modelo genera código, tiene que decidir qué significa elegante o extensible, sin recibir un límite claro.

Un mejor enfoque es escribir prohibiciones o contraejemplos concretos en lugar de virtudes abstractas. Por ejemplo:

1
2
3

Do not add a generic abstraction for a single call site.
Do not change shared parsing logic without test coverage.
Do not put temporary scripts in the application source directory.

Estas reglas son más específicas y más fáciles de seguir.

¿Qué debería entrar?

Puedes usar un estándar simple para decidir si algo pertenece a Claude.md:

Si la IA comete repetidamente el mismo error sin ella, entonces vale la pena anotarlo.

El contenido adecuado para un archivo de memoria global suele tener estas características:

Es duradero
Está fuertemente ligado al repositorio actual.
No se puede inferir naturalmente de la estructura del código.
Cambia claramente el comportamiento del modelo.
Es preferiblemente una restricción, prohibición, regla de ruta o comando fijo.

Por ejemplo:

For all Hugo posts, only edit index.zh-cn.md and do not automatically generate other language versions.
Article front matter must include title/date/draft/tags/categories/slug/description.
Do not modify generated artifacts under public/.
On PowerShell, use scripts/deploy.ps1 for deployment.

Estas no son sugerencias vagas. Están vinculados a cómo funciona realmente el repositorio. Si el modelo no los conoce puede cometer errores; una vez que los conoce, puede evitar verdaderos errores.

¿Qué debería quedar fuera?

Mucha gente convierte Claude.md en un manual de proyecto. Esto suele ser innecesario.

El contenido que generalmente no pertenece allí incluye:

Visión y antecedentes del proyecto.
Descripciones de estructuras de directorios grandes.
Planes de tareas temporales
Pasos únicos de depuración
Lemas de calidad de código abstracto.
Flujos de trabajo largos que solo son necesarios en algunas situaciones.

Por ejemplo, una descripción como “este es un proyecto de comercio electrónico con módulos de producto, pedido y usuario” ayuda muy poco con una tarea de codificación concreta. Durante el desarrollo real, el modelo debe depender de los requisitos, especificaciones, estructura del código y pruebas actuales, no de una introducción aproximada del proyecto en la memoria global.

Lo mismo se aplica a la estructura de directorios. A menos que un directorio tenga una convención especial, como “los componentes compartidos deben importarse desde este directorio”, no es necesario escribir el árbol completo en el archivo. El modelo puede leer el directorio del proyecto. Es fácil que una descripción de directorio estática quede obsoleta.

Los flujos de trabajo pertenecen a habilidades o comandos

Si una sección dice “primero haz esto, luego aquello y luego haz la tercera cosa”, es posible que no pertenezca a Claude.md.

Los flujos de trabajo de larga duración se pueden convertir en habilidades, scripts o comandos. El beneficio es que la memoria global solo necesita conservar el nombre y la condición de activación, mientras que los pasos detallados se cargan solo cuando es necesario.

Por ejemplo:

1
2

When the user asks to translate a Hugo post, use the post-translate skill.
When the user asks to deploy the site, run the hugo-rsync-deploy workflow.

Esto es más liviano que poner los procesos completos de traducción e implementación en Claude.md. La memoria global sigue siendo corta y los flujos de trabajo detallados se encuentran en herramientas activables.

El nuevo flujo de inicialización de Claude también avanza en esta dirección. No solo genera un Claude.md; también intenta dividir los flujos de trabajo reutilizables en habilidades y los eventos fijos en ganchos. La idea subyacente es clara: la memoria global debería ser un punto de entrada, mientras que los detalles deberían cargarse según demanda.

Claude.md necesita iteración

Claude.md no debe escribirse una vez y luego ignorarse.

Un mejor enfoque es ser breve al principio y dejar que las tareas reales expongan los problemas. Si ocurre un error una vez, manéjelo manualmente. Si el mismo tipo de error aparece dos o más veces, puede merecer convertirse en una regla global.

Este tipo de iteración es más útil que escribir un enorme conjunto de reglas al principio. Al principio, no sabes qué reglas son realmente útiles o qué líneas se convertirán en ruido. A medida que el proyecto crece, la colaboración aumenta y el comportamiento del modelo se vuelve más claro, puede agregar gradualmente problemas de alta frecuencia.

También hay una tendencia importante: cuanto más fuerte sea el modelo, más corto debería ser el archivo de memoria global. Muchos requisitos que alguna vez tuvieron que escribirse en indicaciones ahora son manejados naturalmente por el modelo. Continuar poniendo esos requisitos básicos en Claude.md solo aumenta la carga de contexto. La memoria global debería reducirse a medida que mejora la capacidad del modelo, manteniendo solo lo que es exclusivo de este repositorio y no se puede inferir automáticamente.

Una forma más práctica de escribirlo

Al escribir Claude.md, piense en este orden:

¿Qué convenciones especiales tiene este repositorio?
¿Qué errores ha cometido el modelo más de una vez?
¿Qué directorios, archivos o comandos nunca deben usarse indebidamente?
¿Qué flujos de trabajo deberían convertirse en habilidades, guiones o comandos en lugar de un contexto permanente?
¿Qué partes son meras introducciones y pueden eliminarse?

El archivo final puede tener sólo unas pocas docenas de líneas. No es necesario explicar completamente el proyecto. Necesita limitar el comportamiento con precisión.

Un buen Claude.md podría verse así:

# Working Rules

- Only edit files related to the current task.
- Do not modify generated artifact directories such as public/ or resources/.
- Hugo post rewrites only process index.zh-cn.md and do not generate other language versions.
- If deployment is involved, run the Hugo build first, then execute the existing rsync script.
- When there are existing user changes, do not revert them. Continue from the current state.

Es breve, pero cada línea afecta el comportamiento real. Ese es el tipo de contenido que vale la pena mantener en contexto permanentemente.

Pensamiento final

El valor de Claude.md no es hacer que la IA “sepa más”. Se trata de hacer que la IA “evite errores corregidos”.

No es una base de conocimientos ni una enciclopedia de proyectos. Es un archivo de restricciones de larga duración para la codificación AI.
Cuanto más específico, breve y cercano a los errores reales sea, más útil será. Cuanto más genérica, más larga y más parecida a una introducción de proyecto sea, más probable será que ralentice el modelo o incluso empeore los resultados.

Trate la memoria global como un recurso escaso, no como un bloc de notas ilimitado. Ese puede ser el principio más importante para escribir un buen Claude.md.

Cómo elegir entre GPT 5.5, Claude Opus 4.7, DeepSeek V4 y Qwen 3.6 Max

Tue, 28 Apr 2026 22:18:00 +0800

Si solo quieres la respuesta corta, recuerda primero esta versión:

Si desea la opción más confiable y la menor pérdida de tiempo, comience con GPT 5.5
Si lo que más le importa es la presentación de la página, la creatividad y el pulido visual, Claude Opus 4.7 sigue siendo potente.
Si desea saber qué modelo nacional se acerca más al nivel superior, “Qwen 3.6 Max” es altamente competitivo ahora
DeepSeek V4 no es débil, pero su salida es más desigual que la de los demás

Cuando la gente pregunta qué IA de codificación es la más potente en este momento, normalmente no preguntan por una tabla de clasificación. Piden algo más práctico:
Si necesito crear una página, hacer una demostración, generar una pequeña herramienta o agregar interacción, ¿qué modelo es más probable que me brinde algo utilizable en el primer intento?

Desde ese ángulo, las diferencias entre estos modelos ya son bastante claras.

El veredicto general

Si coloca GPT 5.5, Claude Opus 4.7, DeepSeek V4 y Qwen 3.6 Max uno al lado del otro, la opción más consistente sigue siendo GPT 5.5.

No siempre es el más llamativo, pero rara vez te deja claramente decepcionado. Es rápido, el primer borrador generalmente sale con un alto nivel de finalización y maneja la lógica, la interacción, el movimiento y los juegos pequeños con mano firme.

Claude Opus 4.7 se siente diferente. Su mayor fortaleza no es la pura estabilidad. Es la atmósfera de la página, la organización de la interfaz de usuario y la presentación. Muchas veces, abres lo que hizo y tu primera reacción es simplemente que se ve pulido. Si la presentación visual te importa más, vale la pena considerarla.

Qwen 3.6 Max es el que más merece una nueva apariencia. Ya no es sólo “utilizable para un modelo doméstico”. En algunos escenarios, realmente puede competir con “GPT 5.5” en calidad de salida. En las páginas frontales, la integridad visual y el realismo, ha comenzado a generar una presencia real.

DeepSeek V4 no falla porque no puede hacer el trabajo. El problema es que es menos predecible. Cuando funciona, puede ser perfectamente sólido y, a veces, sorprendentemente bueno. Pero la brecha entre sus mejores y más débiles resultados es aún más obvia que en el caso de los demás.

Dónde `GPT 5.5` es más fuerte

Si las cosas que haces con más frecuencia se ven así:

Generar una página web completa.
Crea una pequeña demostración con movimiento.
Crear una página interactiva con algo de lógica.
Generar un pequeño juego o una interacción multiestado.
Mantener el retrabajo al mínimo

Entonces “GPT 5.5” sigue siendo la respuesta predeterminada más segura.

Sus ventajas son principalmente estas:

Generación rápida de código.
Alta usabilidad desde el primer borrador
Menos errores graves en lógica e interacción.
Rendimiento estable en tareas mixtas

Para decirlo de manera más simple, “GPT 5.5” parece el modelo con más probabilidades de lograr las bases correctas en la primera pasada.
Lo que mucha gente realmente necesita no es el resultado más deslumbrante en una categoría. Necesitan que la primera versión no se rompa. En ese frente, sigue siendo la opción menos estresante.

Por supuesto, no está exenta de debilidades.

En páginas muy visuales, no siempre es lo más sorprendente.
A veces es tan estable que deja menos impresión de diseño

Entonces, si desea una recomendación predeterminada, sigue siendo “GPT 5.5”.
Eso no significa que sea el único que vale la pena mirar.

¿A quién se adapta mejor `Claude Opus 4.7`?

El atractivo de “Claude Opus 4.7” proviene más de cómo se siente la página.

Sus puntos fuertes suelen ser:

Estructura de interfaz de usuario más limpia
Presentación visual más completa
Mayor calidad de presentación en algunas páginas.
Creatividad más notoria en visualización y diseño.

Si el modelo te ayuda a construir cosas como:

Páginas de demostración
Páginas de presentación de datos.
Páginas pequeñas donde la sensación visual importa mucho.
Resultados que deberían lucir pulidos inmediatamente

Entonces “Claude” todavía merece un lugar cerca de la cima.

Sus debilidades también son bastante claras:

No es tan estable como GPT 5.5
A veces se ve bien, pero la lógica detallada se desvía.
En algunos casos, el código se ejecuta, pero la experiencia principal no es del todo correcta.

Así que “Claude” se siente más como un modelo frontal con instinto estético extra.
Si su primera prioridad es el aspecto de la página, tiene ventajas reales. Si tu mayor temor es un error lógico en el primer resultado, debes tener un poco más de cuidado.

Por qué `Qwen 3.6 Max` merece una atención seria

Entre estos modelos, el “Qwen 3.6 Max” ofrece la mayor sensación de impulso.

No hace mucho, muchas personas analizaban la IA de codificación doméstica preguntándose principalmente si podría mantenerse al día. Con Qwen 3.6 Max, la pregunta ya es diferente:
En escenarios de producción frontal, ¿puede competir directamente con los mejores modelos extranjeros?

Sus áreas más fuertes en este momento incluyen:

Salida de página atractiva
Movimiento sólido y efectos visuales realistas en algunos casos.
Salidas que se sienten más completas.
Resultados que a veces pueden acercarse o permanecer cerca de GPT 5.5

Eso dice algo importante.
Si su caso de uso se inclina hacia páginas web, trabajo frontend y resultados con muchas presentaciones, Qwen 3.6 Max ya no es solo una opción de respaldo. Puede ser tratado como un candidato principal serio.

Sin embargo, todavía tiene algunas debilidades.

En tareas lógicas con mucha interacción, aún puede perder un poco de integridad.
Algunas páginas se ven muy bien, mientras que algunas tareas son más planas de lo esperado.
Su variación es aún mayor que GPT 5.5

Aun así, su presencia actual ya es muy fuerte.
Si desea saber qué modelo doméstico merece la mayor atención en este momento, es difícil pasar por alto el “Qwen 3.6 Max”.

Dónde se encuentra `DeepSeek V4` ahora mismo

DeepSeek V4 es un poco más complicado de colocar.

El problema no es que no pueda hacer el trabajo. El problema es que es más difícil predecir dónde aterrizará un resultado determinado.
A veces puede terminar la tarea con imágenes y funcionalidad de trabajo decentes. A veces, una vez que la tarea requiere animación, lógica y presentación de datos al mismo tiempo, es más probable que tropiece.

Ahora mismo se siente más así:

Tiene habilidad real.
No es débil
Aún puede dar resultados aceptables en algunas tareas.
Pero su estabilidad aún no es lo suficientemente tranquilizadora.

Eso moldea a quién le conviene más.

Si no le importa intentarlo varias veces, puede tolerar un reinicio ocasional o ya planea verificar y editar el código usted mismo, aún vale la pena usar “DeepSeek V4”.
Pero si su principal prioridad es reducir la fricción y maximizar el éxito del primer paso, todavía no es la opción más segura.

Entonces, ¿qué debería elegir un usuario normal?

Si no está comparando modelos por diversión y realmente quiere trabajar, la forma más sencilla es elegir por caso de uso.

1. Quiere menos complicaciones y una mayor tasa de éxito en el primer paso

Elija “GPT 5.5”.

Lo mejor es este flujo de trabajo: “Este es mi requisito, denme una primera versión utilizable”.
Eso importa aún más cuando no tienes tiempo para seguir iterando y arreglando.

2. Te importa más la presentación y el acabado visual

Elija Claude Opus 4.7.

Si lo que desea es una página que ya se parezca más a un producto terminado, o si su trabajo está más orientado a demostraciones y presentaciones, Claude muestra su valor más fácilmente.

3. Quiere el modelo nacional más sólido para la producción inicial

Comience con Qwen 3.6 Max.

Ya no es algo que se utiliza únicamente como compromiso. Ahora se puede comparar directa y seriamente.
Si sus tareas se inclinan hacia las páginas web, el movimiento y la presentación, su competitividad ya es muy real.

4. Puedes tolerar algunas variaciones y quieres seguir observando el progreso interno.

Esté atento a DeepSeek V4.

Su problema no es la falta de capacidad. Es que el nivel de ejecución aún varía demasiado.
Si la estabilidad sigue mejorando, podría volverse mucho más importante.

Una última línea

La diferencia entre estas IA de codificación convencionales ya no es quién puede codificar y quién no. Se trata de quién es más estable, quién tiene mejor aspecto y quién se adapta a su tipo de trabajo.

Si desea la respuesta más sencilla, “GPT 5.5” sigue siendo la primera opción.
Si desea una calidad de presentación más fuerte, “Claude Opus 4.7” todavía tiene sabor real.
Si le interesa qué modelo nacional merece la mayor atención, “Qwen 3.6 Max” ya está cerca del frente.
DeepSeek V4 se siente más como un fuerte contendiente que todavía está trabajando en la coherencia.

Si quieres la conclusión más breve posible:

Para mayor estabilidad, elija GPT 5.5. Para la presentación, elija “Claude”. Entre los modelos nacionales, el que más vale la pena ver es el Qwen 3.6 Max.

Por qué Elon Musk y SpaceX quieren la opción de 60 mil millones de dólares para adquirir Cursor

Tue, 28 Apr 2026 21:45:47 +0800

Si solo lees el titular, la forma más fácil de malinterpretar esta historia es reducirla a una frase: Elon Musk quiere que SpaceX gaste 60 mil millones de dólares para comprar Cursor.

Pero la parte más importante de la historia no es la cifra de 60.000 millones de dólares en sí. El verdadero punto es que lo que obtuvo SpaceX es una opción de adquisición, no una adquisición completa.

Eso es algo muy diferente.

En pocas palabras, SpaceX tiene una elección futura: a finales de este año, puede adquirir Cursor por “60 mil millones de dólares” o pagar “10 mil millones de dólares” para seguir avanzando en la asociación. Esa estructura por sí sola indica que Elon Musk y SpaceX no persiguen una simple transacción financiera. Lo que quieren es una configuración en la que primero se asocien, observen el resultado y solo entonces decidan si plegarán completamente el Cursor.

01 ¿Por qué no comprarlo ahora?

Si Elon Musk y SpaceX solo quisieran Cursor en el sentido más directo, el camino más sencillo habría sido una adquisición sencilla.

El hecho de que no lo hicieran sugiere que varias cosas aún no están completamente resueltas:

Si Cursor como producto puede mantener un crecimiento muy alto
Si la computación de SpaceX y xAI realmente puede llevar a Cursor a su siguiente etapa
¿Cuánta sinergia tienen realmente las dos partes una vez que trabajan en estrecha colaboración?
Si concretar hoy una adquisición de 60.000 millones de dólares sería demasiado pronto para cualquiera de las partes.

Por eso importa la opción: toma lo más importante ahora mismo, pero no te apresures a enviar todo el dinero hoy.

Para Elon Musk y SpaceX, esto crea flexibilidad. Para Cursor, también conserva más espacio que el que se absorbe por completo de inmediato.

02 Lo que Elon Musk y SpaceX realmente quieren es más grande que el propio cursor

Según los informes públicos, lo que hace atractivo a Cursor no es solo que sea un producto de codificación de IA popular. También se encuentra en la intersección de varias cosas muy valiosas:

Ya cuenta con un canal de distribución de desarrolladores real.
Ha establecido una posición en la categoría de codificación de IA más popular.
Puede alimentar flujos de trabajo de ingeniería reales en modelos e infraestructura.

Más claramente, Elon Musk y SpaceX no están prestando atención a Cursor porque es simplemente un editor. Lo que realmente están mirando es:

Distribución para desarrolladores.
Usuarios de alto valor
Datos de uso reales de flujos de trabajo de codificación de IA

Para un ecosistema como xAI, que todavía persigue a Anthropic y OpenAI, ese tipo de punto de entrada es caro por una razón.

En esta etapa, la competencia en los modelos grandes ya no se trata sólo de quién tiene la puntuación de referencia más alta. También se trata de:

¿Quién se acerca a los flujos de trabajo reales?
¿Quién llega más directamente a los desarrolladores?
¿Quién recopila más datos de interacción de alta calidad?

El cursor es exactamente ese tipo de punto de acceso.

03 Por qué una opción es más importante que un acuerdo de asociación normal

Si el objetivo fuera sólo la cooperación, un acuerdo de asociación ordinario podría haber bastado. Entonces, ¿por qué añadir una opción de adquisición por “60.000 millones de dólares”?

Porque un acuerdo de cooperación normal no resuelve dos problemas.

1. Evita que otra persona se lleve el premio más tarde

Lo que hace que Cursor sea caro no son sólo los ingresos actuales. Existe la posibilidad de que se convierta en una plataforma mucho más grande en los próximos años. Si SpaceX se hubiera asociado sin bloquear ningún derecho, el resultado fácilmente podría haber sido doloroso para Musk:

El producto se fortalece gracias a la asociación.
El crecimiento se acelera gracias a la asociación
La valoración aumenta debido a la asociación.
Y luego interviene otro gigante y lo compra.

Ése es exactamente el tipo de problema que resuelve una opción de adquisición.
No compre todavía, pero primero asegure el derecho de prioridad.

2. Crea un colchón en torno a la incertidumbre de valoración

Si las dos partes intentaran completar una adquisición total ahora, uno de los argumentos más importantes sería simple: ¿son “60 mil millones de dólares” demasiado caros?

Es difícil responder ahora porque el cursor sigue cambiando muy rápidamente:

Desde el punto de vista actual, 60.000 millones de dólares parecen caros.
Pero si la computación mejora, la capacidad del modelo mejora y los usuarios siguen expandiéndose, el número puede verse muy diferente dentro de unos meses.

Por eso una opción es un compromiso tan clásico:

Bloquee el marco de precios hoy
Decidir si ejercerlo después de ver cómo se desempeña la sociedad.

Esto es mucho más típico de acuerdos en los que la estrategia de capital y la estrategia industrial están estrechamente mezcladas.

04 Por qué el cursor estaría de acuerdo

Desde el punto de vista de Cursor, esto tampoco es especialmente difícil de entender.

Lo que Cursor puede necesitar más en este momento no es simplemente más efectivo. Es más probable que se trate de una mayor capacidad informática, más recursos de capacitación y un foso estratégico más sólido.

Los informes públicos ya dejan en claro que Cursor quería impulsar la capacitación aún más, pero estaba limitado por la computación. Una asociación con el ecosistema de Musk, especialmente SpaceX y xAI, le brinda acceso directo a una infraestructura mucho más grande.

Esto importa de maneras muy prácticas:

La formación modelo puede seguir ampliándose
La capacidad del producto puede mejorar más rápido
El cursor no tiene que depender totalmente de proveedores de modelos externos.

Ese último punto importa mucho.

Puede que el cursor sea un producto de codificación de IA popular, pero aún vive con una tensión estructural:
coopera con empresas como Anthropic y OpenAI y compite con ellas directamente en la capa de producto.

Ese tipo de relación es inherentemente inestable.

Lo que ofrece la combinación SpaceX/xAI de Musk es un camino diferente: unir la capa de modelo ascendente y la capa de producto descendente de manera mucho más estrecha.

Por tanto, Cursor no acepta esta opción simplemente porque el precio sea atractivo. También está de acuerdo porque realmente necesita una mayor capacidad informática y una alineación estratégica más profunda.

05 ¿Por qué dejar sobre la mesa una alternativa de 10.000 millones de dólares?

Esta puede ser la parte más interesante.

El encuadre público no es “ni una adquisición ni nada”. Se trata de “o una adquisición de “60 mil millones de dólares” o “10 mil millones de dólares” para profundizar la asociación”.

Eso le indica que ambas partes están asumiendo algo desde el principio:
la asociación en sí misma tiene valor, incluso si nunca se produce una adquisición total.

Ese camino de los “10 mil millones de dólares” funciona como un estado intermedio:

Si la sociedad funciona muy bien, ejecutar la adquisición.
Si funciona, pero aún no es el momento adecuado para las fusiones y adquisiciones, mantener a las dos partes estrechamente unidas a través de una asociación estratégica más sólida. En otras palabras, Elon Musk y SpaceX no están forzando esto a tomar una decisión binaria de “comprar o no comprar”. Están dejando deliberadamente espacio en el medio.

Por lo general, eso significa que ambas partes saben que el mercado de la IA se está moviendo demasiado rápido como para tomar una decisión irreversible demasiado pronto.

06 Desde la perspectiva de Elon Musk y SpaceX, esto parece un movimiento de posicionamiento previo a la IPO

Visto desde fuera, el acuerdo también tiene una dimensión de mercado de capitales muy obvia.

Los informes públicos ya han sugerido que, antes de una posible IPO, SpaceX quiere contar una historia más sólida sobre la IA en lugar de ser vista sólo como una compañía de cohetes y satélites. Para Elon Musk, eso también se ajusta a un patrón más amplio de los últimos años: intentar conectar cohetes, computación, modelos, distribución y flujos de trabajo de desarrolladores en un mapa tecnológico más grande.

En ese contexto, Cursor no es sólo un activo empresarial. También es un activo narrativo:

SpaceX aporta infraestructura y computación a gran escala
xAI trae la historia del modelo y la plataforma.
Cursor ofrece distribución para desarrolladores y un caso de uso de capa de aplicación novedoso

Una vez que esas tres capas se vinculan, la historia se vuelve mucho más completa que “también hacemos modelos”.

Es por eso que la opción también puede leerse como un movimiento para bloquear una historia futura antes de que se arregle la estructura final. Para Musk, no se trata sólo del diseño de acuerdos. También es un paso temprano para asegurar una posición significativa en el punto de entrada de la codificación de IA.

Esto gana tiempo para la integración interna y al mismo tiempo indica al mundo exterior que SpaceX no quiere detenerse en la infraestructura de inteligencia artificial. Quiere seguir llegando a la capa de aplicaciones y a los flujos de trabajo de los desarrolladores.

07 Resumen de una oración

Elon Musk y SpaceX quieren la opción de adquisición de Cursor por “60 mil millones de dólares” no porque estén seguros de que deben tragarse toda la compañía hoy, sino porque quieren acceso de los desarrolladores y derechos de adquisición futura ahora sin asumir todo el riesgo de fusiones y adquisiciones, riesgo de valoración y riesgo de integración de inmediato.

Por eso la palabra “opción” importa más que la cifra “60 mil millones de dólares”.
Muestra que SpaceX no busca una transacción única, sino una estrategia para asegurar su posición primero, probar la asociación y solo después decidir si absorbe completamente la empresa.

DeepSeek V4 Pro vs GPT-5.5: después de probar la interfaz, la escritura y la codificación, la brecha parece mayor de lo esperado

Sat, 25 Apr 2026 11:12:00 +0800

Las comparaciones entre DeepSeek V4 Pro y GPT-5.5 están recibiendo más atención últimamente. La razón ya no es si alguno de los modelos es utilizable. La verdadera pregunta es: cuando el trabajo recae en el desarrollo, la redacción y la codificación del frontend, ¿cuál es mejor para ser su herramienta principal?

Cuando la gente compara modelos como este, a menudo empiezan preguntando cuál es más fuerte.
Pero la pregunta más útil suele ser diferente: en una tarea real, ¿cuál es más estable, más barata para comunicarse y con mayor probabilidad de producir algo que pueda seguir construyendo de inmediato?

Si simplificamos primero la conclusión, queda más o menos así:

Cuando desea un resultado más equilibrado y una experiencia productiva más completa, mucha gente todavía mira primero GPT-5.5
Cuando necesita una iteración de alta frecuencia en chino, se preocupa más por el costo y desea ciclos de respuesta rápidos, “DeepSeek V4 Pro” se convierte en un candidato serio.
Lo que realmente determina la experiencia a menudo no es el nombre del modelo en sí, sino el tipo de tarea, el enfoque de las indicaciones y si es necesario seguir revisándolo después.

Analicemos esto en los tres escenarios de comparación más comunes.

1. Tareas frontend: la verdadera pregunta no es si puede crear una página, sino si puede seguir mejorándola

El trabajo frontend parece ideal para comparaciones de modelos porque el resultado es fácil de ver.
¿Se puede ejecutar la página? ¿Se ve bien? ¿Está limpia la estructura? Puedes juzgar todo eso rápidamente.

Pero la verdadera diferencia no suele aparecer en si el primer borrador funciona. Aparece en preguntas como estas:

¿Está la estructura lo suficientemente clara?
¿La división del componente es natural?
¿Cambiar una pieza accidentalmente rompe otra?
¿Puede seguir la misma lógica de implementación en múltiples rondas de instrucciones?

Es también por eso que muchas demostraciones de frontend que parecen impresionantes en la primera ronda no necesariamente se mantienen a la vanguardia en los flujos de trabajo reales.

Si su tarea es algo como:

Generar rápidamente un prototipo de página ejecutable
Redactar una idea de página de destino.
Complete los estilos, botones, tarjetas, formularios y otros elementos básicos requeridos

entonces ambos modelos a menudo te acercarán bastante, y la diferencia está más en el estilo de salida.

Pero si la tarea se convierte en:

Revisar repetidamente la interfaz de usuario durante varias rondas.
Leer el código existente y continuar desde allí.
Equilibrar la estructura de los componentes, la coherencia del estilo y la mantenibilidad.
Convertir gradualmente una página estática en código de proyecto real.

entonces lo que debes observar ya no es “quién luce mejor en la primera ronda”, sino “quién tiene menos probabilidades de quedarse dormido en la quinta ronda”.

Entonces, en el trabajo frontend, la comparación clave no es si el modelo puede generar una página. Se trata de si, después de seguir agregando restricciones, aún puede mantener una estructura estable, nombres consistentes y costos de modificación manejables.

2. Tareas de escritura: la verdadera diferencia no es cuánto se escribe, sino qué tan estable se mantiene el estilo y qué tan bien se reescribe.

La escritura es otra área en la que la gente puede juzgar mal los modelos con mucha facilidad.

Una razón importante es que los primeros borradores suelen verse bien desde ambos lados.
La estructura es completa, los párrafos están ahí y el tono es lo suficientemente suave como para que sea fácil pensar que son básicamente similares.

Pero tan pronto como avanzas la tarea un paso más, aparecen las diferencias:

¿Puede comprender con precisión a su público objetivo?
¿Puede cambiar de tono manteniendo el mismo tema?
¿Se pierden puntos clave al reescribir?
¿Se mantiene estable al comprimir, ampliar, retitular o reestructurar?

El mayor problema al escribir no suele ser “no puede escribir”, sino “escribió algo que aún necesita mucho arreglo”.

Entonces, al comparar “DeepSeek V4 Pro” y “GPT-5.5”, el método más útil es no pedirles a cada uno que escriba un artículo. Se trata de ejecutar varias rondas como esta:

Escribe el primer borrador.
Reescríbelo en un tono diferente.
Comprímelo en una versión más corta.
Modifíquelo para convertirlo en algo más adecuado para titulares basados en clics o distribución de búsqueda.

Si un modelo puede mantener intactos los puntos clave, la redacción estable y la estructura limpia durante esas rondas, entonces tiene mucho más valor en un flujo de trabajo de escritura real.

En otras palabras, lo que realmente miden las tareas de escritura no es el “estilo literario”, sino la capacidad de revisión, el seguimiento de instrucciones y el sentimiento de colaboración continua.

3. Tareas de codificación: la brecha real se muestra en la estabilidad de la cadena larga

Las tareas de codificación exponen el nivel real de un modelo más fácilmente que el trabajo frontend, porque no se trata solo de generar resultados. Tienen que conectar con la realidad.

Muy rápidamente, te encuentras con preguntas como:

¿Puede comprender la estructura de un proyecto existente?
¿Puede modificar varios archivos a la vez?
¿Introduce nuevos problemas después de realizar cambios?
¿Puede seguir depurando siguiendo registros y errores?
Después de varias rondas, ¿todavía recuerda lo que ya cambió?

En este tipo de trabajo, lo que más preocupa a los usuarios no suele ser si un único fragmento de código parece elegante. Es: ¿puede este modelo seguir avanzando en la tarea, en lugar de dejarme a mí limpiar el desorden?

Entonces, al comparar DeepSeek V4 Pro y GPT-5.5, lo más significativo a considerar generalmente no son indicaciones de codificación aisladas, sino un proceso más cercano al trabajo real:

Leer un repositorio existente
Encuentra un error
Modificar varios archivos relacionados
Continuar corrigiendo según los mensajes de error.
Resumir claramente el resultado al final.

Una vez que la tarea ingresa a ese tipo de flujo de trabajo continuo, la retención del contexto, los hábitos de ejecución, la calidad de la explicación y la tasa de retrabajo son más importantes que la calidad de la respuesta en un solo turno.

Esta es también la razón por la que muchos usuarios eventualmente no se conforman con “usar un solo modelo para siempre” para codificar. En cambio, cambian su herramienta principal según la etapa de la tarea.

4. Lo que realmente vale la pena comparar no es quién gana, sino qué tareas son más rentables asignar a quién

Si pones “DeepSeek V4 Pro” y “GPT-5.5” uno al lado del otro y solo intentas elegir un campeón general, el resultado suele ser una conclusión vacía.

Esto se debe a que las tareas reales no son un examen estándar:

Algunos son de una sola generación.
Algunas son colaboraciones de múltiples rondas.
Algunos están escritos en chino.
Algunos son cambios de ingeniería.
Algunos priorizan la velocidad
Algunos priorizan la estabilidad
Algunos priorizan el costo

Entonces, el enfoque que se acerca más al uso real suele ser dividir por objetivo de la tarea:

Si desea una experiencia general más completa, una interacción más madura y un resultado general más estable, pruebe primero GPT-5.5
Si desea experimentar con alta frecuencia en chino, iteración rápida y mejor relación calidad-precio, “DeepSeek V4 Pro” merece un lugar importante en su flujo de trabajo.
Si la tarea en sí es de cadena larga, de múltiples rondas y colaborativa, no se detenga en el primer resultado; observe quién se mantiene más estable después de cinco rondas.

En otras palabras, la verdadera pregunta no es “quién es absolutamente más fuerte”, sino ésta:
para el trabajo frontend, la escritura y la codificación, ¿qué modelo parece más la herramienta más práctica para su etapa actual?

5. Cómo realizar una comparación que realmente signifique algo

Si desea probar DeepSeek V4 Pro y GPT-5.5 usted mismo, un método más confiable generalmente no es ejecutar una sola ronda, sino hacer algo como esto:

Dé a ambos modelos el mismo requisito inicial.
Mantenga las mismas restricciones en ambos lados
Continúe haciendo preguntas de seguimiento durante tres a cinco rondas.
Registre la calidad de salida, la frecuencia de deriva y la cantidad de retrabajo
Solo entonces compara velocidad, coste y usabilidad final.

Ese tipo de prueba te acercará mucho más al trabajo real que simplemente preguntar quién luce más impresionante en la primera ronda.

Especialmente en frontend, escritura y codificación, lo que a menudo determina la experiencia real no es la línea de partida, sino quién puede quedarse contigo y ayudarte a terminar el trabajo.

6. Una forma sencilla de recordarlo

Si solo quieres un resumen práctico, puedes recordarlo así:

GPT-5.5: más como un espacio de trabajo predeterminado amplio, productivo y convencional
DeepSeek V4 Pro: más bien un competidor fuerte que vale la pena incorporar a los flujos de trabajo diarios en chino y al trabajo de prueba y error de alta frecuencia
El verdadero punto de comparación: no un resultado llamativo en la primera ronda, sino quién se mantiene más estable y ahorra más esfuerzo después de múltiples rondas de revisión.

Entonces, en este tipo de comparación, lo que realmente importa nunca es simplemente “quién ganó”. Es este:
Para sus tareas de frontend, escritura y codificación, ¿qué modelo facilita el progreso continuo, reduce el retrabajo y le brinda resultados más estables?

Cómo dividir tareas entre ChatGPT, Claude y Gemini: elección de uso diario, codificación y capacidades especiales

Sat, 25 Apr 2026 10:51:19 +0800

Mucha gente ya no confía en un solo modelo. En cambio, alternan entre “ChatGPT”, “Claude” y “Gemini”. Eso hace que la pregunta sea mucho más práctica: ¿qué tipo de tareas deberían asignarse a qué modelo?

Esto resulta confuso no porque los tres sean débiles, sino porque ahora son fuertes de diferentes maneras. Si aún así eliges basándose en un estándar vago como “cuál es más inteligente”, fácilmente puedes terminar eligiendo la herramienta equivocada.

Si simplificamos primero la conclusión, queda más o menos así:

Para conversaciones diarias y tareas de propósito general, muchas personas comienzan con ChatGPT
Para la codificación de línea de comandos, la colaboración de contexto prolongado y la ejecución sostenida de tareas, “Claude” a menudo se siente más fluido.
Cuando necesita integración del ecosistema de Google, búsqueda, puntos de entrada multimodales o ciertas capacidades a nivel de producto, “Gemini” tiende a destacar más.

Dividámoslo en tres partes.

1. Conversaciones diarias: por qué muchas personas todavía abren `ChatGPT` primero

Para la mayoría de los escenarios cotidianos, “ChatGPT” todavía se siente como el “punto de entrada predeterminado”.

No se trata de un único punto de referencia. Se trata de la experiencia general:
cuando desea hacer una pregunta rápida, organizar sus pensamientos, redactar un borrador, crear una primera versión o resumir un material, “ChatGPT” generalmente se siente bastante equilibrado.

Sus puntos fuertes suelen aparecer en algunos lugares:

Su estilo de respuesta es relativamente estable.
La curva de aprendizaje es baja para los usuarios generales.
La mayoría de las tareas amplias no requieren muchos ajustes adicionales
El producto se siente pulido y funciona bien para el uso diario frecuente

Entonces, si tu tarea es algo como esto:

Ayúdame a organizar un tema.
Convertir una idea en contenido estructurado.
Resumir un artículo extenso.
Lluvia de ideas sobre varios enfoques
Reescribir algo más claramente

Entonces, “ChatGPT” suele ser un lugar muy natural para empezar.

Eso no significa que sea siempre la opción más sólida para cada tarea profesional. Esto significa que, para un uso amplio y de propósito general, a menudo se siente más como el espacio de trabajo predeterminado.

2. Codificación de línea de comandos y tareas largas: por qué mucha gente se inclina por `Claude`

Una vez que una tarea pasa de “charlemos” a “seguiremos trabajando hasta terminar esto”, muchas personas empiezan a preferir “Claude”.

Esto es especialmente cierto en escenarios como:

Programación de línea de comandos
Comprender el contexto de un gran proyecto.
Coordinar ediciones en múltiples archivos.
Depuración de largas cadenas de tareas.
Leer código mientras se avanza constantemente una tarea

En este tipo de trabajo, la clave no suele ser si una respuesta es especialmente impresionante. Se trata de si el modelo puede permanecer estable a lo largo de una cadena de trabajo más larga.

La razón por la que a menudo se prefiere “Claude” no es que “diga una frase mejor que las demás”, sino que:

Se mantiene mejor en tareas de contexto prolongado.
Se siente más estable al leer archivos, registros y reglas continuamente
Es más adecuado para avanzar gradualmente en trabajos de codificación complejos.
En los flujos de trabajo de agentes y de línea de comandos, a menudo se lo trata como el modelo de trabajo principal.

Si está haciendo “codificación de vibración”, corrigiendo errores en la terminal, entendiendo la estructura del proyecto o cambiando características en varios archivos, las fortalezas de “Claude” tienden a mostrarse más claramente. En pocas palabras, “Claude” se siente más como un modelo con el que trabajas para hacer las cosas, no simplemente como uno al que haces una pregunta y obtienes una respuesta.

3. “Géminis” a menudo gana no “compitiendo frontalmente en todo”

Cuando la gente habla de “Géminis”, a menudo formulan la pregunta de la siguiente manera: ¿es el más fuerte de los tres?

Pero en el uso real, la pregunta más útil no suele ser esa. Es: ¿en qué escenarios vale especialmente la pena sacarlo y usarlo a propósito?

El valor de “Géminis” a menudo se muestra más claramente en estas direcciones:

Integración con el ecosistema de Google.
Búsqueda y recopilación de información.
Puntos de entrada multimodales
Ciertos vínculos de características del lado del producto.

Si su flujo de trabajo ya está cerca de la cadena de herramientas de Google, por ejemplo:

Buscar
Documentos
Correo electrónico
Uso del lado del navegador
Puntos de entrada móviles

Entonces la conveniencia práctica de “Gemini” puede importar más que una simple comparación entre modelo y puntuación.

En otras palabras, “Gemini” suele ser útil porque se integra en su flujo de trabajo de manera más natural, no solo porque puede o no vencer a otra persona en una sola respuesta.

4. La forma útil de elegir no es preguntar quién es más fuerte, sino qué tipo de tarea tienes

Cuando la gente compara los tres modelos uno al lado del otro, la trampa más fácil es tratar de encontrar el “mejor” modelo.

Pero las tareas reales varían demasiado:

Algunas son preguntas y respuestas únicas
Algunas son conversaciones de larga duración.
Algunos son proyectos de software.
Algunos son recuperación de información.
Algunos son procesamiento multimodal
Algunos son colaboración en cadena de herramientas.

Por lo tanto, el enfoque más eficaz suele ser ordenar por tipo de tarea:

Si desea un asistente amplio y de alta frecuencia que funcione de inmediato, comience con ChatGPT
Si necesita contexto extenso, trabajo en la línea de comandos, colaboración en codificación y progreso constante en tareas complejas, pruebe primero con “Claude”.
Si necesita ayuda del ecosistema de Google, búsqueda, puntos de entrada multimodal o ciertas integraciones de productos, preste especial atención a “Gemini”.

Ese tipo de división del trabajo está mucho más cerca del uso en el mundo real que obligar a un único campeón general.

5. Por qué muchos usuarios habituales se suscriben a los tres

Desde la perspectiva de un usuario ligero, pagar por los tres puede parecer redundante.
Desde la perspectiva de un usuario intensivo, es más como asignar diferentes herramientas a diferentes trabajos.

La razón es sencilla:
Si las fortalezas de los tres modelos ya han comenzado a divergir claramente, entonces usarlos juntos no constituye realmente un gasto duplicado. Es una forma de reducir los costos de cambio y los costos de prueba y error.

Por ejemplo:

Utilice ChatGPT para la organización diaria y preguntas y respuestas generales
Utilice Claude para el trabajo de codificación principal.
Utilice Gemini para ciertos flujos de trabajo de búsqueda, multimodales o relacionados con Google

La lógica de esta configuración no es fundamentalmente diferente de la de los diseñadores que instalan múltiples herramientas creativas o los desarrolladores que usan múltiples IDE.

6. Cuándo no debes cambiar de modelo con demasiada frecuencia

Eso sí, tener más modelos no siempre es mejor.

Si todavía estás creando un flujo de trabajo estable, saltar demasiado pronto y con demasiada frecuencia entre tres modelos puede complicar aún más las cosas. Los problemas comunes incluyen:

Volver a explicar la misma tarea tres veces.
Recibir diferentes sugerencias de diferentes modelos y luchar más para juzgarlas.
Perder contexto y aumentar los costos de colaboración.
Estancarse en la elección de herramientas antes de establecer sus propios límites de trabajo.

Entonces, una forma más estable suele ser esta:

Asigne primero a cada modelo un escenario principal
Úselo continuamente en ese escenario por un tiempo.
Construya gradualmente sus propios hábitos de división del trabajo.

Eso hace que sea más fácil obtener experiencia reutilizable en lugar de quedarse para siempre en la etapa de “déjame probar esta hoy”.

7. Una forma sencilla de recordarlo

Si solo desea una versión práctica para recordar, puede utilizar esta división en lenguaje sencillo:

ChatGPT: más parecido al asistente de uso general predeterminado
Claude: más bien la opción principal para tareas largas y colaboración en codificación
Gemini: más bien la herramienta con mayores ventajas en la búsqueda, el trabajo multimodal y el ecosistema de Google

Esta no es una regla absoluta y no significa que los tres no puedan reemplazarse entre sí. Es simplemente un punto de partida más realista.

Lo que realmente importa no es elegir el “modelo más fuerte del universo”, sino averiguarlo lo antes posible:
Para el tipo de tarea que tienes por delante, ¿qué modelo ahorra más tiempo, cuesta menos esfuerzo mental y facilita la obtención de resultados?

CLAUDE.md de 65 líneas de Karpathy: ayudando a la codificación de IA a evitar tres errores comunes

Sun, 19 Apr 2026 18:27:23 +0800

Un proyecto de GitHub sobre codificación de IA ha recibido mucha atención recientemente. Su núcleo no es una base de código compleja, sino un archivo CLAUDE.md de aproximadamente 65 líneas. La razón por la que atrajo tantas estrellas no es la complejidad técnica. Es que captura los problemas con los que muchas personas se encuentran repetidamente cuando usan IA para escribir código.

Los antecedentes comienzan con las observaciones de Andrej Karpathy sobre la codificación de IA. Karpathy es un influyente educador e ingeniero en IA: doctor de Stanford, uno de los primeros contribuyentes de OpenAI y exlíder de IA de Tesla responsable del sistema de visión de Autopilot. Continuó compartiendo sus puntos de vista sobre modelos grandes, educación y herramientas de inteligencia artificial, por lo que sus comentarios sobre los cambios en los flujos de trabajo de programación tienden a llamar mucho la atención de los desarrolladores.

Una vez dijo que después de usar Claude Code durante algunas semanas, su estilo de programación cambió notablemente. Anteriormente, era aproximadamente un 80% de código escrito a mano y un 20% de asistencia de IA. Ahora está más cerca del 80% del código escrito por IA y del 20% editado por él mismo. Lo describió como “programación en inglés”, diciéndole a un LLM qué escribir en lenguaje natural.

Pero también señaló varios problemas recurrentes en la codificación de IA.

01 Suposiciones erróneas

El primer problema es que los modelos hacen suposiciones fácilmente en nombre del usuario y luego siguen escribiendo en ese camino. No siempre manejan su propia confusión y no siempre se detienen a hacer preguntas cuando el requisito es ambiguo.

Por ejemplo, si el usuario solo dice “agregar una función de exportación de usuario”, el modelo podría asumir que debe exportar todos los usuarios, generar JSON, escribir en un archivo local y omitir cualquier confirmación sobre permisos o campos. Sólo después de terminar el código el usuario descubre que la comprensión del modelo no coincide con el escenario real.

Un mejor enfoque es enumerar primero las incertidumbres: ¿debería exportar todos los usuarios o los resultados filtrados? ¿Debería activar una descarga del navegador o ejecutarse como trabajo en segundo plano? ¿Qué campos son necesarios? ¿Qué tamaño tiene el conjunto de datos? ¿Existen restricciones de permisos? Si estas preguntas no se aclaran, escribir más rápido sólo significa ir más lejos.

02 Sobrecomplejidad

El segundo problema es que los modelos a menudo convierten problemas simples en complejos. Una tarea que podría manejarse con una función podría recibir clases abstractas, patrones de estrategia, patrones de fábrica, capas de configuración y un montón de puntos de extensión que tal vez nunca sean necesarios.

Este tipo de código puede parecer diseñado, pero en la práctica aumenta el costo de mantenimiento. La IA es especialmente buena para generar rápidamente estructuras grandes, pero no siempre juzga si esas estructuras son necesarias. El resultado es que una tarea que se puede resolver en 100 líneas se infla en 1000 líneas.

La prueba es sencilla: ¿un ingeniero senior observaría el cambio y pensaría que está sobrediseñado? Si la respuesta es sí, elimine las capas adicionales y resuelva el problema actual con la menor cantidad de código necesario.

03 Daños colaterales

El tercer problema es que los modelos a veces modifican o eliminan código que no comprenden completamente. Mientras solucionan un pequeño error, pueden cambiar comentarios casualmente, reformatear el código cercano, limpiar importaciones que parecen no utilizadas o incluso tocar lógica no relacionada con la tarea actual. Estas “mejoras inmediatas” son riesgosas porque amplían el alcance del cambio y dificultan la revisión. Es posible que el usuario solo desee solucionar un fallo del validador causado por un correo electrónico vacío, pero el modelo también puede mejorar la validación del correo electrónico, agregar validación de nombre de usuario y reescribir cadenas de documentos. Al final, resulta difícil saber qué línea cambió el comportamiento.

Una regla más segura es: cambiar sólo lo que se debe cambiar y sólo solucionar los problemas causados por su propio cambio. El código muerto existente, los problemas de formato o el bagaje histórico no deben tocarse a menos que la tarea lo solicite explícitamente. Como máximo, menciónalo.

04 Transformando las quejas en CLAUDE.md

Después de que los comentarios de Karpathy se difundieran ampliamente, el desarrollador Forrest Cheung hizo algo inteligente: organizó estas quejas en reglas de comportamiento ejecutables y las puso en un archivo CLAUDE.md.

El proyecto no contiene código complicado. Su idea clave es convertir las partes más propensas a fallas de la codificación de IA en reglas de trabajo claras. Se pueden resumir en cuatro principios.

La primera es pensar antes de escribir. No asumas en silencio. No ocultes la confusión. Si un requisito tiene múltiples interpretaciones, enumérelas. Si hay un enfoque más sencillo, dígalo. Pregunte cuando sea necesaria una aclaración y responda cuando sea necesario.

El segundo es mantener las cosas simples. No agregue funciones que no fueron solicitadas. No abstraiga el código único. No agregue configuraciones innecesarias. No escriba grandes cantidades de código defensivo para escenarios extremadamente improbables. Si 50 líneas pueden resolverlo, no escribas 200.

El tercero es hacer cambios precisos. Cada línea modificada debe rastrearse directamente hasta la solicitud del usuario. No mejore el código cercano como misión secundaria. No refactorices algo que no esté roto. Haga coincidir el estilo del proyecto existente tanto como sea posible.

El cuarto es la ejecución impulsada por objetivos. No le des al modelo sólo una instrucción vaga. Dale un criterio de éxito verificable. Por ejemplo, “corregir el error” puede convertirse en “escribir una prueba que reproduzca el error y luego hacer que pase”; “agregar validación” puede convertirse en “escribir pruebas de entradas no válidas y hacerlas pasar”. Cuanto más claro sea el criterio de éxito, más fácil será para el modelo avanzar hacia su finalización.

05 Por qué despegó

Este proyecto se hizo popular no porque el contenido sea misterioso, sino porque se acerca al trabajo de desarrollo real.

Muchas personas que utilizan IA para codificar han visto escenas similares: el modelo malinterpreta con confianza el requisito, el código se vuelve más complejo a medida que avanza o toca lugares que no debería tocar. El valor de CLAUDE.md es que convierte esas experiencias en reglas de colaboración que se pueden colocar dentro de un proyecto.

El coste de entrada también es bajo: un archivo puede empezar a marcar la diferencia, sin una integración complicada. Combinado con la influencia de Karpathy y los ejemplos prácticos de comparación del proyecto, se extendió naturalmente a través de la base de usuarios de Claude Code y la comunidad de codificación de IA en general.

Más importante aún, estas reglas no son solo para el Código Claude. No importa qué herramienta de codificación de IA utilice, los problemas subyacentes son similares: el modelo necesita saber cuándo preguntar, cuándo simplificar, cuándo detenerse y cómo decidir que la tarea está completa.

06 Lo que los desarrolladores pueden llevarse

La lección para los desarrolladores comunes es simple: la codificación con IA no se trata de lanzar una oración a un modelo y esperar un milagro. El enfoque eficaz es darle límites al modelo.

Cuando el requisito no esté claro, pídale que exponga sus supuestos primero. Cuando la implementación comience a complicarse, pídale que vuelva a la solución viable más pequeña. Al cambiar el código, manténgalo enfocado en el objetivo de la tarea. Al finalizar el trabajo, utilice pruebas, comandos o puntos de control explícitos para verificar el resultado.

La IA ya es muy capaz de escribir código, pero aún necesita buenas limitaciones de colaboración. El hecho de que un breve CLAUDE.md pueda atraer tanta atención demuestra que los desarrolladores no sólo necesitan modelos más inteligentes. También necesitan formas de trabajo más fiables.

En resumen:

Pensar antes de escribir para reducir suposiciones erróneas.
Mantenga las cosas simples para evitar el diseño excesivo.
Realizar cambios precisos para controlar el alcance del cambio.
Trabajar hacia metas con criterios de éxito verificables.

Estas cuatro reglas no son complicadas, pero son prácticas. El requisito previo para que la codificación de IA realmente mejore la eficiencia es no hacer que el modelo escriba más. Está haciendo que escriba con mayor precisión, con menos código y bajo un mejor control.

Uso más eficiente de la cuota de código de Claude: modelos, contexto, almacenamiento en caché y /compact

Sun, 19 Apr 2026 15:29:06 +0800

Muchos usuarios de Claude Code o Claude Max se encuentran con el mismo problema: incluso después de pagar por Pro, Max 5x o Max 20x, la advertencia de uso aparece rápidamente o tienen que esperar al siguiente reinicio. Esto resulta especialmente obvio cuando Claude Code lee muchos archivos, corrige errores complicados o ejecuta tareas largas en un proyecto grande.

El punto clave es este: el uso no se deduce linealmente por “minutos”. Depende del modelo, la longitud del contexto, los archivos adjuntos, el tamaño del código base, el historial de conversaciones, las llamadas a herramientas y la capacidad actual. En el mismo período de 5 horas, una persona puede trabajar durante mucho tiempo mientras que otra alcanza el límite en minutos. Por lo general, la cuenta no está rota; cada solicitud es simplemente demasiado pesada.

Esta nota recoge un conjunto de hábitos prácticos para utilizar la cuota de forma más eficiente.

01 Primero comprenda la ventana de uso de Claude

Tanto Claude Pro como Max tienen límites de uso. El uso de Claude Code se comparte con Claude en la web, el escritorio y el dispositivo móvil bajo la misma cuota de suscripción. El centro de ayuda de Anthropic explica que el recuento de mensajes depende de la longitud del mensaje, el tamaño del archivo adjunto, la duración de la conversación actual, el modelo o característica utilizada, y que el uso de Claude Code también se ve afectado por la complejidad del proyecto, el tamaño de la base del código y la configuración de aceptación automática.

Una forma sencilla de pensarlo:

Pro: adecuado para uso ligero y proyectos pequeños.
Max 5x: adecuado para un uso más frecuente y bases de código más grandes.
Máx. 20x: adecuado para colaboraciones diarias más intensas.
Las ventanas de uso se restablecen en sesiones de 5 horas.
Los mensajes largos, las conversaciones largas, los archivos grandes y las tareas complejas consumen el uso más rápidamente.
Los modelos más fuertes, como Opus, alcanzan los límites más rápido que Sonnet.

Así que “sólo lo usé durante 20 minutos” no explica mucho por sí solo. Lo que importa es cuánto contexto leyó Claude durante esos 20 minutos, qué modelo se utilizó, si los archivos grandes se procesaron repetidamente y si la misma larga conversación siguió acumulando más tareas.

02 Primer hábito: no optar por el modelo más caro

La familia de modelos Claude suele posicionarse así:

Opus: capacidad más potente, adecuada para razonamientos complejos, decisiones de arquitectura y errores difíciles.
Sonnet: capacidad y coste equilibrados, adecuado para la mayoría de las tareas de codificación cotidianas.
Haiku: más ligero, adecuado para clasificación, resumen y conversión de formato sencillos.

Para scripts diarios, pequeñas correcciones de errores, limpieza de documentación y explicación de código, Sonnet suele ser suficiente. Guarde Opus para casos como:

Diseño de arquitectura compleja.
Refactorizaciones profundas de múltiples archivos.
Errores difíciles de reproducir.
Solución de problemas de cadena larga.
Tareas donde el modelo normal está claramente estancado.

En Claude Code, use /model para cambiar de modelo o establezca el valor predeterminado en /config. Un hábito más constante es utilizar Sonnet de forma predeterminada y cambiar a Opus sólo en puntos clave, en lugar de ejecutar toda la tarea en Opus.

03 Segundo hábito: controlar el contexto, no arrastrar tareas antiguas

Cuanto más largo sea el contexto, más necesitará procesar Claude en cada turno y más rápido se consumirá el uso. Los documentos del Código Claude recomiendan explícitamente la gestión proactiva del contexto:

Utilice /clear cuando cambie a una tarea no relacionada.
Utilice /compact cuando finalice una fase pero debe permanecer un contexto importante.
Utilice /context para ver qué está ocupando espacio.
Configure una línea de estado si desea visibilidad continua del estado.

Un ritmo útil:

Small phase done: /compact
Large task done: /clear
Switching to unrelated work: /clear
Context usage getting high: /compact early

/compact resume el historial de conversaciones anteriores y al mismo tiempo conserva el estado de las tareas clave, las conclusiones, las rutas de los archivos y el trabajo restante. Reduce la cantidad de historial que se incluye en solicitudes posteriores. También puede agregar una breve instrucción:

`1`	`/compact Preserve changed files, test results, remaining TODOs, and key design decisions`

No espere a que se compacte automáticamente. Los documentos señalan que Claude Code se autocompacta cuando el contexto se acerca al límite, pero la compactación manual en los límites de fase suele ser más fácil de controlar.

04 Tercer hábito: las conversaciones largas y los archivos grandes hacen que cada solicitud sea más pesada

Mucha gente supone que “Sólo hice una pregunta más” debería ser barato. Pero en una conversación larga, esa pregunta puede tener detrás una gran cantidad de historia, resúmenes de archivos, definiciones de herramientas y reglas del sistema.

Las cosas que fácilmente inflan el contexto incluyen:

Conversaciones largas que nunca se aclaran.
Pedirle a Claude que lea archivos grandes completos.
Pegar registros largos, resultados de compilación o resultados de prueba.
Agregar muchas capturas de pantalla o imágenes a la vez.
Pidiéndole que escanee repetidamente todo el repositorio.
Un CLAUDE.md demasiado largo.
Demasiados servidores MCP habilitados.

Un enfoque más eficiente: pegue solo los errores clave de los registros, incluya solo las partes fallidas del resultado de la prueba y deje que Claude use rg, head, tail y la búsqueda de símbolos antes de leer solo las partes necesarias. Si el filtrado de la línea de comandos puede reducir el contenido, no pegue todo en contexto.

05 Cuarto hábito: comprender el almacenamiento en caché, pero no adorarlo

El almacenamiento en caché de avisos de Anthropic puede almacenar en caché prefijos de avisos repetidos. La vida útil predeterminada de la caché es de 5 minutos y también se admite una caché de 1 hora. Cuando se alcanza el caché, no es necesario reprocesar completamente el contexto repetido de gran tamaño, lo que ayuda a reducir los costos y mejorar la utilización del límite de velocidad.

Pero el almacenamiento en caché tiene limitaciones:

El contenido debe coincidir exactamente, incluidos texto e imágenes.
La caché predeterminada es de corta duración.
Cambiar modelos, herramientas, indicaciones del sistema o estructura de contexto puede reducir los accesos al caché.
Los tokens de salida no desaparecen debido al almacenamiento en caché; aún es necesario generar la respuesta.
La forma en que Claude Code utiliza el almacenamiento en caché es un detalle de implementación a nivel de producto, por lo que no lo trate como “memoria libre” permanente.

En la práctica, lo importante no es estudiar cada detalle del almacenamiento en caché. Mantiene la sesión estable:

Evite cambios frecuentes de modelo dentro de la misma fase.
No reescriba repetidamente grandes bloques de reglas a mitad de la tarea.
No sigas agregando nuevas imágenes dentro de la misma tarea.
No dejes una tarea larga inactiva durante demasiado tiempo y luego regreses con otra gran solicitud.
Utilice /compact en los límites de fase.

Esto hace que el contexto repetido sea más fácil de reutilizar y reduce el peso de las solicitudes posteriores.

06 Sobre las horas pico: evítalas cuando puedas, pero no las trates como una fórmula

La gente suele decir que ciertas horas se sienten más apretadas. El centro de ayuda de Anthropic es más cuidadoso: el recuento de mensajes puede verse afectado por la capacidad actual de Claude, la duración de la conversación, los archivos adjuntos, el modelo y las características. En otras palabras, la capacidad máxima puede afectar la experiencia, pero no trate una ventana horaria local específica como una regla permanente.

Sugerencias prácticas:

Realice grandes refactorizaciones y análisis exhaustivos en períodos en los que tanto su red como el servicio sean estables.
No comiences una tarea enorme justo antes de que planees alejarte.
Si espera salir por un largo tiempo, ejecute /compact o /clear primero.
Para ediciones pequeñas, no utilices Opus con un contexto largo a menos que realmente lo necesites.

Esto es más confiable que memorizar una regla fija de “no usarlo de X a Y”.

07 Slim Down CLAUDE.md, reglas, MCP y habilidades

Claude Code carga reglas del proyecto, información de herramientas y algo de contexto ambiental en la sesión. Los documentos oficiales también recomiendan separar las reglas generales de las reglas especializadas para que cada sesión no comience con una gran cantidad de texto no relacionado.

Una división útil:

CLAUDE.md: sólo reglas globales que siempre se aplican.
reglas: reglas específicas de ruta o de tipo de archivo.
habilidades: flujos de trabajo específicos, como publicación de publicaciones, implementación, generación de imágenes o confirmación de código.
MCP: solo habilita los servidores que la tarea actual realmente necesita.

Si CLAUDE.md tiene cientos o miles de líneas, cada sesión conlleva ese costo. Un mejor patrón es trasladar flujos de trabajo ocasionales a habilidades y cargarlos solo cuando sea necesario.

MCP es similar. Más herramientas no significan automáticamente más eficiencia. Los documentos de Claude Code mencionan el uso de /mcp para ver y deshabilitar servidores innecesarios, y /context para ver qué está consumiendo espacio de contexto.

08 Lista de comandos prácticos

Estos son los comandos diarios más útiles:

/model

Cambiar de modelo. Sonnet es un buen valor predeterminado; Utilice Opus para razonamientos complejos.

/clear

Borrar el contexto actual. Úselo cuando cambie a un trabajo no relacionado.

`1`	`/compact`

Comprimir el historial de conversaciones. Úselo cuando finalice una fase pero continúe la misma tarea.

`1`	`/context`

Inspeccione el uso del contexto y encuentre qué está ocupando espacio.

/status

Verifique la suscripción o el estado relacionado con el uso. El centro de ayuda de Anthropic también recomienda monitorear la asignación restante.

/mcp

Vea y administre servidores MCP y desactive las herramientas que no sean necesarias para la tarea actual.

Si utiliza la facturación API, /cost puede resultar útil. Pero para las suscripciones Pro/Max, los documentos de Claude Code explican que la estimación en dólares de “/cost” no es la referencia de facturación correcta; los suscriptores deberían confiar más en la información de uso como /stats y /status.

09 Un flujo de trabajo para ahorrar cuotas

Un flujo de trabajo práctico se ve así:

Ejecute /clear antes de comenzar una nueva tarea.
Utilice Sonnet de forma predeterminada.
Deje que Claude inspeccione primero la estructura del proyecto y los archivos clave, no todo el repositorio.
Ejecute /compact después de cada pequeña fase.
Cambie a Opus solo para bloqueadores duros.
Filtre registros, errores y pruebe los resultados antes de pegarlos.
Ejecute /clear una vez finalizada la tarea; No comience un nuevo trabajo con un contexto obsoleto.
Revise periódicamente CLAUDE.md, MCP y las habilidades para reducir el contexto siempre activo.

La idea central es simple: dejar que Claude vea sólo lo que realmente necesita para la tarea actual.

10 Resumen

El uso de Claude Code que se agota rápidamente no suele deberse a una sola cosa. A menudo es una combinación de modelos de alto costo, largas conversaciones sin borrar, demasiados archivos y registros, contexto de reglas y MCP pesado, reutilización de caché más débil y fluctuaciones máximas de capacidad.

Las soluciones prácticas también son sencillas:

Utilice Sonnet para el trabajo diario.
Guarde Opus para problemas verdaderamente complejos.
Utilice /compact cuando finalice una fase.
Utilice /clear al cambiar de tarea.
Utilice /context para encontrar el contexto hinchado.
Adelgazar CLAUDE.md, reglas, MCP y habilidades.
No volcar todo el repositorio, registros completos o lotes de imágenes grandes en contexto.

La cantidad de trabajo que puede soportar el mismo plan Pro o Max depende en gran medida de cómo gestiona el contexto. Si reduce el contexto y aclara los límites de las tareas, Claude Code se sentirá mucho más estable.

Referencias

Centro de ayuda de Claude: uso de Claude Code con su plan Pro o Max: https://support.claude.com/en/articles/11145838-using-claude-code-with-your-pro-or-max-plan
Centro de ayuda de Claude: Acerca del uso del plan Max de Claude: https://support.anthropic.com/en/articles/11014257-about-claude-s-max-plan-usage/
Claude Code Docs: Gestione los costes de forma eficaz: https://code.claude.com/docs/en/costs
Anthropic Docs: almacenamiento en caché rápido: https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching