AI Coding on KnightLi Blog

Clasificación de proyectos open source de AI en GitHub: de Coding Agent a bases de conocimiento RAG

Thu, 21 May 2026 08:53:13 +0800

Esta página organiza proyectos de AI en GitHub por dirección de uso: AI Coding y Coding Agents, skills y flujos Agent, RAG y bases de conocimiento, creación multimodal, modelos locales e inferencia, aplicaciones verticales y automatización, e infraestructura para desarrollar aplicaciones de AI. Cuando aparezcan nuevos proyectos, pueden añadirse con la misma estructura.

Resumen por categoría

Categoría	Proyectos	Para quién empezar aquí
AI Coding y Coding Agents	19	Usuarios que trabajan con Claude Code, Codex, Cursor, agents de terminal o automatización de repositorios
Skills y flujos Agent	7	Usuarios que quieren estandarizar AI Coding, investigación o flujos de creación
RAG, bases de conocimiento y memoria	7	Usuarios que necesitan búsqueda documental, bases de conocimiento, memoria de largo plazo, crawling web o extracción estructurada
Aplicaciones verticales y automatización	7	Usuarios interesados en finanzas, trading, monitoreo de Xianyu, control de escritorio, automatización de navegador y otros escenarios prácticos
Multimodal y creación de contenido	5	Usuarios que trabajan con imágenes, video, transcripción, librerías de prompts y distribución de contenido
Infraestructura para aplicaciones de AI	3	Desarrolladores que construyen apps de AI, automatización de navegador o toolchains Prompt/MCP
Modelos locales e inferencia	1	Usuarios interesados en DeepSeek local, motores de inferencia y adaptación de hardware

La distribución muestra varias direcciones frecuentes en los proyectos open source actuales de AI: las herramientas de AI Coding son las más numerosas, seguidas por flujos Agent, bases de conocimiento RAG y escenarios aplicados. Hay menos proyectos centrados solo en inferencia local porque mucho contenido de despliegue local se organiza alrededor de modelos, GPUs o planes de despliegue, no de un único proyecto de GitHub.

AI Coding y Coding Agents

Esta categoría se centra en comprensión de código, modificación de código, flujos de ingeniería y agents de terminal. Es el grupo más grande, con 19 proyectos.

Proyecto	Artículo	GitHub	Uso principal	Para quién
Ralph	Ralph: convertir Claude Code y Amp en un ciclo autónomo de desarrollo	snarktank/ralph	Guiar Claude Code / Amp por PRD, planificación, ejecución y revisión	Quienes quieren ordenar el flujo de AI Coding
Claude-Mem	Claude-Mem: memoria de largo plazo entre sesiones para Claude Code	thedotmack/claude-mem	Añadir memoria entre sesiones a Claude Code	Usuarios intensivos de Claude Code
Claude Code Hooks Mastery	Claude Code Hooks Mastery: introducción a 13 etapas del ciclo de hooks	disler/claude-code-hooks-mastery	Aprender el ciclo de vida de hooks y control de automatización	Quienes quieren personalizar Claude Code
Compound Engineering Plugin	Compound Engineering Plugin: convertir AI Coding en ciclos de planificación, ejecución y revisión	EveryInc/compound-engineering-plugin	Dividir AI Coding en planificación, ejecución y revisión	Usuarios que buscan ingeniería más disciplinada
free-claude-code	free-claude-code: conectar Claude Code a OpenRouter, DeepSeek y modelos locales	Alishahryar1/free-claude-code	Conectar Claude Code a distintos backends mediante proxy	Usuarios que quieren reducir costes
Hermes Agent	Qué es Hermes Agent: visión general, ventajas, inicio rápido y comparación con OpenClaw	NousResearch/hermes-agent	Framework local de Agent con herramientas y ejecución de tareas	Usuarios que quieren correr Agents locales
OpenHarness	Qué puede hacer OpenHarness como Agent Harness open source	HKUDS/OpenHarness	Agent Harness y ejecución multi-agent	Investigadores de orquestación Agent
CodexBridge	Usar Codex con modelos nacionales: API compatibles con OpenAI y CodexBridge	begonia599/CodexBridge	Conectar Codex a APIs compatibles con OpenAI	Usuarios que quieren usar Codex con modelos nacionales
ccx	Usar CCX para gestionar APIs compatibles con OpenAI para Codex y modelos nacionales	BenedictKing/ccx	Gestionar proxies de API para Claude, Codex, Gemini y más	Usuarios que alternan varios modelos
cc-haha	cc-haha: un escritorio de trabajo para Claude Code	NanmiCoder/cc-haha	Workspace de escritorio y entrada Computer Use para Claude Code	Usuarios de Claude Code que prefieren GUI
DeepSeek-TUI	DeepSeek-TUI: convertir DeepSeek V4 en un agente de programación en terminal	Hmbown/DeepSeek-TUI	Ejecutar un agente de programación DeepSeek en terminal	Usuarios de DeepSeek y línea de comandos
Open Design	Open Design: convertir Claude Code y Codex en herramientas de diseño AI	nexu-io/open-design	Llevar Claude Code / Codex a generación de diseño	Usuarios que quieren agentes para prototipos
agentmemory	agentmemory: memoria persistente para Claude Code, Codex y Cursor	rohitg00/agentmemory	Añadir memoria persistente a coding agents	Desarrolladores con proyectos largos
Graphify	Graphify: convertir una base de código en un grafo consultable por AI	safishamsi/graphify	Convertir código en grafo de conocimiento para reducir lecturas repetidas	Usuarios con bases de código grandes
CC Switch	CC Switch: gestionar Claude Code, Codex, Gemini CLI y OpenClaw en una herramienta de escritorio	farion1231/cc-switch	Gestionar varias CLI de AI y cambios de cuenta/configuración	Usuarios de varias CLI
Warp	Warp open source: del terminal al Agentic Development Environment	warpdotdev/warp	Terminal y entorno de desarrollo agentic	Usuarios intensivos de terminal
opencode	opencode vs Claude Code vs Codex: guía de herramientas open source de AI Coding	anomalyco/opencode	Agent open source para AI Coding	Quienes buscan alternativas a Claude Code / Codex
9Router	9Router: conectar Claude Code, Codex y Cursor a un único router de AI	decolua/9router	Ruteo de modelos para AI Coding y control de coste de tokens	Usuarios multi-herramienta y multi-modelo
goose	goose: AI Agent open source para escritorio, CLI y API	aaif-goose/goose	Agent open source en escritorio, CLI y API	Usuarios que quieren un workspace Agent general

Skills y flujos Agent

Esta categoría convierte capacidades de AI en skills, procesos y especificaciones repetibles. Incluye 7 proyectos.

Proyecto	Artículo	GitHub	Uso principal	Para quién
mattpocock/skills	Rechazar Vibe Coding: el repo skills de Matt Pocock añade restricciones de ingeniería	mattpocock/skills	Usar skills para controlar flujos de AI Coding	Quienes quieren disciplina de ingeniería para Agents
Superpowers	Superpowers: devolver Coding Agents al flujo de ingeniería	obra/superpowers	Framework de skills agentic y metodología de desarrollo	Quienes quieren flujos sistemáticos con Coding Agents
Prompt-Vault	Prompt-Vault: biblioteca de especificaciones de prompts para probar AI Coding	w512/Prompt-Vault	Reunir prompts de prueba para AI Coding	Evaluadores de modelos y herramientas
web-video-presentation	web-video-presentation: skill Agent para convertir artículos en videos web grabables	ConardLi/garden-skills	Convertir artículos en videos web grabables	Creadores y usuarios de automatización
nuwa-skill	nuwa-skill: convertir “destilar una persona” en un flujo ejecutable	alchaincyf/nuwa-skill	Reproducir estilo expresivo y flujo de pensamiento con skill	Usuarios que construyen Agents de estilo
Scientific Agent Skills	Scientific Agent Skills: entregar flujos científicos a AI Agents	K-Dense-AI/scientific-agent-skills	Colección de skills para investigación científica	Investigadores, analistas y redactores técnicos
easy-vibe	easy-vibe: mapa de aprendizaje para principiantes de Vibe Coding	datawhalechina/easy-vibe	Mapa de aprendizaje de Vibe Coding	Principiantes de AI Coding

RAG, bases de conocimiento y memoria

Esta categoría aborda búsqueda documental, construcción de bases de conocimiento, memoria de largo plazo y extracción estructurada. Incluye 7 proyectos.

Proyecto	Artículo	GitHub	Uso principal	Para quién
LangExtract	Google LangExtract: extraer datos estructurados de textos largos con LLM	google/langextract	Extraer información estructurada de textos largos	Usuarios de extracción de información y datos
qmd	qmd: búsqueda local en Markdown para AI Agents	tobi/qmd	Búsqueda local en documentos Markdown	Usuarios que gestionan conocimiento en Markdown
Firecrawl	Firecrawl: búsqueda, crawling e interacción web para AI Agents	firecrawl/firecrawl	Crawling web, búsqueda y entrada de datos estructurados	Usuarios de RAG e ingestión de datos para Agents
RAGFlow	RAGFlow: funciones y uso de un motor RAG open source	infiniflow/ragflow	Motor RAG open source	Bases de conocimiento empresariales y Q&A documental
OpenHuman	OpenHuman: ruta de escritorio para AI Agent personal open source	tinyhumansai/openhuman	Agent personal local-first y capa de memoria	Usuarios que quieren integrar datos personales
OpenKB	OpenKB: compilar documentos en bases de conocimiento LLM actualizables	VectifyAI/OpenKB	Compilar documentos en bases de conocimiento actualizables	Mantenedores de documentación y conocimiento
PageIndex	PageIndex: indexación RAG razonada sin bases vectoriales	VectifyAI/PageIndex	Indexación documental razonada sin bases vectoriales	Usuarios que siguen nuevas rutas de RAG

Multimodal y creación de contenido

Esta categoría cubre imágenes, video, transcripción y distribución de contenido. Incluye 5 proyectos.

Proyecto	Artículo	GitHub	Uso principal	Para quién
rembg	rembg: herramienta local para quitar fondos de imágenes	danielgatis/rembg	Eliminación local de fondos	E-commerce, diseño y procesamiento de imágenes
awesome-gpt-image-2-prompts	Biblioteca de prompts GPT-Image 2: e-commerce, pósters, retratos y UI	EvoLinkAI/awesome-gpt-image-2-prompts	Prompts y casos para GPT-Image 2	Usuarios de AI Art y prompts
faster-whisper	faster-whisper: motor Whisper más rápido para transcripción	SYSTRAN/faster-whisper	Speech-to-text de alto rendimiento	Usuarios de subtítulos, transcripción y voz
Pixelle-Video	Pixelle-Video: motor AI open source para generar videos cortos desde un tema	AIDC-AI/Pixelle-Video	Flujo para generar videos cortos desde un tema	Creadores de videos cortos y AIGC
AiToEarn	¿Demasiadas plataformas de contenido? AiToEarn usa Agents para ahorrar trabajo	yikart/AiToEarn	Distribución multicanal y automatización para creadores	Operadores de contenido y creadores

Modelos locales e inferencia

Esta categoría se centra en ejecución local de modelos y experimentos de inferencia. Actualmente tiene menos proyectos, con 1 proyecto.

Proyecto	Artículo	GitHub	Uso principal	Para quién
ds4	Ejecutar DeepSeek 4 localmente: Antirez ds4 en Apple Silicon Mac	antirez/ds4	Experimentar con DeepSeek 4 en Apple Silicon	Usuarios de modelos locales e inferencia

Aplicaciones verticales y automatización

Esta categoría aplica Agents o AI a finanzas, trading, navegadores, escritorio, monitoreo de comercio electrónico y otros escenarios concretos. Incluye 7 proyectos.

Proyecto	Artículo	GitHub	Uso principal	Para quién
TradingAgents-CN	TradingAgents-CN: framework multi-agent para investigación de trading financiero en chino	hsliuping/TradingAgents-CN	Framework multi-agent de investigación financiera	Investigadores quant, financieros y de Agents
FinceptTerminal	FinceptTerminal: terminal financiero open source, investigación quant y workspace AI Agent	Fincept-Corporation/FinceptTerminal	Terminal financiero, investigación quant y workspace Agent	Analistas financieros y usuarios quant
Anthropic financial-services	Anthropic financial-services: plantillas reutilizables para escenarios Agent financieros	anthropics/financial-services	Plantillas de Agents para servicios financieros	Usuarios que crean soluciones AI financieras
ai-goofish-monitor	ai-goofish-monitor: sistema open source de monitoreo AI para productos de Xianyu	Usagi-org/ai-goofish-monitor	Monitoreo de productos y automatización de Xianyu	Usuarios de monitoreo de segunda mano
CloakBrowser	CloakBrowser: navegador más humano para Playwright y Puppeteer	CloakHQ/CloakBrowser	Entorno de automatización de navegador más humano	Automatización de navegador y operación Agent
UI-TARS-desktop	¿Dejar que AI use el ordenador? UI-TARS-desktop conecta escritorio, navegador y herramientas	bytedance/UI-TARS-desktop	Agent para operar escritorio, navegador y herramientas	Usuarios que quieren que AI opere el ordenador
AI-Trader	Qué es AI-Trader: plataforma para señales y simulación de trading con Agents	HKUDS/AI-Trader	Señales de trading y simulación con AI Agent	Investigadores de trading y Agents financieros

Infraestructura para aplicaciones de AI

Esta categoría ofrece componentes base para construir aplicaciones de AI y toolchains Agent. Incluye 3 proyectos.

Proyecto	Artículo	GitHub	Uso principal	Para quién
Prompt Optimizer	Prompt Optimizer: optimización, pruebas y herramientas MCP open source	linshenkx/prompt-optimizer	Optimización de prompts, pruebas y MCP	Usuarios de prompt engineering y ajuste de apps
Playwright CLI	Playwright CLI: instalación, skills, sesiones y comandos comunes	microsoft/playwright-cli	CLI de automatización de navegador para coding agents	Usuarios Agent que necesitan operar navegador
Vercel AI SDK	Qué es Vercel AI SDK: toolkit unificado para apps AI en TypeScript	vercel/ai	SDK para aplicaciones AI en TypeScript	Desarrolladores front-end y full-stack

Graphify resuelve la mayor limitación de Claude Code: convertir un codebase en un grafo consultable por IA

Thu, 21 May 2026 08:02:32 +0800

safishamsi/graphify es una herramienta de grafo de conocimiento para asistentes de programación con IA. Su objetivo es directo: tomar el código, documentación, SQL schemas, scripts, papers, imágenes, video y audio dentro de una carpeta de proyecto, convertirlos en un grafo consultable y evitar que los asistentes de IA dependan solo de grep, lectura completa de archivos o búsquedas improvisadas para entender el proyecto.

Proyecto: safishamsi/graphify

En el momento de preparar este artículo, la página de GitHub muestra unas 50.2k stars y 5.4k forks, con licencia MIT. El README lo describe así: escribe /graphify en tu asistente de programación con IA y mapeará todo el proyecto como un grafo de conocimiento consultable.

El problema central que resuelve

Los asistentes de programación con IA son cada vez más potentes, pero en codebases reales todavía encuentran varios problemas:

No saben cómo se conectan los módulos clave.
Leen muchos archivos, pero no forman un mapa general de arquitectura.
La búsqueda encuentra texto, pero no dependencias aguas arriba y aguas abajo.
Código, database schema, documentación e infraestructura están dispersos.
En colaboración de equipo, cada persona puede tener un modelo mental distinto de la estructura del proyecto.

Graphify intenta añadir una “capa de memoria” al proyecto. Conecta entidades de código, conceptos documentales, tablas de base de datos, configuración, notas de diseño y relaciones entre archivos para que el asistente de IA pueda consultar el grafo en lugar de escanear archivos desde cero cada vez.

Uso mínimo

El uso mínimo de Graphify es muy simple. Tras instalarlo, escribe esto en tu asistente de programación con IA:

`1`	`/graphify .`

En PowerShell, el / inicial se interpreta como separador de ruta, así que en Windows PowerShell usa:

`1`	`graphify .`

Después de ejecutarlo, genera el directorio graphify-out/ con tres archivos principales:

graphify-out/
├── graph.html
├── GRAPH_REPORT.md
└── graph.json

Cada archivo cumple una función:

graph.html: grafo interactivo que se abre en el navegador, con nodos clicables, filtros y búsqueda.
GRAPH_REPORT.md: puntos destacados del proyecto, conceptos clave, conexiones inesperadas y preguntas sugeridas.
graph.json: grafo completo, consultable después sin volver a leer todos los archivos.

Para generar una página de arquitectura más legible con diagramas Mermaid de flujo de llamadas, ejecuta:

`1`	`graphify export callflow-html`

Instalación y soporte de plataformas

El paquete de Graphify en PyPI se llama graphifyy, con doble y. El README advierte que otros paquetes graphify* en PyPI no están afiliados al proyecto, aunque el comando CLI sigue siendo graphify.

La instalación recomendada es:

`1`	`uv tool install graphifyy`

También puedes usar:

1
2

pipx install graphifyy
pip install graphifyy

Después, regístralo con tu asistente de IA:

`1`	`graphify install`

El proyecto soporta muchas plataformas, incluidas Claude Code, Codex, OpenCode, GitHub Copilot CLI, VS Code Copilot Chat, Aider, Cursor, Gemini CLI, Kimi Code, Kiro y Google Antigravity. Cada plataforma puede usar comandos distintos, por ejemplo:

graphify install --platform codex
graphify install --platform gemini
graphify cursor install
graphify antigravity install

Los usuarios de Codex también deben añadir esto bajo [features] en ~/.codex/config.toml:

`1`	`multi_agent = true`

El README también indica que Codex usa $graphify, no /graphify.

Qué archivos puede procesar

Graphify cubre muchos tipos de entrada.

En código, soporta 31 lenguajes, incluidos Python, TypeScript, JavaScript, Go, Rust, Java, C/C++, Ruby, C#, Kotlin, Scala, PHP, Swift, Lua, Zig, PowerShell, SQL, Shell, JSON y más.

En documentación, soporta:

.md
.mdx
.qmd
.html
.txt
.rst
.yaml
.yml

También puede ampliarse con dependencias opcionales:

pip install "graphifyy[pdf]"
pip install "graphifyy[office]"
pip install "graphifyy[video]"
pip install "graphifyy[mcp]"
pip install "graphifyy[neo4j]"
pip install "graphifyy[sql]"
pip install "graphifyy[all]"

pdf sirve para extracción PDF, office para .docx y .xlsx, video para transcripción de video y audio, mcp para MCP stdio server, neo4j para enviar a Neo4j, y sql para extracción de SQL schema.

Qué valor tiene el informe generado

GRAPH_REPORT.md no es un resumen normal. Selecciona relaciones del proyecto que son especialmente útiles para asistentes de IA.

El README menciona contenidos como:

God nodes: los conceptos centrales más conectados del proyecto.
Surprising connections: enlaces inesperados entre archivos o módulos.
The why: razones de diseño extraídas de comentarios, docstrings y documentos de diseño.
Suggested questions: preguntas que el grafo está especialmente preparado para responder.
Confidence tags: cada relación se marca como EXTRACTED, INFERRED o AMBIGUOUS.

Esto es importante. Una búsqueda normal solo dice “dónde aparece esta palabra”. Un grafo puede responder “con qué módulos, configuraciones, tablas y documentos se conecta este concepto”. En codebases grandes, eso se acerca más a entender la arquitectura que una simple búsqueda de texto completo.

Comandos comunes

Comandos comunes de Graphify:

/graphify .
/graphify ./docs --update
/graphify . --cluster-only
/graphify . --no-viz
/graphify . --wiki
graphify export callflow-html
/graphify query "what connects auth to the database?"
/graphify path "UserService" "DatabasePool"
/graphify explain "RateLimiter"

También puedes añadir un paper o video al grafo:

1
2

/graphify add https://arxiv.org/abs/1706.03762
/graphify add <youtube-url>

Para análisis asistido de PR:

graphify prs
graphify prs 42
graphify prs --triage
graphify prs --conflicts

Estos comandos encajan con revisiones de código: ver qué comunidades del grafo afecta un PR, si hay riesgo de conflicto con otros PRs y qué review queue conviene priorizar.

Relación con MCP, Neo4j y CI

Graphify no solo genera un grafo HTML. También puede exponer el grafo a asistentes de IA para uso repetido.

Por ejemplo, puedes iniciar un MCP server:

`1`	`python -m graphify.serve graphify-out/graph.json`

El MCP server ofrece capacidades como query_graph, get_node, get_neighbors, shortest_path, list_prs, get_pr_impact y triage_prs.

También soporta exportación o push a Neo4j:

1
2

/graphify ./raw --neo4j
/graphify ./raw --neo4j-push bolt://localhost:7687

Para trabajo en equipo, el README recomienda poder commitear graphify-out/, de modo que todos empiecen con el mismo mapa del proyecto. También puedes ejecutar:

`1`	`graphify hook install`

Así el grafo se reconstruye automáticamente después de cada git commit y se configura un merge driver para evitar que graph.json quede con marcadores de conflicto cuando varias personas commitean en paralelo.

Privacidad y coste

El README de Graphify explica bastante bien los límites de privacidad.

Los archivos de código se parsean localmente con tree-sitter y no generan llamadas API. Video y audio pueden transcribirse localmente con faster-whisper. Docs, PDFs e imágenes para extracción semántica pasan por la API del modelo usado por tu asistente de IA.

Si usas headless graphify extract, puede que necesites estas variables de entorno:

ANTHROPIC_API_KEY
GEMINI_API_KEY
GOOGLE_API_KEY
OPENAI_API_KEY
DEEPSEEK_API_KEY
MOONSHOT_API_KEY
OLLAMA_BASE_URL

También pueden usarse backends como Ollama local, AWS Bedrock o Claude Code CLI. El README indica además que el proyecto no tiene telemetry, usage tracking ni analytics.

En la práctica, conviene recordar que parsear código localmente no significa que todo se quede offline. Si intervienen docs, PDFs, imágenes o modelos cloud, hay que revisar backend, API keys, cumplimiento empresarial y límites de datos.

Escenarios adecuados

Graphify encaja con varios tipos de usuarios:

Desarrolladores que quieren que Claude Code, Codex, Cursor y Gemini CLI entiendan mejor la estructura del proyecto.
Personas que necesitan comprender rápido un codebase grande y desconocido.
Equipos que quieren analizar juntos código, SQL schema, documentación y configuración.
Personas que hacen revisión de arquitectura, PR review o análisis de impacto de refactors.
Equipos que quieren exponer conocimiento del proyecto como herramienta MCP para Agents.
Líderes técnicos que quieren conservar un “mapa del proyecto” para el equipo.

No es necesario para todos los proyectos. En scripts pequeños, demos puntuales o repositorios muy simples, una búsqueda normal y el README quizá basten. El valor de Graphify aparece con más claridad en proyectos con muchos módulos, mucha documentación, mucha colaboración y uso frecuente de asistentes de IA.

Resumen

Graphify importa porque mueve el contexto de los asistentes de programación con IA desde “leer archivos temporalmente” hacia “un grafo de conocimiento del proyecto consultable y persistente”.

Para desarrolladores, no reemplaza el IDE, la búsqueda o el LSP. Añade una capa de memoria estructurada para asistentes de IA: qué módulos importan, qué conceptos están muy conectados, qué documentos explican decisiones de diseño y qué comunidades puede afectar un PR. A medida que herramientas Agent como Codex, Claude Code, Gemini CLI y Antigravity se vuelvan más comunes, esta capa de grafo del proyecto será cada vez más útil.

Referencias:

GitHub: safishamsi/graphify

Gemini 3.5 ya está aquí: Flash llega primero y Google pone el foco en agentes y tareas largas

Wed, 20 May 2026 22:51:31 +0800

Google lanzó oficialmente la serie Gemini 3.5 el 20 de mayo de 2026. El primer modelo disponible es Gemini 3.5 Flash. Su posicionamiento no es solo chat, sino agentes, generación de código y ejecución de tareas complejas de larga duración.

El mensaje de esta presentación es claro: Google quiere que Gemini 3.5 no solo responda preguntas, sino que también planifique, ejecute, compruebe resultados y mantenga el avance en flujos de trabajo de varios pasos.

Gemini 3.5 Flash llega primero

Gemini 3.5 Flash ya está disponible para varios tipos de usuarios:

Los usuarios generales pueden probarlo en la app Gemini y en AI Mode de Google Search.
Los desarrolladores pueden usarlo mediante Google Antigravity, Google AI Studio y la Gemini API en Android Studio.
Los usuarios empresariales pueden acceder a él mediante Gemini Enterprise Agent Platform y Gemini Enterprise.

Google también dijo que Gemini 3.5 Pro sigue en desarrollo, ya se usa internamente en Google y se espera para el próximo mes.

Esto indica que la serie 3.5 mantiene la división entre Flash y Pro: Flash enfatiza velocidad, costo y ejecución a escala, mientras que Pro probablemente apuntará a escenarios más complejos y con mayores requisitos de capacidad.

El foco está en agentes y código

Google describe Gemini 3.5 Flash como uno de sus modelos más fuertes para agentes y programación. El anuncio afirma que supera algunos resultados de Gemini 3.1 Pro en benchmarks de código y agentes como Terminal-Bench 2.1, GDPval-AA, MCP Atlas y CharXiv Reasoning.

La mayoría de usuarios no necesita obsesionarse con cada número. Lo más importante es que Google está llevando la capacidad del modelo hacia flujos ejecutables: no solo escribir código, sino migrar proyectos antiguos, desarrollar aplicaciones complejas, organizar reportes financieros, analizar datos y ejecutar pruebas repetidas.

Dentro del framework de desarrollo Antigravity, Gemini 3.5 Flash puede usar varios subagents colaborativos para manejar tareas grandes. Google mostró ejemplos como analizar el paper de AlphaZero y crear un juego jugable, convertir código legacy a Next.js y generar paisajes urbanos y opciones de UI en paralelo.

La dirección es clara: las herramientas de programación con IA están pasando de “generar un fragmento de código” a “coordinar varios agentes para completar un proyecto”.

UI multimodal y gráficos más potentes

Gemini 3.5 Flash se apoya en la base multimodal de Gemini 3. Google dice que puede generar interfaces web más ricas, animaciones interactivas y contenido visual.

El anuncio incluye ejemplos como:

Crear animaciones interactivas para papers de investigación.
Convertir descripciones de texto en modelos de hardware interactivos.
Generar un concepto completo de marca para una campaña escolar de recaudación.
Producir varias opciones de UX para un flujo de checkout en poco tiempo.

Esto importa para desarrolladores y equipos de producto. El modelo ya no solo escribe explicaciones. También puede participar en prototipos frontend, diseño de interacción y visualización.

Uso empresarial: automatizar flujos que consumen tiempo

Google citó varios ejemplos de socios. Shopify usa subagents para analizar datos complejos y predecir crecimiento de comerciantes. Macquarie Bank prueba 3.5 Flash con documentos de más de 100 páginas para acelerar la apertura de cuentas. Salesforce lo integra en Agentforce. Ramp lo usa para mejorar OCR en facturas complejas. Xero usa agentes de IA para procesos administrativos. Databricks usa flujos automatizados para monitorear anomalías de datos y sugerir correcciones.

Estos casos apuntan a la misma tendencia: la adopción empresarial de modelos grandes se está moviendo de preguntas puntuales a automatización de procesos. Que un modelo sea barato, rápido y estable en tareas largas puede importar más que una respuesta aislada muy llamativa.

Gemini Spark: un agente personal de IA

Google también anunció Gemini Spark, un agente personal de IA impulsado por Gemini 3.5 Flash. Su objetivo es ejecutarse durante largos periodos y realizar tareas de forma proactiva bajo la guía del usuario.

Gemini Spark ya empezó a desplegarse para testers de confianza. Google planea abrir una beta la próxima semana para suscriptores de Google AI Ultra en Estados Unidos.

Vale la pena seguir esta parte. Google Search, la app Gemini, Android, Workspace y el ecosistema del navegador ya están presentes en muchas áreas de la vida digital personal. Si un agente personal puede conectarse con estas entradas, su impacto puede ser mayor que el de un chatbot aislado.

La seguridad se mueve más arriba en el proceso

Google dice que Gemini 3.5 fue desarrollado bajo su Frontier Safety Framework, con protecciones reforzadas para seguridad de la información y riesgos CBRN. El anuncio también menciona herramientas de interpretabilidad para ayudar a examinar y entender el razonamiento del modelo antes de entregar respuestas.

Esto muestra que los lanzamientos de modelos frontera ya no son solo una competencia de capacidad. Cuanto más se enfatizan agentes, ejecución autónoma y tareas largas, más importantes se vuelven los controles de seguridad, la tasa de rechazos erróneos, la prevención de salidas dañinas y la interpretabilidad.

Cómo mirar Gemini 3.5

Gemini 3.5 Flash no es solo otro lanzamiento de modelo. Parece más bien la apuesta de Google por la siguiente forma de los productos de IA: modelos que llaman herramientas, dividen tareas, coordinan ejecución, generan UI y entran en flujos personales y empresariales.

Para desarrolladores, lo importante será la experiencia real en Google Antigravity, AI Studio, Gemini API y Android Studio. Para empresas, la pregunta es si puede reducir trabajo manual de forma estable en flujos reales, no solo sacar buenos resultados en benchmarks.

Gemini 3.5 Pro todavía no está disponible públicamente. Cuando Pro llegue, las diferencias entre Flash y Pro en capacidad, precio, velocidad y manejo de contexto determinarán para qué escenarios de producción conviene cada uno.

Referencias:

Google Blog: Gemini 3.5

agentmemory: memoria persistente para Claude Code, Codex, Cursor y otros agentes de programación

Tue, 19 May 2026 10:56:50 +0800

rohitg00/agentmemory es un sistema de memoria persistente para agentes de programación con IA. Su objetivo es claro: que Claude Code, Codex CLI, Cursor, Gemini CLI, OpenCode y herramientas similares no tengan que volver a aprender el contexto del proyecto, las decisiones de arquitectura y los problemas históricos en cada sesión nueva.

URL del proyecto: https://github.com/rohitg00/agentmemory

