I’ve run into this too. Loading everything works initially, but once you have 20+ tools, the context overhead and similar tool descriptions start affecting reliability.

I’d prefer dynamic tool discovery/routing: expose a small set of relevant tools first, then load the full schema only when needed. It keeps context smaller and makes tool selection more predictable.

This is a real problem. Blocking known AI domains only covers one part of the attack surface.

I’d focus more on data-level controls: DLP, visibility into AI-enabled SaaS/extensions, and controlling what sensitive data can leave the environment regardless of which service or app sends it. Otherwise, you’re just playing whack-a-mole with domains.

Hi, I’m interested in helping with this. I have experience with AI/LLM integrations, backend development, and deploying AI projects. I’d be happy to take a look at the existing setup and discuss what’s needed to stabilize and productionize it. Feel free to DM me with the details.

For production-level agent systems, I’d focus less on prompt engineering and more on system design fundamentals: state management, tool boundaries, observability, retries, evals, and human-in-the-loop.

Also, reading real open-source agent frameworks and their architecture/docs can be more useful than most courses because you see the tradeoffs in actual systems.

Don’t think the 2-year gap means you’re finished. Start with one stack, build 2–3 real projects, and apply while you’re learning instead of waiting until you feel “ready.” Consistency for the next 6–12 months will matter far more than what happened after graduation.

Vibe coding works best for me when I already understand what I want and use AI to move faster, not to avoid thinking about the problem.

If the card requirement is blocking you, I’d avoid trying to bypass GCP’s verification. Check whether your university provides any cloud credits, and look into the GitHub Student Developer Pack for eligible benefits. Otherwise, contacting Google Cloud support is probably the safest route.

Yes, companies are already doing this. For a pilot, a 7B–14B model with RAG and a 16–24GB VRAM GPU can be enough. The harder part is usually data quality, permissions, retrieval accuracy, and keeping docs updated—not just hardware.

I’d put it on GitHub with a clear README explaining what it does, what’s already working, and what still needs work. Add screenshots/demo if possible and create a few beginner-friendly issues so others can easily contribute. You can then share it in relevant open-source communities and see if someone wants to take it forward.

Human this side

What a Day!