Developer Tools on KnightLi Blog

Bun: runtime, gestor de paquetes, pruebas y bundler de JavaScript en una sola herramienta

Sun, 17 May 2026 17:42:25 +0800

Bun es una toolchain open source todo en uno para JavaScript / TypeScript creada por oven-sh.

No quiere ser solo un reemplazo más rápido de Node.js. Reúne runtime, gestor de paquetes, runner de scripts, test runner y bundler bajo el mismo comando bun. Para desarrolladores frontend y Node.js, su atractivo es claro: menos herramientas, menos espera en instalación y build, y muchas tareas comunes con un solo comando.

Proyecto: https://github.com/oven-sh/bun

Conclusión rápida

Bun encaja mejor con quienes quieren simplificar la toolchain JavaScript.

Puede:

Ejecutar JavaScript, TypeScript, JSX y TSX.
Funcionar como runtime compatible con Node.js.
Reemplazar npm / yarn / pnpm para gestionar paquetes.
Ejecutar scripts de package.json.
Ejecutar pruebas.
Empaquetar código frontend o backend.
Usar bunx para ejecutar comandos de paquetes npm.
Ofrecer API integradas como Bun.serve, bun:sqlite, Bun.sql, Bun.redis y Bun.s3.

Su valor más visible es la experiencia de desarrollo: instalaciones rápidas, arranque rápido, comandos unificados y TypeScript / JSX listos para usar.

Pero Bun no es algo que todos los proyectos deban adoptar de inmediato. Aplicaciones Node.js grandes, proyectos con muchas extensiones nativas y servicios de producción con requisitos altos de estabilidad necesitan validar compatibilidad, build, pruebas y despliegue.

Qué es Bun

Según el README oficial, Bun es un toolkit todo en uno para aplicaciones JavaScript y TypeScript. Se distribuye como un único ejecutable llamado bun.

Su núcleo es Bun runtime: un runtime JavaScript rápido que busca actuar como drop-in replacement de Node.js. Bun está escrito en Zig, se basa en JavaScriptCore y optimiza arranque y uso de memoria.

Puedes ejecutar directamente:

`1`	`bun run index.tsx`

TypeScript y JSX funcionan sin configuración adicional.

El mismo comando bun incluye test runner, script runner, gestor de paquetes compatible con Node.js, bundler y package runner.

Comandos frecuentes:

bun test
bun run start
bun install <pkg>
bunx cowsay 'Hello, world!'

Un proyecto típico puede acabar con node, npm, pnpm, tsx, jest, vitest, webpack, esbuild y ts-node. Bun intenta absorber muchas rutas frecuentes en una sola herramienta.

Instalación

Bun soporta Linux, macOS y Windows en x64 y arm64.

Script oficial:

`1`	`curl -fsSL https://bun.com/install \| bash`

Windows:

`1`	`powershell -c "irm bun.sh/install.ps1 \| iex"`

También se puede instalar con npm:

`1`	`npm install -g bun`

macOS Homebrew:

1
2

brew tap oven-sh/bun
brew install bun

Docker:

1
2

docker pull oven/bun
docker run --rm --init --ulimit memlock=-1:-1 oven/bun

En Linux hay que mirar la versión del kernel. El README recomienda Linux kernel 5.6 o superior, con 5.1 como mínimo.

Actualizar:

`1`	`bun upgrade`

Actualizar a canary:

`1`	`bun upgrade --canary`

Canary no suele ser buena opción para producción salvo que estés validando una función nueva o investigando un bug concreto.

Por qué Bun es rápido

La velocidad de Bun viene de varias capas.

Primero, el arranque del runtime es rápido. Muchas herramientas CLI y scripts de desarrollo no están limitados por CPU sostenida, sino por arranque de proceso, carga de módulos, transpilación TypeScript y resolución de dependencias. Bun optimiza esas rutas.

Segundo, la gestión de paquetes es rápida. bun install busca reemplazar los flujos de instalación de npm / yarn / pnpm. Usa caché global y su propio lockfile, lo que puede reducir mucho la espera con muchas dependencias.

Tercero, TypeScript / JSX funcionan sin configuración. Muchos proyectos solo quieren ejecutar un .ts o .tsx; con Node.js tradicional se añaden tsx, ts-node, Babel o un build. Bun puede ejecutarlos directamente.

Cuarto, las herramientas integradas reducen cambios de proceso y configuración. Pruebas, scripts, bundling y ejecución viven en la misma herramienta.

Aun así, “Bun es rápido” no significa que todo proyecto vaya a ser más rápido. Depende de dependencias, lógica de scripts, framework de pruebas, build, uso de API Node.js y caché de CI.

Gestión de paquetes: reemplazar npm / yarn / pnpm

Bun instala dependencias directamente:

`1`	`bun install`

Añadir dependencia:

`1`	`bun add react`

Añadir dependencia de desarrollo:

`1`	`bun add -d typescript`

Eliminar dependencia:

`1`	`bun remove react`

Ver por qué existe una dependencia:

`1`	`bun why react`

Auditoría de seguridad:

`1`	`bun audit`

Si migras desde npm o pnpm, revisa si bun.lock entra en control de versiones, si CI usa bun install --frozen-lockfile, si private registries y .npmrc son compatibles, si workspace se comporta como esperas, si lifecycle scripts introducen riesgo y si un monorepo dependiente de pnpm puede migrar sin fricción.

Los proyectos pequeños pueden probarlo directamente. En monorepos grandes, empieza por un package o un job de CI no bloqueante.

Ejecutar scripts y TypeScript

Bun ejecuta scripts de package.json:

`1`	`bun run start`

También ejecuta archivos directamente:

1
2

bun run index.ts
bun run index.tsx

Es útil para scripts como:

scripts/build.ts
scripts/seed.ts
scripts/migrate.ts
scripts/check.ts

Con Node.js, muchas veces hay que resolver loader TypeScript o precompilación. Bun reduce ese pegamento.

Si un script depende de detalles de Node.js, como loaders, frontera ESM/CJS, módulos nativos, child process, file watching o API de borde, sigue necesitando pruebas.

Test runner

Bun incluye test runner:

`1`	`bun test`

Encaja en proyectos pequeños que quieren menos configuración Jest / Vitest, y también para mover algunas pruebas unitarias, de herramientas o de librerías a un runner más ligero.

Al migrar pruebas, mira diferencias en expect, mock API, snapshots, entorno DOM, reglas de descubrimiento, cobertura y reportes de CI.

Si el proyecto depende profundamente de Jest, con matchers propios, mocks complejos, jsdom, babel-jest o ts-jest, no conviene migrar deprisa. Puedes usar bun test en módulos nuevos y conservar el framework anterior para lo existente.

Bundling y build

Bun ofrece bundler:

`1`	`bun build ./src/index.ts --outdir ./dist`

Puede usarse para bundles frontend, scripts backend, CLI y librerías. La documentación cubre loaders, plugins, macros, CSS, HTML, HMR, minifier y single-file executable.

Buenos candidatos iniciales:

Herramientas frontend pequeñas.
CLI Node.js.
Scripts internos.
Servicios de un solo archivo.
Proyectos sin loaders webpack complejos.

Ten cuidado con cadenas webpack complejas, muchos plugins Vite, transformaciones Babel profundas, pipelines CSS / assets especiales, micro-frontends, module federation y proyectos con requisitos finos de hash, chunks y compatibilidad.

El bundler de Bun es atractivo, pero migrar build suele ser más arriesgado que cambiar el gestor de paquetes. Valídalo por separado.

Ejecutar servicios HTTP

Bun ofrece Bun.serve:

Bun.serve({
  port: 3000,
  fetch(req) {
    return new Response("Hello from Bun")
  },
})

Es práctico para API pequeñas, servicios internos, webhook receivers y servicios con estilo edge. Bun también incluye WebSockets, Workers, Streams, SQLite, PostgreSQL, Redis, S3 y TCP/UDP sockets.

Si ya usas Express, Fastify, NestJS, Next.js, Hono, Elysia u otro framework, revisa primero su compatibilidad con Bun. No hace falta reescribir un servicio solo para usar Bun.

Una ruta realista es usar Bun primero para scripts y paquetes, después para pruebas, y al final evaluar si el runtime de producción debe cambiar. La migración del runtime exige más cuidado porque afecta directamente el comportamiento en producción.

Relación con Node.js

Uno de los objetivos de Bun es ser un drop-in replacement de Node.js, pero compatibilidad no significa equivalencia completa.

El ecosistema Node.js acumula muchos detalles: interoperabilidad CJS / ESM, módulos internos, extensiones nativas, lifecycle scripts de npm, comportamiento de filesystem, stream y Buffer, worker / child_process, debugging y profiling.

Bun mejora rápido, pero la migración a producción debe juzgarse por pruebas.

Preguntas prácticas:

¿Tus pruebas pasan con Bun?
¿Las dependencias clave soportan Bun?
¿Los artefactos de build son equivalentes?
¿CI y local se comportan igual?
¿Hay monitorización y rollback en producción?
¿Docker y despliegue son estables?

Cambiar solo el gestor de paquetes tiene menos riesgo. Cambiar el runtime de producción tiene mucho más.

Proyectos adecuados

Bun encaja bien con proyectos pequeños nuevos en JavaScript / TypeScript, herramientas internas, CLI, CI que necesita instalaciones rápidas, frontend que quiere reducir complejidad, scripts o servicios sensibles al arranque y desarrolladores que quieren TypeScript listo para ejecutar.

Conviene ir con más cautela en monorepos enormes, proyectos atados a pnpm workspace, servicios con muchas extensiones nativas Node.js, builds frontend muy personalizados, backends con exigencias fuertes de consistencia en runtime y suites de pruebas muy dependientes de Jest.

Una estrategia conservadora y útil es usar Bun primero como herramienta de desarrollo, no como sustituto inmediato de todos los runtimes de producción.

Consejos de migración

Para probar Bun en un proyecto existente:

Instala Bun localmente.
Ejecuta bun install y revisa el resultado.
Conserva o commitea bun.lock para evitar confusión con lockfiles.
Prueba bun run <script> con scripts comunes.
Migra pocas pruebas con bun test.
Añade un job Bun no bloqueante en CI.
Si no hay problemas, evalúa cambiar el flujo principal de instalación.
Evalúa la migración del runtime de producción al final.

En equipos, conserva una ruta de rollback. Mantén el flujo npm / pnpm / yarn durante la migración, ejecuta ambos en CI un tiempo, no cambies runtime, gestor, framework de pruebas y bundler en la misma modificación, y divide el proceso en pasos pequeños verificables.

Comandos frecuentes

Instalar:

`1`	`curl -fsSL https://bun.com/install \| bash`

Actualizar:

`1`	`bun upgrade`

Instalar dependencias:

`1`	`bun install`

Añadir dependencia:

`1`	`bun add lodash`

Ejecutar script:

`1`	`bun run dev`

Ejecutar TypeScript directamente:

`1`	`bun run scripts/build.ts`

Pruebas:

`1`	`bun test`

Bundle:

`1`	`bun build ./src/index.ts --outdir ./dist`

Ejecutar comando de paquete:

`1`	`bunx cowsay 'Hello, world!'`

Resumen

El valor de Bun no es solo ser “más rápido que Node.js”. Lo importante es que reúne muchas herramientas dispersas del desarrollo JavaScript / TypeScript en un solo comando bun: runtime, gestor de paquetes, runner de scripts, test runner y bundler.

Para proyectos nuevos y herramientas internas, la experiencia integrada puede ser cómoda: instalaciones rápidas, arranque rápido, menos configuración y TypeScript / JSX directos. En proyectos grandes ya existentes, es mejor introducir Bun primero en áreas de bajo riesgo, como instalación, scripts y algunas pruebas, antes de validar build y runtime.

Si la velocidad de instalación, los fragmentos de configuración y el arranque lento de pruebas de la toolchain Node.js te molestan a menudo, Bun merece una prueba seria. Pero la migración de producción vuelve a lo básico: pruebas, compatibilidad, CI estable y rollback.

Referencias:

Guía de inicio en desarrollo de juegos con Godot: de nodos y escenas a tu primer juego 2D

Sun, 17 May 2026 12:37:30 +0800

Godot es un motor de juegos open source adecuado para juegos 2D, prototipos indie y proyectos 3D medianos.

Sus puntos fuertes son que es ligero, abierto, rápido de iniciar y usa un sistema claro de nodos y escenas. Para principiantes suele ser más accesible que Unity, y para desarrolladores independientes permite mantener proyectos pequeños y controlados.

Conclusión rápida

No intentes aprender todo el motor desde el primer día.

Una ruta mejor:

Empieza por 2D, no por 3D.
Entiende nodos y escenas antes de diseñar arquitecturas complejas.
Aprende primero GDScript.
Crea un juego pequeño que pueda empezar, fallar y reiniciarse.
Luego añade animación, audio, UI, niveles y exportación.

Completar un juego pequeño enseña más que ver muchos tutoriales sueltos.

Para quién sirve Godot

Godot encaja bien si quieres aprender desarrollo de juegos desde cero, crear juegos 2D indie, prototipar rápido, evitar toolchains pesadas o entender cómo se organizan los objetos dentro de un motor.

Unity y Unreal siguen siendo más fuertes para pipelines comerciales grandes, tiendas de assets, SDKs de monetización móvil o gráficos 3D de alto nivel. Pero para aprender y crear tus propios juegos, Godot es una gran entrada.

Instalación y proyecto

Descarga Godot desde la web oficial, descomprime y ejecuta.

Para el primer proyecto:

Usa el renderer por defecto.
Usa un nombre en inglés.
Evita rutas complicadas.
Usa Git desde el inicio.

Ejemplo:

`1`	`first-godot-game`

Familiarízate con Scene, FileSystem, Inspector, Script y las vistas 2D / 3D.

Nodos y escenas

Los conceptos centrales son nodos y escenas.

Nodos comunes:

Node2D: objeto base 2D.
Sprite2D: muestra una imagen.
CollisionShape2D: forma de colisión.
CharacterBody2D: personaje controlable.
Camera2D: cámara 2D.
AudioStreamPlayer: reproduce audio.
Label: muestra texto.

Una escena es un grupo reutilizable de nodos. Un jugador, un enemigo o un nivel pueden ser escenas.

Player (CharacterBody2D)
├── Sprite2D
├── CollisionShape2D
└── Camera2D

Primer proyecto recomendado

Haz un juego 2D de esquivar:

El jugador se mueve arriba, abajo, izquierda y derecha.
Los enemigos aparecen desde los bordes.
Tocar un enemigo significa perder.
El tiempo de supervivencia es la puntuación.
Hay pantalla inicial, game over y reinicio.

Esto cubre movimiento, input, colisiones, spawning, UI, timers, audio y recarga de escena.

Movimiento del jugador

Usa CharacterBody2D:

extends CharacterBody2D

@export var speed := 300.0

func _physics_process(delta):
    var direction := Vector2.ZERO

    direction.x = Input.get_axis("move_left", "move_right")
    direction.y = Input.get_axis("move_up", "move_down")
    direction = direction.normalized()

    velocity = direction * speed
    move_and_slide()

Define acciones de entrada:

move_left  -> A / Left
move_right -> D / Right
move_up    -> W / Up
move_down  -> S / Down

Usa actions en vez de teclas codificadas. Así será más fácil soportar mando, táctil o remapeo.

Colisiones y física

Nodos comunes:

CollisionShape2D: define colisión.
Area2D: detecta solapamientos.
CharacterBody2D: jugador o personaje controlado.
RigidBody2D: objeto físico.
StaticBody2D: paredes o suelo.

Para empezar: usa CharacterBody2D si controlas el movimiento, y Area2D si solo necesitas detectar contacto.

1
2
3

func _on_body_entered(body):
    if body.name == "Player":
        get_tree().reload_current_scene()

Instanciar enemigos

Las escenas funcionan como prefabs:

@export var enemy_scene: PackedScene

func spawn_enemy():
    var enemy = enemy_scene.instantiate()
    enemy.position = Vector2(800, randf_range(50, 550))
    add_child(enemy)

Con un Timer, puedes crear enemigos cada cierto tiempo.

UI, puntuación y audio

La UI usa nodos Control: CanvasLayer, Label, Button, Panel.

Puntuación simple:

var score := 0.0

func _process(delta):
    score += delta
    $CanvasLayer/ScoreLabel.text = str(int(score))

Audio:

`1`	`$HitSound.play()`

Un juego necesita feedback: sonidos, parpadeos, estados de botón, vibración o shake. La función por sí sola no basta.

Organización del proyecto

Desde el inicio:

res://
├── scenes/
├── scripts/
├── assets/
└── ui/

Escenas en scenes/, scripts en scripts/, imágenes y audio en assets/, UI en ui/.

Errores comunes

Elegir mal el tipo de nodo.
Olvidar CollisionShape2D.
Codificar teclas directamente.
Meter jugador, enemigos, UI y nivel en un solo script.
Empezar con un proyecto demasiado grande.

Un juego pequeño terminado vale más que una gran idea abandonada.

Ruta de aprendizaje

Editor.
Nodos y escenas.
GDScript.
Input actions.
Movimiento 2D.
Colisiones y Area2D.
Timer y spawning.
UI y puntuación.
Audio y animación.
Exportación a desktop o web.

Resumen

La entrada a Godot no consiste en memorizar todas sus funciones, sino en entender cómo organiza juegos: nodos forman escenas, escenas forman juegos, scripts dan comportamiento y signals conectan eventos.

Empieza con un juego 2D pequeño. Cuando ya tengas movimiento, colisión, UI, audio y reinicio, avanza a TileMap, guardado, máquinas de estado, 3D, shaders y optimización de exportación.

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

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.

Lectura rápida de la documentación de Ghostty: instalación, configuración y uso diario

Fri, 15 May 2026 14:50:11 +0800

