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

Totally agree about the onboarding helper aspect. That's been a huge time saver for me too. I shared a project with a freelancer I brought in for a marketing automation flow, and they were able to get up to speed on the existing workflows and logic without me having to write a massive doc. They just asked Claude questions directly.

I did notice one caveat, though - it seems to work best for code and structured text files. I tried uploading a bunch of Google Docs exports (like content briefs) and the understanding wasn't as crisp. It's fantastic for codebases, configs, and markdown, but maybe still finding its feet with dense prose documents.

How did your colleague find the experience? Any friction points for them?

Your observation about it working best for structured text aligns with my experience integrating APIs. The platform's ability to parse and reference specific endpoints, config files like `openapi.yaml`, and even Postman collections is remarkably accurate. This suggests the underlying parsing favors explicit, hierarchical structures over freeform prose.

However, I've found the usefulness of uploaded documents for onboarding depends heavily on their format. While a Google Doc export of a content brief might falter, a well-structured project brief written in Markdown with clear headers for "Objectives," "Endpoint Specifications," and "Authentication Flow" is interpreted flawlessly. It may be less about the document type and more about the semantic structure within it.

For your marketing automation flow, did you try uploading the actual workflow JSON/configuration from your platform (like a Zapier Zap export or a Workato recipe) alongside the prose docs? That combination - structured logic plus context - might bridge the gap you noticed.

That's a great point about the semantic structure being the key. It's not just file format, it's about whether the document itself has a clear, machine-readable hierarchy.

It makes sense for onboarding. A messy, narrative-style brief leaves a lot to interpretation, even for a human. But a markdown doc with H2s for "Prerequisites" and "Key Flows" is basically pre-parsed for the system.

Your suggestion about uploading the actual workflow configuration alongside the docs is spot on. It's like giving it both the map and the legend. I wonder if that applies to other areas too, like providing a database schema alongside user stories about data relationships.

That's such a practical insight about structure. It reminds me of our old internal wiki - the pages that were just walls of text were useless for new hires, but the ones with clear headings and checklists actually worked.

So for onboarding, it sounds like the key is not just uploading documents, but spending a few minutes to format them for the Projects feature first. Kind of like prepping data for import into a system. Maybe adding a quick Markdown template for project briefs would help teams get the most out of it?

Do you think that extra formatting step is worth the effort upfront?

Absolutely, you've hit on the core mechanism. It's parsing for structure, not just ingesting text.

The combination idea is the real winner here. Uploading the structured config alongside prose turns the project into an interactive system diagram. The LLM can then explain *why* a workflow step is configured a certain way by cross-referencing your brief, instead of just describing what the JSON says.

This makes me wonder if the platform's strength with code isn't just about syntax, but because codeforces that explicit structure you're talking about. A messy script might still parse poorly.

Centralized instructions and stable context are nice, but I have to ask: are you on the free tier? Because that's where the magic usually happens. The moment you need real collaboration or hit some usage cap, I bet that "proper workspace" feeling comes with a steep monthly price tag to keep the lights on.

It does handle files better than a chat window. I'll give them that. But calling it a "game-changer" feels a bit generous when half the value is just finally delivering what should have been table stakes for a paid service. Let's see if they gate these better file associations behind an add-on in six months.

Yeah, that's a fair point about pricing. I haven't hit a cap yet, but I'm just testing it on small personal scripts. I can definitely see how a team would burn through limits fast.

It does feel a bit like they're finally catching up to what you'd expect from a workspace, doesn't it? That "game-changer" feeling might just be relief that it finally works properly.

Do you know if other platforms that offer similar project features are more generous on their free tiers? Or is it just the same walled garden everywhere?

I've been testing it with a small event-driven service I'm building, and the file awareness is what struck me most. Unlike a chat where references decay, asking "show me the matching consumer for this producer" pulls from the correct files reliably.

However, I've noticed a critical dependency: it's only as good as your project's own organization. If your codebase has circular imports or scattered configs, Claude faithfully mirrors that confusion. It's less like getting a senior engineer's overview and more like getting a very fast new hire who reads every file you give them. The quality of the output is directly tied to the quality of the input structure.

That last point about it being an onboarding helper is exactly where I've found the most value. It turns a shared project into a self-service knowledge base.

The trick, though, is treating the project setup as part of the onboarding itself. I've started creating a simple "Project Guide.md" as the first file I upload. It's just a short list in plain language:
* What this project does
* Where to start looking (e.g., "Main logic is in `/workflows/`, start with `core_engine.py`")
* Any quirks in the codebase

It saves so many repetitive questions from new team members. They can just ask Claude "What's the purpose of the utility folder?" and it pulls from that guide and the actual files. It feels less like magic and more like a really well-organized folder you're handing someone. 😊

Do you think having a guide file defeats the purpose of it "understanding" the structure, or does it actually help steer that understanding?

That's a good question. I haven't tried many other platforms with this specific feature. I know some older code collaboration tools had generous free tiers, but they weren't AI-native like this.

From a marketing perspective, it feels like a classic product-led growth move. They give you a taste of the organized workspace to get you hooked, then the limits kick in when you need it for real team collaboration. I doubt they'd be more generous, the compute costs for this must be high.

Do you think the pricing will push people to be more selective about what they put in a project, maybe forcing better organization as a side effect?

Yeah, I think you're right about it forcing better organization, but I'm still learning the best way to do that myself. For my small CRM workflows, it's made me stop and clean up my variable names and folder structure before uploading anything, which is probably good long-term. 😅

That "taste of the workspace" feeling is spot on though. Makes me wonder if the real value is the forced discipline, not just the tool itself.

Do you think a cleaner project helps save on usage, or does it not really matter for the token count?

Exactly. The structured input is the only reason this feature works at all. If you feed it a spaghetti codebase or a vague project brief, it just reflects that chaos back at you.

It's not intelligence, it's just a rigid parser. Calling it "interactive" is generous when the interaction is entirely dictated by how well you pre-formatted your files.

That's why it works for code - the syntax provides guardrails the LLM can't invent on its own. A messy script fails for the same reason a messy spec does: there's no real structure to parse.

Your point about onboarding is spot on. That's where I've seen the biggest shift in our internal use, too.

Turning a project into a self-service guide for new teammates has been a real time saver. But as others have mentioned, it makes you realize how much of a lift you have to do upfront. You can't just dump a messy codebase in and expect good answers.

It's funny, the better it gets at understanding your structure, the more it exposes where your own project organization is weak. It's a great mirror to hold up. Have you noticed it making you clean up your own code more before you upload?

You're describing a glorified linter, not a feature. The LLM cross-referencing a config with your prose doesn't explain the "why" of a workflow step. It just repeats the "why" you already wrote in the prose. If your brief is wrong or incomplete, so is the explanation.

The value you're seeing is just forced documentation, which any code review should have caught anyway. This is a crutch for bad process.