Hola @swyx, tengo una pregunta para ti, Siempre dices "haz cosas, cuéntaselo a la gente." Pero encuentro que el hacer interfiere con el contar. Me pierdo en el hacer. Tengo que bloquear tiempo en mi calendario a la fuerza solo para obligarme a contarle a la gente escribiendo. Y aun así, siento que estoy desperdiciando tiempo que podría dedicar a hacer más. He visto algo de valor al contarle a la gente. Pero disfruto mucho más el hacer. No quiero ser un escritor técnico. No quiero ser dev rel y soy mayormente alérgico a la palabra "marketing." Solo quiero comunicar ideas lo suficiente para que realmente sean adoptadas (y que la gente use lo que construyo). La vida es corta y, aunque trabaje todo el tiempo, solo hay tanto tiempo. ¿Cómo gestionas el equilibrio? ¿Qué heurísticas utilizas? Creo que muchos creadores luchan con esto y algunos se inclinan demasiado hacia un lado. Me encantaría conocer tu opinión.

Cómo @cline experimentó la "lección amarga" en su propio viaje. Cuando se lanzó el Sonnet 4, muchas cosas se rompieron. El modelo funcionaba en bucles. Tomaba las instrucciones demasiado literalmente y hacía cosas raras. Estábamos confundidos. El mismo aviso del sistema había funcionado para 3.5, 3.7, todo lo anterior. En ese momento nos dimos cuenta: nuestro aviso estaba sobrecargando sensorialmente al modelo. ¿Todas esas instrucciones cuidadosas que habíamos escrito? Estaban interfiriendo con la forma en que el modelo realmente piensa. La lección amarga para los agentes: Crees que puedes ajustar los avisos y hacer que los modelos sean mejores. Y tal vez eso funcione... por ahora. Pero con más capacidad de cómputo, los modelos simplemente mejoran por sí solos. Y cuanto más apoyo brindes, más te estás interponiendo en el camino. El mejor aviso del sistema es el que señala a los agentes en la dirección correcta pero luego se aparta del camino del modelo.

Cómo hacer ingeniería inversa de cualquier herramienta de codificación de IA de código cerrado: Esto funciona para Claude Code, Windsurf, Copilot y literalmente cualquier cosa interceptando sus llamadas. Método 1: Charles Proxy (para herramientas con endpoints internos) Las herramientas como la extensión de Vscode se dirigen primero a su propio backend. - Instala Charles Proxy - Instala el certificado raíz de Charles - Observa el tráfico - Encuentra el endpoint interno al que están accediendo - Márquelo para el proxy SSL en Charles - Lee todo. Método 2: Proxy local (para herramientas que llaman a las API de LLM directamente) - Herramientas como Cline, Claude Code llaman directamente. Charles no funcionará ya que la fijación de certificados lo bloquea. - Levanta un proxy local en localhost:8080 - Configura la extensión para usar eso como su URL base de API - Tu proxy reenvía a la API real - Lee todo en texto plano - No estás interceptando ya que ERES el endpoint, así que no hay problemas de certificados. Con esto verás todos los prompts del sistema, definiciones de herramientas, estructura de conversación, parámetros, todo.