En el momento de escribir este artículo, la API de GitHub mostraba unas 13k estrellas, TypeScript como lenguaje principal y licencia Apache-2.0. El README lo describe como “Persistent memory for AI coding agents”.

Qué problema resuelve

Un dolor habitual de los coding agents es la fragmentación de memoria. Puedes pedir a un agente que arregle un problema de autenticación hoy y abrir una conversación nueva mañana, pero quizá ya no recuerde:

Por qué se tomó una decisión de arquitectura.
Qué archivos son delicados.
Qué bugs se corrigieron antes.
Qué comandos, herramientas o servicios locales usa el proyecto.
Qué convenciones sigue el equipo.

Las notas estáticas ayudan, pero a menudo se olvidan o no están conectadas al flujo activo. agentmemory intenta ofrecer una capa de memoria compartida entre distintas herramientas de programación con IA.

Agentes compatibles

El README menciona Claude Code, Codex CLI, Cursor, Gemini CLI, OpenCode y otras herramientas compatibles con MCP. La idea central es exponer memoria mediante un servicio local, MCP, hooks e integraciones, para que varios asistentes compartan el mismo contexto de proyecto.

Esto es útil para equipos que cambian de herramienta. Un desarrollador puede usar Cursor, otro Claude Code y la automatización Codex CLI. Una capa de memoria compartida reduce explicaciones repetidas.

Inicio rápido

Instalación global:

npm install -g @agentmemory/agentmemory
agentmemory
agentmemory demo
agentmemory connect claude-code

También se puede ejecutar con npx:

`1`	`npx @agentmemory/agentmemory`

El servicio local queda disponible en:

`1`	`http://localhost:3113`

En la práctica, el flujo suele ser iniciar el servicio, conectar el asistente de programación y dejar que el agente lea o escriba memorias del proyecto durante el desarrollo.

Diferencia con archivos de memoria estáticos

Muchos equipos ya mantienen AGENTS.md, CLAUDE.md, README o documentación local. Esos archivos son útiles, pero estáticos. No capturan automáticamente historial de sesiones, resultados de tareas o decisiones recurrentes.

agentmemory se parece más a un servicio de contexto persistente. Puede guardar y mostrar memorias relevantes para el proyecto o la tarea actual. No busca reemplazar la documentación, sino hacer más reutilizable el contexto de trabajo.

Escenarios típicos

Puede servir para:

Recordar pasos de setup y comandos frecuentes.
Registrar por qué se evitó un refactor arriesgado.
Guardar notas sobre tests inestables o servicios locales.
Compartir terminología de dominio entre asistentes.
Ayudar a continuar trabajo después de abrir una sesión nueva.

Tiene más valor en productos de larga vida, monorepos y proyectos con muchas convenciones implícitas.

Precauciones

La calidad de la memoria importa. Si se guarda información vieja o incorrecta, los agentes futuros pueden repetir el error. Las memorias importantes deberían ser cortas, claras y revisables.

También importa la privacidad. No conviene guardar secretos, API keys, datos de clientes ni información sensible de producción si el modelo de seguridad no está claro.

Por último, la memoria no sustituye las pruebas. Ayuda a entender contexto, pero la garantía final viene de revisión de código, tests y verificación.

Para quién es

agentmemory encaja con desarrolladores que usan varias herramientas de AI coding, equipos con codebases grandes y usuarios que necesitan que un agente continúe trabajo anterior. No es imprescindible para scripts pequeños de una sola vez.

Resumen

agentmemory es interesante porque trata la memoria como infraestructura para AI coding, no como un pequeño truco de prompt. Si los coding agents entran en el desarrollo diario, la memoria persistente de proyecto se vuelve una pieza práctica que faltaba.

Guía para ahorrar tokens en Claude Code: cómo modelos, MCP, CLAUDE.md y Skills afectan la caché

Mon, 18 May 2026 18:30:24 +0800

En tareas largas con Claude Code, la tasa de aciertos de Prompt Cache afecta directamente el costo y la velocidad. Muchos usuarios saben que la caché puede ahorrar tokens, pero no qué acciones hacen que falle de repente.

La forma más simple de entenderlo es imaginar cada petición como una cadena de contexto de izquierda a derecha:

`1`	`tools -> system -> CLAUDE.md / skills -> messages`

Cuanto más a la izquierda está un contenido, más estable debería ser y mayor es el beneficio de cachearlo. Si cambia una sección de la izquierda, todo lo que va después puede necesitar recalcularse. Si cambia algo a la derecha, el impacto suele ser menor.

Optimizar Prompt Cache en Claude Code no es magia. La regla es simple: antes de iniciar una tarea, prepara modelo, servidores MCP, Skills, CLAUDE.md y el contexto base. Una vez iniciada, cambia lo menos posible esa parte fija.

Prompt Cache no guarda texto plano

Prompt Cache no es solo una caché de cadenas de texto. En la inferencia Transformer, lo importante es el estado Key/Value calculado por las capas de atención a partir del prefijo de contexto, lo que solemos llamar KV cache.

Eso implica dos cosas:

Si el prefijo se mantiene estable, parte del cálculo previo puede reutilizarse.
Si cambian el modelo, las definiciones de herramientas, el prompt del sistema o los mensajes iniciales, las entradas antiguas de caché pueden dejar de coincidir.

La documentación de Anthropic resume la jerarquía de invalidación como tools -> system -> messages. Cambiar definiciones de herramientas puede invalidar toda la caché; cambios en system afectan system y messages; cambios en messages afectan sobre todo la caché de mensajes.

Claude Code añade otras fuentes de contexto como CLAUDE.md, Skills, MCP, plugins y subagents, así que es fácil romper la caché sin querer.

Asesino de caché 1: cambiar de modelo a mitad de tarea

Cambiar de modelo es una de las operaciones más caras.

Prompt Cache está aislada por modelo. Opus, Sonnet y Haiku tienen arquitecturas y pesos distintos, así que el KV cache calculado desde el mismo texto no es intercambiable. Si construyes un contexto largo en Opus y luego cambias a Sonnet, Sonnet no puede reutilizar la caché de Opus.

Esto produce un resultado poco intuitivo: cambiar a un modelo más barato a mitad de tarea puede hacer inútil la caché acumulada. El contexto que podría leerse a precio de cache read quizá tenga que escribirse y calcularse de nuevo.

Un patrón más estable:

Mantén la conversación principal en un solo modelo.
Usa un subagent para tareas laterales que puedan ejecutarse con un modelo más barato.
Deja que el agente lateral busque, explore o resuma, y devuelva un resultado breve a la conversación principal.

Así el prefijo largo de la conversación principal se mantiene estable y la caché acierta con más consistencia.

Asesino de caché 2: añadir MCP o recargar plugins a mitad de tarea

MCP proporciona herramientas a Claude Code. Al añadir un servidor MCP, cambia la lista de herramientas, y las definiciones de herramientas están en el extremo izquierdo de la cadena de contexto.

Desde la perspectiva de Prompt Cache, cuando cambia la lista de herramientas, system y messages pueden necesitar recalcularse. Si usas muchos MCP, las definiciones de herramientas pueden ocupar muchos tokens, y el costo de invalidación se nota.

Un detalle importante: Claude Code suele leer la configuración MCP al iniciar la sesión. Cambiar configuración durante la sesión no siempre afecta de inmediato. Los momentos peligrosos son reiniciar, hacer resume, recargar plugins o reconstruir la lista de herramientas.

Recomendaciones:

Instala los MCP necesarios antes de iniciar una tarea larga.
Evita descubrir a mitad de trabajo que falta una herramienta y recargar.
Reduce los MCP habilitados por defecto cuando sea posible.
No mantengas servidores MCP raramente usados siempre activos.

Las definiciones de herramientas estables son la base de una Prompt Cache estable.

Asesino de caché 3: editar CLAUDE.md durante la sesión

CLAUDE.md es el archivo de memoria de proyecto de Claude Code. Sirve para comandos de build, tests, convenciones de arquitectura, estilo de código y restricciones del proyecto.

Es útil, pero también entra en el contexto. La ayuda de Claude explica que CLAUDE.md se lee al iniciar la sesión y se entrega como mensaje de usuario. También se beneficia de Prompt Cache: la primera petición paga el precio completo de entrada, y las siguientes pueden usar el precio menor de cache read si la caché sigue válida.

El problema es que CLAUDE.md se identifica por contenido. Si cambias el archivo, la caché antigua deja de coincidir.

Por eso conviene no editar CLAUDE.md con frecuencia durante tareas largas. Mejor:

Revisa si CLAUDE.md es suficiente antes de empezar.
Coloca reglas estables en el archivo e instrucciones temporales en la conversación.
No edites la memoria de largo plazo por una necesidad puntual.
Si debes cambiarlo, trata la siguiente fase como una nueva sesión o etapa.

CLAUDE.md debería ser guía estable de proyecto, no un borrador temporal que cambia cada ronda.

Asesino de caché 4: instalar o actualizar Skills a mitad de tarea

Skills también forman parte del contexto. Instalar una Skill nueva, actualizar una Skill o cambiar la lista de Skills cambia lo que se inyecta en la sesión.

Estos cambios suelen aplicarse al recargar, reanudar o abrir una nueva sesión. Cuando messages se reconstruye, las entradas antiguas de caché pueden dejar de servir.

La recomendación es similar a MCP:

Decide qué Skills necesitas antes de empezar.
Mantén estable el conjunto de Skills para tareas similares.
Evita instalar Skills en mitad de una tarea larga.
Si instalas una Skill nueva, trátalo como inicio de una nueva etapa.

Para flujos repetibles como producción de contenido, review, despliegue o traducción, mantener un conjunto fijo de Skills ayuda a estabilizar la estructura del contexto.

Asesino de caché 5: estar inactivo más allá del TTL

Prompt Cache no dura para siempre. Un TTL común está en el orden de minutos, y la documentación relacionada con Claude Code suele hablar de una ventana cercana a cinco minutos. Pasado el TTL, incluso la misma petición puede requerir reconstruir la caché.

Esto explica una sensación común en tareas largas: todo iba rápido y barato, sales por un café, vuelves y el costo de tokens sube otra vez.

Es fácil que ocurra. Lees la salida de Claude Code, inspeccionas archivos, ejecutas tests o piensas el siguiente paso. Cinco minutos pasan rápido.

Si tu entorno lo permite, puedes pedir un TTL de una hora antes de tareas largas:

`1`	`export ENABLE_PROMPT_CACHING_1H=1`

En Windows PowerShell:

`1`	`$env:ENABLE_PROMPT_CACHING_1H="1"`

Las escrituras de caché de una hora suelen costar más que las de cinco minutos. No siempre conviene para tareas cortas, pero en bases de código grandes, conversaciones largas y trabajos complejos de varias etapas, puede ser más barato que sufrir expiraciones repetidas.

Un flujo de Claude Code que ahorra tokens

Un flujo más estable sería:

Elegir el modelo antes de empezar y evitar cambios frecuentes.
Habilitar los MCP necesarios y desactivar los que no usarás.
Mantener CLAUDE.md breve, estable y centrado en reglas duraderas.
Preparar por adelantado las Skills necesarias.
En tareas complejas, considerar TTL de una hora.
Dividir la tarea en fases, pero mantener estable la estructura de contexto dentro de cada fase.
Usar subagents o sesiones separadas para exploraciones laterales, sin alterar la conversación principal.

El objetivo no es eliminar todos los fallos de caché. Es evitar los fallos caros y fáciles de pasar por alto.

Regla rápida

Hazte esta pregunta:

¿Esta operación cambia el modelo, las definiciones de herramientas, el contexto del sistema o los mensajes fijos del inicio de la sesión?

Si la respuesta es sí, probablemente afecte a Prompt Cache. Cuanto más a la izquierda esté en la cadena de contexto, mayor será el impacto.

Operaciones comunes:

Cambiar modelo: alto riesgo, cachés aisladas por modelo.
Añadir MCP o recargar plugins: alto riesgo, cambia la lista de herramientas.
Editar CLAUDE.md: riesgo medio-alto, cambia la memoria del proyecto.
Instalar Skills: riesgo medio-alto, cambia el contexto inyectado.
Continuar una conversación normal: bajo riesgo, principalmente añade messages.
Superar el TTL en inactividad: alto riesgo, la caché del servidor expira.

Resumen

Optimizar Prompt Cache en Claude Code consiste en mantener estable el prefijo de la sesión.

No cambies modelos sin necesidad. No instales MCP y Skills a mitad de trabajo. No uses CLAUDE.md como borrador temporal. En tareas complejas, considera un TTL más largo. Con estas bases estables, el costo en tokens y la velocidad de respuesta se vuelven mucho más predecibles.

La frase práctica es: configura antes de empezar, cambia menos después.

Referencias

Cómo ve el desarrollo de software con IA Peter Steinberger, creador de OpenClaw: de OpenClaw a la programación en bucle cerrado

Sun, 17 May 2026 20:02:26 +0800

La trayectoria de Peter Steinberger sirve para observar qué está cambiando en el desarrollo de software con IA.

No es un recién llegado que se hizo visible de repente gracias a la IA. Antes de OpenClaw, ya era fundador de PSPDFKit, una empresa dedicada a renderizado PDF, procesamiento de documentos y herramientas para desarrolladores. Este tipo de producto no gana solo con narrativa: debe resolver rendimiento, compatibilidad, diseño de API, clientes empresariales y mantenimiento a largo plazo.

Por eso, cuando Steinberger construyó OpenClaw con herramientas de IA y empezó a hablar de AI Agent, automatización personal y AI coding, lo importante no fue solo que “una persona escribió mucho código”. Lo más interesante es cómo combinó años de experiencia en ingeniería de software con una nueva generación de AI coding agents para reinterpretar el proceso de desarrollo.

AI coding no es un botón mágico

Muchas discusiones sobre AI coding se reducen a dos extremos.

Uno dice que la IA ya puede escribir código y que los programadores pronto no serán necesarios.

El otro dice que el código generado por IA no es fiable y que la ingeniería real debe seguir escribiéndose a mano.

La experiencia de Steinberger apunta a una tercera idea: la IA cambia la unidad de operación del desarrollo de software, pero no elimina el juicio de ingeniería.

Antes, el trabajo del desarrollador giraba alrededor de editar código. Descomponer requisitos, decidir arquitectura, implementar, probar y corregir bugs se organizaba alrededor de cambios manuales.

Cuando entran AI coding agents, el desarrollador empieza a parecerse más a alguien que gestiona un sistema de ejecución:

Explicar el objetivo.
Proporcionar contexto.
Definir límites.
Dejar que el agent modifique código.
Ejecutar pruebas y comprobaciones.
Iterar según los resultados.

Esto no es simplemente entregar el teclado al modelo. Es pasar de “escribir cada línea a mano” a “definir dirección, diseñar feedback y juzgar resultados”.

Por qué no le convence llamarlo vibe coding

Una expresión frecuente alrededor de Steinberger es vibe coding.

El término nació para describir una nueva forma de desarrollo: el desarrollador describe ideas en lenguaje natural, deja que la IA genere mucho código y luego ajusta con resultados de ejecución y feedback.

Pero Steinberger no está del todo de acuerdo con esa etiqueta. En cobertura pública se ha señalado que ve vibe coding como una expresión que puede volverse despectiva, porque sugiere que el desarrollo asistido por IA es solo “generar por intuición” e ignora la habilidad, el juicio y la experiencia detrás.

La crítica tiene sentido.

El AI coding efectivo no consiste en escribir una frase casual y confiar en la salida del modelo. Requiere:

Convertir requisitos vagos en tareas ejecutables.
Detectar si el modelo entendió mal el objetivo.
Diseñar pruebas y criterios de aceptación.
Juzgar si la estructura del código será mantenible.
Saber cuándo dejar de generar y pasar a revisión humana.

En otras palabras, la IA reduce la fricción de escribir código, pero no reduce la responsabilidad de entender el sistema.

La clave es el bucle

Una idea que se asocia con frecuencia a entrevistas y textos de Steinberger es el bucle.

Dejar que la IA genere código es un proceso de bucle abierto.

Dejar que la IA genere código, lo ejecute, lea errores, corrija problemas y vuelva a ejecutar pruebas se acerca más a un bucle cerrado.

La diferencia es importante.

La generación en bucle abierto crea con facilidad software que parece utilizable. La página abre, las funciones parecen existir y hay bastante código. Pero al entrar en escenarios reales aparecen problemas de estado, permisos, manejo de errores, casos límite y despliegue.

El desarrollo en bucle cerrado exige que la salida esté limitada por feedback. El bucle más simple es:

Escribir claramente el objetivo.
Dejar que la IA modifique el código.
Ejecutar automáticamente pruebas, type checks, lint o build.
Devolver los errores a la IA.
Repetir hasta que pase.
Hacer una revisión humana de la ruta crítica.

Ahí es donde el desarrollo de software con IA puede mejorar de verdad la eficiencia. No porque el modelo acierte a la primera, sino porque puede participar rápidamente en el ciclo de generar, validar y reparar.

Cuanta más experiencia, mejor se usa la IA

Uno de los malentendidos más comunes sobre AI coding es que la experiencia deja de importar.

El caso de Steinberger sugiere lo contrario: la experiencia importa más, aunque su función cambia.

Un ingeniero con experiencia juzga mejor:

Qué tareas conviene pasar a un agent.
Qué módulos necesitan pruebas primero.
Qué cambios son demasiado riesgosos para una refactorización amplia con IA.
Qué código generado solo parece razonable.
Qué problemas deberían resolverse con arquitectura y no con más parches.

La IA puede generar muchas soluciones candidatas, pero cuantas más opciones hay, más juicio se necesita. Alguien sin experiencia puede quedar impresionado porque “funciona”. Un ingeniero con experiencia pregunta: ¿se puede mantener? ¿se puede extender? ¿rompe límites de seguridad? ¿se puede depurar si falla?

Por eso los AI coding agents no convierten la ingeniería de software en puro chat. Más bien externalizan una parte del trabajo de ejecución y amplifican la importancia de planificar, revisar, validar y decidir trade-offs.

OpenClaw importa más allá del proyecto

OpenClaw llamó la atención no solo porque es un AI agent open source, ni solo porque creció rápido.

También funciona como señal: los desarrolladores empiezan a querer que la IA no solo responda preguntas, sino que se conecte a herramientas reales y ejecute acciones reales.

Los chatbots tradicionales se quedan dentro de la caja de conversación. Pueden explicar código, escribir borradores y dar consejos, pero muchas veces una persona todavía debe copiar, pegar, abrir software y ejecutar comandos.

La dirección de los agents es conectar modelos con herramientas:

Sistema de archivos.
Navegador.
Terminal.
Email.
Calendario.
Servicios de terceros.
Repositorios de proyecto.

Cuando los modelos pueden usar esas herramientas, cambian los límites del desarrollo de software. La IA deja de ser solo autocompletado de código y participa en lectura de proyectos, descomposición de tareas, edición de archivos, ejecución de pruebas, preparación de PR y automatización de workflows.

Por eso también llamó la atención la incorporación de Steinberger a OpenAI. No representa solo una historia individual de desarrollador, sino una dirección de producto: los agents personales pasarán de demos a la capa de trabajo diaria.

Qué significa para desarrolladores comunes

Para desarrolladores comunes, la experiencia de Steinberger no se puede copiar directamente en todos los casos.

No todo el mundo puede gestionar varios agents a la vez. No todos los proyectos toleran generación intensa con IA. No todos los equipos aceptan el ritmo de “generar primero e iterar rápido”.

Pero hay varias lecciones útiles.

Primero, escribir tareas con claridad.

La IA es sensible a objetivos vagos. Si dices “optimiza esto”, puede cambiar estilo, estructura, funciones y lógica. Si dices “cambia el mensaje de error al fallar el login de inglés a chino sin alterar el flujo de autenticación”, el resultado suele ser más controlable.

Segundo, fijar comandos de validación.

Si un proyecto no tiene pruebas, build ni lint, la IA tiene dificultades para formar un bucle. Incluso comandos básicos como npm test, go test ./..., pytest o hugo son mejores que revisar solo a ojo.

Tercero, controlar el alcance del cambio.

Pedir a la IA que trabaje en un módulo, un bug o una página cada vez suele ser más fiable que pedirle “refactoriza todo el proyecto”.

Cuarto, mantener revisión humana.

En autenticación, pagos, permisos, eliminación de datos, scripts de despliegue, migraciones de base de datos y configuración de seguridad, no bajes el estándar de revisión solo porque el código lo generó IA.

Quinto, revisar prompts y patrones de fallo.

Si la IA malinterpreta a menudo cierto tipo de tarea, escribe esas restricciones en reglas del proyecto, agent instructions o archivos de skill. La capacidad de AI coding no viene solo del modelo, sino también del entorno de trabajo que construyes alrededor.

Hacia dónde va el desarrollo de software con IA

La historia de Steinberger muestra que el desarrollo de software con IA se mueve desde “ayudar a escribir código” hacia “organizar flujos de producción de software”.

Las primeras herramientas de AI coding servían sobre todo para completar funciones, explicar errores y generar plantillas. El cambio actual es que los agents pueden trabajar entre archivos, llamar herramientas, ejecutar comprobaciones y seguir corrigiendo con feedback.

Esto apunta a varias tendencias.

Primero, subirá el techo productivo de los desarrolladores individuales.

Una persona puede avanzar más prototipos, scripts, herramientas internas y productos pequeños. Pero producir más no significa producir mejor automáticamente. Cuanto más rápido se genera, más importante es validar.

Segundo, la estructura del proyecto será más importante.

Cuanto más claro sea el código, más explícitas las pruebas y más completa la documentación, más fácil será que la IA haga cambios correctos. Los proyectos caóticos son difíciles para humanos y para IA.

Tercero, los ingenieros de software se parecerán más a diseñadores de workflows.

En el futuro no importará solo conocer un lenguaje, sino saber organizar requisitos, contexto, herramientas, pruebas, despliegue y permisos en un bucle controlable.

Cuarto, los límites de seguridad serán más sensibles.

Si un agent puede hacer cosas, también puede hacer cosas equivocadas. Si puede leer archivos, ejecutar comandos y acceder a servicios, permisos, auditoría y rollback se vuelven infraestructura básica del entorno de desarrollo con IA.

Resumen

Lo más valioso de la visión de Peter Steinberger sobre desarrollo de software con IA no es “cuánto código generó la IA”, sino la nueva postura de desarrollo que muestra.

Las personas ya no solo escriben línea por línea dentro del editor. Diseñan objetivos, gestionan agents, construyen bucles de feedback, revisan resultados y ajustan el sistema. El código sigue siendo importante, pero ya no es el único centro del trabajo.

Si el desarrollo tradicional enfatizaba “escribir bien el código”, el desarrollo con IA enfatizará cada vez más “hacer que el sistema produzca resultados correctos y verificables de forma continua”.

No se trata solo de bajar la barrera de la ingeniería. Cambia la forma de la capacidad técnica: de implementación manual hacia descomposición de tareas, gestión de contexto, orquestación de herramientas, validación automática y juicio final.

Referencias

Filtración de Gemini 3.5 Pro: con nombre en clave Cappuccino, Google intenta recuperar ritmo en coding y agentes

Sun, 17 May 2026 11:47:27 +0800

Google todavía no ha lanzado oficialmente Gemini 3.5 Pro.

La información disponible por ahora proviene sobre todo de capturas de comunidades de desarrolladores, benchmarks anónimos, filtradores y reportes de medios. El 15 de mayo de 2026, 36Kr / Xinzhiyuan publicó que un checkpoint de la próxima generación de Gemini podría tener el nombre interno Cappuccino, y que modelos relacionados ya habrían aparecido en comunidades y plataformas de evaluación.

Esta información no debe tratarse como un lanzamiento oficial, pero sí muestra una dirección clara: Google intenta cubrir dos brechas a la vez, coding y razonamiento por un lado, y agentes de IA always-on por el otro.

Conclusión rápida

Esta filtración puede leerse en tres capas:

Gemini 3.5 Pro aún no ha sido lanzado oficialmente, y Cappuccino parece más un checkpoint interno o una build candidata.
La información filtrada sugiere que el nuevo Gemini mejora en generación de código, generación SVG / web interactiva y salida multimodal.
La prueba paralela de Gemini Spark por parte de Google puede ser más importante que el modelo en sí, porque apunta a un agente personal de IA funcionando 24 horas.

En otras palabras, no es solo una historia de benchmarks. Parece más una señal de roadmap antes de Google I/O: el modelo necesita alcanzar a GPT-5.5, mientras la capa de agentes necesita capturar flujos de trabajo de usuarios.

Qué es Cappuccino

El artículo de 36Kr menciona que, según una publicación de Lentils, el checkpoint de Gemini 3.5 Pro con nombre en clave Cappuccino ya habría empezado a producirse. La comunidad todavía hablaba de Gemini 3.2 horas antes, pero la filtración más reciente saltó directamente a 3.5.

Si ese nombre termina siendo correcto, Google podría querer presentar el próximo Gemini como un salto de versión más grande, no como una actualización menor.

Por ahora, Cappuccino debe tratarse como un nombre interno filtrado. No significa que Google haya lanzado públicamente el modelo final, ni garantiza que el nombre de lanzamiento vaya a ser Gemini 3.5 Pro.

Por qué el coding es el foco

La parte más comentada de la filtración es la capacidad de coding del nuevo Gemini.

Según capturas y supuestos benchmarks citados por 36Kr, el nuevo modelo parece más fuerte en:

Generación de SVG y componentes visuales.
Generación de aplicaciones web interactivas.
Manejo de animación, 3D, paneles de parámetros ajustables y otras salidas frontend complejas.
Mejoras en razonamiento lógico y generación de código.

El artículo también cita a Bindu Reddy, CEO de Abacus.AI, diciendo que 3.2 Flash se acerca a GPT-5.5 en coding y razonamiento, con un coste mucho menor. Otras fuentes de medios creen que el nuevo Gemini se ubica aproximadamente en el nivel de GPT-5.5, aunque quizá no represente un salto cualitativo.

Por eso conviene leer con cautela la frase “alcanza a GPT-5.5”. Se parece más a un juicio relativo basado en filtraciones y pruebas anónimas que a un resultado oficial de benchmark de Google.

Por qué Google necesita ponerse al día en coding

El AI coding pasó de ser una categoría de herramientas para desarrolladores a ocupar el centro de la competencia entre modelos fundacionales.

OpenAI tiene Codex y Anthropic tiene Claude Code. No solo sirven a ingenieros: también llevan a product managers, diseñadores y equipos de operaciones a flujos donde el lenguaje natural produce productos ejecutables.

En comparación, Google tiene Gemini y Antigravity, pero no ha logrado formar el mismo punto de entrada predeterminado en la mente de los desarrolladores. El artículo de 36Kr también señala que Antigravity no ha logrado despegar claramente en el mercado externo, y que precios, avisos de cuota y estabilidad de experiencia han generado discusión en la comunidad.

Así que, si el nuevo Gemini necesita demostrar algo, coding será el campo de batalla más directo. La pregunta no es solo si puede escribir código, sino si puede producir interfaces completas de forma estable, entender requisitos complejos, llamar herramientas, corregir errores e integrarse en flujos reales de desarrollo.

Spark puede importar más que 3.5 Pro

En la misma ola de filtraciones también apareció Gemini Spark BETA.

Según TestingCatalog y otras fuentes, Spark se posiciona como un agente de IA always-on: puede procesar la bandeja de entrada, ejecutar tareas online, gestionar flujos de varios pasos y conectar contexto de apps de Google, módulos de habilidades, historial de chats, tareas programadas, sitios con sesión iniciada e información de ubicación.

Eso significa que Spark no es una entrada de chat normal. Podría ser un sistema que permanece online, lee contexto de forma continua y ejecuta tareas por el usuario.

El atractivo es obvio: si Google puede conectar Gmail, Calendar, Chrome, Android, Workspace y Gemini, Spark tendrá una ventaja de distribución difícil de copiar para OpenAI y Anthropic.

El riesgo también es obvio. El artículo de 36Kr menciona una descripción de Spark según la cual podría compartir información o completar compras sin preguntar. Aunque el sistema esté diseñado para pedir permiso antes de operaciones sensibles, este tipo de agente sigue planteando riesgos de privacidad, límites de autorización y acciones accidentales.

Qué significa para usuarios comunes

Si eres un usuario normal de Gemini, lo más importante de esta filtración no es el nombre del modelo, sino tres cambios.

Primero, Google puede seguir reforzando la capacidad de producir resultados completos. Antes, usuarios se quejaban de que Gemini podía ser perezoso en generación visual, SVG y páginas frontend. Si el nuevo modelo puede generar varias propuestas completas en una sola pasada, la experiencia mejorará de forma visible.

Segundo, la capacidad de coding seguirá bajando a modelos más ligeros. La filtración menciona varias veces mejoras de Flash en coding, razonamiento y generación interactiva, lo que significa que en el futuro no siempre hará falta un modelo Pro para tareas complejas.

Tercero, los agentes serán más proactivos. Si Spark se lanza, Gemini podría dejar de limitarse a responder preguntas y empezar a asumir correo, web, compras, calendario y tareas entre apps durante periodos largos.

Eso es bueno para la eficiencia, pero crea un nuevo desafío de gestión de permisos.

Qué significa para desarrolladores

Los desarrolladores deberían vigilar dos cuestiones.

La primera es el ecosistema de herramientas. El artículo de 36Kr dice que la comunidad vio una entrada no publicada llamada MCP Tool Testing en el selector de modelos. Si Gemini soporta MCP o pruebas de herramientas de terceros de forma nativa, será más fácil conectarlo a las toolchains propias de los desarrolladores.

La segunda es coste y estabilidad. Aunque el nuevo Gemini alcance a GPT-5.5 en algunos benchmarks, los desarrolladores acabarán mirando tres cosas: calidad real del código, estabilidad del contexto, y si precios y cuotas son predecibles.

El último año de competencia en herramientas de AI coding ha demostrado que la capacidad del modelo es solo el billete de entrada. Lo que retiene a los desarrolladores es si la herramienta puede editar código, ejecutar tests, leer contexto y manejar casos límite de forma fiable en proyectos diarios.

Cómo leer esta noticia ahora

Esta noticia se entiende mejor como “señal fuerte, confirmación débil”.

