Necesito sacarme algo del pecho. 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 secundarios. Me encantaba lo simple que era y lo rápido que podía sentirme productivo. El punto clave para mí fue desarrollar mi propio conjunto de habilidades que convirtieron a cc en casi cualquier cosa que quisiera. Incluso empecé a desarrollar mi propia herramienta de orquestación de agentes sobre él.
Durante mi entrevista presencial, usé Cursor durante 2 días para construir el proyecto de la entrevista. Esto fue antes del lanzamiento de Cursor 3, así que usaba la Ventana del Editor. He usado vscode durante tantos años que la mayoría de los atajos de teclado seguían en mi ventana de contexto, por lo que volver al IDE no fue tan difícil. No puedo mentir, sin embargo. Durante la primera o dos horas, ciertamente extrañaba la cli. Hacer clic en las cosas se sentí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 - se sentí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 hablando maravillas de la revisión adversarial multi-modelo, así que poder hacer esto de forma nativa en la interfaz se sintió muy natural. Mejor aún era la capacidad de generar subagentes de diferentes modelos, para poder obtener lo mejor de ambos mundos en una sola 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, por lo que siempre estaba en un estado de vigilancia constante de mi contexto y uso del plan. Así que me sorprendió muchísimo lo rápido que era en Cursor. Tanto que básicamente nunca necesité mirar cuánto contexto estaba usando. Simplemente funcionaba, mientras que a menudo sentía que el modelo se volvía súper tonto después de la compactación en cc.
Y la tercera cosa que noté fue cuánto más podían ofrecer las GUI sobre las TUI. Poder abrir tu aplicación directamente en el navegador de Cursor y hacer cambios de diseño con el Modo Diseño se sintió intuitivo y me hizo pensar en cuánto las interfaces de usuario diseñadas para un propósito específico podrí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, y usándola como mi herramienta diaria. Si bien todavía pienso que cc es un producto genial con un gran equipo, he notado que su simplicidad tiende a llevar a las personas a querer construir sus propias abstracciones envolviéndolo. En mi último trabajo, sentí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 hackeable, que sea lo suficientemente abierta para que la gente pueda abusar de él para otros casos de uso. Luego ves cómo la gente abusa de él y luego construyes para eso."
¡Eso era exactamente! La gente convergiendo en herramientas de orquestación expone la demanda latente de que usar una cli simplemente 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 CLIs en una GUI perdía completamente el punto. El enfoque que me interesaba era construir confianza en los agentes.
Como ex gerente de ingeniería, rápidamente me di cuenta de que gestionar agentes se sentía similar a construir un equipo de ingeniería humano. Los nuevos empleados necesitan ser incorporados para que entiendan la base de código, pero también cómo se hace el trabajo. Se unen ya pre-entrenados con habilidades que adquirieron 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 aproximarse a eso. Son capaces pero estúpidos, y muy enseñables. Y vi sus modos de falla como oportunidades para enseñarles todo lo que sé sobre hacer ingeniería profunda y rigurosa.
Porque cuando no hay rigor, los agentes harán de manera servil lo que sea necesario para escribir ese código que pediste. Y vaya que pueden y escribirán mucho. La paralelización ingenua solo hace que escriban basura más rápido.
Si quieres ir rápido, primero ve profundo
Sí creo que la orquestación de agentes se puede hacer de manera productiva. Pero necesitamos ir primero en profundidad.
Estoy abriendo el código fuente 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 secundarios, 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 utilizadas 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 falla 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 de juego correcto a seguir para una tarea determinada. El objetivo no es la máxima cantidad de líneas de código, sino lo contrario: 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 excelente manera de abordar la depuración es buscar binariamente en el espacio del problema. Empiezas con algunas hipótesis de lo que podría estar pasando, y luego intentas descartarlas sistemáticamente hasta que puedas 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 agregar instrumentación o registros de consola para verificar el estado del programa mientras se ejecuta.
Estos pasos forman un manual de juego que puede ser utilizado por los agentes para depurar problemas a fondo en lugar de adivinar, que es lo que felizmente harán si se lo permites. pstack viene con muchas habilidades y manuales de juego que te permiten abordar la ingeniería de software con este mismo nivel de rigor. Actualmente tengo manuales de juego 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 funciones
- Paridad visual y prototipado
- Y más
Siempre que necesites rigor, antecede tu mensaje 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. utiliza tus MCPs disponibles para consultar cada categoría de evidencia en paralelo (control de versiones, rastreador de incidencias, documentación extensa, 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 estructuras de datos estén definidos 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 manera adversarial.
- /tdd: estás corrigiendo un error. escribe la prueba que falla primero, 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 de juego riguroso y auditable para la tarea.
- /show-me-your-work: quieres un rastro de decisiones revisable. registra las decisiones en un tsv que puedes confirmar.
Y finalmente, puedes crear tu propia habilidad de modo con /automate-me. Extrae tus transcripciones recientes, redacta una habilidad de tu-modo a partir de cómo has trabajado, y la enruta a través de pstack internamente.
pstack funciona con cualquier herramienta de codificación agéntica, pero funciona especialmente bien en herramientas multimodelo como Cursor. Muchas de las habilidades utilizan flujos de trabajo multimodelo para aprovechar las fortalezas y debilidades únicas de cada modelo. Es orquestación de agentes, pero aplicada primero en profundidad en lugar de en amplitud.
El cuello de botella con los agentes es la verificación. Los agentes pueden escribir una gran cantidad 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, necesitamos ir profundo y ser rigurosos. Creo que llegamos allí 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 ahora es una pesadilla con los agentes escribiendo todo el código. Los errores, problemas de rendimiento y 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 se pueden programar, o ejecutar en respuesta a eventos como nuevos mensajes en un canal de Slack. Un ejemplo de esto 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 de software. La idea es esta: si ahora tenemos la confianza para resolver problemas "de un solo golpe" 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. Usamos mucho Cursor internamente y, por lo tanto, recibimos muchos comentarios de los empleados sobre nuestras versiones candidatas. Benny entiende imágenes y archivos adjuntos de video, explora la base de código usando habilidades de pstack, y chatea con el reportero 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 se rompe.
Una vez triado, Benny crea un ticket con sus hallazgos al mirar el código, el historial de git para regresiones recientes de errores, Slack para otros mensajes sobre el mismo error, e incluso Notion para decisiones de diseño y producto sobre cómo debería funcionar una función: ¿es un error, o fue diseñado para funcionar de esta manera?
Después de que se presenta el ticket, otro bot Benny lo recoge usando otra habilidad que creé llamada /orchestrate.
Primero, intenta reproducir el problema mediante el uso de la computadora. Los Agentes en la Nube 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 mediante programación 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 solucionarlo. Si es un problema de rendimiento, Benny puede tomar trazas de CPU y capturas de montón antes y después. Los subplanificadores generan más trabajadores para verificar la corrección usando habilidades de pstack y verificando el trabajo contra el ticket si se solucionó.
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 muchísimo más trabajo 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 funciones 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 haga cargo de un problema de principio a fin, incluida la verificación, no puedes automatizar tus procesos. A medida que aumentas la confianza usando plugins como pstack que le dan a tus agentes más profundidad de ingeniería, puedes comenzar a abordar problemas más ambiciosos. Intentar paralelizar agentes en los que aún no confías es un gran desperdicio de tokens e introduce más basura en tu base de código.
¡Gracias por leer!
