Ex-VP Engineering @ Creditas ($4.8B). 20+ years building and scaling tech teams. Today, I help CTOs make better decisions.
El código fue la parte fácil
|
Durante los últimos meses construí un proyecto personal usando Claude como mi principal herramienta de desarrollo. La idea parecía simple: Crear una quiniela del Mundial donde los participantes hacen todos sus pronósticos antes de que empiece el torneo, como hacíamos en Excel hasta hace poco. El software estuvo listo mucho más rápido de lo que imaginaba. Pero lo más interesante fueron los aprendizajes a lo largo del camino. Algunos de ellos: Los tests son obligatorios. En un momento decidí leer todos los unit tests generados por Claude. Fue entonces cuando descubrí que estaba colocando una parte importante de la lógica dentro de la base de datos. Cuando lo cuestioné, la respuesta fue básicamente: “Ah, entonces moveré esa lógica al código. Es más fácil de testear.” Touché. Otro aprendizaje: los tests encontraron muchos más problemas de los que esperaba. Detecté:
Otra cosa que aprendí fue el concepto de mutation testing. No basta con tener tests. La pregunta es: ¿los tests son buenos? Las herramientas de mutation testing modifican automáticamente el código para verificar si los tests detectan el problema. Si los tests siguen pasando, probablemente no están cubriendo el comportamiento que deberían. Hay tests que parecen simples y son absurdamente difíciles. Un ejemplo fue validar la clasificación de los grupos del Mundial. Empate en puntos. Diferencia de goles. Goles marcados. Enfrentamiento directo. Probar todas las combinaciones posibles de cuatro selecciones fue mucho más complicado que implementar la funcionalidad. Los usuarios ven cosas que tú no ves. Le mostré la home a un amigo publicista. La miró durante unos segundos y dijo: “La tipografía se ve vieja.” Pensé que era una opinión. Era un bug. El CSS se estaba cargando incorrectamente. Poner nombre a las cosas sigue siendo difícil. Hasta hoy no sé cuál es la mejor forma de explicar el producto. ¿Es una quiniela? ¿Una quiniela clásica? ¿Una quiniela hasta la final? ¿Y encontrar un buen dominio? Ni hablar. Pensé que el problema sería desarrollar. Terminé gastando mucho más tiempo intentando explicar lo que había desarrollado. Traducir es fácil. Entender el mercado es difícil. Como la barrera de implementación se volvió mucho menor gracias a la IA, una de las primeras ideas que tuve fue lanzar el producto en varios idiomas. Traducir la interfaz sería trivial. El problema apareció antes. Si ya me costaba explicar el producto en Brasil, ¿cómo iba a descubrir cuál es el equivalente de este tipo de quiniela en otros países? ¿Cómo se conoce? ¿La gente juega de esta manera? ¿Existe demanda? Le pregunté a una amiga argentina si este tipo de quiniela era común allí. La respuesta fue negativa. Mi research internacional terminó ahí mismo. Fue un buen recordatorio de que la IA redujo drásticamente el costo de construir software. Pero no redujo en la misma proporción el costo de entender clientes y mercados. No toda automatización vale la pena. Decidí validar manualmente los pagos vía Pix (el sistema brasileño de pagos instantáneos). ¿Podría automatizarlo? Claro. Pero para el volumen esperado, la complejidad no lo justificaba. Fue un buen recordatorio de que la mejor solución no siempre es la más tecnológica. La IA genera landing pages muy rápido. Usé IA para crear prácticamente todas las páginas de SEO. ¿Leí cada una con atención? No. ¿Podrían ser mejores? Probablemente. Pero también aprendí que SEO es un juego de largo plazo. Las páginas fueron publicadas casi dos meses antes del Mundial para dar tiempo a que fueran indexadas. Y por último: los problemas más peligrosos son los de especificación. Cuatro días antes del inicio del Mundial, un usuario me avisó que los cruces de los dieciseisavos de final estaban equivocados. El código estaba funcionando exactamente como había sido especificado. El problema era la especificación. Yo había interpretado incorrectamente una parte del reglamento de la FIFA. Claude no cuestionó nada. Yo no releí el Anexo C. Y el error pasó. Resultado: Tuve que reimplementar toda la lógica de los cruces y avisar a unas 30 personas que ya habían completado sus pronósticos de eliminación directa para que los revisaran nuevamente. No fue una experiencia agradable. Tal vez esa haya sido la principal lección del proyecto. La IA reduce muchísimo el costo de implementación. Pero sigue sin reemplazar la comprensión del problema. Y cuando entiendes mal el problema, implementa el error con una velocidad impresionante. PD: Si quieres probar el producto, está disponible en www.obolaodacopa.com.br (en portugués) |
Leo Andreucci - CTO Mentor
Ex-VP Engineering @ Creditas ($4.8B). 20+ years building and scaling tech teams. Today, I help CTOs make better decisions.
Nos últimos meses construí um projeto pessoal usando Claude como principal ferramenta de desenvolvimento. A ideia parecia simples: Criar um bolão da Copa do Mundo onde os participantes fazem todos os palpites antes do torneio começar, como fazíamos em excel até pouco tempo atrás. O software ficou pronto muito mais rápido do que eu imaginava. Mas o mais interessante foram os aprendizados ao longo do caminho. Alguns deles: Testes são obrigatórios. Em um momento eu decidi que iria ler todos os...
Uma ideia muito forte do Uncle Bob sobre IA: “Sem restrições, os agentes fazem qualquer coisa.” Por isso ele insiste muito na criação de “physical barriers”. Ou seja: mecanismos concretos que limitam o que a IA pode fazer dentro do sistema. O checklist que ele sugere é interessante: unit tests com cobertura extremamente alta (os agentes usam os testes para entender o comportamento esperado do sistema) acceptance tests escritos em Gherkin/BDD (testes legíveis por humanos funcionando como...
Una idea muy fuerte de Uncle Bob sobre IA: “Sin restricciones, los agentes hacen cualquier cosa.” Por eso insiste mucho en la creación de “physical barriers”. Es decir: mecanismos concretos que limitan lo que la IA puede hacer dentro del sistema. El checklist que él sugiere es interesante: unit tests con cobertura extremadamente alta (los agentes usan los tests para entender el comportamiento esperado del sistema) acceptance tests escritos en Gherkin/BDD (tests legibles para humanos...