La señal fuerte es que múltiples pistas comunitarias apuntan a que Google prepara un Gemini más fuerte y un Gemini Spark Agent más proactivo.

La confirmación débil es que Gemini 3.5 Pro aún no ha sido lanzado oficialmente, Cappuccino sigue siendo un nombre filtrado, y la afirmación de que “alcanza a GPT-5.5” necesita validación con benchmarks oficiales de Google, pruebas de terceros y experiencia real de usuarios.

La lectura más prudente por ahora:

No tratarlo como un producto ya lanzado.
Tratarlo como una vista previa temprana de la próxima dirección de Gemini.
Observar si I/O u otros eventos oficiales confirman el nombre del modelo, disponibilidad de API, precios, ventana de contexto, tool calling y límites de permisos del agente.

Resumen

La exposición de Gemini 3.5 Pro / Cappuccino sugiere que Google podría estar preparando un empuje más fuerte para la próxima generación de Gemini. No intenta corregir una sola capacidad aislada, sino todo un flujo de trabajo de IA: el modelo debe escribir mejor código, generar interfaces y manejar razonamiento complejo, mientras Spark empuja Gemini hacia un agente always-on.

Pero antes de un lanzamiento oficial, todos los benchmarks y capturas siguen siendo pistas. Lo que decidirá si Gemini 3.5 Pro puede recuperar impulso no será si el nombre en clave suena bien, sino si puede ganar de forma fiable en desarrollo real, trabajo de oficina real y tareas reales de varios pasos.

Referencias:

Codex ya admite acceso remoto desde ChatGPT móvil y Access Tokens para espacios Enterprise

Sun, 17 May 2026 09:12:07 +0800

El 14 de mayo de 2026, OpenAI actualizó las notas de lanzamiento de ChatGPT Enterprise & Edu con dos cambios centrados en Codex: acceso remoto desde la app móvil de ChatGPT y Codex access tokens para automatización controlada en espacios Enterprise.

No es un lanzamiento de nuevas capacidades de modelo. Es un cambio en la forma del producto Codex. Codex está pasando de ser un asistente de programación local o web a un coding agent que puede ejecutarse durante más tiempo, gestionarse a distancia e integrarse en flujos de automatización empresarial.

Qué cambió

Según OpenAI Help Center, Codex ahora admite acceso remoto desde ChatGPT mobile app. Los usuarios pueden conectarse desde el teléfono a un entorno Codex en ejecución, seguir tareas largas e intervenir cuando sea necesario.

Al mismo tiempo, los espacios ChatGPT Enterprise reciben Codex access tokens. Están pensados para flujos locales confiables y no interactivos, permitiendo que la automatización use ChatGPT workspace identity y controles empresariales sin iniciar sesión en el navegador cada vez.

La actualización tiene dos entradas principales:

Acceso remoto móvil: resuelve qué hacer cuando Codex ejecuta una tarea larga y el usuario no está frente al ordenador.
Access Tokens: resuelve cómo los scripts empresariales de automatización pueden llamar flujos de Codex con una identidad controlada.

Qué problema resuelve el acceso remoto móvil

Las tareas típicas de Codex no siempre terminan en segundos. En desarrollo real, puede leer un repositorio, modificar varios archivos, ejecutar pruebas, esperar salida de comandos, corregir errores y pedir aprobación a mitad del proceso.

Antes, estas tareas solían exigir que el usuario estuviera cerca del Mac local, la app de escritorio, la CLI o el IDE. Ahora, ChatGPT móvil puede funcionar como una consola remota para seguir Codex incluso lejos del ordenador.

OpenAI indica que el móvil puede mostrar el estado en tiempo real del entorno subyacente, incluyendo:

Contexto del proyecto.
approvals.
screenshots.
terminal output.
diffs.
test results.

El usuario también puede responder preguntas de Codex, redirigir la ejecución, aprobar acciones, revisar salidas y cambiar entre distintos connected hosts. La tarea sigue ejecutándose en un Mac host o en un entorno remoto conectado; el teléfono sirve para revisar y controlar.

Valor para desarrolladores

Esta capacidad es especialmente útil para tareas largas que requieren confirmaciones ocasionales.

Por ejemplo:

Codex está ejecutando pruebas lentas y quieres revisar el resultado fuera de casa.
Codex modificó varios archivos y quieres revisar el diff en el móvil antes de aprobar el siguiente paso.
Codex espera confirmación antes de una operación riesgosa.
Hay varios connected hosts y quieres cambiar entre ellos desde el móvil.

El valor no es escribir código en el teléfono. El valor es no tener que permanecer frente al ordenador todo el tiempo. Codex sigue trabajando en el entorno original y el usuario interviene solo en momentos clave.

Esto también muestra que Codex se acerca a un modelo de “Agent en segundo plano”: las tareas pueden seguir ejecutándose, el usuario no necesita estar siempre conectado, pero la aprobación y el control siguen en manos humanas.

Qué resuelven los Access Tokens

Codex access tokens están dirigidos a espacios ChatGPT Enterprise. Su objetivo no es el inicio de sesión normal de usuarios personales, sino la automatización empresarial confiable.

En una empresa, a menudo hay flujos locales o internos que deben ejecutarse de forma no interactiva, por ejemplo:

Revisiones de código programadas.
Activación de flujos Codex en máquinas controladas.
Integración de Codex con herramientas internas de desarrollo.
Uso de identidad de workspace sin abrir el navegador.

Access tokens permiten que estos flujos se ejecuten con ChatGPT workspace identity y sigan sujetos a políticas empresariales. Frente al login manual, encajan mejor con automatización. Frente a compartir credenciales personales, son más fáciles de gobernar.

No es una API key genérica

Este punto es importante. Codex access tokens no deberían entenderse como una simple “API key universal”.

OpenAI señala que access tokens están disponibles para espacios ChatGPT Enterprise, los administradores pueden gestionar su disponibilidad a nivel de workspace, y los miembros con roles permitidos pueden crear sus propios tokens. Cuando esté disponible, la interfaz de gobernanza también puede reflejar actividad de access tokens.

Es decir, access tokens se integran en el marco de permisos, roles y auditoría empresarial:

El administrador decide si el workspace los habilita.
No todos los miembros pueden crearlos por defecto.
La actividad del token puede aparecer en vistas de gobernanza.
Heredan ChatGPT workspace identity y controles empresariales.

Esto no es lo mismo que crear casualmente un secreto personal de larga duración.

Valor seguro por defecto: Remote Control está apagado

Codex mobile remote access toca entornos de código, salida de terminal, diffs, resultados de pruebas y acciones de aprobación. Si estuviera habilitado por defecto, implicaría riesgos empresariales evidentes.

Por eso OpenAI adopta una postura conservadora: remote control está apagado por defecto y un admin u owner debe habilitarlo en Workspace settings.

Al activar el acceso remoto móvil, también pueden intervenir:

workspace-enabled Remote Control access.
SSO.
Autenticación multifactor.
passkey.

Esto muestra que es una capacidad que debe configurar el equipo de IT y seguridad, no algo disponible automáticamente para todos tras actualizar la app.

Qué hay que actualizar antes de usarlo

OpenAI indica que el acceso remoto móvil requiere actualizar ambos lados:

ChatGPT mobile app.
Codex app en macOS.

Si el workspace lo exige, la configuración móvil también puede activar SSO, autenticación multifactor o passkey.

En la práctica, los administradores deberían revisar primero la configuración de remote control en Workspace settings y decidir qué miembros o roles pueden usar estas capacidades.

Impacto en el uso empresarial de Codex

Esta actualización empuja Codex en dos direcciones.

Primero, Codex se vuelve más apto para tareas largas. Antes, el problema era que el usuario debía vigilarlo constantemente. Ahora puede revisar estado y aprobar acciones desde el móvil, lo que hace más natural que Codex trabaje en segundo plano.

Segundo, Codex se vuelve más apto para automatización empresarial. Access tokens dan a los flujos no interactivos una identidad formal, facilitando integraciones futuras con CI interno, revisión de código, scripts y plataformas de desarrollo.

Juntas, estas dos direcciones significan que Codex deja de ser solo un asistente de IA junto al desarrollador y se convierte en un agent administrable dentro del flujo de desarrollo empresarial.

Límites que siguen importando

La actualización es útil, pero no significa que Codex pueda ejecutarse sin supervisión.

Las empresas todavía deben considerar:

Qué proyectos permiten control remoto.
Qué comandos requieren aprobación.
Cómo crear, rotar y revocar tokens.
Si mobile remote access encaja con la política de gestión de dispositivos.
Si terminal output, screenshots y diffs pueden contener información sensible.
Si los logs de auditoría y vistas de gobernanza cumplen los requisitos internos.

Especialmente los access tokens: una vez que entran en flujos de automatización, deben gestionarse como otras credenciales empresariales, con mínimo privilegio, rotación, sin hardcoding y revocación rápida de tokens que ya no se usen.

Resumen

La actualización de Codex es clara: ChatGPT móvil puede acceder remotamente a tareas largas de Codex, y los espacios Enterprise pueden usar Codex access tokens para automatización controlada.

Lo primero evita que el desarrollador tenga que estar siempre frente al ordenador. Lo segundo permite a las empresas integrar Codex de forma más formal en flujos internos. Juntas, ambas funciones muestran que Codex avanza desde un asistente interactivo de programación hacia un coding agent empresarial, gestionable, auditable y preparado para automatización.

Referencia:

OpenAI Help Center: ChatGPT Enterprise & Edu - Release Notes

easy-vibe: un mapa de aprendizaje para principiantes de Vibe Coding

Sat, 16 May 2026 22:44:43 +0800

easy-vibe es un proyecto open source de Datawhale para aprender Vibe Coding. No está dirigido a desarrolladores que ya dominan herramientas de AI Coding, sino a estudiantes, product managers, diseñadores, equipos de operaciones, indie developers y personas con interés técnico que apenas empiezan con Vibe Coding.

El valor del proyecto no está en listar otro grupo de herramientas de IA, sino en convertir “cómo empezar a construir proyectos con IA” en una ruta de aprendizaje más fácil de entender. Para muchos principiantes, lo difícil no es saber que existen Claude Code, Cursor, MCP o los Agents. Lo difícil es saber qué aprender primero, cómo practicar y cuándo pasar a herramientas más avanzadas.

Lo que más necesitan los principiantes es una ruta

Vibe Coding se ha vuelto popular en los últimos años, pero no es especialmente amigable para principiantes.

En apariencia, si sabes describir un requisito, puedes pedir a la IA que escriba código. En la práctica, en cuanto la tarea se vuelve un poco más compleja, aparecen problemas: el requisito no está claro, el modelo modifica el archivo equivocado, la estructura del proyecto no se entiende, los errores no se saben resolver, las dependencias no se instalan, los prompts se vuelven cada vez más confusos y el flujo termina regresando a “copiar código en una caja de chat”.

Por eso aprender Vibe Coding no puede limitarse a “cómo escribir prompts”. Como mínimo debe resolver varias cosas:

Cómo dividir una idea en tareas ejecutables;
Cómo hacer que la IA entienda la estructura del proyecto;
Cómo leer el código generado por el modelo;
Cómo manejar errores e iterar;
Cómo usar la terminal y el entorno local de desarrollo;
Cómo pasar del chat web a herramientas reales de AI Coding.

Ahí está el sentido de easy-vibe: intenta organizar estos temas en una ruta de aprendizaje, en lugar de dejar que los principiantes se pierdan entre herramientas, tutoriales y términos.

No es un tutorial aislado, sino una hoja de ruta

Según la presentación del proyecto, easy-vibe cubre tutoriales básicos, ejercicios interactivos, contenido visual, RAG, herramientas de terminal, herramientas de AI Coding y temas más avanzados como Claude Code, MCP, Skills y Agent Teams.

Esta forma de organizar el contenido es adecuada para principiantes. AI Coding no es una sola habilidad, sino una combinación de capacidades:

Describir requisitos;
Dividir tareas;
Leer proyectos;
Pedir al modelo que modifique código;
Ejecutar y verificar;
Iterar según los errores;
Convertir flujos repetidos en herramientas o skills.

Si solo aprendes una herramienta, es fácil quedar limitado por su interfaz. Cambias de modelo, editor o CLI, y el flujo vuelve a no estar claro. La ventaja de una hoja de ruta es construir primero el método de trabajo y luego poner las herramientas en el lugar adecuado.

Es especialmente útil para no programadores

El mayor atractivo de Vibe Coding es que permite a personas que no son programadoras profesionales crear prototipos.

Un product manager puede convertir una idea de producto en un demo interactivo. Un diseñador puede validar lógica de interacción. Un equipo de operaciones puede crear herramientas internas. Un estudiante puede construir proyectos de clase rápidamente. Un fundador puede validar demanda en etapas tempranas. Estas personas no necesariamente necesitan convertirse en ingenieros full-time en el sentido tradicional, pero sí necesitan un método para “hacer que la IA me ayude a llevar una idea a algo funcional”.

Por eso easy-vibe encaja bien con la comunidad china. Muchos usuarios chinos ya saben que la IA puede escribir código, pero aún faltan materiales sistemáticos para empezar: entorno de desarrollo, prompts, estructura de proyecto, depuración y uso de herramientas Agent. Es mejor cuando todo se explica con claridad en chino y se acompaña con ejercicios graduales.

Para este tipo de usuarios, lo más importante no es aprender un framework complejo desde el primer día, sino completar un ciclo completo: plantear un requisito, generar un proyecto, ejecutarlo, encontrar problemas, seguir modificando y terminar con una versión usable.

La parte avanzada se acerca a flujos reales de desarrollo con IA

Claude Code, MCP, Skills y Agent Teams, que aparecen en easy-vibe, ya no son solo conceptos introductorios.

Claude Code representa los Agents de programación en terminal: el modelo puede entrar en un proyecto local, leer archivos, modificar código y ejecutar comandos. MCP resuelve la conexión con herramientas y fuentes de datos, para que el modelo no se quede encerrado en una caja de chat. Skills permite conservar flujos reutilizables, como generación fija de proyectos, organización de documentos, revisión de tests o procesos de producción de contenido. Agent Teams va un paso más allá y divide tareas entre varios agentes.

Para principiantes, estos temas pueden parecer lejanos, pero vale la pena conocerlos pronto. La dirección de Vibe Coding ya está clara: pasar de “hacer que la IA escriba un fragmento de código” a “hacer que la IA participe en un flujo completo de proyecto”.

Si una ruta de aprendizaje se queda solo en prompts, pronto quedará atrás frente a la evolución de las herramientas. Pero si al principio se lanzan todos los conceptos avanzados a la vez, el principiante no sabrá por dónde empezar. El valor razonable de easy-vibe es colocar esos temas en una ruta de actualización gradual.

Dos errores que conviene evitar

El primer error es creer que Vibe Coding significa que, aunque no sepas código, puedes desentenderte por completo del código.

La IA puede generar muchas cosas, pero el usuario sigue necesitando juzgar si el resultado es correcto. Como mínimo, hay que entender la estructura del proyecto, saber cómo ejecutarlo y ubicar aproximadamente dónde ocurre un error. Aunque no escribas código complejo, necesitas sentido común básico de ingeniería.

El segundo error es creer que cuanto más avanzada sea la herramienta, mejor.

Un principiante no necesariamente necesita Claude Code, MCP o múltiples Agents al inicio. Un orden mejor es crear primero un ciclo de feedback con proyectos simples, y luego introducir poco a poco terminal, control de versiones, tests, llamadas a herramientas y flujos automatizados. Las herramientas deben coincidir con la complejidad de la tarea; si no, se convierten en algo que parece potente pero no se sabe para qué usar.

Cómo usarlo

Si apenas empiezas con Vibe Coding, puedes usar easy-vibe como una lista de aprendizaje.

Empieza con conceptos básicos y ejercicios simples. No hace falta perseguir todas las herramientas. Construye un proyecto pequeño, como una página personal, un dashboard de datos, una herramienta de formularios, un script de automatización o una demo de base de conocimiento. Durante el proceso, observa en qué partes ayuda la IA y en cuáles necesitas confirmar por tu cuenta.

Cuando puedas completar proyectos pequeños de forma estable, empieza con temas más complejos:

Usar herramientas de terminal para trabajar con proyectos locales;
Usar Git para gestionar cada cambio;
Usar RAG para conectar tus propios materiales;
Usar MCP para conectar herramientas externas;
Usar Skills para fijar flujos repetidos;
Usar Agent Teams para dividir tareas complejas.

Aprender Vibe Coding así no es solo aprender a preguntar a la IA. Es aprender a poner la IA dentro de tu propio flujo de trabajo.

Conclusión

easy-vibe puede verse como un mapa de entrada en chino para Vibe Coding. Organiza conceptos, herramientas y ejercicios dispersos de AI Coding en una ruta que ayuda al principiante a pasar de “he oído que la IA puede escribir código” a “puedo construir un proyecto con IA”.

El valor real de Vibe Coding no es saltarse todo aprendizaje, sino bajar la barrera entre idea y prototipo. Aún necesitas entender requisitos, organizar tareas, verificar resultados y controlar riesgos. Pero muchos pasos repetitivos, tediosos y fáciles de bloquear pueden hacerse con ayuda de la IA.

Si quieres una entrada sistemática al AI Coding y no quieres perderte desde el principio entre nombres de herramientas y configuraciones de ingeniería complejas, easy-vibe es un buen punto de partida.

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

Sat, 16 May 2026 22:41:41 +0800

DeepSeek-TUI es un proyecto open source que lleva DeepSeek V4 al flujo de desarrollo en terminal. No es una simple carcasa de chat. Se parece más a un “agente de programación de línea de comandos”, como Claude Code o Codex CLI: puede leer archivos, modificar código, ejecutar comandos, llamar herramientas y seguir avanzando tareas desde una TUI.

Si ya estás acostumbrado a alternar entre editor y terminal, el valor de este tipo de herramienta es directo: no tienes que copiar código una y otra vez en una ventana de chat web, ni describir manualmente toda la estructura del proyecto. Le das una tarea, puede leer el contexto del workspace actual, planificar pasos, aplicar cambios y devolverte el resultado para revisión.

Resuelve el problema de entrada para usar DeepSeek

Los modelos DeepSeek ya ofrecen buenas capacidades de razonamiento y código, pero para llevar esa capacidad a un flujo real de desarrollo hace falta una capa de ingeniería.

El chat web sirve para hacer preguntas, pero no para editar proyectos durante mucho tiempo. La API sirve para integraciones, pero un desarrollador común tendría que construir por su cuenta llamadas a herramientas, gestión de contexto, operaciones de archivos y control de permisos. DeepSeek-TUI intenta cubrir esa capa: envolver DeepSeek V4 como un Agent que puede trabajar dentro de la terminal.

Según la presentación del proyecto, sus capacidades principales incluyen:

Interfaz TUI en terminal;
Conversación y ejecución de tareas para DeepSeek V4;
Llamadas a herramientas y operaciones de archivos;
Soporte de contexto de 1M;
Modo Auto;
Subagentes;
Ejecución en sandbox;
Cola de tareas persistente.

El objetivo de combinar estas funciones no es que el modelo responda de forma más humana, sino que pueda entrar con más facilidad en el entorno de desarrollo.

Una TUI encaja mejor con tareas largas que una CLI textual

Muchas herramientas AI CLI empiezan con interacción de texto puro: escribes un prompt, esperas la salida, copias comandos o añades más contexto. Es simple, pero cuando la tarea se alarga, se vuelve confuso.

La ventaja de una TUI es que puede colocar conversaciones, archivos, resultados de ejecución y estado de tareas en una interfaz más estable. Para un Agent de programación, eso importa. Una tarea de código rara vez es una sola pregunta y respuesta. Suele incluir:

Entender la estructura del proyecto;
Encontrar archivos relevantes;
Modificar código;
Ejecutar tests o comandos;
Corregir según los errores;
Resumir los cambios.

Si la interfaz solo es una cadena de logs, al usuario le cuesta ver en qué punto está el Agent. Una TUI al menos ofrece un lugar mejor para observar y tomar el control.

El modo Auto conviene para tareas con límites claros

El modo Auto que menciona DeepSeek-TUI encaja con trabajos de límites claros. Por ejemplo, arreglar un bug pequeño, añadir un script, cambiar una configuración, ordenar documentos o implementar una función local.

Estas tareas tienen algo en común: el objetivo es claro, la forma de comprobarlo también, y el alcance del impacto es controlable. El Agent puede revisar archivos, editarlos, ejecutar comandos y luego entregar el resultado al usuario para confirmación.

Pero el modo Auto no debe significar permisos ilimitados. En proyectos reales, borrar archivos, hacer refactors masivos, migrar bases de datos o ejecutar despliegues debería requerir confirmación explícita. La eficiencia de los Agents de programación viene de la automatización, pero el riesgo también. Cuanto más pueda ejecutar comandos una herramienta, más necesita sandbox, límites de permisos y revisión humana.

Los subagentes importan porque dividen tareas

Los subagentes no son un concepto nuevo, pero son útiles en escenarios de código.

Una tarea algo compleja suele requerir varios tipos de trabajo a la vez: alguien lee el código, alguien cambia la implementación, alguien revisa tests y alguien ordena documentación. Los sistemas multi-agent tradicionales a menudo parecen llamativos porque no tienen herramientas reales ni un workspace real; solo discuten dentro de una conversación.

Si los subagentes se combinan con sistema de archivos, ejecución de comandos y cola de tareas, se parecen más a un mecanismo de descomposición de trabajo. Por ejemplo, un subagente analiza dependencias, otro modifica un módulo concreto y el agente principal integra el resultado. Así se reduce el problema de meter demasiada información no relacionada en un solo contexto.

Por supuesto, los subagentes también añaden costo: más tokens, estado más complejo y límites de responsabilidad más difíciles de seguir. Por eso encajan mejor con tareas de complejidad media o superior, no necesariamente con cada cambio pequeño.

El contexto de 1M no es magia, pero ayuda a leer proyectos

El contexto de 1M suena exagerado, pero en programación no es solo una cifra de marketing.

El contexto de un repositorio real está fragmentado: README, archivos de configuración, definiciones de tipos, tests, cadenas de llamadas, convenciones históricas y logs de errores pueden influir en un cambio. Un contexto más largo puede reducir el problema de editar tras mirar solo una parte local, y ayudar al modelo a conservar más restricciones del proyecto.

Aun así, más contexto no significa mejor juicio automáticamente. Las tareas de código siguen necesitando búsqueda, filtrado y verificación. Meter todo el proyecto en el contexto no siempre es mejor que leer con precisión los archivos relevantes. Un buen Agent de programación debería tratar el contexto largo como un buffer, no como un atajo que sustituye el criterio de ingeniería.

Para quién es más útil

DeepSeek-TUI encaja mejor con varios grupos:

Desarrolladores que quieren usar DeepSeek para tareas de código en la terminal;
Personas que no quieren construir por su cuenta frameworks de llamadas a herramientas y operaciones de archivos;
Usuarios que ya conocen Claude Code o Codex CLI y quieren probar una entrada basada en DeepSeek;
Quienes necesitan contexto de proyecto local, no solo preguntar por fragmentos de código en una web;
Desarrolladores que quieren llevar el flujo de AI Coding al entorno de línea de comandos.

Si solo preguntas de vez en cuando cómo escribir una función, el chat web basta. Si quieres que el modelo participe directamente en cambios del proyecto, un Agent de terminal tiene más sentido.

Riesgos a vigilar

Hay tres cosas especialmente importantes en este tipo de herramienta.

La primera son los permisos. Si una herramienta puede leer y escribir archivos o ejecutar comandos, hay que saber a qué puede acceder por defecto, si puede borrar archivos, si puede conectarse a la red y si los comandos peligrosos requieren confirmación.

La segunda es la reversibilidad. Antes de usarla, conviene mantener limpio el árbol de trabajo de Git, para que cada cambio del Agent pueda verse claramente con git diff. No conviene dejar que un Agent edite automáticamente un proyecto con muchos cambios sin commit.

La tercera es la verificación. Que el Agent escriba código no significa que la tarea esté terminada. Tests, builds, lint y review humana siguen siendo necesarios. Las herramientas de AI Coding pueden acelerar el avance, pero no sustituyen la confirmación final de ingeniería.

Conclusión

La importancia de DeepSeek-TUI no está en añadir otro cliente de chat, sino en poner DeepSeek V4 dentro de un entorno de terminal más cercano al trabajo real de desarrollo.

Para los desarrolladores, la capacidad del modelo es solo el primer paso. La experiencia real depende de si puede leer el proyecto, modificar archivos con seguridad, ejecutar comandos de verificación, mantener estado en tareas largas y permitir que el usuario tome el control en cualquier momento.

Si quieres usar DeepSeek para cambios diarios de código, lectura de proyectos y tareas de desarrollo automatizadas, DeepSeek-TUI merece atención. La dirección también está clara: las herramientas de AI Coding están pasando de “responder preguntas de código” a “participar en la ejecución de proyectos”.

Acceso remoto móvil de Codex: sigue tareas de programación en Mac desde la app ChatGPT

Sat, 16 May 2026 17:42:40 +0800

OpenAI llevó Codex remote access a la app móvil de ChatGPT a mediados de mayo de 2026. La idea no es programar en el teléfono, sino seguir y dirigir Codex mientras trabaja en un Mac.

Codex sigue leyendo el proyecto, ejecutando comandos, editando archivos y revisando pruebas en el ordenador. El móvil sirve para revisar progreso, responder preguntas, añadir instrucciones y aprobar acciones.

Qué puede hacer

Según la documentación de OpenAI, desde el móvil puedes:

iniciar nuevos threads en proyectos del host o continuar existentes;
enviar instrucciones, responder preguntas y ajustar la dirección del trabajo;
aprobar comandos y otras acciones;
revisar salidas, diffs, resultados de pruebas, terminal y capturas;
recibir notificaciones cuando Codex termina o necesita atención;
cambiar entre hosts y threads conectados.

No es solo una ventana de chat pequeña: conecta con el contexto real de trabajo de Codex en el host.

Requisitos

Necesitas acceso a Codex en la misma cuenta y workspace de ChatGPT en el móvil y en el Mac. También necesitas la última app móvil de ChatGPT en iOS o Android.

El host actualmente debe ser un Mac despierto, en línea, ejecutando Codex App y con la misma cuenta y workspace. La configuración móvil y el control del dispositivo requieren por ahora Codex App for macOS; no se configuran desde Codex CLI ni desde la IDE Extension.

Si tu cuenta usa MFA, SSO o passkey, debes completar ese flujo. En un workspace de ChatGPT, un administrador puede tener que habilitar Remote Control access.

Límites

Primero, requiere un macOS host. El teléfono se conecta a Codex App en un Mac, no directamente a Codex CLI, a la IDE Extension ni a cualquier equipo Linux / Windows.

Segundo, el host debe estar en línea. El Mac debe permanecer despierto, conectado y con Codex App abierto. Si duerme, pierde red o cierra Codex, la sesión remota puede desconectarse.

Tercero, la conexión usa QR. Debes abrir Set up Codex mobile en el Mac, escanear el código y completar la vinculación en ChatGPT.

Cuarto, las acciones remotas siguen pasando por aprobaciones. Antes de aprobar desde el móvil, conviene leer qué quiere hacer Codex, sobre todo si implica terminal, cambios de archivos, pruebas o acceso externo.

Cómo conectarlo

Abre Codex en el Mac.
Elige Set up Codex mobile en la barra lateral.
Codex activa el acceso remoto para ese host y muestra un QR.
Escanea el QR con el teléfono para abrir el flujo en ChatGPT.
Confirma la misma cuenta y workspace.
Completa MFA, SSO o passkey si hace falta.
El Mac aparecerá en Codex dentro del móvil.

Después puedes gestionar dispositivos en Settings > Connections desde Codex en el Mac, y revisar opciones como mantener el equipo despierto, Computer Use o Chrome extension.

Para qué sirve el móvil

El móvil sirve sobre todo para aprobar, corregir dirección y revisar resultados. Puedes aprobar comandos, añadir una instrucción cuando Codex se equivoca o falla una prueba, y mirar diffs, logs de terminal, pruebas y capturas sin volver al escritorio.

El valor no es escribir código en el móvil, sino convertirlo en una consola ligera para tareas de ingeniería que siguen ejecutándose en el host.

Problemas comunes

Si el host no aparece, confirma que Codex App sigue abierto en el Mac, que Allow other devices to connect está activado y que ambos dispositivos usan la misma cuenta y workspace.

Si no aparece una solicitud de aprobación, abre Codex dentro de la app móvil de ChatGPT, vuelve a escanear el QR o reinicia la configuración desde el host. En equipos, revisa si el administrador habilitó Remote Control access.

Si la sesión se desconecta, revisa si el Mac se durmió, perdió red o cerró Codex App. Si la autenticación bloquea la configuración, completa MFA, SSO o passkey primero.

Cuándo conviene

Encaja bien si ejecutas tareas largas con Codex, necesitas aprobar comandos lejos del escritorio, gestionas varios proyectos o threads y usas Mac como máquina principal.

Encaja peor si trabajas principalmente en Windows o Linux, solo usas Codex CLI o IDE Extension, esperas un entorno de desarrollo completo en el teléfono o tienes una red inestable.

Mi lectura

El acceso remoto móvil de Codex no mueve el desarrollo al teléfono. Hace más manejables los momentos en los que Codex se detiene por aprobación, preguntas, fallos de pruebas o cambios de dirección.

Si ya usas Codex intensivamente en Mac, merece la pena activarlo. Si solo haces preguntas de código ocasionales, su valor será menos evidente.

Referencias

No subas API Keys a GitHub: guía para evitar fugas de secretos al programar con IA

Sat, 16 May 2026 16:26:50 +0800

La programación con IA reduce la barrera para crear software, pero también lleva muchos problemas de seguridad de ingeniería a principiantes y usuarios no técnicos.

Uno de los incidentes más comunes es subir a un repositorio público un API Key, Secret, Token, cadena de conexión a una base de datos o archivo .env. En local, estos archivos parecen simples configuraciones para que la aplicación funcione. En un repositorio público de GitHub, se convierten en credenciales que pueden ser escaneadas, llamadas y abusadas automáticamente.

