Hay una manera de hacerlo. Hay una manera de hacer todo. La siguiente pregunta es ¿cuál es tu prompt de apertura favorito? Oh, está bien. Entonces, doy mucha información de fondo, así que diría, como, estoy tratando de resolver este problema en particular, y necesitamos discutir cómo podemos resolver esto. Me gusta tener un enfoque realmente colaborativo con un agente. De hecho, uno de mis modificadores favoritos, no responde completamente a la pregunta, pero uno de mis modificadores favoritos para cualquier prompt es cualquier pregunta. En casi cada prompt que hago, si es ligeramente ambiguo, o podría ser ligeramente ambiguo, simplemente añado al final cualquier pregunta, y usualmente, habrá preguntas. De lo contrario, usualmente no hay preguntas, y tu agente hará una suposición. Así que, supongo, el prompt de apertura favorito es solo lo normal, pero luego ese modificador es genial. Sí, seguro.
Bien, tenemos una pregunta de costo que es ¿cómo escalaría esto en términos de uso de tokens en proyectos de larga duración? Entonces, lo que acabo de hablar con la otra pregunta es que tu delta describe el comportamiento de tu sistema, y lo que está sucediendo. Tuve esta pregunta recientemente, de hecho, en una masterclass que dirigí, y mi sugerencia fue idear una manera de ignorar ciertas especificaciones más antiguas dentro de tu agente, así que podrías, por supuesto, limpiar tus especificaciones archivadas más antiguas, pero haría como un archivo de ignorar clawed o cursor para tal vez ignorar cosas que no necesitaba. Pero por lo que he visto, incluso para proyectos de larga duración, no ves tanto uso de tokens porque tu modelo no mirará inmediatamente dentro de tu archivo, mirará en tus especificaciones delta donde tienes esa versión mucho más comprimida. Depende del framework, pero mi consejo es siempre monitorear esto a medida que avanzas, y corregir el rumbo, pero nunca es algo que no podrías corregir en el futuro.
Sobre un tema similar, alguien ha preguntado, ¿crees que sería útil o beneficioso identificar las partes de las especificaciones con la mayor inercia de cambio para ayudar a evitar tomar malas decisiones que sean difíciles de corregir más adelante? Sí, no sé cómo harías eso, pero es una gran idea, sí. A medida que escala, querrías ser selectivo, y sí, no sé cómo responderlo. Siento que eso depende mucho del contexto, y la respuesta correcta dependerá de muchas variables diferentes. Sí, seguro. Así que hoy, el porqué detrás de un trabajo de características usualmente existe en Slack, Linear, o Jira, y otras fuentes de contexto. ¿Por qué serían mejores las especificaciones colaborativas que cualquiera de estas otras fuentes colaborativas? ¿Diferente a Jira y Slack y cosas así? Supongo que es principalmente porque viven junto a tu base de código, y creo que es muy fácil perder el contexto en otros lugares. Si todavía estuviéramos, ya sabes, imaginemos un mundo donde no estamos usando IA, y todos estamos escribiendo código a mano, nos hemos ralentizado mucho, obviamente podemos monitorear la salida porque estamos escribiendo el código, y si las especificaciones vivieran en otro lugar, podríamos mantener ese contexto porque nos hemos ralentizado mucho, pero creo que tan pronto como introduces esta cosa que genera código rápidamente, necesitas una manera de tener estos rápidos por qué hicimos esto, qué hicimos antes, qué salió mal antes, que es algo que no dije en mi charla, pero necesitamos saber qué sucedió antes para que no vuelva a suceder. Creo que eso es lo más importante, y perdemos eso cuando, como, ya sabes, generamos miles de líneas de código por minuto. Así que, sí. Claro, seguro. Otro sobre ese tipo de importancia del contexto y organizarlo, ¿cómo organizas tus especificaciones de manera que no se vuelvan simplemente infladas?
Comments