benswerd

I’m confused what you mean, I post on either subdomains of my own website for personal projects or blogs on my company website freestyle.sh.

My twitter is @benswerd.

What are you saying?

I'll say this: as a very competent engineer I have gone weeks at a time without handwriting a single line of code in the past few months. It is where the industry is going.

With respect to CSS expertise, I don't need/want perfect CSS at my company, I want styling that is clear and workable. Tailwind and ShadCN gets me there, my most backend-y backend engineer gets tailwind. The job of CSS on my team is not to be beautiful or top 1%, its to function.

i agree, very pro that

I'm a big believer in guides. ShadCN provides great starting points for continued engineering as do other ShadCN libraries. For companies with the resources to, they do just start with BaseUI.

In the long run I think most UI will be BaseUI/RadixUI + Component and style guides, prompts, and traditional packages will no longer be relevant.

Just did this, found result fairly interesting, I reject most of its objections on the basis of bad code. When I say Im pro explicitness I'm also pro comment, and pro separating the "this is core fact" and "this is configuration that i don't care too much about". Will use this test for future writing.

This is a fair point. Im not opposed to the open function existing, but I do think its valuable to own the underlying implementation of thigns like it (maybe not open) in your codebase so you can review the implementation and reconfigure it to your precise requirements.

One strategy I like for this is a notes field on every single MCP route. Lets the AI optionally just decide to tell you things.

I think this is a misinterpretation. BaseUI provides baseline semantics that because the code is in your codebase you can choose to keep or remove. BaseUI is also actively unstyled/unopinionated, you use it to compose your own components, which again live in your codebase.

When you import shadcn components you can rebuild them however you want, thats the point.

gonna use it on my websites homepage

im not opposed to good defaults, i just believe they should be explicit. The AI should read the starting.md to fill in explicitly what its JVM configuration is. Then, when you want to tune in the future its clear what options are available and what specifically is changing.

Conservatively speaking, LLMs degrade past 40% of a 2M context window, 4k tokens is 0.2%, so no degradation there. Thats also current generation conservative estimate.

I think wasteful is an irrelevant metric. Claude ingests those tokens in a quarter of a second, if it causes it to catch any bug ever it saves far more time than it ever uses.

Any individual default that causes unexpected behavior causes more problems, takes more time and costs more than the small cost of being explicit.

Think MUI, heroUI, traditional components have you install their package, import the component and configure it through arguments.

ShadCN components have you copy the component code into your codebase, you own it. They come with the ability to configure arguments, but also because the code is yours its expected that you change the internal logic/styling/structure of the component.

I believe in the era of AI code the ladder just makes more sense.

Why not?

The docs for git clone at https://git-scm.com/docs/git-clone are less than 4000 tokens, I don't think this is unreasonable.

MCP Auth is just Oauth, its designed for humans to authenticate their sessions for connections.

TBH I know nothing about A2A.

Agent Identity and Authz is a different problem, allowing agents to operate independently from humans with granular permissions is coming/whether from these protocols or others, and when it does I think CLIs/CLI Device Auth which is used as a rough proxy for this where the agent just takes your identity will finally go away.

Generally, when using these components I ended up wanting to customize a lot. I switched around the options, coloring, the words in the loading, I mix and matched the components from different CLIs, etc.

I think these are more useful as baselines than as final destinations, and I expect production users to customize them far more than options in components.

I also separately don't really believe in traditional components anymore, code is cheap. The value in these components is that I took the time to pixel match a bunch of the CLIs, not the specific interface used to integrate them.

Without using agnost, what are some basic SQL queries I can run on my data to find outliers I'd otherwise be missing?

How far can I get with just keywords, common phrases, boring traditional analysis?

Depending on what I measure there, when is the right time for me to consider upgrading to something like Agnost/what is a specific example of what it will find that traditional/rigid analytics approaches will miss?

Been feeling this more recently, building got 10x easier but choose what to build kinda got harder.

a pricing calculator showing the prices of different sandboxes with dials to compare them in practice.

Live migrations and the tech powering it was the hardest thing I ever built. Its something that I think will come naturally to projects like smolVM as more of the hypervisors build it in, but its a deeply challenging task to do in userspace.

My team spent 4 months on our implementation of vm memory that let us do it and its still our biggest time suck. We also were able to make assumptions like RDMA that are not available.

All that to say — as someone not working on smolVMs — I am confident smolVMs and most other OSS sandbox implementations will get live migration via hypervisor upgrades in the next 12 months.

Until then there are enterprise-y providers like that have it and great OSS options that already solve this like cloud hypervisor.

Its actually almost O(1) with respect to fork count. We have some O(N) behaviors but I expect to be able to remove those in the next 6 months and get to full horizontal fork O(1) any VM any fork count.

We read your blogs when building all of this!

Freestyle isn't designed for an individual engineer working on their Github repos. Its designed for platforms building coding agents that want to take the place of Github all together. Those platforms need some source of truth alongside the VMs, just like how you don't store all of your important documents on your personal computer. That is why we offer git.

I'm not sure what you saw as slow, I'd love to improve it. Do you mean the dashboard?

We're built as an API for platforms to build on rather than tool for individual developers. Oriented at platform orchestrating tens of thousands at VMs rather than individuals using CLI. We also have a CLI but its primarily a debugging and testing tool.

Resuming a freestyle VM with claude code in it will just work. You can do that via SSH.

So first I don't, I think startup times are fundamentally really important. 5s is different than 1s is different than 500ms is different than 200ms and users notice.

I don't think people run real world benchmarks on what that coldstart really means though, like time to first response from a NextJS is a very important benchmark for Freestyle and we've spent a lot of time on it. While Daytona sandboxes boot faster than Freestyle ones our first response is an order of magnitude ahead of theirs.

I think another important one is concurrency: In worst case scenarios how many VMs can you get from a provider in a 5 second period is important.

I also think not enough time is spent on "Does it actually work on this VM", stuff like postgres, redis, ntftables, complex linux binaries that are hard to run need to work on these sandboxes because AI is going to need them and I don't think there has really been a feature-bench system yet.

Networking/snapshotting/persistence characteristics all also need to come into this.

I

This is a good note. We've never been great at explaining what we're doing and plan to do a lot more work on making it accessible/make sense.

I don't believe so. while it is technically easy to fork claude code running in these VMs, its not technically difficult to fork a conversation loop outside of the VM as well.

What matters is that its all forked atomically, which can be done with resources outside of the VM as well.

If git isn't for you we'd still love to support you. We believe to build the sandboxes for coding agents you also need to provide git repos for them so we do that as well. You can easily say give me this vm with these 3 repos and these permissions with us.

But that said, the sandbox stands on its own without it.

This assumes you can retain the same state after an operation.

"I wonder if this is slow because we have 100k database rows" DELETE FROM TABLE; "Woah its way faster now" But was is the 100k rows or was it a specific row

Thats a great place where drilling bugs and recreating exact issues can be really problem, and testing the issues themselves can be destructive to the environment leading to the need for snapshots and fork.

That + its not always simple to replicate state. A QA agent in the future could run for hours to trigger an edge case that if all actions to get there were theoretically taken again it wouldn't happen.

That can happen via race conditions, edge states, external service bugs.