Ghostty es un nuevo emulador de terminal, pero no es simplemente “otra terminal más rápida”. Según su documentación oficial, intenta equilibrar tres direcciones al mismo tiempo: velocidad, funciones y una experiencia de escritorio nativa. Es decir, busca aceleración por GPU y buen rendimiento de renderizado, pero también quiere sentirse como una aplicación local real en macOS y Linux, no como una interfaz completamente dibujada a mano.

Si hoy usas iTerm2, Kitty, Alacritty, WezTerm o la terminal del sistema, lo más interesante de Ghostty no es una función aislada. Es la combinación entre “funciona desde el primer arranque” y “se puede configurar en profundidad”. La configuración predeterminada ya es usable; cuando quieres ajustar más, la documentación ofrece entradas completas para archivos de configuración, temas, atajos, fuentes, integración con Shell y secuencias de control de terminal.

Primero, el posicionamiento

El posicionamiento central de Ghostty se puede resumir en tres puntos:

Es un emulador de terminal multiplataforma, con foco actual en macOS y Linux.
Usa UI nativa de cada plataforma: Swift, AppKit y SwiftUI en macOS; Zig y GTK4 en Linux.
Su núcleo de terminal es libghostty, y las aplicaciones GUI se construyen alrededor de este núcleo compartido.

Este diseño afecta la experiencia diaria. Pestañas, divisiones, mensajes de error, restauración del estado de ventanas y atajos del sistema no son simples componentes que “parecen una aplicación de escritorio”; intentan acercarse a los hábitos de interacción de cada sistema. Los atajos predeterminados de macOS y Linux también se diferencian según las convenciones de cada plataforma.

Instalación: directa en macOS, dependiente de la distribución en Linux

Los binarios precompilados oficiales apuntan principalmente a macOS. La forma más común de instalarlo es descargar el .dmg, abrirlo y arrastrar Ghostty al directorio Applications. Los usuarios de Homebrew también pueden usar el cask mantenido por la comunidad:

`1`	`brew install --cask ghostty`

En Linux la situación está más fragmentada. La documentación de Ghostty separa administradores de paquetes, binarios comunitarios y compilación desde código fuente para distintas distribuciones. Arch, Alpine, Gentoo, NixOS, Snap, Solus, Void y otras tienen rutas propias. Si una distribución no tiene un repositorio oficial o confiable, la documentación tiende a recomendar compilar desde el código fuente antes que instalar binarios de terceros sin revisar.

Esto es especialmente importante en servidores y estaciones de trabajo: un emulador de terminal maneja mucha entrada y salida, portapapeles, enlaces, sesiones SSH y rutas de archivos locales. Conviene ser conservador con la fuente de instalación y priorizar el paquete oficial de macOS, los repositorios de la distribución o un proceso de compilación cuyo origen puedas auditar.

Configuración: no copies una configuración gigante de dotfiles al principio

La filosofía de configuración de Ghostty es “usable con cero configuración”. La fuente predeterminada incluye JetBrains Mono y soporte de Nerd Font, así que la mayoría de usuarios puede trabajar normalmente al abrirlo por primera vez. La documentación incluso sugiere que, si necesitas cambiar una opción no subjetiva para sentirte cómodo, quizá esa conducta debería ser la predeterminada.

Cuando realmente necesitas personalizar, Ghostty usa un archivo de configuración de texto. El nombre actual es config.ghostty, aunque versiones antiguas también soportan config. Las rutas comunes incluyen:

$XDG_CONFIG_HOME/ghostty/config.ghostty
$XDG_CONFIG_HOME/ghostty/config
$HOME/.config/ghostty/config.ghostty
$HOME/.config/ghostty/config

En macOS también lee:

1
2

$HOME/Library/Application Support/com.mitchellh.ghostty/config.ghostty
$HOME/Library/Application Support/com.mitchellh.ghostty/config

La sintaxis es muy directa: key = value. Por ejemplo:

font-family = JetBrains Mono
font-size = 14
theme = light:Rose Pine Dawn,dark:Rose Pine
keybind = ctrl+shift+t=new_tab

Un consejo práctico: no empieces copiando la configuración completa de otra persona. Es más estable usarlo unos días sin cambios y modificar solo tres cosas al principio: fuente, tamaño de fuente y tema. Cuando de verdad notes fricción con atajos, divisiones, ventanas o integración con Shell, agrega esas opciones una por una.

Consulta de documentación: también hay referencia completa local

Ghostty tiene muchas opciones de configuración, y la documentación oficial las reúne en Option Reference. Además de la página web, después de instalarlo puedes consultar la referencia localmente:

`1`	`ghostty +show-config --default --docs`

Este comando imprime la configuración predeterminada y la documentación en la salida estándar, útil para enviarlo a un paginador:

`1`	`ghostty +show-config --default --docs \| less`

Para ver fuentes disponibles:

`1`	`ghostty +list-fonts`

Para ver temas incorporados y disponibles:

`1`	`ghostty +list-themes`

Para ver los atajos predeterminados:

`1`	`ghostty +list-keybinds --default`

Estos comandos son más confiables que copiar fragmentos de internet, porque vienen de la versión de Ghostty instalada en tu máquina.

Atajos: piensa en “acciones” como concepto central

El formato de configuración de atajos de Ghostty es:

`1`	`keybind = trigger=action`

trigger es la forma de activar una tecla o combinación, y action es la operación que ejecuta Ghostty. Crear una pestaña, cerrar la surface actual, recargar configuración o saltar a un prompt son acciones. El modelo es claro: no estás “cambiando una opción de menú”, sino vinculando una secuencia de entrada a una acción.

Después de cambiar la configuración, puedes recargarla en tiempo de ejecución. El atajo predeterminado es:

Linux: ctrl+shift+,
macOS: cmd+shift+,

No todas las opciones se aplican de inmediato. Algunas solo afectan terminales nuevas, y otras requieren reiniciar completamente. Si “la configuración está escrita pero no cambia nada”, revisa primero la explicación de esa opción; suele ahorrar más tiempo que sospechar de la sintaxis una y otra vez.

Temas y fuentes: usa primero lo incorporado y luego ajusta

Ghostty incluye muchos temas y soporta cambiar entre temas según el modo claro u oscuro del sistema:

`1`	`theme = light:Rose Pine Dawn,dark:Rose Pine`

Los temas también pueden venir de archivos personalizados. La documentación lo advierte con claridad: un archivo de tema es, en esencia, un archivo de configuración de Ghostty y puede definir muchas opciones, así que no conviene usar temas de fuentes no confiables.

En fuentes, font-family se puede repetir varias veces para especificar fuentes fallback. Es útil en entornos multilingües: la fuente principal puede cubrir inglés y símbolos, mientras las siguientes cubren chino, japonés u otros caracteres. Si aparecen detalles de visualización con emoji, negrita, cursiva o ligaduras, basta con revisar la opción correspondiente en Option Reference.

Integración con Shell: especialmente importante para usuarios de SSH

Ghostty soporta inyección automática de shell integration para bash, elvish, fish, nushell y zsh. Al activarla, varias experiencias se vuelven más naturales:

Las terminales nuevas pueden abrirse en el directorio de trabajo de la terminal anterior.
Los prompts complejos pueden redibujarse al cambiar tamaño en lugar de reacomodarse mal.
Puedes saltar entre salidas de comandos mediante marcadores de prompt.
El comportamiento del cursor en el prompt se ajusta mejor a hábitos de edición.

Si no quieres inyección automática, desactívala en la configuración:

`1`	`shell-integration = none`

SSH merece atención extra. Ghostty usa xterm-ghostty como TERM, pero muchos hosts remotos todavía no tienen el terminfo correspondiente. La documentación ofrece dos funciones de shell integration, ssh-env y ssh-terminfo, desactivadas por defecto y activables según necesidad:

`1`	`shell-integration-features = ssh-env,ssh-terminfo`

Si te conectas a menudo a servidores antiguos, contenedores, bastiones o entornos de producción con gestión estricta, conviene leer primero la documentación oficial de Terminfo y Shell Integration antes de activar estas funciones. La negociación de capacidades de terminal parece menor, pero cuando falla puede producir colores anómalos, atajos rotos o programas de pantalla completa desordenados.

Mi orden de prueba

Si solo quieres decidir si Ghostty encaja contigo, puedes probarlo en este orden:

Instálalo y úsalo un día sin escribir configuración.
Ajusta solo font-family, font-size y theme.
Usa ghostty +list-keybinds --default para ver los atajos predeterminados, en lugar de importar primero la tabla de otra persona.
Si usas SSH con frecuencia, revisa primero la compatibilidad de terminfo en hosts remotos.
Al final ajusta divisiones, ventanas, transparencia, barra de título, imagen de fondo y preferencias visuales o de flujo de trabajo.

La documentación de Ghostty está escrita con un enfoque bastante ingenieril. Conviene leerla como un manual de referencia de configuración, no como una página promocional. Para la mayoría de usuarios, el criterio real es simple: si la experiencia predeterminada ya resulta cómoda y tus flujos diarios con editor, Shell, SSH, tmux o Zellij son estables. Si esas piezas funcionan bien, Ghostty merece entrar en tu lista de terminales candidatas a largo plazo.

Referencias

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

¿Cómo conectar Codex con modelos chinos? APIs compatibles con OpenAI y el enfoque de CodexBridge

Wed, 13 May 2026 23:08:28 +0800

CodexBridge es una herramienta local de puente cuyo objetivo es claro: exponer Codex CLI/SDK como un servicio HTTP compatible con OpenAI. Así, Codex deja de estar limitado al terminal y puede ser llamado desde OpenWebUI, Cherry Studio, scripts, sistemas de automatización o cualquier cliente compatible con OpenAI Chat Completions.

Sus endpoints principales son /v1/chat/completions y /v1/models. El primero gestiona conversaciones y admite respuestas normales y transmisión SSE. El segundo permite a los clientes descubrir modelos como si leyeran una lista de modelos estilo OpenAI. Para herramientas que ya soportan OpenAI API, normalmente basta con cambiar el base URL, la API key y el nombre del modelo.

Proyecto: https://github.com/begonia599/CodexBridge

Cuándo usarlo

CodexBridge encaja cuando quieres integrar Codex en clientes o flujos de trabajo existentes. Por ejemplo:

Seleccionar Codex directamente en OpenWebUI o Cherry Studio.
Llamar a Codex local desde curl, Python, Node.js u otros scripts.
Conectar un mismo frontend a OpenAI, Ollama, otras APIs compatibles y Codex.
Conservar los hilos locales, sandbox, directorio de trabajo y aprobaciones de Codex.
Ofrecer a herramientas internas una entrada unificada /v1/chat/completions.

No es un nuevo LLM ni un reemplazo completo de Codex CLI. Es más bien una capa adaptadora: Codex sigue siendo el motor aguas arriba, y el puente convierte solicitudes estilo OpenAI en entradas de conversación que Codex entiende.

Requisitos básicos

Antes de ejecutarlo necesitas:

Node.js 18 o superior.
Codex CLI instalado y con sesión iniciada.
npm, o pnpm / yarn si lo prefieres.

Despliegue básico desde código fuente:

git clone https://github.com/begonia599/CodexBridge
cd codexbridge
npm install
cp .env.example .env
cp .env .env.local

Luego edita .env o .env.local para definir la API key, modelo predeterminado, directorio de trabajo, modo sandbox, acceso de red y otras opciones.

Inicia el servicio HTTP:

`1`	`npm run codex:server`

El puerto predeterminado es 8080, configurable con PORT. Tras iniciar, el servicio expone:

1
2
3

GET /health
POST /v1/chat/completions
GET /v1/models

Modo de conversación CLI

Además del servicio HTTP, CodexBridge conserva una CLI ligera:

`1`	`npm run codex:chat`

Desde la CLI puedes escribir mensajes en lenguaje natural para conversar con Codex. Dos comandos útiles son:

/reset: crear un nuevo hilo de Codex.
/exit: salir de la CLI.

El ID del hilo actual se guarda en .codex_thread.json. Si este archivo sigue existiendo al iniciar la CLI de nuevo, puedes continuar la conversación anterior.

Ejemplo HTTP

Una solicitud mínima:

curl http://localhost:8080/v1/chat/completions \
  -H "content-type: application/json" \
  -H "authorization: Bearer 123321" \
  -d '{"model":"gpt-5-codex:medium","session_id":"demo","messages":[{"role":"user","content":"ls"}]}'

Puntos importantes:

El token de authorization debe coincidir con CODEX_BRIDGE_API_KEY.
model puede incluir nivel de razonamiento, por ejemplo gpt-5-codex:medium o gpt-5-codex:high.
session_id vincula la solicitud a una conversación y permite reutilizar el mismo hilo de Codex.

Para salida en streaming, añade stream: true:

curl -N http://localhost:8080/v1/chat/completions \
  -H "content-type: application/json" \
  -H "authorization: Bearer 123321" \
  -d '{"model":"gpt-5-codex:high","session_id":"stream","stream":true,"messages":[{"role":"user","content":"Explica paso a paso cómo crear un proyecto Node.js"}]}'

Para clientes que soportan respuestas en streaming de OpenAI, esta forma se siente más cercana a una conversación normal.

Persistencia de sesiones

Una función importante de CodexBridge es el mapeo de sesiones. La solicitud puede pasar un ID de sesión mediante estos campos:

session_id
conversation_id
thread_id
user

También puede pasarse por cabeceras:

x-session-id
session-id
x-conversation-id
x-thread-id
x-user-id

En producción conviene activar:

`1`	`CODEX_REQUIRE_SESSION_ID=true`

Así todas las solicitudes deben incluir un ID de sesión, evitando que distintos usuarios o ventanas de chat se mezclen en el mismo contexto temporal. El mapeo del puente se guarda en .codex_threads.json. Borrar este archivo restablece la relación del puente; los hilos propios de Codex siguen en ~/.codex/sessions.

Si CODEX_REQUIRE_SESSION_ID=false y la solicitud no incluye ID de sesión, el puente expande los messages actuales como una entrada de un solo uso para Codex. Sirve para llamadas temporales, pero no para conversaciones largas.

Entrada multimodal

CodexBridge admite bloques de contenido estilo OpenAI y convierte imágenes en entradas local_image utilizables por Codex.

Imagen remota:

{
  "type": "image_url",
  "image_url": {
    "url": "https://example.com/demo.png"
  }
}

Imagen local:

{
  "type": "local_image",
  "path": "./images/demo.png"
}

Los recursos remotos se descargan primero en un directorio temporal y se limpian al final del turno. En uso real, presta atención al tamaño del cuerpo de la solicitud, especialmente cuando envías imágenes en base64. Puede que necesites aumentar CODEX_JSON_LIMIT.

Salida estructurada

Si el cliente soporta response_format, CodexBridge puede mapearlo al outputSchema de Codex. Es útil cuando quieres que Codex devuelva una estructura JSON fija, como resultados de revisión, resúmenes, clasificación o informes de automatización.

Ejemplo mínimo:

{
  "model": "gpt-5-codex",
  "session_id": "lint",
  "response_format": {
    "type": "json_schema",
    "json_schema": {
      "name": "lint_report",
      "schema": {
        "type": "object",
        "properties": {
          "summary": { "type": "string" },
          "status": {
            "type": "string",
            "enum": ["ok", "action_required"]
          }
        },
        "required": ["summary", "status"],
        "additionalProperties": false
      }
    }
  },
  "messages": [
    {
      "role": "user",
      "content": "Revisa los problemas de lint en src/ y devuelve el resultado como JSON"
    }
  ]
}

type: "json_schema" debe incluir schema; de lo contrario, el servicio devuelve 400.

Variables de entorno clave

La configuración común puede agruparse así.

Servicio y autenticación:

1
2
3

PORT=8080
CODEX_BRIDGE_API_KEY=123321
CODEX_JSON_LIMIT=10mb

Modelo predeterminado:

1
2

CODEX_MODEL=gpt-5-codex
CODEX_REASONING=medium

Entorno de ejecución de Codex:

CODEX_WORKDIR=
CODEX_SANDBOX_MODE=read-only
CODEX_APPROVAL_POLICY=never
CODEX_SKIP_GIT_CHECK=true

Acceso de red:

1
2

CODEX_NETWORK_ACCESS=false
CODEX_WEB_SEARCH=false

Si solo lo usas para chat desde un frontend, es más seguro mantener la red desactivada por defecto. Activa estas opciones solo cuando Codex necesite ejecutar curl, git clone o búsqueda web.

Docker y scripts de instalación

El proyecto también ofrece despliegue con Docker para mantener el servicio en ejecución:

1
2

docker compose up -d
docker compose logs -f codexbridge

También hay un script de instalación para Linux:

`1`	`curl -fsSL https://raw.githubusercontent.com/begonia599/CodexBridge/master/scripts/install.sh \| bash`

El script instala dependencias, clona o actualiza el repositorio, copia .env.example e inicia el servicio con Docker Compose. Requiere sudo, por lo que encaja mejor en un servidor limpio. Si la máquina ya tiene un entorno complejo de Node.js, Docker o Codex, revisa el script antes de ejecutarlo.

Problemas comunes

La solicitud devuelve 413

Normalmente el cuerpo es demasiado grande, a menudo por imágenes base64. Aumenta:

`1`	`CODEX_JSON_LIMIT=20mb`

La API key no es válida

Comprueba que la cabecera incluya:

`1`	`Authorization: Bearer <tu CODEX_BRIDGE_API_KEY>`

o usa x-api-key.

Codex informa una restricción de repositorio Git

Si el directorio de ejecución no es un repositorio confiable, Codex puede activar una verificación. Úsalo solo en entornos seguros:

`1`	`CODEX_SKIP_GIT_CHECK=true`

Restablecer conversaciones

El mapeo del puente está en .codex_threads.json, y los hilos propios de Codex están en ~/.codex/sessions. Detén el servicio y borra los archivos o directorios correspondientes para restablecerlos.

Recomendaciones

