xxwink

This post is in itself a one bit message

I agree. LLMs contributing more or less autonomously is the "new normal". Managing and orchestrating what gets shipped is the real responsibility to track here.

I'm a father of two teenage boys. Both of them could've used "customized learning". What makes you think otherwise ?

There's a huge potential in personalized learning/education space. A big problem in education is that everyone learns different, and teachers / schools have to go by the speed of the lowest common denominator. AI can tailor content to the individual students most optimal way of learning. Whoever cracks that code will literally boost humankind

Technology is not life. It might make your life easier or it might connect you to people or experiences that would be hard to achieve without it. But technology is not the end goal. You past interest have brought you here. That doesn't mean it was "wrong" or that you can't find the passion again. But it seems like you need a break and maybe a new passion for a while

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.

How do you handle code versioning, Deployment and Infrastructure as a non technical person ?

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.