kstenerud

It seems like many ‘vibe coders’ don't realize that they don't actually have a community around them.

Really? You've read their minds and have determined that this is what they're actually thinking?

We see projects having a lot of code activity, heavy CI/CD testing, frequent and large release binaries.

People doing this before LLMs wasn't a problem, for some reason.

Sometimes, it feels like the amount of supported platforms exceeds the amount of actual users.

If you want traction, you need to plan out your optimal territory. Not everyone does this well.

We do not believe it is reasonable for Codeberg to invest our precious donation money into hosting of large ghost projects.

Then kick people off. Alienate them so that they go with less judgmental hosting.

The training and deployment of LLMs has drastically raised the cost of buying hardware, in particular for SSDs and memory. it is money that we can not spend elsewhere to improve our service and foster the mission of Codeberg.

Tough. You knew that you'd be affected by market changes when you went in on this venture. Don't go crying about it now.

These price hikes also lead to a growing digital divide: Small and even large operators are endangered by rising costs, while only the largest cloud companies have reliable agreements for hardware.

Yes, because the few producers of said hardware decided to follow the money. And guess what? They left the fertile ground of their previous market behind, ripe for new competitors to move in (and they're already starting). This is the market at work.

We acknowledge that many developers have started to embrace LLMs as a tool in their workflows. Some use it extensively and rarely code by hand, others delegate only specific tasks to it. We understand that you want to know how the change affects your projects going forward. While we can't give an easy answer ...

This is the primary reason to avoid these guys. Activist vendors are among the most dangerous because of their capriciousness. Especially when they start railing against the market they operate in.

This is a selection problem, not a character problem.

This is a times problem, not a selection problem. The unipolar world order is ending, and everyone responds by turning inward and looking for strong leaders who will protect them against the rest.

They don't need to prove that it's true. They just need to get it repeated enough, with some officialdom thrown in, for it to enter the public consciousness as "true".

The next step is to go dark on data about ICE, immigration, and voter fraud so that nobody can prove the opposite anymore.

This is a very old playbook, and it works extremely well.

I'd actually put one in for Clint Eastwood.

Although most popular knowledge about him revolves around his earlier acting career (Westerns, Dirty Harry), you'll notice a distinct change in many of his films once he started directing.

* Play Misty for Me

* Breezy

* Unforgiven

* A Perfect World

* The Bridges of Madison County

* Midnight in the Garden of Good and Evil

* Mystic River

* Million Dollar Baby

* Changeling

* Gran Torino

* American Sniper

* Sully

* The Mule

Have I? I believe I've merely chased them around their moving goalposts. When it's closed source, that's nefarious because "they're not sharing" and that's against the whole spirit of open source. When it's dogfooding with a reduced audience, it's "shoving vibe coded slop on people" (this information gleaned through magical knowledge). When that unfounded assertion is called, lo and behold: It's closed source, so bad bad bad! It's called a logical fallacy for a reason.

But more to your point: Do you believe in "guilty until proven innocent"? Do you believe that they're doing bad things with the bun code, and you can't be convinced otherwise in your judgment of them until they release the code?

How do you know it's vibe coded slop? Have you seen the source code?

Yeah. One single project that they control. Not thousands of other people's projects breaking, I'm sure with a ton of HN outcry over releasing "this pile of vibe coded slop" upon the poor populace.

You just can't win.

So you wouldn't, for example, after doing a complete ground-up rewrite, perhaps spend a few months dogfooding it to work out the worst bugs before unleashing it upon the public, thus maximizing your initial velocity by minimizing the blast radius and support requests and triage during this phase?

Why is that even a thing to object to? You're talking as if you placed stock in the bizarre idea that Anthropic would close source the project and start charging for it.

Stay your pitchforks.

I've already explained in some sister comments. Sandboxing is one of those things that seems very simple on the surface, and is EXTREMELY complicated once you start actually digging into the implications, gotchas, and security issues. The underlying tools were never designed with this use case in mind, so they need a little help to reach that last mile. And this glue is where all the chaos ensues.

Here's a small sample of the crazy shit you have to deal with: https://github.com/kstenerud/yoloai/blob/main/docs/contribut...

And that's if you're actually following the proper procedures (which are themselves byzantine and tricky to get right).

Heh, good luck with that.

How so? Orwell's stories dealt with class protectionism, and how the average person unwittingly contributes to systems of oppression and exclusion. Empire is about outsourcing the bottom end of inequality.

I discovered this a few months ago when I was describing a binary data format using Dogma. On a whim, I tried handing the task off to Claude and it not only finished it correctly, but also fixed some errors!

It all seems so simple at first. Just launch a container/vm with a base image of your dev environment, mount whatever you need, do your work, and then tear down. Maybe add some iptables rules for good measure. Easy peasy, something any moderately competent dev could do and even put in a quick shell script.

I started with that assumption, but there are a lot more gotchas and security issues than you'd think.

I designed it to provide a single interface to agent sandboxing, no matter how far up the security tower you want to go.

It eliminates the manual process steps you end up doing with an ad-hoc system (which gets old the 10th time you do it).

Common weak points:

- The agent can access your homedir.

- The agent can access .gitignored files, which can contain secrets (and are gitignored for this reason).

- The agent has r/w access to your workdir.

- The agent could follow your remote mounted dirs.

- The agent can act in your name with whatever credentials it finds (and it will use them when it tries to be helpful, especially with the gh tool).

- Do you even know what's in the diagnose_problem.sh file it just created and asked permission to run?

- Even the .git dir can be weaponized, such as with evil filters.

- The agent can edit its own process, bypassing the harness controls and giving it the same access as you have (amplified by each credential sitting on that machine).

Meanwhile, you're reflex-hitting ENTER without looking because 99% of the permission prompts are mundane.

And that's before you even get to all of the idiosyncrasies in the backends that will eventually trip you up. The list is quite large and continually growing: https://github.com/kstenerud/yoloai/blob/main/docs/contribut...

Sandboxing is a VERY HARD problem. I've been working on it for months, and finally have something that's mostly there:

- Sandbox on Linux using Docker, Podman, containerd, gVisor, Kata, Firecracker

- Sandbox on Mac using Docker (Docker Desktop or Orbstack), Podman, Apple containers, Seatbelt, Tart (Tart lets you run simulators).

- Network control

- Secrets control (file mounts or credentials broker)

- NO ambient data (ENV is replaced with a minimal and local-to-sandbox one)

- NO access to your homedir. You have to explicitly mount things you want.

- NO direct access to your workdir: Your work dir is never modified until you apply the changes, either standalone or as a git commit. You can also diff before applying. Git runs sandbox side in case the repo has filters.

- gitignored files never get copied in. The agent never sees them.

- Has built-in support for claude, codex, gemini, aider, and opencode, but you can also launch it in "shell" mode and run whatever you want.

- Supports VS code tunnels, so you can remotely access in VS code if you don't want to use the terminal.

- Full lifecycle support: Launch, attach, stop, restart, wait, one-shot, clone, destroy

- MCP passthrough

- Layered API (golang) if you want to sandbox other things

- Self-contained binary. No external requirements other than the backends you want to use. Defaults to a ~/.yoloai dir for config/data, but you can point it anywhere.

- FOSS

https://github.com/kstenerud/yoloai

You'll never know. And that's fine.

Yup, I built one! https://github.com/kstenerud/yoloai

You can even run simulators in it if you choose the Tart backend.

Not if you've got a good sandbox.

I built yoloAI for this kind of nightmare scenario (among others).

- The sandboxed agent has no access to your homedir, or ANY dir on your machine except what you explicitly give it access to.

- Even with your workdir, it honors .gitignore and refuses to copy in any ignored paths to the sandbox copy.

- The sandboxed agent doesn't have access to your ENV (unless you explicitly pass things through one-by-one).

- Networking can be restricted any way you like.

- Credentials are proxied (currently Claude only), so the agent has access to NO secrets at all.

- You pick the security backend to match your needs (containers, VMs, etc).

- It's FOSS.

https://github.com/kstenerud/yoloai

yoloAI does something similar:

- Sandbox on Linux using Docker, Podman, containerd, gVisor, Kata, Firecracker

- Sandbox on Mac using Docker (Docker Desktop or Orbstack), Podman, Apple containers, Seatbelt, Tart (Tart lets you run simulators).

- Network restriction

- Secrets control (file mounts or credentials broker)

- NO ambient data (ENV is replaced with a minimal and local-to-sandbox one, no host-side filesystem access beyond what you explicitly allow)

- Workdir protection: Your work dir is never modified until you apply the changes, either standalone or as a git commit. You can also diff before applying. Git runs SANDBOX side in case the repo has filters.

- Uses copy-on-write if your filesystem supports it (most modern ones do)

- Has built-in support for claude, codex, gemini, aider, and opencode, but you can also launch it in "shell" mode and run whatever you want.

- Supports VS code tunnels, so you can remotely access in VS code if you don't want to use the terminal.

- Full lifecycle support: Launch, attach, stop, restart, wait, one-shot, clone, destroy

- MCP passthrough

- Layered API (golang) if you want to sandbox other things

- Self-contained binary. No external requirements other than the backends you want to use. Defaults to a ~/.yoloai dir for config/data, but you can point it anywhere.

- FOSS

https://github.com/kstenerud/yoloai

I made a tool that creates sandboxes (docker, podman, orbstack, seatbelt, tart, Apple containers, containerd, kata, firecracker) and then sets up an agent (claude, codex, gemini, aider, opencode) inside it with max permissiveness (no prompts to call sed, etc).

It creates a CoW copy of your workdir for the agent to play in, and then you pull changes out using git diff/apply semantics.

You control network access, secrets, which files/dirs it has access to.

It's a MASSIVE time saver, and I use it as my daily driver.

https://github.com/kstenerud/yoloai

You don't have to use the opinionated harnesses. Nothing stopping you from launching your own.

I've been beating a dead horse over this for months now but nobody seems to listen until it's too late...

1) Sandbox any LLM that has access to tools (I don't mean the pathetic sandboxes the agent harnesses provide).

2) Assign them credentials and use auth/access control like you would for a human.