Para pruebas locales, empieza con la API key predeterminada y el sandbox read-only. Cuando OpenWebUI, Cherry Studio o tus scripts llamen al servicio correctamente, ajusta gradualmente CODEX_WORKDIR, CODEX_SANDBOX_MODE, CODEX_NETWORK_ACCESS y CODEX_APPROVAL_POLICY.

Si lo usarán varias personas, al menos:

Exige session_id.
Cambia la API key predeterminada.
Limita claramente el directorio de trabajo y los permisos del sandbox.

El valor de CodexBridge no está en tener muchas funciones, sino en colocar Codex dentro del ecosistema compatible con OpenAI. Si un cliente permite cambiar el base URL, puede tratar Codex como un modelo de chat normal y conservar al mismo tiempo sus hilos locales, sandbox y llamadas a herramientas.

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.

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

goose: un agente de IA open source con escritorio, CLI y API

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

goose es un agente de IA open source que corre en tu propia máquina. No se limita a completar código; busca cubrir código, investigación, escritura, automatización, análisis de datos y otros trabajos. El README lo presenta como aplicación de escritorio, CLI y API para usuarios normales y flujos personalizados.

El proyecto pasó de block/goose a la Agentic AI Foundation (AAIF), dentro de Linux Foundation. El repositorio actual es:

`1`	`https://github.com/aaif-goose/goose`

goose está escrito principalmente en Rust y TypeScript, con licencia Apache-2.0. Su descripción en GitHub dice que es un agente de IA extensible que va más allá de sugerencias de código: puede instalar, ejecutar, editar y probar con cualquier LLM.

Qué problema resuelve

Muchas herramientas de programación con IA se centran en sugerencias o cambios locales. goose apunta a algo más amplio: permitir que un agente de IA complete tareas directamente en tu máquina.

Puede servir para:

Cambios de código y pruebas.
Automatización local.
Investigación y escritura.
Análisis de datos.
Flujos multi-paso.
Integración mediante API.
Extensión mediante MCP.

Si solo necesitas autocompletado en el IDE, una herramienta tipo Copilot puede bastar. goose es más útil cuando quieres IA dentro de la cadena local de ejecución de tareas.

Escritorio, CLI y API

La aplicación de escritorio soporta macOS, Linux y Windows.

La CLI encaja con flujos de terminal y automatización local.

La API permite insertar goose como runtime de agente en otros sistemas o herramientas internas.

Para uso personal, empieza por escritorio o CLI. Para equipos, conviene revisar también la API y las distribuciones personalizadas.

Instalación

Aplicación de escritorio:

`1`	`https://goose-docs.ai/docs/getting-started/installation`

CLI:

`1`	`curl -fsSL https://github.com/aaif-goose/goose/releases/download/stable/download_cli.sh \| bash`

GitHub Releases ofrece builds para varias plataformas. La versión latest consultada fue v1.33.1, publicada el 2026-04-29, con assets para macOS, Linux, Windows, deb, rpm y Flatpak.

Después de instalar, configura un proveedor siguiendo el Quickstart oficial y prueba primero en un directorio de bajo riesgo.

Proveedores

goose admite más de 15 proveedores, entre ellos Anthropic, OpenAI, Google, Ollama, OpenRouter, Azure, Bedrock y otros proveedores cloud o compatibles con OpenAI.

Puede usar API keys y también suscripciones existentes de Claude, ChatGPT o Gemini mediante ACP.

ACP es relevante porque muchos usuarios ya tienen suscripciones, pero no todas las herramientas las reutilizan bien. goose las integra en un flujo de agente. Aun así, verifica siempre términos del proveedor, cuotas y políticas para código corporativo o datos sensibles.

Extensiones MCP

goose soporta extensiones Model Context Protocol. El README menciona más de 70 extensiones.

MCP permite conectar el agente con documentación, bases de datos, navegadores, sistemas internos, búsqueda, herramientas de diseño o gestión de proyectos mediante interfaces estándar.

Para equipos, MCP puede ser una capa de integración más segura que exponer todos los sistemas directamente al modelo.

Diferencia frente a un asistente de código

goose no es solo autocompletado. Es más bien un runtime local de agente.

Los asistentes comunes se enfocan en completar, explicar, generar funciones y editar en el IDE. goose se centra en ejecución local de tareas, flujos multi-paso, proveedores intercambiables, extensiones, escritorio y CLI, API embebible y tareas que no son solo código.

Eso también implica más complejidad: configuración de modelos, permisos, extensiones, workspace, logs y credenciales.

Distribuciones personalizadas

CUSTOM_DISTROS.md explica cómo construir una distribución de goose con proveedores, extensiones y branding preconfigurados.

Un equipo puede predefinir proveedores permitidos, conectar servidores MCP internos, configurar seguridad y logs, bloquear servicios externos y aplicar onboarding propio.

Recomendaciones

Instala la app de escritorio o CLI.
Configura un proveedor conocido.
Ejecuta tareas simples en un directorio de prueba.
Observa qué archivos lee y qué acciones ejecuta.
Añade extensiones MCP.
Prueba repositorios complejos después.

Haz commit antes de cambios importantes, no guardes API keys en archivos del proyecto, limita los modos de alto permiso a workspaces confiables y revisa la política de datos antes de usar código de empresa.

Resumen

goose es un agente de IA open source bajo AAIF/Linux Foundation. Ofrece escritorio, CLI y API, soporta más de 15 proveedores, acceso a suscripciones vía ACP y más de 70 extensiones MCP.

Su valor no es solo escribir código, sino unir modelos, herramientas, extensiones y ejecución local dentro de un mismo marco de agente.

Referencias

Cómo cambiar el idioma de la interfaz de VS Code: chino, inglés y otros idiomas

Fri, 08 May 2026 13:18:57 +0800

VS Code admite muchos idiomas de interfaz. Lo habitual es instalar primero el paquete de idioma correspondiente y luego elegir el idioma de visualización desde la paleta de comandos. Si necesitas fijar VS Code a un idioma concreto, también puedes modificar manualmente el valor locale en argv.json.

Este método no solo sirve para chino simplificado; también funciona con inglés, chino tradicional, japonés, coreano, francés, alemán, español y otros idiomas.

Instalar el paquete de idioma correspondiente

Si quieres cambiar a una interfaz que no sea inglés, normalmente debes instalar primero un paquete de idioma.

Abre el panel de extensiones de VS Code en la barra lateral izquierda, o usa el atajo Ctrl+Shift+X.
En el cuadro de búsqueda, escribe el idioma objetivo, por ejemplo Chinese, Japanese, Korean o French.
Selecciona el paquete de idioma correspondiente y haz clic en Install.
Cuando termine la instalación, reinicia VS Code si se te solicita.

Para chino simplificado, el paquete habitual es Chinese (Simplified). Para chino tradicional, usa Chinese (Traditional).

Cambiar el idioma desde la paleta de comandos

Este es el método recomendado para la mayoría de los usuarios.

Abre la paleta de comandos: Ctrl+Shift+P.
Escribe Configure Display Language.
Selecciona el comando Configure Display Language.
Elige en la lista el idioma que quieres usar.
Reinicia VS Code si se te solicita.

Después del reinicio, los menús, las páginas de configuración y los mensajes habituales usarán el idioma seleccionado. Si el idioma objetivo no aparece en la lista, instala antes su paquete desde el panel de extensiones.

Especificar el idioma manualmente en argv.json

Si el cambio desde la paleta de comandos no funciona, o si quieres fijar explícitamente el idioma de visualización, puedes editar directamente el archivo de argumentos de ejecución de VS Code.

Abre la paleta de comandos: Ctrl+Shift+P.
Escribe y selecciona Preferences: Configure Runtime Arguments.
Busca o agrega la opción locale.
Cambia su valor por el código del idioma objetivo.
Guarda el archivo y reinicia VS Code.

Por ejemplo, para cambiar a inglés:

1
2
3

{
  "locale": "en"
}

Para cambiar a chino simplificado:

1
2
3

{
  "locale": "zh-cn"
}

Para cambiar a japonés:

1
2
3

{
  "locale": "ja"
}

argv.json es un archivo JSON, así que presta atención a las comas y las comillas. Si la configuración no es válida, VS Code puede no leer correctamente el idioma configurado.

Códigos de idioma de interfaz comunes

Idioma de visualización	locale
English (US)	`en`
Chino simplificado	`zh-cn`
Chino tradicional	`zh-tw`
French	`fr`
German	`de`
Italian	`it`
Spanish	`es`
Japanese	`ja`
Korean	`ko`
Russian	`ru`
Portuguese (Brazil)	`pt-br`
Turkish	`tr`
Bulgarian	`bg`
Hungarian	`hu`

Qué hacer si el idioma no cambia

Revisa estos puntos en orden:

Confirma que el paquete del idioma objetivo está instalado.
Confirma que locale usa el código correcto. Por ejemplo, chino simplificado es zh-cn, no zh-CN.
Cierra VS Code por completo y vuelve a abrirlo después de cambiar el idioma.
Si editaste argv.json manualmente, comprueba que la sintaxis JSON sea válida.
Si la configuración está desordenada, elimina la entrada locale y vuelve a elegir el idioma mediante Configure Display Language.

En la mayoría de los casos, Configure Display Language es la opción más sencilla. Edita argv.json solo cuando necesites forzar un idioma concreto o cuando el cambio desde la paleta de comandos no surta efecto.

Referencias

VScode: cambiar el idioma de la interfaz de VS Code a chino simplificado y alternar el idioma de visualización

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

Guía de instalación de uv: cómo elegir entre macOS, Linux, Windows, pipx, Homebrew y WinGet

Thu, 07 May 2026 23:23:58 +0800

uv es un gestor de toolchain de Python creado por Astral. Sirve para gestionar versiones de Python, entornos virtuales, dependencias, scripts, proyectos y herramientas. Tiene muchas formas de instalación. La documentación oficial ofrece instaladores independientes y también admite PyPI, Homebrew, WinGet, Scoop, Docker, GitHub Releases y Cargo.

Si solo quieres instalarlo rápido, da prioridad al instalador independiente oficial. Si prefieres mantener la versión mediante el gestor de paquetes del sistema, usa Homebrew, WinGet o Scoop. Si ya acostumbras instalar herramientas de Python en entornos aislados, puedes usar pipx.

Elección rápida

Escenario	Método recomendado	Comando
Instalación rápida en macOS / Linux	Instalador independiente oficial	`curl -LsSf https://astral.sh/uv/install.sh \| sh`
macOS / Linux sin curl	Script oficial + wget	`wget -qO- https://astral.sh/uv/install.sh \| sh`
Instalación rápida en Windows	Instalador de PowerShell	`powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 \| iex"`
Instalación aislada de herramientas Python	pipx	`pipx install uv`
Instalación temporal o tradicional de Python	pip	`pip install uv`
Gestión de paquetes en macOS	Homebrew	`brew install uv`
Usuarios de MacPorts en macOS	MacPorts	`sudo port install uv`
Gestión de paquetes en Windows	WinGet	`winget install --id=astral-sh.uv -e`
Usuarios de Scoop en Windows	Scoop	`scoop install main/uv`
Usuarios de Rust	Cargo	`cargo install --locked uv`

Las opciones generales más recomendables son:

macOS / Linux: instalador independiente oficial;
Windows: instalador oficial de PowerShell o WinGet;
si ya gestionas herramientas CLI de Python con pipx: pipx install uv.

macOS y Linux: instalador oficial

El método oficial más directo consiste en descargar el script con curl y ejecutarlo con sh:

`1`	`curl -LsSf https://astral.sh/uv/install.sh \| sh`

Si el sistema no tiene curl, puedes usar wget:

`1`	`wget -qO- https://astral.sh/uv/install.sh \| sh`

Si quieres instalar una versión concreta, coloca el número de versión en la URL. Por ejemplo, el ejemplo oficial usa 0.11.11:

`1`	`curl -LsSf https://astral.sh/uv/0.11.11/install.sh \| sh`

Este método encaja con la mayoría de entornos personales de desarrollo. Es simple, multiplataforma y funciona mejor con el mecanismo oficial de actualización de uv.

El instalador coloca binarios como uv y uvx bajo el directorio del usuario, y puede modificar el shell profile para que los comandos puedan usarse directamente desde la terminal. Si no quieres que el instalador modifique PATH, revisa las opciones oficiales del installer, por ejemplo configurando UV_NO_MODIFY_PATH=1.

Windows: instalador de PowerShell

El método oficial en Windows es ejecutar el script de instalación con PowerShell:

`1`	`powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 \| iex"`

Para instalar una versión concreta, también puedes poner el número de versión en la URL:

`1`	`powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/0.11.11/install.ps1 \| iex"`

Aquí ExecutionPolicy ByPass permite obtener y ejecutar el script de instalación desde internet. Como hábito de seguridad, puedes revisar el contenido del script antes de ejecutarlo:

`1`	`powershell -c "irm https://astral.sh/uv/install.ps1 \| more"`

Si estás acostumbrado a gestores de paquetes de Windows, también puedes priorizar WinGet o Scoop.

Instalar con pipx

La documentación oficial indica que uv se publica en PyPI. Si lo instalas desde PyPI, se recomienda ponerlo en un entorno aislado, por ejemplo con pipx:

`1`	`pipx install uv`

Este método es adecuado si ya usas pipx como gestor de herramientas CLI de Python. Evita mezclar uv con el entorno del proyecto actual.

Si no tienes pipx, también puedes usar pip directamente:

`1`	`pip install uv`

Pero ten en cuenta que uv ofrece wheels precompilados en muchas plataformas. Si una plataforma no tiene un wheel compatible, se construirá desde código fuente, y en ese caso necesitarás una toolchain de Rust.

Mi recomendación: en una máquina personal, pipx install uv es más limpio que pip install uv; dentro de un entorno de proyecto, no recomiendo instalar uv como dependencia del proyecto.

Homebrew, MacPorts, WinGet y Scoop

Si prefieres gestores de paquetes del sistema, uv también admite canales comunes.

En macOS, usa Homebrew:

`1`	`brew install uv`

Los usuarios de MacPorts pueden usar:

`1`	`sudo port install uv`

En Windows, usa WinGet:

`1`	`winget install --id=astral-sh.uv -e`

Los usuarios de Scoop pueden usar:

`1`	`scoop install main/uv`

La ventaja de estos métodos es que delegan el mantenimiento en el gestor de paquetes del sistema. La desventaja es que el ritmo de actualización depende del origen de paquetes correspondiente, no del instalador oficial de uv.

Docker, GitHub Releases y Cargo

uv también ofrece imágenes Docker en GitHub Container Registry:

`1`	`ghcr.io/astral-sh/uv`

Esto sirve para CI, Dockerfiles, creación de imágenes y entornos temporales de ejecución. En uso real, conviene revisar también la documentación oficial de integración con Docker.

Si quieres descargar binarios manualmente, puedes hacerlo desde GitHub Releases. Cada página de release suele incluir binarios para las plataformas compatibles y explicar cómo llamar al instalador independiente usando una URL de GitHub.

Los usuarios de Rust también pueden instalar desde crates.io:

`1`	`cargo install --locked uv`

Pero este método compila desde código fuente y requiere una toolchain de Rust compatible. A menos que necesites instalarlo explícitamente desde el ecosistema Rust, los usuarios normales no tienen por qué elegir Cargo primero.

Actualizar uv

Si uv se instaló mediante el instalador independiente oficial, puedes usar el comando de autoactualización:

`1`	`uv self update`

La documentación oficial indica que actualizar uv vuelve a ejecutar el instalador y puede modificar el shell profile. Si no quieres que la actualización modifique PATH, configura:

`1`	`UV_NO_MODIFY_PATH=1`

Si lo instalaste de otra forma, debes actualizarlo con el gestor correspondiente. Por ejemplo, si lo instalaste con pip, usa:

`1`	`pip install --upgrade uv`

Homebrew, WinGet, Scoop y MacPorts también deben usar sus propios comandos de actualización.

Activar autocompletado de shell

uv admite autocompletado de shell. La documentación oficial recomienda comprobar primero cuál es tu shell actual:

`1`	`echo $SHELL`

Bash:

`1`	`echo 'eval "$(uv generate-shell-completion bash)"' >> ~/.bashrc`

Zsh:

`1`	`echo 'eval "$(uv generate-shell-completion zsh)"' >> ~/.zshrc`

fish:

`1`	`echo 'uv generate-shell-completion fish \| source' > ~/.config/fish/completions/uv.fish`

PowerShell:

if (!(Test-Path -Path $PROFILE)) {
  New-Item -ItemType File -Path $PROFILE -Force
}
Add-Content -Path $PROFILE -Value '(& uv generate-shell-completion powershell) | Out-String | Invoke-Expression'

Si también usas uvx con frecuencia, puedes activar el autocompletado de uvx por separado.

Bash:

`1`	`echo 'eval "$(uvx --generate-shell-completion bash)"' >> ~/.bashrc`

Zsh:

`1`	`echo 'eval "$(uvx --generate-shell-completion zsh)"' >> ~/.zshrc`

fish:

`1`	`echo 'uvx --generate-shell-completion fish \| source' > ~/.config/fish/completions/uvx.fish`

PowerShell:

if (!(Test-Path -Path $PROFILE)) {
  New-Item -ItemType File -Path $PROFILE -Force
}
Add-Content -Path $PROFILE -Value '(& uvx --generate-shell-completion powershell) | Out-String | Invoke-Expression'

Después de configurarlo, reinicia el shell o recarga el archivo de configuración correspondiente.

Desinstalar uv

Para desinstalar uv, primero puedes limpiar la caché y los datos gestionados por uv:

1
2
3

uv cache clean
rm -r "$(uv python dir)"
rm -r "$(uv tool dir)"

Después elimina los binarios.

macOS / Linux:

`1`	`rm ~/.local/bin/uv ~/.local/bin/uvx`

Windows:

1
2
3

