Cuando un CEO decide codear: La historia de Bricks & Walls y el día que la IA reescribió las reglas del juego
Bricks & Walls nació como muchas empresas de tecnología: con una idea clara, un equipo talentoso y la convicción de que la calidad no se negocia. En poco más de una década, B&W se convirtió en una software factory de 90 personas que desarrolla aplicaciones móviles, plataformas web, ecommerce, integraciones con ERPs y servicios de consultoría estratégica para empresas de toda la región.
Por el equipo editorial de B&W Tech | 2026
90 personas. 12 proyectos. Un cuello de botella invisible.
Bricks & Walls nació como muchas empresas de tecnología: con una idea clara, un equipo talentoso y la convicción de que la calidad no se negocia. En poco más de una década, B&W se convirtió en una software factory de 90 personas que desarrolla aplicaciones móviles, plataformas web, ecommerce, integraciones con ERPs y servicios de consultoría estratégica para empresas de toda la región.
El organigrama era sólido. Un CEO con 30 años de experiencia y maestría en inteligencia artificial. Un Gerente Comercial que no paraba de traer oportunidades. Un Gerente de Tecnología que conocía cada línea de arquitectura. Gerentes de Proyecto que orquestaban sprints con precisión quirúrgica. Developers, testers, diseñadores UX/UI, DevOps, marketing, recursos humanos, administración, tesorería. Todo en su lugar.
El stack técnico era moderno y probado: Figma para diseño, React y Next.js en el front-end, Node.js y NestJS en el back-end, MongoDB y MySQL como bases de datos, Python para automatizaciones y data, RabbitMQ para mensajería asíncrona, AWS SES para envío de correos transaccionales, WordPress para sitios corporativos, y todo desplegado sobre Google Cloud con pipelines de CI/CD en Jenkins, repositorios en BitBucket y gestión en Jira.
Contratos de soporte post-venta de 3, 6 y 12 meses garantizaban que cada plataforma entregada siguiera evolucionando. Los clientes confiaban. El pipeline comercial crecía.
Pero algo no cuadraba.
El problema que nadie quería nombrar
Las señales estaban ahí, silenciosas como una fuga de agua detrás de la pared.
El análisis tomaba semanas. Cada nuevo proyecto requería reuniones interminables de levantamiento de información. Documentos de requerimientos que iban y venían. Preguntas que generaban más preguntas. Para cuando el equipo tenía claridad, ya habían pasado 3 o 4 semanas — y el cliente empezaba a impacientarse.
Las iteraciones de UX no terminaban. El equipo de diseño producía wireframes, los presentaba, recibía feedback, rediseñaba, volvía a presentar. Tres, cuatro, cinco rondas de revisión antes de que alguien dijera “ahora sí”. No era falta de talento — era un proceso que no tenía un mecanismo para converger rápido.
Las estimaciones eran una lotería. ¿Cuánto toma este módulo de front-end? “Dos semanas.” ¿Y el back-end? “Tres semanas, tal vez cuatro.” ¿Y los tests? “Depende.” Cada estimación cargaba un margen de incertidumbre que se acumulaba sprint tras sprint, erosionando la predictibilidad y la confianza del equipo comercial al momento de cotizar.
Los proyectos se bloqueaban entre sí. Con 12 proyectos activos y recursos compartidos, mover una pieza en un tablero significaba paralizar otro. Un developer senior asignado a una integración con SAP no podía ayudar con el ecommerce que se estaba retrasando. Un tester ocupado en regresión de una app móvil dejaba sin cobertura al proyecto web que estaba por salir a producción.
Y lo más frustrante: nuevos proyectos no podían entrar. El Gerente Comercial cerraba oportunidades que el equipo de tecnología no podía absorber. No por falta de capacidad técnica, sino por falta de ancho de banda. Cada “sí” a un cliente nuevo significaba un “espera” a otro.
B&W no tenía un problema de talento. Tenía un problema de velocidad.
El CEO que no se quedó mirando
Aquí es donde la historia se pone interesante.
El CEO de B&W no era un ejecutivo de escritorio. Con 30 años en la industria y una maestría en inteligencia artificial, había escrito código antes de que muchos de sus developers nacieran. Conocía la diferencia entre un ORM mal configurado y un problema de arquitectura. Sabía leer un flame chart. Entendía qué significaba realmente “deuda técnica”.
Y tenía una inquietud que no lo dejaba dormir: ¿Qué pasaría si la IA generativa no fuera solo un chatbot para responder preguntas, sino un ingeniero de software que pudiera trabajar al lado del equipo?
Empezó a experimentar. Primero con Cline, una herramienta de coding asistido que le permitió automatizar tareas repetitivas en sus proyectos personales. Los resultados fueron prometedores, pero limitados. La herramienta era buena para autocompletar, no para pensar.
Luego probó Google Antigravity, buscando la potencia de los modelos de Google aplicada al desarrollo. Interesante, pero le faltaba profundidad en razonamiento complejo y la capacidad de orquestar tareas de principio a fin.
Y entonces llegó Claude Code.
El momento en que todo cambió
La primera vez que el CEO abrió Claude Code con el modelo Opus 4.6, no esperaba lo que sucedió.
Le pidió que analizara un documento de requerimientos de 47 páginas de un proyecto real de B&W — uno que al equipo le había tomado 3 semanas entender, desglosar y convertir en historias de usuario.
Claude Code lo hizo en 23 minutos.
No solo extrajo los requerimientos funcionales y no funcionales. Identificó ambigüedades que el equipo había pasado por alto. Sugirió preguntas de clarificación para el cliente. Propuso una arquitectura técnica compatible con el stack de B&W. Y generó un backlog preliminar en formato Jira-ready con criterios de aceptación.
El CEO se quedó mirando la pantalla. Releyó todo. Buscó errores. Encontró dos observaciones menores que corrigió en segundos.
“Esto no es autocompletado”, pensó. “Esto es un ingeniero senior que trabaja a la velocidad de la luz.”
La arquitectura de la revolución
Lo que siguió fue un proceso metódico, como corresponde a alguien con 30 años de experiencia. El CEO no salió corriendo a reemplazar a nadie. Se sentó, diseñó un flujo de trabajo y lo probó en proyectos internos antes de escalarlo.
La configuración que encontró óptima fue:
-
Claude Code con Opus 4.6 para planning: análisis de requerimientos, diseño de arquitectura, definición de estrategia técnica, research de mercado, estimaciones basadas en complejidad real del código.
-
Claude Code con Sonnet 4.6 para ejecución: generación de código, implementación de componentes, pruebas unitarias, configuración de pipelines, documentación técnica.
-
Plugins y Skills que extendían las capacidades base: investigación de mercado automatizada, generación de esquemas de base de datos, scaffolding de proyectos completos con la estructura de B&W.
-
MCP (Model Context Protocol) para conectar Claude Code directamente con las herramientas del ecosistema: repositorios en BitBucket, tableros en Jira, documentación interna, bases de datos de conocimiento.
-
Agentes en paralelo que podían trabajar simultáneamente en diferentes aspectos del mismo proyecto: uno analizando el front-end, otro diseñando el back-end, otro escribiendo tests, otro documentando — todos coordinados, todos consistentes.
El resultado fue demoledor.
Los números que nadie esperaba
| Actividad | Tiempo tradicional | Con Claude Code | Reducción |
|---|---|---|---|
| Análisis y levantamiento de información | 2-4 semanas | 2-4 horas | 95% |
| Diseño UX (wireframes + iteraciones) | 2-3 semanas | 1-2 días | 85% |
| Estimación técnica de un proyecto completo | 1 semana | 30-60 minutos | 95% |
| Scaffolding de proyecto (front + back + DB) | 3-5 días | 20-40 minutos | 97% |
| Pruebas unitarias y de integración | 1-2 semanas | 2-4 horas | 90% |
| Documentación técnica | 1 semana | 1-2 horas | 95% |
Pero los números no cuentan toda la historia.
Lo que realmente cambió fue el flujo. Ya no había cuellos de botella. El CEO podía tomar un proyecto nuevo, hacer el análisis completo, generar la arquitectura, crear el scaffolding, escribir las primeras iteraciones de código — todo antes de que el equipo terminara su standup de la mañana.
No estaba reemplazando al equipo. Estaba desbloqueándolo.
La revelación más difícil
Aquí viene la parte que nadie quiere escuchar, pero que toda empresa de tecnología necesita confrontar.
Un CEO, trabajando solo con Claude Code, estaba produciendo el equivalente a lo que un equipo de 8-10 personas hacía en semanas. No porque el equipo fuera malo — eran profesionales competentes, dedicados, con años de experiencia. Sino porque el modelo tradicional de desarrollo de software tiene fricción inherente:
- Fricción de comunicación: reuniones, correos, mensajes, malentendidos, aclaraciones.
- Fricción de contexto: cada persona tiene una vista parcial del proyecto; nadie tiene la imagen completa en la cabeza al mismo tiempo.
- Fricción de coordinación: dependencias entre tareas, esperas por code review, bloqueos por disponibilidad.
- Fricción de conocimiento: “¿Cómo funciona esta API?” “¿Qué patrón usamos para esto?” “¿Dónde está la documentación?”
La IA no elimina la necesidad de talento humano. Pero elimina la fricción. Y cuando eliminas la fricción, descubres que el 70% del tiempo de un proyecto no se va en construir — se va en prepararse para construir.
Lo que esto significa para el futuro
El CEO de B&W no publicó un comunicado interno diciendo “la IA nos va a salvar”. No despidió a nadie el lunes siguiente. Lo que hizo fue algo más inteligente y más difícil: empezó a rediseñar la empresa.
La visión es clara:
Fase 1 — Augmentación: Equipar a cada developer, diseñador y PM con herramientas de IA que multipliquen su capacidad individual. Un developer con Claude Code no es un developer — es un developer con un equipo de soporte invisible que nunca duerme, nunca se distrae y nunca olvida el contexto.
Fase 2 — Rediseño de procesos: Los procesos de B&W fueron diseñados para humanos trabajando sin IA. Análisis de 3 semanas, diseño de 2 semanas, desarrollo de 6 semanas. Esos timelines ya no tienen sentido. Los procesos necesitan rediseñarse desde cero, asumiendo que la IA es parte del equipo desde el día uno.
Fase 3 — Escalabilidad real: Con la fricción eliminada, B&W puede tomar más proyectos, entregar más rápido, mantener más plataformas y — esto es lo más importante — dedicar más tiempo a lo que realmente importa: la estrategia, la innovación, la relación con el cliente, la calidad que no se puede automatizar.
Una reflexión para quienes lideran empresas de tecnología
Si estás leyendo esto y diriges una empresa de desarrollo, una software factory, una consultora tecnológica — hazte esta pregunta:
¿Cuánto del tiempo de tu equipo se va en fricción?
No en construir. No en innovar. No en resolver problemas difíciles. Sino en esperar, coordinar, documentar, estimar, reunirse, aclarar, iterar, re-estimar.
La IA generativa aplicada al desarrollo de software no es una amenaza para tu equipo. Es una amenaza para la ineficiencia que has normalizado.
El CEO de Bricks & Walls no descubrió que su equipo sobraba. Descubrió que su equipo estaba atrapado. Atrapado en procesos diseñados para una era en la que la única forma de escribir código era teclearlo línea por línea, la única forma de analizar requerimientos era leerlos párrafo por párrafo, y la única forma de estimar era adivinar con experiencia.
Esa era terminó.
La pregunta no es si la IA va a cambiar tu empresa de tecnología. La pregunta es si vas a ser tú quien lidere ese cambio — o si vas a leer sobre cómo lo hizo otro.
Bricks & Walls Tech Company (B&W) es una empresa ficticia creada para ilustrar un escenario que, aunque narrado como historia, refleja dinámicas reales que están ocurriendo hoy en empresas de tecnología alrededor del mundo. Las herramientas mencionadas — Claude Code, Opus 4.6, Sonnet 4.6, MCP, Cline — son productos reales. Los resultados descritos están basados en experiencias documentadas de profesionales que han adoptado estas tecnologías en flujos de trabajo de producción.