Necesito desahogarme. Antes de mi entrevista en @cursor_ai, nunca había usado Cursor.
En Meta, Claude Code estaba explotando. Incluso pagué un plan personal de $200 al mes para mis proyectos paralelos. Me encantaba lo simple que era y lo rápido que podía sentirme productivo. El punto clave para mí era desarrollar mi propio conjunto de habilidades que convirtieran a cc en casi cualquier cosa que quisiera. Incluso empecé a desarrollar mi propia herramienta de orquestación de agentes encima de él.
Durante mi entrevista presencial, usé Cursor durante dos días para construir el proyecto de la entrevista. Esto fue antes del lanzamiento de Cursor 3, así que estaba usando la ventana del editor. He estado usando VSCode durante tantos años que la mayoría de los atajos de teclado todavía estaban en mi ventana de contexto, así que volver al IDE no fue demasiado difícil. Pero no voy a mentir, durante la primera o dos horas ciertamente extrañaba la CLI. Hacer clic en las cosas me parecía casi bárbaro. Pero hubo algunas cosas que realmente me llamaron la atención.
Primero, los modelos que solía usar en ese momento —Opus y Codex— parecían más inteligentes, de alguna manera. Y era increíble poder cambiar de modelo sobre la marcha y usar ambos al mismo tiempo en diferentes partes de mi proyecto (Opus para el frontend, Codex para sistemas). Antes de mi entrevista, ya estaba alabando la revisión adversarial multimodelo, así que poder hacer esto de forma nativa en la interfaz se sintió muy natural. Aún mejor era la capacidad de generar subagentes de diferentes modelos, para obtener lo mejor de ambos mundos en una misma conversación.
Segundo, la compactación era increíblemente rápida. Como usuario de cc, estaba acostumbrado a que la compactación tomara muchos minutos, así que siempre estaba en un estado de vigilancia constante de mi contexto y uso de planes. Por eso me sorprendió muchísimo lo rápida que era en Cursor. Hasta el punto de que prácticamente nunca necesité mirar cuánto contexto estaba usando. Simplemente funcionaba, mientras que en cc a menudo sentía que el modelo se volvía súper tonto después de compactar.
Y la tercera cosa que noté fue cuánto más podían ofrecer las GUI frente a las TUI. Poder abrir tu aplicación directamente en el navegador de Cursor y hacer cambios de diseño con Design Mode se sentía intuitivo y me hizo pensar en cuánto las interfaces creadas para un propósito específico podían hacer que la codificación agéntica fuera más efectiva.
Construyendo Cursor con Cursor
Desde que me uní a finales de marzo, he estado trabajando principalmente en la ventana de agente de Cursor 3, usándola como mi herramienta diaria. Aunque todavía creo que cc es un producto interesante con un gran equipo, he notado que su simplicidad tiende a llevar a la gente a querer construir sus propias abstracciones envolviéndolo. En mi último trabajo, parecía que cada semana se anunciaba una nueva herramienta de orquestación interna construida sobre cc.
@bcherny habla mucho sobre esta idea de "demanda latente":
"Hay una idea muy antigua en productos llamada demanda latente... construyes un producto de una manera que sea pirateable, que sea lo suficientemente abierta para que la gente pueda abusar de él para otros casos de uso. Luego observas cómo la gente abusa de él y entonces construyes para eso."
¡Exactamente eso! Que la gente converja en herramientas de orquestación expone la demanda latente: usar una CLI te convierte a ti, el humano, en el orquestador.
Pero cada flujo de trabajo de agente que había usado se centraba en lo incorrecto. Ejecutar múltiples CLI en una GUI perdía completamente el sentido. El enfoque que me interesaba era construir confianza en los agentes.
Como exgerente de ingeniería, rápidamente me di cuenta de que gestionar agentes se sentía similar a construir un equipo humano de ingeniería. Los nuevos empleados necesitan ser incorporados para que entiendan la base de código, pero también cómo se hace el trabajo. Llegan ya entrenados con habilidades adquiridas de sus experiencias pasadas: cómo depurar, cómo escribir código y pruebas de alta calidad, y cómo comunicarse, por nombrar algunas.
Los agentes son como nuevos empleados en un estado constante de amnesia e idiotez. No recuerdan lo que les dices, y nunca aprenden realmente nada nuevo. Pero podemos equiparlos con reglas, habilidades, herramientas y memoria a largo plazo que pueden aproximar eso. Son capaces pero estúpidos, y muy enseñables. Y vi sus modos de fallo como oportunidades para enseñarles todo lo que sé sobre ingeniería profunda y rigurosa.
Porque cuando no hay rigor, los agentes harán servilmente cualquier cosa para escribir ese código que les pediste. Y vaya si pueden y lo harán, escribiendo muchísimo. La paralelización ingenua solo hace que escriban código de baja calidad más rápido.
Si quieres ir rápido, primero profundiza
Creo que la orquestación de agentes puede hacerse de manera productiva. Pero necesitamos ir primero en profundidad.
Estoy abriendo el código de pstack, mi conjunto personal de habilidades y principios de ingeniería que uso todos los días para construir @cursor_ai. Empecé a desarrollar iteraciones tempranas de estas habilidades en mis proyectos paralelos, y las he estado refinando desde entonces.
Consíguelo aquí: https://cursor.com/marketplace/cursor/pstack
Estas habilidades se han convertido en algunas de las más usadas por el equipo de Cursor, así que estoy emocionado de compartirlas con todos ustedes.
pstack enseña a los agentes a ser más rigurosos usando múltiples modelos. He tomado todos los modos de fallo que he observado y los he convertido en habilidades. El corazón del plugin es /poteto-mode, que es una habilidad de orden superior que les da a los agentes el manual correcto a seguir para una tarea determinada. El objetivo no es la máxima cantidad de líneas de código, sino lo contrario: el máximo impacto con la menor cantidad de código.
El rigor se aplica abordando los problemas de la misma manera que lo hacen los ingenieros experimentados. Por ejemplo, una gran manera de abordar la depuración es buscar de forma binaria en el espacio del problema. Empiezas con algunas hipótesis de lo que podría estar pasando, y luego intentas descartarlas sistemáticamente hasta acercarte a la verdadera causa raíz. Si es difícil de reproducir, podrías intentar forzar sintéticamente que ocurra el error. O podrías intentar añadir instrumentación o registro en consola para verificar el estado del programa mientras se ejecuta.
Estos pasos forman un manual que los agentes pueden usar para depurar problemas a fondo en lugar de adivinar, algo que están felices de hacer si se lo permites. pstack viene con muchas habilidades y manuales que te permiten abordar la ingeniería de software con este mismo nivel de rigor. Actualmente tengo manuales para:
- Creación de habilidades y evaluaciones
- Trabajo autónomo
- Corrección de errores y análisis forense en tiempo de ejecución
- Desarrollo de funcionalidades
- Paridad visual y prototipado
- Y más
Siempre que necesites rigor, prefija tu prompt con /poteto-mode. Por ejemplo:
También puedes invocar opcionalmente bajo demanda las otras habilidades:
- /how: quieres un recorrido de cómo funciona realmente un subsistema.
- /why: quieres saber por qué algo se construyó de esta manera. usa tus MCP disponibles para consultar cada categoría de evidencia en paralelo (control de versiones, rastreador de incidencias, documentación larga, chat en tiempo real, observabilidad de infraestructura, seguimiento de errores, almacén de análisis).
- /architect: estás a punto de escribir código que cruza un límite de función y quieres que los tipos y las estructuras de datos se resuelvan primero.
- /arena: quieres N intentos paralelos de lo mismo, y luego tomar las mejores partes de cada uno.
- /interrogate: quieres que diferentes modelos revisen algo de forma adversarial.
- /tdd: estás arreglando un error. escribe primero la prueba que falla, luego la corrección.
- /unslop: estás limpiando cualquier tipo de escritura de IA. hace que hablen de manera sencilla.
- /reflect: quieres mejorar continuamente tus habilidades después de conversaciones largas.
- /figure-it-out: ¿haciendo algo inusual? diseña un manual riguroso y auditable para la tarea.
- /show-me-your-work: quieres un rastro de decisiones revisable. registra las decisiones en un archivo tsv que puedes confirmar.
Y finalmente, puedes crear tu propia habilidad de modo con /automate-me. Extrae tus transcripciones recientes, redacta una habilidad "tu-modo" a partir de cómo has trabajado, y la enruta a través de pstack por debajo.
pstack funciona con cualquier herramienta de codificación agéntica, pero funciona especialmente bien en herramientas multimodelo como Cursor. Muchas de las habilidades usan flujos de trabajo multimodelo para aprovechar las fortalezas y debilidades únicas de cada modelo. Es orquestación de agentes, pero aplicada en profundidad antes que en amplitud.
El cuello de botella con los agentes es la verificación. Los agentes pueden escribir grandes cantidades de código rápidamente. Asegurarse de que todo sea correcto es extremadamente difícil. Cuando puedas llegar allí, la verdadera paralelización de agentes, como en una fábrica oscura para software, podría ser posible.
Pero primero, debemos ir en profundidad y ser rigurosos. Creo que llegaremos ahí aumentando la confianza.
Prueba pstack y cuéntame qué te parece.
Zen y el arte del mantenimiento de software
Estas habilidades me ayudan a moverme con más confianza al escribir código. Pero mantener el código es ahora una pesadilla con los agentes escribiendo todo el código. Los errores, los problemas de rendimiento y las solicitudes de funciones aún toman tiempo para resolverse. ¡Y ahora hay mucho más!
Hago un uso extensivo de las automatizaciones de Cursor en Cursor. Son agentes en la nube que pueden programarse o ejecutarse en respuesta a eventos como nuevos mensajes en un canal de Slack. Un ejemplo es mi bot Benny. Le he dado las mismas habilidades que tengo en pstack.
Benny sigue siendo un trabajo en progreso, pero mi visión es automatizar tanto como sea posible el proceso de mantenimiento del software. La idea es esta: si ahora tenemos la confianza para "resolver de un solo tiro" la mayoría de los problemas con pstack, con un buen grado de certeza de que la calidad del PR es alta, seguramente también podemos automatizar la retroalimentación.
Esta fábrica comienza su vida con el triaje: recopilando información de los empleados sobre informes de errores. Comemos nuestro propio alimento probando Cursor internamente, así que recibimos mucha retroalimentación de los empleados sobre nuestros candidatos a lanzamiento. Benny entiende imágenes y archivos adjuntos de video, explora la base de código usando las habilidades de pstack, y conversa con el informante para obtener información sobre los pasos de reproducción si no está claro.
Esta es una parte importante del proceso de reporte de errores. Sin pasos de reproducción claros y una comprensión de lo que está roto, los agentes solo pueden adivinar la solución. Necesitamos darles una comprensión clara de exactamente dónde y cómo falla.
Una vez triado, Benny crea un ticket con sus hallazgos al revisar el código, el historial de git en busca de regresiones recientes de errores, Slack en busca de otros mensajes sobre el mismo error, e incluso Notion para decisiones de diseño y producto sobre cómo debería funcionar una característica: ¿es un error, o fue diseñado para funcionar así?
Después de que se registra el ticket, otro bot Benny lo recoge usando otra habilidad que creé llamada /orchestrate.
Primero, intenta reproducir el problema mediante el uso de computadora. Los Cloud Agents de Cursor pueden ejecutar Cursor en la nube, donde interactúan con el escritorio, hacen clic en cosas y envían entrada de teclado. Internamente, esto usa más habilidades que hice para controlar nuestros productos programáticamente usando protocolos como CDP o equivalente.
Esto nos permite demostrar si el informe de error se puede reproducir. Si reproduce el error de manera consistente, entonces intenta arreglarlo. Si es un problema de rendimiento, Benny puede tomar trazas de CPU y capturas de heap antes y después. Subplanificadores generan más trabajadores para verificar la corrección usando las habilidades de pstack y verificando el trabajo contra el ticket si se arregló.
Se generan trabajadores adicionales en esta ejecución para tomar un video del antes y después, y finalmente un trabajador abre el PR para revisión con el video en la descripción.
Todo esto sigue siendo un trabajo en progreso y hay mucho más por hacer, pero estoy emocionado de tener un equipo de agentes para ayudarme a corregir errores con confianza mientras duermo o hago otras cosas. Hacer que la revisión de código sea escalable es otra área importante, y creo que Cursor tendrá algunas características interesantes próximamente para ayudar.
Pero la clave para construir tu propia fábrica de software es la confianza. A menos que puedas confiar en que un agente se encargue de un problema de principio a fin, incluyendo la verificación, no puedes automatizar tus procesos. A medida que aumentas la confianza usando plugins como pstack que dan a tus agentes más profundidad en ingeniería, puedes empezar a abordar problemas más ambiciosos. Intentar paralelizar agentes en los que todavía no confías es un enorme desperdicio de tokens e introduce más código de baja calidad en tu base de código.
¡Gracias por leer!
