alienchow

Connectivity density also means longer commute time. 15km can take 1.5h unless you have a train station right at your doorstep.

All instructions to LLMs are merely suggestions to nudge it in the right behaviour. Unless you have a deterministic guardrail that guards against a single specific action, everything else is a slot machine that's biased strongly in your favour.

My global CLAUDE.md explicitly states "When commenting on code and configs, or writing MD files, strictly write within the domain of the content being commented on. DO NOT include information, negatives or ramblings from work sessions. For e.g. if commenting on a proto string field that is replacing an int field, do not comment that 'this is not an int field'".

This reduced the idiocy of the agent (Opus 5 included) when writing documents. But I'm still catching it writing README.md talking about the negatives that it removed. Those belong in the memory if it is actually that important (most of the time it's junk), but Claude doesn't seem to understand and never ever learns.

It would depend on whether the computers back then could handle that (along with all the crypto algorithms in their infancy) when A:\ and B:\ weren't even a thing.

The infrastructure layer would have to create the interface for a custom operator to reconcile with. There are a fair bit of bridges out there to enable this. There's now Kubevirt for VM management and Metal3 for baremetal configurations as well. If the operator isn't readily available from the selection of community solutions, the platform team would have to implement it themselves. Kubernetes is really just a glorified etcd store for any manifest schema (CRD) you implement alongside a reconciling controller. It just so happens that the default use case of it was designed for container orchestration. Once you look past Kubernetes as purely a container orchestration tool, you can use its paradigm to implement your own declarative reconciliation logic for anything.

I know that's not a satisfactory answer but the infrastructure models (for VMs or Windows machines) would have to be implemented into the new paradigm bit by bit to make this work. This used to be something that was laborious but you could have Claude Code cook up something for the loop interfaces and have a working controller prototype in a short time.

Not saying the integration is going to be simple though. The team has to actually buy in and prioritise building the controller logic for each platform solution. And that includes reviewing the code slop that Claude creates.

This is the way.

But the downside is that you do get the Cider team constantly messaging and asking for reasons you won't switch. I gave feedback that their Vim bindings were broken (it would sometimes fail on holding down directional hjkl for no reason) but I'm not sure if they've fixed it since I left in 2023.

Cider is good for writing g3docs though.

Spin up one in the US central region instead of an instance near your satellite office. The bottleneck is usually not your shell connection to the instance but the connections from the instance to all the infrastructure that's mainly based in the US.

I'm not familiar with the jargon either, but based on some reading it comes down to how the latest kernel treats process preempts.

Postgres uses spinlocks to hold shared memory for very critical processes. Spinlocks are an infinite loop with no sleep to attempt to hold a lock, thus "spinning". Previous kernels allowed spinlocking processes to run with PREEMPT_NONE. This flag tells the kernel to let the locking process complete their work before doing anything. Now the latest kernel removed this functionality and is interrupting spinlocking processes. So if a process that is holding a lock gets interrupted, all other postgres spinlocks processes that need the same lock spin in place for way longer times, leading to performance degradation.

What I don't understand is that, if coding agents are making coding obsolete, why do these vibe coders not choose a language that doesn't set their users' compute resources on fire? Just vibe rust or golang for their cli tools, no one reviews code slop nowadays anyway /s.

I do not understand the insistence on using JavaScript for command line tools. I don't use rust at all, but if I'm making a vibe coded cli I'm picking rust or golang. Not zig because coding agents can't handle the breaking changes. What better test of agentic coders' conviction in their belief in AI than to vibe a language they can't read.

If this is a skill issue, feel free to let me know. In general Claude Code is decent for tooling. Onduty fullstack tooling features that used to sit ignored in the on-caller ticket queue for months can now be easily built in 20 minutes with unit tests and integration tests. The code quality isn't always the best (although what's good code for humans may not be good code for agents) but that's another specific and directed prompt away to refactor.

However, I can't seem to get Opus 4.6 to wire up proper infrastructure. This is especially so if OSS forks are used. It trips up on arguments from the fork source, invents args that don't exist in either, and has a habit of tearing down entire clusters just to fix a Helm chart for "testing purposes". I've tried modifying the CLAUDE.md and SPEC.md with specific instructions on how to do things but it just goes off on a tangent and starts to negotiate on the specs. "I know you asked for help with figuring out the CNI configurations across 2 clusters but it's too complex. Can we just do single cluster?" The entire repository gets littered with random MD files everywhere for directory specific memories, context, action plans, deprecated action plans, pre-compaction memories etc. I don't quite know which to prune either. It has taken most of the fun out of software engineering and I'm now just an Obsidian janitor for what I can best describe as a "clueless junior engineer that never learns". When the auto compaction kicks in it's like an episode of 50 first dates.

Right now this is where I assume is the limitation because the literature for real-world infrastructure requiring large contexts and integration is very limited. If anyone has any idea if Claude Opus is suitable for such tasks, do give some suggestions.

Thanks HN folks for all the comments. To clarify a bit, the cables are pulled through PVC conduits under the flooring before being buried in cement. Currently the hypotheses for why the cable disintegrated so quickly is hydrolysis and paint solvents. Singapore is extremely humid but this doesn't explain why the exposed cabling on the other end is still healthy and not crumbly.

The second possibility is that I keep the leftover wall paints (Nippon Paint Vinilex 5000) in the same room and have noticed that much of the solvents have evaporated. It is possible that the solvents in the air might have caused the cable to fail in 3 years. It would explain why the other ends that aren't exposed to the air inside the bomb shelter aren't falling apart.

Some other learnings from this. Buried cabling should always be permanently fixed and attached to a patch panel instead of dangling in the open. That was the original plan but I figured it wouldn’t be an issue. I was wrong. Always measure exact length of buried fibre cabling as they aren’t meant to be stored in loops.

Should be solvent based.

Thanks, I really appreciate the SMEs commenting here. I'm learning a lot.

Definitely learnt it the hard way this time. You're right that buried cables should be exact in length and fastened to a patch panel. I'll probably look into better conduit design as well for the next time (in 15 years?). Having shared conduits means I would risk damaging other cables if I tried to pull a new cable through.