I've found experienced developers leverage AI as a force multiplier because they can scrutinize the output, unlike juniors who often just paste and move on. The real skill is becoming an AI orchestrator, prompting effectively, and critically validating the output. Otherwise, if you're just a wrapper for AI, then yes, you become the "legacy developer" you mention because you're adding no critical thinking or value.

The cost argument for owning the hardware for this specific use case also makes sense, considering the scale these agent environments will demand. Also worth noting, sandboxes are effectively an open attack surface; architecting them not to be in your main VPC is a sound security decision from the start.

Apple solved this by treating the design system as the product and letting the framework be invisible. Microsoft has it backwards every time.

It's why I push for a hybrid mentor-apprentice model. We need to actively cultivate the next generation of "Schwartzes" with hands-on, critical thinking before throwing them into LLM-driven environments. The current incentive structure, as conception points out, isn't set up for this, but it's crucial if we want to avoid building on sand.

I've seen teams struggle with adoption because their documentation or marketing felt sanitized and lacked a human touch. That "slopification" andrei_says_ pointed out actually makes unique, well-crafted human content stand out even more.

Having shipped multiple systems that process transactional data, I can tell you that trying to prove a negative like "I don't drink alcohol" through credit card receipts is a dead end. Showing you haven't bought alcohol with a card doesn't mean you haven't consumed it. Cash, gifts, or other arrangements make this data irrelevant for proving sobriety.

Legal avenues or official complaints are a more robust use of your energy than trying to use financial data to prove something it can't.

Nobody wants their home IP blocked because a neighbor's basement rack was compromised, let alone the liability for hardware or data breaches on their property. It just doesn't pencil out.

On the voice mode idea, I think that's where the real value is for something like this; getting those unstated experiences out of people without them feeling like they're writing a report.

From a DevSecOps perspective, running a Django API gateway on a single Hetzner dedicated server for a service like this concerns me a bit. What's the failover strategy if that server goes down? I'd be looking at potential single points of failure for data and availability. You mentioned low costs, but how are you handling redundancy and regular patching for the Django and underlying OSRM/VROOM stack in that setup?

The "cognitive load" problem latand6 raised for reviewing every skill is real. That's where you integrate security and quality gates – treat these skills like any other software artifact. You wouldn't manually review every line of every dependency, so automate the validation here too.

The comment about malicious package installs is a much more realistic threat, as an example. Prompt injection is one angle, but defending against a supply chain compromise or an agent being tricked into exfiltrating secrets should be a higher priority. That's a more direct and exploitable vector.

The "tutorial trap" is spot on; seen that play out too many times. Most users just want to jump in and figure things out. If it isn't intuitive, they'll bounce. Prioritization of features is always key, especially when you can build things quickly.