Personally yes. And I'm sure others have too. The thing is: Large enterprises cracking the agentic swarm isn't giving away their trade secrets. Also not giving away too much info myself here, because it might be flagged as promotional.
The framing of "offload" might be the wrong model entirely. I don't offload coding to AI — I govern it.
I work with a two-layer setup: one AI agent as architect and coordination layer, another as implementer. Every cross-file change requires a documented amendment before a single line is written. The AI reads the decision log before touching any file.
The result is that the AI produces something coherent and maintainable — not because it's smarter, but because it has constraints. Without them my experience matches what others describe here: it goes rogue and changes unrelated things.
The overhead is real but it's architectural overhead, not AI overhead. You'd need the same discipline with a junior human developer.
Your aerospace analogy is fair, and I'd push back on one thing: the problem isn't that developers don't plan — it's that most planning tools for software are too lightweight to actually constrain AI output. "Plan mode" is indeed vibe-coding with extra steps if your plan is a bullet list.
I've been building a Go web framework using AI as the primary code writer. What made it work wasn't a task list — it was locking architectural decisions upfront in a document the AI reads before touching any file. Not guidelines. Decisions. Closed. With rationale, rejected alternatives, and consequences documented.
Any change that crosses a decision boundary gets stopped. Any change touching more than one file requires an explicit Amendment — numbered, approved, then implemented. If you've worked with formal change control in project management, it's exactly that mental model applied to AI-assisted development.
The AI writes code. It does not decide what gets built or how the pieces fit together.
That's closer to your requirements derivation + down-select model than to anything most software teams do. The difference is the tooling forces it — the AI won't proceed without the context, and the context is the spec.
This matches my experience exactly. I came back to coding
after 20 years away — the expertise I brought wasn't Go
syntax, it was product thinking and architectural discipline
from years of project management. That turned out to be
exactly what the AI needed to produce something coherent
and maintainable. The tool amplified what I already knew,
not what I didn't.
This is a really interesting area as the cybersecurity battlefield has no rules of engagement. We could see some very creative models coming from this field.
This matches my experience building a Go framework with AI as
the primary developer. I ended up with a formal Amendment
protocol — every architectural change is proposed,
consequence-analysed, and approved before implementation.
The document that records these decisions (DECISIONS.md) became
the most important file in the repo. Not the code — the decisions
behind the code.
Versioning the investigation is exactly right. The AI has no
memory between sessions. The only continuity is what you write down.
Exactly this. "Architecture guidance and human taste" is the
part that doesn't get automated. In my experience the AI is
very good at implementation once the constraints are clear —
but the constraints have to come from somewhere. That somewhere
is still a human who knows what good looks like.
"if a request is not grounded in verified data, the agent must not improvise." - This is an instruction sales people across the globe also could benefit from. And the LLM is trained on content humans made. Makes sense it needs the same instruction.
Concrete experience from building a Go framework with AI as
the primary developer (not just a helper): the properties that
make Go good for agents are exactly what you'd expect — one
formatter, one build system, static typing, and a strong
convention around package structure.
The part that surprised me: the bottleneck wasn't AI capability.
It was that the tooling wasn't designed for AI as the builder.
Once I locked architectural decisions upfront and enforced a
single way to do everything, the AI stopped hallucinating
boilerplate and started making genuinely good decisions.
Zero ambiguity in the codebase = zero drift in AI-generated code.