One Interface, Two Audiences: Designing CLIs for Humans and AI Agents

If a tool has to work equally well for a person typing in a terminal and an AI agent calling the same commands, how much of the design actually has to change? That's the question behind two CLIs rebuilt from the ground up: `dtwiz`, which analyzes a system and recommends how to instrument it, and `dtctl`, a kubectl-style CLI for managing platform resources like workflows and dashboards. Both are open source ([github.com/dynatrace-oss/dtwiz](https://github.com/dynatrace-oss/dtwiz), [github.com/dynatrace-oss/dtctl](https://github.com/dynatrace-oss/dtctl)), and both ship with an agent Skill so tools like Claude Code and GitHub Copilot can run the same commands a person would, no separate documentation required. This is a working session, not a pitch. We'll walk through the concrete decisions: zero-config defaults, dry-run previews, structured output modes, and a confirm-before-you-proceed prompt, plus the honest tradeoffs, like what "confirm" even means when nobody's watching the terminal. We'll also connect it to the GUI side: a new onboarding flow built on the same underlying logic. If you're deciding whether your product needs a GUI, a CLI, an agent skill, or all three, you'll leave with a concrete blueprint and two open-source repos to go read yourself.