You might want to give https://github.com/kstenerud/yoloai a try, then.

Runs agents in tmux in sandboxes.

I have the agent inject comments that mention that this particular code is legacy and must not be used as a reference, should not be cleaned up, etc. If you have a document that lists all of the reasons not to use or touch some code, the comments can simply be references to it.

    // LEGACY CODE, per docs/legacy_rules.md §14, §19

The biggest public thing I'm working on is an AI sandbox tool that keeps it separated from your system and secrets.

Changes the AI makes to the "workdir" are extracted via diffs or git commits, so you can see what the AI did before deciding if you want it or not.

It has no access to your home dir, no access to your env, and you can restrict its network access.

Containment can be container or VM level, with a Linux or MacOS contained environment.

https://github.com/kstenerud/yoloai

Hell no. I want you to doubt. More for me.

Calling bullshit on this.

The size of projects I've done in the past year compared to before is mind boggling. There is NO way I could have reached this level of productivity without a properly trained and properly prompted LLM.

What's really interesting to do with all of these people arguing over audio formats (as always happens on HN) is to point a frontier model at this thread.

In a nutshell: nullc, rahimnathwani, zamadatix and vor_ know their shit, and geraldmcboing and PaulDavis are technicially correct but talking past each other. speak_on and TheOtherHobbes are confidently wrong.

And also: 44.1 kHz captures the entire human audible spectrum with room to spare, and 16-bit already goes beyond anything useful for listening. The higher resolution / sample size format is useful for production or archival purposes only.

The two main reasons why you hear a difference between the two formats: (1) it's likely a different master, (2) tiny gain differences in the signal (salesmen use this trick, but it's also easy to do it by mistake).