Las fugas de secretos no son raras. El informe 2026 de GitGuardian indica que los commits públicos de GitHub en 2025 contenían unos 28,65 millones de nuevas credenciales hardcodeadas, y que las fugas de credenciales relacionadas con servicios de IA crecieron un 81% interanual. El problema ya no es solo descuido: la programación con IA, los prototipos rápidos y el alojamiento público están amplificando la escala.

Por qué los principiantes filtran claves con más facilidad

Muchos agentes de IA y pequeñas herramientas tienen dos “repositorios”: uno en el disco local y otro visible para todo el mundo en GitHub. El problema es que los principiantes a menudo no distinguen bien esa frontera.

Durante el desarrollo local, config.json, .env y settings.yaml pueden contener API keys. Después de ejecutar git add ., git commit y git push, esos archivos pueden subirse completos. Cuando el repositorio es público, los bots de escaneo no necesitan entender tu negocio: solo necesitan detectar un patrón de secreto.

La programación con IA agrava esto:

Los ejemplos generados por IA pueden poner OPENAI_API_KEY = "sk-..." directamente en el código fuente.
Para “hacer que funcione”, los principiantes tienden a hardcodear secretos en frontend, scripts o archivos de configuración.
Muchas plataformas de vibe coding despliegan aplicaciones directamente sin pasar por la protección de push de GitHub.
El usuario puede no saber qué archivos, APIs o permisos predeterminados existen dentro del proyecto generado por IA.

En resumen, la IA puede ayudarte a crear algo que funciona más rápido. No asume automáticamente la responsabilidad de seguridad.

`.gitignore` no es decoración

Git gestiona el historial de versiones, GitHub aloja el código y .gitignore le dice a Git qué archivos no deben entrar en ese historial.

Un proyecto básico de IA debería ignorar al menos:

.env
.env.*
*.key
*.pem
config.local.*
secrets.*
credentials.*

Pero .gitignore no basta. Solo evita que archivos no rastreados se añadan en el futuro. Si un archivo con secretos ya fue committeado, añadirlo después a .gitignore no lo elimina del historial.

Un hábito más seguro:

Crear .gitignore al inicio del proyecto.
Guardar API keys solo en variables de entorno o configuración local.
Proporcionar .env.example con placeholders, no secretos reales.
Ejecutar un escáner de secretos antes de hacer commit, como gitleaks, trufflehog o GitHub Secret Scanning.

Borrar el archivo no basta

Si una clave ya llegó a un repositorio público, la primera reacción no debería ser “borro el archivo y hago otro commit”. Primero revoca o rota la clave.

Git registra el historial. Aunque el último commit elimine el archivo, los commits antiguos, forks, clones, cachés y sistemas de escaneo pueden conservarlo. La documentación de GitHub también recomienda revocar o rotar contraseñas, tokens y credenciales como primer paso.

Orden recomendado:

Revoca la clave antigua en el panel del proveedor y genera una nueva.
Revisa facturación, registros de uso, IPs sospechosas y tráfico inusual.
Elimina secretos hardcodeados y usa variables de entorno o un gestor de secretos.
Limpia archivos sensibles del historial con git filter-repo o BFG.
Activa GitHub Secret Scanning y Push Protection.
Revisa CI/CD, plataformas de despliegue, funciones cloud y artefactos frontend por si contienen la clave antigua.

En servicios como OpenAI, Anthropic, DeepSeek, proveedores cloud, pagos, correo o bases de datos, una clave filtrada puede provocar algo más que una factura inesperada: lectura de datos, abuso del servicio, contaminación de la cadena de suministro o bloqueo de cuentas.

Los secretos reales no van en el frontend

Muchos principiantes ponen API keys en JavaScript del frontend porque la página funciona:

`1`	`const apiKey = "sk-xxxxxxxx";`

Eso equivale prácticamente a publicarlas. El código del navegador, las peticiones de red, los Source Map y los artefactos de build se pueden inspeccionar. Cualquier clave que deba ser secreta no debe aparecer en el cliente.

La forma correcta es que el frontend llame a tu propio backend, y que el backend lea variables de entorno y llame a la API externa:

// frontend
await fetch("/api/chat", {
  method: "POST",
  body: JSON.stringify({ message })
});

El servidor usa la variable de entorno:

1
2

// server
const apiKey = process.env.OPENAI_API_KEY;

Esto mantiene el secreto en el entorno del servidor y evita exponerlo a todos los visitantes.

Vibe Coding no elimina la responsabilidad de seguridad

El problema del vibe coding no se limita a GitHub. Muchas aplicaciones se publican directamente desde plataformas de programación con IA a internet, sin revisión de código, escaneo de repositorio ni pruebas de seguridad tradicionales.

Investigaciones recientes de RedAccess encontraron una gran cantidad de activos públicos generados o alojados por herramientas de programación con IA, y algunos exponían datos corporativos, información personal o archivos internos. La lección es clara: cuando “se puede desplegar” se vuelve demasiado fácil, se olvida preguntar “¿debería ser público?”, “¿debería ser solo interno?” y “¿tiene control de acceso?”.

Antes de publicar una app generada por IA, pregunta:

¿Esta aplicación necesita realmente acceso público?
¿Tiene login, autenticación y separación de permisos?
¿Expone URLs de bases de datos, API keys, tokens o webhooks en el frontend?
¿Tiene límites de cuota, dominio, permisos y caducidad para APIs externas?
¿Puedes desactivar claves y revertir despliegues rápidamente tras un incidente?

El código generado por IA también necesita revisión de seguridad. Cuanto menos código hayas escrito personalmente, menos deberías asumir que es seguro.

Comprobaciones para hacer ahora

Empieza por tu cuenta de GitHub. Busca tu usuario junto con:

API_KEY
SECRET
TOKEN
OPENAI_API_KEY
ANTHROPIC_API_KEY
DEEPSEEK_API_KEY
.env
config
credentials

Si encuentras una clave real, rota primero y limpia después. Si entró alguna vez en un repositorio público, trátala como filtrada.

Para futuros proyectos con IA, usa un proceso fijo:

Escribe .gitignore antes del código de negocio.
Usa .env.example para documentar las variables necesarias.
Pon todos los secretos en variables de entorno, no en el código fuente.
Da a las API keys permisos mínimos, cuotas y fechas de caducidad.
Activa GitHub Secret Scanning y Push Protection.
Pide a la IA una revisión de seguridad antes de publicar, pero no confíes solo en su conclusión.

El verdadero peligro de la programación con IA no es solo que escriba código incorrecto. Es que da a muchas personas, por primera vez, la capacidad de publicar rápidamente aplicaciones inseguras en internet. Escribir rápido no es el problema. Entregar secretos, datos y permisos sí lo es.

Referencias

Filtraciones de Gemini 3.5 Pro: Google quiere recuperar la entrada de programación AI con Spark Agent

Fri, 15 May 2026 23:45:34 +0800

Gemini 3.5 Pro todavía no se ha lanzado oficialmente, pero las filtraciones a su alrededor ya están ganando fuerza.

La información actual gira alrededor de varios términos: Gemini 3.5 Pro, el nombre en clave Cappuccino, Gemini Spark, programación AI e integración de herramientas MCP. Todos apuntan en la misma dirección: Google no solo quiere actualizar otro modelo de chat. Quiere volver a conectar modelos, herramientas, Agents y puntos de entrada del ecosistema Google.

Antes de un lanzamiento oficial, todo esto debe tratarse como información filtrada. La señal importante no está en una captura concreta ni en un resultado de benchmark, sino en las carencias que Google podría estar intentando cerrar.

Por Qué Gemini 3.5 Pro Importa

Según la información expuesta, Gemini 3.5 Pro podría representar un salto de nombre.

Hasta hace poco se hablaba de Gemini 3.2, y luego apareció Gemini 3.5 Pro en filtraciones. Si el nombre es real, Google probablemente quiere contar una historia de versión más grande en la próxima presentación, no solo lanzar una actualización menor.

Los puntos filtrados se concentran principalmente en tres áreas:

mejoras continuas en programación y razonamiento;
mayor capacidad para generar SVG, páginas interactivas, animaciones y 3D;
un nuevo producto Agent, Gemini Spark, que podría pasar al primer plano.

Ninguna de estas direcciones sorprende. Gemini siempre ha enfatizado la multimodalidad, y Google tiene canales de distribución muy fuertes. La verdadera pregunta es si puede alcanzar el ritmo de OpenAI y Anthropic en herramientas para desarrolladores y flujos de trabajo tipo Agent.

La Programación Es La Asignatura Que Google Más Necesita Recuperar

En 2026, la programación ya no es solo un punto de evaluación de modelos. Se ha convertido en uno de los puntos de entrada de producto más directos.

La razón es simple: las herramientas de programación AI tienen uso frecuente y generan muchos datos de retroalimentación. Los desarrolladores piden a los modelos leer código, modificar código, ejecutar pruebas y corregir errores todos los días. Estas interacciones empujan de forma natural la siguiente generación de modelos y herramientas.

Durante el último año, Claude Code ha ganado mucha presencia entre desarrolladores, mientras OpenAI ha seguido reforzando la colaboración entre Codex y ChatGPT. Google tiene productos como Antigravity, pero su presencia externa no ha sido tan fuerte.

Por eso Gemini 3.5 Pro está bajo observación. Si solo chatea mejor o responde más rápido, el impacto será limitado. Si realmente mejora la comprensión de código, la edición entre varios archivos, las llamadas a herramientas y la ejecución de tareas largas, entonces sí puede cambiar flujos de trabajo de desarrollo.

Gemini Spark Puede Ser La Variable Más Grande

Más agresivo que el modelo en sí es el rumoreado Gemini Spark.

Según las filtraciones, Spark no se posiciona como un asistente de chat normal, sino como un AI Agent siempre activo. Podría conectarse a correo, calendario, páginas web, tareas, estado de cuenta y contexto personal para ayudar al usuario a manejar flujos de varios pasos.

Este tipo de producto abre mucho espacio de imaginación. Por ejemplo:

organizar automáticamente la bandeja de entrada;
hacer seguimiento de tareas para el usuario;
ejecutar acciones en páginas web;
manejar procesos entre aplicaciones;
organizar asuntos diarios según preferencias personales.

Pero los riesgos son igual de evidentes. Si un Agent siempre activo puede acceder al estado de sesión, datos del navegador, archivos, ubicación y servicios de terceros, debe responder varias preguntas: ¿cuándo debe confirmar el usuario una acción? ¿qué operaciones deben quedar prohibidas para la automatización? ¿se compartirán datos con terceros? ¿cómo se aíslan el navegador remoto y las credenciales?

Así que el punto clave de Spark no es solo si puede hacer trabajo por ti. Es si Google puede dejar suficientemente claros los permisos, la auditoría, los flujos de confirmación y el control del usuario.

Qué Sugiere La Integración De Herramientas MCP

Las filtraciones también mencionan que el nuevo selector de Gemini podría incluir modelos o entradas de prueba relacionadas con MCP.

Si esto llega al producto, sugiere que Google también está empujando los modelos desde un sistema de preguntas y respuestas hacia un sistema operativo de herramientas. El modelo ya no solo genera texto. Debe llamar herramientas externas, acceder a sistemas de negocio, leer y escribir archivos, ejecutar comandos y mantener estado de tarea entre varios pasos.

Es la misma dirección que siguen OpenAI y Anthropic. Quien logre llamadas a herramientas más estables tendrá más facilidad para insertar AI en flujos reales.

Pero la integración MCP no es el final. Lo difícil es la estabilidad:

si el modelo puede elegir la herramienta correcta;
si los parámetros son fiables;
si puede recuperarse tras un fallo;
si los límites de permisos están claros;
si el usuario puede rastrear cada paso.

Si estas preguntas no se resuelven, más herramientas también significan más superficie de error.

La Multimodalidad Sigue Siendo Una Carta Fuerte Para Google

El área donde Google tiene más opciones de diferenciarse sigue siendo la multimodalidad.

Según los ejemplos filtrados de SVG, páginas interactivas, animaciones y generación visual, Gemini podría seguir reforzando la capacidad de generar contenido interactivo a partir de prompts. Frente a escribir solo un fragmento de código, esto se acerca más al prototipado de producto: el usuario describe una idea y el modelo entrega directamente una interfaz operable, ajustable y previsualizable.

Esta ruta encaja bien con Google. Aprovecha las fortalezas multimodales de Gemini y también puede conectarse con Android, Chrome, Workspace, Search, Ads y Cloud.

Si Google quiere evitar competir solo en “qué modelo programa mejor”, probablemente pondrá más peso en un sistema Agent multimodal más completo.

Las Tres Compañías Empiezan A Diferenciar Sus Jugadas

La competencia actual de grandes modelos ya no es solo una competencia de rankings.

La ventaja de OpenAI está en la velocidad de iteración de producto y distribución. Codex, ChatGPT, herramientas empresariales y APIs están cada vez más conectados.

La ventaja de Anthropic está en la mente de los desarrolladores y en la calidad de sus modelos de código. Claude Code ya se ha convertido en el punto de entrada de programación AI por defecto para muchas personas.

La ventaja de Google es el acceso al ecosistema. Gmail, Docs, Chrome, Android, Search, YouTube, Maps y servicios cloud forman una enorme red de datos personales y empresariales. Si los Agents pueden conectarse a estos puntos de entrada de forma segura, Google puede pasar de ser un “perseguidor de modelos” a controlar entradas de flujo de trabajo.

Por eso Gemini Spark merece atención. No necesita quedar primero en todos los benchmarks. Si logra entrar en los flujos diarios, puede construir su propio foso.

Cómo Deberían Leer Esto Los Usuarios Comunes

Para usuarios comunes, no hace falta dejarse arrastrar por cada filtración a corto plazo.

Los puntos prácticos a observar son tres:

Si la capacidad de programación de Gemini 3.5 Pro mejora de verdad, especialmente en repositorios complejos, contexto largo y llamadas a herramientas.
Si Gemini Spark es seguro por defecto, con confirmación clara y registros rastreables antes de operaciones sensibles.
Si Google ofrece precios, cuotas y gestión de permisos empresariales claros, no solo demos llamativas.

Generar unas cuantas capturas bonitas tiene valor limitado. Poder conectarse de forma estable a flujos reales es la línea divisoria de esta generación de productos AI Agent.

Qué Significa Para Desarrolladores

Los desarrolladores deberían preocuparse menos por “qué modelo ganó” y más por si su flujo de trabajo es portable.

Claude Code, Codex, Gemini, Antigravity, Cursor, Windsurf y muchas otras herramientas compiten por el punto de entrada. Si todos los procesos quedan atados a una sola plataforma, cualquier cambio futuro de coste, cuota, política de modelo o regla de permisos hará dolorosa la migración.

Una postura más segura es:

mantener flujos Git estándar en proyectos importantes;
revisar siempre el diff después de ediciones automáticas;
usar pruebas y CI como respaldo para tareas clave;
no entregar credenciales de producción a Agents opacos;
cuando se puedan conectar herramientas con protocolos abiertos, preferir opciones reemplazables.

Los modelos seguirán mejorando, pero la disciplina de ingeniería no quedará obsoleta.

Resumen

Las filtraciones de Gemini 3.5 Pro sugieren que Google está acelerando para cerrar brechas en programación AI y puntos de entrada tipo Agent. La mejora del modelo es solo una parte; Agents siempre activos como Gemini Spark podrían ser el movimiento estratégico más grande.

Pero cuanto más puede un sistema “hacer cosas automáticamente” por el usuario, más necesita límites estrictos de permisos y flujos verificables. Para Google, el reto real no es solo alcanzar a GPT-5.5 o Claude. Es combinar modelos fuertes, mecanismos de seguridad y entradas de ecosistema en un flujo diario confiable.

Si lo consigue, Gemini no necesitará liderar todos los rankings para recuperar parte de la iniciativa en los puntos de entrada de AI.

Guía de despliegue local de Claude Code + Ollama: crear un asistente de programación AI gratuito con CC Switch

Fri, 15 May 2026 23:27:50 +0800

Claude Code se ha vuelto un asistente de programación AI muy popular. Su atractivo no está solo en conversar sobre código, sino en leer un proyecto, modificar archivos, ejecutar comandos, instalar dependencias y seguir corrigiendo errores como un Agent operativo.

El problema es el coste. Cuando el proyecto crece, el contexto se alarga y varias rondas de trabajo tipo Agent pueden consumir cuota de API muy rápido. Si solo quieres experimentar, modificar herramientas pequeñas, escribir scripts o trabajar con proyectos privados locales, surge una pregunta natural: ¿se puede mantener la experiencia de Claude Code, pero ejecutar el modelo en local?

La herramienta clave de esta configuración es CC Switch. Permite que Claude Code se conecte al servicio local de Ollama mediante una API compatible con OpenAI, de modo que las solicitudes se reenvían al modelo local en lugar de ir directamente a la API oficial de Claude.

Qué Problema Resuelve Esta Configuración

Puedes entender el flujo completo así:

1
2
3

Claude Code desktop
+ CC Switch API forwarding layer
+ Ollama local model

Claude Code sigue encargándose del flujo de programación y de las operaciones sobre el proyecto. CC Switch gestiona la configuración del proveedor de modelos y la compatibilidad de API. Ollama ejecuta el modelo en la máquina local.

Esto no significa que un modelo local se convierta de pronto en Claude. Su valor real está en poder usar el flujo tipo Agent de Claude Code en escenarios locales, privados, sin conexión o de menor coste.

Preparación Básica

Antes de empezar, prepara estos componentes:

Instala Git.
Instala Ollama.
Descarga un modelo local adecuado para programación.
Instala CC Switch.
Ten Claude Code disponible en tu máquina.

Para el modelo, puedes empezar con opciones orientadas a código, como Qwen Coder, DeepSeek Coder u otros modelos con buen comportamiento en generación de código y llamadas a herramientas. Cuanto más grande sea el modelo, mejores pueden ser los resultados, pero también aumentará la presión sobre la memoria y la GPU.

Si tu equipo tiene memoria limitada, empieza con un modelo más pequeño. Primero confirma que el flujo funciona bien y luego prueba modelos más grandes.

Configuración Clave De CC Switch

Después de iniciar Ollama, su dirección local de API suele ser:

`1`	`http://127.0.0.1:11434/v1`

En CC Switch, elige un tipo de proveedor compatible con OpenAI. Una opción habitual es:

`1`	`OpenAI Chat Completions`

Después apunta el base URL a la dirección local de Ollama.

Para el campo de API key, Ollama local normalmente no necesita una clave real, pero muchas herramientas siguen exigiendo una variable de entorno o un valor de relleno. Puedes usar:

`1`	`ANTHROPIC_API_KEY`

o cualquier otra variable de relleno aceptada por tu configuración local.

Hay un punto de configuración que merece especial atención:

`1`	`"inferenceModels"="[\"haiku\",\"sonnet\",\"opus\"]"`

Esto mapea los roles de modelo que Claude Code espera hacia el proveedor local. En la práctica, debes vincular haiku, sonnet y opus con los nombres de modelo expuestos por Ollama o CC Switch. Si este mapeo es incorrecto, Claude Code puede fallar al llamar al modelo o volver a una configuración inesperada.

Dónde Destaca Claude Code

La mayor ventaja de Claude Code no es una finalización aislada, sino el flujo completo de desarrollo:

leer y entender la estructura del proyecto;
localizar archivos relacionados con una tarea;
editar código directamente;
ejecutar comandos y pruebas;
observar errores e iterar;
completar tareas de varios pasos en una sola sesión.

Por eso muchas personas quieren conservar Claude Code aunque cambien a un modelo local. Una interfaz de chat normal puede generar fragmentos de código, pero no trabaja de forma natural dentro de un repositorio. Claude Code se parece más a un asistente de desarrollo capaz de actuar.

Qué Papel Cumple Ollama

Ollama se encarga de ejecutar y gestionar los modelos locales. Gestiona la descarga, la carga y la inferencia local.

La ventaja es clara: las solicitudes permanecen en tu máquina, el uso repetido no genera facturas de API y también puedes trabajar cuando la red está limitada. Para código privado, también resulta más aceptable que enviar cada ventana de contexto a un modelo en la nube.

La contrapartida también es clara. Los modelos locales dependen mucho del hardware y de la calidad del modelo. Un modelo pequeño puede manejar ediciones simples, explicaciones y generación de scripts, pero puede sufrir con refactorizaciones grandes entre varios archivos o decisiones de arquitectura delicadas.

Dónde Están Los Límites De La Experiencia

Esta configuración no debe verse como un reemplazo completo de los modelos cloud más potentes de Claude.

Puedes encontrarte con estos problemas:

comprensión más débil de contextos largos;
llamadas a herramientas inestables en tareas complejas;
inferencia lenta en máquinas solo con CPU;
más alucinaciones de rutas de archivo o APIs inexistentes;
planificación menos fiable en varias rondas;
menor tasa de éxito en refactorizaciones de repositorios grandes.

La expectativa más razonable es usarlo como un asistente de desarrollo local gratuito, no como un sustituto perfecto de un modelo cloud de primera línea.

La Compatibilidad Multimodal Sigue Siendo Inestable

Algunos usuarios quieren que Claude Code maneje capturas de pantalla, imágenes de UI, diagramas u otras entradas multimodales. Esta parte depende del modelo local y de la capa de reenvío.

Si el modelo de Ollama seleccionado no admite visión, o si CC Switch no traduce correctamente el formato de solicitud, las funciones multimodales pueden fallar. Incluso con un modelo de visión, el comportamiento puede diferir de la API oficial de Claude.

Por ahora, esta configuración es más adecuada para flujos de texto y código. Conviene tratar el soporte multimodal como algo experimental.

Para Quién Tiene Sentido Probarlo

Esta configuración es adecuada para:

desarrolladores que quieren probar el flujo de Claude Code a bajo coste;
usuarios que escriben scripts, herramientas pequeñas y automatizaciones con frecuencia;
equipos que prefieren mantener el código en máquinas locales;
principiantes que quieren un asistente de programación AI sin gasto continuo de API;
personas que evalúan distintos modelos locales para código.

Es menos adecuada si dependes mucho de contexto largo, monorepos grandes, calidad estricta de revisión de código o refactorizaciones complejas de proyectos completos.

Recomendaciones De Uso

Empieza con tareas pequeñas.

Por ejemplo:

explicar un solo archivo;
refactorizar una función pequeña;
generar un script de shell;
corregir un error simple;
añadir una función pequeña;
escribir pruebas unitarias para un módulo acotado.

Después de cada cambio, ejecuta pruebas o al menos revisa el diff. Un modelo local puede ser útil, pero no conviene aceptar a ciegas todas sus ediciones.

Si el modelo pierde el contexto con frecuencia, reduce el alcance de la tarea. En lugar de pedirle “refactoriza todo el proyecto”, pídele “refactoriza esta función” o “añade validación en este archivo”.

Resumen

Claude Code + CC Switch + Ollama es una combinación interesante. Mantiene el flujo de desarrollo tipo Agent de Claude Code y mueve la inferencia a un modelo local.

Sus mayores ventajas son el menor coste, la privacidad local y un flujo de desarrollo cómodo. Sus límites también son evidentes: la calidad del modelo, el rendimiento del hardware, el contexto largo y la estabilidad de las llamadas a herramientas afectan directamente la experiencia final.

Si ya usas Ollama y quieres un flujo de programación AI local más práctico, vale la pena probar esta configuración. Solo recuerda empezar con tareas pequeñas, verificar cada cambio y tratar el modelo local como un asistente, no como un ingeniero automático.

Prompt-Vault: una biblioteca de especificaciones de prompt para probar AI Coding

Fri, 15 May 2026 09:00:52 +0800

w512/Prompt-Vault es un repositorio pequeño pero útil. No colecciona prompts mágicos; organiza prompts ejecutables de programación por dificultad para probar LLMs y coding agents.

Proyecto: https://github.com/w512/Prompt-Vault

La estructura es clara: Easy, Medium y Hard. Cada archivo Markdown es una tarea independiente. El README también los presenta como prompts para probar modelos o practicar pequeños proyectos.

No es una colección de ocurrencias

Muchos repositorios de prompts parecen grandes, pero cuesta evaluar su calidad. Los títulos atraen, pero faltan criterios de aceptación.

Prompt-Vault se parece más a una biblioteca de especificaciones. Cada tarea intenta dejar claro qué app construir, qué funciones son obligatorias, qué estilo de UI se espera, qué restricciones técnicas existen, si debe ser un solo archivo, si se permiten dependencias y si hay persistencia.

Eso prueba mejor a un modelo que pedir “haz un Kanban bonito”.

Easy: interacción básica

Bubble_Sort_Visualizer.md pide un index.html único que visualice Bubble Sort con barras, botones start/reset, slider de velocidad, contador de comparaciones y tema oscuro.

Sirve para probar si el modelo conecta estado algorítmico con UI, controla animación, maneja reset y mantiene el código simple.

ToDo_List.md parte de HTML estático y añade tareas, estado completado, borrar, contadores, estadísticas Active / Completed y localStorage.

Es simple, pero revela si el modelo evoluciona el código paso a paso o lo mezcla todo.

Medium: estado y animación

Sorting_Visualization.md exige seis algoritmos en la misma página: Bubble, Insertion, Selection, Merge, Quick y Heap Sort.

También requiere selector de algoritmo, sliders de velocidad y tamaño, reset, start / pause y panel de estadísticas.

Muchos modelos logran una animación de Bubble Sort, pero fallan al combinar varios algoritmos, pausa, reanudación y estadísticas.

Hard: sensación de producto completo

Kanban_Board.md pide un tablero completo: columnas por defecto, columnas nuevas, renombrado con doble clic, borrar columnas vacías, tarjetas con título y descripción, prioridad, fecha límite, drag-and-drop, búsqueda, filtro, localStorage, estadísticas, tema oscuro glassmorphism y scroll horizontal responsive.

Esto evalúa producto, no solo una función.

Markdown_Editor_Desktop.md pide un editor Markdown de escritorio con Tauri 2: edición y vista previa, scroll sincronizado, render en vivo, modos, abrir/guardar/guardar como, indicador de no guardado, toolbar, atajos, temas, fuentes, Vue 3, Pinia, marked.js, prism.js y plugins de Tauri.

Ya no es un prompt web simple; prueba estado frontend, permisos de filesystem, IPC y empaquetado.

Por qué vale la pena

Su valor no es la cantidad, sino ofrecer muestras reutilizables de evaluación.

Con el mismo prompt puedes comparar modelos o agents: cuál respeta restricciones, cuál omite menos funciones, cuál maneja bordes, cuál deja código mantenible, cuál cuida mejor la UI.

Es más fiable que “me parece más inteligente”.

En frontend, muchos fallos no son sintaxis: faltan estados de botón, animaciones se atascan, no persiste el dato, el drag no marca el destino o las estadísticas no se actualizan.

Cómo ampliarlo

Podría mejorar con checklists de aceptación, casos de fallo, criterios de puntuación, implementaciones de referencia y registros por modelo.

Por ejemplo, en sorting: “pulsar Start / Reset rápido no debe crear múltiples bucles de animación”. En Kanban: aclarar qué ocurre al borrar una columna con tarjetas.

Cómo usarlo

Para probar una herramienta de AI Coding:

Entrega el prompt sin cambios.
No des pistas adicionales.
Ejecuta el resultado.
Verifica función por función.
Registra omisiones y bugs.
Da una ronda de reparación.
Compara tiempo, coste de tokens y calidad final.

Resumen

Prompt-Vault es una biblioteca ligera de especificaciones. Sirve para evaluar AI Coding y para practicar frontend.

Recuerda que un buen prompt no es un deseo: debe definir requisitos, restricciones, interacción, estado, aceptación y modo de ejecución.

Qué es Token Efficiency: DeepSeek V4, planificación con modelos grandes y ejecución con modelos pequeños

Fri, 15 May 2026 08:59:33 +0800

La próxima métrica importante en AI Coding quizá no sea quién tiene el modelo más fuerte, sino quién completa más trabajo verificable con menos tokens, menor coste y un proceso más estable.

Ese es el valor de Token Efficiency.

Muchos lo entienden como modelos baratos, contexto largo o cache hits más económicos. Eso es solo la base. Lo que lo convierte en productividad es la división de trabajo entre modelos, la orquestación de tareas, el presupuesto de contexto y la evaluación.

Token Efficiency no es un truco para ahorrar dinero. Es un método de ingeniería para convertir tokens en producción.

DeepSeek V4: separar planificación y ejecución

DeepSeek V4 no es solo otro modelo más fuerte. Divide las dos capacidades necesarias para Token Efficiency en V4 Pro y V4 Flash: V4 Pro encaja mejor con planificación, razonamiento, juicio arquitectónico y revisión crítica; V4 Flash encaja con ejecución frecuente, reescritura en lote, completado de código, organización de información y nodos normales de un agente.

En AI Coding esto se traduce así:

V4 Pro: planner / consultant para requisitos, diseño técnico, bugs complejos, revisión de arquitectura y aceptación final.
V4 Flash: executor para escanear archivos, implementar cambios simples, completar tests, ordenar documentación, generar candidatos y repetir tareas.

La documentación API de DeepSeek indica que ambos soportan 1M de contexto, JSON Output, Tool Calls, Chat Prefix Completion y FIM Completion. La página de precios también separa input con cache hit y señala una bajada fuerte de ese precio.

La combinación es lo importante: 1M de contexto reduce compresión en tareas agent complejas; el cache hit barato reduce el coste de volver a cargar prompts, docs, código e historial; la separación Flash / Pro evita usar un modelo flagship para cada paso o depender solo de un modelo pequeño inestable.

Así, DeepSeek V4 ofrece una estructura de coste realista para el patrón “modelo consultor + modelo ejecutor + harness de orquestación”.

No hacer que el modelo más fuerte lo haga todo

Antes era común elegir el modelo más inteligente y dejarle requisitos, código, tests y resumen de punta a punta.

Es sencillo, pero no siempre eficiente. Muchas tareas no necesitan razonamiento de frontera. Los modelos caros deberían actuar como consultores, arquitectos o planificadores que intervienen en puntos clave.

Una estructura mejor:

