The key constraint was keeping the quality bar high.

If I lower the quality bar and _only_ care about a working solution, this works great. And I dare not look at the implementation details if this is the outcome I care about.

But if I want a working solution _and_ have it done the right way, then I need to be in the loop at key points. Newer models, unfortunately, have made this problem worse. I will inevitably come back to some form of bad decisions, deviations or just slop. Left unattended, it snowballs into a pile of mess. At this point, I decide if I spend time fixing it or switch my mental model to not care about the quality.

The problem is worse when there's a team involved here. Fragmented tooling , prompts, harness, model causes more divergence. Especially in quality. Senior engineers become bottleneck as the quality enforcers.

I do like the revert rate metric that Posthog tracks. This can help incrementally build the tooling to a point it can be trusted and scales.

The local stack only became reliable after fixing multiple separate failures in the stack, fixing the coding harness, improving system prompt and other tweaks in different components.

Concrete repo evidence in the post is from Clawrium(https://github.com/ric03uec/clawrium) PRs #855, #859, and #861. Will continue to iterate on this till I can offload about 30% of the project work completely to the local models.

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

Points: 2

# Comments: 1

fwiw, this is my high level process.

1. i keep comprehensive notes _while_ i'm experimenting(like checkpoints). this is a mix of commits and a append-only changelog file

2. if some part of what i've done seems like i can share with public, i create an outline of it. small paragraph with a few points

3. then i ask the model to merge the two to generate a post. i have my own style guide but ofcourse, the model idiosyncrasies will always creep in.

The tool_choice="auto" failure on Qwen3-Next isn't a parser issue — the model reasons inside , decides, and never emits the tool call. No error, just empty tool_calls. The fix was swapping the backbone from Thinking to Instruct, not tuning any parser flag.

The "load the bigger model first, size the smaller against actual residency" playbook generalizes to anything with shared CUDA framework overhead. The ~5 GiB framework floor shows up even at small gpu_memory_utilization values — plan against actuals, not targets.

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

Points: 95

# Comments: 49

So I've been building Clawrium (clm) - a CLI that treats your machines as a fleet and your agents as the things you deploy onto them. Point it at a host, deploy an agent, and you get one command center instead of three terminal tabs.

What works today: - `clm` CLI to configure instances, LLM providers, IP addresses etc - End-to-end install + lifecycle management for OpenClaw (Zeroclaw in progress) - Basic TUI to list all the running agent instances in one place - Normalized config format; Clawrium translates to Openclaw native format but I intend to add support for all *Claws

What's coming: ZeroClaw, Hermes and other claw support, token-usage guardrails across the fleet, config import/export, backups and other goodies. I'm the solo dev on this so I'm building the features based on my immediate needs.

It's built on Python + Typer + ansible-runner.

Still early and rough around the edges. Would love feedback from anyone running agents across multiple machines, especially on what the CLI ergonomics should feel like.

Repo: https://github.com/ric03uec/clawrium

Docs: https://ric03uec.github.io/clawrium/

Announcement: https://www.devashish.me/p/introducing-clawrium-an-aquarium

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

Points: 3

# Comments: 1

1. Experimenting with local models. OpenClaw uses local inference on a DGX Spark machine. Helps me understand how different, newer models work and behave

2. Bot 1 helps me maintain a personal project. It sits in discord channel and I throw ideas at it, ask it to log issues, give me priorities, update docs etc. Basically maintenance work to manage the repo

3. Bot 2 is general purpose assistant to take notes(while driving, on a walk, etc), give me daily AI news summary from trusted sources and my relevance criteria. Give me suggestions on what should I dig deeper

4. Bot 3 is setup for work environment. Sits in slack as my team's assistant. Process meeting notes automaticlaly from google and send us summary for the week/month, important notes from a project, answer questions for rest of the org and more. This is most "real" use case so far for me

I build https://github.com/ric03uec/clawrium as a lightweight orchestration system to manage agents on a local network because i was having a hard time keeping tabs on these agents. all the ssh-ing and config file gymnastics was too much to handle.

Local models (obviously) didn't compare well with the cloud counterparts for this experiment. But I've found them to be useful for simpler tasks with a well defined scope e.g. testing, documentation, compliance. etc

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

Points: 2

# Comments: 0

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

Points: 3

# Comments: 0

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

Points: 1

# Comments: 1

https://www.devashish.me/p/why-5x-engineers-dont-make-5x-tea...

Would love to hear thoughts from others who are trying something similar.

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

Points: 1

# Comments: 1

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

Points: 1

# Comments: 0

Thanks for your inputs. A lot of it resonates with what I've observed which translates to the fact that this is as much a cultural/people problem as much it is a technical problem. If teams took ownership by just building visibility, then it'd be an easier problem to solve.

You bring up a good point of doing canary deployments for solving this problem. I'll check this out.

But its interesting that you say ".. if it is a substantial risk in your domain". Isn't this a problem that most engineering teams are struggling with, especially in last few years? Being part of a few DevOps meetups in my area(Seattle) for a while and having attended a bunch of conferences in last couple of year, I've noticed cost coming up as one of the most recurring discussion topics. Just curious why cloud costs wont be a risk in any domain.

The problem is when 30 odd microservices (each team owning between 5-10) talking to each other. In pre-production setup, changes in few of these services might not have noticeable impact on cost which will become quite apparent in production. When this happens, we definitely notice an increase the cost and the unit metric. But then we dont know where to start fixing this problem from. Right now, this becomes a war-room situation based on the severity but I dont think this is sustainable.

In comparison, if we take API latency as a metric, the accountability and ownership are clearly defined: If an API slows down, the team that owns it, fixes it. They can work with anyone they need to but its their job to fix it.

Did you face similar concerns/issues? Not sure if this is a problem other engineering teams are struggling with or even considering as a real problem to invest it.

I'm also not sure if theres a "standard" way of doing this which we should be thinking about. So, looking for ideas and thoughts here.

Since cost is not really a "deliverable" for non-platform teams, this incentive doesnt go far. Especially after a few iterations of this are done, saving 1K is hard.

We did a short program(similar to a bug bash) for a couple of sprints to dig up all the improvements we can do to reduce to cost. This was early in our cost reduction journey. This did help us get a huge list of what we can do and we picked the most impactful items from this.