Presentamos el SDLC de Citizen Developer de Tenex, un ciclo de vida de seis etapas que lleva lo que los empleados no técnicos construyen con IA desde un prototipo personal hasta la producción gobernada en la 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 TLDR
El Citizen SDLC 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 la producción gobernada. Un principio recorre cada etapa: la IA hace el trabajo, el código determinista establece los límites y los humanos manejan las excepciones. Existe porque la IA redujo el costo de escribir código a casi cero y trasladó el cuello de botella río abajo, a asegurar que lo construido sea sólido y mantener gobernada una flota creciente una vez que está en vivo.
Uno de nuestros clientes es una firma de inversión. Un miembro de su equipo de operaciones de cartera, alguien que nunca ha escrito una línea de código, construyó el tablero que todo su equipo usa ahora a diario. Rastrea el trabajo de creación de valor en varias docenas de empresas de la cartera. Lo construyó usando 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 instantánea. Ella esbozó el producto correcto antes de que ningún ingeniero se involucrara.
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 hercúleo: un gerente de producto para convertir su problema en una especificación, ingenieros para traducir la especificación en 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 quería decir.
Esa brecha acaba de colapsarse. El poder de construir se ha movido a las personas que realmente entienden el proceso, saben lo que significan los datos y viven 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 datos de 80 KB 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 guardado 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 tablero en el que su equipo confiaba todos los días 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 entregara.
El cuello de botella se movió
Durante décadas, construir software era la parte costosa. Era lento, escaso y costoso, 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: asegurar que lo construido sea sólido y seguro, y mantener una flota creciente de estas aplicaciones gobernada una vez que están en vivo.

GIF
Y la construcción no se está desacelerando, creando dos problemas que deben resolverse:
Primero, la calidad bajo el capó. Un agente incitado desde una página en blanco por un no ingeniero converge en software improvisado 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, la expansión descontrolada. Cada equipo quiere su propia aplicación, y ningún grupo central de TI puede construir y operar docenas de ellas manualmente. Sin barreras de seguridad, 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 almacenados donde sea que cayeran. Bloquea las solicitudes y no se detienen, simplemente se mueven fuera de los libros registrados. De cualquier manera, heredas no solo una flota de aplicaciones sino el lío enredado de la infraestructura debajo de ellas, y nada de eso es algo que TI pueda asegurar, soportar o explicar de manera razonable.
Entonces, la verdadera pregunta que toda empresa está a punto de enfrentar: ¿cómo permites 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 fantasma 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 hacia herramientas de IA sin estructura y celebra las demostraciones. Así es como obtienes el archivo de 540 KB. Y no puedes revisar tu salida 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 desde 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 despliegue espera el calendario de un revisor. Las revisiones o matan la adopción o se convierten en un sello de goma. Ambos resultados derrotan el propósito.
Entonces la respuesta no es otro documento de política sino un ciclo de vida: un SDLC real, diseñado para personas que nunca se llamarán a sí mismas desarrolladores, con barreras de seguridad integradas en la plataforma en lugar de escritas en un memorando. 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 los límites y los humanos manejan las excepciones. La IA redacta, clasifica y escribe. El código decide lo que está permitido. Las personas se utilizan solo donde realmente se requiere juicio. Mantén esa división; es lo que hace que todo escale.
Lo llamamos el Citizen SDLC. 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 la posee. Toma minutos y se lee como un memo. Duplica 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 de fondos 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 cada viernes". La IA pregunta lo que preguntaría un analista de admisión. ¿Quién más necesita verlo? Doce personas en finanzas de fondos y relaciones con inversores. ¿Dónde viven los datos hoy? Una hoja de cálculo en Box, y solo lectura está bien. ¿Quién lo posee cuando estás fuera? 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 el término PRD.

GIF
Nada existe todavía. Sin código, sin acceso, sin infraestructura. Eso es deliberado: la firma forma una opinión sobre la aplicación antes de que la aplicación exista, en lugar de seis meses después de que sea crítica.
Etapa 2
La puerta de entrada
Cada solicitud pasa por una puerta de entrada estructurada, y el mismo movimiento que la archiva la deja caer 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 solicitudes en el pasillo, sin favores, sin canalización oculta. No puedes gobernar lo que no puedes ver, y no puedes compartir lo que no puedes encontrar. La puerta de entrada hace ambas cosas verdaderas desde el primer día.
Esta es la etapa que mata la canalización oculta. Una construcción que salta la puerta de entrada aún puede existir como 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 corporativo, un pipeline de despliegue, un lugar donde ejecutarse realmente. Nada de eso llega a una construcción que nunca pasó por aquí. Puedes rodear 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 tableros interactivos. Nombrar la forma te dice la arquitectura que necesita, y le entrega a la siguiente etapa el camino pavimentado para estampar. Radio de explosión: ¿cuánto daño podría hacer esta construcción si sale mal? Puntuamos eso en cuatro dimensiones:
- Alcance y capacidad: ¿qué puede tocar, y puede escribir o solo leer?
- Reversibilidad y autonomía: ¿hay un humano en el ciclo, 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: tablero interactivo. Radio de explosión: datos internos del fondo, doce usuarios internos, solo lectura, humano en el ciclo, 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 compromiso de LP. El resumen puede ser tan persuasivo como quiera; ese único cambio eleva la dimensión de sensibilidad de datos más allá del umbral que TI estableció, y la solicitud va a una persona. No ocurrió ninguna decisión en el medio. Una regla coincide o no.
Tres rutas de salida:
- Aprobado. Radio de explosión dentro de cada umbral, resumen completo, alta confianza. En nuestro cliente, aproximadamente 9 de cada 10 solicitudes se resuelven de esta manera, automáticamente.
- Reutilización. 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 en TI y Seguridad recibe la solicitud completa como contexto.

