En este artículo veremos cómo adaptar nuestro trabajo con la llegada de agentes IA y al final construiremos una pequeña aplicación de vesting para ponerlo en práctica.
Desarrollo contratos inteligentes de forma profesional desde 2020 y he participado en todo tipo de proyectos. Desde proyectos institucionales hasta las shitcoins más shit que nos podamos imaginar.
Durante este tiempo, la manera de desarrollar en Solidity ha cambiado bastante. En algún momento mi stack principal fue Truffle con Drizzle encima de Ropsten. Hoy ninguna de esas herramientas existe. Aun así, ningún cambio ha sido tan significativo como la llegada de los agentes de IA.
Aunque Remix sigue siendo una muy buena manera de aprender, no es una herramienta amigable con un setup de agentes hoy.
Para mí, fue a partir de Opus 4.5, en diciembre de 2025, que cambió mucho mi flujo de trabajo. Ahora dedico más tiempo a decidir qué estándares estudiar, escoger la arquitectura de cada proyecto y encontrar dónde se concentra el riesgo.
A continuación veremos tres recomendaciones para desarrollar smart contracts en 2026 bajo esta nueva forma de trabajo.
1. Usemos herramientas para agentes, no para humanos
En 2026 prefiero Foundry o Hardhat en vez de Remix, cast y llamadas RPC directas en vez de Etherscan, y anvil en vez de Ganache. Bueno, este último ya ni siquiera existe, pero se entiende que el punto es preferir herramientas con APIs y comandos en la terminal para que nuestros agentes puedan operarlas con facilidad.
En el pasado lancé muchos protocolos desde Remix, quizás más de los que debería, y aunque todavía me parece una excelente herramienta para aprender, ya no la veo como una herramienta de desarrollo.
2. Sobre la seguridad de los smart contracts
Hoy podemos pedirle a un modelo de frontera que revise nuestros contratos, genere tests, haga fuzzing o ejecute análisis estático. Claro está que sigue siendo nuestra responsabilidad correr estas pruebas, encaminar a los robots y verificar que todo esté en orden. Pero en mi opinión ahora será menos probable lanzar un contrato con errores clásicos como una reentrancy, un acceso indebido o algún otro hack obvio.
Solidity además tiene un scope bastante reducido comparado con otros lenguajes. La EVM mantiene estado, memoria y código determinista (mira nuestra serie de tutoriales de EVM de bajo nivel aquí). No tiene que encargarse de archivos, múltiples procesos, threads o redes. También existen ERCs e implementaciones conocidas para casi todo lo común.
¿Significa esto que web3 ahora es un espacio más seguro? No necesariamente. El desafío se moverá hacia sistemas de mayor escala donde operen más contratos, chains, bridges, oráculos y servicios. La IA nos permitirá crear sistemas mucho más grandes, pero cada componente traerá nuevos vectores de ataque. Es ahí donde debemos prestar mayor atención.
3. Trabajemos sobre las ramas del sistema
Me gusta una analogía que Erik Schluntz, de Anthropic, utiliza para explicar cómo construir con agentes. Debemos distinguir entre las ramas del código, de las cuales dependen muchas otras partes, y las hojas, que pueden reemplazarse fácilmente sin afectar el resto.
La idea principal es dedicar más tiempo a revisar y pulir las ramas que las hojas. Me parece que esta analogía aplica muy bien a Web3 con un especial énfasis en la seguridad.
Nuestro enfoque debe estar en el tronco y las ramas del sistema. Podemos confiarle a la IA las partes menos críticas.
Cada proyecto es diferente, pero normalmente el contrato es donde centramos nuestra mayor atención, especialmente sus funciones que modifican el estado. También debemos revisar con cuidado las integraciones (e.g. oráculos, librerías de solidity, llamadas a otros contratos, etc...) y el código del frontend que construye las transacciones que firmaremos. El resto de la interfaz puede recibir una revisión más ligera.
¿Cómo se ve esto en la práctica?
Para ponerlo en práctica vamos a construir SloppyVesting, una pequeña aplicación de vesting para tokens ERC-20. Puedes observar el código final en Github.
Nuestra recomendación es comenzar construyendo un PRD o un spec. No tiene que ser algo complicado. Podemos iniciar una conversación así:
Queremos construir una aplicación sencilla de vesting para tokens ERC-20. Antes de escribir código, ayudanos a definir exactamente cómo debería funcionar.
Si queremos una estructura más formal podemos utilizar OpenSpec, un standard para expresar requisitos del código.
Durante nuestra conversación con los agentes definimos el período de vesting y los demás comportamientos del contrato. También investigamos las alternativas existentes y encontramos VestingWallet y VestingWalletCliff de OpenZeppelin. Después elegimos Foundry porque necesitamos compilar, hacer fuzzing y simular el deployment desde herramientas que nuestros agentes puedan operar directamente.
UI de SloppyVesting tras los agentes finalizaron la implementación.
Cuando estemos contentos con el spec podemos enviar a nuestros agentes a construir el proyecto. Antes de revisar el código conviene que probemos el resultado completo para encontrar errores evidentes y comprobar que el producto se siente como esperábamos.
Luego comienza la revisión. En SloppyVesting nos concentraremos mayormente en el contrato, revisar que esté libre de exploits. También revisaremos la conexión web3 del frontend para comprobar qué dirección, función y argumentos terminaremos firmando. Los tests nos ayudarán a verificar el comportamiento acordado en el spec y el resto de la aplicación recibirá una revisión proporcional al riesgo que controla.
Recomendaciones antes de lanzar
Por razones de seguridad, deberíamos lanzar un protocolo desde otro ambiente totalmente libre agentes. Aunque Anthropic, OpenAI y los demás proveedores prometan no utilizar nuestras variables de entorno y private keys, no tenemos manera de verificar todo lo que ocurre de su lado. ¿Y pues es por eso que estamos aquí en web3, verdad? Para no confiar en lo que no podemos verificar.
Tampoco deberíamos lanzar una arquitectura que todavía nos resulte demasiado compleja. En ese caso es mejor reducir el alcance o seguir estudiando hasta comprenderla (si no sabes por donde empezar, revisa mi video introductorio a Solidity). Esto no solo mejora la seguridad sino que también nos permite trabajar con los robots para crear proyectos más interesantes y originales.
Pero bueno, este tema merece su propio artículo.
Podemos continuar la conversación aquí y en YouTube, donde seguiremos explorando desarrollo de frontera en aplicaciones que respetan las libertades y autonomía de nuestros usuarios.
Top comments (0)