F
Facundo Ezequiel Diaz Cappella
LinkedIn Post
Interesante análisis para tener en cuenta a la hora de usar skills como Caveman "input tokens outnumber output by 20-25x. The input price is the number that actually drives your bill."
F
Facundo Ezequiel Diaz Cappella
LinkedIn Post
💬 Español
Anthropic ha lanzado un nuevo modelo al público general 🚀. Diferentes benchmarks sugieren que es claramente superior a su predecesor Claude Opus y que también supera a competidores como Gemini y los modelos de OpenAI. Curiosamente, este modelo forma parte de la familia Mythos, lo que significa que comparte las mismas capacidades base, pero en esta versión pública Anthropic ha añadido guardrails que impiden el acceso a conocimiento relacionado con ciberseguridad, biología y métodos de distillation.
(distillation)Esto significa que no podremos usar Fable para construir mejores modelos, básicamente un mecanismo de protección frente a la competencia.
Estas salvaguardas se están viendo por primera vez en modelos de Anthropic. Ya hay varias publicaciones de la comunidad discutiéndolas, e incluso hay informes que sugieren que los guardrails no son totalmente fiables, con ejemplos de falsos negativos 😳.
Anthropic suspendió el uso ayer (15 de junio de 2026) siguiendo una orden del gobierno de EE. UU. El timing también resulta bastante conveniente para Anthropic, especialmente teniendo en cuenta las preocupaciones de la comunidad sobre los guardrails, incluyendo reportes de falsos negativos.
Será interesante ver cuánto tardan los modelos open en alcanzar este nivel. El tiempo lo dirá ⏳
Documento oficial de la release del modelo en los cometarios.
💬 English
Anthropic has released a new model to the general public 🚀. Different benchmarks suggest it is clearly superior to its predecessor Claude Opus and also ranks ahead of competitors like Gemini and OpenAI models. Interestingly, this is part of the Mythos family, meaning it shares the same core capabilities, but in this public release Anthropic has added safeguards that prevent access to knowledge related to cybersecurity, biology, and distillation methods.
(distillation)This means we won’t be able to use Fable to build better models,essentially a protection mechanism against competitive.
These safeguards are being seen for the first time in Anthropic models. There are already several community posts discussing them, and there are even reports suggesting the guardrails may not be fully reliable, with examples of false negatives 😳.
Anthropic suspended usage yesterday (June 15, 2026) following an order from the US government. The timing also feels very convenient for Anthropic, especially given the guardrail concerns raised by the community, including reports of false negatives.
It will be interesting to see how long it takes for open models to reach this level. Time will tell ⏳
Check official system card in the comment section
F
Facundo Ezequiel Diaz Cappella
LinkedIn Post
💬 Español
De Software Engineer a Context Engineer 🧠
Este término está en tendencia hace un tiempo, y por buena razón. Cuanto más profundizas en este enfoque, más matices descubres.
Una verdad que pocos dicen en voz alta: si la IA falla, muchas veces el problema no está en el modelo, está en el contexto. Ahí es exactamente donde el ingeniero tiene que brillar.
Dominar Context Engineering implica saber evitar alucinaciones, optimizar el uso de tokens y asegurarse de que cada pieza de información que entra en la ventana de contexto tenga un propósito claro. Nada de más, nada de menos.
Andrej Karpathy lo resume mejor de lo que yo podría: "Context engineering is the delicate art and science of filling the context window with just the right information for the next step"
Requiere práctica constante y mantenerse al día en un campo que evoluciona rápido.
El link al tweet de Andrej en los comentarios, por si quieres leerlo directamente. ✨
💬 English
From Software Engineer to Context Engineer 🧠
The term is everywhere right now, and for good reason. The more you dig into it, the more layers you find.
Here's something not enough people say out loud: when AI gets it wrong, the model is often not the problem. The context is. And that's exactly where the engineer needs to step up.
Mastering Context Engineering means knowing how to prevent hallucinations, optimize token usage, and ensuring every piece of information entering the context window serves a clear purpose. Nothing more, nothing less.
Andrej Karpathy puts it better than I ever could: "Context engineering is the delicate art and science of filling the context window with just the right information for the next step"
It takes consistent practice and a commitment to staying current in a field that moves fast.
Dropping the link to Andrej's tweet in the comments if you want to read it directly. ✨
F
Facundo Ezequiel Diaz Cappella
LinkedIn Post
💬 Español
Interesante ver el ritmo al que crecen las empresas de IA en poder de cómputo.n
¿Cuál será el verdadero cuello de botella?
Será la energía y la infraestructura física.
Los chips avanzan más rápido de lo que se construyen plantas eléctricas. 🤔
💬 English
Interesting to see the pace at which AI companies are growing in compute power.
What will the real bottleneck be?
It will be energy and physical infrastructure.
Chips advance faster than power plants get built. 🤔
F
Facundo Ezequiel Diaz Cappella
LinkedIn Post
💬 Español
Spec Driven Development está ganando terreno… y GitHub acaba de entrar en la conversación. 🚀
En un momento donde la industria del software evoluciona más rápido que nunca, el desarrollo basado en especificaciones (Spec Driven Development) está ganando cada vez más relevancia.
GitHub no se ha quedado atrás: acaba de lanzar su propio kit para este enfoque, y la demo disponible directamente en su repositorio es muy interesante de explorar.
Puedes elegir el agente de codificación que mejor se adapte a tu flujo de trabajo: Copilot, Claude o Codex.
Link en los comentarios 👇
💬 English
Spec Driven Development is gaining serious momentum… and GitHub just made its move. 🚀
In an industry evolving at breakneck speed, Spec Driven Development is becoming increasingly relevant.
GitHub has just launched its own kit for this approach, and the demo available directly in their repository is well worth exploring.
You can choose the coding agent that best fits your workflow, Copilot, Claude, or Codex.
Link in the comment section 👇
F
Facundo Ezequiel Diaz Cappella
LinkedIn Post
💬 Español
Encontré un artículo que compara cuándo y por qué usar MCP sobre HTTP en la comunicación entre agentes. Aunque ambos pueden funcionar, hay diferencias importantes a tener en cuenta que harán que el descubrimiento de agentes sea mucho más fácil y conveniente. Vale la pena leerlo.
Al final del artículo comparten este framework de decisión:
• ¿Es el agente de IA el que llama a la herramienta? No (es una operación de backend), usa HTTP directo.
• ¿Cuántas herramientas externas necesitas? Si son 1-2, HTTP directo es más simple. Si son 3 o más, considera MCP.
• ¿Existe un servidor MCP ya construido para el servicio? Si, usarlo te ahorra tiempo de desarrollo.
• ¿Necesitas que la integración funcione en varias plataformas de IA? Si, MCP te da esa portabilidad.
• ¿La latencia es crítica (menos de 100ms para las llamadas)? Si, mide el impacto de MCP y decide según los resultados.
• ¿Distintos equipos gestionan distintas integraciones? Si, el modelo de MCP con un servidor por integración ayuda a definir responsabilidades.
En la práctica, si estás construyendo un agente de IA que necesita interactuar con servicios externos, MCP es cada vez más la opción por defecto. El ecosistema de servidores pre-construidos es lo suficientemente amplio como para que puedas empezar sin escribir ningún código de servidor.
Fuente: Jakub Swistak - quickchat.ai
---
💬 English
I found an amazing article comparing why and when to use MCP over HTTP in agent communication. While both can get the job done, there are important differences to take into account that will make agent discovery much easier and more convenient. Check out the article for all the details , it's a great read!
At the end of the article they shared this decision framework:
• Is the AI agent calling the tool? If no (it's a backend operation), use direct HTTP.
• How many external tools do you need? If 1-2, direct HTTP is simpler. If 3+, consider MCP.
• Does a pre-built MCP server exist for the service? If yes, using it saves development time.
• Do you need the integration to work across multiple AI platforms? If yes, MCP provides portability.
• Is latency critical (sub-100ms budget for tool calls)? If yes, benchmark MCP overhead and decide accordingly.
• Do different teams own different integrations? If yes, MCP's server-per-integration model helps with ownership boundaries.
In practice, if you are building an AI agent that needs to interact with external services, MCP is increasingly the default choice. The ecosystem of pre-built servers is large enough that you can often get started without writing any server code at all.
Source: Jakub Swistak - quickchat.ai
check the full article in the comment section
F
Facundo Ezequiel Diaz Cappella
LinkedIn Post
💬 Español
¿Estás usando la IA para validar tus ideas… o solo para ejecutarlas? 🤔
Hace poco me topé con el trabajo de
#MattPocock,
Entre sus *skills* para mejorar la productividad con IA (o hacerla mas efectiva), hay una que me mas me gusto personalmente: **"Grill Me"**.
La premisa es simple pero muy poderosa: en lugar de pedirle a la IA que ejecute tu plan, le pides que lo interrogue sin piedad. Que explore cada rama del árbol de decisiones. Que resuelva dependencias. Que te dé su recomendación en cada punto problemático.
En otras palabras, usas la IA en contra de tu idea, no como cámara de eco.
Esto ayuda a construir un plan técnico más robusto antes de escribir la primera línea de código. 💡
---
💬 English
Are you using AI to validate your ideas, or just to execute them? 🤔
I recently came across the work of
#MattPocock,
Among his productivity-focused AI skills, one stopped me: **"Grill Me"**.
The concept is simple: instead of asking AI to carry out your plan, you ask it to interrogate it relentlessly. Walk down every branch of the decision tree. Resolve dependencies. Offer a recommended answer at every point of friction.
In short, use AI against your technical plan, not as a yes-machine.
This forces you to build something stronger before you write the first line of code. 💡
Link to original article in the comment section.
F
Facundo Ezequiel Diaz Cappella
LinkedIn Post
💬 Español
Navegando por internet me encontré con una herramienta CLI que me pareció muy interesante en el mundo de los agentes de IA. 🤖
Se trata de una solución que puedes conectar directamente con tu asistente de código favorito, ya sea Gemini, Claude o Codex, y que te permite desplegar agentes en Google Cloud siguiendo buenas prácticas, todo alineado con el framework ADK (Agent Development Kit), también desarrollado por Google.
Lo que más me llama la atención es la propuesta integral que ofrece: no solo construyes el agente, sino que también puedes evaluarlo y desplegarlo de forma estructurada y reproducible.
Si estás explorando arquitecturas de agentes o buscas una forma más ordenada de llevarlos a producción en Google Cloud, vale la pena echarle un vistazo. 👇
Link al repositorio en los comentarios.
---
💬 English
While browsing the web, I came across a CLI tool that caught my attention, especially for those of us exploring the AI agent space. 🤖
It's a solution you can connect directly to your favorite code assistant, Gemini, Claude, or Codex, and use to deploy agents on Google Cloud following best practices, all aligned with the ADK (Agent Development Kit) framework, also developed by Google.
What stands out most is the end-to-end approach it offers: you don't just build the agent, you can also evaluate it and deploy it in a structured, repeatable way. Exactly the kind of tooling that closes the gap between experimentation and production.
If you're exploring agent architectures or looking for a cleaner path to getting them into production on Google Cloud, this one is worth a look. 👇
Link to the repo in the comments.