la IA no es perfecta
estoy creando un saas nuevo y ya está terminado. lo cree 100% con agentes, usando buenas prácticas, tests automáticos, agentes para mejorar la UX, hacer QA en navegador
está listo, pero cuando fui a probar el onboarding, en la parte más critica, que es la carga de datos iniciales, me di cuenta que está poco claro. puedo perder usuarios si no mejoro esto
lo que hice fue
1) hable mucho con claude para encontrar un approach correcto y le pedí que me escriba un handoff con las propuestas y un prompt para que otro agente lo continue desde cero
2) el agente nuevo comparó el documento contra el código, encontró 3 cosas que no coincidían y creó un spec de implementación
3) armó 24 archivos de prueba con la forma de los que suben los usuarios reales
4) 12 agentes recorrieron el flujo, uno haciendo de usuario novato y otro de revisor de ux. en una notebook común, monitor, etc
5) despues armó los mockups antes de tocar código, y los mismos 24 archivos van a pasar por el flujo de hoy y por el nuevo para comparar
con eso veo como voy a implementar las mejoras y armar el plan de cambios
el criterio humano sigue siendo importante
de todas formas, una vez definido el criterio, sigo usando IA para solucionarlo
7 RECURSOS sin coste para programadores
① APIs de IA con capas gratuitas
→ itsfree․ai
② +1500 APIs para tu próximo proyecto
→ publicapis․dev
③ Iconos de empresas y productos en SVG
→ svgl․app
④ 100 bases de datos SQLite de 5GB en la nube
→ turso․tech
⑤ Revisión de Pull Requests con IA para Open Source
→ coderabbit․ai
⑥ 3000 emails al mes desde API
→ resend․com
⑦ Monitoriza 50 webs y APIs sin pagar nada
→ uptimerobot․com
¡Añade tu recurso favorito en los comentarios!
aprender sobre agentes puede ser abrumador. hay muchos conceptos dando vueltas y no siempre está claro por dónde empezar.
ayuda separar el aprendizaje en 2:
1) usar agentes como Codex o Claude Code.
necesitas aprender a darles el contexto que necesitan, definir tareas claras y explicar cómo vas a comprobar que están resueltas.
también crear skills para procesos que repetís y conectar mcps para que puedan trabajar con tus sistemas.
parte del aprendizaje es saber cuándo pedir un plan, cómo dividir una tarea grande y cuándo intervenir. además de verificar el resultado.
2) construir tus propios agentes.
entender el loop: el modelo decide qué hacer, solicita una tool, recibe el resultado y vuelve a decidir. vos acá diseñás las tools disponibles, qué información recibe y qué permisos tiene para actuar.
también necesitás guardar el estado, manejar errores y reintentos, poner límites de tiempo y costo, y definir cuándo debe frenar o pedir ayuda. todo esto forma parte de harness engineering.
además, evaluar con casos reales si resuelve la tarea y revisar dónde falla para mejorarlo (evals).
los dos caminos se complementan. saber qué querés hacer te ayuda a decidir qué aprender primero.
Si estás aprendiendo programación en 2026, NO centres tu aprendizaje en:
- Memorizar sintaxis
- Recordar APIs de memoria
- Escribir boilerplate
- Dominar comandos aislados
- Implementar todo desde cero
En su lugar, aprende:
un hack que uso bastante para estudiar:
1) le pido a Claude que me arme un PDF sobre un tema
2) los subo a NotebookLM
3) los convierto en un podcast enfocado en lo que quiero aprender
si querés profundizar, armás varios PDFs más chicos sobre partes específicas y hacés que el podcast vaya mucho más al detalle.
si quieren arrancar a aprender sobre Agentes, yo iría más o menos en este orden:
1) entender qué es un agente: un modelo que puede usar tools y repetir pasos hasta completar una tarea.
2) construir uno simple que haga algo concreto de punta a punta. por ejemplo: buscar información, leer archivos y devolverte un resultado.
3) aprender contexto: qué información darle al modelo para trabajar, cuándo cargarla y qué conviene dejar afuera.
4) sumar memoria, skills, MCPs y otras integraciones cuando realmente hagan falta.
5) aprender a verificar lo que hace: tests, checks y criterios claros para saber si el resultado está bien.
6) después pasar a multi-agent: dividir una tarea, delegar partes a distintos agentes y coordinar cómo se pasan el trabajo entre ellos.
7) por último, meterse con harness engineering: sandbox, permisos, observabilidad, límites y toda la infraestructura que permite darles más autonomía.
para empezar a construir, pueden usar OpenAI Agents SDK o LangChain. los 2 van muy bien.
No saber desarrollo de software te obliga a pedirle a la IA cambio tras cambio y a perder horas iterando.
Saber desarrollo te permite definir exactamente qué hay que modificar y dejar que la IA lo haga.
Uno improvisa. El otro ya sabe qué quiere.
Esa es la simple diferencia entre vibecoding y spec-driven development.
A mí el trabajo remoto me cambió como persona. Me hizo más independiente, más organizada y más honesta conmigo misma. Porque cuando no tienes a nadie diciéndote qué hacer, te toca conocerte de verdad. Y eso a veces asusta pero también es lo más valioso.
¿En qué te cambió el trabajo remoto? 💛
Salvo que el VPS corra en tu casa, la infraestructura siempre depende de alguien.
Si tengo que elegir entre pagar 5 dólares por un VPS en un proveedor random o 20 dólares a Vercel a cambio de toda su oferta, elijo @vercel siempre.
Además, hablamos de tráfico en serio: tenemos miles de personas comprando y leyendo cómics en https://t.co/M4fLezNS0x. No podemos tener un solo VPS; necesitamos al menos tres, con un LB delante. No es tan fácil de armar.
Otro free advice: Life cicle de las tech hoy en día:
- se juntan tech bros y piensan la idea
- usan AI para complejizarla y hacerla súper técnica
- usan Claude para hacer el pitch deck y la web
- van a un fondo de inversión y buscan un grant sonando lo más techie nerd saavy en la habitación
- consiguen el grant, hacen brag al respecto, y gastan en volverse más tech.
- son tan tech y complejos que la gente normal no los usa
- entran en un ciclo de empujar gente a que los use, gastando sus grants en publicidad y regalos, mientras buscan más grants.
- se repite el ciclo.
- muere.
- los fundadores siguen con otra idea y repiten el ciclo.
Rompan el ciclo. Creen para la gente no para los fondos de inversion. O aprendan a pitchear a los fondos sin dejar a la gente afuera.
A mis amigos del mundo tech, un súper consejo gratuito: dejen de construir productos que ustedes entienden y que a sus tech amigos les gusta. La gente no quiere entender tech, la gente quiere usar la tech y listo.
Ayer me mostraron una app que usaba palabras como layer, stacking, defi y demases. Felicidades crearon una app que solo la gente ya metida en el sistema va a usar.
La razón porque Apple superó a Microsoft, IBM y otras, no fue solo la tecnología, pero la simpleza de poder usarla, por una simple y llana razón Steve jobs no era técnico, porque el aportaba el ojo de un humano normal.
Esfuércense más si es que realmente quieren cambiar el mundo, y si solo lo hacen para vivir de grant a grant, super van por buen camino