rm $HOME\.local\bin\uv.exe
rm $HOME\.local\bin\uvx.exe
rm $HOME\.local\bin\uvw.exe

La documentación oficial también recuerda que antes de 0.5.0, uv se instalaba en ~/.cargo/bin. Si actualizaste desde una versión antigua, es posible que los binarios viejos sigan allí y debas eliminarlos manualmente.

Qué hacer después de instalar

Después de instalar, conviene confirmar primero la versión:

`1`	`uv --version`

Luego puedes empezar con algunas tareas comunes:

uv python install
uv venv
uv pip install requests
uvx ruff --version

Si es un proyecto nuevo, puedes seguir aprendiendo:

uv init: inicializar un proyecto;
uv add: añadir dependencias;
uv sync: sincronizar el entorno;
uv run: ejecutar comandos dentro del entorno del proyecto;
uvx: ejecutar temporalmente herramientas CLI de Python.

Mi recomendación

En una máquina personal de desarrollo, prioriza el instalador independiente oficial, porque es el método más alineado con la documentación oficial de uv y admite uv self update.

Si usas Windows y no quieres ejecutar un script remoto, puedes usar WinGet o Scoop. Si usas macOS y prefieres que todas tus herramientas las gestione Homebrew, puedes usar directamente brew install uv.

Quienes ya gestionan herramientas CLI de Python con pipx pueden usar pipx install uv. Pero no recomiendo ejecutar pip install uv dentro del entorno virtual de un proyecto concreto, porque eso mezcla la toolchain con las dependencias del proyecto.

Si se trata de CI o construcción de contenedores, revisa primero Docker y GitHub Releases, y fija la versión según el flujo de creación de la imagen.

Enlaces relacionados

Documentación de instalación de uv: https://docs.astral.sh/uv/getting-started/installation/
uv First steps: https://docs.astral.sh/uv/getting-started/first-steps/
Integración de uv con Docker: https://docs.astral.sh/uv/guides/integration/docker/
uv GitHub Releases: https://github.com/astral-sh/uv/releases

Warp Open Source: de terminal a entorno de desarrollo agentico

Thu, 07 May 2026 20:15:08 +0800

warpdotdev/warp es el repositorio open source del cliente de Warp. Warp se describe ahora como un “entorno de desarrollo agentico, nacido del terminal”: parte del terminal, pero lleva agentes de programacion con IA, indexacion de codebase, gestion de tareas y flujos de desarrollo a un solo entorno.

No es un repositorio open source ordinario de emulador de terminal. Se parece mas a una respuesta a una pregunta mayor: cuando agentes como Claude Code, Codex y Gemini CLI se vuelven comunes, deberia el propio terminal convertirse en un entorno de desarrollo para planificar, observar y gestionar agentes?

La respuesta de Warp es si.

Estado actual del repositorio

Al 7 de mayo de 2026, warpdotdev/warp es un repositorio publico. GitHub muestra alrededor de 56k stars y 4.1k forks. El README dice que el codigo del cliente Warp ahora es open source y da la bienvenida a contribuciones de la comunidad.

El lenguaje principal es Rust. El desglose de lenguajes de GitHub muestra Rust por encima del 98%, lo que encaja con el posicionamiento de Warp: no es un wrapper web, sino una herramienta de desarrollo nativa y multiplataforma.

Varios detalles del README importan:

Warp es un entorno de desarrollo agentico, nacido del terminal.
Puede usar su agente de programacion integrado y tambien conectar con agentes CLI externos como Claude Code, Codex y Gemini CLI.
OpenAI es el patrocinador fundador del repositorio Warp recien abierto.
Los flujos de gestion agentica del repositorio estan impulsados por modelos GPT.
Los crates del framework de UI de Warp usan licencia MIT, mientras que el resto del codigo usa AGPL v3.

Esto muestra que el movimiento open source de Warp no consiste solo en publicar un terminal. Esta operando el proyecto como un campo de pruebas para flujos de trabajo con agentes.

Warp es mas que un terminal

Los terminales tradicionales hacen principalmente tres cosas:

iniciar una shell;
ejecutar comandos;
mostrar salida.

La diferenciacion inicial de Warp era hacer que el terminal se sintiera mas moderno: bloques de comandos, autocompletado, historial, colaboracion, interacciones con estilo de UI y pulido multiplataforma. Ahora el foco se ha desplazado mas hacia organizar el desarrollo alrededor de agentes de IA.

Segun el README, Warp ya no enfatiza solo “un mejor terminal”. Enfatiza:

agentes de programacion integrados;
soporte para agentes CLI externos;
triage de issues;
escritura de especificaciones;
revision de PR;
coordinacion de contribuidores;
sesiones de agentes observables.

En otras palabras, Warp quiere convertir el terminal de “donde escribes comandos” en “donde trabajas con multiples agentes”.

Oz y gestion de proyectos open source

El README menciona Oz varias veces.

La vista de contribucion de Warp muestra miles de agentes Oz trabajando en triage de issues, especificaciones, implementacion y revision de PR. Esto es interesante porque extiende los agentes de IA desde “ayudar a una persona a escribir codigo” hasta “ayudar a gestionar colaboracion open source”.

La parte mas dificil de muchos proyectos open source no es escribir codigo, sino mantener:

demasiados issues y poca clasificacion;
bugs y feature requests mezclados;
nuevos contribuidores sin saber que tareas son abordables;
presion de revision de PR;
maintainers intentando seguir cada hilo de comunidad.

La idea de Warp es dejar que los agentes asuman primero parte del trabajo de gestion de proyecto y colaboracion. El README tambien menciona Oz for OSS, un programa orientado a maintainers para llevar flujos similares de gestion open source agentica a otros repositorios.

Esto sugiere que la ambicion de Warp no es solo el producto terminal, sino tambien un nuevo modelo de mantenimiento open source en la era de la IA.

Estructura del repositorio y stack tecnico

Por la estructura del repositorio, Warp es un proyecto Rust grande.

La raiz contiene:

app/: codigo principal de la aplicacion.
crates/: crates Rust centrales.
assets/: archivos de recursos.
command-signatures-v2/: contenido relacionado con firmas de comandos.
docker/, script/, resources/, specs/ y otros directorios de ingenieria.
.claude/, .warp/, .agents/skills y otras configuraciones relacionadas con agentes.

WARP.md aporta mas detalle de ingenieria. Describe Warp como un emulador de terminal basado en Rust que usa un framework de UI interno llamado WarpUI.

Los modulos principales pueden entenderse aproximadamente asi:

app/: emulacion de terminal, gestion de shell, integracion de IA, Drive, autenticacion, ajustes, workspace y sesiones.
crates/warp_core/: utilidades centrales y abstraccion de plataforma.
crates/editor/: funcionalidad de edicion de texto.
crates/warpui/ y crates/warpui_core/: framework de UI interno.
crates/ipc/: comunicacion entre procesos.
crates/graphql/: cliente GraphQL y esquema.

WARP.md tambien menciona rasgos arquitectonicos como:

un sistema Entity-Handle;
una estructura modular de workspace;
targets para macOS, Windows, Linux y WASM;
integracion de IA, incluyendo Agent Mode, conciencia de contexto e indexacion de codebase;
sincronizacion cloud Warp Drive.

Esta complejidad esta mas cerca de un IDE completo que de un terminal tradicional ligero.

Comandos de build local

El README da un flujo local conciso:

1
2
3

./script/bootstrap
./script/run
./script/presubmit

Donde:

./script/bootstrap realiza la inicializacion especifica de la plataforma.
./script/run compila y ejecuta Warp.
./script/presubmit ejecuta formato, clippy, tests y otras comprobaciones previas al envio.

WARP.md tambien lista comandos mas detallados:

cargo run
cargo bundle --bin warp
cargo nextest run --no-fail-fast --workspace --exclude command-signatures-v2
cargo fmt
cargo clippy --workspace --all-targets --all-features --tests -- -D warnings

Si quieres contribuir a Warp, ./script/presubmit es practicamente obligatorio.

Flujo de contribucion

El flujo de contribucion de Warp no es simplemente “abre un PR”.

El README describe un proceso ligero desde issue hasta PR:

Buscar primero issues existentes.
Si no hay duplicado, abrir un bug o feature request.
Los maintainers revisan el issue y pueden anadir etiquetas de preparacion.
ready-to-spec significa que el diseno puede expandirse en una especificacion.
ready-to-implement significa que el diseno esta lo bastante claro para empezar un PR de implementacion.
Los contribuidores pueden tomar issues etiquetados.

Este proceso encaja con un proyecto open source grande. Separa ideas, diseno e implementacion, reduciendo el riesgo de que los contribuidores pasen tiempo construyendo en una direccion equivocada.

Tambien encaja bien con agentes de IA. Un agente puede organizar issues, redactar specs, anadir tests y luego pasar a implementacion. Warp usa este patron para demostrar gestion de proyecto agentica.

Licencia: MIT + AGPL v3

Warp usa una estructura de doble licencia.

El README dice:

el framework de UI de Warp, concretamente los crates warpui_core y warpui, usa licencia MIT;
el resto del repositorio usa AGPL v3.

Esto importa. AGPL v3 tiene requisitos open source mas fuertes para servicios de red y distribucion. Si estas aprendiendo, investigando o contribuyendo, normalmente es sencillo. Pero si quieres usar codigo de Warp en un producto comercial o en un derivado closed-source, debes leer la licencia con cuidado y consultar asesoria legal si hace falta.

En resumen, Warp es open source, pero no es open source de “tomalo y cierralo libremente”.

Por que merece atencion

Primero, Warp une terminal, agentes y gestion de proyecto.

Muchas herramientas de programacion con IA siguen siendo CLI o plugins de editor. Warp parte del punto de entrada del terminal e intenta unificar tareas de agentes, ejecucion de codigo, salida de comandos, flujos de PR y colaboracion de equipo.

Segundo, el enfoque open source de Warp es un buen lugar para observar flujos con agentes.

No solo publica codigo. Tambien expone vistas de contribucion, sesiones de agentes, triage de issues y flujos de especificacion. Para cualquiera que estudie como la IA puede participar en colaboracion open source, el propio repositorio es una muestra.

Tercero, Warp es una aplicacion de escritorio Rust compleja.

Si quieres estudiar GUI en Rust, emulacion de terminal, apps multiplataforma, clientes GraphQL, sincronizacion cloud e integracion de IA, el repositorio tiene mucho que leer. Pero no es un proyecto pequeno, asi que los nuevos contribuidores deberian leer primero la documentacion y el proceso de issues.

Cuarto, Warp soporta tanto un agente integrado como un enfoque “trae tu propio agente CLI”.

Esto es realista. Los desarrolladores no usaran un solo agente. Claude Code, Codex, Gemini CLI, OpenCode, OpenClaw y herramientas similares probablemente coexistiran. Si Warp puede convertirse en un banco de trabajo para ellos, se vuelve mas valioso que un terminal de proposito unico.

A quien deberia importarle

Si eres un usuario normal de terminal, Warp importa porque el terminal puede estar cambiando de herramienta de linea de comandos a banco de trabajo con IA.

Si eres usuario intensivo de agentes de programacion con IA, Warp merece seguimiento porque intenta gestionar multiples agentes en vez de actuar como otro punto de entrada de chat.

Si mantienes proyectos open source, la direccion de Oz for OSS merece atencion. Explora triage de issues con agentes, revision de PR, colaboracion comunitaria e incorporacion de contribuidores.

Si eres desarrollador Rust, Warp es una aplicacion de escritorio real y de gran escala que merece estudiarse por organizacion de UI, internals de terminal, sincronizacion cloud, integracion de IA y codigo multiplataforma.

Si solo quieres un terminal que pueda reemplazar al actual de inmediato, es mejor descargar primero la version estable y despues decidir si estudiar el codigo fuente. Compilar desde codigo es mas adecuado para contribuidores y usuarios profundos.

Lectura breve

El punto de que Warp se vuelva open source no es simplemente “un terminal moderno se hizo open source”.

Mas precisamente, Warp intenta actualizar el terminal hasta convertirlo en un entorno de desarrollo agentico: el terminal conecta shell, codebase, ejecucion de comandos, agentes, issues, PRs y flujo de colaboracion.

A medida que los agentes de programacion con IA sigan creciendo, el punto de entrada del entorno de desarrollo puede cambiar. Antes, el IDE dominaba la experiencia del desarrollador mientras el terminal ejecutaba comandos. Ahora el terminal puede convertirse en el centro de colaboracion con agentes. El repositorio de Warp explora esa posibilidad.

Enlaces relacionados

GitHub repository: https://github.com/warpdotdev/warp
Warp website: https://www.warp.dev
Warp documentation: https://docs.warp.dev
Warp build overview: https://build.warp.dev
WARP.md: https://github.com/warpdotdev/warp/blob/master/WARP.md
CONTRIBUTING.md: https://github.com/warpdotdev/warp/blob/master/CONTRIBUTING.md

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.

Cómo usar DeepSeek V4 Pro en Cline

Fri, 01 May 2026 20:59:06 +0800

Cline ya admite el proveedor OpenAI Compatible. La API de DeepSeek también es compatible con llamadas al estilo del SDK de OpenAI, así que conectar deepseek-v4-pro a Cline no es complicado: elige OpenAI Compatible y completa la Base URL de DeepSeek, la API Key y el nombre del modelo.

Los pasos siguientes cubren tanto la interfaz de la extensión para VS Code como Cline CLI.

Preparar una API Key de DeepSeek

Primero, crea una API Key en la plataforma de DeepSeek.

Necesitas tres valores:

Elemento	Valor
Provider	`OpenAI Compatible`
Base URL	`https://api.deepseek.com`
Model ID	`deepseek-v4-pro`

La documentación oficial de DeepSeek indica que la serie V4 usa la interfaz existente compatible con OpenAI. Mantén base_url como https://api.deepseek.com y establece model en deepseek-v4-pro o deepseek-v4-flash al llamarlo.

Configurarlo en la extensión de Cline

Si usas la extensión de Cline en VS Code, configúrala así:

Abre Cline desde la barra lateral de VS Code.
Entra en la configuración de Cline o en la configuración de modelos.
Selecciona OpenAI Compatible como proveedor.
Introduce tu API Key de DeepSeek.
Configura Base URL como:

`1`	`https://api.deepseek.com`

Configura Model ID como:

`1`	`deepseek-v4-pro`

Guarda la configuración y ejecuta una prueba sencilla en Cline.

Empieza con una tarea de solo lectura y bajo riesgo:

`1`	`Please read the current project directory structure and summarize what type of project this is. Do not modify any files.`

Si Cline puede leer y responder con normalidad, la conexión del modelo funciona.

Configurarlo en Cline CLI

Si usas Cline CLI, ejecuta cline provider configure openai-compatible para entrar en la configuración interactiva.

Ejemplo:

`1`	`cline provider configure openai-compatible`

Completa:

1
2
3

API Key: sk-...
Base URL: https://api.deepseek.com
Model ID: deepseek-v4-pro

Después de configurarlo, prueba con una tarea de solo lectura:

`1`	`cline "Summarize this repository structure without changing files."`

Si quieres reducir el coste al principio, puedes cambiar temporalmente Model ID a:

`1`	`deepseek-v4-flash`

Luego vuelve a deepseek-v4-pro para planificación compleja, verificación de hechos, colaboración con varias herramientas o cambios de código de alto riesgo.

División de modelos recomendada

DeepSeek V4 Pro y Flash funcionan mejor con una separación clara.

Modelo	Mejor para
`deepseek-v4-flash`	Lectura rutinaria de código, pequeños arreglos por lotes, generación de scripts, resúmenes de contexto, cambios frontend de bajo riesgo
`deepseek-v4-pro`	Planificación de arquitectura, bugs complejos, refactors entre archivos, verificación de hechos, llamadas multi-herramienta, cambios de alto riesgo

En herramientas de Agent como Cline, el coste suele venir del contexto largo, lecturas repetidas de archivos, generación de planes y llamadas de herramientas en varias rondas. Si la tarea es ligera, usa Flash para volumen; si necesita mejor juicio, cambia a Pro.

Cómo configurar la longitud de contexto

DeepSeek V4 Pro y Flash admiten contexto largo. Si Cline exige un valor manual de ventana de contexto, puedes interpretarlo según el contexto de 1M indicado en la página oficial de modelos de DeepSeek.

En la práctica, no conviene meter todos los archivos en contexto desde el inicio. Cline lee archivos según la tarea, y un flujo mejor suele ser:

primero pedirle que inspeccione la estructura del directorio;
luego pedirle que localice los archivos relevantes;
finalmente dejar que modifique solo los archivos objetivo.

Esto ahorra tokens y mantiene más claro el límite de la tarea.

Problemas comunes

1. Modelo no encontrado

Primero comprueba que Model ID sea exactamente:

`1`	`deepseek-v4-pro`

No escribas DeepSeek V4 Pro, deepseek-v4 ni otro nombre mostrado.

2. 401 o fallo de autenticación

Comprueba la API Key:

si se copió completa;
si contiene espacios adicionales;
si se introdujo en la configuración de proveedor que Cline está usando;
si la cuenta de DeepSeek tiene saldo disponible.

3. Fallo de conexión

Comprueba la Base URL:

`1`	`https://api.deepseek.com`

No añadas /v1/chat/completions al final. El proveedor OpenAI Compatible de Cline construirá por sí mismo las solicitudes de la interfaz compatible.

4. Las llamadas de Cline son demasiado caras

Puedes pasar las tareas rutinarias a deepseek-v4-flash y usar deepseek-v4-pro solo para tareas complejas.

Además, haz que la descripción de la tarea sea lo más clara posible:

`1`	`Only modify files related to the login page. Do not refactor unrelated modules. First provide a plan, and modify code only after confirmation.`

Las tareas de Agent son más caras cuando los límites son poco claros. Cuanto más claro sea el límite, menos archivos leerá, menos llamadas de herramienta hará y más controlable será el coste.

