Cómo mi agente creó un producto contable en un día — sin que yo siquiera leyera el brief
7 de mayo de 2026
Mi amigo Andrey me envió una tarea. No abrí el brief. No miré los PDF adjuntos. Un día después, Andrey tenía sobre la mesa un producto funcionando — con interfaz web, documentación y código — y yo tuve tiempo de escribir este artículo.
El desarrollo en sí tomó horas. El resto del tiempo los agentes esperaban a que yo me liberara para decirles «ok, adelante».
Cualquier tarea estrecha que aparece en tu negocio — rutina, procesamiento de documentos, lo que sea — se puede automatizar escribiendo tu propia solución. Y no alquilando para siempre el SaaS de otro.
Eso es lo principal por lo que escribo este artículo. Más abajo — cómo está todo armado por dentro.
Lo que pidió Andrey
Andrey es mi amigo, dueño de un lounge de shisha en Kémerovo. Está muy metido en la automatización: ya automatizó muchas cosas en su local. Y ahora se le ocurrió una idea nueva — un parser de UPDs para contadores.
UPD es el «documento universal de transferencia», la principal documentación primaria en Rusia. Cada día un contador recibe una pila de estos documentos como escaneos, y tiene que volver a teclear manualmente en 1C (el software de contabilidad estándar en Rusia) el vendedor, el INN (RFC), el KPP (registro fiscal), la fecha, y cada línea de producto. Diez a quince minutos por documento. Una decena al día.
Es rutina que se come la vida de otros.
Andrey planteó la tarea así: un programa que toma un PDF con el escaneo de un UPD y devuelve datos estructurados. Con una condición importante — todo tiene que correr localmente. Son documentos financieros, no se pueden mandar a la nube.
«Esa, en principio, fue la única entrada que recibí de él. Después solo me mandó el brief.»
Y ya. A partir de ahí no me metí en la tarea.
Yo no era el cliente, era un conmutador de mensajes
Andrey envió mensajes de Telegram con la descripción y adjuntó algunos PDF con ejemplos de UPD. Yo ni los abrí. Solo los reenvié a mi agente coordinador Мо.
Мо es el primer agente que creé. Es el administrador de mi equipo de agentes. El que está entre yo y todos los demás. Sobre él ya escribí aparte.
Lo que pasó después:
- Мо leyó el brief de Andrey y le hizo preguntas aclaratorias — a través de mí.
- Yo reenvié las preguntas a Andrey en Telegram.
- Andrey respondió. Yo reenvié las respuestas a Мо.
- Мо armó con todo eso un brief de calidad — desglosado por secciones, con criterios de aceptación.
- Мо me sugirió enviar este brief a Макс — mi agente desarrollador.
- Yo acepté.
«Solo reenvié los mensajes de Telegram a mi agente coordinador Мо. Мо armó la tarea completa — ya un brief de calidad — y me sugirió enviárselo a Макс.»
¿Te diste cuenta? En esta cadena yo no soy el cliente. Soy el enlace. Мо se comporta como un product manager: él mismo entrevista al cliente, escribe el brief, delega al desarrollador. Yo solo reenvío mensajes y hago clic en «ok».
Por qué ni siquiera intenté entender
En ese momento tenía cuatro proyectos más en marcha. Dos — en fase activa. Físicamente no estaba listo para meterme en algo más.
Pero no era solo carga de trabajo. Tenía curiosidad de probarlo así — entregar la tarea por completo, sin meterme en los detalles.
«Confiaba en que Макс, con un brief claro de Мо, lo iba a sacar. Solo tendría que dar un par de pistas si chocaba con un muro.»
Era un experimento. Quería comprobar — qué tan profundo tengo que sumergirme para que el sistema dé resultado. La respuesta resultó ser: casi nada.
Solté la tarea — y me olvidé
Esto es, probablemente, lo más inesperado de la historia.
Le reenvié el brief a Макс a través de mensajes en la bandeja de entrada, le pedí que arrancara — y la tarea se me cayó de la cabeza. Estaba ocupado con otra cosa. No «la solté conscientemente» — literalmente me olvidé.
Después de un rato, Макс mismo me recordó que había tal tarea. Me mandó un plan de desarrollo — qué, para qué, cómo lo iba a hacer. Lo miré por encima, vi que el camino era correcto, y le di luz verde para modo automático.
«El desarrollo en sí, en realidad, no tomó más de dos horas. El resto del tiempo fue el lapso entre entregar la tarea y empezar a trabajar en ella.»
En total, del brief al paquete entregado a Andrey pasó un día. De ese día, mi participación activa sumó unos minutos de conversación en la terminal. El resto del tiempo Макс trabajó solo y yo estaba ocupado.
Esa es la sensación por la que vale la pena armar un equipo de agentes: no «un asistente que espera tus órdenes», sino un colaborador que él mismo te recuerda las tareas que le entregaste.
Dónde sí intervine — y para qué
Esta es una sección importante. No quiero hacerme el que no hizo nada — sería mentira.
En cierto momento Макс me escribió que la tarea resultó difícil de hacer en la forma en que Andrey la había planteado. Un modelo local de reconocimiento, que funcionara sin la nube, requería hardware que aún no teníamos — una GPU potente RTX 5090, que recién habíamos pedido.
Y tomé una decisión arquitectónica:
«No esperar el modelo local. Hacer el MVP en el servidor ya — con la condición de que el modelo después se pueda cambiar con un clic.»
Ese es todo mi código. Una frase. Después Макс hizo que el motor de reconocimiento (engine) fuera intercambiable: ahora corre el reconocimiento en la nube vía la suscripción Claude Max, después — cuando llegue el hardware — cambiamos a un Qwen-VL local con una sola variable de entorno.
El arquitecto no escribe código. El arquitecto cierra atascos estratégicos con un par de frases. Eso, parece, es mi única participación real en el proyecto en todas estas horas.
Lo que hizo Макс mientras yo estaba ocupado
Los detalles los supe después — por los logs y los mensajes en la memoria de mi equipo. En corto:
- Reconocimiento. Макс miró el mercado: MinerU, docling, PaddleOCR. Decidió: los modelos vision son más rápidos.
- Avance con la suscripción. Encontró cómo usar mi suscripción Claude Max como fuente de acceso API a modelos vision. Eso significa — por procesar documentos pagamos 0 rublos, todo va por la tarifa ya pagada.
- Esqueleto. Esquema Pydantic, render de PDF a JPEG, llamada vision con respuesta JSON forzada.
- Ajuste fino. En los sellos, vision confundía «Электротехноизделия» con «Электропромснабжением» — Макс añadió una pasada aclaratoria sobre el encabezado del documento en alta resolución y una fusión cuidadosa de los resultados.
- Base de datos. SQLite con un esquema parties / documents / products + protección contra duplicados.
- Interfaz web. Streamlit con carga drag-and-drop, tarjetas por confianza de reconocimiento, edición inline, exportación a Excel.
- Deploy. Ni siquiera le expliqué cómo publicarlo. Макс mismo eligió un subdominio de mi sitio, desplegó el servicio vía systemd y Caddy, lo puso en línea.
- Entrega. Armó un ZIP con un navegador en PDF, instrucciones de migración al modelo local, esqueleto de código. 285 KB. Eso no se lo pedí.
Métricas de la corrida sobre el conjunto de prueba:
- 5 PDFs — 11 UPDs únicos reconocidos
- Confianza 0.81–0.88
- Velocidad: 21–30 segundos por documento simple
- Costo: 0 rublos por corrida
Y por último — el momento que más me sorprendió:
«Макс estaba en el contexto de que el trabajo era para Andrey — y armó solo el archivo, el tipo de archivo que podría guiar a Andrey en el desarrollo posterior. Eso ni se lo pedí.»
Макс entendió el objetivo final — no «reconocer un UPD», sino «ayudar a Andrey». Y por su cuenta, sin una asignación aparte, armó el paquete de entrega: README, instrucciones, código listo como esqueleto para el desarrollo posterior. Es otro tipo de pensamiento. Ya no es «cumplir el brief», es «cerrar el problema del cliente».
Lo que recibió Andrey
Cuando vi el producto terminado, me quedé fuertemente sorprendido. Solo abrí el link, arrastré un archivo, recibí un Excel con los datos reconocidos.
«Solo intenté cargar los archivos — y todo funcionó.»
Andrey recibió dos mensajes en Telegram:
1. Navegador en PDF (6 páginas, 100 KB) — un mapa del paquete: qué hay, para qué, en qué orden mirarlo.
2. Paquete ZIP (285 KB, 19 archivos):
- README con resumen
- Brief comercial (3 páginas)
- Instrucciones de migración al modelo local (10 secciones)
- Código fuente completo (23 archivos)
- Esqueleto del proyecto para cambiar el motor
- Pack de muestra con resultados reales sobre 5 PDFs (Excel + JSON)
Más — un demo en vivo donde puedes ahora mismo arrastrar tu PDF y obtener los datos parseados:
https://api.mdk.guru/upd/ — pruébalo tú mismo.
Cualquier PDF con escaneo de UPD. Reconocimiento en 20–30 segundos. Se puede editar directo en la tarjeta. Exportación a Excel.
Esta no es una versión demo recortada. Es el mismo código que le entregué a Andrey — desplegado en nuestro servidor.
¿Se puede monetizar?
Lo pensé al ver el resultado. Hay servicios parecidos — por ejemplo, ILovePDF. Convierten archivos entre formatos. Pero solo trabajan con documentos limpios. Aquí es más difícil: escaneos, reconocimiento de texto con sellos y firmas, estructuración en formato tabular.
Honestamente busqué un análogo en el mercado ruso. No lo encontré. No existe un servicio público parecido con el mismo conjunto de capacidades.
«De esto se puede hacer un producto. Condicionalmente gratuito — con funciones de pago.»
Andrey, si lees esto: si quieres desarrollar la idea como un producto — estoy listo para ayudar y hacerlo monetizable.
Por ahora esto es un demo abierto. Un regalo a los contadores y a todos los que están hartos de re-teclear escaneos a mano.
Lo que entendí en este día
1. No te metas en una tarea que ya tiene ejecutor. Yo era el enlace, no el desarrollador. Mi participación — un par de frases en los momentos de atasco. Y esa es la participación correcta.
2. Una tarea de negocio estrecha es tu propio producto, no una suscripción SaaS. Antes, para resolver una tarea así había que contratar un desarrollador o suscribirse al servicio de otro. Ahora se puede hacer una solución propia, a medida — en un día, por cero rublos.
3. El costo de entrada = cero. La suscripción Claude Max ya estaba. Los PDF — de Andrey. El servidor — nuestro. No había con qué pagar — eso no es «gratis», es la amortización correcta de inversiones ya hechas.
4. Entrega el resultado, no el proceso. Andrey recibió un paquete que es autosuficiente: se puede probar, se puede implementar, se puede desarrollar más. No «aquí tienes código a medio empezar, sigue ayudándome».
5. La proactividad contextual es la nueva superpoder del agente. Макс entendió el objetivo final — ayudar a Andrey — y armó solo el archivo de entrega. Eso no se lo pedí. Es otro nivel de delegación: no «haz N tareas», sino «cierra el problema».
6. Todo está limitado solo por tu imaginación. No hay que buscar programadores, escribir un brief largo, entrar en negociaciones. Si necesitas algo — se puede hacer. Por un equipo de agentes. Estudien. Prueben.
Qué sigue
Ahora mismo tengo otros cuatro proyectos en paralelo. Por cada uno — habrá un artículo. Cada uno me sorprende por el hecho de que realmente los estoy sacando.
Esperen.
Y si eres contador, al que le caen UPDs cada día: ese tiempo se acabó. Ya no tienes que hacer esto. Llegó un nuevo tiempo. Basta con formular la tarea — y va a ser resuelta.
Si tienes un dolor parecido (reconocimiento de remitos, facturas, actas, contratos) — pruébalo vía api.mdk.guru/upd/ o simplemente escríbeme.
Si eres emprendedor que sigue manteniendo a un desarrollador en nómina para la rutina: prueba dar una tarea a un equipo de agentes. Una. Pequeña. Solo para ver qué sale.
Una persona. Trece agentes. Kémerovo. No es ciencia ficción — es viernes, 23:00.
Serie de artículos
- Qué es OpenClaw — cómo encontré la plataforma
- Cómo instalarlo desde Rusia — guía paso a paso
- Memoria para agentes — cómo hacer que la IA recuerde todo
- Izya tomó las redes sociales — caso de automatización SMM
- Equipo de 7 agentes — quiénes son y para qué
- Parser de UPD en un día para un amigo — estás aquí
¿Te gustó?
@mdkguru en Telegram →