La sesion 001 de 0fee.dev produjo 42 archivos conteniendo 7.900 lineas de codigo Python de grado de produccion en aproximadamente 45 minutos. Un backend completo de FastAPI con modelos SQLAlchemy, adaptadores de proveedores, un motor de enrutamiento, pila de middleware, servicio de cifrado y estructura de proyecto completa.
Ningun equipo de ingenieria humano escribe 7.900 lineas de codigo de produccion en menos de una hora. No porque los ingenieros humanos sean lentos -- no lo son. Sino porque la ingenieria humana involucra actividades que el desarrollo con IA no tiene: cambio de contexto, debates arquitectonicos, ciclos de revision de codigo, interrupciones de reuniones y la sobrecarga cognitiva de mantener una estructura de proyecto de 42 archivos en la memoria de trabajo.
Este articulo analiza lo que ocurrio en la sesion 001, lo que lo hace imposible para equipos humanos, y como se ve el modelo CEO+CTO de IA en la practica.
Lo que produjo la sesion 001
La sesion genero una arquitectura de backend completa:
backend/
main.py # Punto de entrada de aplicacion FastAPI
config.py # Entorno y configuracion
database.py # Motor y sesion de SQLAlchemy
models/
user.py, app.py, transaction.py, provider.py,
payment_method.py, webhook.py, api_key.py
routes/
auth.py, apps.py, payments.py, transactions.py,
providers.py, webhooks.py
providers/
base.py, stripe_adapter.py, paypal_adapter.py,
hub2_adapter.py, pawapay_adapter.py, test_adapter.py
services/
routing.py, encryption.py, billing.py, webhook_delivery.py
middleware/
auth.py, rate_limit.py, cors.py, logging.py
utils/
ids.py, currency.py
requirements.txt42 archivos. Cada archivo era sintacticamente correcto. Cada importacion resolvia. La aplicacion arrancaba sin errores. Los endpoints de API devolvian respuestas validas.
Lo que los ingenieros humanos hacen diferente
La discusion de arquitectura (2-4 horas)
Antes de que un equipo humano escriba la primera linea de codigo para una plataforma de pagos, tienen una discusion de arquitectura. ¿Django o FastAPI? ¿PostgreSQL o SQLite para desarrollo? ¿Que ORM? ¿Que estrategia de autenticacion? ¿Como abstraer los proveedores?
En la sesion 001, Thales dijo "orquestador de pagos, Python, FastAPI" y Claude produjo la arquitectura. El "debate" fue un prompt de 30 segundos, no una discusion de multiples dias.
La fase de configuracion (4-8 horas)
Un equipo humano iniciando un nuevo proyecto Python necesita crear un entorno virtual, instalar dependencias, configurar la estructura del proyecto, configurar la conexion a base de datos, escribir el primer modelo, la primera ruta, probar que funciona. La fase de configuracion para un proyecto de 42 archivos tipicamente toma a un ingeniero senior 4-8 horas.
Claude genera toda la estructura -- incluyendo configuracion, dependencias y diseno del proyecto -- en una sola respuesta.
El costo de cambio de contexto (50% de sobrecarga)
Los ingenieros humanos pierden contexto cuando cambian entre archivos. Escribir models/transaction.py requiere pensar en el modelo de datos de transaccion. Cambiar a routes/payments.py requiere pensar en el contrato de la API. Cambiar a providers/stripe_adapter.py requiere pensar en la API de Stripe.
Claude no cambia de contexto. Genera los 42 archivos dentro de una sola ventana de contexto. El modelo de transaccion, la ruta de pago y el adaptador de Stripe estan todos "en memoria" simultaneamente.
El ciclo de revision de codigo (1-3 dias)
En un equipo, la salida de la sesion 001 pasaria por revision de codigo. Un ingeniero senior revisaria 42 archivos, dejaria comentarios, solicitaria cambios. Este ciclo tipicamente toma 1-3 dias para un PR de este tamano.
En el modelo CEO+CTO de IA, Thales revisa la salida ejecutando la aplicacion y probando endpoints. La revision es funcional (¿funciona?) en lugar de estilistica (¿sigue nuestras convenciones?).
Sin reuniones
Un equipo humano construyendo una plataforma de pagos tiene: standups diarios, planificacion de sprint, revisiones de arquitectura, reuniones uno a uno, retrospectivas. Para un equipo de 5 personas, esto son aproximadamente 10-15 horas por semana de reuniones. En 80 dias, eso son 115-170 horas -- el equivalente a 4 semanas de trabajo completas.
0fee.dev tuvo cero reuniones.
La ventaja de la IA: sin perdida de contexto
La ventaja mas significativa no es la velocidad. Es la retencion de contexto dentro de una sesion.
Cuando Claude genera providers/base.py, define una interfaz abstracta. Cuando luego genera providers/stripe_adapter.py, implementa esa interfaz exacta. Y cuando genera services/routing.py, llama a la interfaz correctamente. Los tres archivos se generan con perfecta consistencia interna porque existen en el mismo contexto.
La limitacion de la IA: sin memoria institucional
Pero la sesion 001 tambien revelo la limitacion fundamental: cuando la sesion 002 empezo, Claude no tenia memoria de la sesion 001. Toda la arquitectura de 42 archivos existia solo en el codigo y el log de sesion.
Por eso el modelo de log de sesion es esencial. Sin el, cada nueva sesion empezaria desde cero, redescubriendo decisiones arquitectonicas que ya se habian tomado.
El rol del CEO: velocidad de decision
La ventaja de la IA es el rendimiento. La ventaja del CEO es la velocidad de decision.
En la sesion 001, Thales tomo aproximadamente 30 decisiones arquitectonicas en segundos cada una. No hubo comite, sin marco DACI, sin "dejame pensarlo y te aviso". El CEO decidio; la IA implemento.
Esta velocidad corta en ambos sentidos. Las buenas decisiones se implementan instantaneamente. Las malas decisiones tambien se implementan instantaneamente. Pero la capacidad de iterar rapidamente significo que las malas decisiones eran baratas de revertir.
¿Lo hariamos diferente?
Si empezaramos 0fee.dev de nuevo, la sesion 001 se veria similar pero con tres cambios:
- Empezar con PostgreSQL. La decision de SQLite ahorro 10 minutos de configuracion y costo 15 horas de depuracion de WAL. No valio la pena.
- Definir convenciones de moneda en el log de sesion. "Todos los montos almacenados en unidades mayores (dolares, no centavos)" -- esta sola oracion habria prevenido la categoria de errores mas persistente.
- Escribir la prueba de interfaz de
BaseProviderprimero. No una suite de pruebas completa, sino una prueba de contrato que valide que cada adaptador de proveedor implementa la interfaz correctamente.
Todo lo demas -- la estructura del proyecto, el patron adaptador, la pila de middleware, el motor de enrutamiento -- se mantuvo a traves de 85 sesiones posteriores. La arquitectura establecida en 45 minutos era solida. Los detalles de implementacion necesitaron iteracion, pero la base era firme.
Eso es lo que ningun ingeniero humano haria: producir una arquitectura solida de 42 archivos en 45 minutos. No porque los humanos no puedan diseñar bien, sino porque el ciclo diseñar-implementar-revisar en equipos humanos es inherentemente serial. En el modelo CEO+CTO de IA, ese ciclo se comprime a su minimo teorico: decidir, generar, probar.
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.