do we want or need a full repo file tree?

[adboio]

problem

assuming this gets merged: #1497

it removes the file tree for the full repo, and only exposes changed files / diffs.

i think this is the right call for the simplicity of the UX in day-to-day usage, but are there use-cases for opening/viewing files outside of what the agent is touching? particularly if we maintain the stance that we won't allow file editing so as to not become an IDE?

solution

if we want it, we just need to figure out where we want it, and add it back.

if we don't want it, we need to do more cleanup, e.g. we can probably remove codemirror entirely, delete the file tree components (i left them in case we want them), etc

[CaioDGallo]

I want to give my 2 cents on this topic because it touches my main "friction points" with PostHog Code.

The full repo file tree is definitely not my most-used feature, but one thing that makes me always reach for an external editor is "the critical part" of every PR. After I designed, planned, and applied some changes with the assistance of a model, I read everything it did, I analyze it, and more frequently than not, I tweak some parts of the code (sometimes asking the agent again, but most of the time by hand).

This "critical part" involves mostly standard IDE tools like file search, grep, using the file tree, file editing, and lsp-enabled actions. For projects or code that is very important, I am personally not able to not do it every time, and that is when I leave posthog code most of the time.

Of course, I do have projects that all that is available in PostHog Code right now is perfectly fine, and removing the file tree or not having these other aspects does not hurt the experience.

---

Maybe I did not get the full vision of what the product is aspiring to become yet, @adboio, if you could share your two cents with me, that would be great!

[adboio]

thank you @CaioDGallo !! this is exactly the kind of feedback i was hoping to get 😄

can you explain a bit further on what your workflow looks like in your IDE after leaving posthog code? for example, my workflow is typically:

1. design, plan, etc
2. agent writes code
3. i review the output as the agent goes, and overall once it's done, within posthog code (at least now with the new/upcoming changes to the diff review panel)
4. almost always i jump to vscode at this point, for small things like:
   1. quickly removing slop comments (in vscode's diff viewer)
   2. minor refactoring, like moving functions to utils or extracting small re-usable components (also in vscode's diff viewer)
   3. poking around more holistically and copying file paths so i can feed them back to the agent (e.g. "you put this function in /path/to/fileA.tsx, i think we should move it to /path/to/someUtils.ts")
   4. shift+cmd+f'ing to double-check the agent didn't miss anything in a refactor

so i'm rarely leveraging more "advanced" features of the IDE because the agent can often just do those for me faster, and i'm almost never editing files outside of what's in the diff... so i'm curious what your typical workflow looks like and what sort of things you're doing in the IDE after leaving posthog code!

for a bit of context on our current thinking:

• personally, i really want to be able to edit diffs in posthog code. that'd take care of ~80% of the reasons i leave the app
• i think i still want to be able to explore the full repo file tree, at least for global search and/or grabbing file paths as references, but i don't necessarily need to edit untouched files, and the file tree doesn't need to be as prominent in the UI as it is right now
• we are trying to be very careful with our decision to add more "IDE-like" features (full file tree, editing, etc) because the more we add, the more we'll be seen as an IDE and expected to live up to such expectations, which is not the product we want to build

[CaioDGallo]

So my overall flow is similar to yours in some aspects, it tends to be something like:

1. design, plan, etc
2. agent writes code
3. I mostly watch the agent going for major off-course changes or things that drift wildly from what I plan to achieve. I review the changes on posthog code also, no real complaints there but the improvements were very welcome and definitely took away some reasons to leave.
4. after the core work (3 previous steps) I usually go to neovim for the following reasons:
   1. a new flow/feature/library requires a new (or changing) environment variable
   2. there is a function or package being used that I have no idea what it does, so I jump to its definition and investigate if it is what I need.
   3. file search/find and replace related actions
   4. Previously I was handling git "finishing work" outside posthog code but now I am using it.

But now that you mentioned it, since I never stopped to think about it (editors can edit any file) now I realize that probably 80%+ of edits on a given feature would be within changed files, so it would match your assumption that editing the diffs would solve a big part of leaving the app. We are so wired to the old IDE-like workflow that even when not needing it all we tend to reach for it.

Well, this comment turned out to be more of a "self-realization" piece of feedback but the good part we can get out of it is that the reasons to leave posthog code are going away 😄

[CaioDGallo]

i think i still want to be able to explore the full repo file tree, at least for global search and/or grabbing file paths as references, but i don't necessarily need to edit untouched files, and the file tree doesn't need to be as prominent in the UI as it is right now

These items you mentioned are very relevant; they look to be very key to getting to this "search and context gathering" that feels missing