stillpointlab

I guess the question is: did the project you worked on fail? As in, you couldn't achieve the outcome you were trying to achieve? Or at some point did you sneak a look at the code and recoil in revulsion? What was the failure state?

Was this with the latest models (Fable/Opus 5.5 or equivalent) or an older model in a 3rd party harness?

Are you in the camp of: "if at first you don't succeed, never ever try again".

I think that depends on where you work. If your company demands that all code is reviewed then anyone who doesn't do that should be spoken to.

However, I suspect there are teams that are making different choices. In the most obvious example, I can do whatever I want on my personal projects (I hope you agree). And if I started a business and hire in programmers, I have some expectation on defining the culture, making hiring decisions based on my preferences, etc.

Whether or not such teams succeed will be a matter of fact, which I do not believe has been decided at this time.

Because one may learn that those fears are overblown. Or they may learn that they cannot build any kind of software without reviewing every line of code.

The person is saying "I am still unable to stop" and that is most likely because they feel a sense of responsibility. If they choose a project where there is no responsibility, where it literally doesn't matter if the project fails, they may feel able to stop. And if they manage to make that project work, if they can succeed, then they will build up confidence.

It seems better to be able to work both on projects where they review all code as well as projects where they do not review any code. In fact, keeping their job in the long term may (or may not) require having both skills.

I understand the skepticism and I can't claim I am right. But some points come to mind.

First, I think we overestimate how different code is from other code. We even joke about CRUD apps and how cookie-cutter they are. A lot of changes in those apps are: add some new features to a data access layer (SQL, ORM, whatever), add new routes, add new UI surface, etc. There is an entire industry around "Design Patterns" and people live by the DRY axioms. Things like Ruby on Rails exists because rebuilding these systems over and over is wasteful. I feel we are just moving further down that same path.

Second, your question of "why would we want" is totally backwards. Progress doesn't follow your desires. Progress doesn't require justification. Sometimes we adapt the environment to our needs, other times we adapt to a changing environment. Which case we are currently in is still undecided and you are free to fight for the future you prefer. But demanding an industry justify itself before it is allowed to change fails in the face of evolution. If it works, we will justify it in hindsight.

I'm thinking about high volume mass manufacturing as an example here. I like those "How it is made" type YouTube videos. You see a production line that has some kind of QA process where cameras + automated systems do spot checks at high speeds and these crazy actuators are punching out bad examples. These processes often also involve spot checks where some statistical sample is selected and viewed carefully.

I don't think we've gotten to that level of reliable review with code, but I don't see any reason we can't continue moving in that direction.

Issue: I am still unable to stop myself from doing line-by-line code review

Response: Try experimenting in a low stakes environment

From Google: "Exposure therapy is a psychological treatment designed to help people confront their fears, break cycles of avoidance, and reduce anxiety."

It looks like a DeLorean to me. Someone needs to do an AI mashup taking Back to the Future and replacing the car with this.

My advice is to start a totally vibe coded side project. You will never gain confidence until you experiment, find the failure cases, learn to deal with them, etc.

Choose something you want to do but don't really care that much about. Be more ambitious than you think you could be, have a high bar on the outcome but purposefully choose to completely ignore the actual code. Make it write tests, dashboards, monitoring - whatever you need other than code to feel confident.

Now is the cheapest time it will ever be to experiment.

NOTE: This would suggest a surface reading of Brandom's "deontic scorekeeping" might be keeping score of who has what obligations, who is following or breaking rules, etc.

Then the argument against LLMs being party to that is that we don't really assign roles and responsibilities to LLMs, they don't really have "duties" or "obligations" in the way a member of society will have. We don't negotiate with them over who should do what, they don't contribute to the rules that are set for them.

I'm literally just guessing based on the context here though, since the few times I've tried to watch podcasts with Brandom I generally bounce after 15-20 minutes feeling I haven't really understood anything he is saying.

This may not be helpful or strictly accurate, but when I see deontology or variants of that word, I substitute "SHOULD". It is like a duty or obligation.

Super roughly:

* Virtue ethics: character and motivations

* Deontological ethics: rules and obligations

* Consequentialist ethics: utility and outcomes

