Ochenta y seis sesiones de construccion de una plataforma de orquestacion de pagos con un CTO de IA produjeron un conjunto de lecciones que ningun libro de texto cubre. Algunas de estas lecciones son especificas de fintech. Algunas son sobre desarrollo asistido por IA. Algunas son sobre la interseccion unica de ambos -- construir un sistema que maneja dinero real usando un modelo de desarrollo que nunca se ha intentado a esta escala.
Este articulo captura lo que funciono, lo que fue dificil, lo que nos sorprendio y lo que le diriamos a otro equipo intentando lo mismo.
Lo que funciono
Desarrollo sesion por sesion
La practica mas efectiva fue el modelo de sesiones en si. Cada sesion tenia un alcance definido, un entregable claro y un log de sesion que documentaba cada decision. Esto produjo varios beneficios:
Trazabilidad. Cada funcionalidad, cada correccion, cada decision arquitectonica es rastreable a una sesion especifica. Cuando algo se rompe, el log de sesion te dice exactamente cuando y por que fue introducido.
Reanudabilidad. Claude no tiene memoria persistente entre sesiones. El log de sesion sirve como documento de traspaso. Al inicio de cada sesion, Thales proporciona contexto del log de la sesion anterior, y Claude retoma exactamente donde termino la ultima sesion.
El patron de adaptador de proveedor
La decision de usar el patron adaptador para proveedores de pago se tomo en la sesion 001 y nunca cambio. Cada proveedor implementa la misma interfaz BaseProvider. Agregar un nuevo proveedor es siempre la misma tarea: implementar cuatro metodos. Sin cambios de enrutamiento, sin cambios de base de datos, sin cambios de API.
Simplificacion agresiva
Las sesiones de mayor impacto no fueron las que agregaron funcionalidades. Fueron las que eliminaron complejidad:
| Sesion | Que se elimino | Impacto |
|---|---|---|
| 015 | Precios de 3 niveles | Elimino codigo de gestion de niveles, simplifico incorporacion |
| 044 | Limites de credito | Elimino logica de suspension, complejidad de facturacion |
| 045 | Campos de API complejos | Reduccion a 3 campos requeridos (amount, currency, reference) |
Lo que fue dificil
Correccion de conversion de moneda
El manejo de monedas fue la mayor fuente de errores en todo el codigo. Los problemas se manifestaron en cada capa: formato de almacenamiento, formato de visualizacion, formato del proveedor, conversion entre monedas, monedas sin decimales, aritmetica de punto flotante.
La leccion es: define tus convenciones de moneda en un documento unico antes de escribir cualquier codigo, y referencia ese documento en cada sesion.
Limitaciones de SQLite a escala
SQLite nos sirvio bien durante las primeras 60 sesiones. Pero a medida que agregamos manejadores de webhook concurrentes, workers de Celery y manejo de solicitudes API, la limitacion de escritor unico se volvio insostenible. Las condiciones de carrera WAL costaron aproximadamente 15 horas de tiempo de depuracion.
La leccion: comienza con PostgreSQL para cualquier aplicacion que tendra escrituras concurrentes.
Lo que nos sorprendio
La maraton del 12 de diciembre
Trece sesiones en un dia no estaban planeadas. La sorpresa no fue la productividad (Claude puede generar codigo indefinidamente). La sorpresa fue que la calidad se mantuvo. El codigo generado en la sesion 019 (la 13a sesion del dia) era tan estructuralmente solido como la sesion 006 (la primera). La IA no se cansa.
Que tan rapido se podian generar SDKs
Construir 7 SDKs en una sola sesion (sesion 003) se sentia imposible antes de intentarlo. El descubrimiento clave: una vez que la API esta bien definida, un SDK es una traduccion mecanica.
Los errores de moneda fueron la categoria dominante de errores
En 86 sesiones, mas tiempo de depuracion se gasto en problemas relacionados con monedas que en cualquier otra categoria de errores. No autenticacion, no rendimiento, no integracion de proveedores -- moneda.
Consejos para desarrollo fintech asistido por IA
- Define convenciones financieras antes de codificar. Crea un documento que especifique: formato de almacenamiento, decimales por moneda, como convertir para cada proveedor, como mostrar a usuarios, como manejar redondeo.
- Comienza con PostgreSQL. SQLite es tentador por su simplicidad. Resiste la tentacion.
- Haz los registros de transacciones inmutables. Una vez creada, nunca debe modificarse. En muchas jurisdicciones (incluidos los paises OHADA), es un requisito legal.
- Construye el patron adaptador desde el primer dia. Cada proveedor implementa la misma interfaz. Nuevos proveedores son adiciones aisladas, no cambios en todo el sistema.
- Registra todo, pero no las credenciales. Registra cada transicion de estado de pago, cada webhook recibido, cada decision de enrutamiento. Pero enmascara todas las claves API, secretos y tokens en los logs.
- Mantiene logs de sesion. Si estas usando IA para desarrollo, mantiene logs de sesion detallados. Compensan la falta de memoria persistente de la IA.
- Simplifica implacablemente. La mejor sesion en la historia de 0fee.dev fue cuando eliminamos codigo.
- Realiza auditorias de seguridad temprano. Auditamos en la sesion 054 (63% del camino). Deberiamos haber auditado en la sesion 030.
El modelo CEO+CTO de IA: una evaluacion honesta
El modelo funciona. 0fee.dev es la prueba. Pero funciona diferente a un equipo de ingenieria tradicional:
Fortalezas: - Rendimiento de ingenieria ilimitado (13 sesiones en un dia) - Consistencia perfecta entre sesiones (mismos patrones, mismas convenciones) - Cero sobrecarga de comunicacion (sin reuniones, sin hilos de Slack) - Simplificacion instantanea (sin necesidad de construir consenso)
Debilidades: - Sin memoria persistente (los logs de sesion son esenciales, no opcionales) - Sin juicio independiente (la IA no dice "esto es una mala idea" sin ser solicitada) - Sin conocimiento institucional (cada sesion empieza fresca) - Punto unico de falla (el CEO toma cada decision; las malas decisiones se cascadean)
El mayor riesgo no es la capacidad de la IA. Es el juicio del CEO. En un equipo tradicional, una mala decision arquitectonica se detecta en la revision de codigo. En el modelo CEO+IA, una mala decision se implementa inmediatamente y perfectamente. La velocidad amplifica tanto las buenas como las malas decisiones por igual.
0fee.dev fue construido en 80 dias con cero ingenieros humanos. Ese es el titular. La historia completa son 86 sesiones de decisiones, errores, simplificaciones y lecciones que ninguna cantidad de planificacion podria haber predicho.
Este articulo es parte de la serie "Como construimos 0fee.dev". 0fee.dev es un orquestador de pagos que cubre mas de 53 proveedores en mas de 200 paises, construido por Juste A. GNIMAVO y Claude desde Abiyan sin ningun ingeniero humano. Sigue la serie para conocer la historia completa de construccion.