¿Qué pasa cuando cualquiera puede crear software?
Me metí en el barro para desplegar un servicio end-to-end y acabé redescubriendo la importancia de las plataformas
Hay una frase que empieza a aparecer en conversaciones donde, hace dos años, habría sonado exagerada: “ahora cualquiera puede programar”. No significa que todo el mundo vaya a escribir sistemas distribuidos ni que, de repente, la ingeniería deje de ser una disciplina. Significa algo más práctico: que un porcentaje creciente de los problemas que antes requerían un equipo de ingeniería ahora se resuelven con intención, herramientas y algo de criterio.
Por eso llama la atención ver a ingenieros históricamente escépticos como Salvatore Sanfilippo (Redis) o Ryan Dahl (Node.js) reconocer que los LLMs cambian el significado de “construir” en el día a día. Y por eso también es significativo que un CEO como Tobi Lütke (Shopify) esté programando más que nunca. No, no es que crea que el CEO lo vaya a hacer todo él solito. Pero la realidad es que el umbral de entrada ha bajado lo suficiente como para que “hacer una herramienta” vuelva a ser una acción normal, no un proyecto.
La consecuencia de esto es fácil de describir y difícil de gestionar: se va a crear mucho más software dentro de las empresas y no solo desde ingeniería. Prototipos que se convierten en flujos reales. Automatizaciones internas que pasan de “hack” a “esto lo usa todo el equipo”. Integraciones que nacen en una tarde y, de casualidad, se convierten en infraestructura de facto.
Y ahí aparece la pregunta que me interesaba: si crear software deja de ser el cuello de botella, ¿qué pasa con las plataformas?
Me metí en el barro
Durante unos días, actué como si fuera un desarrollador más. La idea era hacerlo yo solo, sin recurrir al pair programming ni al conocimiento tribal. Seguí el onboarding estándar y desplegué un servicio backend de punta a punta, utilizando documentación y plantillas de autoservicio.
No lo hice para evaluar herramientas ni para sacar conclusiones del tipo “esto hay que migrarlo a X”. Lo hice para entender dónde aparece la fricción cuando intentas avanzar con lo que hay, y qué tipo de fricción es la que de verdad te frena.
El camino estándar™ tenía agujeros
Lo básico estaba: crear el repositorio, tener una plantilla, hacer la build, desplegarlo y verlo correr. Había pipelines de integración y despliegue continuos (CI/CD) para compilar, desplegar y ejecutar, así como métricas y logs. Vamos bien, ¿no? Pues no tanto. Cuando todo “más o menos funciona”, es fácil confundir la existencia con la coherencia y la dirección.
Por ejemplo, el soporte estaba repartido entre varios canales de Slack, lo cual no es grave hasta que te obliga a adivinar de antemano quién es responsable de qué. En la práctica, el sistema no te resuelve el problema: te pide que entiendas la organización para poder usarlo. Esto es una forma bastante típica de exportar carga cognitiva. No es que falte soporte. Es que el coste de “saber dónde preguntar” lo paga el usuario. Y ese coste no se ve en ningún dashboard, pero se nota en cada interrupción, en cada pregunta repetida y en cada minuto que inviertes orientándote en vez de avanzar.
Lo mismo me ocurrió con el onboarding. Se asumían demasiadas cosas: qué perfil de Spring Boot seleccionar, qué herramientas tener instaladas y qué configuraciones locales ya debían existir. Y como esas suposiciones no se validaban al principio — en las plantillas de autoservicio —, el sistema me dejaba avanzar hasta que, de repente, no podía. El resultado fue bastante tonto: cinco o seis idas y vueltas con CI que no eran bugs, sino prerrequisitos disfrazados.
Ahí es donde me vino a la cabeza la idea de leaky abstraction. En teoría, tenía una “plantilla estándar”. En teoría, esa abstracción estaba para que yo no tuviera que pensar en lo de siempre. En plan: genero el servicio, sigo el camino estándar y ya está. Pero tenía agujeros. Y cada agujero te empujaba a hacer justo lo contrario de lo que promete una plataforma: bajar de nivel, entender qué hay debajo y probar hasta acertar. Un ejemplo tonto pero real: si no elegías ciertas configuraciones o librerías “por definición”, el sistema no te lo decía pronto ni te guiaba hacia el valor por defecto correcto. Y entonces tocaba investigar, ajustar, volver a probar. En vez de construir, estaba adivinando. Y una plataforma existe precisamente para que no tengas que adivinar.
Hasta aquí, podríamos llamarlo fricción normal. El punto en el que esto se vuelve interesante es cuando aparece la automatización.
¿Qué es una plataforma?
“Plataforma” es una palabra con demasiada carga. En algunas empresas significa “infra”. En otras, es una excusa elegante para decir “el equipo que no entrega funcionalidades”.
A mí me sirve una definición más operativa:
Una plataforma es un conjunto de building blocks y caminos recomendados que permiten que equipos autónomos construyan y operen software sin tener que negociar cada detalle ni aprenderlo todo desde cero.
La palabra clave ahí no es “herramientas”, sino “coherencia”. Es una forma de tomar decisiones por adelantado para que no tengas que tomarlas cada vez. De hecho, si lo pensamos, los productos de plataforma que funcionan suelen compartir el mismo patrón: convierten decisiones repetidas en defaults razonables.
Un ejemplo genérico: imagina que un equipo quiere crear un nuevo servicio. En una empresa sin plataforma, ese equipo tiene que decidir mil cosas: cómo se despliega, cómo se observa, cómo se configura, qué librerías son estándar, cómo se gestionan los secretos, qué implica “listo para producción”. En una empresa con plataforma, gran parte de eso ya está resuelto en forma de plantillas, pipelines, guardrails y estándares ejecutables. No porque alguien quiera controlar, sino porque repetir esas decisiones una y otra vez es caro y, además, genera entropía.
La plataforma, en el fondo, es el mecanismo que permite la autonomía sin fragmentación.
En un mundo post-IA, automatizar deja de ser el problema
En el flujo de despliegue había varios puntos que pedían automatización a gritos. El ejemplo más obvio era el aprovisionamiento de una base de datos. Es el típico paso mecánico que, en cuanto lo haces dos veces, piensas: “vale, esto debería estar automatizado”.
Lo interesante es que hace unos años, ahí, la conversación solía morir. Automatizarlo bien podía implicar tocar el tooling, mantener scripts, pelearse con los permisos, integrarlo en la CI o empaquetarlo en un CLI. Y si estabas en un equipo de producto, era fácil justificar lo contrario: “esto es una distracción, ya lo haremos cuando duela más”. El coste era suficientemente alto como para que, por definición, la actitud fuera dejarlo manualmente.
Ahora el coste ha bajado muchísimo. No solo por los LLMs, sino también porque construir automatizaciones pequeñas resulta más accesible para más gente. El punto ya no es si alguien puede hacerlo. El tema es saber dónde hacerlo para que sume y no genere una solución paralela.
Y ahí me quedé bloqueado. Me empecé a preguntar: ¿Esto vive en un CLI? ¿En una plantilla? ¿En el pipeline? ¿Qué se considera “el sitio correcto” en esta empresa para automatizar este tipo de tareas? Cuando la respuesta no está clara, el sistema empuja a dos comportamientos muy humanos: o lo dejas manual, o lo automatizas en local “para salir del paso”. Y lo gracioso es que, en un mundo donde automatizar es barato, ambos caminos salen caros. Uno, porque desperdicia capacidad, y el otro, porque fragmenta. Empiezan a aparecer golden paths privados, scripts que funcionan “en mi máquina” y automatizaciones que no encajan con el resto de la plataforma.
En cambio, cuando hay dirección y principios explícitos, el efecto es el contrario. Si el estándar es algo tan concreto como: “los golden paths de aprovisionamiento se construyen con Scaffolder en Backstage”, de repente la empresa entera puede empujar en la misma dirección. No hace falta coordinar a veinte equipos. Hace falta que la regla sea clara, el camino sea fácil y los guardrails estén donde toca.
Ese es, para mí, el cambio grande post-IA: la capacidad de crear automatización se dispara, pero solo se convierte en velocidad real cuando la plataforma ofrece un sitio, un patrón y límites. Ahí es cuando pasas de tener automatizaciones sueltas a contar con una plataforma que acumula automatizaciones, refuerza los defaults y reduce el coste de moverse rápido sin romper cosas.
Las plataformas más importantes que antes, no menos
Durante años hemos hablado de plataformas internas como una inversión para acelerar la ingeniería: reducir el toil, estandarizar buenas prácticas y permitir que los equipos de producto entreguen sin pelearse con la infraestructura. Eso tenía sentido porque el cuello de botella era la escasez de ingeniería y el coste de construcción.
Si ese cuello de botella se debilita, podrías pensar que las plataformas pierden relevancia. Pues no. Es justo lo contrario.
Cuando se va a crear mucho más software, desde muchos más sitios, el problema principal deja de ser la velocidad de un equipo y pasa a ser la coherencia del conjunto. La plataforma se convierte en el mecanismo que hace que un aumento de la capacidad de creación se traduzca en valor y no en un mosaico de automatizaciones incompatibles, decisiones repetidas y deuda organizativa.
¿Cómo cambia el trabajo de los equipos de plataforma?
Aquí es donde creo que muchos equipos de plataforma se van a equivocar por inercia. No nos engañemos. Somos ingenieros y la respuesta fácil es construir más cosas. Más tooling, más features en la plataforma, más abstracciones. Eso tranquiliza porque se parece a lo que siempre hemos hecho: “vemos fricción, construimos una herramienta”.
Pero el trabajo crítico no es “hacer más”. Es hacer que otros puedan hacerlo sin desalinearse. El resultado no es solo software. Es claridad operativa.
Building blocks sólidos y reutilizables para que la empresa no tenga que reinventar lo básico cada vez.
Golden paths que no sean “recomendaciones”, sino caminos que el sistema haga naturalmente fáciles, porque ya incluyen los defaults correctos.
Guardrails ejecutables allí donde de verdad importe la consistencia, porque si algo depende de que la gente lea un documento, en la práctica depende del azar.
Principios y límites explícitos: qué se automatiza, dónde se ubica esa automatización y qué significa “bien” en ese contexto.
En el fondo, lo que la empresa necesita no es más libertad para crear. Eso ya está llegando. Lo que necesita es un marco en el que esa libertad no genere entropía.
Cerrando el círculo
Sí, al final desplegué el servicio. Pero lo que más me interesaba no era “si se podía”, sino qué hice después de ver dónde estaban los agujeros. Porque ahí es donde, para mí, se decide si esto se queda en una anécdota o se convierte en plataforma. Hice dos cosas:
Abrí dos Pull Requests (PRs) para mejorar los guardrails del camino estándar. No eran cambios heroicos. Eran los típicos checks que evitan que el sistema te deje avanzar con una configuración incompleta y estrellarte diez minutos después en CI. Total, hoy puedes ponerte a iterar rápido — sí, incluso con Claude en un tab del terminal — y convertir ambigüedades en defaults ejecutables.
Documenté un conjunto de recomendaciones para los equipos que mantienen la plataforma. No en plan “hay que rehacerlo todo”, sino en plan “estos son los sitios donde el sistema está exportando carga cognitiva, y estas son las decisiones que convendría cerrar para que la empresa entera pueda empujar en la misma dirección”.
En resumen: pude desplegar el servicio. También pude abrir dos PRs para mejorar los guardrails del camino estándar. Eso, hoy, es barato. Lo caro es seguir dejando que cada persona pague el coste de orientarse, de probar hasta acertar y de reinventar el estándar en local.
Vale… ¿y ahora qué?
Cuando “hacer software” deja de ser una actividad rara y cara, la pregunta deja de ser “¿cómo hacemos para construir más?”. Pasa a ser: “¿cómo hacemos para que lo que se construye no se convierta en un puzzle imposible?”.
En ese mundo, las plataformas no desaparecen. Se convierten en el sitio donde decides qué va a escalar en tu empresa: la capacidad de creación o la complejidad de mantenimiento.
Y lo más frustrante es que no se decide con un gran rediseño ni con una migración épica. Se decide cerrar unas pocas cosas, hacerlas explícitas y convertirlas en caminos y guardrails ejecutables. Lo suficiente como para que automatizar sea barato, sí, pero también acumulativo.
— João
Tienes alguna referencia más al concepto de exportar carga cognitiva?
Le has puesto nombre a algo que veo hace tiempo en algunos equipos, es que asumen que todo el mundo va a tener el mismo contexto