5. Error: reasoning_content must be passed back

Si ves un error como este:

{
  "message": "400 The `reasoning_content` in the thinking mode must be passed back to the API.",
  "code": "invalid_request_error",
  "modelId": "deepseek-v4-pro"
}

Normalmente no es un problema de Key, cuota o Base URL. Significa que el modo de pensamiento de DeepSeek V4 Pro y el historial multi-ronda de llamadas de herramientas del cliente actual no están alineados.

La documentación oficial de DeepSeek indica:

el modo de pensamiento está enabled por defecto;
el modo de pensamiento devuelve reasoning_content;
si ocurre una llamada de herramienta en una ronda, las solicitudes posteriores deben devolver el reasoning_content de ese mensaje del asistente;
si el cliente no lo devuelve correctamente, la API devuelve 400.

Cuando Cline se conecta mediante el proveedor OpenAI Compatible, este error puede aparecer en la segunda ronda o después de llamadas de herramienta si la versión actual no conserva y reenvía por completo el reasoning_content de DeepSeek.

Prueba en este orden:

Actualiza Cline a la versión más reciente;
confirma que estás usando OpenAI Compatible, no el proveedor normal OpenAI;
si Cline admite cuerpo de solicitud personalizado, intenta desactivar el modo de pensamiento:

{
  "thinking": {
    "type": "disabled"
  }
}

si Cline no admite parámetros extra en el body, usa temporalmente otro modelo o un servicio proxy compatible;
vuelve a deepseek-v4-pro cuando Cline admita reenviar reasoning_content de DeepSeek V4.

Ten en cuenta que desactivar el modo de pensamiento puede reducir la capacidad de razonamiento complejo, pero puede esquivar problemas de compatibilidad del cliente cuando reasoning_content no se devuelve.

Configuración copiable

Provider: OpenAI Compatible
API Key: sk-your DeepSeek API Key
Base URL: https://api.deepseek.com
Model ID: deepseek-v4-pro

Para modo de bajo coste:

Provider: OpenAI Compatible
API Key: sk-your DeepSeek API Key
Base URL: https://api.deepseek.com
Model ID: deepseek-v4-flash

Resumen

Solo hay tres pasos clave para llamar a DeepSeek V4 Pro en Cline:

elegir OpenAI Compatible como proveedor;
establecer Base URL en https://api.deepseek.com;
establecer Model ID en deepseek-v4-pro.

Después de configurarlo, prueba con una tarea de solo lectura antes de darle cambios reales de código. Si ejecutas tareas de Agent con frecuencia, separa Flash y Pro: Flash maneja trabajo ligero y frecuente, mientras Pro se ocupa del juicio complejo y las tareas de respaldo.

Referencias:

mattpocock/skills: una colecci贸n pr谩ctica de habilidades para agentes de codificaci贸n con IA

Fri, 01 May 2026 03:43:20 +0800

mattpocock/skills es una colección pública de habilidades de agentes de codificación IA de Matt Pocock.

No es una aplicación completa ni un nuevo cliente de chat. Es un conjunto de habilidades funcionales que pueden ser utilizadas por asistentes de codificación IA. La idea es práctica: desglosar problemas comunes de codificación de IA en pequeñas habilidades que un Agent puede llamar en la tarea adecuada, en lugar de depender de un solo prompt enorme cada vez.

Si a menudo utilizas Claude Code, Codex, Cursor o herramientas de codificación IA similares, vale la pena observar este tipo de colección de habilidades. Lo que realmente afecta la experiencia de codificación con IA a menudo no es si el modelo puede escribir código, sino si puede avanzar en la tarea según tu estilo de trabajo preferido.

false

Qué Problema Resuelve

Los asistentes de codificación de IA son potentes, pero pueden cometer errores fácilmente.

Las situaciones comunes incluyen:

Comenzar cambios de código sin entender el requisito
Modificar demasiados archivos a la vez
Producir mucha explicación pero poca acción útil
Intentar cosas a ciegas después de errores
No ejecutar pruebas o verificaciones a tiempo
Ignorar patrones de proyecto existentes
Introducir abstracciones innecesarias para terminar una tarea
Escribir código sin revisar realmente los riesgos después

Estos problemas no siempre son causados por una débil capacidad del modelo. A menudo, el flujo de trabajo no está lo suficientemente restringido.

El valor de mattpocock/skills es que transforma estos modos de fallo comunes en métodos operativos reutilizables, haciendo que el Agent se comporte más como un colaborador de ingeniería experimentado en diferentes escenarios.

false

¿Qué son los Skills

En el contexto de AI Agent, un skill se puede entender como una instrucción de tarea reutilizable, un método de trabajo o un flujo de trabajo profesional.

No tiene por qué ser un código plugin, y no siempre necesita llamar a un servicio externo. En muchos casos, un skill es simplemente un conjunto claro de reglas:

Cuándo usarlo
Qué hacer primero
Qué no hacer
Qué salida se requiere
Cómo juzgar la finalización de la tarea

Esto es algo parecido a una normal prompt template, pero la granularidad está más cerca de una capacidad de tarea.

Las normal prompt templates suelen copiarse y pegarse manualmente por el usuario. Los skills son mejores como parte de una toolbox de agente, lo que permite al Agent elegir el flujo de trabajo correcto para la tarea.

false

Por qué es importante la pequeñez y la componibilidad

El README enfatiza que estas habilidades son pequeñas y componibles.

Esta dirección es importante.

Si una habilidad intenta manejarlo todo, rápidamente se convierte en un nuevo prompt gigante: largo, vago y difícil de mantener. La ventaja de las habilidades pequeñas son los límites claros.

Por ejemplo, una habilidad puede centrarse en:

Planificar primero
Arreglar errores de TypeScript
Ejecutar pruebas y corregir basándose en los resultados
Realizar revisión de código (code review)
Resumir convenciones del proyecto
Mejorar prompts
Eliminar abstracciones innecesarias

Estas habilidades se pueden combinar según la tarea. Una tarea simple puede necesitar solo una habilidad, mientras que una tarea compleja puede encadenar varias.

Esto se acerca más al trabajo de ingeniería real. No utilizas el mismo flujo de trabajo (workflow) para cada problema; eliges las herramientas según la situación.

false

Manteniendo al Ingeniero en Control

Una dirección importante de este repositorio es mantener al ingeniero en control.

La codificación con IA puede derivarse fácilmente en dos extremos.

El primero es completamente manual. La IA solo ayuda a escribir unas pocas líneas de código, mientras que todo el contexto, la planificación y la verificación todavía dependen de ti.

El segundo es completamente automatizado (hands-off). Tú envías una tarea a un Agent, lo dejas cambiar muchas cosas, y luego te enfrentas a un diff que es difícil de revisar.

Las habilidades ayudan a encontrar una posición intermedia más estable.

Permiten que la IA asuma más flujo de trabajo repetitivo, mientras la sigue limitando con reglas:

Entender la tarea antes de actuar
Leer los archivos relevantes antes de editar
Mantener el alcance de la modificación controlado
Informar sobre la incertidumbre
Verificar después de los cambios
No refactorizar código no relacionado solo para demostrar

Esto no debilita a la IA. Hace que las acciones de la IA sean más fáciles de revisar y asumir para los humanos.

false

Problemas de Alineación

El primer tipo de fallo de codificación de IA suele ser un fallo de alineación.

El usuario quiere un cambio muy específico, pero el Agent puede entenderlo como una refactorización más amplia. El usuario solo quiere que se arregle un bug, pero cambia estilos en el proceso. El usuario quiere que se siga la arquitectura existente, pero introduce un patrón nuevo.

Las habilidades pueden ayudar al Agent a hacer varias cosas al comienzo de una tarea:

Restatear el objetivo
Identificar el alcance del impacto
Reconocer los patrones de implementación existentes
Proporcionar un plan
Aclarar lo que no se hará

Este paso es como una autocomprobación del ingeniero antes de comenzar el trabajo.

Si el Agent no puede declarar claramente los límites de la tarea y comienza a escribir código directamente, es fácil que la tarea se desvíe.

false

Problemas del Bucle de Retroalimentación

La IA no debe escribir código únicamente mediante la generación one-shot.

En el desarrollo real, los bucles de retroalimentación son importantes:

Cambiar una pequeña parte
Ejecutar pruebas o type checks
Leer los errores
Corregirlos
Verificar de nuevo

Muchos Agents fallan porque omiten la retroalimentación intermedia. Cambian muchas cosas a la vez y luego resumen por intuición que “it should work”.

Las Skills pueden hacer explícito el bucle de retroalimentación. Por ejemplo, pueden exigir al Agent que:

Ejecute comprobaciones relevantes después de la modificación
Lea los mensajes de error primero si las comprobaciones fallan
Evite cambiar ciegamente archivos no relacionados
Verifique de nuevo después de cada ronda de correcciones
Informe los resultados finales de la verificación

Esto hace que la codificación con IA se parezca más al depurado (debugging) real y menos a la escritura one-shot.

false

Problemas de Control de Arquitectura

AI es bueno generando abstracciones, y también bueno sobregenerando abstracciones.

Para completar un requisito pequeño, puede crear una capa de servicio (service layer), funciones auxiliares (helper functions), objetos de configuración, type wrappers y adaptadores, haciendo que el código sea mucho más complejo que el requisito en sí.

Esto es especialmente peligroso en proyectos grandes. Las abstracciones generadas por AI a menudo parecen profesionales, pero pueden no coincidir con el estilo del proyecto existente y pueden aumentar el costo de mantenimiento.

Las buenas habilidades recuerdan al Agent que:

Preferir patrones existentes
Evitar nuevas abstracciones innecesarias
Evitar la refactorización de áreas no relacionadas
Ajustar el cambio al tamaño de la tarea
Comprender el código antes de diseñar la estructura

Esto reduce la producción que parece ingenierizada pero que en realidad es más difícil de mantener.

false

Por qué son importantes las habilidades de revisión

Escribir código y revisar código son estados diferentes.

Cuando un Agent escribe código, generalmente tiende a demostrar que su implementación funciona. Puede explicar por qué el cambio debería funcionar, pero no siempre busca activamente riesgos.

El propósito de una habilidad de revisión es cambiar el rol del Agent:

Encontrar posibles errores (bugs)
Encontrar regresiones de comportamiento
Encontrar pruebas faltantes
Encontrar casos límite (edge cases)
Encontrar mayor complejidad
Encontrar inconsistencias con las convenciones existentes

Esto es importante para la programación con IA porque la IA genera código rápidamente. Sin revisión, los usuarios pueden sentirse fácilmente abrumados por grandes diffs.

Una buena salida de revisión debe listar los problemas primero, no alabar la implementación primero. Debe ayudar al ingeniero a decidir si el cambio se puede fusionar (merged).

false

Diferencia con los archivos de reglas normales

Muchas herramientas de codificación de IA admiten reglas, instrucciones o memoria.

Estos archivos generalmente registran reglas a largo plazo, como:

Stack tecnológico del proyecto
Convenciones de nomenclatura
Comandos de prueba
Directorios que no deben modificarse
Preferencias de estilo de respuesta

Las habilidades (Skills) se centran más en el flujo de trabajo de la tarea.

Las reglas le dicen al Agent “cómo comportarse a largo plazo”, mientras que las habilidades le dicen al Agent “cómo ejecutar este tipo de tarea”.

Ambos funcionan mejor juntos.

Por ejemplo, las reglas pueden indicar que el proyecto usa pnpm test, mientras que una habilidad de revisión requiere verificar la cobertura de pruebas después de los cambios. Entonces el Agent sabe no solo el comando, sino también cuándo usarlo.

false

Escenarios Adecuados

Los repositorios como mattpocock/skills son adecuados para:

Uso frecuente de AI coding tools
Agents que trabajan en codebases reales
Reducir ediciones de AI fuera de alcance
Hacer que el Agent verifique los resultados de forma más activa
Convertir tus hábitos de ingeniería en skills
Aprender cómo otros diseñan workflows de agentes
Convertir prompts temporales en una colección de skills mantenible

Si solo pides ocasionalmente a AI que escriba una función pequeña, quizás no necesites mantener skills.

Pero si ya tratas a AI como un socio de desarrollo a largo plazo, las skills se vuelven cada vez más importantes. Son como un método de trabajo reutilizable para el Agent.

false

Cómo aprender de este repositorio

Incluso si no utilizas cada habilidad directamente, puedes aprender varias cosas de este repositorio.

Primero, anota los modos de fallo.

No solo te quejes cuando la AI comete un error. Convierte los patrones que a menudo se equivoca en reglas, para que una habilidad pueda evitarlos la próxima vez.

Segundo, mantén las habilidades cortas.

Una habilidad debe resolver un problema claro. Cuanto más corta sea, más fácil será llamarla correctamente y mantenerla.

Tercero, haz que el formato de salida sea claro.

Si quieres que el Agent enumere un plan primero, ejecute después y resuma los resultados de verificación al final, escribe esa estructura claramente. Los requisitos vagos suelen producir resultados vagos.

Cuarto, conserva puntos de traspaso humano.

Una buena habilidad no debe permitir que la AI funcione sola durante demasiado tiempo. Cuando haya incertidumbre, un alcance de impacto expandido, pruebas fallidas o una decisión de producto, debe detenerse y explicar la situación.

false

Notas de uso

Primero, no conviertas todo en habilidades (skills).

Demasiadas habilidades hacen que el sistema sea complejo, y el Agent podría no saber cuál elegir. Empieza con los escenarios más frecuentes y más problemáticos.

Segundo, las habilidades necesitan iteración.

La primera versión de una habilidad puede no ser buena. Observa cómo la IA la ejecuta realmente, luego elimina, añade y reescribe gradualmente.

Tercero, no permitas que las habilidades reemplacen el juicio de la ingeniería.

Las habilidades pueden mejorar el flujo de trabajo, pero no pueden garantizar una implementación correcta. Las pruebas (tests), la revisión, las comprobaciones de compilación (build checks) y el juicio humano siguen siendo importantes.

Cuarto, presta atención a las diferencias entre los Agents.

Claude Code, Codex, Cursor y Copilot soportan las instrucciones, las habilidades y las reglas de manera diferente. La misma idea se puede reutilizar, pero el formato específico debe ajustarse para cada herramienta.

false

Referencia

mattpocock/skills

false

Pensamiento Final

Lo que hace que mattpocock/skills merezca la pena es no un único prompt mágico dentro de él, sino la idea práctica de codificación con IA que demuestra: dividir la experiencia de ingeniería en pequeñas habilidades y luego permitir que el Agent las combine según el escenario.

A medida que la codificación con IA pasa de ser una asistencia ocasional a formar parte del flujo de trabajo diario, las habilidades se convierten en herramientas importantes para limitar a los Agents, mantener a los ingenieros en control y mejorar la calidad de la retroalimentación. false

Compound Engineering Plugin: convertir la programación con IA en un ciclo de planificación, ejecución y revisión

Fri, 01 May 2026 03:15:39 +0800

Compound Engineering Plugin es un plugin de flujo de trabajo de programación con IA publicado como open source por Every Inc.

No se centra en “hacer que la IA escriba un fragmento de código más rápido”, sino en colocar la programación con IA dentro de un ciclo más parecido al de un equipo de ingeniería: primero planificar, luego implementar, después revisar y finalmente conservar la experiencia aprendida. Para quienes usan con frecuencia herramientas como Claude Code, Codex, Cursor o Copilot, este tipo de plugin resuelve un problema de flujo de trabajo, no solo de prompts.

Las herramientas de programación con IA son cada vez más fuertes, pero en proyectos reales lo más difícil no suele ser generar código, sino lograr que siga de forma continua las reglas del proyecto, entienda los límites de la tarea, evite repetir errores y acumule contexto durante iteraciones largas.

Qué problema resuelve

Muchas personas usan asistentes de programación con IA más o menos así:

Describen directamente el requisito
Dejan que la IA modifique código
Miran si el resultado puede ejecutarse
Si hay error, añaden más instrucciones
En la siguiente tarea vuelven a explicar desde cero

Este método puede completar tareas pequeñas, pero en proyectos complejos aparecen problemas con facilidad:

El requisito no se divide primero con claridad y la IA empieza a modificar directamente
Falta una review sistemática después de los cambios
Las reglas del proyecto dependen de que el usuario las recuerde una y otra vez
El mismo tipo de error vuelve a aparecer en la siguiente ocasión
Falta un método de trabajo común entre varias herramientas Agent
La experiencia no se convierte en reglas reutilizables

Compound Engineering Plugin quiere resolver precisamente estos problemas. Divide la programación con IA en varias etapas, para que el Agent no solo ejecute comandos, sino que participe en un proceso de ingeniería más completo.

Qué es Compound Engineering

Según la descripción del README del proyecto, Compound Engineering puede entenderse como un método de desarrollo de software asistido por IA.

Destaca un ciclo:

Planificación: entender primero el objetivo, dividir tareas y confirmar la ruta
Ejecución: modificar código según el plan, ejecutar comandos y tratar problemas
Revisión: comprobar calidad de implementación, riesgos y cobertura de pruebas
Aprendizaje: convertir la experiencia en reglas reutilizables para el futuro

Este ciclo se parece mucho a la forma de trabajo de un equipo de ingeniería real.

Un ingeniero fiable no recibe un requisito y empieza a cambiar cosas sin rumbo, ni entrega directamente después de modificar. Primero evalúa el alcance de impacto, luego implementa, después revisa riesgos y resultados de pruebas, y finalmente registra los problemas encontrados. Los AI Agent también necesitan restricciones similares.

Por qué hace falta un plugin

Un prompt puede decirle a la IA “planifica antes de ejecutar”, pero el prompt por sí mismo no siempre es estable.

Cuando la conversación se alarga y el contexto se vuelve complejo, el modelo puede saltarse la planificación, ignorar reglas o volverse demasiado confiado para terminar la tarea. El valor del plugin está en fijar el proceso para que distintos entornos Agent sigan un método parecido.