GIF
La décima solicitud, la excepción, aún llega 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 a TI decir que sí a gran 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 escribe 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 corporativo, una identidad de despliegue, 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 poder elevado, y un humano está al frente. Cada aplicación nace aislada, gobernada y auditada: su propio entorno cerrado, sin dirección pública, sin secretos almacenados en la nube, un rastro de auditoría de solo apéndice 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 escribe por forma, la aprobación humana es una postura predeterminada, no un impuesto permanente. Las formas novedosas y las construcciones de alto radio de explosión mantienen la puerta humana para siempre. Pero una vez que el camino de una forma se ha probado a sí mismo a través de suficientes construcciones, las solicitudes de bajo radio de explosión 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, enrutas más a una persona, y a medida que los patrones se mantienen, la línea se mueve hacia la automatización.

Y el camino lleva una cosa más que importa tanto como la infraestructura: el libro de reglas de IA. El repositorio heredado entrega al agente de codificación un conjunto de instrucciones en cada sesión, codificando los anti-patrones aprendidos de fallas reales. No incrustar blobs de datos de más de 1 KB. No agregar 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 incita 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 está allí: correo, unidades sincronizadas, cookies del navegador, credenciales en caché. En el espacio de trabajo, el agente ve el proyecto. Nada más.
Todo lo que un ingeniero normalmente llevaría es llevado por los rieles: en nuestro cliente, 35 barreras de seguridad 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 lo envía de nuevo.
Los humanos no revisan los 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 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 tablero de la apertura. Dos de esas verificaciones de desviación se habrían activado en él en la primera semana. El blob de 80 KB en una sola línea 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 relaciones con inversores cuestiona la fecha límite de transferencia en el aviso de marzo. El rastro 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 nombrado 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 se ejecuta en señales, no en auditorías anuales. Las métricas de uso del rastreador muestran que dos equipos más están apoyándose en él, por lo que se promociona y se invierte en él. El tablero 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 primer día, por lo que nada sobrevive a su constructor sin dueño. La documentación se regenera a medida que la aplicación evoluciona, por lo que nunca se vuelve obsoleta. Una aplicación no utilizada es un fracaso, no un trofeo. El objetivo nunca fue el número 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 tiene que expandirse hacia los equipos que poseen las aplicaciones. Cuándo y qué tan lejos federar eso es un juicio, y cambia a medida que la cartera crece. 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 al 90% de las preguntas de "¿esto necesita el proceso completo?": la regla del segundo consumidor. Funciona porque ese es el momento en que el perfil de riesgo cambia.
¿Alguien construyendo análisis para sí mismo, en su propia laptop, con acceso a datos limitado? Bajo radio de explosión, gobernanza ligera. Gráficos, memorandos y scripts que ejecutan para sí mismos no necesitan un pipeline de despliegue. Pero ¿en el momento en que una segunda persona quiere usar el resultado directamente, en lugar de pedirle al autor actualizaciones? El radio de explosión 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 la razón por la que el proceso no ahoga a las personas. La mayoría de las construcciones nunca cruzan la línea. Las que lo hacen son exactamente las que valen la ceremonia.
Lo que somos honestos
Ninguna plataforma hace que los constructores primerizos escriban código perfecto. No afirmamos eso. Las capas existen para que un error sea una molestia 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 a los inversores, aplicaciones construidas para usuarios externos, cualquier cosa donde el tiempo de inactividad conlleve una penalización financiera: esos aún pertenecen a la ingeniería, y la puerta de entrada los enruta allí el primer día. 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 entrega 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 la motivó: el tablero de la historia inicial, rehecho en los rieles. Mismas pantallas. Misma constructora. Ahora con almacenamiento real, inicio de sesión corporativo y un historial de cada edición. Nunca más podrá 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 explosión por naturaleza. Herramientas internas, de solo lectura en su mayoría, de audiencia pequeña. A medida que el camino de cada forma se prueba a sí mismo, más de esas construcciones se vuelven seguras de aprovisionar y desplegar sin ningún humano en el ciclo. La atención humana sigue concentrándose en la cola consecuente y adelgazándose en todas partes.
El sí toma minutos hoy, y tiende hacia lo instantáneo, porque el no está integrado.
Toda empresa está a punto de tener cientos de constructores. La mayoría de las empresas aún están decidiendo si tener miedo de eso o estar emocionadas al respecto. Las que ganen no serán las que tengan más constructores. Serán las que tengan los mejores caminos.