Modelos grandes para descomponer problemas y tomar decisiones clave.
Modelos pequeños para ejecutar, procesar en lote y repetir cambios.
Herramientas y harness para proceso, estado, contexto y validación.
Personas para definir producto, aceptar resultados y decidir tradeoffs.

Así el razonamiento caro no se desperdicia en ejecución mecánica.

Más contexto no siempre es mejor

El contexto largo importa en coding agents porque código, documentos, historial, salida de tests y logs consumen ventana. Cuando se llena, aparecen compresión, olvido y errores de juicio.

Pero contexto largo no significa meterlo todo.

Token Efficiency exige que cada tarea quepa en una ventana clara y controlada: archivos necesarios, documentos relevantes para la decisión, estado actual, entradas y salidas claras, y resumen estructurado para el siguiente nodo.

Si el contexto es barato, la tentación es meter ruido. El ruido no hace al modelo más inteligente.

El harness importa más que un modelo aislado

Conectar Claude Code, Codex u otro agent a un modelo barato no basta. Los modelos pequeños se desvían en cadenas largas si no hay control de proceso.

Un harness decide cómo dividir tareas, correr nodos, escoger modelos, validar resultados, reintentar fallos y pasar contexto.

Sin esa capa, un modelo pequeño solo es barato. Con esa capa, puede convertirse en palanca.

Dividir tareas con DAG

Una tarea compleja puede convertirse en un DAG. Por ejemplo: aclarar requisitos, diseñar solución, dividir tareas, implementar, completar tests, hacer Code Review, corregir y enviar PR.

Cada nodo puede ser un agente independiente con rol, prompt, permisos de herramientas y formato de salida. Los nodos deberían intercambiar resultados estructurados, no conversaciones largas.

Esto hace cada nodo más corto, más fácil para modelos pequeños y más medible.

Ejecutar varias réplicas de una tarea

Cuando los tokens son suficientemente baratos, una tarea no tiene por qué ejecutarse una sola vez. Puedes correrla con distintos modelos, prompts u orquestaciones, luego elegir el mejor resultado o combinar partes útiles.

Sirve para diseños, copy, casos de prueba, hipótesis de bug, alternativas de refactor y Code Review. No sirve para tareas con efectos externos, estado compartido o criterios de aceptación borrosos.

El objetivo no es apostar, sino obtener muestras comparables para mejorar la orquestación y la elección de modelos.

Construir evaluación

Token Efficiency no se mide solo por precio. Un modelo barato con alta tasa de fallo consume tiempo humano y puede salir más caro.

Conviene registrar tasa de finalización, intervenciones humanas, fallos de tool calls, tests que pasan, hallazgos de review, coste por tarea, tiempo, retrabajo y diferencias entre combinaciones de modelos.

Con esos datos se sabe qué tareas van bien con modelos pequeños, cuáles requieren modelos grandes y cuáles deben quedarse en manos humanas.

Hacer atómicos los workflows

No todo el mundo tiene que construir un harness completo. Pero sí puede dividir sus procesos en nodos atómicos.

Producción de contenido: tema, investigación, esquema, borrador, fact-check, estilo, título SEO, traducción y revisión de publicación.

Desarrollo de software: requisitos, diseño técnico, estructura de datos, cambios de API, unit tests, implementación, migraciones, documentación y review.

Cada nodo debe tener entrada, salida, aceptación y contexto claros. Cuando maduren las herramientas de harness, esos procesos podrán conectarse directamente.

El hardware no es lo primero

Muchas conversaciones sobre Token Efficiency saltan a despliegue local y GPU. Para la mayoría, la API debería ser la primera opción.

Antes de validar el modelo económico, el hardware local es coste adelantado. Mejor: validar el workflow con API, medir coste y calidad, detectar nodos frecuentes y estables, y solo después estudiar qué merece localizar.

Resumen

Token Efficiency no consiste en sustituir modelos caros por baratos, sino en rediseñar el workflow de IA.

Modelos grandes juzgan, modelos pequeños ejecutan, el harness orquesta y valida, y las personas definen objetivos y aceptación. Solo juntas estas capas convierten tokens en productividad.

La diferencia futura quizá no esté en quién llama al modelo más fuerte, sino en quién convierte los mismos tokens en más resultados reales.

Superpowers: un framework de skills que devuelve los coding agents al proceso de ingeniería

Fri, 15 May 2026 08:53:17 +0800

obra/superpowers es un framework de skills para coding agents y también una metodología de desarrollo de software. Su objetivo no es crear otro prompt universal, sino hacer que el agente siga un proceso: aclarar objetivos, producir diseño, escribir un plan, implementar con TDD, revisar y cerrar.

Proyecto: https://github.com/obra/superpowers

En el momento de escribir, la API de GitHub muestra más de 190.000 stars, licencia MIT y actividad reciente. El README lo describe como An agentic skills framework & software development methodology that works.

Qué problema resuelve

Muchas herramientas de AI Coding no fallan por no saber escribir código, sino por escribirlo demasiado pronto.

El usuario da una petición vaga, el agente edita archivos y el resultado parece terminado, aunque los límites, tests y arquitectura sigan sin estar claros. En tareas pequeñas puede pasar; en proyectos complejos se convierte en retrabajo y deuda técnica.

Superpowers hace que el agente entre en un workflow antes de tocar código:

Si detecta que el usuario quiere construir algo, pregunta primero por el objetivo.
Convierte la conversación en una especificación y la confirma por partes.
Tras aprobar el diseño, genera un plan de implementación.
Solo cuando el usuario dice “go” empieza a implementar.
Durante la implementación enfatiza TDD, YAGNI, DRY y revisión.

No es ingeniería nueva, pero los agentes rápidos necesitan barandillas más fuertes.

Herramientas soportadas

Superpowers no está ligado a un único agente. El README lista Claude Code, Codex CLI, Codex App, Factory Droid, Gemini CLI, OpenCode, Cursor y GitHub Copilot CLI.

Su papel se parece más a una capa de workflow entre harnesses que a un truco para un modelo concreto.

Workflow base

Primero está brainstorming: antes de implementar, el agente convierte ideas vagas en diseño ejecutable y lo confirma.

Después using-git-worktrees: crea un worktree y una rama aislados, y comprueba que instalación y tests parten de una base limpia.

Luego writing-plans: divide el diseño en tareas pequeñas con rutas, alcance de código y pasos de validación.

En ejecución puede usar subagent-driven-development para delegar o executing-plans para avanzar por lotes. Cada tarea debe poder revisarse y verificarse.

Después llega test-driven-development: RED-GREEN-REFACTOR real. Escribir un test que falla, confirmar el fallo, implementar lo mínimo, confirmar el paso y refactorizar.

requesting-code-review introduce revisión entre tareas, y los hallazgos críticos bloquean el avance.

Finalmente finishing-a-development-branch valida tests y ofrece opciones como merge, PR, conservar o descartar el worktree.

Qué hay en la Skills Library

La parte de testing gira alrededor de test-driven-development.

La parte de debugging incluye systematic-debugging y verification-before-completion: reproducir, minimizar, formular hipótesis, validar y no declarar completado sin verificar.

Las skills de colaboración incluyen:

brainstorming
writing-plans
executing-plans
dispatching-parallel-agents
requesting-code-review
receiving-code-review
using-git-worktrees
finishing-a-development-branch
subagent-driven-development

También hay skills meta como writing-skills y using-superpowers.

Juntas dan al agente hábitos de ingeniería: cuándo preguntar, planificar, testear y detenerse para review.

Diferencia frente a un prompt normal

Un prompt normal suele apilar reglas en un system prompt: no cambies de más, piensa primero, prueba, explica, sé breve. Cuantas más reglas, más fácil es que el modelo olvide algunas en tareas complejas.

Superpowers divide las reglas en módulos de workflow activables. Cada skill es más corta y enfocada. El agente sabe en qué fase está, el proceso se vuelve revisable y el equipo puede codificar sus propias prácticas.

La lección no es solo usar un modelo más inteligente, sino darle una forma repetible de trabajar.

Para quién sirve

Superpowers encaja mejor con desarrolladores que ya usan coding agents en proyectos reales: tareas de varios archivos, diseño antes de implementación, TDD o validación, ramas o worktrees paralelos, subagents para implementación o review, y equipos que quieren convertir su flujo en skills reutilizables.

Para cambiar una línea de configuración puede ser pesado. Para trabajos de varias fases, sus restricciones aportan valor.

Precauciones

No es piloto automático. Da proceso al agente, pero requisitos, límites y aceptación final siguen siendo humanos.

TDD y review añaden coste inicial. En tareas pequeñas pueden parecer lentos; en tareas complejas reducen retrabajo.

Los subagents en paralelo no siempre ayudan. Funcionan si los límites y el alcance de escritura son claros. Si el requisito es borroso, el paralelismo multiplica la confusión.

También hay que mantener la calidad de las skills. Procesos obsoletos, instrucciones vagas y reglas conflictivas perjudican al agente.

Resumen

Superpowers vale porque aleja al coding agent de “recibir petición y editar código” y lo devuelve al proceso de ingeniería de software.

Lo que falta en AI Coding no suele ser velocidad de generación, sino aclaración, planificación, verificación, review y cierre. Cuanto más fuerte sea el modelo, menos conviene saltarse esos pasos.

Si usas Codex, Claude Code, Cursor o Gemini CLI en proyectos reales, Superpowers merece una lectura. Aunque no lo instales, su forma de dividir skills sirve como referencia para diseñar tu propio workflow de agentes.

Rechazar el Vibe Coding: el repositorio skills de Matt Pocock añade restricciones de ingeniería a la programación con IA

Fri, 15 May 2026 08:46:23 +0800

Cuanto más rápido escribe código la IA, más rápido puede perder el control un proyecto. La cuestión real no es si un modelo puede generar funciones, sino si entiende el requisito, respeta el lenguaje del equipo y avanza con cambios pequeños dentro de la arquitectura existente.

El repositorio mattpocock/skills de Matt Pocock apunta en la dirección opuesta al vibe coding: no dejar que la IA tome todo el proceso de desarrollo, sino ponerla dentro de restricciones maduras de ingeniería de software.

Proyecto: https://github.com/mattpocock/skills

No se trata de un prompt mágico. Es un conjunto de agent skills que convierten aclaración de requisitos, modelado de dominio, TDD, diagnóstico y revisión arquitectónica en workflows adecuados para herramientas de AI Coding.

Primero resolver la falta de alineación

El fallo más común en AI Coding es creer que el modelo entendió cuando en realidad solo adivinó a partir de una descripción vaga.

grill-me invierte la interacción. Antes de escribir código, el agente actúa como un revisor exigente y pregunta por ramas, límites y decisiones pendientes.

Si pides una página de login, debería preguntar primero:

Cómo funcionará recuperar contraseña.
Si habrá login de terceros.
Qué error mostrar cuando falle el login.
Si bloqueo de cuenta, CAPTCHA o control de riesgo están dentro del alcance.
A dónde redirigir tras el éxito.

Parece más lento, pero reduce retrabajo. Cuanto más barato es generar código, más caro se vuelve no haber aclarado el requisito.

Escribir el lenguaje de dominio en el contexto

Otro problema es el vocabulario genérico. El modelo no conoce los términos internos del equipo, así que los nombres de variables, funciones y documentos empiezan a desviarse.

grill-with-docs pregunta mientras revisa CONTEXT.md, ADRs o documentos de dominio. Los términos y decisiones confirmados pueden volver a esos documentos.

Esto se parece al lenguaje ubicuo de DDD. Si el equipo dice customer en lugar de user, o transaction en lugar de order, la IA debe heredar esa terminología.

El valor del contexto no está en acumular datos, sino en reducir la necesidad de adivinar.

Usar TDD para limitar la velocidad

La IA es peligrosa porque es rápida. Antes, escribir mucho mal código tomaba tiempo; ahora aparecen cientos de líneas en segundos. El problema no es la velocidad, sino la falta de ciclos de feedback.

El skill tdd devuelve el ciclo rojo-verde-refactor:

Escribir un test fallido para un comportamiento.
Implementar lo mínimo para pasarlo.
Refactorizar.
Continuar con el siguiente corte vertical.

La clave es avanzar comportamiento por comportamiento. La IA ejecuta; la persona controla dirección y límites.

Diagnosticar con un ciclo

Ante un bug, muchos agentes adivinan y parchean varias veces hasta empeorar el código.

diagnose exige crear primero un ciclo de feedback:

Reproducir el problema
Minimizar el caso
Formular una hipótesis
Añadir observación o logs
Corregir
Añadir una prueba de regresión

Es un proceso clásico, pero en AI Coding es aún más importante. La IA prueba rápido; el proceso la mantiene cerca de la causa raíz.

Revisar la arquitectura con regularidad

Que una tarea pase no significa que el código esté mejor. Muchas pequeñas modificaciones de IA pueden difuminar límites de módulos, complicar interfaces y hacer más difíciles los tests.

Skills como improve-codebase-architecture hacen que el agente mire el código desde más arriba:

Qué módulos mezclan responsabilidades.
Qué interfaces son demasiado complejas.
Qué rutas son difíciles de probar.
Qué nombres no encajan con el lenguaje de dominio.
Qué duplicaciones conviene consolidar.

No es una gran refactorización automática. Es observación estructurada y dirección de mejora; la decisión sigue siendo humana.

Lo que hay que limitar es la libertad

La idea central es sencilla: programar con IA no consiste en dejar improvisar al modelo, sino en darle objetivos, contexto, tests y condiciones de parada.

Las personas definen el problema, los límites de arquitectura, las decisiones de negocio y los criterios de aceptación. La IA genera código, completa tests, repite cambios y hace refactors locales.

Los fundamentos de ingeniería de software no quedaron obsoletos porque la IA mejoró. Aclarar requisitos, usar lenguaje de dominio, TDD, diagnóstico y revisión de arquitectura es cada vez más importante.

Cada vez más personas podrán escribir código. La diferencia estará en quién puede insertar la IA en un sistema de ingeniería mantenible, verificable y capaz de evolucionar.

Qué es cc-haha: un proyecto que convierte Claude Code en un banco de trabajo de escritorio

Thu, 14 May 2026 22:38:04 +0800

cc-haha es un proyecto construido alrededor de un flujo de trabajo modificado de Claude Code. Su repositorio completo es NanmiCoder/cc-haha. La página del proyecto lo dice de forma directa: está basado en el código fuente de Claude Code filtrado desde el Anthropic npm registry el 2026-03-31, y su forma principal actual es un banco de trabajo de escritorio para Claude Code.

Proyecto: https://github.com/NanmiCoder/cc-haha

Hay dos puntos importantes en esa descripción.

Primero, no es Claude Code oficial de Anthropic. El README también indica que el copyright del código fuente original pertenece a Anthropic y que el proyecto es solo para aprendizaje e investigación.

Segundo, su foco ya no es simplemente “ejecutar un Claude Code CLI local”. Por lo que muestran el README y el release más reciente, cc-haha se parece más a una app de escritorio que reúne sesiones de Claude Code, proyectos, permisos, diffs, Computer Use, acceso remoto y configuración de proveedores de modelos.

Qué problema intenta resolver

Claude Code nació como una herramienta orientada a la terminal. Las sesiones, la ejecución de comandos, las confirmaciones de permisos, las ediciones de archivos y el cambio de contexto ocurren en la terminal. Para quien está cómodo con CLI, eso funciona. Pero en uso prolongado aparecen varias incomodidades:

Varios proyectos y sesiones son difíciles de gestionar a la vez.
Para ver qué archivos modificó la IA, hay que cambiar a Git o al editor.
Las aprobaciones, la ejecución de comandos y los diffs quedan repartidos en varias superficies.
Ver la sesión actual desde un teléfono u otro dispositivo requiere una solución adicional.
Conectar modelos que no sean de Anthropic exige manejar compatibilidad de protocolos.

La dirección de cc-haha es empaquetar todo eso en un banco de trabajo gráfico. No es solo una capa visual para Claude Code; mueve la gestión de sesiones y el control del flujo de desarrollo local a la app de escritorio.

Banco de trabajo de escritorio: de terminal a centro de control

Según el README, la app de escritorio de cc-haha reúne estas capacidades en macOS / Windows:

Banco de trabajo multisesión: pestañas, cambio de proyecto, entrada a terminal e historial de sesiones.
Arranque por branch / Worktree: una nueva sesión puede elegir rama del repositorio y decidir entre el árbol actual o un Worktree aislado.
Panel derecho de cambios de código: ver archivos modificados, líneas añadidas/eliminadas y estado del workspace mientras se chatea.
Visualización de cambios: inspeccionar ediciones de la IA, diffs y proceso de ejecución.
Flujo de permisos y confirmaciones: aprobar comandos peligrosos, tool calls y preguntas de la IA desde el escritorio.
Varios proveedores de modelos: API compatibles con Anthropic, modelos de terceros, WebSearch fallback y configuración local.
Acceso remoto H5: usar un token de un solo uso para entrar a la sesión de escritorio desde un teléfono u otro dispositivo.
Integración con IM: conversar, cambiar proyectos y aprobar permisos desde Telegram, Feishu, WeChat o DingTalk.
Tareas programadas y uso de tokens: crear tareas planificadas y ver tendencias de consumo local de tokens.

Estas funciones lo acercan más a un “banco de trabajo de programación con IA” que a un simple sustituto de la línea de comandos. Intenta poner en un solo lugar las superficies más comunes al programar con IA: chat, cambios de archivos, permisos, proyectos, entrada remota y configuración de modelos.

Instalación y arranque

Para usuarios normales, lo más razonable es descargar el instalador de escritorio desde Releases.

El flujo indicado en el README es:

Ir a GitHub Releases y descargar el instalador de macOS o Windows.
En el primer arranque, configurar proveedor de modelo, API Key y modelo por defecto en los ajustes de escritorio.
Si macOS indica que la app no se puede abrir, seguir la guía de instalación para resolver permisos de Gatekeeper.

La página del release más reciente muestra que v0.2.6 se publicó el 2026-05-13. Esa versión se centra en recuperar de forma segura el acceso móvil H5, mejorar la gestión de sesiones de escritorio, la búsqueda de menciones de archivos y detalles de experiencia de escritorio.

Si quieres arrancar el CLI desde código fuente, el README da estos comandos:

1
2
3

bun install
cp .env.example .env
./bin/claude-haha

Ese camino es más adecuado para quien quiera depurar el CLI inferior, el servidor o desarrollar cambios propios. Para uso normal, la app de escritorio es más directa.

Qué cambió en v0.2.6

El punto principal de v0.2.6 es que el acceso H5/LAN volvió de una apertura temporal a un modelo de activación explícita y emparejamiento por token.

Cambios destacados:

El acceso H5/LAN debe activarse explícitamente en local.
Los enlaces QR llevan un token visible una sola vez.
Las API remotas, proxy y WebSocket ya no quedan expuestos sin protección.
Settings añadió una página independiente de H5 Access.
La barra lateral de escritorio añadió modo de gestión masiva, con selección múltiple y borrado de sesiones.
La búsqueda de menciones de archivos ahora es git-first, respeta reglas ignore y reduce ruido de node_modules y artefactos de build.
Se añadió un tema blanco puro y se corrigieron problemas como URLs largas rompiendo el layout del chat o borradores cruzados entre tabs.

Esto muestra que el proyecto ya no está solo en la fase de “funciona”, sino que empieza a cubrir límites de seguridad y detalles diarios propios de un producto de escritorio.

La parte de H5 merece especial cuidado. El autor avisa en el release que H5 es una entrada de navegador para individuos o equipos confiables, no un sistema público de login multi-tenant. En la práctica, no debería tratarse como un panel SaaS expuesto a internet.

Computer Use: dejar que el Agent opere el escritorio

Otro punto importante de cc-haha es Computer Use.

La documentación del proyecto explica que esta función parte de una versión muy modificada del Computer Use interno del código filtrado de Claude Code. La implementación oficial depende de módulos nativos privados de Anthropic, como @ant/computer-use-swift y @ant/computer-use-input, que no están disponibles públicamente. cc-haha reemplaza la capa inferior por un Python bridge basado en bibliotecas públicas como pyautogui, mss y pyobjc.

Computer Use soporta operaciones como:

Captura de pantalla: screenshot, zoom
Ratón: clic, arrastre, movimiento, scroll y lectura de posición del cursor
Teclado: escribir texto, pulsar teclas, mantener teclas
Aplicaciones: abrir apps, cambiar pantalla
Permisos: solicitar acceso a apps, listar aplicaciones autorizadas
Portapapeles: leer y escribir contenido
Otros: esperar, operaciones por lote

Su flujo es un ciclo de “captura - análisis - acción”:

El modelo recibe la solicitud del usuario.
Llama a screenshot para capturar la pantalla.
El modelo usa visión para identificar botones, campos y coordenadas.
Llama a herramientas de clic, escritura u operación de apps.
Vuelve a capturar pantalla para confirmar el resultado y continúa.

Según la documentación, la plataforma con soporte completo es principalmente macOS, tanto Apple Silicon como Intel. Windows / Linux son teóricamente posibles, pero las partes de gestión de aplicaciones basadas en pyobjc deben reemplazarse por soluciones de cada plataforma, y hoy no están completamente adaptadas.

Los requisitos de ejecución incluyen:

Bun >= 1.1.0
Python >= 3.8
permiso de Accessibility en macOS
permiso de Screen Recording en macOS

Esta función es potente, pero también aumenta el riesgo de permisos. Al dejar que la IA opere apps de escritorio, conviene autorizar solo las aplicaciones realmente necesarias y no dejar contenido sensible abierto en ventanas no relacionadas.

Varios modelos mediante una capa compatible con Anthropic

La comunicación base de cc-haha sigue siendo el protocolo Anthropic Messages API. La documentación recomienda usar LiteLLM como proxy de conversión de protocolo.

La estructura básica es:

`1`	`claude-code-haha ──Anthropic协议──▶ LiteLLM Proxy ──OpenAI协议──▶ 目标模型 API`

Es decir, cc-haha envía solicitudes Anthropic Messages API, LiteLLM las convierte a formatos como OpenAI Chat Completions y las reenvía a OpenAI, DeepSeek, Ollama u otros servicios de modelos.

La instalación de LiteLLM indicada en la documentación es:

`1`	`pip install 'litellm[proxy]'`

Después se pueden configurar OpenAI, DeepSeek, Ollama y otros modelos en litellm_config.yaml. Una vez iniciado el proxy, se configuran estas variables en .env o ~/.claude/settings.json:

ANTHROPIC_AUTH_TOKEN=sk-anything
ANTHROPIC_BASE_URL=http://localhost:4000
ANTHROPIC_MODEL=gpt-4o
ANTHROPIC_DEFAULT_SONNET_MODEL=gpt-4o
ANTHROPIC_DEFAULT_HAIKU_MODEL=gpt-4o
ANTHROPIC_DEFAULT_OPUS_MODEL=gpt-4o
API_TIMEOUT_MS=3000000
DISABLE_TELEMETRY=1
CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1

Hay varios detalles prácticos:

drop_params: true es importante, porque parámetros de Anthropic como thinking o cache_control no existen en la API de OpenAI.
Extended Thinking es una función propia de Anthropic y no está disponible con modelos de terceros.
Prompt Caching tampoco funciona en la forma nativa de Anthropic.
Los tool calls pasan de Anthropic tool_use a OpenAI function calling, así que algunos tool calls complejos pueden tener problemas de compatibilidad.
Modelos locales pequeños en Ollama pueden no manejar de forma estable este flujo intensivo en herramientas.

Así que conectar varios modelos puede funcionar, pero no significa que todos ofrezcan la misma experiencia. cc-haha sigue exigiendo al modelo buena capacidad de tool use, comprensión de código y contexto largo.

Para quién tiene sentido

cc-haha encaja mejor con:

Usuarios que ya conocen Claude Code y quieren gestión de sesiones en escritorio.
Personas que trabajan con varios repositorios, ramas y sesiones de IA al mismo tiempo.
Quienes quieren ver cambios de archivos, diffs y estado del workspace en un panel lateral.
Usuarios que quieren probar Computer Use y dejar que un Agent opere apps de escritorio.
Personas que quieren conectar OpenAI, DeepSeek, Ollama u otros modelos mediante un protocolo compatible con Anthropic.
Usuarios que necesitan ver sesiones o aprobar permisos desde móvil o IM.

Encaja peor con:

Usuarios que solo quieren la experiencia oficial y estable de Claude Code.
Personas que no aceptan el origen en código filtrado y la incertidumbre de copyright.
Usuarios que no quieren conceder permisos altos del sistema a herramientas locales.
Equipos que necesitan cumplimiento empresarial, auditoría y soporte oficial.
Personas que no están cómodas con API keys, proxies, compatibilidad de modelos y servicios locales.

Riesgos y límites

Este artículo no puede hablar solo de funciones; también debe hablar de riesgos.

El origen de cc-haha hace que no sea una reimplementación comunitaria normal. El README indica claramente que está basado en código fuente filtrado de Claude Code, y que el código original pertenece a Anthropic. Eso crea incertidumbre de copyright, cumplimiento y mantenimiento a largo plazo.

Además, Computer Use, acceso remoto H5, integración IM y aprobación local de permisos son capacidades de alto privilegio. Cuanto más cómodas son, más claros deben ser sus límites:

No abrir H5 access en redes no confiables.
No tratar el token como una credencial pública de login a largo plazo.
No permitir que el Agent opere aplicaciones sensibles no relacionadas.
No integrarlo casualmente en producción o entornos corporativos regulados.
No exponer configuración de proxies de modelos ni API keys en repositorios públicos.

Si el objetivo es estudiar arquitectura de herramientas de programación con IA, flujos de escritorio e implementación de Computer Use, es una referencia útil. Si se quiere usar en un flujo de producción a largo plazo, hay que evaluar primero riesgos legales, de permisos, seguridad y mantenimiento.

Resumen

Lo más interesante de cc-haha no es si puede replicar Claude Code, sino que empuja las herramientas de programación con IA tipo Claude Code hacia una forma de banco de trabajo de escritorio.

Sesiones, proyectos, Worktree, diffs, permisos, acceso remoto, Computer Use, proveedores de modelos, tareas programadas y estadísticas de tokens se reúnen en una sola experiencia de escritorio. Esto muestra que el siguiente paso de las herramientas de programación con IA no es solo tener modelos más fuertes, sino también interfaces de flujo de trabajo más completas.

Pero sus límites también son claros: no es un producto oficial de Anthropic, tiene un origen sensible y sus funciones de alto permiso requieren cuidado. La actitud más razonable es verlo como un proyecto para observar la evolución de las herramientas de programación con IA, no como un reemplazo despreocupado de Claude Code oficial.

Referencias

Repositorio de GitHub: https://github.com/NanmiCoder/cc-haha
Último release: https://github.com/NanmiCoder/cc-haha/releases/tag/v0.2.6
Documentación de Computer Use: https://github.com/NanmiCoder/cc-haha/blob/main/docs/computer-use.md
Documentación de modelos de terceros: https://github.com/NanmiCoder/cc-haha/blob/main/docs/guide/third-party-models.md

Codex /goal vs Claude Code /goal: ejecutar tareas largas hasta terminarlas

Thu, 14 May 2026 22:25:31 +0800

/goal se está convirtiendo en un comando importante dentro de las herramientas de programación con IA.

No se trata de hacer que el modelo escriba unas cuantas líneas más de código. Resuelve un problema más práctico: cuando una tarea tiene condiciones claras de finalización, ¿puede el Agent seguir avanzando hasta cumplirlas, en lugar de detenerse después de cada turno y esperar a que el usuario escriba “continúa”?

Codex CLI ya añadió un /goal experimental en su documentación oficial. Claude Code también publicó su propia documentación de /goal, y lo describe como una capacidad de automatización que puede seguir trabajando durante varios turnos. El nombre es el mismo, pero la orientación del producto no es exactamente igual.

Qué problema resuelve `/goal`

Una conversación normal de programación con IA suele funcionar turno por turno:

El usuario plantea una tarea.
El Agent analiza, modifica código y ejecuta pruebas.
El Agent informa el resultado.
El usuario decide el siguiente paso.

Ese flujo funciona bien para tareas cortas. Pero cuando se trata de migraciones, refactors, correcciones de pruebas o limpieza de un issue backlog, se vuelve fragmentado. El Agent puede avanzar solo un poco y luego detenerse hasta que escribas “continúa”.

La idea de /goal es cambiar la pregunta de “qué hago ahora” a “qué estado final cuenta como terminado”. Por ejemplo:

`1`	`/goal 完成登录模块迁移，所有 auth 测试通过，lint 无报错`

Este tipo de objetivo encaja de forma natural con tareas largas, porque tiene un punto final claro: las pruebas pasan, la compilación funciona, los archivos se han dividido, una cola queda vacía o se cumplen los criterios de aceptación.

`/goal` en Codex: experimental y ligado al hilo actual

La documentación de Codex CLI de OpenAI marca /goal como experimental. No es una capacidad estable activada por defecto; primero hay que habilitar features.goals.

Hay dos formas de hacerlo:

`1`	`/experimental`

O añadir esto a config.toml:

1
2

[features]
goals = true

Una vez habilitado, se puede usar así:

`1`	`/goal Finish the migration and keep tests green`

Los comandos habituales incluyen:

/goal
/goal pause
/goal resume
/goal clear

Según la documentación de OpenAI, Codex adjunta el goal al active thread actual y sigue ese objetivo mientras avanza una tarea más grande.

Aquí hay un detalle importante: el lenguaje oficial sobre Codex /goal es prudente. Enfatiza configurar un objetivo experimental para trabajo de larga duración y adjuntar ese objetivo al hilo actual, pero no describe con el mismo detalle que la documentación de Claude Code un evaluator independiente que revise cada turno y arranque automáticamente el siguiente. Por eso, de momento conviene tratar Codex /goal como un mecanismo experimental para objetivos de tareas largas, no como un modo de ejecución desatendida plenamente estable.

`/goal` en Claude Code: ejecución por varias rondas guiada por condiciones de finalización

La documentación de /goal en Claude Code es más explícita: después de que el usuario define una completion condition, Claude sigue trabajando entre turnos hasta cumplirla.

Ejemplo:

`1`	`/goal all tests in test/auth pass and the lint step is clean`

El mecanismo de Claude Code, a grandes rasgos, es este:

