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.

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.

Moltbook might have been a fad. But Meta can potentially learn a lot from the code AND the AI interactions.

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.