Este tipo de plugin suele dividir el flujo de trabajo en comandos, reglas, plantillas o subprocesos. El usuario no necesita escribir cada vez un prompt completo, sino que activa una etapa mediante una entrada fija.

Por ejemplo:

Pedir primero al Agent que genere un plan
Implementar después paso a paso según el plan
Activar review tras terminar los cambios
Volver a corregir cuando se encuentren problemas
Escribir las experiencias valiosas en memoria o reglas

Esto hace que la programación con IA se parezca más a una “colaboración controlada” que a una conversación de una sola vez.

Qué entornos Agent soporta

El README menciona que el proyecto soporta varios entornos de programación con IA, incluyendo:

Claude Code
Codex
Cursor
GitHub Copilot
Amp
Factory
Qwen Code

Este punto es importante.

Muchas herramientas de flujo de trabajo están atadas a un solo cliente; al cambiar de herramienta, las reglas dejan de reutilizarse. Compound Engineering Plugin se parece más a un método de ingeniería transversal a distintos Agent, llevando procesos similares de planificación, ejecución y revisión a varias herramientas.

Si usas varios asistentes de programación con IA al mismo tiempo, este tipo de flujo unificado gana valor. Las herramientas tienen capacidades distintas, pero las normas del proyecto, los hábitos de review y el método de división de tareas deberían ser lo más consistentes posible.

Para qué sirve la etapa de planificación

El valor de la planificación es evitar que la IA actúe demasiado pronto.

En tareas complejas, las preguntas realmente importantes suelen ser:

Qué archivos hay que modificar
Qué módulos pueden verse afectados
Cuál es el patrón existente
Si hay pruebas
Dónde están los riesgos
Si hay que leer documentación antes
Si puede dividirse en pasos más pequeños

Si el Agent no piensa primero estas preguntas y se pone a escribir código directamente, es fácil que produzca una implementación que parece terminada, pero que se aleja de la estructura del proyecto.

El plan no tiene que ser largo. Un buen plan debería ser corto, concreto y ejecutable. Su objetivo no es fabricar documentación, sino dar límites a la implementación posterior.

Qué evitar en la etapa de ejecución

Cuando la IA ejecuta tareas de código, aparecen con facilidad varios problemas:

Refactorizar código no relacionado de paso
Sobrescribir cambios existentes del usuario
Cambiar solo el happy path
Ignorar manejo de errores
No seguir el estilo existente del proyecto
No ejecutar validaciones necesarias
Probar a ciegas tras encontrar errores

Un plugin de flujo de trabajo no puede garantizar que estos problemas desaparezcan por completo, pero puede reducir su frecuencia mediante reglas y restricciones por etapa.

Por ejemplo, la etapa de ejecución puede pedir al Agent que avance paso a paso según el plan; si descubre algo fuera del alcance previsto, primero explica el riesgo; si modifica módulos compartidos, añade pruebas o al menos ejecuta validaciones relacionadas.

Esta restricción es especialmente importante en codebases grandes. Cuanto más rápido escribe código la IA, más necesita un proceso que limite su inercia.

Por qué importa la etapa de review

Muchos fallos de programación con IA no ocurren porque el código no pueda ejecutarse en absoluto, sino porque los detalles están mal:

No se tratan condiciones límite
Las actualizaciones de estado no son consistentes
El contrato de API se cambia en silencio
Las pruebas no cubren rutas clave
Los mensajes de error no son claros
No se mencionan riesgos de rendimiento o seguridad

La etapa de review cambia al Agent de “modo autor” a “modo revisor”.

El modo autor tiende a justificar su propia implementación; el modo revisor debe buscar activamente defectos, riesgos de regresión y pruebas omitidas. Separar estas dos etapas suele ser más fiable que pedir en una misma respuesta que implemente y se autoevalúe.

Para el usuario, la salida de review también es más valiosa. Ayuda a decidir rápidamente si este cambio merece integrarse o si necesita otra ronda de trabajo.

El sentido de aprendizaje y memoria

La palabra “Compound” del nombre del proyecto sugiere una idea importante: la experiencia de ingeniería debería crecer con efecto compuesto.

Si cada vez que la IA comete un error solo lo arregla en ese momento, pero la próxima vez comete el mismo error, la mejora de eficiencia es limitada. Un mejor método es conservar la experiencia útil:

Convenciones de directorios del proyecto
Métodos de diagnóstico para ciertos errores
Comandos de prueba y precauciones
Archivos generados que no deben tocarse
Preferencias de estilo de código
Patrones de implementación habituales

Estas experiencias pueden convertirse en reglas, memoria, documentación o plantillas. En tareas posteriores, el Agent lee primero ese conocimiento acumulado y luego empieza a trabajar.

Esa es la clave para que la programación con IA pase de “pregunta y respuesta puntual” a “colaboración de largo plazo”.

Escenarios adecuados

Compound Engineering Plugin es adecuado para:

Usar AI Agent para escribir código de forma continua
Modificar un mismo proyecto durante muchas rondas
Querer que la IA planifique antes de implementar
Querer que después de modificar entre automáticamente en mentalidad de review
Equipos que quieren unificar el flujo de programación con IA
Personas que usan a la vez Claude Code, Codex, Cursor y otras herramientas
Querer convertir experiencia del proyecto en reglas reutilizables

Si solo pides ocasionalmente a la IA que escriba un pequeño script, el flujo completo puede parecer pesado.

Pero si estás tratando al asistente de programación con IA como un compañero diario de desarrollo, el ciclo de planificación, ejecución, revisión y aprendizaje se vuelve claramente útil.

Diferencia frente a plantillas de prompt comunes

Las plantillas de prompt comunes suelen resolver “cómo expresar bien la tarea”.

Por ejemplo:

Piensa paso a paso
Lee primero los archivos
Mantén el estilo de código
Ejecuta pruebas
Resume los cambios

Estas indicaciones son útiles, pero siguen dependiendo de que el usuario las use correctamente cada vez.

Compound Engineering Plugin se sitúa más en la capa de flujo de trabajo. Organiza estos requisitos en un proceso repetible y lo adapta a distintas herramientas Agent. Así, no partes de cero escribiendo prompts cada vez, sino que avanzas dentro de un proceso.

En pocas palabras, una plantilla de prompt se parece a un recordatorio; un plugin de flujo de trabajo se parece a un sistema.

Precauciones al usarlo

Primero, no conviertas el proceso en una carga.

Las tareas pequeñas no siempre necesitan un plan completo y una review larga. Un buen flujo de trabajo debería ajustarse a la complejidad de la tarea: resolver rápido los problemas simples y usar el ciclo completo en problemas complejos.

Segundo, la review no sustituye a las pruebas.

Una review hecha por Agent puede encontrar muchos problemas, pero aun así puede omitir errores reales de ejecución. El juicio final depende de pruebas, type checking, resultados de build y revisión humana.

Tercero, hay que limpiar reglas de forma continua.

Acumular experiencia es importante, pero demasiadas reglas también se convierten en ruido. Reglas obsoletas, repetidas o que solo servían para una tarea puntual deberían ordenarse periódicamente.

Cuarto, consistencia entre herramientas no significa identidad total.

Claude Code, Codex, Cursor, Copilot y otras herramientas tienen capacidades e interacciones diferentes. Lo que se unifica es el método de trabajo, no necesariamente cada comando ni cada detalle de configuración.

Qué equipos pueden aprovecharlo

Si un equipo ya permite que AI Agent modifique código real, no basta con discutir “qué modelo es más fuerte”.

Debería preocuparse más por:

Si la IA entiende la tarea antes de modificar
Si respeta límites del proyecto mientras modifica
Si revisa riesgos activamente después de modificar
Si aprende de errores históricos
Si el equipo tiene una norma común de uso de Agent

Ahí está el sentido de proyectos como Compound Engineering Plugin. Llevan la programación con IA desde una habilidad personal hacia un proceso reutilizable por el equipo.

Referencia

EveryInc/compound-engineering-plugin

Una última frase

Lo que merece atención de Compound Engineering Plugin no es que añada un comando más de programación con IA, sino que organiza la programación con IA como un proceso de ingeniería que puede mejorar en ciclos.

Cuando los AI Agent empiezan a participar en proyectos reales, planificación, ejecución, revisión y acumulación de experiencia importan más que generar código una sola vez.

Dominio de los ganchos de Claude Code: una introducción a los 13 eventos del ciclo de vida de los ganchos y al control de automatización

Fri, 01 May 2026 03:11:27 +0800

claude-code-hooks-mastery es un proyecto de aprendizaje centrado en Claude Code Hooks.

No es sólo una colección de guiones dispersos. Explica el ciclo de vida del gancho de Claude Code, los métodos de configuración, los patrones de script y los escenarios de automatización comunes en un solo lugar. Para las personas que quieren que Claude Code sea más controlable y más parecido a un asistente de ingeniería, vale la pena leer este tipo de material.

Claude Code ya puede leer código, editar archivos y ejecutar comandos de forma predeterminada. Pero si desea que verifique permisos automáticamente, bloquee operaciones riesgosas, inyecte reglas de proyecto, ejecute pruebas o le recuerde las convenciones del equipo en momentos específicos, las instrucciones de chat por sí solas no son lo suficientemente estables. El valor de los ganchos es que convierten las “reglas que necesito recordarle a la IA cada vez” en un flujo de trabajo ejecutable.

Qué problemas resuelven los ganchos

Después de usar Claude Code por un tiempo, los puntos débiles comunes incluyen:

Cada nueva sesión necesita repetir las mismas reglas del proyecto.
Te preocupa que pueda ejecutar comandos que no debería ejecutar.
Quieres verificaciones antes y después de la edición de archivos.
Quiere formatear, realizar pruebas o realizar análisis de seguridad antes de confirmar
Quieres que las convenciones del equipo sean un flujo de trabajo fijo en lugar de recordatorios verbales.
Quiere contexto antes y después de las llamadas a herramientas para iniciar sesión o bloquear
Quiere que tareas complejas activen subagentes o scripts dedicados

Los ganchos están diseñados para estas “acciones automáticas en momentos fijos”.

Puedes considerarlos como enlaces de eventos en el flujo de trabajo de Claude Code. Cuando se inicia una sesión, un usuario envía un mensaje, el modelo está a punto de llamar a una herramienta, finaliza una llamada a una herramienta o un agente está a punto de detenerse, Claude Code puede ejecutar los scripts que usted configuró.

Los 13 eventos del ciclo de vida del gancho

Uno de los puntos principales del proyecto README es que cubre sistemáticamente los 13 eventos de gancho del Código Claude.

Estos eventos abarcan varias etapas, desde el inicio de la sesión hasta las llamadas a las herramientas, y desde la entrada del usuario hasta la terminación del agente. Por finalidad, se pueden agrupar a grandes rasgos como:

Inicio de sesión: inicializa el entorno e inyecta el contexto del proyecto.
Entrada del usuario: inspeccionar indicaciones, agregar reglas y realizar auditorías
Antes de las llamadas a la herramienta: comprobaciones de permisos, bloqueo de comandos y validación de seguridad.
Después de las llamadas a la herramienta: registrar resultados, activar el formateo y ejecutar la verificación
Finalización de tareas: resumir, limpiar, notificar o guardar estado

Este diseño de ciclo de vida significa que no es necesario incluir todas las reglas en un mensaje muy largo.

Por ejemplo, el control de permisos debe realizarse antes de las llamadas a la herramienta. Las comprobaciones de formato son mejores después de editar los archivos. La inyección de reglas del proyecto es mejor al inicio de la sesión o después de la entrada del usuario. Poner reglas en el punto de enlace correcto suele ser más confiable que meter todo en un indicador del sistema.

Dónde vive la configuración

Los ganchos de Claude Code generalmente se configuran a través de archivos de configuración.

Las ubicaciones comunes incluyen:

Configuración a nivel de usuario: ~/.claude/settings.json
Configuración a nivel de proyecto: .claude/settings.json

La configuración a nivel de usuario es buena para las preferencias personales, como reglas generales de seguridad, bloqueo de comandos y rutas de registro.

La configuración a nivel de proyecto es mejor para reglas específicas del repositorio, como qué pruebas se deben ejecutar, qué directorios no se pueden editar, cómo se manejan los archivos generados y qué comprobaciones se requieren antes de la confirmación. Si usa Claude Code en un equipo, es mejor colocar la configuración a nivel de proyecto en el repositorio. De esa manera, todos inician el proyecto con las mismas limitaciones de colaboración de IA en lugar de depender de la memoria personal.

Por qué son importantes los scripts de un solo archivo

El proyecto enfatiza los scripts de un solo archivo “UV”.

El beneficio es una implementación simple. Un único archivo Python puede declarar dependencias y ejecutarse sin mantener un entorno complejo para un enlace. Esto encaja bien con los ganchos porque muchos ganchos solo hacen una pequeña cosa:

Comprobar si un comando está permitido
Determinar si la ruta de un archivo es segura
Leer las reglas del proyecto y devolvérselas a Claude.
Escanear la salida en busca de información confidencial
Ejecutar formateo o pruebas después de las ediciones.
Escribir eventos en registros.

Cuanto más pequeño sea un script de enlace, más fácil será de mantener y es menos probable que se convierta en un sistema nuevo y complicado.

¿Qué pueden hacer los ganchos con la automatización?

claude-code-hooks-mastery muestra muchas direcciones. En el trabajo real, los más comunes se encuentran a continuación.

1. Control de permisos y seguridad

Este es el uso más directo de los ganchos.

Antes de que Claude Code ejecute un comando, un gancho puede inspeccionar el contenido del comando. Si contiene acciones de alto riesgo, como eliminar, restablecer, limpiar o sobrescribir, puede bloquear la ejecución o requerir confirmación manual.

Se pueden aplicar reglas similares a las rutas de archivos:

No modificar la configuración de producción.
No escribir en archivos secretos
No eliminar scripts de migración
No tocar directorios específicos
No ejecute comandos de red no aprobados

Anteponer esta protección a las llamadas a herramientas es más confiable que escribir “no realizar operaciones peligrosas” en un mensaje.

2. Inyección de contexto

Muchos proyectos tienen información de fondo fija:

Pila de tecnología
Convenciones de codificación
Comandos de prueba
Estrategia de ramificación
Estructura del directorio
Acciones prohibidas
Reglas para archivos generados.

Decirle esto a Claude Code manualmente cada vez es molesto y fácil de olvidar. Los ganchos pueden inyectar automáticamente el contexto necesario al inicio de la sesión o después de que el usuario envía un mensaje.

Esto es como darle a Claude Code un manual de trabajo a nivel de proyecto. No reemplaza el README ni la documentación de desarrollo, pero ayuda a la IA a ingresar al estado correcto antes de ejecutar una tarea.

3. Verificación después de las ediciones

Después de que Claude Code modifica archivos, los ganchos pueden activar comprobaciones automáticamente.

Las acciones comunes incluyen:

Ejecutar formateo
Ejecutar pelusa
Ejecutar pruebas unitarias.
Verificar errores de tipo
Escanear archivos generados
Validar formato Markdown o JSON

Esto ayuda a reducir los errores de bajo nivel. Cuando la IA edita varios archivos, una verificación ligera después de la modificación puede revelar problemas antes.

Sin embargo, los ganchos no deberían ejecutar tareas pesadas de forma predeterminada. Ejecutar el conjunto de pruebas completo después de cada cambio de archivo puede ralentizar la experiencia. Un mejor enfoque es elegir comprobaciones según el tipo de archivo, el directorio y el riesgo de la tarea.

4. Validación de las reglas del equipo

Si un equipo ya tiene convenciones claras, algunas de ellas pueden colocarse en ganchos.

Por ejemplo:

Confirmar formato de mensaje
Reglas de estilo de código
No editar directamente ciertos archivos generados
La documentación debe actualizarse en conjunto.
Los cambios de API deben actualizar las pruebas.
Ciertos directorios sólo pueden ser generados por herramientas específicas Esto hace que Claude Code se parezca más a una parte del flujo de trabajo del equipo que a un asistente externo sin restricciones.

Por supuesto, los ganchos no deberían reemplazar a la CI. Son mejores para recordatorios locales y bloqueo temprano. La validación final aún debe pertenecer a los sistemas de CI, revisión y prueba.

5. Subagentes y tareas dedicadas

El archivo README también menciona contenido relacionado con subagentes.

Este tipo de uso es adecuado para enviar tareas complejas a flujos de trabajo más especializados. Por ejemplo, la conversación principal puede comprender el requisito, mientras que un enlace o una configuración desencadenan tareas dedicadas de verificación, auditoría, resumen o documentación.

Para los usuarios individuales, el primer paso útil no es la compleja orquestación de agentes. Es mejor entregar primero a los ganchos acciones repetitivas, claras y de bajo riesgo. Una vez que las reglas se estabilicen, puede producirse una automatización más compleja.

Línea de estado y estilos de salida

El proyecto también cubre la línea de estado y los estilos de salida.

Esto puede parecer un pequeño detalle de la experiencia, pero es importante para el uso a largo plazo del Código Claude. Una línea de estado puede mostrar el contexto actual, el estado de la tarea, información del entorno o sugerencias. Los estilos de salida pueden hacer que las respuestas de Claude Code se ajusten mejor a sus hábitos de trabajo.

Si colaboras con IA en el mismo terminal todos los días, estos detalles afectan la eficiencia. Las buenas sugerencias de estado reducen los errores y le ayudan a determinar rápidamente si la sesión actual se encuentra en el proyecto, rama y entorno correctos.

No hagas que los ganchos sean demasiado pesados

Los ganchos son poderosos, pero no son el lugar para poner todo.

Las buenas reglas son:

Las acciones de alta frecuencia deben ser rápidas.
El bloqueo de seguridad debe ser claro.
La salida debe ser corta.
Los motivos del fallo deben ser legibles.
Los scripts deben tener una única responsabilidad.
Las comprobaciones exhaustivas deben ser comandos explícitos o tareas de CI

