Max Planck Dev × MiA — Makers IA
¿Code
/
No‑Code?
Cómo la IA está rediseñando el trabajo del developer — y por qué dejamos de aceptar cajas negras, suscripciones caras y pesadillas de infraestructura.
maxplanck.dev
Charla técnica
2026
Quiénes somos
Brian Hume
Max Planck Dev — desarrollo con IA, hombro a hombro.
Desarrollamos software a medida, integraciones y agentes de IA para empresas que no se conforman con cajas negras. Acompañamos al cliente desde el MVP hasta la operación de plataforma — seguridad, performance, costos y trazabilidad incluidos.
Desarrollo a medida
Integraciones
Agentes de IA
Automatización
Buy vs. Build
Max Planck.Dev
EMAIL
LINKEDIN
linkedin.com/in/hume-brian
SITIO
maxplanck.dev
SEDE
112 Capitol Trail, Newark, DE
En el último año, la IA cambió cómo encaramos los problemas.
Ya no aceptamos cajas negras, suscripciones caras ni pesadillas de infraestructura.
Hoy construimos soluciones transparentes, observables y baratas de operar — que son nuestras.
CASO REAL — DROPSHIPPING
04 / 16
El reto del cliente
Sincronizar 8.000 productos desde cinco proveedores con ERPs propios hacia Shopify, vía Modern Dropship.
El retailer no tenía stock propio. Los proveedores tampoco tenían cuenta en Modern Dropship. Nuestro trabajo: hacer que sus APIs custom se comporten como si la tuvieran.
Origen
5 proveedores
3 ERPs distintos
Cada uno con su API custom, su esquema y sus rarezas.
La pieza que faltaba
Capa de sincronización
Traducción, normalización, manejo de errores y observabilidad — el problema que vinimos a resolver.
Destino
Modern Dropship
→ Shopify
Catálogo, variantes, stock e imágenes, listos para el retailer.
ENFOQUE 1 — ETL TRADICIONAL
05 / 16
Lo que probaron antes que nosotros
Contrataron un vendor de ETL. La promesa: extract, transform, load. Simple en teoría.
ACCESO RESTRINGIDO
⬛ CAJA NEGRA ⬛
- →El cliente no podía ver dentro de los flujos.
- →No podía ajustarlos ni mantenerlos.
- →Suscripción cara, dependencia total del vendor.
- →Para depurar, había que llamar a un especialista en Italia.
Tercerizar a una caja negra resuelve el problema de hoy y crea la dependencia de mañana.
Lección aprendida
El punto medio que prometía mucho
Flujos visuales, cloud-hosted, mantenibles por nosotros. Sin caja negra. Sin vendor lock-in. Construimos 8.000 productos de cinco proveedores.
Y se cayó.
Y se cayó de nuevo.
Y se cayó otra vez.
ENFOQUE 2 — DIAGNÓSTICO
07 / 16
Por qué n8n no aguantó
Probamos todo. A cierto volumen de datos, simplemente no escala.
- 01Paginar por chunks
- 02Su feature nueva de data tables
- 03Correrlo en su cloud
- 04Dockerizado en máquinas locales
- 05Self-hosting en instancias más grandes
Cuando se caía, no había logs útiles. Rebooteaba en silencio y entrábamos cinco minutos después sin saber qué pasó.
Opacidad total en el momento que más importa
EL TRABAJO QUE NADIE QUIERE HACER
08 / 16
Antes de pivotar a IA — la base
Organizamos toda la documentación. Esto fue el arma secreta.
# estructura del knowledge base
knowledge-base/
├── modern-dropship/
│ ├── supplier-api.md
│ └── webhooks.md
├── vendors/
│ ├── vendor-a/ → ERP-X
│ ├── vendor-b/ → ERP-X
│ ├── vendor-c/ → ERP-Y
│ ├── vendor-d/ → ERP-Y
│ └── vendor-e/ → ERP-Z
├── erps/
│ ├── erp-x.md
│ ├── erp-y.md
│ └── erp-z.md
└── cross-vendor-notes.md ← saber tribal
- 01Docs de cada API — proveedores y Modern Dropship, en un solo lugar.
- 02Mapeo vendor → ERP — quién usa qué, y por qué eso importa.
- 03Notas cruzadas — si arreglamos un bug en ERP-X, hay que aplicarlo en todos los vendors que lo usan.
- 04Markdown plano — leíble por humanos, parseable por agentes.
ENFOQUE 3 — AGENTES DE IA
09 / 16
Lo que sí funcionó
Le dimos el knowledge base a nuestros agentes. Pedimos dashboard, visibilidad, sync on-demand y vista de errores.
sync-dashboard · prod
● live
Productos sincronizados8.014
Errores0
Memoria pico512 MB
Última corrida12s
vendor-a · ERP-XOK
vendor-b · ERP-XOK
vendor-c · ERP-YOK
vendor-d · ERP-YOK
vendor-e · ERP-ZOK
2 h
Tiempo de construcciónDe desarrollo agéntico — no de tipear código humano.
8.000
Productos en la primera corridaSin caídas. Andó bien en el primer intento.
0
Cajas negrasVisibilidad completa, sync on-demand, vista de errores para retroalimentar a la IA.
LA VICTORIA OCULTA
10 / 16
Eficiencia de recursos en producción
0,5 GB
Medio giga de RAM en pico de carga. Toda la sincronización corre cómoda en una EC2 micro.
Suscripción n8n + cloud
~$100+ / mes
Nuestra infra en producción
$4 / mes
Y además
Sin pagar la suscripción cuando se cae.
01 / 03
Las tres rarezas de hacerlo con IA
Monitoreo de recursos como feature, no como afterthought.
Como somos dueños del sistema, decidimos qué se mide. CPU y memoria en vivo sobre el dashboard, sin add-ons ni vendors.
Resultado: dimensionamos la infra observando uso real, no adivinando. La observabilidad cambia las decisiones de costos.
MEMORIA · t-peak512 MB / 1 GB
02 / 03
Las tres rarezas de hacerlo con IA
Onboarding de vendor guiado por entrevista — el conocimiento se captura solo.
Skill interactiva "Onboard Vendor": la IA hace preguntas estructuradas, completa su propio prompt y actualiza el knowledge base.
Si reconoce el ERP de otro vendor, reutiliza el patrón. Sin developer en el medio. Sin documentación olvidada.
MiABienvenido. Voy a darte de alta un proveedor. ¿Nombre del vendor?
OperadorAcme Supply Co.
MiA¿Qué ERP usan?
OperadorERP-Y.
MiA · autoTengo el patrón de ERP-Y. Reuso el mapping.knowledge-base/vendors/acme/ creado · prompt actualizado
03 / 03
Las tres rarezas de hacerlo con IA
Una CLI conversacional para gestionar vendors — sin tocar variables de entorno.
5 flujos × 5 combinaciones vendor-ERP = 25 variables de entorno dispersas. Inmantenible.
Skill "Manage Vendors": estado de todo, drill-down, on/off por flow. Por debajo edita el archivo de config; arriba, el operador habla en su idioma.
mia ❯ manage-vendors
# estado actual de vendors y flows ───────────
| vendor-a | · | ERP-X | · | ● activo | 4/4 flows |
| vendor-b | · | ERP-X | · | ● activo | 4/4 flows |
| vendor-c | · | ERP-Y | · | ● activo | 4/4 flows |
| vendor-d | · | ERP-Y | · | ○ pausado | 3/4 flows |
| vendor-e | · | ERP-Z | · | ● activo | 4/4 flows |
mia ❯ toggle vendor-d:inventory off
✓ vendor-d.inventory → off
flows.config.json actualizado
TIEMPO Y COSTO, LADO A LADO
14 / 16
Los tres enfoques, comparados
El nuevo skill del developer: invertir en los inputs correctos para la IA.
ETL tradicional
n8n
Agentes de IA
Tiempo
Meses
~60 h
10–12 h
base · + 2 h build
Costo recurrente
Suscripción cara
Suscripción + cloud
$4 / mes
Visibilidad
Caja negra. Vendor opaco.
Aparente — hasta que se cae.
Total. Logs, métricas, errores.
Mantenimiento
Vendor en retainer.
Frágil al cambio de versión.
El equipo lo opera.
Escala
Costosa.
No llegó.
8.000 productos sin sudar.
EL CAMBIO DE MENTALIDAD
15 / 16
Nuevas oportunidades
Buscá cajas negras caras en los procesos del cliente. Ahí está el próximo proyecto.
01
Inventario en un SaaS caro y poco integrado.
Reemplazá la suscripción por un sistema custom con agentes que se conectan a las fuentes reales de datos del cliente.
↳Costo operativo −70%.
02
Marketing procesando leads a mano entre tres herramientas.
Pipeline con IA que conecta las herramientas, automatiza el procesado y centraliza todo en un solo dashboard.
↳Vendors recurrentes: eliminados.
03
Logística pagando reconciliación de envíos a un tercero.
Sistema que aprende las reglas del negocio, automatiza los casos comunes y marca excepciones con criterio.
↳El vendor deja de ser necesario.
El nuevo oficio del developer
Aceptamos cajas negras.Construimos transparencia.
Pagamos suscripciones por features que podríamos tener.Construimos las alternativas.
Asumimos que escalar es difícil.Construimos sistemas que se monitorean solos.
El skill no es aprender el framework más nuevo. Es hacer mejores preguntas: ¿cuál es el cuello de botella real?, ¿qué conocimiento hay que capturar?, ¿en qué puede ayudar la IA, en serio?
Max Planck Dev × MiA — Makers IA
Code
/
No‑Code?
How AI is redesigning the developer's job — and why we stopped accepting black boxes, expensive subscriptions and infrastructure nightmares.
maxplanck.dev
Tech talk
2026
Who we are
Brian Hume
Max Planck Dev — building with AI, shoulder to shoulder.
We build custom software, integrations and AI agents for companies that won't settle for black boxes. We stay with the client from MVP through running the platform — security, performance, cost and traceability included.
Custom development
Integrations
AI agents
Automation
Buy vs. Build
Max Planck.Dev
EMAIL
LINKEDIN
linkedin.com/in/hume-brian
SITE
maxplanck.dev
HQ
112 Capitol Trail, Newark, DE
Over the past year, AI changed how we approach problems.
We no longer accept black boxes, expensive subscriptions or infrastructure nightmares.
Today we build solutions that are transparent, observable and cheap to run — and ours.
REAL CASE — DROPSHIPPING
04 / 16
The client's challenge
Sync 8,000 products from five suppliers with their own ERPs into Shopify, via Modern Dropship.
The retailer held no stock of its own. The suppliers had no Modern Dropship account either. Our job: make their custom APIs behave as if they did.
Source
5 suppliers
3 different ERPs
Each with its own custom API, its own schema and its own quirks.
The missing piece
Sync layer
Translation, normalization, error handling and observability — the problem we were brought in to solve.
Destination
Modern Dropship
→ Shopify
Catalog, variants, stock and images, ready for the retailer.
APPROACH 1 — TRADITIONAL ETL
05 / 16
What they tried before us
They hired an ETL vendor. The promise: extract, transform, load. Simple in theory.
RESTRICTED ACCESS
⬛ BLACK BOX ⬛
- →The client couldn't see inside the flows.
- →They couldn't adjust them or maintain them.
- →Expensive subscription, total dependency on the vendor.
- →Debugging meant calling a specialist in Italy.
Outsourcing to a black box solves today's problem and creates tomorrow's dependency.
Lesson learned
The middle ground that promised a lot
Visual flows, cloud-hosted, maintainable by us. No black box. No vendor lock-in. We built all 8,000 products from five suppliers.
And it crashed.
And it crashed again.
And again.
APPROACH 2 — DIAGNOSIS
07 / 16
Why n8n couldn't take it
We tried everything. Past a certain data volume, it simply doesn't scale.
- 01Paginating in chunks
- 02Their new data tables feature
- 03Running it on their cloud
- 04Dockerized on local machines
- 05Self-hosting on bigger instances
When it went down, there were no useful logs. It rebooted silently and we'd come in five minutes later with no idea what happened.
Total opacity at the moment that matters most
THE WORK NOBODY WANTS TO DO
08 / 16
Before pivoting to AI — the groundwork
We organized every piece of documentation. This was the secret weapon.
# knowledge base structure
knowledge-base/
├── modern-dropship/
│ ├── supplier-api.md
│ └── webhooks.md
├── vendors/
│ ├── vendor-a/ → ERP-X
│ ├── vendor-b/ → ERP-X
│ ├── vendor-c/ → ERP-Y
│ ├── vendor-d/ → ERP-Y
│ └── vendor-e/ → ERP-Z
├── erps/
│ ├── erp-x.md
│ ├── erp-y.md
│ └── erp-z.md
└── cross-vendor-notes.md ← tribal knowledge
- 01Docs for every API — suppliers and Modern Dropship, in one place.
- 02Vendor → ERP mapping — who runs what, and why that matters.
- 03Cross-cutting notes — fix a bug in ERP-X and it has to land on every vendor running it.
- 04Plain Markdown — readable by humans, parseable by agents.
APPROACH 3 — AI AGENTS
09 / 16
What actually worked
We handed the knowledge base to our agents. We asked for a dashboard, visibility, on-demand sync and an error view.
sync-dashboard · prod
● live
Products synced8,014
Errors0
Peak memory512 MB
Last run12s
vendor-a · ERP-XOK
vendor-b · ERP-XOK
vendor-c · ERP-YOK
vendor-d · ERP-YOK
vendor-e · ERP-ZOK
2 h
Build timeOf agentic development — not of humans typing code.
8,000
Products on the first runNo crashes. It worked on the first try.
0
Black boxesFull visibility, on-demand sync, error view to feed back into the AI.
Resource efficiency in production
0.5 GB
Half a gig of RAM at peak load. The whole sync runs comfortably on an EC2 micro.
n8n subscription + cloud
~$100+ / mo
Our infra in production
$4 / mo
And on top of that
No subscription to pay while it's down.
01 / 03
The three quirks of doing it with AI
Resource monitoring as a feature, not an afterthought.
Because we own the system, we decide what gets measured. Live CPU and memory on the dashboard, no add-ons, no vendors.
The result: we size the infra by watching real usage, not by guessing. Observability changes the cost decisions.
MEMORY · t-peak512 MB / 1 GB
02 / 03
The three quirks of doing it with AI
Interview-guided vendor onboarding — the knowledge captures itself.
An interactive "Onboard Vendor" skill: the AI asks structured questions, completes its own prompt and updates the knowledge base.
If it recognizes another vendor's ERP, it reuses the pattern. No developer in the middle. No documentation left behind.
MiAWelcome. Let's onboard a supplier. Vendor name?
OperatorAcme Supply Co.
MiAWhich ERP do they run?
OperatorERP-Y.
MiA · autoGot the ERP-Y pattern. Reusing the mapping.knowledge-base/vendors/acme/ created · prompt updated
03 / 03
The three quirks of doing it with AI
A conversational CLI to manage vendors — without touching environment variables.
5 flows × 5 vendor-ERP combinations = 25 environment variables scattered around. Unmaintainable.
The "Manage Vendors" skill: status of everything, drill-down, on/off per flow. Underneath it edits the config file; on top, the operator speaks plain language.
mia ❯ manage-vendors
# current vendor and flow status ─────────────
| vendor-a | · | ERP-X | · | ● active | 4/4 flows |
| vendor-b | · | ERP-X | · | ● active | 4/4 flows |
| vendor-c | · | ERP-Y | · | ● active | 4/4 flows |
| vendor-d | · | ERP-Y | · | ○ paused | 3/4 flows |
| vendor-e | · | ERP-Z | · | ● active | 4/4 flows |
mia ❯ toggle vendor-d:inventory off
✓ vendor-d.inventory → off
flows.config.json updated
TIME AND COST, SIDE BY SIDE
14 / 16
The three approaches, compared
The developer's new skill: investing in the right inputs for the AI.
Traditional ETL
n8n
AI agents
Time
Months
~60 h
10–12 h
groundwork · + 2 h build
Recurring cost
Pricey subscription
Subscription + cloud
$4 / mo
Visibility
Black box. Opaque vendor.
Apparent — until it goes down.
Total. Logs, metrics, errors.
Maintenance
Vendor on retainer.
Fragile across version bumps.
The team runs it.
Scale
Expensive.
Never got there.
8,000 products without breaking a sweat.
THE MINDSET SHIFT
15 / 16
New opportunities
Look for expensive black boxes in your client's processes. That's the next project.
01
Inventory in an expensive, barely integrated SaaS.
Replace the subscription with a custom system whose agents connect to the client's real data sources.
↳Operating cost −70%.
02
Marketing processing leads by hand across three tools.
An AI pipeline that connects the tools, automates the processing and centralizes everything in a single dashboard.
↳Recurring vendors: gone.
03
Logistics paying a third party to reconcile shipments.
A system that learns the business rules, automates the common cases and flags exceptions with judgment.
↳Vendor no longer needed.
The developer's new craft
We accepted black boxes.We build transparency.
We paid subscriptions for features we could own.We build the alternatives.
We assumed scaling is hard.We build systems that monitor themselves.
The skill isn't learning the newest framework. It's asking better questions: where is the real bottleneck? what knowledge needs capturing? where can AI genuinely help?