Presentamos el SDLC para Ciudadanos Desarrolladores de Tenex, un ciclo de vida de seis etapas que transforma lo que los empleados no técnicos construyen con IA, desde un prototipo personal hasta un producto en producción en el que toda la empresa puede confiar.
Por Alex Lieberman (@businessbarista), Arman Hezarkhani (@ArmanHezarkhani, Suchi Patel y Ashwin Kadaru (@AshwinKadaru
Un marco de Tenex.co.
El resumen
El SDLC Ciudadano es un ciclo de vida de seis etapas (idea, puerta de entrada, triaje, aprovisionamiento, construcción, ejecución y cambio) que lleva el software construido por empleados no técnicos con IA, desde un prototipo personal hasta una producción gobernada. Un principio recorre cada etapa: la IA hace el trabajo, el código determinista establece las barreras de protección, y los humanos manejan las excepciones. Existe porque la IA redujo el costo de escribir código a casi cero y movió el cuello de botella río abajo, a asegurar que lo construido sea sólido y mantener una flota creciente de aplicaciones gobernadas una vez en producción.
Uno de nuestros clientes es una firma de inversión. Un miembro de su equipo de operaciones de portafolio, alguien que nunca había escrito una línea de código, construyó el panel que todo su equipo usa ahora a diario. Rastrea el trabajo de creación de valor en docenas de empresas del portafolio. Lo construyó indicándole a Claude, iterando durante unos dos meses. Cada línea fue escrita por IA.
Y es bueno. Las vistas son correctas, el flujo de trabajo se ajusta a cómo opera realmente el equipo, y la adopción fue inmediata. Ella bosquejó el producto correcto antes de que ningún ingeniero participara.
Eso no es suerte. Durante décadas, la persona que entendía un problema de negocio casi nunca era la que podía construir el software para solucionarlo. Cerrar esa brecha era un esfuerzo titánico: un gerente de producto para convertir su problema en una especificación, ingenieros para traducir la especificación a código, y un lugar en la fila detrás de todo lo demás en el roadmap. Pasaban meses entre la idea y la herramienta, y lo que finalmente se lanzaba era la interpretación de otra persona de lo que ella quiso decir.
Esa brecha acaba de colapsar. El poder de construir se ha trasladado a las personas que realmente entienden el proceso, saben lo que significan los datos y viven en el flujo de trabajo todos los días. Ella construyó lo correcto en el primer intento porque ella era la fuente. Nadie se interpuso para traducirla, o para hacerlo ligeramente mal. Esa es la promesa del desarrollo ciudadano, y ella la cumplió.
Luego miramos bajo el capó.
Toda la aplicación era un solo archivo HTML. 540 KB. Alrededor de 5,300 líneas. El conjunto de datos maestro vivía dentro de él como un blob de 80 KB de datos en una sola línea. Cuando el archivo necesitaba actualizarse, la IA había añadido funciones de parche que reescribían valores cada vez que la aplicación se cargaba. Guardar tu trabajo significaba que la aplicación reescribía su propio HTML, se descargaba a tu laptop, y tú lo volvías a subir a una unidad compartida como una nueva versión. Si dos personas editaban al mismo tiempo, el último en guardar ganaba, y las ediciones de la otra persona desaparecían.
Un día, una función de guardado buscó un marcador en el archivo, no lo encontró, y devolvió lo que tenía de todos modos. Toda la aplicación de 540 KB se truncó a 7 bytes. En una sola escritura silenciosa, el panel en el que su equipo confiaba cada día dejó de existir, y nada en la forma en que fue construido estaba diseñado para detectarlo, detenerlo o recuperarlo.
La mayoría de los líderes escuchan esa historia y concluyen que el desarrollo ciudadano es un riesgo que debe cerrarse. Creemos que esa es la lección equivocada, y las empresas que actúen en consecuencia van a perder. La lección correcta: ella hizo su trabajo de manera brillante. Nadie había construido el camino para que el software se enviara.
El cuello de botella se movió
Durante décadas, construir software era la parte costosa. Era lento, escaso y caro, y todo el ciclo de vida del desarrollo de software creció para protegerlo. Especificaciones, tickets, sprints, revisión de código: cada ceremonia en el SDLC tradicional existe porque escribir el código era el cuello de botella.
La IA colapsó esa etapa a casi cero, y el cuello de botella se ha movido. Cuando cualquiera puede construir una aplicación funcional en una tarde, el trabajo costoso ya no es la construcción. Es lo que viene después: asegurarse de que lo construido sea sólido y seguro, y mantener una flota creciente de estas aplicaciones gobernadas una vez que están en vivo.
GIF
Y la construcción no se está desacelerando, creando dos problemas que deben resolverse:
Primero, calidad bajo el capó. Un agente al que se le indica desde una página en blanco por un no ingeniero converge en un software chapucero que funciona hoy y es imposible de mantener para siempre. El archivo de 540 KB no es una excepción; es el resultado predeterminado de construir sin rieles.
Segundo, expansión descontrolada. Cada equipo quiere su propia aplicación, y ningún grupo central de TI puede construir y operar docenas a mano. Sin barreras de protección, cada una se construye sobre la pila que el constructor o el modelo eligió: una base de datos diferente, un esquema de autenticación diferente, secretos guardados donde sea que caigan. Bloquea las solicitudes y no se detienen, solo se vuelven no oficiales. De cualquier manera, heredas no solo una flota de aplicaciones, sino el enredo de infraestructura debajo de ellas, y nada de eso es algo que TI pueda asegurar, soportar o explicar razonablemente.
Entonces, la verdadera pregunta que toda empresa enfrentará: ¿cómo dejas que el personal no técnico envíe software interno real sin heredar esa flota?
Las tres respuestas predeterminadas fallan:
1) Bloquearlo. Las solicitudes se acumulan, la paciencia se agota y las aplicaciones ocultas se construyen de todos modos. Ahora no puedes ver nada de eso. No puedes gobernar lo que no puedes ver.
2) Dejarlo fluir. Apunta a los no ingenieros a herramientas de IA sin estructura y celebra las demostraciones. Así es como obtienes el archivo de 540 KB. Y no puedes revisar para salir de eso después del hecho. Para cuando un monolito aparece en la revisión de código, ya es un monolito. Tiene que prevenirse en el punto de partida.
3) Revisar todo. Pon una aprobación humana en cada cambio. Tu equipo de TI es reducido, el volumen de construcción está explotando, y ahora cada implementación espera el calendario de un revisor. Las revisiones matan la adopción o se convierten en un trámite. Ambos resultados frustran el propósito.
Entonces, la respuesta no es otro documento de políticas, sino un ciclo de vida: un SDLC real, diseñado para personas que nunca se llamarán a sí mismas desarrolladores, con barreras de protección integradas en la plataforma en lugar de escritas en un memo. Un camino que lleva una construcción desde la primera idea en lenguaje sencillo hasta la producción gobernada, sin pedirle al constructor que se convierta en ingeniero. La persona proporciona la intención; la plataforma proporciona la disciplina.
Un principio recorre cada etapa: la IA hace el trabajo, el código determinista establece las barreras de protección, y los humanos manejan las excepciones. La IA redacta, clasifica y escribe. El código decide qué está permitido. Las personas se utilizan solo donde se requiere juicio. Aférrate a esa división; es lo que hace que todo escale.
Lo llamamos el SDLC Ciudadano. Seis etapas, cada una gobernada.
Etapa 1
La idea
Una persona describe la aplicación en lenguaje sencillo, con ayuda de la IA: qué hace, quién la usa, qué datos toca, quién es el dueño. Toma minutos y se lee como un memo. También sirve como el resumen sobre el que se ejecuta todo lo que sigue. Este es el primer movimiento del modelo operativo: la IA hace el trabajo de convertir una divagación en un artefacto estructurado.
Así es como se ve en la práctica. Alguien en finanzas del fondo escribe: "Quiero un rastreador para avisos de llamadas de capital. Ahora mismo es una hoja de cálculo que actualizo a mano y envío por correo electrónico cada viernes". La IA pregunta lo que preguntaría un analista de admisiones. ¿Quién más necesita verlo? Doce personas entre finanzas del fondo y relaciones con inversores. ¿Dónde viven los datos hoy? Una hoja de cálculo en Box, y con solo lectura está bien. ¿Quién es el dueño cuando no estás? Su gerente. La divagación se ha convertido en un resumen: propósito, usuarios, fuente de datos, nivel de acceso, propietario, incluso una primera estimación de la forma de la aplicación. Un PRD, en efecto, escrito por alguien que nunca ha oído hablar del término PRD.
GIF
Todavía no existe nada. Sin código, sin acceso, sin infraestructura. Eso es deliberado: la firma forma una opinión sobre la aplicación antes de que exista la aplicación, en lugar de seis meses después de que sea crítica.
Etapa 2
La puerta de entrada
Cada solicitud pasa por una única puerta de entrada estructurada, y el mismo movimiento que la archiva la coloca directamente en triaje. El resumen es la solicitud, el ticket que ve TI, el registro permanente y una entrada en un catálogo que todos pueden buscar, todo a la vez. Sin preguntas en el pasillo, sin favores, sin canal oculto. No puedes gobernar lo que no puedes ver, y no puedes compartir lo que no puedes encontrar. La puerta de entrada hace que ambas sean ciertas desde el día uno.
Esta es la etapa que mata el canal oculto. Una construcción que salta la puerta de entrada puede seguir existiendo como un prototipo en una laptop, pero ahí se queda. Todo lo que convierte un prototipo en software en el que un equipo puede confiar vive río abajo de esta etapa: almacenamiento real, inicio de sesión de la firma, un pipeline de implementación, un lugar donde ejecutarse. Nada de eso llega a una construcción que nunca pasó por la puerta. Puedes evitar la puerta de entrada; simplemente no puedes pasar del prototipo si lo haces.
Etapa 3
El triaje
La IA clasifica la solicitud en dos ejes. Forma: ¿qué tipo de aplicación es? Una auditoría inversa de lo que los empleados realmente construyen casi siempre se reduce a una lista corta: generadores de artefactos, automatizaciones de flujo de trabajo, aplicaciones CRUD y paneles interactivos. Nombrar la forma te dice la arquitectura que necesita, y le entrega a la siguiente etapa el camino pavimentado para estampar. Radio de impacto: ¿cuánto daño podría hacer esta construcción si sale mal? Lo puntuamos en cuatro dimensiones:
- Alcance y capacidad: ¿qué puede tocar, y puede escribir o solo leer?
- Reversibilidad y autonomía: ¿hay un humano en el bucle, y se puede deshacer la acción?
- Exposición: ¿quién ve el resultado, y qué tan lejos viaja fuera de la empresa?
- Sensibilidad de los datos: ¿qué tan confidenciales son los datos con los que interactúa?
Pero aquí está la regla que hace que esto sea confiable: La IA aconseja. El código decide. El modelo lee el resumen y lo clasifica; luego, el código de políticas que TI escribió verifica cada clasificación contra las reglas. Míralo funcionar en el rastreador de llamadas de capital. Forma: panel interactivo. Radio de impacto: datos internos del fondo, doce usuarios internos, solo lectura, humano en el bucle, sin superposición con aplicaciones existentes. Cada dimensión cae dentro de los umbrales aprobados, por lo que está aprobado, y ningún humano discutió al respecto.
Ahora cambia un hecho. Digamos que el rastreador también necesita datos de compromisos de LP. El resumen puede ser tan persuasivo como quiera; ese único cambio eleva la dimensión de sensibilidad de datos por encima del umbral que TI estableció, y la solicitud va a una persona. No hubo un juicio de por medio. Una regla coincide o no.
Tres rutas de salida:
- Aprobado. Radio de impacto dentro de todos los umbrales, resumen completo, alta confianza. En nuestro cliente, aproximadamente 9 de cada 10 solicitudes se resuelven de esta manera, automáticamente.
- Reutilizar. Se superpone con una aplicación que ya existe, por lo que el solicitante es dirigido al propietario de esa aplicación en lugar de construir un duplicado. Los duplicados se fusionan, no se multiplican.
- Escalado. Una dimensión cruza su umbral, o la confianza es baja. Un humano de TI y Seguridad recibe la solicitud completa como contexto.
GIF
La décima solicitud, la excepción, sigue llegando al escritorio de un humano con el resumen completo adjunto. Las otras nueve nunca lo necesitaron.
Etapa 4
El aprovisionamiento
Aquí está el movimiento que permite que TI diga que sí en volumen: el aprovisionamiento no es que TI pierda el control de lo que se envía, sino que el control de TI se mueva río arriba. En lugar de revisar cada aplicación después del hecho, TI crea el camino pavimentado una vez, y cada aplicación nace en él. Una persona aprueba, y la plataforma estampa la aplicación desde el camino para su forma: un repositorio, inicio de sesión de la firma, una identidad de implementación, un entorno privado y su propia base de datos, todo definido como infraestructura como código que TI posee y versiona. Aprovisionado en minutos.
Este es el único momento en que se ejecuta un poder elevado, y un humano está al frente. Cada aplicación nace aislada, gobernada y auditada: su propio entorno amurallado, sin dirección pública, sin secretos almacenados en la nube, un registro de auditoría de solo agregar desde el día cero. El trabajo de seguridad ocurrió una vez, en el camino. Ninguna aplicación tiene que repetirlo.
Debido a que el camino se crea por forma, la aprobación humana es una postura predeterminada, no un impuesto permanente. Las formas novedosas y las construcciones de alto radio de impacto mantienen la puerta humana para siempre. Pero una vez que el camino de una forma ha demostrado su valía en suficientes construcciones, las solicitudes de bajo radio de impacto en ese camino pueden aprovisionarse automáticamente. Es la misma lógica de "guardar el juicio humano para la cola" aplicada una etapa antes: al principio, diriges más a una persona, y a medida que los patrones se mantienen, la línea se desplaza hacia la automatización.
Y el camino lleva una cosa más que importa tanto como la infraestructura: el libro de reglas de la IA. El repositorio heredado le entrega al agente de codificación un conjunto de instrucciones en cada sesión, codificando los antipatrones aprendidos de fallas reales. No incrustes blobs de datos de más de 1 KB. No agregues funciones que reescriban datos cuando la aplicación se carga. Así es como se resuelve la calidad bajo el capó sin pedirle al constructor que conozca una sola mejor práctica: el camino hace que el agente las siga. Cada una de esas reglas es una cicatriz con una historia detrás (ya has leído una de ellas).
Etapa 5
La construcción
El constructor indica a su agente de codificación (Claude Code, Codex, etc.) dentro de un espacio de trabajo controlado en la nube, nunca en su propia laptop. Un agente terminal en una laptop hereda todo lo que hay allí: correo, unidades sincronizadas, cookies del navegador, credenciales almacenadas en caché. En el espacio de trabajo, el agente ve el proyecto. Nada más.
Todo lo que un ingeniero normalmente llevaría lo llevan los rieles en su lugar: en nuestro cliente, 35 barreras de protección en cuatro capas que el constructor no puede desactivar.
La capa de fusión incluye verificaciones de desviación diseñadas específicamente para código generado por IA: presupuestos de tamaño de archivo, sin datos en línea sobredimensionados, conformidad con el registro de auditoría. Verde o no se fusiona. Cuando una verificación falla, el constructor le pide al agente que lo arregle y vuelve a enviar.
Los humanos no revisan cambios rutinarios. Las verificaciones son la revisión. Los cambios rutinarios se mueven a la velocidad de CI, no a la velocidad del calendario de un revisor. Lo que llega a un humano es la cola consecuente, detectada mecánicamente: cambios destructivos en el esquema, nuevas dependencias, cambios en las propias restricciones del agente, cualquier cosa que toque la infraestructura. Esos esperan a una persona. Nada más lo hace. Y cuando algo nuevo se escapa de todos modos, la solución es una nueva verificación automatizada, no más revisión humana. El sistema se vuelve más estricto codificando lecciones, no agregando reuniones.
Recuerda el panel de la apertura. Dos de esas verificaciones de desviación se habrían activado en la primera semana. El blob de una sola línea de 80 KB habría fallado CI en su primer commit, meses antes de que cualquiera de los modos de falla se endureciera.
Etapa 6
Ejecución y cambio
Seis meses después, el rastreador de llamadas de capital sigue funcionando, y aquí es donde el ciclo de vida demuestra su valor. Alguien en RI cuestiona la fecha límite de la transferencia en el aviso de marzo. El registro de auditoría responde en treinta segundos: quién cambió el campo, cuándo y qué decía antes, registrado en la misma transacción que la edición misma. Nadie reconstruye la verdad a partir de una cadena de correos electrónicos. Cuando el constructor cambia de equipo, la propiedad se transfiere a un sucesor designado en lugar de disolverse en un encogimiento de hombros. Y si ella deja la firma por completo, su inicio de sesión muere y cada puerta que abrió se cierra al instante. El rastreador incluido. La solicitud de función del próximo trimestre recorre los mismos rieles que el primer commit.
La gobernanza funciona con señales, no con auditorías anuales. Las métricas de uso del rastreador muestran que dos equipos más dependen de él, por lo que se promueve y se invierte en él. El panel de divisas que nadie ha abierto desde abril se archiva, no se deja pudrir en un menú. Nadie lo llora. La propiedad se asigna el día uno, por lo que nada sobrevive a su constructor sin dueño. Una aplicación no utilizada es un fracaso, no un trofeo. El objetivo nunca fue la cantidad de aplicaciones: es un catálogo vivo en el que tu gente realmente confía, en lugar de un cementerio de software olvidado.
A medida que el catálogo crece de diez aplicaciones a doscientas, un equipo central ya no puede mantener un ojo en todo, y la supervisión debe expandirse hacia afuera a los equipos que poseen las aplicaciones. Cuándo y qué tan lejos federar eso es un juicio, y cambia a medida que crece el portafolio. La gobernanza aquí es una postura que sigues ajustando, no un control que configuras una vez.
La regla que mantiene todo unido
Hay un desencadenante que enseñamos a cada cliente, porque responde el 90% de las preguntas de "¿esto necesita el proceso completo?": la regla del segundo consumidor. Funciona porque ese es el momento en que cambia el perfil de riesgo.
Alguien que construye un análisis para sí mismo, en su propia laptop, con acceso a datos limitado? Bajo radio de impacto, gobernanza ligera. Gráficos, memos y scripts que ejecutan para sí mismos no necesitan un pipeline de implementación. Pero en el momento en que una segunda persona quiere usar el resultado directamente, en lugar de pedirle al autor actualizaciones? El radio de impacto salta: más alcance, datos viajando más lejos, alguien más confiando en que sea correcto. Es software ahora, y se gradúa al ciclo de vida completo, deliberadamente, como un evento explícito. Mismas fuentes de datos, misma identidad, nuevo camino.
Esa única regla es por qué el proceso no ahoga a la gente. La mayoría de las construcciones nunca cruzan la línea. Las que lo hacen son exactamente las que vale la pena hacer la ceremonia.
Lo que somos honestos
Ninguna plataforma hace que los constructores primerizos escriban código perfecto. No afirmamos hacerlo. Las capas existen para que un error sea un inconveniente dentro de un límite pequeño, no un incidente en toda la firma. Cada capa cubre exactamente lo que la de arriba no puede:
Y la auditoría no previene nada, pero hace que cada incidente sea corto, explicable y atribuible. Esa es la diferencia entre una mala tarde y un mal trimestre.
El desarrollo ciudadano no pretende reemplazar la ingeniería profesional. Los sistemas de registro en procesos regulados, cualquier cosa orientada al cliente o al inversor, aplicaciones construidas para usuarios externos, cualquier cosa donde el tiempo de inactividad tenga una penalización financiera: esos siguen perteneciendo a la ingeniería, y la puerta de entrada los dirige allí el día uno. Lo que reemplaza es el cuello de botella. Democratiza la larga cola de herramientas internas que nunca valieron un proyecto de ingeniería formal y las envía a una velocidad que la cola del roadmap nunca podría ofrecer. Un marco sin límites es un eslogan; este sabe para qué no es.
Lo que realmente cambia
En la firma de inversión, la primera aplicación a través de la plataforma es la que lo motivó: el panel de la historia de apertura, rehecho en los rieles. Mismas pantallas. Misma constructora. Ahora con almacenamiento real, inicio de sesión de la firma y un historial de cada edición. Nunca más puede truncarse a 7 bytes, porque la clase de código que lo causó no puede fusionarse.
Aproximadamente 9 de cada 10 solicitudes ya se resuelven automáticamente, y esa proporción solo crece. La mayor parte de lo que hacen los constructores no técnicos es de bajo radio de impacto por naturaleza. Herramientas internas, mayormente de solo lectura, para audiencias pequeñas. A medida que el camino de cada forma demuestra su valía, más de esas construcciones se vuelven seguras de aprovisionar e implementar sin ningún humano en el bucle. La atención humana sigue concentrándose en la cola consecuente y adelgazándose en todas partes.
El sí toma minutos hoy, y tiende a ser instantáneo, porque el no está incorporado.
Toda empresa está a punto de tener cientos de constructores. La mayoría de las empresas todavía están decidiendo si tener miedo de eso o emocionarse. Las que ganen no serán las que tengan más constructores. Serán las que tengan los mejores caminos.