Si un enlace tarda más de diez segundos cada vez, los usuarios pronto querrán desactivarlo. Si un gancho tiene reglas de bloqueo vagas, tanto Claude Code como el usuario tendrán dificultades para entender qué hacer a continuación.

Los ganchos son mejores para tareas con límites claros: permitir o rechazar, agregar contexto, registrar eventos, ejecutar comprobaciones ligeras y sugerir el siguiente paso.

¿Quién debería usarlo?

Si solo ocasionalmente le pides a Claude Code que edite un pequeño fragmento de código, es posible que aún no necesites estudiar los ganchos en profundidad.

Pero este proyecto es útil si:

Utilice Claude Code con frecuencia
A menudo deja que la IA modifique el código del proyecto real.
Preocupación por que la IA ejecute comandos peligrosos
Quiere inyectar automáticamente reglas de equipo en los flujos de trabajo de IA
Quiere que las comprobaciones se ejecuten automáticamente después de las ediciones
Quiere convertir recordatorios repetidos en configuración
Están creando un flujo de trabajo de codificación de IA más estable.

Los ganchos son especialmente significativos en proyectos colaborativos. Pueden convertir parte de la experiencia del equipo en guiones en lugar de depender de que cada persona se lo recuerde a la IA manualmente.

Notas de uso

Primero, comience con los ganchos de seguridad.

En comparación con la automatización compleja, el bloqueo de comandos, la protección de rutas y las comprobaciones de archivos confidenciales son más fáciles de implementar y reducen el riesgo de inmediato.

En segundo lugar, comprometa cuidadosamente las reglas a nivel de proyecto.

.claude/settings.json afecta a todos los que usan el repositorio. Antes de comprometer reglas, asegúrese de que no restrinjan demasiado el desarrollo normal ni dependan de rutas que solo existen en su máquina.

En tercer lugar, mantenga la salida del gancho concisa. Claude Code consume esta salida. Si es demasiado largo, contamina el contexto. Si es demasiado vago, no guía el siguiente paso. Lo mejor es devolver sólo el juicio necesario y la siguiente recomendación.

Cuarto, mantenga los ganchos depurables.

Cuando los ganchos aumentan en número, los problemas pueden provenir de la configuración, los scripts, los permisos, las rutas, las dependencias o el propio Claude Code. Los registros claros facilitan mucho la depuración posterior.

Referencia

disler/claude-code-hooks-mastery

Pensamiento final

El valor de “Claude Code Hooks” es convertir “reglas que espero que la IA recuerde siempre” en flujos de trabajo que realmente se ejecutan.

Si ya utiliza Claude Code en proyectos reales, los ganchos son un paso clave desde “un asistente de codificación que puede conversar” hasta “un colaborador de ingeniería limitado”.

Claude-Mem: Agregar memoria a largo plazo entre sesiones al código Claude

Fri, 01 May 2026 03:01:02 +0800

Claude-Mem es un sistema de memoria persistente para Claude Code.

Intenta resolver un problema muy específico: cada vez que un asistente de codificación de IA inicia una nueva sesión, a menudo olvida decisiones de arquitectura anteriores, obstáculos pasados, preferencias de proyecto y contexto de implementación.
Si un proyecto dura mucho tiempo, explicar repetidamente los mismos antecedentes se convierte en una pérdida de tiempo.

La idea detrás de Claude-Mem es comprimir las conversaciones de Claude Code en recuerdos, almacenarlas en una base de datos local y en un almacén de vectores, y luego recuperarlas a través de una herramienta de búsqueda.

¿Qué problema resuelve?

Claude Code es bueno en tareas de código, pero el contexto de la sesión aún es limitado.

Los puntos débiles comunes incluyen:

Una nueva sesión no sabe lo que hicieron las sesiones anteriores.
Las decisiones de diseño del proyecto deben explicarse repetidamente.
Los problemas que ya fueron depurados son fáciles de repetir
Las tareas de larga duración carecen de continuidad.
El conocimiento del proyecto es difícil de acumular a través de conversaciones.

Claude-Mem está diseñado en torno a estos problemas.

No se trata simplemente de guardar registros de chat. En cambio, comprime las conversaciones en fragmentos de memoria que son más fáciles de recuperar. Cuando sea necesario más adelante, la búsqueda semántica puede recuperar el contexto relevante.

Cómo funciona

Según el diseño README, “Claude-Mem” consta principalmente de varias partes.

La primera parte son los ganchos.

Se integra con el flujo de sesión de Claude Code y captura datos de la conversación en el momento adecuado.

La segunda parte es un trabajador en segundo plano.

El trabajador procesa el contenido de la conversación en bruto y lo convierte en recuerdos más breves y fáciles de buscar.

La tercera parte es el almacenamiento local.

El proyecto utiliza SQLite para metadatos estructurados y Chroma para indexación de vectores. Esto preserva la información básica de la sesión al tiempo que admite la recuperación semántica.

La cuarta parte es “mem-search”.

Este es el punto de entrada de consulta para Claude Code. Cuando se necesita un contexto antiguo, se pueden buscar recuerdos relevantes a través de esta herramienta.

El flujo general se puede entender así:

Las sesiones de Claude Code generan contenido
Los ganchos capturan datos de la sesión
El trabajador lo comprime y organiza de forma asincrónica.
Los recuerdos se escriben en SQLite y Chroma.
Las sesiones posteriores los recuperan mediante mem-search

¿Cuándo es útil?

Claude-Mem es adecuado para proyectos de larga duración, no para tareas pequeñas y puntuales.

Por ejemplo:

Un repositorio se desarrolla durante muchos días.
La estructura del código es compleja y tiene muchos antecedentes.
Es necesario recordar las convenciones del proyecto, los hábitos de nomenclatura y las elecciones de arquitectura.
Claude Code se utiliza a menudo para corregir errores, funciones y documentación.
Quieres que la IA recuerde por qué se cambió algo antes

Si solo le pide a Claude Code que haga un cambio de una línea, la memoria a largo plazo no es muy significativa.
Pero si tratas a Claude Code como un colaborador a largo plazo, resulta útil.

Instalación y puesta en marcha

El README proporciona un flujo de instalación directo:

1
2

npm install -g claude-mem
claude-mem install

Empiece con:

`1`	`claude-mem start`

Verificar estado:

`1`	`claude-mem status`

Deténgalo cuando sea necesario:

`1`	`claude-mem stop`

El objetivo detrás de estos comandos es conectar el sistema de memoria como un servicio local de larga duración al flujo de trabajo de Claude Code.

Cómo utilizar `mem-search`

mem-search es el punto de entrada clave para recuperar la memoria.

No pretende reemplazar la búsqueda ordinaria. Permite a Claude Code consultar conversaciones pasadas por significado.

Por ejemplo, Claude Code puede buscar:

Por qué un módulo fue diseñado de cierta manera
Cómo se depuró un error anteriormente
Reglas de nomenclatura acordadas en el proyecto.
Compensaciones técnicas discutidas anteriormente
El trasfondo detrás de una refactorización.

Esto es diferente de la simple búsqueda de palabras clave.
Si la compresión de memoria y la indexación de vectores funcionan bien, puede recuperar contenido semánticamente relacionado incluso si no recuerda la redacción exacta.

¿En qué se diferencia de la documentación del proyecto?

La documentación del proyecto es buena para sacar conclusiones estables.

Por ejemplo:

Notas de arquitectura
Procedimientos de implementación
Convenciones API
Estructura de la base de datos
Reglas de desarrollo

Claude-Mem es mejor para el contexto creado durante las conversaciones.

Por ejemplo:

Por qué se rechazó un plan
Cómo se solucionó un problema temporal
La discusión detrás de una implementación.
Las preferencias del proyecto aún no están escritas en los documentos.
Antecedentes de tareas acumulados en múltiples conversaciones

Los dos no se reemplazan el uno al otro.
Un buen flujo de trabajo es escribir conocimientos estables en los documentos del proyecto y utilizar el sistema de memoria para ayudar a recuperar el contexto conversacional.

Cosas a tener en cuenta

En primer lugar, una mayor memoria a largo plazo no siempre es mejor.

Si cada conversación se guarda sin distinción, la recuperación posterior puede resultar ruidosa. Los recuerdos más valiosos son las decisiones del proyecto, los antecedentes de la implementación, el historial de depuración y las preferencias a largo plazo.

En segundo lugar, la memoria no puede reemplazar el código y la documentación.

El contexto antiguo encontrado por la IA es sólo una referencia. El juicio final aún depende del código actual, los resultados de las pruebas y los requisitos más recientes.

En tercer lugar, preste atención a la privacidad y los datos locales.

Dado que almacena el contenido de la conversación, debes saber qué proyectos son adecuados para él y qué información confidencial no debe entrar en la conversación.

Cuarto, los sistemas de memoria necesitan mantenimiento.

A medida que avanza un proyecto, los viejos recuerdos pueden quedar obsoletos. Si el contexto obsoleto se reutiliza incorrectamente, puede inducir a error en tareas posteriores.

Por qué es importante este tipo de herramienta

Las herramientas de codificación de IA están pasando de preguntas y respuestas únicas a una colaboración a largo plazo.

En preguntas y respuestas únicas, el modelo solo necesita responder la pregunta actual.
En una colaboración a largo plazo, es necesario conocer el historial del proyecto, las decisiones anteriores, las preferencias del equipo y los obstáculos que ya se han encontrado.

Aquí es donde importan herramientas como Claude-Mem: convierten el “recordar el contexto” de una capacidad de chat temporal en un sistema local que puede instalarse, ejecutarse y buscarse.

Para proyectos de ingeniería reales, esto es más práctico que simplemente alargar la ventana de contexto del modelo.
No es necesario contextualizar mucha información de una sola vez; es necesario recuperarlo en el momento adecuado.

¿Quién debería intentarlo?

Quizás quieras probarlo si:

Usas Claude Code con frecuencia
A menudo trabajas en el mismo proyecto durante varios días.
El contexto del proyecto es complejo.
Explicas repetidamente los mismos antecedentes a la IA.
Quieres preservar la experiencia de las conversaciones.

Si solo usas Claude Code ocasionalmente, o el proyecto es pequeño, es posible que aún no necesites este tipo de sistema.

Referencia

thedotmack/claude-mem

Pensamiento final

El objetivo de Claude-Mem no es “guardar registros de chat”. Ayuda a Claude Code a recuperar contexto útil en tareas posteriores. A medida que la codificación de IA pase de tareas únicas a colaboraciones en proyectos de larga duración, los sistemas de memoria serán cada vez más importantes.
No pueden reemplazar la documentación y las pruebas, pero pueden reducir las explicaciones repetidas y hacer que la IA se sienta más como un asistente que comprende el historial del proyecto.

Primeros pasos con la compilación de programas UEFI: desde uefi-simple hasta su primer .EFI

Thu, 30 Apr 2026 19:53:08 +0800

Compilar su primer programa UEFI no es precisamente sencillo. La configuración del entorno puede llevar tiempo, los errores del vinculador son comunes y un programa .EFI no tiene la misma experiencia directa de edición y ejecución que una aplicación de escritorio normal.

Este artículo organiza el tema desde la perspectiva de un principiante: si sólo desea compilar su primer programa UEFI, ¿por dónde debería empezar, qué conceptos importan primero y qué errores es más probable que aparezcan?

¿Qué es un programa UEFI?

Un programa UEFI suele ser un archivo .EFI.

No es un .exe ordinario en el que se hace doble clic en Windows. Es un ejecutable PE/COFF que se ejecuta dentro del entorno de firmware UEFI. Los casos de uso comunes incluyen:

Gestores de arranque
Herramientas de inicialización de hardware.
Herramientas de actualización de firmware
Herramientas de diagnóstico previas al arranque
Flujos de arranque personalizados

Muchas funciones que ve al principio del proceso de inicio del sistema pueden estar relacionadas con aplicaciones, controladores o servicios de firmware UEFI.

Para los principiantes, no es necesario comprender inmediatamente el desarrollo completo del firmware. El primer objetivo es simple: compilar un archivo .EFI que pueda cargarse mediante un UEFI Shell o un emulador.

¿Por qué no empezar con EDK II?

El desarrollo real de UEFI a menudo implica EDK II.

EDK II es completo y más cercano a la ingeniería de firmware real, pero no es muy amigable para principiantes:

La estructura del proyecto es compleja.
El sistema de construcción tiene una curva de aprendizaje.
Las variables de entorno y la configuración de la cadena de herramientas implican muchos detalles.
Los errores del compilador no siempre son fáciles de entender.
Es fácil quedarse atascado en el entorno antes de escribir cualquier código.

Si el objetivo es simplemente ejecutar un programa UEFI mínimo, un ejemplo ligero es un mejor punto de partida.

pbatard/uefi-simple es uno de esos proyectos. Su objetivo es sencillo: proporcionar un ejemplo UEFI Hello World sencillo para que puedas compilar un archivo .EFI primero.

¿Para qué sirve `uefi-simple`?

uefi-simple es un buen primer paso para los principiantes en UEFI.

Resuelve tres problemas prácticos:

Le brinda una estructura de aplicación UEFI mínima y compilable.
Evita la complejidad de grandes proyectos de firmware al principio
Le permite verificar que compilar, vincular y ejecutar todo funciona.

El proyecto admite múltiples métodos de compilación, incluidos Visual Studio 2022 y MinGW/gcc. También se puede probar con QEMU y OVMF.

En otras palabras, no es necesario reiniciar repetidamente una máquina real para los primeros experimentos. Ejecutar primero el programa en un emulador es mucho más seguro.

Qué preparar antes de comenzar

Necesita al menos algunas categorías de herramientas.

La primera categoría es la cadena de herramientas del compilador.

En Windows, puedes comenzar con:

Estudio Visual 2022
O MinGW/gcc

La segunda categoría es un entorno de ejecución UEFI.

Hay dos opciones comunes:

Ejecute el archivo .EFI en UEFI Shell de una máquina real
Pruébalo en un entorno virtual con QEMU + OVMF

La tercera categoría es un proyecto de ejemplo.

Los principiantes no deberían empezar escribiendo scripts de compilación desde un directorio vacío. Usar un ejemplo mínimo como uefi-simple ayuda a evitar muchos problemas del sistema de compilación.

Flujo de trabajo básico

Un flujo de trabajo mínimo de un programa UEFI se puede entender así.

Primero, obtenga el proyecto de ejemplo.

`1`	`git clone https://github.com/pbatard/uefi-simple.git`

En segundo lugar, elija una cadena de herramientas de compilación. Si usa Visual Studio, cree con la solución Visual Studio en el proyecto.
Si usa MinGW/gcc, siga el Makefile o las instrucciones proporcionadas por el proyecto.

En tercer lugar, genere el archivo .EFI.

El punto clave aquí es confirmar la arquitectura de destino. Una PC común suele ser x86_64, es decir, un entorno UEFI de 64 bits.

Cuarto, coloque el archivo .EFI en algún lugar al que pueda acceder UEFI Shell.

En una máquina real, esto normalmente significa preparar una partición FAT32 o una unidad USB.
Con QEMU, puede montar un directorio o una imagen de disco.

Quinto, ejecútelo en UEFI Shell.

El resultado suele ser un resultado mínimo, como un mensaje estilo Hola mundo.

Donde los principiantes suelen quedarse estancados

La parte más difícil de compilar un programa UEFI no suele ser el lenguaje C en sí, sino el entorno y el proceso de vinculación.

Los problemas comunes incluyen:

Arquitectura de compilador incorrecta
Formato de destino incorrecto
Parámetros del enlazador incompletos
Falta el punto de entrada UEFI
Generar un ejecutable ordinario en lugar de un .EFI cargable por UEFI
QEMU u OVMF no configurados correctamente
Arranque seguro en una máquina real que bloquea un programa no firmado

Los errores del vinculador son especialmente fáciles de malinterpretar como problemas de código.
En muchos casos, el verdadero problema es la función de entrada, el subsistema, la arquitectura de destino o el script del vinculador.

Entonces, en la primera etapa, no se apresure a entrar en una lógica compleja. Asegúrese de que el ejemplo original se pueda compilar y ejecutar, luego cambie la salida poco a poco.

¿Por qué utilizar QEMU + OVMF para realizar pruebas?

Es posible probar programas UEFI en una máquina real, pero no es conveniente en la etapa principiante.

Es posible que tengas que repetir este ciclo:

compilar
Copiar a una unidad USB
Reiniciar
Ingrese al UEFI Shell
Ejecutar el programa
Registra el error
Regresar al sistema y modificar el código.

Ese bucle es lento.

QEMU + OVMF le permite simular un entorno UEFI directamente dentro del sistema operativo. Puede verificar si un archivo .EFI se carga más rápidamente y es menos probable que afecte sus entradas de arranque reales.

Una vez que el programa funciona básicamente, probarlo en una máquina real es mucho más manejable.

¿Qué deberían modificar primero los principiantes?

Si ya ha compilado su primer .EFI con el proyecto de ejemplo, no salte a funciones complejas de inmediato.

Un mejor orden es:

Cambie primero el texto de salida para confirmar que la recompilación realmente surte efecto.
Intente leer información sencilla proporcionada por UEFI.
Comprender la función de entrada, protocolo de salida y servicios básicos.
Luego considere funciones más complejas, como sistemas de archivos, salida gráfica o administración de entradas de arranque.

Este enfoque hace que cada paso sea verificable.
Si cambia demasiado a la vez, resulta difícil saber si el problema está en el código, el proceso de compilación o el entorno de ejecución.

¿En qué se diferencia de un programa C normal?

Aunque los programas UEFI se pueden escribir en C, su entorno de ejecución es completamente diferente al de los programas C normales.

Un programa C normal normalmente se ejecuta dentro de un sistema operativo y puede depender de la biblioteca, el sistema de archivos, el modelo de proceso y las llamadas al sistema estándar.

