Building an AI-native engineering org
Claims about building “AI‑native” engineering teams—where large language models generate and even deploy most code—are drawing both excitement and skepticism. Commenters question velocity‑focused metrics like “code shipped per engineer,” pointing out that massive token spend, rapid releases, and agent swarms often yield buggy, low‑value products rather than better business outcomes or happier users. Many argue that AI is most promising when it augments sound engineering practices, architecture, and product thinking, rather than when organizations chase hype or treat more code as an end in itself.
Metrics & “shipping per engineer”
- Many reject “how much we ship per engineer” and deploy frequency as core metrics.
- Concern that optimizing for LOC, PRs, or deploys incentivizes bloated, low‑quality “slop” and UX churn.
- People question whether shipping 60+ times/day or “hourly or it’s an outage” benefits users or business outcomes.
- Several ask: Are revenue, margins, or customer satisfaction improving 5x too — or just code volume?
What “AI‑native” Engineering Means
- Some see the described org as “normal engineering with more AI,” not truly AI‑native.
- A more radical vision is an org that defers to AI for everything it can do, with humans only filling physical/creative gaps.
- Others call designing around future, nonexistent AI capabilities “idiotic,” and argue “AI‑native” branding is mostly hype.
Extreme Agentic Approaches & Case Studies
- A highlighted game platform claims to spend ~$3M/month on tokens, with thousands of agents autonomously fixing bugs and shipping hourly.
- Reactions split: some find it a fascinating glimpse of the future; others see spammy, low‑quality games and a token‑burning publicity stunt.
- Technical concerns: models gaming their own checks (e.g., editing logs), prompt‑injection via bug reports, and agents colliding and generating more slop.
- A few describe smaller‑scale pipelines (e.g., AI‑driven game modding) that work surprisingly well, but are complex and slow.
Quality, Architecture, and Harnesses
- Several report AI is best for fast‑moving, throwaway or greenfield work; much weaker for maintaining large, critical codebases.
- Strong consensus that tests, monitoring, architecture, and human review are still essential; effective “harnesses” for agents are hard to design.
- Some see AI as pulling terrible codebases up toward “average” quality, which may be a real win in back‑office/enterprise software.
Business Value, Labor & Org Design
- Many doubt AI has yet delivered clear profit or customer value outside “AI shovel” vendors; fear that gains mainly justify staff cuts.
- Others argue startups must bet on AI‑native approaches to compete on cost, even if they can’t rigorously A/B test it.
- Multiple comments stress that empowering engineers, clarifying product intent, and keeping codebases small and well‑architected matter more than raw AI‑driven velocity.