{"slug": "one-ai-chat-is-not-a-research-workspace", "title": "One AI Chat Is Not a Research Workspace", "summary": "Developer Omid Kashan argues that AI chat interfaces are poor research workspaces and advocates for a Markdown-in-Git knowledge base with an inbox for capturing raw thoughts. He outlines a folder structure and workflow to preserve ideas for future articles, emphasizing that chat is for moving ideas, not keeping them.", "body_md": "*Originally published on omid.dev.*\n\nI was deep in a research thread that was not going to become a weekend post.\n\nThe topic started small: juniors asking an AI to format code that Prettier already owns, or to invent a debounce helper the repo already has. It got larger fast. Sometimes the person is not a developer at all — they have an idea, they paste a warning into ChatGPT, the \"build\" goes green, and they never learn that the message was ESLint. The software can become more sophisticated than the operator's mental model. That is a different problem than \"juniors are lazy,\" and it is too big to finish in one sitting.\n\nThen the conversation itself became the bottleneck. Scrollback got expensive. Earlier distinctions went fuzzy. I caught myself asking the model to remember what we had already decided, which is a bad use of a thinking partner.\n\nThe useful question was not \"which model has a longer context window?\"\n\nIt was:\n\nWhere do the notes live so this can become an article — or a playbook — months from now?\n\nNot in that chat. Not in the next chat either.\n\nChat is excellent at *moving* an idea. It is a poor place to *keep* one.\n\nA long ChatGPT, Claude, Gemini, or Cursor thread will fail a research project in boring, predictable ways:\n\nI already argued that [Cursor should not be the place you debate architecture](https://omid.dev/2026/06/29/how-to-stretch-cursor-pro-with-a-split-ai-workflow/). The same split applies one layer up. The chat is not the knowledge base. The chat is a tool you point *at* a knowledge base.\n\nThe rule:Keep a workspace where ideas can be messy, contradictory, duplicated, and only gradually organized. Do not spend your energy deciding where a thought belongs before you have captured it.\n\nThat sounds sloppy. It is the point. Organization is a later pass, the same way a clean API is a later pass over a spike. If you file every thought into the \"right\" folder on arrival, you will stop writing thoughts down.\n\nI wanted a place with four properties:\n\nJupyter can be that for *executable* thinking — I wrote about a [personal knowledge engine](https://omid.dev/2025/12/28/personal-knowledge-engine-jupyter-llm/) in that shape. This problem was different. Most of the material was not code to run. It was observations, half-formed concepts, examples, and arguments I was not ready to defend. Markdown in Git is the boring tool that fits.\n\nSomething like this:\n\n```\nresearch-workspace/\n├── README.md\n├── inbox/\n│   ├── raw-thoughts.md\n│   ├── examples.md\n│   └── observations.md\n├── research/\n│   ├── cognitive-offloading.md\n│   └── ai-coding-studies.md\n├── concepts/\n│   ├── premature-delegation.md\n│   └── productive-friction.md\n├── examples/\n│   └── linting.md\n├── counterarguments/\n│   └── ai-is-not-the-problem.md\n├── drafts/\n└── outline.md\n```\n\nName the folders for *your* project. The structure is not the insight. The insight is the `inbox/`\n\ncontract:\n\n**Nothing in inbox/ has to be true, unique, or well placed.**\n\nDump dated fragments and move on:\n\n```\n# 2026-08-24\n\nA person hit an ESLint warning, read it as a generic build failure,\npasted it into AI, accepted the fix.\n\nThey did not know what a linter was.\n\nThis is not the same as a developer using AI badly.\n\nMaybe: AI as a substitute for mental models?\n\nNeed notes on cognitive offloading.\n```\n\nThat paragraph is more valuable in a file than it is as message 87 in a chat you will never re-read carefully.\n\nWhen a fragment keeps showing up, *then* promote it into `concepts/`\n\nor `examples/`\n\n. Promotion is a decision. Capture is not.\n\nThis is the part that saves the eventual article from becoming a vibe.\n\nSix months later you will not remember whether you *saw* something or *theorized* it. Chat transcripts erase that distinction because the model blends them for you. Your files should not.\n\nA note in `examples/`\n\ncan look like this:\n\n```\n## Observation\n\nSomeone using AI-generated code hit an ESLint warning. They did not\nknow what ESLint was. They treated it as a build error, pasted it\ninto a chatbot, and accepted the generated fix.\n\n## Interpretation\n\nAI can hide a missing mental model. The failure disappears without\nthe concept ever appearing.\n\n## Hypothesis\n\nResolving a tooling failure through a chatbot reduces the pressure\nto learn what the tool is for.\n\n## Questions\n\n- Is this new, or is it Stack Overflow with a smoother UX?\n- Does it happen to experienced developers in unfamiliar stacks?\n- What would falsify this?\n```\n\nThose four headings are not bureaucracy. They stop you from publishing a confident thesis built on one anecdote plus a lot of fluent continuation.\n\nThe originating research — AI as a substitute for engineering knowledge — is still in that shape for me. This post is not that article. This post is the container I needed before I was allowed to write that article.\n\nCreate a `counterarguments/`\n\nfolder early, while you still like your thesis.\n\nFor every claim you are tempted to tattoo on the outline:\n\n```\n# AI causes deskilling\n\n## Argument for\n\nCheap code production can skip the friction where judgment forms.\n\n## Argument against\n\nEngineers have always used abstractions. Nobody needs to understand\nthe TypeScript compiler to use TypeScript. Libraries already hide\nenormous amounts of knowledge.\n\n## What would falsify this?\n\nEvidence that people who use AI as an oracle still build accurate\nmental models at the same rate, just faster.\n\n## Current confidence\n\nMedium. Do not draft the polemic yet.\n```\n\nIf you skip this, the project will drift into an anti-AI rant. The position I actually expect to land on is narrower than \"AI bad\":\n\nAbstraction is normal. The failure mode is operating an abstraction without enough of its boundary to use it safely.\n\nThat sentence is only trustworthy if I have tried to kill it.\n\nOnce the notes exist as files, the AI job changes.\n\nDo **not** ask:\n\nRemember everything we discussed and write the book.\n\nAsk against the tree:\n\n`inbox/`\n\nand list recurring concepts, contradictions, and research questions. Do not rewrite anything.`research/`\n\n. Where is the evidence thin?That is the same discipline as the [split coding workflow](https://omid.dev/2026/06/29/how-to-stretch-cursor-pro-with-a-split-ai-workflow/): the model executes against artifacts you own. Cursor is unusually good at this part — not as a chatbot with a repo attached, but as an editor that can cluster notes, open three files, and leave the prose messy on purpose.\n\nA useful progression, and I would not skip steps because a model offered to:\n\n```\nraw notes\n  → cluster\n  → name concepts\n  → find contradictions\n  → read the literature\n  → challenge hypotheses\n  → conceptual model\n  → outline\n  → draft\n  → editorial review\n```\n\n**Do not ask AI to turn a pile of thoughts into a book. Ask it to help you think about the pile first.**\n\nIf that sounds slow, good. The slowness is the research. Generating a 4,000-word draft from a chat summary is how you get a fluent article you do not believe next month.\n\n**Git plus Markdown** is the default I would give another developer. Version history, diffs, branches, grep, backup, no proprietary format, and any coding agent can read it. A private GitHub repo is enough. Make pieces public later if you want; do not start public and perform the mess.\n\n**Obsidian** is optional and compatible. It sits on the same Markdown files. Use it if you want daily notes, backlinks, and a graph over `inbox/`\n\n. Do not use it as an excuse to leave Git. The vault should be the working copy of the repo.\n\n**ChatGPT Projects, Claude Projects, NotebookLM** are fine as *lenses*. They are not the source of truth. If the files only live in the vendor's project, you are back to a nicer conversation.\n\n**FigJam / Figma** is for a later pass: once you have a model worth drawing — amplifier vs prosthetic vs oracle, a knowledge-gradient sketch, a hierarchy of \"already solved\" problems. Keep the diagram as a view, not as the archive. Boxes in a whiteboard do not grep.\n\nI would not put this kind of work in Notion as the canonical store. It is a reasonable reading surface. It is a weak object for agents, diffs, and \"this paragraph changed.\"\n\nNot when the chat feels complete.\n\nWhen you can point at files and answer:\n\nIf those answers are fuzzy, you do not have an article yet. You have an inbox. That is a successful research workspace. Treat it that way.\n\nThe chat that started this was useful. It was also the wrong database. I moved the notes out. The bigger piece — when AI becomes a substitute for software-engineering knowledge — can wait until the workspace has earned a draft.", "url": "https://wpnews.pro/news/one-ai-chat-is-not-a-research-workspace", "canonical_source": "https://dev.to/omidfarhang/one-ai-chat-is-not-a-research-workspace-18ae", "published_at": "2026-08-28 22:03:23+00:00", "updated_at": "2026-08-28 22:48:11.774315+00:00", "lang": "en", "topics": ["developer-tools", "ai-tools", "ai-research"], "entities": ["Omid Kashan", "ChatGPT", "Claude", "Gemini", "Cursor", "Jupyter", "ESLint", "Prettier"], "alternates": {"html": "https://wpnews.pro/news/one-ai-chat-is-not-a-research-workspace", "markdown": "https://wpnews.pro/news/one-ai-chat-is-not-a-research-workspace.md", "text": "https://wpnews.pro/news/one-ai-chat-is-not-a-research-workspace.txt", "jsonld": "https://wpnews.pro/news/one-ai-chat-is-not-a-research-workspace.jsonld"}}