Perhaps you can also help me understand why #1 being right and #2 being wrong would be some win for alignment that people on X claim it to be?

My impression, being a total outsider, is that the reaction feels like a bunch of insider bros hyping up their insider bro friend. It feels more like PR than a genuine groundswell behind a truly revolutionary idea.

I do wish I could give it a try with some free credits but I would bet Google is wanting to limit usage until they know they can handle the traffic.

I'm starting to feel the subscription fatigue and a small amount of FOMO. I just can't justify pro accounts for every frontier model now that it includes OpenAI, Anthropic, Meta and Google.

I enjoyed this talk very much, although I suspect that the capability work in Scala preceded this new agental AI world and just happens to apply, rather than being formed by it. Like a solution that found its problem.

But his approach seems very pragmatic, not judging whether or not agental development practices are good or bad, but rather considering how we can address the issues they create at the level that he works at: language design. No doubt his work in practically realising these ideas will contribute to the evolution of language and systems design.

A self-hosted cloud offering is very close to what I was thinking of from a commercial offer. It is also the least documented, which makes sense. I'm guessing what I am trying to do is the niche case and most devs will either want to run on their local machine and/or a cloud. Therefore a commercial offering is obviously going to want to support local while providing a low-friction on-ramp to their commercial cloud product.

Thank you for the resource, this kind of aggregation is very useful.

On a quick skim you have categories: Local, vendor-managed, Hybrid. I am looking for something in-between local and vendor-managed. In a sense, I want the separate box to be the sandbox, rather than have a sandbox on my local machine isolated using a container or VM. That is a bit different of a setup with its own constraints that things like VMs or containers don't directly address.

I think spec review, which is definitely valuable, solves a different problem. One question to ask is "are we building the right thing", which a spec review definitely helps to answer.

But another question is "did we build what we planned, and did we build it to a high quality". Code review partially answered that question. Adversarial review is the closest we have to that in the automated LLM world, but I feel we need something better.

I did some investigation into podman since I'm on Fedora and my limited understanding is that it is a bit more lightweight and less tied to the commercial Docker offering. My conclusion was that even that was a bit more than is actually needed. Both Opus 5.5 and Sol 6.1 suggested just to set up a single `agents` user on the box that both use and put things like shared dev credentials into a ~/.config/agents subfolder.

But there are many tiny details to the whole setup. Like, making sure services start at boot instead of login. And adding isolation to dev resources (I mostly use Postgres and Redis) to avoid agents stepping on each other. There's also things like setting up GitHub Apps so that attribution works well. And then there are the "remote control" features of Claude vs. a persistent tmux I can ssh into. I've could go on, but I think most people will get the point.

I'm actually surprised I don't see more discussion about this from devs.

The benchmarks I saw posted to X are impressive, which makes them hard to believe.

I recall that Meta made massive investments into compute infrastructure that put their capacity near the top of all competitors. If all of this is true, it looks like ownership of compute is a significant differentiator in performance.

Tangentially, I've been investigating the last few days on how to setup a separate Linux box as an agent "playground". I got a mac mini to use as my own personal driver and now my Linux box is free, so I want to have a local setup where I keep my personal machine a bit stricter while giving near free-reign for agents on the Linux machine.

It is like a locally-hosted version of these commercial projects. But I'm doing it ad-hoc. This seems like a space that should be filled by open source. What are the options that exist now? I have pro plans for both Codex and Claude Code and enough credits to run a couple instances of each. I want to control them from the mac mini over a tailnet. What options exists now?

As a senior engineer that is struggling to give up line-by-line reviews, I agree with your take.

I've spent literal decades where one of the most valuable practices has been code reviews, for many dimensions. It is one of the best ways to ensure quality production releases. It is one of the best ways to transfer skill to junior engineers. It increases tribal knowledge throughout the engineering org by exposing others to systems they may not be working in. The number of benefits to a traditional human-centric engineering team is hard to overstate.

But I'm starting to feel that instead of starting at one extreme (heavy handed reviews) and moving towards less review, it probably makes more sense to start at the other extreme (no review at all) and move towards a brand new practice tailored for the new agentic reality.

It is looking increasingly likely that we don't need to modify code review for the agentic era, we need some completely new practice that hasn't yet been invented.

