Launch HN: Poly - Cursor for Files and the link-first office

Poly makes the file system feel overdue for a rethink

When Poly launched on Hacker News as "Cursor for Files," the pitch landed because the pain is familiar. Most teams have terabytes of folders, screenshots, PDFs, presentations, contracts, spreadsheets, videos, brand assets, research notes, and half-finished drafts. The problem is not that files disappeared. The problem is that we kept adding more file types while the basic experience stayed close to Finder, File Explorer, Dropbox, and search boxes that work only when you remember the right name.

Poly's Launch HN post described an app meant to replace the normal file browser with something more searchable and active. It can search across many file types in natural language and then help with actions like summarizing, renaming, tagging, moving, annotating, and organizing. The public examples in the launch included archives such as Whole Earth Catalogues, PlayStation manuals, Orson Welles material, and Dali artwork. That is a good demo choice because it shows the real use case: large messy collections where browsing folder names is not enough.

The Hacker News thread also showed why the phrase "Cursor for Files" works. Cursor changed how many developers think about editing code because the editor can read context and help make changes. Poly is making a similar argument for files: your file browser should not just show icons. It should understand what is inside them, help you find the thing, and do some of the busywork around it.

Poly's strength is retrieval across messy work, not office publishing

The fair way to look at Poly is to start with what it seems genuinely strong at. If you have a large archive and you need to ask questions across documents, images, audio, video, PDFs, decks, and spreadsheets, a semantic file browser is much more useful than folder discipline. Most people do not name files well. Most teams do not keep a perfect taxonomy. Search has to survive human mess.

That matters for research teams, creative teams, legal teams, agencies, founders, and anyone who has ever searched for "that one deck from last quarter with the blue chart" and failed. A file-aware agent can save time before any writing or presenting begins. It can help you locate source material, extract summaries, compare assets, and clean up a pile of files that would otherwise become digital sediment.

But finding files and publishing work are different jobs. Poly starts from the premise that files remain the main container and should become more intelligent. Plain starts from a different premise: for many office artifacts, the file is the wrong final format. A deck, doc, or sheet usually ends up being shared with people who only need to read it, comment on it, present it, or reuse part of it. Sending another attachment creates versions, permissions confusion, export friction, and the familiar "which file is latest?" problem.

The AI-era office should end in a link, not another attachment

In old office workflows, the final object is a file. You draft in Word, PowerPoint, or Excel, export if needed, attach it to Slack or email, and hope nobody edits the wrong copy. In the AI era, that workflow feels backwards. AI can draft a structure quickly, but the real value comes when the output becomes something other people can open instantly and understand without downloading software or asking for the latest version.

That is where Plain's difference is sharp. Plain turns office work into shareable web pages: a deck as a link, a doc as a link, a sheet as a link. You can start from an AI-generated structure, then edit by clicking elements on the page. If you prefer source, you can work in Markdown. If you need to present, you present from the browser. If a stakeholder still asks for PowerPoint, export .pptx as a fallback instead of treating export as the main event.

This sounds small until you compare the daily behavior. A file asks, "Do you have the app? Did you download the right copy? Can you open this version?" A web page asks, "Can you open a link?" That is a much lower bar for customers, investors, classmates, managers, and teammates. It also matches how the rest of the internet works. We share Notion pages, Figma links, dashboards, docs, and prototypes as URLs. Office artifacts are late to the same shift.

Click-to-edit matters because AI drafts are never done

A lot of AI office tools stop at generation. They can produce a deck outline, a memo, a table, or a polished-looking first pass. That is useful, but it is not the whole job. Real office work is revision. You move a title, tighten a sentence, swap a chart, delete a weak slide, add a footnote, split one idea into two pages, and adjust the hierarchy until the thing reads correctly.

This is where click-to-edit is more than a nice interface detail. If AI gives you a web page and every element is directly editable, you do not have to bounce between prompt writing and manual cleanup. You can use AI for the blank page problem, then use your eyes and judgment for the last mile. That is usually where quality comes from. The editor needs to respect that humans still make the taste decisions.

Markdown matters for the same reason. Some people think in visual layouts. Some think in text. A good AI-era office tool should let you move between both. Markdown keeps the source simple, portable, and easy to rewrite. Direct editing keeps the page grounded in what the reader will actually see. Together, they make AI output feel less like a sealed artifact and more like a draft you can control.

Poly and Plain point to two sides of the same file problem

Poly is about the work before the artifact is ready. It helps with the pile: the archive, the folder, the asset library, the forgotten PDF, the file you cannot remember how to name. That is a real problem, and Poly's launch made it clear that people want their computers to understand file contents rather than only paths and filenames.

Plain is about the work after the artifact starts taking shape. Once you are making the deck, doc, or sheet that someone else needs to consume, the better container is often a web page. The AI can help create the first structure, but the final object should be easy to share, edit, present, and keep current. A link is simpler than an attachment because there is one destination instead of many copies.

There is overlap, of course. Both products react to the same frustration: the file system was built for a world where humans did all the reading, naming, searching, converting, and organizing. AI changes that. But the product choices are different. Poly makes files smarter. Plain makes the office artifact less file-like in the first place.

The practical choice depends on whether you are finding work or shipping it

If your main problem is locating information across a huge collection, Poly is worth watching. It seems built for the moment when you know the answer exists somewhere in your drive, but normal search cannot reach it. For research, archives, media libraries, and messy team folders, that can be a serious time saver.

If your main problem is creating something people need to read, review, or present, a link-first workflow is usually cleaner. Plain is not trying to be a smarter Finder. It is trying to make decks, docs, and sheets behave like the web: open instantly, share cleanly, edit directly, and present without turning the artifact back into a file unless you have to.

The deeper lesson from Launch HN: Poly (YC S22) - Cursor for Files is not that every app should copy Cursor's branding. It is that office work is being rebuilt around context and action. Files are no longer passive containers. But for many outputs, the best move is even simpler: stop sending the file at all. Send the page.