Prompting Claude Opus 5.5
Los rápidos avances del modelo Claude Opus 5.5 de Anthropic están impresionando a muchos desarrolladores con una programación, planificación e incluso capacidades de visualización 2D/3D más sólidas, pero también están generando preocupaciones sobre el hype, la inestabilidad y los trucos de “prompt engineering” en constante evolución que parecen cambiar cada pocos meses. Los comentaristas destacan tanto el poder como la fricción de las herramientas actuales: negativas de seguridad opacas, salida verbosa, barreras agresivas en torno a permisos y seguridad, y comportamientos de andamiaje que pueden ocultar lo que el modelo está haciendo. Esto lleva a algunos a buscar alternativas más baratas o más permisivas (incluidos modelos chinos y pesos abiertos) y a cuestionar si los flujos de trabajo agenticos de hoy son lo bastante maduros para una dependencia a largo plazo, o solo una etapa intermedia que avanza muy rápido.
Capacidad general y entusiasmo
- Muchos consideran que Opus 5.5 supone un gran salto, especialmente para programación y flujos de trabajo agenticos complejos de varias horas (p. ej., construir juegos sustanciales, planes de múltiples oleadas, revisión automática de código, subagentes, pruebas de simulación).
- A algunos les impresionan sus capacidades de visualización 2D/3D con solo JS/TS y bibliotecas básicas, y reportan un “cambio de escala” frente a Opus anteriores.
- Otros se muestran poco impresionados en comparación con las demos de redes sociales, señalando que muchos resultados llamativos dependen de herramientas externas (Suno, ElevenLabs, etc.) y de una orquestación pesada más que de una “AGI de un solo intento”.
- Varios usuarios dicen que Opus 5.5 supera a Astra para programar, mientras que otros siguen prefiriendo DeepSeek/Gemini/modelos chinos por coste o por tener menos restricciones.
Prompting, UX y “AI slop”
- Queja frecuente: las buenas prácticas de prompting cambian cada pocos meses; la gente siente que se ve obligada a “reaprender a conducir” con cada lanzamiento de frontera.
- La guía de Anthropic sobre los valores predeterminados de frontend lleva a algunos a entender por qué pedir un “aspecto de IA no genérico” sigue devolviendo tropos de diseño similares; el prompting negativo con patrones concretos que evitar funciona mejor.
- Algunos elogian flujos de trabajo simples y conversacionales (“plan.md, architecture.md, decisions.md”) sin andamiajes elaborados; otros dependen mucho de MCPs, skills, agentes y una orquestación compleja.
Uso de herramientas, andamiajes y sesiones
- Experiencias mixtas con Claude Code y otros andamiajes:
- Algunos reportan ejecuciones autónomas excelentes y configuraciones multiagente productivas.
- Otros ven problemas: comandos largos que bloquean, poca visibilidad en las llamadas a herramientas, confusión con la gestión de caché/sesiones, olvido de herramientas disponibles (p. ej., lectores de PDF) y un comportamiento demasiado ansioso que cambia código en vez de preguntar.
- Ocultar las llamadas a herramientas y los modelos de permisos más estrictos frustran a usuarios que quieren transparencia y control.
Seguridad, negativas y “thinking tokens”
- Salvaguardas más fuertes en 5.5 provocan negativas inesperadas para algunas tareas de tipo ciberseguridad o relacionadas con operaciones de PII.
- A veces el modelo se niega a editar sus propios ajustes de seguridad o a escribir contraseñas/códigos de verificación, lo que algunos ven como paternalista y teatro de seguridad; otros lo consideran un endurecimiento necesario contra la inyección de prompts.
- A varios les disgusta que no se expongan los “thinking tokens”/el razonamiento interno; algunos consideran cambiarse a proveedores chinos por un razonamiento más abierto y menos restricciones de seguridad.
Coste, verbosidad y estabilidad
- Los usuarios señalan un mayor consumo de tokens, más verbosidad y explicaciones más largas con contenido accionable enterrado al final, incluso cuando se pide “conciso”.
- Debate sobre estrategias de coste: modelo caro tanto para planificación como para codificación vs. “planificador inteligente + ejecutor barato + revisor inteligente”; desacuerdo sobre qué resulta más barato una vez se cuenta el tiempo de ingeniería.
- Crece el deseo de modelos estables, fijados por versión o de pesos abiertos, para evitar el desvío constante del comportamiento y el reajuste de prompts y flujos de trabajo.