bhl

Usually with Business or Enterprise plans, there's a privacy mode where OpenAI and Cursor / Windsurf can't train on user data.

That's very ambitious. You have companies and startups at each of those layers right now: code, pull request reviews, issue tracking, documentation.

It's cheap but also lazy. It sometimes generates empty strings or empty arrays for tool calls, and then I just re-route the request to a stronger model for the tool call.

I've spent a lot of time on prompts and tool-calls to get Flash models to reason and execute well. When I give the same context to stronger models like 4o or Gemini 2.5 Pro, it's able to get to the same answers in less steps but at higher token cost.

Which is to be expected: more guardrails for smaller, weaker models. But then it's a tradeoff; no easy way to pick which models to use.

Instead of SQL optimization, it's now model optimization.

Paste it into Claude and ask it to made the minified code more readable ;)

Agree the code should just be open source but there's nothing secretive that you can't extract manually.

For context.md, it's that simple because it's unstructured data extraction from your codebase and working with a regular LLM model.

For design.md, I have a prompt because we're now working with a reasoning model and doing structured data extraction: create me an issue on Linear with a title, description, and a to-do list.

I would recommend trying the approach yourself and saving the prompts if you can nail down the repetitive asks.

Haven't tried Windsurf yet.

Chat function is just chat; it can't edit your files.

Composer probably relies on prompt engineering to do editor-architecture, as it reads and writes to your codebase. But it's heavily heavily to Sonnet 3.5 and tool-calling.

For architecture-type stuff, I prefer DeepSeek R1 as reasoning models do better on high level design. Which is why I will copy and paste in and out of compsoer.

I use it everyday.

For coding, I use cursor composer to gather context about the existing codebase (context.md). Then I paste that into DeepSeek R1 to iterate on requirements and draft a high level design document, maybe some implementation details (design.md).

Paste that back into composer, and iterate; then write tests. When I'm almost done, I ask composer to generate me a document on the changes it made and I double check that with R1 again for a final pass (changes.md).

Then I'm basically done.

This is architect-editor mode: https://aider.chat/2024/09/26/architect.html.

I've found Cursor + DeepSeek R1 extremely useful, to the point that I've structured a lot of documents in the codebase to be easily greppable and executable by composer. Benefit of that is that other developers (and their composers) can read the docs themselves.

Engineers can self-onboard onto the codebase, and non-technical people can unstuck themselves with SQL statements with composer now.

Look into immunotherapy trials at hospitals like UCSF. They might have pre-existing conditions which would make them in-eligible however. In any case, try to spend as much time with them as possible; you won't regret anything when they pass.

Any non in-memory search indices? Was hoping to find one that used indexeddb to implement fuzzy search. Maybe that’s just not as performant which is why I haven’t found a popular library yet.

Any grounding with google maps or mapbox, etc?

Four Square just open sourced their places dataset. https://location.foursquare.com/resources/blog/products/four...

Given how expensive it is to query Google places, would love a crowdsourced open-source places API.

Is sandboxed browser environments on your roadmap? Would much prefer to use the client's runtime for non-computational expensive things like web dev.

> We now use QuickJS, a JavaScript VM written in C and cross-compiled to WebAssembly.

https://www.figma.com/blog/an-update-on-plugin-security/

Makes a lot of sense given they released Artifacts previously, which let you build simple web apps.

The browser nowadays can be a web dev environment with nodebox and webcontainers; and JavaScript is the default language there.

Allows you to build experiences like interactive charts easier.

Serverless git repos would be useful if you wanted to make a product like real-time collaboration + offline support code editing in the browser.

You can still sync to a platform like GitHub or BitBucket after all users close their tabs.

A long time ago, I looked into using isomorphic-git with lightning-fs to build light note-taking app in the browser: pull your markdown files in, edit them in a rich-text-editor a la Notion, stage and then commit changes back using git.

Was looking into local DuckDB notebooks and found this: https://www.duckbook.ai/

I've done the same with mobx-state-tree, and realized I was essentially building a relational database with cache-ing in JavaScript.

The only thing SQLite is missed, which is important when integrating with React, is incremental view maintenance: how do we maintain as much immutable state on an update as possible to avoid wasteful re-renders?

The project is open source (https://github.com/Brayden/starbasedb/blob/main/src/index.ts). Yes to it provides a way to update Cloudflare's SQLite with HTTP.

You get tighter feedback loops and better products if you own the vertical.

OpenAI already A/Bs test the responses it generates. Imagine if they own the text editor or spreadsheet you work on too. It’ll incorporate all of your edits to be self-correcting.

I was coincidentally looking into this yesterday, trying to find an implementation of JS sandbox to run AI-generated code or web apps in.

A similar project is sandpack, but that relies on nodebox which is also closed source.

One insight I’ve gleaned from working on this project is that I’m convinced web dev will trend towards well-designed and modular components with accessible state and mutators.

LLMs will then have a set of these components to dynamically route and build interfaces with.

Component libraries are already popular and more time will be spent inside of them than managing the glue that is outside.

Prompting GPT to do rich text editing.

Instead of replacing the entire document or selection, we want it to create diffs or operations for the minimal amount of edits as possible. This helps preserve intent better when merging the doc later on with OT/CRDTs. (Of course, you could also ask GPT to semantically merge docs for you haha).

So far, it's been harder than plain text or spreadsheets which have an easier position/coordinate system to work with: just line-col or row-col.

Rich text is usually stored as trees with json or html. Have seen a paper (https://www.inkandswitch.com/peritext/) that represents it as a flat array.

Difference in approach would then be: is it easier for gpt to work with diffs or with operations/tool calls?

I wonder if tool-calling to output schema'd json would have a low error rate here. For each field, you could have a description of what is approximately right, and that should anchor the output better than a one-off prompt.

What library do you use to compute embedding right now? I'm wondering if it's possible to do both embedding and vector search client-side for a local-first app.

Checkout this discussion

https://discuss.codemirror.net/t/codemirror-6-and-typescript...

or this package

https://github.com/val-town/codemirror-ts

DevTools is open-source!

https://github.com/ChromeDevTools/devtools-frontend/blob/mai...

Does Caltrans have any history of developing profitable mixed used properties around new stations, like with the MTR Corporation?

https://en.wikipedia.org/wiki/MTR_Corporation

It seems this is not a full rewrite of the calculation engine, so it’s hard to compare the performance of JavaScript against WASM.

Has anyone rewritten a performant calculation in that way from JavaScript to WASM? I’m curious to what the performant gap is, and whether browser optimizations are closing or widening that gap.

What’s the difference between tool calling and “agents”?

How would you handle map-reduce type of tool calls where you have a lot of parallel tools that you want to merge later on? What’s a good way to scale that without running into API limits?