Comments URL: https://news.ycombinator.com/item?id=48482437

Points: 2

# Comments: 3

Comments URL: https://news.ycombinator.com/item?id=48373569

Points: 4

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=48356837

Points: 2

# Comments: 0

at the same time, context poisoning is a real cognitive problem for humans too and I can't tell you the number of times I've seen irrelevant details become a drag on execution. my fear is that having too much context will only cause bikeshedding and a revisiting of prior decisions.

frankly, our organizational structures were already pretty good at creating mechanisms for eliciting the right implicit context at large scales. it is possible that we're just going to come up with the same mechanisms from first principles...

a couple of months ago I had to analyze a few thousand audio recordings to help identify issues with customer support. i was able to get some raw high-level initial results with python scripts invoking LLM APIs, but they were too general and unhelpful. writing basic prompts is easy, but tuning them and making them specific enough to ensure no faint signal is missed is hard. you need to iterate through the data with an initial prompt, segment the data into different buckets, chain another prompt for each bucket etc. Then you need to constantly review the raw data to tweak the prompts just the right way to get the desired results.

There are no good user-facing tools for scaling to thousands of rows of unstructured data analysis with LLMs. Claude Cowork / agents with access to filesystems are scratching the surface, but having a text-only UI is challenging, especially when you want to go back and adjust your research pipeline, narrow down deterministically to a specific subset of your data with SQL-like filters, or do any cost management. Scaling past 100 files is not well supported. Deep research is difficult to steer and verify.

I needed a mini-data warehouse that could help me get insights out of my data, optimize costs with bulk LLM operations (via cost estimation and model choice), and let me browse and verify the data in a user-friendly way, without requiring me to set up something like Databricks. So, I built folio.

Folio is a free, local, macOS app for analyzing your unstructured data with LLMs. It's a UI wrapper around a minimal data warehouse that lets users (and agents) do LLM-based transformations on big unstructured datasets. All you need to get started is an AI API key and an account with modal.com

Users bring their files into Folio which then get loaded into a tabl, where each row contains a markdown representation of the file contents. Users can then run LLM operations in bulk on those files and use sql filters to create views and narrow down the scope of the transformations. Agents are a first-class citizen and they can plug into folio to do most of the work for you. To take load off the desktop for OCR/Audio Transcription as well as the thousands of http requests to AI APIs we integrate with modal.com as the execution engine. A local orchestrator fans out jobs to modal and then fans them in once complete. Data is never stored anywhere, and only moves in transit through AI API provider and the user's own modal infrastructure.

folio workspaces are multi-modal (you can load different data types in the same workspace and move it through the same analysis pipeline) and they can support thousands of files.

People use folio today to: - review customer support tickets/emails: bucket issue into different categories, narrow in on categories of interest, and then action that data by generating a response. - extract detailed data from financial documents: load all data that can be found on a particular company, extract structured data like revenue numbers and projections. - do literature reviews: there are lots of agents that help you load data from research paper repositories. once that data is loaded into folio, users can do a steerable deep research over those files. - perform criteria-based search: generate yes/no criteria like "document contains data on XYZ", "document mentions ABC", "documented cites XYZ".

Companies like v7labs, hebbia, Legora, Harvey have similar "Tabular Document Review" features, but they are not scalable or compatible with outside agents like Claude Code. Additionally they require expensive enterprise contracts.

I see folio moving beyond data analysis into the perfect companion for agentic tasks that require a human-facing UI/UX, cost management and actioning on data in bulk.

Website: https://www.usefolio.ai Github: https://github.com/usefolio/folio X: https://x.com/usefolio_ai

Looking forward to hearing what people think!

Comments URL: https://news.ycombinator.com/item?id=47532301

Points: 4

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=47415806

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=47047544

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=46975150

Points: 1

# Comments: 0

its interesting to see how "lock-in" is the main pitch here. all things considered, i don't think "lock-in" is relevant at all unless the activity performed with the tool is highly strategic to the company.

you could argue that some orgs may not want openai/anthropic to have their sensitive data leave the parameter, but im also here to tell you that even the most privacy sensitive companies in the world probably resolve this by having a proxy in between the users and the LLM APIs from the labs.

so where does this leave you ? cost savings from OSS? maybe, but its hard to imagine that we are in the phase of the adoption cycle where companies have become as acutely aware of costs as you think they are.

my 2c - focus on the integrations and see which one gets most traction. that will be your value capture mechanism long-term.

Comments URL: https://news.ycombinator.com/item?id=45790325

Points: 25

# Comments: 8

ng3n is more of a grid-like workflow solution on top of documents. it's a user-facing application geared towards non-technical users that have processing needs.

if there are all these new problems that became solvable, what exactly are they?

id be interested in replacing datalab with extend, but im not sure what avenues that opens for ng3n. would be very curious to learn!

Comments URL: https://news.ycombinator.com/item?id=45497994

Points: 3

# Comments: 0

Engineers that refuse to acknowledge constraints, whatever the nature of those constraints may be, are not engineers. At best they are ideologues, at worst they are just incompetent. The most pathetic thing you can do is just continuously deny the laws of physics and reality, because it doesn’t suit you at some ideological level.

Truly elegant solutions are those that account for all constraints in the simplest, most concise way. It is those that do more with less.

i've seen this happen with people that have had much much smaller financial success in the industry..or even ones that haven't had any at all. you are either naturally inclined to identify with the culture or you trick yourselves into it so that you may belong.

the culture of SV today is an amalgamation of Taylorist ideas, Randian objectivism, Utilitarianism etc etc. there is a lot of social capital to be earned by embodying the values of these currents. DOGE is a quintessential representation of this. it is not surprising at all that author had such a visceral reaction to it.

its important to emphasize that there have been very successful companies that have gone against the current (ie Apple), with an emphasis on craftsmanship, obsession with the process, taste-driven vs data-driven decisions and appreciation for things that are outside of profit maximization.