Un programa UEFI se ejecuta antes de que se inicie el sistema operativo. Se basa en los servicios proporcionados por el firmware UEFI. Muchas cosas a las que está acostumbrado en los programas normales no están disponibles aquí automáticamente. Al escribir programas UEFI, es necesario adaptarse a varias diferencias:

La función de entrada es diferente.
La salida funciona de manera diferente
Las bibliotecas disponibles son diferentes.
El acceso a la memoria y a los archivos funciona de forma diferente
La depuración funciona de manera diferente

Es por esto que partir de un ejemplo mínimo es mejor que escribir código como si fuera un programa C normal.

Un camino de aprendizaje práctico

Para principiantes, un camino realista es el siguiente:

Paso 1: compilar uefi-simple
Paso 2: Ejecútelo con QEMU + OVMF
Paso 3: Modificar la salida de Hola Mundo
Paso 4: Comprenda cómo UEFI Shell carga .EFI
Paso 5: aprenda la función de entrada UEFI y el protocolo de salida básico
Paso 6: Luego lea EDK II o material de desarrollo UEFI más completo

El objetivo de este camino es construir primero un circuito de retroalimentación que funcione.

Una vez que pueda generar un .EFI desde la fuente y ver el resultado en un entorno UEFI, ya habrá cruzado el primer umbral más difícil.

Referencias

-pbatard/uefi-simple

[Zhihu: material de compilación del programa UEFI] (https://zhuanlan.zhihu.com/p/643704056)

Pensamiento final

La parte difícil de compilar su primer programa UEFI generalmente no es escribir un poco de código C, sino conectar la cadena de herramientas, el formato de enlace y el entorno de ejecución.

No se apresure a utilizar funciones complejas.
Comience con un ejemplo mínimo como “uefi-simple”, obtenga primero un “.EFI” ejecutable y luego comprenda gradualmente los puntos de entrada, protocolos y métodos de compilación de UEFI.

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.

Codex está empezando a controlar la computadora. ¿Qué significa eso para el futuro?

Wed, 29 Apr 2026 11:28:25 +0800

La parte más importante de esta actualización del Codex no es que agregó otro botón común y corriente. Es que el Codex está empezando a avanzar hacia “controlar la computadora”.

En el pasado, usar IA generalmente significaba hacer preguntas en un cuadro de chat, copiar, pegar y luego operar manualmente el software.
Ahora ese límite se está ampliando: la IA no solo te responde. Puede operar aplicaciones de escritorio según su objetivo.

A corto plazo, esta es una característica nueva. A largo plazo, puede cambiar la cantidad de personas que usan computadoras.

¿Qué es esta característica?

En pocas palabras, la capacidad de uso de computadoras de Codex le permite acceder y operar el entorno de escritorio.

Puede hacer cosas como:

seleccionar y controlar una aplicación
recibir tareas en lenguaje natural
abrir navegadores, herramientas de inteligencia artificial, archivos locales u otro software
ingrese texto, haga clic en botones y espere resultados
conectar varios pasos en una tarea
seguir ejecutándose en segundo plano sin necesidad de que el usuario siga cada paso manualmente

Su función no es solo escribir un texto para usted, sino también completar un flujo de operación para usted.

Esa es la diferencia clave entre un Agente y un chatbot común y corriente:
un chatbot da principalmente respuestas; un Agente está más cerca de “recibir un objetivo y luego ejecutarlo”.

Por qué esto es importante

En el pasado, gran parte de la automatización requería que supieras escribir guiones.

Por ejemplo, supongamos que desea completar un flujo de trabajo entre software:

abrir una página web
encontrar información
copiar contenido
pásalo a otra herramienta de IA
guardar un archivo
abre el directorio local y comprueba el resultado

Para automatizar esto de forma tradicional, es posible que necesite scripts de navegador, API, programas locales e incluso automatización de ventanas.

Pero muchos usuarios comunes y corrientes no saben cómo escribir estas cosas.
Incluso si lo hacen, puede que no valga la pena escribir un guión para una tarea temporal.

Aquí es donde importa el uso de la computadora: empuja la “capacidad similar a un script” hacia el lenguaje natural.

No es necesario que le diga exactamente dónde hacer clic.
Puede decirle qué resultado desea y dejar que intente completar la tarea.

Flujos de trabajo que pueden cambiar

Creo que los primeros flujos de trabajo que cambiarán no serán trabajos extremadamente serios o de alto riesgo, sino tareas molestas, fragmentadas, repetitivas y para las que no vale la pena escribir un programa dedicado.

1. Mover información a través del software

El caso más típico es el de mover información entre aplicaciones.

Anteriormente, podía alternar entre un navegador, un documento, una ventana de chat y una carpeta local.
En el futuro, podrás encargar este tipo de tarea a un Agente:

encontrar cierto tipo de información
resumirlo en un documento
guárdelo en un directorio específico
abre el resultado para que lo revises

Este trabajo no es difícil, pero requiere atención.
El valor de un Agente es que absorbe estas pequeñas operaciones.

2. Coordinación entre múltiples herramientas de IA

El flujo de trabajo real de muchas personas ya no se basa en una única herramienta de inteligencia artificial.

Puede verse así:

una herramienta escribe código
una herramienta busca información
una herramienta genera imágenes
una herramienta organiza documentos

Anteriormente, estas herramientas se conectaban mediante copiar y pegar manualmente.
En el futuro, un Agente puede convertirse en la capa intermedia: abre herramientas, pasa contexto, espera resultados y organiza resultados. Esto puede convertir “múltiples herramientas de IA trabajando juntas” de un proceso manual a un proceso semiautomático.

3. Automatización del software de oficina

Las hojas de cálculo, las presentaciones, los documentos y el correo electrónico comparten una característica: son potentes, pero muchas operaciones están fragmentadas.

Si los agentes pueden controlar este software de forma fiable, la barrera a la automatización de oficinas disminuirá notablemente.

No es necesario recordar dónde está un menú ni aprender atajos complicados.
Solo necesitas describir el objetivo, como por ejemplo:

convierta esta hoja de cálculo en un informe mensual
hacer un resumen de una página de este documento
combinar estos materiales en una explicación claramente estructurada

Las tediosas operaciones de los botones quedarán gradualmente ocultas detrás del lenguaje natural.

Qué significa para los usuarios comunes

Para los usuarios comunes, este tipo de característica puede tener un impacto más directo que “el modelo se volvió un poco más inteligente”.

Porque reduce la barrera operativa, no sólo la barrera del conocimiento.

Muchas personas pueden describir lo que quieren, pero no saben dónde hacer clic o cómo combinar funciones dentro del software.
Si los Agentes pueden hacerse cargo de esta parte, el uso de una computadora puede convertirse en:

1
2
3

I describe the goal
Agent operates the software
I check the result

Esto está más cerca de la productividad real que un simple chat.

Su impacto en el software

Si este tipo de capacidad del Agente continúa madurando, el software en sí también se verá afectado.

En el pasado, el diseño de software se basaba principalmente en el clic humano.
En el futuro, es posible que también sea necesario que el software sirva para la operación del Agente.

Esto significa:

los elementos de la interfaz deben ser más claros
la retroalimentación de operación debe ser más estable
los permisos locales deben ser más granulares
el software puede proporcionar interfaces más adecuadas para las llamadas de los agentes
A los usuarios les puede interesar más si la IA puede operar el software sin problemas

A largo plazo, los límites entre las aplicaciones pueden volverse más delgados.
Es posible que a los usuarios les importe menos “qué aplicación debo abrir” y más “qué tarea quiero completar”.

No lo exageres todavía

Por supuesto, todavía no es momento de dejarlo ir por completo.

Este tipo de capacidad todavía tiene varias limitaciones claras:

la estabilidad aún necesita observación
las tareas complejas pueden fallar en el medio
los límites de los permisos deben manejarse con cuidado
Las operaciones de eliminación de cuentas, pagos y archivos no deben delegarse a la ligera.
el consumo de cuotas no es algo que puedas ignorar por completo

Entonces, en esta etapa, el mejor caso de uso es no dejar que se haga cargo de toda la computadora, sino permitir que maneje tareas de bajo riesgo, revisables y con muchos pasos.

Por ejemplo:

organización de materiales
generar borradores
mover contenido entre herramientas
abrir y comprobar archivos
ejecutar flujos de trabajo semiautomáticos que pueden ser revisados por un humano

Una última línea

La verdadera importancia de esta actualización del Codex es que empuja a la IA de “responder preguntas” a “operar el entorno”.

A corto plazo, es una característica del uso de la computadora.
A largo plazo, puede marcar un cambio en la forma en que se utilizan las computadoras personales.

En el futuro, es posible que dediquemos menos tiempo a recordar botones, buscar menús y cambiar de ventana.
Más a menudo, describiremos el objetivo, dejaremos que un Agente lo ejecute y luego dejaremos que los humanos tomen el juicio final.

¿Por qué existe una habilidad del Codex en el directorio pero aún no aparece?

Wed, 29 Apr 2026 11:18:00 +0800

Este problema era fácil de pasar por alto: varias habilidades ya estaban ubicadas en ~/.codex/skills, pero después de abrir un nuevo hilo del Codex, la barra lateral todavía mostraba solo un pequeño subconjunto de ellas.

Al principio, parecía un problema de caché o de indexación. La causa real fue más específica: varios archivos SKILL.md comenzaron con una lista de materiales UTF-8. El cargador de habilidades de Codex 0.111.0 no omitió esa secuencia de bytes, por lo que calculó erróneamente que los archivos no tenían contenido YAML válido.

Síntoma

El directorio local contenía estas habilidades:

~/.codex/skills/git-commit-push/SKILL.md
~/.codex/skills/hugo-rsync-deploy/SKILL.md
~/.codex/skills/bilibili-speech-transcriber/SKILL.md
~/.codex/skills/product-cutout-normalize/SKILL.md

Pero después de abrir un hilo nuevo, las habilidades realmente expuestas fueron solo:

1
2

bilibili-speech-transcriber
product-cutout-normalize

En otras palabras, un archivo existente en el disco no significa que la sesión actual pueda cargarlo correctamente. Codex analiza primero la portada de cada SKILL.md. Si el análisis falla, esa habilidad se excluye directamente.

Investigación

Iniciar una nueva sesión con codex exec mostró un error más directo. En VS Code u otros IDE, es posible que estos registros no sean visibles:

1
2

failed to load skill C:\Users\knightli\.codex\skills\git-commit-push\SKILL.md: missing YAML frontmatter delimited by ---
failed to load skill C:\Users\knightli\.codex\skills\hugo-rsync-deploy\SKILL.md: missing YAML frontmatter delimited by ---

Visualmente, estos archivos parecían tener un encabezado normal:

---
name: post-rewrite
description: ...
---

El verdadero problema estaba en el nivel de bytes.

El comienzo de un archivo fallido fue:

`1`	`EF-BB-BF-2D-2D-2D`

El comienzo de un archivo que se cargó correctamente fue:

`1`	`2D-2D-2D`

2D-2D-2D es ---. El EF-BB-BF anterior es la lista de materiales UTF-8.

Causa

En Codex 0.111.0, el cargador de habilidades espera que el primer byte de SKILL.md sea el primer - en ---.

Si el archivo comienza con una lista de materiales UTF-8, el comienzo real será:

`1`	`BOM + ---`

Entonces, el cargador piensa que el archivo no comienza con el delimitador inicial e informa:

`1`	`missing YAML frontmatter delimited by ---`

El contenido de la habilidad no era incorrecto y el directorio tampoco era incorrecto. Un pequeño detalle de codificación impidió que el analizador reconociera el archivo.

Arreglar

Convierta los archivos SKILL.md afectados a UTF-8 sin BOM.

En PowerShell, esto se puede hacer así:

$paths = @(
  'C:\Users\knightli\.codex\skills\git-commit-push\SKILL.md',
  'C:\Users\knightli\.codex\skills\hugo-rsync-deploy\SKILL.md',
)

$utf8NoBom = New-Object System.Text.UTF8Encoding($false)

foreach ($p in $paths) {
  $text = [IO.File]::ReadAllText($p, [Text.Encoding]::UTF8)
  [IO.File]::WriteAllText($p, $text, $utf8NoBom)
}

Después del procesamiento, el encabezado del archivo debería cambiar de:

`1`	`EF-BB-BF-2D-2D-2D`

`1`	`2D-2D-2D`

Verificación

Después de reiniciar una sesión del Codex, las habilidades visibles se restauraron en:

git-commit-push-zh
hugo-rsync-deploy
bilibili-speech-transcriber
product-cutout-normalize

Si la barra lateral todavía muestra la lista anterior, cierre la barra lateral o ventana actual del Codex y vuelva a abrir el proyecto. La lista de habilidades generalmente se carga cuando comienza la sesión, por lo que es posible que los cambios realizados en mitad de una sesión no se actualicen inmediatamente.

Una última línea

Este tipo de problema es fácil de confundir con “El Codex no se volvió a indexar” o “la habilidad no se instaló correctamente”.

Al solucionar problemas, verifique primero estas tres cosas:

si SKILL.md está realmente en el directorio correcto
si el archivo tiene un texto inicial --- válido en la parte superior
si el archivo es UTF-8 sin BOM

La clave en este caso fue el tercer punto: el archivo se veía bien, pero su primer byte no era “-”, por lo que Codex no lo trató como una habilidad válida.

¿Cuál es la diferencia entre ~/.codex/skills y Project .codex/skills en Codex?

Wed, 29 Apr 2026 11:08:00 +0800

Al organizar las habilidades del Codex, la gente suele quedarse estancada en dos preguntas:

¿Cuál es la diferencia entre ~/.codex/skills y project/.codex/skills?
¿Por qué existe una habilidad en el directorio pero no aparece en la sesión actual?

Aquí está la versión corta.

La diferencia

La forma más sencilla de recordarlo:

~/.codex/skills es tu biblioteca de habilidades global
project/.codex/skills es la biblioteca de habilidades local para ese repositorio

`~/.codex/skills`

Úselo para:

Habilidades que reutilizas personalmente en todos los proyectos.
flujos de trabajo generales que no están vinculados a un repositorio específico
flujos de trabajo que claramente pertenecen a sus propios hábitos

Por ejemplo:

post-reescritura
post-traducir -git-commit-push -hugo-rsync-deploy
bilibili-transcriptor-de-voz

El rasgo clave de este tipo de habilidad es: todavía tiene sentido fuera del proyecto actual.

`proyecto/.codex/skills`

Úselo para:

flujos de trabajo que solo se aplican a este repositorio
reglas estrechamente acopladas a la estructura, scripts o plantillas del proyecto actual
Habilidades que deben ser compartidas por el equipo.

Por ejemplo:

un flujo de trabajo de publicación específico para este repositorio
una plantilla de generación que solo funciona en este proyecto
pasos de automatización estrechamente vinculados a scripts de proyectos privados

El rasgo clave de este tipo de habilidad es: deja de ser significativo una vez que sale de este repositorio.

Cuándo utilizar habilidades globales y cuándo utilizar habilidades de proyecto

Esta regla general es suficiente:

Si se trata de tus hábitos personales, ponlo en ~/.codex/skills
Si se trata de reglas del repositorio, colóquelo en project/.codex/skills
Si se puede reutilizar en todos los proyectos, prefiera global
Si debe ser compartido por varias personas y evolucionar con el repositorio, prefiera el nivel de proyecto

El repositorio actual

Basado en el estado actual:

su máquina tiene ~/.codex/skills
este repositorio no tiene .codex/skills

Así que ahora mismo dependes principalmente de las habilidades globales.

Eso significa que flujos de trabajo como “post-reescritura”, “post-traducción” y “git-commit-push” son actualmente más bien parte de su flujo de trabajo personal, no algo incluido explícitamente con este repositorio.

Por qué existe una habilidad en el disco pero puede no aparecer en la sesión actual

Hay dos cosas diferentes aquí:

Existente en el disco: el archivo de habilidad existe en un directorio local
Expuesto a la sesión: la sesión actual lo registró en la lista de habilidades disponibles

Estos no son lo mismo.

Entonces esto puede suceder:

ya existe una habilidad en ~/.codex/skills
pero no aparece en la lista después de /

Por lo general, esto no significa que la habilidad esté rota. Más a menudo significa: la sesión actual no la ha vuelto a indexar.

Cómo hacer que una habilidad esté disponible en la sesión actual

La lista de verificación práctica es breve.

1. Colóquelo en el directorio correcto

Mundiales:

`1`	`~/.codex/skills/<skill-name>/SKILL.md`

Nivel de proyecto:

`1`	`project/.codex/skills/<skill-name>/SKILL.md`

2. Haga que el encabezado `SKILL.md` sea reconocible

Como mínimo, necesita:

---
name: your-skill-name
description: What this skill does
---

3. Abra una nueva sesión después de crearla o editarla

En muchos casos, una habilidad no aparece porque la sesión actual ya fijó su lista de habilidades disponibles cuando comenzó.

Entonces, si crea una habilidad en medio de una sesión, es posible que ya exista en el disco, pero es posible que esta sesión no la reconozca.

El flujo de trabajo más confiable es:

Ponga en práctica la habilidad
Finalizar la sesión actual
Vuelva a ingresar al proyecto.
Abre una nueva sesión
Compruebe si aparece debajo de /

4. Implemente las habilidades para el proyecto antes de comenzar

Si desea que project/.codex/skills se reconozca de manera más confiable, coloque esas habilidades en el proyecto antes de ingresar al repositorio e iniciar la sesión.

Una última línea

La conclusión más corta es:

~/.codex/skills es tu biblioteca de habilidades personales
project/.codex/skills es la biblioteca de reglas local del repositorio
una habilidad existente en el directorio no significa que la sesión actual siempre la mostrará
la solución más común es colocarlo en el directorio correcto, escribir un SKILL.md válido y luego iniciar una nueva sesión