GDG Cloud Taipei: Do We Still Need Software Engineering in the AI-Native Era?
Denny Huang (SITCON co-founder, GDG Cloud Taipei organizer) opened with a provocative question: he teaches SDLC to students for the SITCON Summer Camp. Does that still make sense in the age of coding agents?
His answer is the thesis of the whole talk:
In the AI-Native era, outputs get generated faster — and precisely because of that, human judgment, boundaries, delivery, and verification become more critical, not less.
CI as a “Harness”
The central concept is a redefinition of CI. It’s not just push → test → deploy:
CI is turning human judgment, AI output, and system boundaries into verifiable engineering contracts.
Every SDLC phase has its own Harness question:
| Phase | Harness question |
|---|---|
| Request & Analysis | Are we still solving the same problem? |
| Design | Are the boundaries and contracts still standing? |
| Coding | Are the new changes stabilized? |
| Testing | Can the output be adopted/used? |
| Maintenance | Can the next person safely continue? |
The pedagogical experiment
Instead of teaching methodology first, Denny does the opposite: he hands out only the pain point, lets students use a coding agent directly, and waits for them to experience the chaos. The value of SDLC gets discovered from the inside, out of that chaos. Then comes evolution (more features) and collaboration (swapping projects between groups).
The real project: SITCON Flickr Photo Finder, a tool for organizers to find event photos. All photos indexed in a Google Spreadsheet as the source of truth, with parallel sub-agents (Claude, Gemini, Codex) tagging them — a design deliberately agnostic to the model, with no dependence on a single provider.
What the git history tells you
The project’s git growth report speaks for itself: from 0 to ~32,000 lines in 10 days. But the number that stuck with me most: 124 docs commits versus 109 feat commits — more documentation than features. The Harness makes documenting part of the flow, not an afterthought.
Ideas I’m taking with me
- Sub-agents for simulated user interviews. Before launching the agents, the orchestrator checks the workspace (
git status --short) and reads the repo’s key docs; only then does it launch 6 parallel agents with distinct roles (community, design, marketing, press, metadata, infra) grounded in those documents. - ADRs (Architectural Decision Records) as architecture memory: the agent has no memory between sessions, and the ADR is the mechanism that lets the context of past decisions survive. It’s a MEMORY.md, but for architecture.
- Testing as an adoption boundary: explicitly define what can happen automatically and what must pause for human judgment. His real-world case: they detected lazy AI output using statistical distribution — suspiciously clustered people-count values triggered an audit of that album.
- On evals: the TDD → tests → Skill → Evals flow makes sense when the output is AI-generated. For Java/Spring Boot, JUnit + AssertJ + Mockito are already sufficient as a verifiable spec. And watch out for the pitfalls: overfitting to the eval, measuring what’s easy instead of what matters, false confidence, and maintenance — evals go stale just like tests do.
This connects directly to the WordPress Meetup from two days earlier: the AGENTS.md / MEMORY.md / SKILL.md framework shows up again as an emerging standard.