> American frontier labs are run by unhinged lunatics who genuinely believe they're creating the Machine God, that they're fine with burning down the world to bring about AGI, and that they believe with religious fervor that they're the only ones smart enough to safely control it

I like hyperbole as much as the next guy. And I'm cynical by nature. But this just seems like a wildly pessimistic view that gives literally zero charity to anyone working at or leading a frontier lab. And the fact the author goes on to say that they "already knew this" just points to confirmation bias.

The rest of the article is actually pretty decent and encourages people to investigate and run open weight models. That is a totally reasonable position that I don't think requires the heavy-handed in-group signal that precedes it.

My understanding is he is not talking about "top users" as being further ahead in skill, he is talking about access.

The kind of FOMO he is triggering is the same kind that wanting to be in an exclusive country club gives a certain kind of businessman. One simply can't reproduce that network outside of the exclusive access, no matter how skilled they are.

One useful part of standup is to elicit connections where one wasn't expected. For example, someone might say "I've been working on X" and another person might say "Oh, I worked on X a couple of days ago and you should know ..."

It is an opportunity for things people didn't realize they needed to communicate to get stated publicly in a way that can create connections neither side would have initiated.

In my update notes I have a warning to always do a btrfs snapshot before a system update. And my system update warns me when kernel changes (since that usually requires new drivers for Nvidia). And to wait after flatpak updates for the driver to finish compiling (since apparently the flatpak installer exits as done before the background akmods compilation finishes)

So, yeah, I feel that pain. So far I've been careful and/or lucky.

I think you are right. Right now I'm on Fedora because I asked the LLM for the most boring and reliable Linux distro for doing development. I'm at the point in my life that I prefer stability to many other attributes - I like boring tech and Fedora is boring.

I'm waiting to see if Omarchy switches to NixOS for their next major release. I have ~100GB of unpartitioned space ready for experimentation and NixOS is the most likely candidate.

My most cynical take: keeping the feel-good image of Anthropic is a temporary ploy to keep fickle SV tech workers building the technology.

When OpenAI started to move obviously towards commercial and governmental ties, a lot of people left. Those people were necessary to build the tech. Many landed at Anthropic, a company that still attracts the most ideologically strict and capable ML researchers.

But at some point of their choosing, the powers that be will just take it.

Same experience here. I've dabbled with Linux Desktop in the past but always backed out once I encountered the rough edges. Just because everything is fixable doesn't mean I want to spend a couple of hours on each of the 100 paper cuts. It adds up over time and feels never-ending.

But now, I just open Claude Code and say "this is bothering me" and it runs in the background while I complete other tasks. I get it to document anything it changes and push my custom configs into a private git repo along with my dot files.

In some sense, I'm starting to see Linux almost like a Smalltalk image. Anything permanent is backed up to git and I have documented recipes to go from fresh-install to custom environment in a couple of hours.

There are still a lot of rough edges all over the place but it is a totally workable environment.

I'm very sad Deno is going away, even though I've never used it nor did I plan to use it.

It is a bit hypocritical in a sense. Similar to how I was sad that a local restaurant recently closed down. In the past two years I went there maybe three times total. But I just liked having it there as an option.

Deno had a ton of good ideas but I just never felt confident that it would have the lasting power. Some of the early decisions, like their initial refusal to fully support package.json and the npm eco-system, made me unsure of their suitability as the basis for a business.

But I always wanted them to succeed. In the same way I always wanted Heroku to succeed even though I never used their service.

More options are better. But I guess "use it or lose it" applies. Did I dodge a bullet or contribute to the downfall?

celld is very interesting and I've been following Dahl's posts on X about it. But it is not related directly to deno. The celld repo [1] for example suggests that it is 78.5% Rust.

It is much more of a side-quest and it doesn't answer the question: where is deno going?

1. https://github.com/denoland/celld

I don't like being the "to be fair ..." guy, but if your argument is that sometimes, when perturbing a system, it may come back to rest at a different equilibrium that is much less desirable, it suggests that sometimes it may come back to rest at a different equilibrium that is much more desirable.

In fact, such a distinction might characterize the difference between pessimism and optimism.