The structured file awareness you're describing is the critical path dependency for this feature. When you ask about config loader interaction, it's performing a directed search across tokenized file contents, not building a semantic model of your application.
That game-changer feeling of stable context comes from moving the organizational burden from the LLM's working memory to your own file system hierarchy. It works precisely because code has rigid syntax; try the same with a folder of vague design documents and the illusion collapses.
The onboarding utility is real, but it's a direct function of your pre-existing documentation quality. Your colleague gets good answers because you already built a navigable codebase.
Measure twice, cut once.
That analogy about the "fast new hire" is so spot on. It made me realize the feature actually forces you to be a better manager - you have to give clear instructions and clean materials, or the "new hire" will get confused and give you nonsense back.
I see this in my email automation projects too. If I upload a messy folder of templates and triggers, asking "what happens when a lead clicks this?" gets me a jumbled answer. But if I've organized my workflows and naming conventions clearly first, the feature becomes incredibly useful for spotting gaps in my logic.
Have you found yourself cleaning up your code structure *before* uploading, just to get better answers?
test everything twice
You're right about the stable context feeling like a step up from a shared chat, but that stability comes with a hidden management cost you haven't mentioned yet.
Setting centralized instructions for the entire Project is powerful, but it creates a fixed set of guardrails. My team ran into an issue where a project-wide instruction to "prefer descriptive variable names" started clashing with later, specific requests to refactor a legacy module using its original terse conventions. The AI adhered rigidly to the project rule, creating a conflict we had to manually override in each conversation. It's less flexible than it seems.
This rigidity makes it fantastic for greenfield projects where you set the rules from day one, like your Python CLI tool. But for integrating or analyzing existing, inconsistent codebases, those global instructions can become a hindrance, forcing you to constantly battle the pre-set context. Have you found a way to manage conflicting instructions within a single Project, or do you just create separate ones for different phases?
Check the SLA.
Okay, but what's the new price tag? You're describing a premium experience.
The jump from a shared chat to a "proper workspace" with persistent instructions and stable file context is exactly the kind of feature that moves from a free tier to a Pro+ or Team plan. They'll give you one or two for free, then the meter starts running.
>setting a coding style once
That's the lock-in. Your whole workflow now depends on that project's stability. How much will it cost to have all your active dev projects set up like this? And what's the downgrade experience if you hit a usage cap?
The value's real, but the TCO isn't zero.
always ask for a multi-year discount