GDG Cloud Taipei: ¿sigue haciendo falta ingeniería de software en la era AI Native?
Denny Huang (co-fundador de SITCON, organizer de GDG Cloud Taipei) abrió con una pregunta provocadora: él enseña SDLC a estudiantes para el SITCON Summer Camp. ¿Tiene sentido seguir haciéndolo en la era de los coding agents?
Su respuesta es la tesis de toda la charla:
En la era AI Native los outputs se generan más rápido — y precisamente por eso el juicio humano, los límites, la entrega y la verificación se vuelven más críticos, no menos.
CI como “Harness”
El concepto central es una redefinición de CI. No es solo push → test → deploy:
CI es convertir el juicio humano, el output de la IA y los límites del sistema en contratos de ingeniería verificables.
Cada fase del SDLC tiene su pregunta de Harness:
| Fase | Pregunta del Harness |
|---|---|
| Request & Analysis | ¿Seguimos resolviendo el mismo problema? |
| Design | ¿Los límites y contratos siguen en pie? |
| Coding | ¿Los cambios nuevos quedan estabilizados? |
| Testing | ¿El output puede ser adoptado/usado? |
| Maintenance | ¿La siguiente persona puede continuar con seguridad? |
El experimento pedagógico
En lugar de enseñar metodología primero, Denny hace lo contrario: entrega solo el pain point, deja que los estudiantes usen un coding agent directamente, y espera a que experimenten el caos. De ese caos se descubre el valor del SDLC desde adentro. Después vienen la evolución (más features) y la colaboración (intercambiar proyectos entre grupos).
El proyecto real: SITCON Flickr Photo Finder, una herramienta para que organizadores encuentren fotos de eventos. Todas las fotos indexadas en un Google Spreadsheet como fuente de verdad, con sub-agentes paralelos (Claude, Gemini, Codex) etiquetándolas — diseño deliberadamente agnóstico al modelo, sin dependencia de un solo proveedor.
Lo que cuenta el historial de git
El git growth report del proyecto es elocuente: de 0 a ~32.000 líneas en 10 días. Pero el dato que más me quedó: 124 commits de docs contra 109 de feat — más documentación que features. El Harness hace que documentar sea parte del flujo, no un afterthought.
Ideas que me llevo
- Sub-agents para user interviews simuladas. Antes de lanzar los agentes, el orquestador verifica el workspace (
git status --short) y lee los docs clave del repo; solo entonces lanza 6 agentes en paralelo con roles distintos (comunidad, diseño, marketing, prensa, metadata, infra) grounded en esos documentos. - ADRs (Architectural Decision Records) como memoria de arquitectura: el agente no tiene memoria entre sesiones, y el ADR es el mecanismo para que el contexto de decisiones pasadas sobreviva. Es un MEMORY.md pero para arquitectura.
- Testing como adoption boundary: definir explícitamente qué puede pasar automático y qué debe pausar para juicio humano. Su caso real: detectaron lazy output de la IA usando distribución estadística — valores de conteo de personas sospechosamente concentrados dispararon una auditoría de ese álbum.
- Sobre los evals: el flujo TDD → tests → Skill → Evals tiene sentido cuando el output es generado por IA. Para Java/Spring Boot, JUnit + AssertJ + Mockito ya son especificación verificable suficiente. Y ojo con los peligros: overfitting al eval, medir lo fácil en vez de lo importante, falsa confianza, y el mantenimiento — los evals se vuelven stale igual que los tests.
Conecta directo con el WordPress Meetup de dos días antes: el framework AGENTS.md / MEMORY.md / SKILL.md aparece otra vez como estándar emergente.