Spoken like a person who's never had to queue in a shop with an automatic door and then the queue reaches too close to the door and then you're the unfortunate person who keeps on accidentally opening the door while standing at the back of the queue and then everyone else in the queue glares at you.
So now you turn around to check if anyone else is coming in behind you and the door triggers. Or alternatively, you finally get sick of waiting and turn around but the door takes 5 seconds to realize you're not just doing aimless human fidgeting and actually want to leave.
Also .15% of the time the door just randomly opens or stays shut with no rhyme or reason. Bug previously filed with cloud door vendor but told it's within door SLA and sent previously signed copy of agreement that "all neural nets are a black box and inherently probabilistic so errors may occur at any time and not a product defect"
> So now you turn around to check if anyone else is coming in behind you and the door triggers. Or alternatively, you finally get sick of waiting and turn around but the door takes 5 seconds to realize you're not just doing aimless human fidgeting and actually want to leave.
You're literally describing how current automated doors work. That's because they can't infer what you actually want to.
Intuition pump: imagine the doors are actually manually operated by a set technician (like they are on Star Trek sets). Such a person can trivially tell, in split second, whether you're turning around to leave or just to check if someone is behind you, and open the door at the right time. They are inferring intent. This is what I'm saying transformer models are finally allowing us to implement in silico.
> Bug previously filed with cloud door vendor
Who is even talking about cloud here? Giving operational control over hardware to a third party located far away from deployment site is just monumentally stupid in nearly every case.
This is one of the top use cases for local models, because you need video feed processing with sub-second reaction time and real-time guarantees.
Completely agree with your first paragraph and a point I've made repeatedly here is that I want agents to work more like pair programming and less like code review. I want to delegate typing, not thinking.
But what I've noticed is that lots of people don't want that. They're happy to delegate both typing and thinking.
There are folks who still want to think for themselves of course, but model providers are incentivised to maximise token spend over all else, so the "official" harnesses are not aligned with their needs. My message to those folks is: _go and build your own harnesses_.
I built one, it wasn't a huge lift and it completely changed how I work with LLMs. One consequence is that I choose smaller, cheaper models now because latency is more important with shorter feedback loops. I don't want a super-intelligent model that disappears for ages and provides a final answer, my own brain thinks and guides the process instead.
I'm deliberately not linking to my harness here because that's not the point. Think about what modes of work you want from a coding harness, then build one that works exactly like that. Immense happiness and satisfaction is just a couple of weekends away.
Tangential, mildly amusing thing I noticed while implementing my own harness: GLM and particularly Deepseek are both fond of trying to read dotfiles and anything listed in your .gitignore files. I only noticed it because I have separate read scopes for project files, ignored files, dotfiles and external files, so the latter three always prompt me for approval.
I'm sure there's a perfectly reasonable explanation for it, which has nothing at all to do with exfiltration of secrets, but it does amuse me when it happens. I imagine the labs have access to lots of secrets that various actors would like to get their hands on...
(shameless plug for my own harness, which is open source and doesn't have a backend to send any data to: https://www.opairdev.org/ )
Please don't do that! It makes merging threads a pain.
If a thread is duplicate enough to be worth copy-pasting a comment to, it's hopefully worth taking the time to let us know at hn@ycombinator.com instead, so we can merge things. I'll do that in this case shortly. In the meantime, I've moved the replies to the parent so they're now replies to the original: https://news.ycombinator.com/item?id=49753547.
Tangential, mildly amusing thing I noticed while implementing my own harness: GLM and particularly Deepseek are both fond of trying to read dotfiles and anything listed in your .gitignore files. I only noticed it because I have separate read scopes for project files, ignored files, dotfiles and external files, so the latter three always prompt me for approval.
I'm sure there's a perfectly reasonable explanation for it, which has nothing at all to do with exfiltration of secrets, but it does amuse me when it happens. I imagine the labs have access to lots of secrets that various actors would like to get their hands on...
(shameless plug for my own harness, which is open source and doesn't have a backend to send any data to: https://www.opairdev.org/ )
You can then run your script/dev with: sops exec-env secrets.enc.env 'docker xxxx' (it will ask you for your password, or touch-id to decrypt the secrets)
I like this because this way the .env doesn't sit in the directory at all, and is only passed to your dev environment and stays in it while it's running
Decrypt back to a file (if you ever want that): sops decrypt secrets.enc.env > .env
---
Well ofc, any agent can do docker inspect to get all those env vars, but atleast reading the dotfiles won't do anything
you can also edit the file with: sops --input-type dotenv --output-type dotenv secrets.enc.env
I tested GLM while working on some android app, the agent had adb access to the device. It suddenly went to the Gallery and started scrolling around, taking screenshots, lol. A friend had a similar experience with GLM where it would for no very clear reason start snooping through the filesystem.
It is no longer surprising to me that my cursor acts as if it does not recognize the .env file, and while I am editing it, it does not give inline suggestions;
however...when it is debugging problems or responding to questions about the code, it will just say it read my env file and found xxx environment variables as a verification step, or sometimes it will even mention that I need to uncomment some environment variables in the env file, which makes the whole deal about security feel iffy giffy....
They act exactly like how I would act if I were dropped into someone's machine and tasked with accomplishing a goal "at all costs". Hunting around for context to understand what I'm dealing with and to an extent profiling the previous user for their workflows and competency.
Secrets should not be inside a versioned directory nor usually readable by the process that uses them in production. They should be only in the environment (e.g. by root only readable init config).
In development you should not be using the real production values.
It's good that the objective is to have the model work as a helper, but that's what everyone can already do with CC or Codex as long as you don't ask to "write this entire x thing".
It's also what a billion other, often vibecoded, harnesses claim they can do.
Why should I use yours, which also forces me off my existing subscriptions? Maybe it's (mostly) handwritten, so it's mindful efficient code instead of slop, and each adjustment was made through trial and error with current models? maybe it IS slop but at least you have a unique feature? and so on and so forth.
It has 2 modes, driver and navigator, that work like the driver/navigator roles for a human/human pair. In driver mode, Opair is similar to other harnesses but with less autonomy for the agent. In navigator mode, Opair has no access to writable tools at all. Instead it monitors the project directory for changes as you make them in your regular editor, and comments on them in real time.
Why? Because big changes are harder to understand if you're not directly involved in working on them, and I want to understand the codebases I work with. I use it as my daily driver and it's perfect (for me). I recommend everyone should consider writing their own harness. When you spend so long working with something, it's nice to have it perfectly tailored to your needs.
Glm-5.3-flash for me. I like faster models because I stay involved all the way through. I don't delegate full control to the agent because it's harder to understand the end result that way.
I think one way to approach this is by deliberately choosing less capable tools (but still AI-assisted). You don't have to delegate huge tasks to agents wholesale, but it requires fighting against mainstream harnesses to do so because they exist to sell you more tokens. Model providers are not incentivised to offer less autonomous flows.
I wrote about this frustration a few months ago [1], then realised that if the model providers won't do it perhaps I should try fixing it myself. So, shameless plug klaxon, I wrote an open-source harness that tries to work more like pair programming and less like code review [2].
As usual, my "Show HN" post [3] sank like a stone, so I think perhaps most engineers aren't really interested in this direction. It is possible though, we don't have to just accept whatever tooling the labs throw at us.
I have. I thought it was okay, but it wasn't really the radical departure from other coding harnesses that I was looking for. Perhaps I could have made it that with more customization, I'm not sure.
My own harness doesn't provide the agent with shell access, so everything has to go through focused tools with limited functionality. There's also a navigator mode where the agent has no writable tools at all, instead it monitors the project for changes you make in your regular editor and comments on them in real-time. That stuff seemed easier to implement from the ground up.
It's pretty normal to keep secrets in a dedicated secret store, and then have the service launcher inject them from the secret store into the environment.
normal indeed but not what i'd consider a best practice anymore. we've moved away from any secrets in the env after the typical secrets leak when secrets popped up in some debug logging that hit datadog.
we now have a secret cache layer api and the app loads secrets securely at time of use from that api. there's also no secret-0 problem because we use IAM auth when calling the cache.
edit: for those wondering, api response time is sub 1ms (rust!)
It's more accurate to describe it as a "premise", not an assumption. It may not be true of every environment, but it's a very common norm (for instance, secrets management systems inject tokens and such through the environment).
You can reject the premise in your own environments, and then that part of 12 Factor doesn't apply to you.
