I like Cognition as a company and hope they succeed. Seemingly excellent engineering org.
I used to really like Windsurf. (Now Devin. Kind of? But also now Antigravity.) I still use it as my editor but haven't touched the agent for a while simply due to the rise of Codex.
They allow 3rd party sellers in their platform and in their warehouses
There's many reasons for this but they include:
Somebody will compete in every segment: building the taxis, operating them, and vertically integrating them. Put another way - some people will buy taxis in this model either way, so Tesla is incentivized to participate in this also. That helps them get economies of scale.
It also of course minimize risk. But not just the obvious kind. It also minimises risk of a niche competitor taking the buy to own robotaxi market and from that wedge becoming a substantial competitor.
But also like Amazon - operators should worry about Tesla taking the data they have about most successful routes and using that to compete directly in the must lucrative identified markets.
Actually, while I still like your point there really is still a lot of operational work.
You need to clean, inspect, repair, insure, secure and charge the cars. To do so efficiently you will need to custom develop premises full of chargers and efficient charging and cleaning infrastructure.
That absolutely is operationally intense. Premises, permits, construction and then significant operations.
They could, but running local operations isn't his forte, preference or interest, it seems. Even if he had a massive fleet of these, he'd have to navigate local laws, demand, operations and logistics.
His revealed preference is to run things centrally and at massive scales.
> They could, but running local operations isn't his forte, preference or interest, it seems. Even if he had a massive fleet of these, he'd have to navigate local laws, demand, operations and logistics.
You wrap it but there must be some kind of call you're making to your API. So are you saying that call fires immediately, races the main wrapped execution, and is therefore done when the execution is finished, therefore neglible latency except for cold starts on extremely short functions?
How does the probe function technically. Inspector API I believe is unavailable on CloudFlare etc.
I once wrote something like this which could work on serverless platforms without the Inspector API. It used Typescript AST transforms to insert no-op listeners at every line, so they would dynamically eval or dump breakpoint style if a listenToLine parameter equalled their line, otherwise no-op. So trivial but not technically zero runtime cost.
makes no difference if its cold or warm start. (The latency because of us, not latency in general)
Using AST, that's clever actually! I thought along somewhat similar lines. User tree-sitter. But it needs a build step! not sure how people feel about that :D
It changes your source code itself so we'd need a 2 tiered source resolution. Dirty, but doable.
And instead of having this at every line, i did this at "lines of interest"
before and after every scope ends.
so at the start/end of an if condition, start/end of fn definiton.
it sort of worked, but it slowed down our synthetic benchmarks for "no effect when probes arent there" by more than what i wanted to tolerate
and it depended of eval which i thought devs wont accept.
and using node-vm slowed it further
But will give another try again. thanks for sharing this!
If I was building this for serverless I would transform with two copies of the code: instrumented and not. Then do one single if statement between them.
If you are transforming anyway you're looking at virtually zero dev time cost and runtime cost when no probe is active of less than 1 ms.
This approach survives any environment I know of and has almost zero runtime cost.
This debugging in production thing has always been interesting to me. Rookout, etc.
How does it work? Using the NodeJs inspector API or other language equivalent to drop breakpoints? Those APIs are unavailable in many serverless environments and are challenging to use alongside bundlers.
YES!!!
for nodejs, inpector API is used. But if you're adding dynamic logs or metrics, we dont even call the inspector completely. we return an expression that will always evaluate to false and safely evaluate our the log/metric. saves time and computations happen in the same cpu cycle
You're correct inpector API is not available in many non-v8 targets. Bun also has somewhat of a partial support for inpector API but at least has a programmable debugger interface. It's not going to be as fast as native inspector but its better than nothing i guess :P
for python sys.monitoring. for JVM, we do bytecode manipulation itself.
bundlers are not an issue because we support sourcemaps.
We just need mappings, not code in the sourcemaps and we do sourcemap resolutions out of process so that your app doesnt spend ~200 MB of memory for parsing sourcemaps
Why is it hard? Ultimately you take whatever your signal is and send it to some relatively cheap LLM.
How is it easier to sign up and manage a different service, implement a different API, etc.
And from the company side the fatal flaw is that these types of tools rely upon 1% of their users having huge spend. Nobody is going to be a huge spender here because it's easier to hand roll than navigate procurement on this (not to mention impossible to justify the spend, additional security/privacy risk, etc.)
It feels approximately impossible for this company to have large accounts.
it gets hard when you need this continuously across lots of chats/calls, with metadata, changing clusters, going deeper into a user journey, etc. the LLM call is just one part of it lol
we're keeping it useful every week, finding out insights that the teams can extract value out of, work with them to understand users better.
the procurement what we've seen is v similar to how one would have for any analytics product? and we're selling this to companies when/once it becomes someone's job to do this
Why... why do companies keep taking every tiny feature and trying to productize it?
In the tradition of boring software, even before LLMs it was much simpler to just use your existing tools and hand-roll. With LLMs I cannot fathom reaching for a product for something small like this.
i agree w you for smaller teams tbh. if you have a few hundred convos and someone can maintain scripts/prompts, hand-rolling is probably fine.
it becomes less tiny when it’s 10k+ msgs/week, long voice calls, metadata, changing clusters, retention/redaction, and the team wants this continuously without maintaining another internal tool.
but i'd still wanna know how you'd do this with existing tools before llms?
Must admit, for this particular case I don't see the appeal in using a wrapper.
Why would I not just use Codex directly?
The we wrote a bunch of prompts argument is kind of meh. That sort of thing has not only diminishing value with subsequent model releases but I actually believe will turn negative. The model will know better by default.
For example, initially giving the model some advice on code best practice was helpful. But now it's unhelpful because the model already knows best.
I used to really like Windsurf. (Now Devin. Kind of? But also now Antigravity.) I still use it as my editor but haven't touched the agent for a while simply due to the rise of Codex.
reply