Cuando termina el turno actual, el control no vuelve inmediatamente al usuario.
Un modelo pequeño y rápido revisa si la condición del objetivo ya se cumplió.
Si no se cumplió, Claude empieza automáticamente el siguiente turno.
Si se cumplió, el goal se borra automáticamente y el estado de finalización queda registrado en el transcript.

Esto hace que /goal en Claude Code se parezca más a “continuar automáticamente hasta satisfacer la condición de finalización”. No solo fija un objetivo en la conversación; delega en un paso de evaluación independiente la decisión de si debe continuar.

Claude Code también permite ver el estado directamente:

/goal

El estado muestra la condición del objetivo, el tiempo transcurrido, la cantidad de turnos evaluados, el consumo de tokens y la razón más reciente del evaluator.

Para detenerlo antes de tiempo, se puede usar:

`1`	`/goal clear`

stop, off, reset, none y cancel también funcionan como alias de limpieza. Después de activar un objetivo, si la sesión se interrumpe y más tarde se reanuda con --resume o --continue, un goal activo puede recuperarse. Sin embargo, el tiempo, el número de turnos y la línea base de tokens se recalculan.

La diferencia principal

Codex y Claude Code están empujando la programación con IA desde respuestas de un solo turno hacia la ejecución de tareas largas, pero la posición de /goal no es la misma.

Comparación	Codex CLI `/goal`	Claude Code `/goal`
Estado	experimental	documentado en una página oficial dedicada
Activación	requiere `features.goals`	usable directamente en un workspace confiable
Alcance del objetivo	active thread actual	session actual
Operaciones habituales	set / view / pause / resume / clear	set / view / clear
Evaluación automática	la documentación enfatiza adjuntar y seguir el objetivo	la documentación describe checks del evaluator después de cada turno
Continuación automática	el lenguaje oficial es prudente	empieza el siguiente turno automáticamente si las condiciones no se cumplen
Mejor caso de uso	mantener un objetivo de largo plazo en una tarea de Codex	dejar que Claude Code avance según condiciones de finalización

En resumen, /goal en Codex se parece más a “adjuntar un objetivo experimental de largo plazo al hilo actual”. /goal en Claude Code se parece más a “definir una condición verificable de parada para la sesión actual y dejar que siga trabajando hasta satisfacerla”.

Cómo escribir un buen `/goal`

Uses la herramienta que uses, /goal no es un buen lugar para deseos vagos.

Un mal ejemplo:

`1`	`/goal 把项目优化一下`

Un mejor ejemplo:

`1`	`/goal 将 payment 模块迁移到新 API，npm test -- payment 退出码为 0，git diff 只包含 payment 相关文件`

Un buen objetivo suele incluir tres cosas:

Un estado final claro.
Un método de validación ejecutable.
Límites que deben respetarse.

Si el objetivo es grande, conviene añadir una condición de parada:

`1`	`/goal 修复 eslint 报错，npm run lint 退出码为 0；如果超过 20 轮仍未完成，停止并总结剩余问题`

Esto importa. Cuanto más potente sea /goal, más necesita límites. Si no, el Agent puede modificar demasiados archivos, ejecutarse durante demasiado tiempo, consumir demasiados tokens o seguir adelante con una cuestión que debería haberse detenido para pedir criterio humano.

Cuándo conviene usar `/goal`

Encaja bien con:

Corrección de pruebas: hasta que pasen pruebas específicas.
Migraciones de código: hasta que todos los puntos de llamada estén actualizados y la compilación funcione.
Limpieza por lotes: hasta eliminar una clase de errores de lint o tipos.
Documentación: hasta que todos los módulos especificados tengan explicación.
Gestión de issues: hasta que todos los issues bajo una etiqueta estén tratados o clasificados con claridad.

No encaja bien con:

Requisitos que todavía no están claros.
Tareas que requieren juicio de producto frecuente.
Eliminaciones de alto riesgo, migraciones de datos o cambios de permisos.
Criterios de aceptación puramente subjetivos.
Tareas que cruzan muchos módulos no relacionados.

Una regla práctica: si puedes escribir “qué comando ejecutar, qué resultado esperar y qué archivos no se deben tocar”, es buen candidato para /goal. Si solo puedes escribir “hazlo mejor”, sigue siendo más seguro usar conversación normal, plan mode o revisión humana.

Qué significa esto para las herramientas de programación con IA

/goal apunta a una dirección clara: las herramientas de programación con IA están pasando de asistentes interactivos a unidades de trabajo que pueden ejecutarse de forma continua.

Antes, usar un Agent solía implicar quedarse cerca. Si se atascaba, lo guiabas. Si terminaba las pruebas, le decías que continuara. Si aparecía un error, dabas otra orden. /goal comprime esa interacción en una condición de finalización y deja que el Agent decida qué debe hacer el siguiente turno.

Pero esto también sube el listón para los usuarios. Escribir prompts ya no consiste solo en describir una tarea; también implica definir criterios de aceptación, comandos de validación, límites de modificación y reglas de parada. Dicho de otro modo, el trabajo del usuario pasa de “pedirle que continúe” a “definir qué significa terminado”.

Que Codex y Claude Code hayan llegado a /goal muestra que los Agents de tareas largas ya no pertenecen solo a tareas en segundo plano o colas en la nube. Las herramientas locales de programación en terminal también empiezan a necesitar una capacidad más fuerte de avance autónomo.

Resumen

Codex CLI y Claude Code tienen /goal, pero por ahora no conviene tratarlos como la misma función.

El /goal de Codex sigue siendo experimental, requiere features.goals y encaja mejor como una forma de mantener un objetivo de largo plazo en el hilo actual de Codex. El /goal de Claude Code conecta de forma más explícita las condiciones de finalización con la continuación automática, usando un evaluator independiente para decidir si debe seguir.

Para el desarrollo diario, este tipo de comando funciona mejor en tareas de ingeniería con criterios de aceptación claros. No reemplaza el juicio de producto ni la revisión de código, pero puede reducir mucho el ciclo repetitivo de “continúa”, “ejecútalo otra vez” y “corrige hasta que pasen las pruebas”.

La habilidad importante no es memorizar el comando, sino aprender a escribir tareas como objetivos claros, verificables y detenibles.

Referencias

OpenAI Codex CLI Slash Commands: https://developers.openai.com/codex/cli/slash-commands
Documentación de Claude Code Goal: https://code.claude.com/docs/en/goal

Por qué DeepSeek se volvió la clave para ahorrar en esta ola de herramientas de AI Coding

Mon, 11 May 2026 04:59:00 +0800

En esta ola de herramientas de AI Coding, la competencia parece girar en torno a capacidad del modelo, ecosistema de plugins y automatización con agentes. Pero cuando se usan de verdad, el primer muro que aparece es el coste.

Claude Code, Codex, OpenClaw y Superpowers son herramientas muy útiles, pero comparten una característica: cuando una tarea se vuelve compleja, consumen muchísimos tokens. Tienen que leer el proyecto, crear planes, llamar herramientas, resumir contexto, revisar resultados una y otra vez, e incluso lanzar subtareas. Cuanto más inteligente es el modelo y más automatizado es el workflow, más fácil es que la factura crezca en silencio.

Por eso DeepSeek se volvió importante en esta ronda. No solo porque pueda escribir código, sino porque su contexto largo y su coste de caché atacan justo la parte más cara de las herramientas de AI Coding.

Por qué las herramientas agent consumen tantos tokens

Los asistentes de programación tradicionales en modo chat suelen funcionar con preguntas y respuestas. Preguntas cómo escribir una función y el modelo responde con un fragmento de código. Ese modo también consume tokens, pero sigue siendo relativamente controlable.

Las herramientas agent son distintas. No solo responden preguntas, sino que entran al proyecto como un ingeniero temporal:

escanean directorios y archivos clave;
entienden el requisito y la arquitectura existente;
crean un plan;
modifican archivos;
ejecutan comandos o tests;
siguen corrigiendo según los errores;
resumen al final qué cambió.

Durante este proceso, el modelo lee repetidamente el mismo contexto. Descripciones del proyecto, fragmentos de código, resultados de herramientas, historial de conversación, planes y logs de error vuelven una y otra vez al contexto. Cuando la tarea es un poco compleja, cientos de miles de tokens desaparecen rápido.

Si además instalas plugins más agresivos, el coste se nota todavía más. Algunas extensiones de OpenCode o Claude Code pueden organizar por defecto todo un equipo de agentes. Tú solo querías cambiar una pequeña función, pero la herramienta puede iniciar planificación, revisión, ejecución y retrospectiva. La tarea parece más “inteligente”, pero los tokens suben sin parar.

La ventaja de Superpowers es activarse bajo demanda

Una ventaja de herramientas como Superpowers es que no fuerzan un flujo agent completo en todas las tareas.

Normalmente puedes seguir usando Claude Code, OpenCode o Codex de la forma habitual. Solo cuando llamas explícitamente a una skill, como brainstorming, planificación, ejecución de plan o retrospectiva, entra en un flujo de automatización más pesado.

Esto importa mucho para el coste.

AI Coding no debería usar artillería pesada para todo. Cambiar una línea de configuración, revisar un error o escribir un script pequeño se puede resolver con una conversación normal. Solo refactors complejos, cambios en varios archivos, procesamiento de documentos largos y validación por varias rondas justifican un flujo agent completo.

Cuanto más poderosa es la herramienta, más importante es controlar cuándo se activa. Si no, más automatización solo significa más desperdicio.

La ventaja clave de DeepSeek es una caché barata

Una razón importante por la que DeepSeek encaja con estas herramientas agent es su bajo coste cuando hay cache hit.

Las tareas de AI Coding tienen muchos prefijos repetidos: contexto del proyecto, prompts de sistema, instrucciones de herramientas, contenido de archivos y turnos anteriores aparecen muchas veces en solicitudes posteriores. Si el servicio del modelo soporta prompt cache, esas partes repetidas cuestan mucho menos después de un acierto de caché.

En muchos modelos, un cache hit solo es algo más barato que un miss, quizá alrededor de un tercio del precio original. La ventaja de DeepSeek es que la diferencia después de un hit puede ser mucho mayor. En workflows agent con contexto largo, muchas rondas y lectura repetida del proyecto, esa diferencia se ve directamente en la factura.

Es decir, DeepSeek no tiene por qué dar la mejor respuesta en cada turno. Pero en escenarios con tareas largas, muchas rondas y lectura repetida de contexto, su estructura de costes encaja especialmente bien con AI Coding.

El contexto largo hace más útil a Claude Code

Al conectar Claude Code o herramientas similares a DeepSeek V4, otra ventaja clara es el contexto largo.

Lo que más temen las herramientas de AI Coding es quedarse sin contexto. Cuando el contexto no alcanza, hay que comprimir con frecuencia. Cuando se comprime mucho, se pueden perder detalles ya leídos. El modelo empieza a olvidar la estructura del proyecto, las restricciones o por qué se modificó cierto archivo, y la calidad baja después.

La capacidad de contexto largo de DeepSeek V4 lo hace más adecuado para repositorios de código, procesamiento por lotes de documentos, traducción de subtítulos y limpieza de artículos de sitio. Especialmente al conectarlo a Claude Code u OpenClaw, una buena configuración puede retrasar la compresión de contexto y conservar más detalles del proyecto.

Por eso algunas tareas se sienten “resistentes” con DeepSeek: no necesariamente impresiona en cada paso, pero aguanta llamadas largas, baratas y repetidas.

Cómo repartir trabajo entre V4 Pro y V4 Flash

DeepSeek V4 Pro y V4 Flash no deberían usarse sin distinción.

Para tareas simples, DeepSeek V4 Flash suele ser mejor. Es rápido, barato y normalmente suficiente para:

traducir subtítulos;
ordenar documentos;
generar scripts comunes;
modificar pequeñas zonas de código;
ejecutar tareas ligeras en OpenClaw;
procesar contenido simple de un sitio.

Para tareas complejas, conviene considerar DeepSeek V4 Pro:

refactors de gran escala;
comprensión de código con varios módulos;
razonamiento complejo;
tareas agent de cadena larga;
cambios de código de alto riesgo;
tareas de ingeniería que requieren planificación más fuerte.

Mucha gente quiere conectar siempre el modelo más fuerte, pero eso suele ser poco rentable. La forma práctica de usar herramientas de AI Coding es dividir las tareas por capas: que el modelo barato procese mucho trabajo rutinario, y reservar el modelo caro para los puntos críticos.

MiniMax, Doubao y DeepSeek ocupan posiciones distintas

Entre modelos y planes chinos, MiniMax, Doubao, Kimi y DeepSeek tienen posiciones diferentes.

MiniMax destaca por dar mucho volumen, bajo precio y funciones amplias. Quizá no sea el modelo de programación más inteligente, pero sirve muy bien para traducción, limpieza ligera y procesamiento por lotes. Procesar subtítulos, cambiar formatos o hacer revisión simple son buenos casos para planes tipo MiniMax.

Doubao destaca por un ecosistema de herramientas más completo: imagen, video, búsqueda, TTS, posible STT y embedding pueden conectarse dentro de la misma caja. Se parece más a una caja de herramientas general.

DeepSeek tiene una posición más clara: texto, código, contexto largo y caché barata. No tiene un ecosistema completo de generación de imagen, voz y video, y sus debilidades son evidentes. Pero en AI Coding y workflows agent de texto largo, sus fortalezas son suficientemente fuertes.

No se trata de que uno sustituya a otro. Se trata de dividir la tarea y usar cada herramienta donde encaja.

Ahorrar no es solo elegir un modelo barato

Ahorrar en AI Coding no significa cambiar todas las solicitudes al modelo más barato.

Las formas realmente efectivas son:

No iniciar un agent pesado para tareas simples.
No usar Pro cuando Flash basta.
Aprovechar la caché en tareas largas.
Mantener estable el contexto repetido para no romper cache hits con cambios inútiles.
Dejar que un modelo barato haga borradores y batch processing, y usar un modelo fuerte para revisiones clave.
Decirle claramente al agent que no repita hechos ni resuma el mismo punto una y otra vez.

El último punto es especialmente importante. Las herramientas de AI tienden a ser verbosas, y la verbosidad no es solo un problema de lectura; también es un problema de coste. Incluir en el prompt “describe cada hecho una sola vez y expresa cada opinión una sola vez” puede mejorar tanto la calidad del texto como el consumo de tokens.

Para qué workflows de AI Coding encaja DeepSeek

DeepSeek encaja mejor en:

lectura de repositorios largos;
cambios ligeros en varios archivos;
limpieza de documentos por lotes;
traducción masiva de subtítulos;
limpieza de artículos Hugo;
ejecución de planes agent;
automatización barata con mucho contexto repetido.

No sirve para todo. Si necesitas gusto frontend especialmente fuerte, juicio de producto complejo o creación multimodal, quizá necesites combinarlo con Claude, GPT, Gemini, Doubao u otras herramientas.

Pero cuando la tarea es de texto largo, contexto largo, llamadas repetidas y sensibilidad al coste, DeepSeek se vuelve fácilmente la primera opción.

Resumen

En esta ola de herramientas de AI Coding, el valor de DeepSeek no es solo que un modelo chino pueda escribir código. Su valor real es resolver el dolor más práctico de las herramientas agent: las tareas largas cuestan demasiado.

Herramientas como Claude Code, OpenClaw y Superpowers automatizan cada vez más el proceso de desarrollo, pero detrás de esa automatización hay lecturas masivas de contexto y llamadas en múltiples rondas. Quien consiga bajar ese coste puede convertir AI Coding de algo “agradable de vez en cuando” en algo “usable todos los días”.

El contexto largo de DeepSeek, su bajo coste de caché y el uso por capas de V4 Flash / V4 Pro lo colocan justo en esa posición.

La verdadera clave de ahorro en esta ronda no es dejar de usar buenos modelos. Es combinar bien modelos buenos, modelos baratos, caché y workflows agent. Cuando entiendes esa factura, las herramientas de AI Coding se convierten en productividad real, no en un juguete bonito pero caro.

Datos originales de ProgramBench: puntuaciones, costes y 200 registros de tareas

Sun, 10 May 2026 12:42:41 +0800

ProgramBench es un nuevo benchmark para evaluar la capacidad de programación con IA. No pide al modelo que arregle un bug dentro de un repositorio existente, sino que reconstruya desde cero un programa con comportamiento equivalente a partir de un ejecutable compilado y su documentación de uso.

Este artículo funciona como referencia de datos, con una explicación mínima. Las tablas siguientes conservan los registros originales publicados en el sitio de ProgramBench para facilitar citas y comparaciones posteriores. Las fuentes son ProgramBench homepage, Extended Results y Task Instances. Los datos se obtuvieron en 2026-05-10T12:42:41+08:00.

Criterios de los datos

Resolved: proporción de tareas que pasan por completo las pruebas de comportamiento ocultas.
Almost resolved: proporción de tareas que pasan al menos el 95% de las pruebas de comportamiento.
Cost: coste medio de API por instancia de tarea, en dólares estadounidenses.
Calls: número medio de llamadas al LLM por instancia de tarea.
Todos los modelos se evaluaron con mini-SWE-agent sobre 200 tareas.

Leaderboard principal

#	Model	Provider	Agent	Resolved	Almost resolved	Run
1	Claude Opus 4.7	Anthropic	mini-SWE-agent	0%	3.0%	https://programbench.com/run/claude-opus-4-7/
2	Claude Opus 4.6	Anthropic	mini-SWE-agent	0%	2.5%	https://programbench.com/run/claude-opus-4-6/
3	Claude Sonnet 4.6	Anthropic	mini-SWE-agent	0%	1.0%	https://programbench.com/run/claude-sonnet-4-6/
4	GPT 5.4	OpenAI	mini-SWE-agent	0%	0.0%	https://programbench.com/run/gpt-5-4/
5	Gemini 3.1 Pro	Google	mini-SWE-agent	0%	0.0%	https://programbench.com/run/gemini-3-1-pro/
6	Gemini 3 Flash	Google	mini-SWE-agent	0%	0.0%	https://programbench.com/run/gemini-3-flash/
7	Claude Haiku 4.5	Anthropic	mini-SWE-agent	0%	0.0%	https://programbench.com/run/claude-haiku-4-5/
8	GPT 5.4 mini	OpenAI	mini-SWE-agent	0%	0.0%	https://programbench.com/run/gpt-5-4-mini/
9	GPT 5 mini	OpenAI	mini-SWE-agent	0%	0.0%	https://programbench.com/run/gpt-5-mini/

Resultados extendidos

#	Model	Provider	Agent	Resolved	Almost resolved	Cost	Calls	Run
1	Claude Opus 4.7	Anthropic	mini-SWE-agent	0%	3.0%	$3.81	93	https://programbench.com/run/claude-opus-4-7/
2	Claude Opus 4.6	Anthropic	mini-SWE-agent	0%	2.5%	$11.38	260	https://programbench.com/run/claude-opus-4-6/
3	Claude Sonnet 4.6	Anthropic	mini-SWE-agent	0%	1.0%	$26.73	472	https://programbench.com/run/claude-sonnet-4-6/
4	GPT 5.4	OpenAI	mini-SWE-agent	0%	0.0%	$0.33	16	https://programbench.com/run/gpt-5-4/
5	Gemini 3.1 Pro	Google	mini-SWE-agent	0%	0.0%	$1.51	94	https://programbench.com/run/gemini-3-1-pro/
6	Gemini 3 Flash	Google	mini-SWE-agent	0%	0.0%	$0.30	85	https://programbench.com/run/gemini-3-flash/
7	Claude Haiku 4.5	Anthropic	mini-SWE-agent	0%	0.0%	$0.80	124	https://programbench.com/run/claude-haiku-4-5/
8	GPT 5.4 mini	OpenAI	mini-SWE-agent	0%	0.0%	$0.04	18	https://programbench.com/run/gpt-5-4-mini/
9	GPT 5 mini	OpenAI	mini-SWE-agent	0%	0.0%	$0.03	15	https://programbench.com/run/gpt-5-mini/

Registros originales de las 200 instancias de tareas

