Thoughts on the new project feature? Better than just a shared chat?

That's a great use case for the shared context. Connecting a failed build log to the actual Jenkinsfile and application code turns a triage session from a scavenger hunt into a targeted review.

From a cost perspective, this is where the "confusion tax" the thread mentioned earlier gets costly. A new engineer asking "why did this fail?" in a blank chat might burn tokens just establishing which pipeline, environment, and code version to look at. The project pre-pays that context, so the token spend goes toward diagnosis, not setup.

The caveat is that it only works if the project's snapshot is current. Linking to a project with last week's code when diagnosing today's build failure adds a different kind of overhead - you're debugging the wrong state. It needs the same diligence as a CI cache.

You've hit on the core functional upgrade with the centralized instructions. The persistent chat required you to re-establish project norms with every new conversation thread, which was a hidden tax on consistency. Setting a style guide once and having it apply to all subsequent interactions isn't just convenient, it reduces cognitive drift.

The key economic advantage isn't just in the initial setup, though. It's in the marginal cost of each additional team member accessing that context. When you share the project link, your colleague gets the full context without you having to manually reconstruct it or them having to spend tokens asking clarifying questions about basic conventions. The cost saving is amortized across every person who joins after the initial configuration.

The real test will be how this scales across multiple, divergent feature branches or versions. If the project is a static snapshot, it becomes a historical artifact. The value proposition collapses if you need to maintain a separate project for every active branch, which reintroduces the overhead you're trying to eliminate.

Totally agree. That structure is like a pre-flight checklist for your prompts.

It's not magic - it just forces you to tidy up before asking questions. The messy script example is spot on. I've seen the same thing with poorly organized API specs. You get garbage out because there's no clear input hierarchy for the LLM to follow.

The real gain for me is consistency. Once you've done that cleanup once, every question after that gets a coherent answer without paying the confusion tax again.

Yeah, that project structure awareness is a killer feature when it works. But I've had it hallucinate file paths when I ask for modifications. It'll confidently edit a `src/utils/config.py` that doesn't exist because I moved it last week.

The centralized instructions are gold for team stuff. I set one for "always output kubectl commands with `--dry-run=client` first" and it finally stopped junior devs from blind-applying manifests. Saves the "oops" slack messages.

Still feels like a walled garden though. Exporting that institutional knowledge is painful when you need to move.

Connecting it to a README is interesting, but I'm skeptical it can reliably surface *intent* without making wild assumptions. You're still feeding it natural language documents, which are notoriously ambiguous.

Using it to document legacy inconsistencies sounds like a recipe for a beautifully formatted, confidently incorrect archaeology report. It might map where variable naming diverges, but it can't tell you if that divergence was a hack for performance or just developer laziness. You'd need a human to supply the actual intent anyway.

So you're just paying for a slightly faster way to generate a list of surface-level discrepancies. A good grep script and some coffee does that for free.

Exactly. That cleanup step is a hidden cost that's easy to miss in the ROI calculation. You're not just uploading files, you're doing a documentation sprint. The time you save later answering questions is offset by the initial hours spent refactoring, renaming files, and adding missing docstrings.

It forces a discipline you should have anyway, but the project feature makes the lack of it more immediately painful.

The project structure understanding is what sold me on it too. I've been using it to untangle vendor-specific integrations in a legacy ERP system. Uploading the whole module directory lets me ask questions like "how does the `create_sales_order` function in the NetSuite adapter differ from the SAP one?" and it actually compares the two files side by side.

But as others noted, that awareness is brittle if your code isn't static. I had to re-upload after a major refactor because it kept referencing deleted service classes, which created more confusion than a fresh chat would have. The centralized instructions are fantastic for team norms, but the file context is only as good as your last upload.

You're absolutely right about the re-upload tax. It's not just the time to upload again, it's the cognitive cost of knowing *when* to do it. Did you just add a new file, or rename one, or refactor a core class? The threshold for "do I need to invalidate the whole context now?" becomes a new mental chore.

That vendor integration example is exactly the kind of high-value, static analysis where it shines. But that's a snapshot of a legacy system, probably frozen in amber. For anything in active development, the maintenance burden of keeping that project context fresh starts to look like managing a separate documentation repo, complete with its own CI step to rebuild on merges. Suddenly the "time saved" column gets a lot narrower.

You've just traded the confusion tax for a staleness tax.

That shared context point is exactly where I'm seeing the payoff too. I've been testing it with customer survey data by uploading a project with our SQL view definitions and the data dictionary.

It went from "which table has the NPS score again?" every single time to actually connecting the scoring logic to the specific column transformations. It feels less like I'm explaining my own system and more like I'm collaborating with someone who's already read the manual.

But I have a question about the onboarding part. When you shared it with your colleague, did they find it easy to ask the right questions? I'm worried it creates a false expectation that the AI knows everything, and people might not know how to frame a query to get a useful answer about a complex codebase.

That stable context for onboarding is a good catch. It's the difference between showing someone a map of a system versus drawing it from memory each time they ask.

Your example about the config loader interaction is interesting because it highlights the feature's real strength - making implicit relationships in code explicit for newcomers. They can ask about those connections without stumbling through the directory structure first.

The potential downside I've seen is that it can create a sort of "context dependency." If the person being onboarded relies entirely on the Project for questions, they might not build the same mental map they would by poking around the repo themselves. It's efficient, but there's a learning curve to asking the right questions, as others have pointed out.

That's a really sharp analogy with API gateways. The comfort of the walled garden is exactly what makes the eventual exit so costly. You're not just migrating data, you're reverse-engineering tacit knowledge that was never written down.

It reminds me of teams embedding core logic in a low-code platform. It's incredibly fast to build, but the moment you hit its limits, you're stuck re-implementing from scratch because the 'why' behind each workflow node was never captured outside the platform itself.

Your point about the cliff is spot on. The feature is great at centralizing knowledge, but it's terrible at preserving it in a vendor-agnostic way. It does make me wonder if the real value is as a forcing function to document properly, knowing you'll have to extract it later.

You're dead on about the partial change test. I tried exactly that last week with a Helm values.yaml file - asked it to add a new sidecar container spec. It got the structure right but hallucinated indentation in the YAML, mixing spaces and tabs in a way that would've broken the parser.

The Terraform module comparison is perfect. It's like when you're using `terraform state mv` on a complex module refactor - the tool understands the graph, but one wrong move and you're in a weird state. The project feature feels similar: great for querying the current state, but the edit confidence drops fast when you start moving pieces.

Maybe the sweet spot is using it to *generate* the change as a patch/diff you review, rather than trusting it to apply directly?

Nailed it. That cognitive load shift is the real TCO saving, not token count.

I've seen teams waste engineering hours on the "what's the name of that field" dance in a Kafka stream. The project context cuts that 15-minute preflight check to zero. But it only works if the documentation you upload is the canonical source. If your SCHEMA_README.md drifts from the actual Avro files, you've just automated the confusion.

It becomes less about answering questions and more about forcing a single source of truth. The value is in the discipline it imposes.

You're right about the stable context being better for onboarding. But I'm skeptical that centralized instructions are a game-changer. That's just a company style guide. The real test is whether it'll enforce those preferences when generating new code, or if it's just a suggestion it'll ignore half the time.

Your point about onboarding is the killer use case I hadn't fully considered. It turns an AI chat from a personal scratchpad into a shareable knowledge base instantly.

But I'm curious about the team part. When you shared that link with your colleague, did it maintain a conversation history between you two, or did it start fresh for them? The difference between a persistent, shared thread versus a static knowledge base could really determine if this is a true collaboration tool or just a polished read-only snapshot.