kkapelon

While I understand where you are coming from, I think some of those are subjective.

I personally prefer articles that link to other(better) sources for definining concepts instead of trying to explain everything.

So several times I read articles like a stack, starging with A, then in the middle going to B and after finishing B going back to A. It doesn't bother me at all. It actually says to me that the author understands they cannot be experts on everything and recognize other articles.

I also enjoy articles with reveal their twist late if they are not super long.

On my personal blog I am actually writing both styles (just explain right away, or build up to something that will become clear later in the article)

Cyclomatic (and cognitive complexity) are a good start.

Some other ideas

1) Enforce architecture decisions (see archunit). But somebody needs to write them down first.

2) Check that tests actually break if the code that accompanies them is removed (several LLMs/agents today create tests that don't actually test the code they "guard against)

3) Automated performance testing. An LLM/agent might create a change that is "correct" but increases latency for 3x (best case) and 20x (worst case)

The hardest part that I see no solution for today is to understand when a change breaks backwards compatibility. LLMs/agents are trigger-happy and will happily refactor/remove stuff without any care about who is using that.I don't have a proposal for that, but the problem is there and is not covered by 12-factor config.

Duplication was just an example. Code architecture is the general topic.

Yes a plugin system is great, but it only works if that plugin API/interface it designed correctly and gives plugins what they need while still enforcing good practices.

But somebody needs to design a plugin system that does this first. And designing a plugin system (for large projects) brings us back to square 1 :-) (that you need a large enough context to see what the code does in order to anticipate plugin needs).

Sure. But in order to do central refactoring and actually improve stuff you need to keep in context all the small pieces.

You can split a small program into piece A, B, C All of them look correct on their own. But they duplicate something in 3 different ways and person/agent who can "see" all of them can see the duplication and refactor.

Current model context is simply not enough for large projects.

Same problem for letting AI review code. A PR might look correct on its own and be small enough to fit into context. But somebody who has access to the whole code of the project again sees the duplication.

I am an OSS developer and when reviewing PRs I actually look at how the same problem was solved in other popular OSS projects. No AI can check this today because there is simply not enough context.

Basically if we had unlimited context what you said might be true. But context size is limited today.

I don't see context size improving.

It was mostly 256k, then it went to 1M and now it has stalled there.

> You should absolutely be setting criteria that can be objectively measured and rejecting code that doesn’t meet those criteria or perform as specified

This is the classic "make no mistakes".

On a serious note, I might set as criteria "avoid code duplication". Does that mean that the model/agent will actually follow it?

> What does that accomplish, other than to slow your dev process down enormously?

I am an OSS developer and I often see PRs (i.e. from the general public) that look correct, pass all CI checks, are heavily documented and they are still wrong.

Most of the times either they duplicate code that already exists somewhere else, or they implement a "feature" by opening a can of worms for subsequent "features" in the same area.

> You can still read the code, ask the AI questions about it, and ask it to fix things

This only works in small projects. For large projects, it is close to impossible. Everybody talks about how new models appear all the time and nobody comments on the fact that context size has almost stalled.

12 factor is good but it is a very low bar.

It is perfectly possible to vibe-code a badly designed app that still passes those 12, 15 or whatever points you define.

It is a warning to developers who don't understand the trade-offs involved.

Also a confirmation to people who have the same inner thoughts and are ashamed to admit in public that they think the exact same thing.

I think we need such kind of posts to combat the influx of AI news.

People who want a VR system that runs Linux

You can buy a pocket sized steam deck and do it yourself https://armadaos.dev/

Or use gamenative on your phone

You could already do that with gamenative. There are many videos.

Also you can run steam os on arm portables. https://armadaos.dev/

So all this was possible before the Steam frame was launched

Xreal or Viture

Either testing for something bigger OR demonstrating their power to a 3rd party with minimal real disruption

I am also using termux and moshi and at least with moshi everything works out of the box. Where does it get clunky? What functionality is missing?

How many other products can you name that:

1) are terminal based (not gui apps that you need to install)

2) Can be run by mosh/ssh

3) Track agent sessions automatically

4) Have built-in git worktree management

5) Show agents connections over different machines (the new feature mentioned in the blog post)?

> Their connectivity product is unique

There is also netbird, netmaker, zerotier and several others.

source?link?

You are lucky that you got valid PRs that actually fix something.

I got PRs that either never worked or even broke stuff

https://blog.codepipes.com/llms/your-pr-was-rejected.html

Strictly from personal opinion

1) Built-in sub agents assume you use a single AI agent. Some people use multiple, so they need separate terminals/processes by definition. Even if you use the same agent sometimes you have different security boundaries. Think also the needs for a consultant working with many customers at once.

2)Multiple-open terminals. When that number passes 5-7 for me, then yes I don't like clicking on each one of those manually to see where my attention is needed. Herdr (and similar tools) show exactly what is working and what stalled.

3) No I use herdr locally mostly right now. But since it is just ssh I like the fact that you can run it from anywhere. I haven't done it yet, but I imagine you could open a herdr session from a steamdeck to a remote server to debug somthing

Another thing I like on herdr is easy work trees. Sure you can do it manually with git commands, or ask the agent itself to use a new worktree, but just having workrees with a single click and a visual tree/children hierarchy was the killer feature for making me look at herdr at the first place.

Yes technically you can do the same thing with just many terminals and custom scripts. But it is the same question of why Dropbox sells when you could do the same thing with cvs/ftp :-)

Not sure I understand your question. You literally asked, "WHAT is it that makes herdr et al so popular"?

Why? Because it has more/better features. Or you mean something else?

Specifically against cmux, it is not Macosonly. So you can run it directly on a linux server and then ssh/mosh from anywhere.

Simplest setup would be just plain ssh/mosh. Nothing more exotic.

I have seen moshi.app but haven't tested it yet.

I am not familiar with all the tools you listed so please correct me if i am wrong, but all these will catch stuff that LLMs can potentially catch as well (if configured correctly).

They will not handle any architectural problems (i.e. this method is correct but doesn't belong on this package, or this method is called isX - but has side effects).

And I am pretty sure that none of them do what I am saying with the tests. i.e. run tests without the associated code change and see them fail. I am also pretty certain that none of them will understand problems with breaking backward compatibility (i.e., a fix that is correct that breaks the setup of all existing users).

In other words, it is possible today to create a PR that passes all checks, all security scans, all analysis tools, all test suite while still being wrong due to architecture, backwards compatibilty, wrong scope etc. So even before and even after LLMs a human is needed there.

PRs might become unhelpful as you say if in the future one of the two things we happen

1) LLMs have unlimited context so you can pass all source code plus all architectural designs them 2) We have a super smart analysis tool that is one level above what we have today (including llms)

We are not there yet.

> Once you do all that the PR process is pointless

manual PR reviews can catch things that llms currently miss. Examples are duplicated code, lack of unit tests or introducing security issues. None of these really break the build. So just requiring "do not break the build" is a very low barrier.

Tests also are useless unless you have a smart system that runs the new test WITHOUT the changes and see it break. Most teams I see today have the LLM write a test along with the change, without a guarantee that the tests actually guard the feature.

tmux and zellij are compared here https://herdr.dev/compare/

There is a whole page just on this subject https://herdr.dev/compare/

There is a whole page about this https://herdr.dev/compare/

For me the killer feature is the git worktree management.

But in essence it is tmux on steroid (Specifically for agents)

You missed the most important one. Automatic git worktree management. So that different agents don't clash with each other.