#	Repository	Description	Lang	Stars	Tests	Best Score	Task
1	junegunn/fzf	:cherry_blossom: A command-line fuzzy finder	go	79,721	1,874	81.9%	https://programbench.com/task/junegunn__fzf.b56d614/
2	jesseduffield/lazygit	simple terminal UI for git commands	go	76,901	855	56.4%	https://programbench.com/task/jesseduffield__lazygit.1d0db51/
3	BurntSushi/ripgrep	ripgrep recursively searches directories for a regex pattern while respecting your gitignore	rs	62,855	1,994	79.7%	https://programbench.com/task/burntsushi__ripgrep.3b7fd44/
4	FFmpeg/FFmpeg	Mirror of https://git.ffmpeg.org/ffmpeg.git	c	59,217	3,050	5.3%	https://programbench.com/task/ffmpeg__ffmpeg.360a402/
5	sharkdp/bat	A cat(1) clone with wings.	rs	58,487	801	33.2%	https://programbench.com/task/sharkdp__bat.f822bd0/
6	typst/typst	A markup-based typesetting system that is powerful and easy to learn.	rs	52,957	1,724	28.0%	https://programbench.com/task/typst__typst.88356d0/
7	jgm/pandoc	Universal markup converter	hs	43,632	5,228	14.1%	https://programbench.com/task/jgm__pandoc.5caad90/
8	sharkdp/fd	A simple, fast and user-friendly alternative to ‘find’	rs	42,668	1,235	78.1%	https://programbench.com/task/sharkdp__fd.40d8eb3/
9	php/php-src	The PHP Interpreter	c	40,030	14,288	4.8%	https://programbench.com/task/php__php-src.c891263/
10	duckdb/duckdb	DuckDB is an analytical in-process SQL database management system	cpp	37,657	5,650	12.4%	https://programbench.com/task/duckdb__duckdb.bdb65ec/
11	ajeetdsouza/zoxide	A smarter cd command. Supports all major shells.	rs	35,994	531	76.5%	https://programbench.com/task/ajeetdsouza__zoxide.67ca1bc/
12	jqlang/jq	Command-line JSON processor	c	34,541	6,072	89.9%	https://programbench.com/task/jqlang__jq.b33a763/
13	dandavison/delta	A syntax-highlighting pager for git, diff, grep, rg –json, and blame output	rs	30,445	950	37.3%	https://programbench.com/task/dandavison__delta.acd758f/
14	sharkdp/hyperfine	A command-line benchmarking tool	rs	27,960	291	54.3%	https://programbench.com/task/sharkdp__hyperfine.327d5f4/
15	ggreer/the_silver_searcher	A code-searching tool similar to ack, but faster.	c	27,080	1,006	59.3%	https://programbench.com/task/ggreer__the_silver_searcher.a61f178/
16	facebook/zstd	Zstandard - Fast real-time compression algorithm	c	27,013	2,038	68.8%	https://programbench.com/task/facebook__zstd.1168da0/
17	facebookresearch/fastText	Library for fast text representation and classification.	cpp	26,511	312	75.6%	https://programbench.com/task/facebookresearch__fasttext.1142dc4/
18	robertdavidgraham/masscan	TCP port scanner, spews SYN packets asynchronously, scanning entire Internet in under 5 minutes.	c	25,544	2,549	57.0%	https://programbench.com/task/robertdavidgraham__masscan.b99d433/
19	tree-sitter/tree-sitter	An incremental parsing system for programming tools	rs	24,953	1,232	37.2%	https://programbench.com/task/tree-sitter__tree-sitter.5e23cca/
20	FiloSottile/age	A simple, modern and secure encryption tool (and Go library) with small explicit keys, no config options, and UNIX-style composability.	go	22,077	676	63.5%	https://programbench.com/task/filosottile__age.706dfc1/
21	rust-lang/mdBook	Create book from markdown files. Like Gitbook but implemented in Rust	rs	21,541	1,114	55.5%	https://programbench.com/task/rust-lang__mdbook.37273ba/
22	jarun/nnn	n³ The unorthodox terminal file manager	c	21,506	477	98.1%	https://programbench.com/task/jarun__nnn.cb2c535/
23	antonmedv/fx	Terminal JSON viewer & processor	go	20,433	2,047	75.7%	https://programbench.com/task/antonmedv__fx.86d0d34/
24	mikefarah/yq	yq is a portable command-line YAML, JSON, XML, CSV, TOML, HCL and properties processor	go	15,281	2,000	39.5%	https://programbench.com/task/mikefarah__yq.602586d/
25	Y2Z/monolith	⬛️ CLI tool and library for saving complete web pages as a single HTML file	rs	15,024	713	51.2%	https://programbench.com/task/y2z__monolith.8702e66/
26	direnv/direnv	unclutter your .profile	go	14,998	849	62.0%	https://programbench.com/task/direnv__direnv.02040c7/
27	google/brotli	Brotli compression format	c	14,673	441	90.7%	https://programbench.com/task/google__brotli.b3dc9cc/
28	tomnomnom/gron	Make JSON greppable!	go	14,424	224	90.2%	https://programbench.com/task/tomnomnom__gron.88a6234/
29	XAMPPRocky/tokei	Count your code, quickly.	rs	14,300	732	69.5%	https://programbench.com/task/xampprocky__tokei.505d648/
30	ast-grep/ast-grep	⚡A CLI tool for code structural search, lint and rewriting. Written in Rust	rs	13,541	882	11.9%	https://programbench.com/task/ast-grep__ast-grep.dde0fe0/
31	cheat/cheat	cheat allows you to create and view interactive cheatsheets on the command-line. It was designed to help remind *nix system administrators of options for commands that they use frequently, but not frequently enough to remember.	go	13,278	297	59.9%	https://programbench.com/task/cheat__cheat.b8098dc/
32	jonas/tig	Text-mode interface for git	c	13,200	1,586	83.9%	https://programbench.com/task/jonas__tig.8334123/
33	ninja-build/ninja	a small build system with a focus on speed	cpp	12,895	1,438	72.3%	https://programbench.com/task/ninja-build__ninja.cc60300/
34	Canop/broot	A new way to see and navigate directory trees : https://dystroy.org/broot	rs	12,619	539	67.0%	https://programbench.com/task/canop__broot.d6c798e/
35	orf/gping	Ping, but with a graph	rs	12,433	339	78.5%	https://programbench.com/task/orf__gping.26eb5b9/
36	svenstaro/genact	🌀 A nonsense activity generator	rs	11,995	232	59.1%	https://programbench.com/task/svenstaro__genact.16f96e3/
37	lz4/lz4	Extremely Fast Compression algorithm	c	11,781	1,496	82.7%	https://programbench.com/task/lz4__lz4.1519f46/
38	o2sh/onefetch	Command-line Git information tool	rs	11,745	1,166	81.7%	https://programbench.com/task/o2sh__onefetch.e5958ce/
39	bootandy/dust	A more intuitive version of du in rust	rs	11,609	584	70.9%	https://programbench.com/task/bootandy__dust.62bf1e1/
40	ekzhang/bore	🕳 bore is a simple CLI tool for making tunnels to localhost	rs	11,075	406	68.7%	https://programbench.com/task/ekzhang__bore.8e059cd/
41	BurntSushi/xsv	A fast CSV command line toolkit written in Rust.	rs	10,757	1,182	82.7%	https://programbench.com/task/burntsushi__xsv.f430466/
42	bellard/quickjs	Public repository of the QuickJS Javascript Engine.	c	10,565	3,034	3.6%	https://programbench.com/task/bellard__quickjs.d7ae12a/
43	hatoo/oha	Ohayou(おはよう), HTTP load generator, inspired by rakyll/hey with tui animation.	rs	10,201	899	72.5%	https://programbench.com/task/hatoo__oha.8dc6349/
44	tstack/lnav	Log file navigator	cpp	10,200	990	13.4%	https://programbench.com/task/tstack__lnav.ee34494/
45	sharkdp/hexyl	A command-line hex viewer	rs	10,086	906	82.8%	https://programbench.com/task/sharkdp__hexyl.2e26437/
46	lua/lua	A copy of the Lua development repository, as seen by the Lua team. Mirrored irregularly. All communication should be through the Lua mailing list https://www.lua.org/lua-l.html	c	9,908	1,338	43.1%	https://programbench.com/task/lua__lua.c6b4848/
47	johnkerl/miller	Miller is like awk, sed, cut, join, and sort for name-indexed data such as CSV, TSV, and tabular JSON	go	9,842	14,637	22.9%	https://programbench.com/task/johnkerl__miller.8d85b46/
48	sqlite/sqlite	Official Git mirror of the SQLite source tree	c	9,434	13,514	67.0%	https://programbench.com/task/sqlite__sqlite.839433d/
49	boyter/scc	Sloc, Cloc and Code: scc is a very fast accurate code counter with complexity calculations and COCOMO estimates written in pure Go	go	8,320	464	37.7%	https://programbench.com/task/boyter__scc.515f91c/
50	ariga/atlas	Declarative schema migrations with schema-as-code workflows	go	8,311	1,318	54.8%	https://programbench.com/task/ariga__atlas.6d81150/
51	pemistahl/grex	A command-line tool and Rust library with Python bindings for generating regular expressions from user-provided test cases	rs	8,103	1,312	73.9%	https://programbench.com/task/pemistahl__grex.fa3e8ed/
52	htop-dev/htop	htop - an interactive process viewer	c	8,021	693	85.1%	https://programbench.com/task/htop-dev__htop.523600b/
53	peco/peco	Simplistic interactive filtering tool	go	7,881	1,224	76.7%	https://programbench.com/task/peco__peco.4e58dad/
54	bensadeh/tailspin	🌀 A log file highlighter	rs	7,793	615	75.8%	https://programbench.com/task/bensadeh__tailspin.6278437/
55	ducaale/xh	Friendly and fast tool for sending HTTP requests	rs	7,754	1,171	50.0%	https://programbench.com/task/ducaale__xh.4a6e44f/
56	svenstaro/miniserve	🌟 For when you really just want to serve some files over HTTP right now!	rs	7,561	304	78.6%	https://programbench.com/task/svenstaro__miniserve.8449e8b/
57	mgdm/htmlq	Like jq, but for HTML.	rs	7,520	1,455	93.9%	https://programbench.com/task/mgdm__htmlq.6e31bc8/
58	parcel-bundler/lightningcss	An extremely fast CSS parser, transformer, bundler, and minifier written in Rust.	rs	7,515	2,828	53.6%	https://programbench.com/task/parcel-bundler__lightningcss.aa2ed1e/
59	universal-ctags/ctags	A maintained ctags implementation	c	7,149	2,258	13.3%	https://programbench.com/task/universal-ctags__ctags.243595e/
60	chmln/sd	Intuitive find & replace CLI (sed alternative)	rs	7,072	810	90.9%	https://programbench.com/task/chmln__sd.87d1ba5/
61	ogham/dog	A command-line DNS client.	rs	6,640	1,300	84.2%	https://programbench.com/task/ogham__dog.721440b/
62	danmar/cppcheck	static analysis of C/C++ code	cpp	6,599	2,126	14.6%	https://programbench.com/task/danmar__cppcheck.0a5b103/
63	doxygen/doxygen	Official doxygen git repository	c	6,422	229	34.5%	https://programbench.com/task/doxygen__doxygen.966d98e/
64	sharkdp/pastel	A command-line tool to generate, analyze, convert and manipulate colors	rs	6,334	1,114	77.2%	https://programbench.com/task/sharkdp__pastel.b60e899/
65	BLAKE3-team/BLAKE3	the official Rust and C implementations of the BLAKE3 cryptographic hash function	rs	6,178	647	97.5%	https://programbench.com/task/blake3-team__blake3.15e83a5/
66	Nukesor/pueue	:stars: Manage your shell commands.	rs	6,154	638	15.4%	https://programbench.com/task/nukesor__pueue.8b9d6fe/
67	OSGeo/gdal	GDAL is an open source MIT licensed translator library for raster and vector geospatial data formats.	cpp	5,875	657	25.4%	https://programbench.com/task/osgeo__gdal.0847f12/
68	Byron/dua-cli	View disk space usage and delete unwanted data, fast.	rs	5,794	709	86.9%	https://programbench.com/task/byron__dua-cli.8570c15/
69	dundee/gdu	Fast disk usage analyzer with console interface written in Go	go	5,578	1,161	70.1%	https://programbench.com/task/dundee__gdu.ede21d2/
70	eradman/entr	Run arbitrary commands when files change	c	5,551	586	88.6%	https://programbench.com/task/eradman__entr.8e2e8b4/
71	LuaJIT/LuaJIT	Mirror of the LuaJIT git repository	c	5,518	2,967	71.5%	https://programbench.com/task/luajit__luajit.a553b3d/
72	mgechev/revive	🔥 ~6x faster, stricter, configurable, extensible, and beautiful drop-in replacement for golint	go	5,486	727	46.4%	https://programbench.com/task/mgechev__revive.201451e/
73	cweill/gotests	Automatically generate Go test boilerplate from your source code.	go	5,294	603	61.9%	https://programbench.com/task/cweill__gotests.2a672c5/
74	cordx56/rustowl	Visualize Ownership and Lifetimes in Rust	rs	5,113	589	75.2%	https://programbench.com/task/cordx56__rustowl.655bc5c/
75	abishekvashok/cmatrix	Terminal based “The Matrix” like implementation	c	5,042	508	97.0%	https://programbench.com/task/abishekvashok__cmatrix.5c082c6/
76	quinn-rs/quinn	Async-friendly QUIC implementation in Rust	rs	5,041	522	61.7%	https://programbench.com/task/quinn-rs__quinn.bb359cc/
77	alecthomas/chroma	A general purpose syntax highlighter in pure Go	go	4,910	515	15.9%	https://programbench.com/task/alecthomas__chroma.8d04def/
78	anordal/shellharden	The corrective bash syntax highlighter	rs	4,778	1,095	81.7%	https://programbench.com/task/anordal__shellharden.6a6ffd4/
79	yoav-lavi/melody	Melody is a language that compiles to regular expressions and aims to be more readable and maintainable	rs	4,748	1,205	78.9%	https://programbench.com/task/yoav-lavi__melody.f4af9b4/
80	sayanarijit/xplr	A hackable, minimal, fast TUI file explorer	rs	4,735	463	60.5%	https://programbench.com/task/sayanarijit__xplr.1751065/
81	hpjansson/chafa	📺🗿 Terminal graphics for the 21st century.	c	4,648	1,931	58.4%	https://programbench.com/task/hpjansson__chafa.dd4d4c1/
82	jhspetersson/fselect	Find files with SQL-like queries	rs	4,420	3,115	44.0%	https://programbench.com/task/jhspetersson__fselect.c3559ca/
83	ivanceras/svgbob	Convert your ascii diagram scribbles into happy little SVG	rs	4,182	472	41.3%	https://programbench.com/task/ivanceras__svgbob.6d00ad9/
84	multiprocessio/dsq	Commandline tool for running SQL queries against JSON, CSV, Excel, Parquet, and more.	go	3,867	542	80.3%	https://programbench.com/task/multiprocessio__dsq.c3ae0ba/
85	rcoh/angle-grinder	Slice and dice logs on the command line	rs	3,727	1,130	38.0%	https://programbench.com/task/rcoh__angle-grinder.9c2fc88/
86	rs/curlie	The power of curl, the ease of use of httpie.	go	3,637	701	89.3%	https://programbench.com/task/rs__curlie.5dfcbb1/
87	antonmedv/walk	Terminal file manager	go	3,598	470	74.3%	https://programbench.com/task/antonmedv__walk.bf802ef/
88	JohannesKaufmann/html-to-markdown	⚙️ Convert HTML to Markdown. Even works with entire websites and can be extended through rules.	go	3,586	885	85.5%	https://programbench.com/task/johanneskaufmann__html-to-markdown.3006818/
89	TheZoraiz/ascii-image-converter	A cross-platform command-line tool to convert images into ascii art and print them on the console. Now supports braille art!	go	3,284	465	64.1%	https://programbench.com/task/thezoraiz__ascii-image-converter.d05a757/
90	hairyhenderson/gomplate	A flexible commandline tool for template rendering. Supports lots of local and remote datasources.	go	3,135	2,926	74.7%	https://programbench.com/task/hairyhenderson__gomplate.05eb3aa/
91	ip7z/7zip	7-Zip	cpp	2,967	1,043	33.9%	https://programbench.com/task/ip7z__7zip.839151e/
92	madler/pigz	A parallel implementation of gzip for modern multi-processor, multi-core machines.	c	2,924	831	83.2%	https://programbench.com/task/madler__pigz.fe4894f/
93	tinycc/tinycc	Unofficial mirror of mob development branch	c	2,843	1,978	12.8%	https://programbench.com/task/tinycc__tinycc.9b8765d/
94	raviqqe/muffet	Fast website link checker in Go	go	2,597	293	88.1%	https://programbench.com/task/raviqqe__muffet.a882908/
95	segmentio/chamber	CLI for managing secrets	go	2,588	1,748	82.0%	https://programbench.com/task/segmentio__chamber.5f93f5f/
96	astaxie/bat	Go implement CLI, cURL-like tool for humans	go	2,563	1,091	71.8%	https://programbench.com/task/astaxie__bat.17d1080/
97	zk-org/zk	Plain text note-taking assistant	go	2,542	1,108	43.1%	https://programbench.com/task/zk-org__zk.10d93d5/
98	kisielk/errcheck	errcheck checks that you checked errors.	go	2,480	341	80.4%	https://programbench.com/task/kisielk__errcheck.dacab89/
99	mkj/dropbear	Dropbear SSH	c	2,231	682	58.1%	https://programbench.com/task/mkj__dropbear.75f699b/
100	noborus/trdsql	CLI tool that can execute SQL queries on CSV, LTSV, JSON, YAML and TBLN. Can output to various formats.	go	2,159	1,312	66.8%	https://programbench.com/task/noborus__trdsql.d8c5ff6/
101	sheepla/pingu	🐧ping command but with pingu	go	2,087	383	96.6%	https://programbench.com/task/sheepla__pingu.926d475/
102	go-critic/go-critic	The most opinionated Go source code linter for code audit.	go	2,041	493	41.6%	https://programbench.com/task/go-critic__go-critic.9aea378/
103	OSGeo/PROJ	PROJ - Cartographic Projections and Coordinate Transformations Library	cpp	1,974	5,319	73.8%	https://programbench.com/task/osgeo__proj.75d455c/
104	noborus/ov	🎑Feature-rich terminal-based text viewer. It is a so-called terminal pager.	go	1,935	1,854	87.6%	https://programbench.com/task/noborus__ov.b96c2ba/
105	samtools/samtools	Tools (written in C using htslib) for manipulating next-generation sequencing data	c	1,886	1,425	14.2%	https://programbench.com/task/samtools__samtools.aa823b5/
106	gabotechs/dep-tree	Tool for helping developers keep their code bases clean and decoupled. It allows visualising a code base complexity using a 3d force-directed graph of files and the dependencies between them.	go	1,706	865	65.2%	https://programbench.com/task/gabotechs__dep-tree.60a95a2/
107	cmatsuoka/figlet	Claudio’s FIGlet tree	c	1,606	872	77.5%	https://programbench.com/task/cmatsuoka__figlet.202a0a8/
108	lh3/seqtk	Toolkit for processing sequences in FASTA/Q formats	c	1,537	429	67.4%	https://programbench.com/task/lh3__seqtk.94e7070/
109	tukaani-project/xz	XZ Utils	c	1,522	1,410	36.0%	https://programbench.com/task/tukaani-project__xz.1007bf0/
110	skeema/skeema	Declarative pure-SQL schema management for MySQL and MariaDB	go	1,361	1,708	76.5%	https://programbench.com/task/skeema__skeema.6a76243/
111	mfridman/tparse	CLI tool for summarizing go test output. Pipe friendly. CI/CD friendly.	go	1,246	425	77.6%	https://programbench.com/task/mfridman__tparse.2416b4b/
112	lfos/calcurse	A text-based calendar and scheduling application	c	1,243	666	53.8%	https://programbench.com/task/lfos__calcurse.49180d5/
113	hooklift/gowsdl	WSDL2Go code generation as well as its SOAP proxy	go	1,219	391	86.4%	https://programbench.com/task/hooklift__gowsdl.2a06cec/
114	guumaster/hostctl	Your dev tool to manage /etc/hosts like a pro!	go	1,216	1,051	82.8%	https://programbench.com/task/guumaster__hostctl.d6d9699/
115	rs/jplot	iTerm2 expvar/JSON monitoring tool	go	1,178	583	89.0%	https://programbench.com/task/rs__jplot.2a54bcc/
116	naggie/dstask	Git powered terminal-based todo/note manager – markdown note page per task. Single binary!	go	1,157	1,278	58.8%	https://programbench.com/task/naggie__dstask.ff57396/
117	sigoden/argc	A Bash CLI framework, also a Bash command runner.	rs	1,135	995	44.1%	https://programbench.com/task/sigoden__argc.04a08f1/
118	sibprogrammer/xq	Command-line XML and HTML beautifier and content extractor	go	1,109	792	75.9%	https://programbench.com/task/sibprogrammer__xq.b89f681/
119	xorg62/tty-clock	Clock using lib ncurses	c	1,105	281	84.0%	https://programbench.com/task/xorg62__tty-clock.f2f847c/
120	unhappychoice/gittype	A CLI code-typing game that turns your source code into typing challenges	rs	1,075	741	91.3%	https://programbench.com/task/unhappychoice__gittype.34b72d0/
121	eudoxia0/hashcards	A plain text-based spaced repetition system.	rs	1,071	1,151	56.3%	https://programbench.com/task/eudoxia0__hashcards.48aa136/
122	rvben/rumdl	Fast Markdown linter and formatter written in Rust	rs	1,051	3,322	40.7%	https://programbench.com/task/rvben__rumdl.2d75c4d/
123	sclevine/yj	CLI - Convert between YAML, TOML, JSON, and HCL. Preserves map order.	go	1,041	767	74.4%	https://programbench.com/task/sclevine__yj.8016400/
124	arq5x/bedtools2	bedtools - the swiss army knife for genome arithmetic	c	1,029	1,053	38.9%	https://programbench.com/task/arq5x__bedtools2.dd57059/
125	cslarsen/jp2a	Converts jpg images to ASCII	c	1,021	631	56.1%	https://programbench.com/task/cslarsen__jp2a.61d205f/
126	blacknon/hwatch	A modern alternative to the watch command, records the differences in execution results and can check this differences at after.	rs	1,016	1,016	81.1%	https://programbench.com/task/blacknon__hwatch.edfcb62/
127	eliukblau/pixterm	Draw images in your ANSI terminal with true color	go	1,014	430	74.9%	https://programbench.com/task/eliukblau__pixterm.1a93fd5/
128	Canop/rhit	A nginx log explorer	rs	1,006	817	53.2%	https://programbench.com/task/canop__rhit.ae90bcb/
129	stathissideris/ditaa	ditaa is a small command-line utility that can convert diagrams drawn using ascii art (‘drawings’ that contain characters that resemble lines like \| / - ), into proper bitmap graphics.	java	1,005	609	20.4%	https://programbench.com/task/stathissideris__ditaa.f2286c4/
130	rbakbashev/elfcat	ELF visualizer. Generates HTML files from ELF binaries.	rs	990	564	98.2%	https://programbench.com/task/rbakbashev__elfcat.52f8cc7/
131	nuta/nsh	A command-line shell like fish, but POSIX compatible.	rs	966	1,963	83.7%	https://programbench.com/task/nuta__nsh.bdd0702/
132	dalance/amber	A code search / replace tool	rs	941	567	71.1%	https://programbench.com/task/dalance__amber.69a0f52/
133	pls-rs/pls	pls is a prettier and powerful ls(1) for the pros.	rs	932	332	62.3%	https://programbench.com/task/pls-rs__pls.4e1ae50/
134	Esubaalew/run	Universal multi-language runner and smart REPL written in Rust.	rs	919	1,212	85.2%	https://programbench.com/task/esubaalew__run.0fb9dec/
135	chirlu/sox	SoX, Swiss Army knife of sound processing	c	913	1,202	37.9%	https://programbench.com/task/chirlu__sox.42b3557/
136	clog-tool/clog-cli	Generate beautiful changelogs from your Git commit history	rs	912	575	93.0%	https://programbench.com/task/clog-tool__clog-cli.7066cba/
137	tarka/xcp	An extended `cp`	rs	911	1,184	92.6%	https://programbench.com/task/tarka__xcp.5e5b448/
138	oppiliappan/eva	a calculator REPL, similar to bc(1)	rs	907	913	88.7%	https://programbench.com/task/oppiliappan__eva.41ae245/
139	git-bahn/git-graph	Command line tool to show clear git graphs arranged for your branching model	rs	904	568	79.6%	https://programbench.com/task/git-bahn__git-graph.87b4473/
140	gromacs/gromacs	Public/backup repository of the GROMACS molecular simulation toolkit. Please do not mine the metadata blindly; we use https://gitlab.com/gromacs/gromacs for code review and issue tracking.	cpp	901	1,245	9.3%	https://programbench.com/task/gromacs__gromacs.665ea4c/
141	sirwart/ripsecrets	A command-line tool to prevent committing secret keys into your source code	rs	901	611	72.8%	https://programbench.com/task/sirwart__ripsecrets.34c9e03/
142	Drew-Alleman/DataSurgeon	Quickly Extracts IP’s, Email Addresses, Hashes, Files, Credit Cards, Social Security Numbers and a lot More From Text	rs	890	502	74.3%	https://programbench.com/task/drew-alleman__datasurgeon.d257cee/
143	alexpovel/srgn	A grep-like tool which understands source code syntax and allows for manipulation in addition to search	rs	889	1,852	69.5%	https://programbench.com/task/alexpovel__srgn.89f943b/
144	kyoheiu/felix	tui file manager with vim-like key mapping	rs	888	502	49.2%	https://programbench.com/task/kyoheiu__felix.95df390/
145	oppiliappan/statix	lints and suggestions for the nix programming language	rs	882	815	42.8%	https://programbench.com/task/oppiliappan__statix.e9df54c/
146	nachoparker/dutree	a tool to analyze file system usage written in Rust	rs	871	641	89.5%	https://programbench.com/task/nachoparker__dutree.44e877d/
147	simeg/eureka	💡 CLI tool to input and store your ideas without leaving the terminal	rs	867	344	78.8%	https://programbench.com/task/simeg__eureka.df3796c/
148	kyoh86/richgo	Enrich `go test` outputs with text decorations.	go	863	546	85.0%	https://programbench.com/task/kyoh86__richgo.313114f/
149	rochacbruno/marmite	Markdown makes sites - A Static Site Generator for Blogs	rs	837	668	45.4%	https://programbench.com/task/rochacbruno__marmite.7d4bc2d/
150	rust-embedded/svd2rust	Generate Rust register maps (`struct`s) from SVD files	rs	835	920	72.9%	https://programbench.com/task/rust-embedded__svd2rust.1760b5e/
151	konradsz/igrep	Interactive Grep	rs	827	385	73.5%	https://programbench.com/task/konradsz__igrep.aa75630/
152	nikolassv/bartib	A simple timetracker for the command line. It saves a log of all tracked activities as a plaintext file and allows you to create flexible reports.	rs	827	722	87.3%	https://programbench.com/task/nikolassv__bartib.6b9b5ce/
153	yassinebridi/serpl	A simple terminal UI for search and replace, ala VS Code.	rs	824	446	61.0%	https://programbench.com/task/yassinebridi__serpl.c48a9d7/
154	riquito/tuc	When cut doesn’t cut it	rs	820	1,196	92.7%	https://programbench.com/task/riquito__tuc.16fb471/
155	ecumene/rust-sloth	A 3D software rasterizer… for the terminal!	rs	818	380	52.6%	https://programbench.com/task/ecumene__rust-sloth.051c559/
156	crowdagger/crowbook	Converts books written in Markdown to HTML, LaTeX/PDF and EPUB	rs	813	807	60.3%	https://programbench.com/task/crowdagger__crowbook.ea214d7/
157	WGUNDERWOOD/tex-fmt	An extremely fast LaTeX formatter written in Rust	rs	789	455	80.7%	https://programbench.com/task/wgunderwood__tex-fmt.3f1aef6/
158	Stranger6667/jsonschema	A high-performance JSON Schema validator for Rust	rs	770	2,933	51.7%	https://programbench.com/task/stranger6667__jsonschema.d52e881/
159	rhysd/kiro-editor	A small terminal UTF-8 text editor written in Rust 📝🦀	rs	761	595	93.3%	https://programbench.com/task/rhysd__kiro-editor.4157485/
160	astro/deadnix	Scan Nix files for dead code	rs	745	602	85.5%	https://programbench.com/task/astro__deadnix.d590041/
161	sstadick/hck	A sharp cut(1) clone.	rs	738	855	95.7%	https://programbench.com/task/sstadick__hck.b66c751/
162	trasta298/keifu	Git genealogy, untangled. A TUI for navigating commit graphs with color and clarity.	rs	729	262	67.2%	https://programbench.com/task/trasta298__keifu.3331426/
163	AmmarAbouZor/tui-journal	Your journal app if you live in a terminal	rs	722	1,402	70.8%	https://programbench.com/task/ammarabouzor__tui-journal.2b4540d/
164	incu6us/goimports-reviser	Right imports sorting & code formatting tool (goimports alternative)	go	715	513	86.4%	https://programbench.com/task/incu6us__goimports-reviser.81bd549/
165	yaa110/nomino	Batch rename utility for developers	rs	710	313	79.9%	https://programbench.com/task/yaa110__nomino.f892499/
166	wfxr/csview	📠 Pretty and fast csv viewer for cli with cjk/emoji support.	rs	694	335	96.1%	https://programbench.com/task/wfxr__csview.8ac4de0/
167	chmln/handlr	A better xdg-utils	rs	693	722	90.7%	https://programbench.com/task/chmln__handlr.90e78ba/
168	Miserlou/Loop	UNIX’s missing `loop` command	rs	692	710	94.6%	https://programbench.com/task/miserlou__loop.209927c/
169	KSXGitHub/parallel-disk-usage	Highly parallelized, blazing fast directory tree analyzer	rs	689	531	86.1%	https://programbench.com/task/ksxgithub__parallel-disk-usage.96978ed/
170	hush-shell/hush	Hush is a unix shell based on the Lua programming language	rs	688	1,201	83.3%	https://programbench.com/task/hush-shell__hush.560c33a/
171	zevv/duc	Dude, where are my bytes: Duc, a library and suite of tools for inspecting disk usage	c	682	874	83.4%	https://programbench.com/task/zevv__duc.a58fa4e/
172	altdesktop/i3-style	🎨 Make your i3 config a little more stylish.	rs	678	539	80.0%	https://programbench.com/task/altdesktop__i3-style.f93821b/
173	wintermute-cell/ngrrram	A TUI tool to help you type faster and learn new layouts. Includes a free cat.	rs	674	303	84.5%	https://programbench.com/task/wintermute-cell__ngrrram.8ea13c3/
174	psampaz/go-mod-outdated	Find outdated dependencies of your Go projects. go-mod-outdated provides a table view of the go list -u -m -json all command which lists all dependencies of a Go project and their available minor and patch updates. It also provides a way to filter indirect dependencies and dependencies without updates.	go	669	285	98.2%	https://programbench.com/task/psampaz__go-mod-outdated.bb79367/
175	wfxr/code-minimap	🛰 A high performance code minimap render.	rs	660	313	88.8%	https://programbench.com/task/wfxr__code-minimap.0ddeea5/
176	kaushiksrini/parqeye	Peek inside Parquet files right from your terminal	rs	654	479	58.9%	https://programbench.com/task/kaushiksrini__parqeye.8072121/
177	stacked-git/stgit	Stacked Git	rs	652	1,488	20.0%	https://programbench.com/task/stacked-git__stgit.430027d/
178	Isona/dirble	Fast directory scanning and scraping tool	rs	632	718	66.7%	https://programbench.com/task/isona__dirble.e2dea9f/
179	YS-L/flamelens	Flamegraph viewer in the terminal	rs	622	224	59.4%	https://programbench.com/task/ys-l__flamelens.0b4dc33/
180	mookid/diffr	Yet another diff highlighting tool	rs	612	606	84.7%	https://programbench.com/task/mookid__diffr.2152742/
181	shashwatah/jot	⚡Rapid note management for the terminal.	rs	609	752	84.6%	https://programbench.com/task/shashwatah__jot.a92aad8/
182	Epistates/treemd	A (TUI/CLI) markdown navigator with tree-based structural navigation.	rs	603	1,569	55.1%	https://programbench.com/task/epistates__treemd.825c6dd/
183	pier-cli/pier	A CLI to organize and run short Unix shell scripts	rs	596	692	83.7%	https://programbench.com/task/pier-cli__pier.5e1bde9/
184	jrnxf/thokr	✨ sleek typing tui with visualized results and historical logging	rs	595	445	82.2%	https://programbench.com/task/jrnxf__thokr.09375ef/
185	ismaelgv/rnr	A command-line tool to batch rename files and directories	rs	581	683	82.1%	https://programbench.com/task/ismaelgv__rnr.fc0733b/
186	sitkevij/hex	🔮 Futuristic take on hexdump, made in Rust.	rs	563	823	91.7%	https://programbench.com/task/sitkevij__hex.61ae69b/
187	brocode/fblog	Small command-line JSON Log viewer	rs	561	978	86.0%	https://programbench.com/task/brocode__fblog.3b54330/
188	codesnap-rs/codesnap	🦀️📸 Pure Rust tool to generate beautiful code snapshots, provide CLI and Library	rs	557	730	59.2%	https://programbench.com/task/codesnap-rs__codesnap.f81e4f3/
189	foriequal0/git-trim	Automatically trims your branches whose tracking remote refs are merged or stray	rs	548	509	64.6%	https://programbench.com/task/foriequal0__git-trim.07c2f50/
190	axodotdev/oranda	🎁 generate beautiful landing pages for your developer tools	rs	542	767	53.6%	https://programbench.com/task/axodotdev__oranda.27d60c7/
191	elkowar/pipr	A tool to interactively write shell pipelines.	rs	541	525	57.1%	https://programbench.com/task/elkowar__pipr.fae0b17/
192	paradigmxyz/solar	Blazingly fast, modular and contributor friendly Solidity compiler, written in Rust	rs	539	1,978	43.3%	https://programbench.com/task/paradigmxyz__solar.5190d0e/
193	Lymphatus/caesium-clt	Caesium Command Line Tools - Lossy/lossless image compression tool	rs	537	575	92.3%	https://programbench.com/task/lymphatus__caesium-clt.a529b2e/
194	agourlay/zip-password-finder	Find the password of protected ZIP files.	rs	534	680	97.9%	https://programbench.com/task/agourlay__zip-password-finder.704700d/
195	rust-ethereum/ethabi	Encode and decode smart contract invocations	rs	525	997	90.9%	https://programbench.com/task/rust-ethereum__ethabi.b1710ad/
196	ArthurSonzogni/json-tui	A JSON terminal UI made in C++	cpp	438	755	71.0%	https://programbench.com/task/arthursonzogni__json-tui.17a22b6/
197	tomarrell/wrapcheck	A Go linter to check that errors from external packages are wrapped	go	374	480	80.8%	https://programbench.com/task/tomarrell__wrapcheck.c058da1/
198	NikolaDucak/caps-log	A small TUI journaling tool. 📖	cpp	370	551	61.7%	https://programbench.com/task/nikoladucak__caps-log.2cf2d1e/
199	mibk/dupl	a tool for code clone detection	go	367	373	85.0%	https://programbench.com/task/mibk__dupl.1bf052b/
200	HaliteChallenge/Halite	@twosigma’s first artificial intelligence programming challenge	cpp	202	275	80.4%	https://programbench.com/task/halitechallenge__halite.822cfb6/

Cómo leer estos datos

En el leaderboard principal de ProgramBench, los 9 modelos tienen Resolved en 0%. Bajo una configuración unificada con un agent ligero, los modelos actuales todavía no pueden reconstruir software completo de forma fiable a partir de comportamiento de caja negra y documentación.

Almost resolved sí permite distinguir capacidades. Claude Opus 4.7 alcanza 3.0%, Claude Opus 4.6 llega a 2.5%, Claude Sonnet 4.6 llega a 1.0% y el resto de modelos queda en 0.0%. Este indicador sirve mejor para observar la capacidad de acercarse a una solución completa que mirar solo la finalización total.

La tabla de instancias también es importante. Enumera el lenguaje, las estrellas, el número de pruebas y el mejor resultado actual de cada proyecto open source, mostrando que ProgramBench cubre compresión, búsqueda, bases de datos, compiladores, herramientas de línea de comandos, procesamiento multimedia y otros tipos de software. Para AI Coding, esto se parece mucho más a presión de ingeniería real que un benchmark simple de algoritmos.

ProgramBench 0% explicado: lo inquietante no es el fallo, sino que la hoja de ruta ya está clara

Sun, 10 May 2026 12:32:39 +0800

En el mundo de AI Coding acaba de aparecer un nuevo benchmark: ProgramBench. A primera vista, su resultado parece tranquilizador para los programadores: nueve modelos principales obtuvieron 0% en la métrica fully resolved, y ningún modelo completó por completo ni una sola tarea.

Pero lo verdaderamente inquietante no es que los grandes modelos actuales todavía fallen. Lo importante es que, por primera vez, la ingeniería de software completa se ha convertido en un conjunto claro de tareas evaluables, clasificables y optimizables de forma repetida.

Una vez que una tarea queda definida con claridad, la industria de IA suele hacer lo que mejor sabe hacer: resolver el benchmark, iterar, perseguir el leaderboard y empujar poco a poco lo que antes parecía imposible hacia el borde de lo utilizable.

Qué mide ProgramBench

Muchos benchmarks de programación miden completar funciones, corregir bugs, pasar unit tests o añadir una pequeña función a un proyecto existente. ProgramBench es mucho más duro. No proporciona código fuente, ni estructura de proyecto, ni test cases ya preparados.

El modelo recibe principalmente solo dos cosas:

Un ejecutable ya compilado.
La documentación de uso de ese programa.

El modelo debe ejecutar el binario por su cuenta, observar el comportamiento de entrada y salida, entender argumentos de línea de comandos, casos límite, mensajes de error y formas de almacenamiento de datos, y luego volver a implementar un programa con comportamiento equivalente.

Esto ya no es “escribir un fragmento de código”. Es una tarea de ingeniería de software simplificada pero completa: entender requisitos, explorar comportamiento, elegir lenguaje, diseñar estructura, escribir código fuente, proporcionar un método de build e intentar pasar las pruebas ocultas.

Según la descripción oficial de ProgramBench, actualmente contiene 200 tareas, desde pequeñas herramientas de línea de comandos hasta proyectos reales grandes como PHP, FFmpeg y SQLite. El conjunto de pruebas se genera mediante agent-driven fuzzing y supera las 248.000 pruebas de comportamiento.

Si descomponemos el flujo de evaluación, ProgramBench mide aproximadamente cuatro capacidades:

Leer documentación: entender qué comandos, argumentos y salidas debe ofrecer el programa.
Explorar comportamiento: ejecutar repetidamente el binario y observar entradas normales, entradas inválidas y casos límite.
Reconstruir la implementación: elegir lenguaje y estructura de proyecto, y escribir un reemplazo con comportamiento cercano.
Pasar pruebas ocultas: no basta con acertar el comportamiento normal; también cuentan el manejo de errores, el formato de salida y las condiciones de borde.

Por eso su valor de búsqueda no es simplemente “otro ranking”. Responde a una pregunta más concreta: ¿puede un gran modelo recrear software real desde cero, sin código fuente, usando solo documentación y comportamiento de caja negra?

Por qué el resultado es 0%

La métrica principal de ProgramBench es fully resolved: una tarea solo cuenta como completada si todas sus pruebas pasan. En el leaderboard actual, los nueve modelos tienen 0% en esta métrica.

Los modelos evaluados incluyen familias como Claude, GPT y Gemini, todos usando mini-SWE-agent como agent base. Claude Opus 4.7 es el mejor en la métrica almost resolved, con alrededor de 3.0% de tareas que pasan al menos el 95% de las pruebas. Claude Opus 4.6 llega a 2.5%, y Claude Sonnet 4.6 a 1.0%. GPT 5.4, GPT 5.4 mini, Gemini 3.1 Pro, Gemini 3 Flash y otros quedan en 0.0% en almost resolved.

Esto muestra que los grandes modelos actuales, combinados con un agent ligero, todavía no pueden reconstruir software completo desde cero. Incluso en las tareas más simples, alinear todos los detalles resulta difícil.

Pero hay un matiz importante: esta evaluación usó mini-SWE-agent, no Claude Code ni Codex. Con un coding agent más fuerte, más soporte de herramientas y un ciclo de exploración más largo, los resultados podrían mejorar. La interpretación más precisa es: los modelos actuales con un agent ligero aún no bastan para completar de forma estable la reconstrucción de software completo.

Qué significan fully resolved y almost resolved

Al leer los resultados de ProgramBench, estas dos métricas son fáciles de confundir.

fully resolved es la métrica más estricta: todas las pruebas ocultas de una tarea deben pasar para que se considere completamente resuelta. Si falta un caso límite, un formato de error o un comportamiento de argumento de línea de comandos, la tarea no cuenta como fully resolved.

almost resolved se parece más a “casi completado”: si una tarea pasa al menos el 95% de sus pruebas, entra en almost resolved. Refleja si el modelo logró reproducir la mayor parte del comportamiento, pero no significa que el programa ya pueda sustituir al software original.

Por eso el 0% debe leerse por partes. El 0% en fully resolved indica que los modelos aún no pueden entregar una solución completa. La diferencia en almost resolved muestra qué modelos ya se acercan al éxito en algunas tareas. Por ejemplo, Claude Opus 4.7 alcanza alrededor de 3.0% en almost resolved, lo que indica que se acerca más en unas pocas tareas relativamente simples, pero sigue muy lejos de reconstruir software completo de forma estable.

Por qué mini-SWE-agent afecta el resultado

La evaluación usa un mini-SWE-agent unificado, lo cual tiene una ventaja clara: equidad. Todos los modelos corren sobre el mismo marco ligero de agent, así que la comparación horizontal es más sencilla.

Pero también limita el techo. La reconstrucción de software completo no depende solo del modelo. También depende de si el agent puede planificar una estrategia de exploración, gestionar tareas largas, generar tests automáticamente, localizar causas de fallo de forma repetida y organizar la estructura del proyecto.

mini-SWE-agent se parece más a una línea base común que al entorno de ingeniería más potente posible.

Coding agents más completos como Claude Code o Codex suelen ofrecer mejor uso de herramientas, organización de contexto, descomposición de tareas y reparación en múltiples rondas. Si se usaran esas herramientas, los resultados podrían ser mejores.

Así que el resultado de ProgramBench se entiende mejor así: los modelos actuales no pueden realizar reconstrucción completa de software en un entorno de agent ligero. No demuestra que los modelos nunca podrán hacerlo, ni mide por completo el techo de todos los coding agents comerciales.

Diferencias con SWE-bench

SWE-bench ya es un benchmark importante en AI Coding. Pide a los modelos leer issues en repositorios reales de GitHub, modificar código y enviar parches, para evaluar su capacidad de resolver bugs reales.

Pero SWE-bench sigue siendo, en esencia, reparar un coche existente: el coche ya está ahí, y el stack tecnológico, la estructura de directorios, la organización del código y la arquitectura ya fueron creados por humanos. El modelo solo necesita encontrar el problema y arreglar la pieza rota.

ProgramBench se parece más a construir el coche de nuevo: solo sabes qué comportamiento debe tener, por ejemplo detenerse ante un semáforo rojo o tocar la bocina cerca de peatones. La estructura, el lenguaje, los módulos y el método de build deben decidirse desde cero.

Por eso es mucho más difícil. Ya no evalúa solo la capacidad de hacer parches locales, sino arquitectura de software, razonamiento de sistemas, exploración de comportamiento, pruebas automáticas, corrección en múltiples rondas y diseño de ingeniería a largo plazo.

La diferencia puede resumirse así:

Dimensión	SWE-bench	ProgramBench
Punto de partida	Repositorio de GitHub e issue existentes	Ejecutable compilado y documentación de uso
Código fuente disponible	Sí	No
Tarea principal	Corregir un bug en un proyecto existente	Reimplementar un programa completo a partir del comportamiento
Stack tecnológico	Ya definido por el proyecto	Elegido por el modelo
Estructura del proyecto	Ya existe	Diseñada por el modelo
Método de prueba	Ejecutar tests tras enviar un parche	Usar pruebas ocultas de comportamiento para medir la reconstrucción
Enfoque principal	Leer código, localizar problemas, reparar con parches	Explorar comportamiento, abstraer sistemas, diseñar arquitectura, implementar completo

Por eso ProgramBench encaja mejor como objetivo de la siguiente etapa de AI Coding: empuja el problema desde “arreglar código existente” hacia “reconstruir software completo”.

0% no significa seguridad

Al ver 0%, la primera reacción de muchas personas puede ser: el trabajo de los programadores está a salvo por ahora.

A corto plazo, eso es cierto. Los grandes modelos actuales todavía no pueden completar ingeniería de software completa de forma estable, especialmente sin código fuente, test cases ni estructura de proyecto. La aclaración de requisitos, el diseño de arquitectura, el mantenimiento a largo plazo, el control de seguridad, la colaboración de equipo y la comprensión del negocio siguen siendo ventajas importantes de los ingenieros humanos.

Pero interpretar 0% como “AI Coding llegó a su límite” sería demasiado optimista.

Lo que ProgramBench cambia de verdad es la definición del problema. Antes ya sabíamos que la IA podía completar código y corregir bugs, pero “reconstruir software completo a partir de un ejecutable y documentación” no estaba colocado en una pista común. Ahora son 200 tareas, una evaluación unificada y un ranking unificado.

Eso significa que las empresas de modelos, agents y herramientas de desarrollo saben hacia dónde empujar: hacer que la IA evolucione de escribir fragmentos de código a mantener, reconstruir y entregar sistemas de software completos.

Por qué hacen falta modo offline y anti-cheating

Hay un detalle importante en el diseño de ProgramBench: evitar trampas.

En pruebas iniciales, los modelos intentaban encontrar directamente el código fuente en GitHub, descargar paquetes que contenían el código mediante package managers, o incluso buscar paquetes ya descargados en directorios de caché del sistema. Eso rompe el propósito de la evaluación, porque la pregunta deja de ser “puede reconstruir software desde el comportamiento” y pasa a ser “puede encontrar el código fuente original”.

Por eso ProgramBench usa sandbox y entorno offline. No permite acceso a internet, ni decompilación, ni desensamblado, ni lectura del contenido del ejecutable. El modelo solo puede ejecutar el programa, observar su comportamiento y luego implementar su propia versión.

Esta restricción hace la evaluación más limpia y la acerca a la pregunta real: ¿puede un gran modelo de lenguaje partir del comportamiento y la documentación de un programa para construir por sí mismo un proyecto de software ejecutable?

Qué deben mejorar realmente los programadores

El resultado de ProgramBench no es simplemente una buena noticia ni una mala noticia para los programadores.

A corto plazo, la ingeniería de software completa sigue siendo difícil, y los programadores no van a perder su trabajo de inmediato por este benchmark. En especial, el juicio arquitectónico, la aclaración de requisitos, el control de seguridad, la validación de calidad y la comprensión del negocio todavía requieren responsabilidad humana.

A largo plazo, el trabajo del programador seguirá subiendo de nivel. Las personas más vulnerables no son quienes “no saben escribir código”, sino quienes solo saben escribir código y no saben definir problemas, verificar resultados, organizar toolchains ni controlar riesgos.

El ingeniero de software del futuro podría parecerse más a esto:

Definidor de requisitos: convertir problemas de negocio difusos en objetivos ejecutables.
Validador de sistemas: juzgar si el resultado generado por IA realmente cumple los requisitos.
Organizador de toolchains: combinar modelos, agents, tests, despliegue y monitorización.
Responsable de calidad: controlar seguridad, mantenibilidad, casos límite y riesgos a largo plazo.
Traductor entre negocio y tecnología: convertir problemas reales en restricciones que un sistema de ingeniería pueda manejar.

Si la IA realmente evoluciona de asistente de código a ingeniero de software completo, el valor del programador humano ya no será escribir cada línea a mano. Será definir qué vale la pena construir, qué cuenta como correcto y dónde no se puede fallar.

Resumen

El 0% de ProgramBench no es el final. Es el comienzo de una nueva etapa.

Muestra que los grandes modelos actuales todavía no pueden reconstruir de forma estable sistemas de software completos desde cero. Pero también define con claridad el objetivo de la próxima generación de AI Coding agents: pasar de parches locales a proyectos completos, de fragmentos de código a entrega de sistemas.

Para los programadores, a corto plazo se puede respirar un poco. Pero a largo plazo no conviene quedarse mirando solo que “la IA todavía no puede”. Lo más importante es subir cuanto antes de ejecutor de código a definidor de problemas, validador de resultados y controlador de riesgos.

Lo verdaderamente inquietante no es que la IA haya sacado 0% hoy. Es que el examen ya está escrito.

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”.

Qué ocurrió en el incidente de facturación HERMES.md de Claude Code

Sat, 02 May 2026 11:19:23 +0800

Claude Code tuvo recientemente un incidente de facturación bastante típico: un usuario solo inició el CLI y no había hecho una petición explícita, pero un archivo local grande HERMES.md fue leído y generó un cargo considerable.

Vale la pena mirarlo porque expone un nuevo riesgo en herramientas de programación con IA. En cuanto una herramienta lee contexto automáticamente, los archivos locales pueden convertirse en coste real de tokens.

Qué ocurrió

El issue público muestra que el usuario tenía un archivo HERMES.md grande en el directorio de trabajo. Cuando Claude Code arrancó, el CLI escaneó y cargó contexto del proyecto. El problema fue que ese archivo se incluyó automáticamente en el contexto y contó como uso de API.

El usuario no pidió explícitamente al modelo procesar ese archivo, pero la facturación ya había ocurrido. La parte más delicada es que esto puede pasar durante inicialización o preparación de contexto, así que los usuarios pueden no darse cuenta de inmediato de que se está generando coste.

Anthropic respondió después en el issue que reembolsaría el cargo anómalo y daría créditos adicionales. Eso confirma que el problema fue reconocido y gestionado, pero también recuerda a los usuarios que el “contexto automático” en un CLI de IA no es gratis.

Por qué HERMES.md lo disparó

HERMES.md en sí no es el punto. Podría ser cualquier archivo grande: logs, documentos exportados, datos de prueba, volcados de base de datos o informes generados.

El problema real es la combinación de tres cosas:

Claude Code lee automáticamente el contexto del proyecto.
El archivo leído puede ser grande.
Los tokens de contexto entran en la ruta de facturación.

Si un archivo es lo bastante grande, incluso ser incluido “de pasada” puede crear un coste notable. Para modelos basados en tokens, una automatización más fuerte necesita límites más claros.

No es un bug ordinario

Un bug normal de CLI puede significar un comando fallido, una salida incorrecta o una función rota. Un bug de facturación es más sensible porque afecta directamente a la factura del usuario.

En herramientas de programación con IA, el límite de facturación puede ser borroso:

Los system prompts consumen tokens.
Las reglas de proyecto consumen tokens.
Los archivos leídos automáticamente consumen tokens.
Los resultados de llamadas de herramientas consumen tokens.
Reintentos, compresión y resúmenes pueden seguir consumiendo tokens.

El usuario puede ver solo “arrancar la herramienta” o “un chat”, mientras en segundo plano ya se enviaron varias solicitudes con mucho contexto.

Cómo pueden reducir el riesgo los usuarios

Si usas Claude Code, Codex, Cline o herramientas similares de programación con IA, empieza con algunos hábitos:

No pongas archivos grandes directamente en la raíz del proyecto.
Añade logs, datos exportados, salidas de build y archivos temporales a reglas de ignore.
Comprueba si la herramienta admite .ignore, exclusión de contexto o allowlists de archivos.
Activa alertas de presupuesto o límites de uso.
Prueba en un directorio pequeño antes de ejecutarla en un repositorio grande.

Si un repositorio debe conservar archivos grandes, dile explícitamente a la herramienta que no los lea. Las reglas de proyecto también pueden decir: no leer proactivamente logs, dumps, datasets, archivos comprimidos ni Markdown grandes.

Qué deberían mejorar los proveedores

Esto no puede depender solo de la cautela del usuario. Las herramientas deberían ofrecer límites duros.

Mejores diseños incluirían:

La inicialización no debería facturar silenciosamente por archivos grandes.
Leer automáticamente archivos muy grandes debería requerir confirmación.
El CLI debería mostrar tokens estimados y rango de coste para la solicitud.
Archivos grandes comunes y directorios generados deberían ignorarse por defecto.
Los picos anómalos de tokens deberían tener umbrales de protección.

Cuanto más se comporten las herramientas de programación con IA como agentes autónomos, más transparentes deben ser sus costes. De lo contrario, los usuarios no pueden juzgar cuánto costará una operación concreta.

Resumen

El incidente de facturación HERMES.md de Claude Code es, en esencia, un conflicto entre contexto automático y facturación por uso.

Para usuarios, la clave es controlar el contexto del proyecto: no exponer archivos grandes a herramientas de IA por defecto, y configurar límites de presupuesto y uso. Para proveedores, la lectura automática de archivos necesita avisos visibles de coste y mecanismos de protección.

Referencias:

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?

La configuración de entorno en cuatro partes de Claude Code: CLAUDE.md, Rules, Memory y Hooks

Thu, 23 Apr 2026 10:43:40 +0800

Si usas Claude Code durante un tiempo, pronto notas algo: el modelo importa, pero el entorno que le das, los límites que defines y las reglas que configuras importan igual.

Al principio, mucha gente se centra en “cómo escribo este prompt”. Pero cuando empiezas a usar Claude Code en serio, te importa más otra cosa:

¿Sabe quién eres?
¿Sabe cómo trabajas?
¿Sabe qué reglas no puede romper?
¿Sabe qué acciones requieren confirmación primero?
¿Puede recordar esos límites con el tiempo?

Lo que vuelve maduro a Claude Code no es solo la capacidad del modelo. Es que hay un sistema completo para convertir tu estilo de trabajo en estructura persistente. A alto nivel, ese sistema puede dividirse en cuatro capas:

CLAUDE.md
Rules
Memory
Hooks

Este artículo explica las cuatro.

Por qué la configuración de entorno importa más que prompts únicos

Puedes pensar en Claude Code como un asistente que contrataste.

El primer día no le dirías solo “ayúdame a hacer cosas”. Le darías un manual y explicarías:

quién eres
qué estilo de comunicación prefieres
qué acciones siempre requieren confirmación
qué errores ya ocurrieron y no deben repetirse
dónde están los documentos importantes del proyecto

Por eso, a largo plazo, la configuración de entorno suele importar más que un prompt aislado.

Un prompt resuelve “qué hacemos esta vez”. La configuración de entorno resuelve “cómo trabajamos cada vez desde ahora”.

Capa 1: `CLAUDE.md`

Empieza por la pieza básica. CLAUDE.md es esencialmente un archivo de texto.

Puedes escribir instrucciones para Claude, como:

quién eres
en qué trabajas
tus preferencias de comunicación
reglas obligatorias
contexto especial del proyecto actual
dónde están documentos o directorios importantes

Cada vez que Claude Code arranca, este documento se inyecta automáticamente en el contexto, así que el modelo lo leerá.

Suelo pensarlo como un “archivo de entendimiento compartido”, porque eso es: el acuerdo permanente entre tú y el modelo.

Qué poner en `CLAUDE.md`

Lo mejor para CLAUDE.md suele ser:

identidad y contexto de trabajo
preferencias de tono y salida
reglas globales de comportamiento
contexto de proyecto que aparece a menudo
errores comunes y cómo evitarlos

Por ejemplo:

tu zona horaria
si permites que el modelo envíe emails o mensajes directamente
qué acciones son irreversibles
tus hábitos con documentos y archivos
prácticas de seguridad y límites sobre información sensible

Un principio muy importante: mantenerlo conciso

Un principio clave para CLAUDE.md: mantenlo lo más conciso posible.

La razón es simple: se inyecta en contexto cada vez.

Si crece demasiado, ocupa demasiado espacio de contexto y diluye la información importante. El modelo no lo ignora, pero su atención se dispersa, así que es más probable que pase por alto reglas críticas.

La recomendación oficial suele ser mantenerlo por debajo de 400 líneas.

Mi hábito es aún más conservador: intento mantenerlo por debajo de 200 líneas.

Alcances comunes de `CLAUDE.md`

En la práctica, CLAUDE.md puede existir en distintos niveles, y esos niveles determinan su alcance.

1. Nivel de usuario

Es el nivel global.

Vive en tu entorno de máquina y aplica a todos los proyectos locales.

Es buen lugar para:

información de identidad
preferencias generales de comunicación
hábitos que aplican a todos los proyectos
reglas globales de seguridad

2. Nivel de proyecto

Es el nivel del proyecto.

Está dentro de un directorio de proyecto concreto y solo aplica a ese proyecto.

Es buen lugar para:

contexto específico del proyecto
reglas que solo tienen sentido ahí
explicación de la estructura de directorios
entradas a documentos clave del proyecto

Cómo decidir qué nivel usar

La regla es simple:

Si lo escrito seguiría siendo verdad en otro proyecto, ponlo en el user level.

Si deja de ser verdad al cambiar de proyecto, ponlo en el project level.

Cómo escribir la primera versión

Hay dos formas comunes de empezar:

1. Usar `/init`

Puedes ejecutar /init directamente en la terminal y dejar que Claude escanee el proyecto para generar un CLAUDE.md básico.

2. Dejar que Claude te ayude a organizarlo

También puedes pedirle que busque cómo otras personas estructuran CLAUDE.md, que te haga preguntas según tu situación y organice una versión que encaje contigo.

Un hábito práctico

Al colaborar con Claude, cuando notes algo que debe recordarse o que no debe fallar otra vez, puedes pedirle que lo escriba en CLAUDE.md.

Antes de hacerlo, decide:

¿es una regla global?
¿o solo del proyecto actual?

No lo metas todo en un único archivo.

Capa 2: `Rules`

La siguiente capa es Rules.

La diferencia principal con CLAUDE.md no es el formato, sino cómo se carga.

CLAUDE.md se lee sin importar qué haces.

La ventaja de Rules es que pueden cargarse condicionalmente.

Una regla puede cargarse solo para ciertas rutas, archivos, herramientas o escenarios.

Por qué importa la carga condicional

Porque el espacio de contexto siempre es escaso.

Si todas las reglas entran al contexto todo el tiempo:

el modelo carga más overhead
las reglas realmente importantes se entierran

El valor de cargar reglas bajo demanda es que el modelo ve la información correcta en el momento correcto.

Cuándo mover reglas desde `CLAUDE.md` a `Rules`

Suelen darse dos situaciones:

1. `CLAUDE.md` se volvió demasiado largo

Si empieza a pasar de 200 líneas, sigue creciendo y lo importante se diluye, toca separar reglas.

2. Algunas reglas solo aplican a rutas concretas

Si sabes que ciertas reglas solo tienen sentido para ciertos archivos, por ejemplo:

reglas solo para scripts Python
reglas solo para un directorio de hooks
reglas solo para un subproyecto

entonces pertenecen más naturalmente a Rules.

Dónde encajan mejor `Rules`

El caso típico es “situación específica, ruta específica, tipo de archivo específico”.

Por ejemplo:

convenciones al manejar hooks
reglas de código para cierto tipo de scripts
formas de trabajo que solo aplican bajo un directorio

Mantener ese contenido en CLAUDE.md suele no ser rentable.

Capa 3: `Memory`

La tercera capa es Memory.

Como CLAUDE.md y Rules, también entra al contexto del modelo, pero su diferencia central es:

CLAUDE.md es algo que defines deliberadamente.

Memory se parece más a notas que Claude escribe para sí mismo durante la colaboración.

Qué entra en `Memory`

Cuando Claude juzga que algo vale la pena recordar o conservar por un tiempo, escribe esa información en Memory.

Ejemplos comunes:

una forma de trabajar que corregiste
una preferencia nueva
estado temporal del proyecto actual
algo que no terminaste hoy y debes continuar mañana
con quién colaboraste recientemente
contexto personal aparecido hace poco

Es conocimiento dinámico más que política de largo plazo.

Diferencia con las dos primeras capas

Una distinción simple:

CLAUDE.md / Rules: reglas explícitas, de largo plazo y tipo política
Memory: contexto temporal, dinámico y recién aprendido

Si algo solo importa unos días o cambia con frecuencia, suele pertenecer a Memory, no a una regla permanente.

`Memory` también puede escribirse manualmente

Aunque Memory puede mantenerse automáticamente, también puedes decirle explícitamente:

recuerda lo que debo hacer mañana
recuerda a quién debo hacer seguimiento
recuerda el hito clave de este proyecto este mes

También puedes usar /memory para ver, editar o borrar memorias.

Capa 4: `Hooks`

La última y más avanzada capa es Hooks.

Todo lo anterior, incluido CLAUDE.md, Rules y Memory, sigue siendo guía en lenguaje natural.

Escribes reglas y el modelo normalmente las sigue, pero primero debe interpretarlas.

Mientras la regla viva en lenguaje natural, quedan problemas:

el modelo puede pasarla por alto
demasiadas reglas diluyen atención
puede decidir que no es suficientemente importante

Qué son realmente `Hooks`

Hooks ya no son instrucciones en lenguaje natural. Son scripts.

Son lógica de enforcement a nivel programa, disparada por eventos.

Cuando ocurre cierto evento, esa lógica corre. No se salta porque el modelo la ignore.

Ese es su valor:

convierten “debería seguir esto” en “debe ejecutarse esto”.

Cuándo subir algo a `Hooks`

Si una regla ya está escrita en CLAUDE.md o Rules, pero Claude todavía falla ocasionalmente, y el coste de fallar es real, probablemente debería ser un Hook.

En simple:

comportamiento de bajo riesgo: reglas
comportamiento de alto riesgo: Hooks

Escenarios típicos

Ejemplos obvios:

exigir confirmación antes de enviar un email
exigir confirmación antes de enviar mensajes Slack, Outlook o Gmail
interceptar borrados peligrosos de archivos
bloquear fugas de contraseñas o API keys

Si solo están escritas como reglas, el modelo puede equivocarse algún día. Si son Hooks, el evento se intercepta cada vez.

Puntos de disparo comunes

Hooks pueden engancharse en distintas etapas:

inyectar recordatorios al inicio de una conversación
revisar condiciones antes de ejecutar una herramienta
validar resultados después de ejecutar una herramienta

No necesitas conocer toda la terminología formal. A menudo basta con describir claramente el requisito y preguntar a Claude si debería convertirse en hook.

También puedes usar /hook para inspeccionar hooks configurados.

Una forma práctica de empezar

Recomiendo este orden:

Paso 1: usa `/init` para generar un `CLAUDE.md` básico

No intentes escribir un enorme documento completo desde el inicio.

Deja que Claude escanee el proyecto y genere un punto de partida, luego itera.

Paso 2: añade cosas mientras trabajas

Cuando notes:

esto debe recordarse
este error no debe repetirse
esta preferencia aplicará siempre

pide a Claude que lo añada a CLAUDE.md.

Paso 3: mueve cosas a `Rules` cuando `CLAUDE.md` crezca

Cuando CLAUDE.md se alarga y el modelo no sigue todo con fiabilidad:

¿qué reglas son globales?
¿cuáles solo aplican a ciertas rutas?

Mueve las segundas a Rules para carga condicional.

Paso 4: convierte reglas de alto riesgo en `Hooks`

Si una regla sigue fallando y el coste de fallar es alto, no te quedes en lenguaje natural. Conviértela en Hooks.

Ahí el “recordatorio” se vuelve “enforcement”.

Paso 5: deja que `Memory` maneje estado temporal

Para cosas que expiran, cambian a menudo o no son política permanente, no lo metas todo en CLAUDE.md.

Es más limpio dejar que Memory guarde:

progreso actual del proyecto
colaboradores recientes
preferencias recién añadidas
planes y to-dos de corto plazo

Qué debería guardar cada capa

Modelo mental rápido:

CLAUDE.md: entendimiento compartido de largo plazo, instrucciones globales, contexto base del proyecto
Rules: reglas especializadas cargadas por ruta o escenario
Memory: conocimiento dinámico, estado temporal, cosas aprendidas recientemente
Hooks: enforcement programático para acciones de alto riesgo

Cierre

Mucha gente trata Claude Code como “una interfaz de chat que escribe código”. Pero al usarlo a fondo, se siente más como una estación de trabajo inteligente de largo plazo.

La clave no es solo cómo formulas cada instrucción. Es si le diste un entorno estable, claro y acumulativo.

Cuando construyes estas cuatro capas:

CLAUDE.md
Rules
Memory
Hooks

la calidad de colaboración suele mejorar mucho.

Porque ya no reexplicas desde cero quién eres, cómo trabajas y qué no debe pasar en cada sesión. Convertiste esas cosas en parte del entorno.

Ese es el paso clave para convertir un modelo fuerte en una herramienta madura.

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

Usar Claude en VS Code: de configurar API a generar páginas

Thu, 16 Apr 2026 17:47:17 +0800

Cuando empiezas a llevar modelos grandes al desarrollo diario, el mayor cambio no suele ser si pueden escribir código. Es si pueden empujar de una vez un conjunto de tareas pequeñas y dispersas.

El valor real de estas herramientas no es completar unas líneas. Es poder chatear, editar archivos, previsualizar resultados y seguir iterando sin salir del editor. Para páginas simples, prototipos rápidos, ajustes de estilo y pequeñas funciones, ese workflow suele sentirse mucho más fluido que cambiar manualmente de una herramienta a otra.

Este artículo resume un enfoque práctico: después de conectar un modelo tipo Claude a VS Code, cómo usarlo realmente para generación de páginas e iteración de pequeñas funciones.

1. Conecta primero la toolchain

El flujo central de un plugin de AI coding suele ser simple:

Instalar en VS Code un plugin que soporte edición conversacional de código
Rellenar el Base URL del servicio de modelo
Añadir tu API Key
Elegir el nombre de modelo

Una vez hecho, la parte AI del editor es realmente usable. Después, las diferencias de experiencia dependen más de calidad del modelo, interacción del plugin y estabilidad del output generado.

Si nunca configuraste un plugin así, piensa en esto:

el plugin convierte tu petición en lenguaje natural en acciones del editor
la API envía la solicitud a un servicio de modelo
el modelo interpreta tu intención y devuelve código, ediciones o resultados estructurados

El trabajo real de emparejar piezas está en tres cosas: plugin, endpoint y nombre de modelo.

2. Empieza con tareas pequeñas

Mucha gente quiere que la herramienta construya un proyecto completo al primer intento. Puede funcionar, pero para principiantes lo más rápido es empezar con algo mucho menor.

Por ejemplo:

Generar una página frontend simple
Añadir una sección de aviso a una página existente
Crear un formulario de registro
Hacer que la UI se vea más pulida y formal

Estas tareas ayudan porque:

el prompt es más claro
puedes previsualizar el resultado de inmediato
ves cómo conversación y ediciones de archivo trabajan juntas

Cuando la petición es suficientemente específica, el plugin puede conversar en una barra lateral mientras edita archivos. Luego inspeccionas el resultado, previsualizas la página y decides si pedir otro cambio.

3. La ganancia real es la iteración, no la generación de una pasada

Un malentendido común es centrarse demasiado en si el primer resultado impresiona.

En la práctica importa más si la segunda y tercera ronda siguen moviéndose en la dirección correcta.

Un patrón común:

Pedir un esqueleto funcional de página
Añadir una o dos funciones claras
Revisar si código y UI se vuelven más completos

Si la herramienta se siente fluida, empieza a parecerse a trabajar con un junior muy rápido:

describes la tarea
produce una primera pasada
señalas lo que falta
sigue refinando

Ese workflow iterativo y conversacional se acerca mucho más al desarrollo real y es donde estas herramientas crean mayor diferencia de productividad.

4. Saber qué dar a AI y qué corregir tú

Esta distinción importa mucho.

Layout de página, borradores de componentes, scaffolding de formularios, pulido de estilo, copy placeholder y boilerplate repetitivo suelen ser buenos candidatos para AI.

Pero si solo necesitas:

cambiar una etiqueta de botón
ajustar una frase de footer
tocar un detalle mínimo de estilo

a menudo es más rápido editarlo tú. El cambio es demasiado pequeño para justificar otra interacción completa con el modelo.

El enfoque eficiente no es darle todo a AI. Es saber cuándo dejarle manejar un bloque grande y cuándo terminar los últimos detalles a mano.

5. La configuración API es una barrera, pero no lo más difícil

Mucha gente no se atasca en programar. Se atasca en configurar.

Checks habituales:

¿El endpoint es correcto?
¿La key es válida?
¿El nombre de modelo coincide con el servicio?
¿El plugin espera un formato concreto de Base URL?

Si uno falla, el plugin puede abrir normalmente pero las solicitudes fallan por debajo.

Orden práctico de troubleshooting:

Revisar endpoint
Revisar key
Revisar nombre de modelo y requisitos de formato URL

Esos tres puntos resuelven la mayoría de problemas de setup.

6. Cómo juzgar si el output vale la pena

Un estándar práctico no es si el output parece espectacular, sino si aguanta pruebas básicas:

¿La página generada corre de inmediato?
¿La estructura es razonablemente clara?
¿Sigue el rumbo tras peticiones de seguimiento?
¿Mantiene consistencia al crecer el alcance de edición?

Si una o dos rondas bastan para mover una página desde blanco hasta algo refinable, la herramienta ya es útil.

Si cada resultado requiere rework grande, no está ahorrando tiempo. Solo convierte escribir código en revisar código.

Cierre

Lo más interesante de usar modelos tipo Claude en VS Code no es la fantasía de no escribir código nunca más. Es que muchas tareas dispersas, repetitivas y que rompen contexto pueden avanzar en una pasada.

Un workflow realista:

deja que AI construya el primer esqueleto de página y función
usa dos o tres rondas conversacionales para refinar
haz tú los pequeños cambios finales claros

Así, AI se vuelve un acelerador, no un reemplazo que deba tomar todo el desarrollo.