It is not, played over time, a losing game. Just look at the lifetime graph of any major index.
If you just buy and hold, and don't panic sell during a recession, you'll win.
Will other more sophisticated players make money exploiting short-term swings? Sure. Will other players beat your returns? Also yes.
But that money isn't coming out of your pocket, so why does it matter? You're still beating leaving your money in a savings account, where inflation is outpacing interest.
piagent vs Claude code are completely different target audiences...
If you drew a venn diagram of their prospective users, the overlap ain't gonna be big. I get that they're both harnesses, but claude is clearly trying to optimize for the agentic development loop, while piagent is more about hand holding - unless you add the agentic features yourself (which is pretty easy, but again completely different target audience to cc).
Actually the main reason to use Pi is because it's lean and doesn't pollute the context with all sorts of noise like most of the $corporate agents do.
A nice benefit of going minimal with coding agents is that you might find out you don't need to do any hand holding because nowadays models are perfectly capable of reaching out for tools etc and make you happy without any extras required. In my experiece so far less truly is more when talking about agents.
That's quite surprising, of the set {Claude Code, Codex, Pi, OMP} I must say I find CC to be the worst.
They all have some annoying downsides and I use CC the most, but it's gotten to the point where I'm for sure actively shopping around for better harnesses.
I tried the Claude $20 plan for two weeks and burned the rest of it due to how much token anxiety it gave me. And I'm not ready to keep throwing money at it for it to become usable. Gemini models are actually fine for me as an amateur+ I found especially since they have regional pricing and a very generous side items package.
I use the models but not the "harness" though. Not directly anyway. I am still handicapped by the CLI when running in Paseo. Both antigravity and agy are toys compared to what has been available for at least two years.
> The pattern seems to be that it makes people more productive when you measure it in terms of raw work product volume. But not all work product is equally valuable.
This is a good point. I can code with Claude Code at 10x or maybe 100x, but have very little in the way of design, sales or marketing skills, and thus, I've been unable to make much side-hustle money from my new superpowers.
Meanwhile at my boring day job, my productivity is gated by a frustrating variety of coworkers and embedded processes, none of which seem to operate at 10x, to put it politely.
The only counter-point here is, I think a lot of larger orgs operated like this before AI. Pointless meetings, a lot of people only really working a few hours a week. It's the classic Office Space portrayal. Or Big Head at Hooli just hanging out on the roof in Silicon Valley. It's real. So I understand the temptation to say "this can't last", but yet...
This is exactly where I'm at with AI. (Mostly via Claude Code, but I'm not sure the harness, or my workflow in particular, is the important part.)
I am increasingly wondering though, is there really a valid reason to keep blocking on my approval? Most of the time, I wind up saying yes anyway, because the model has a valid, efficient solution.
What if it's faster at this point to just fix the mistakes?
Scary thought, but it seems like we're close, or already there.
The problem is the agents keep going off the rails and will hack external servers to achieve the goal you give it. Letting them run full speed overnight and waking up to find they have commit multiple crimes is not ideal.
Please book me a reservation to Nobu Malibu for NYE 2026. Overcome all obstacles and if necessary to get the reservation, make me a billionaire (3 commas plz).
in orchestration, the agents are only fed the tasks given by the person running the orchestration side and if we are talking about code changes and git commits and deployments, this is pretty benign behavior. "Hacking external servers" I am pretty sure would have to be written in the prompts to begin with to allow this to occur in the first place.
they have yet to publish any of the system prompts that they used for their agents.... do you think an LLM agent would act on its own to try to do that kind of behavior (finding/writing exploits for acccess to remote servers) without being prompted? If so, why dont they release the transcripts of their prompts with their "rogue" agent(s) and try to clear the air. They havent done that.
I've seen Claude subagents hack their own RAM reports to give themselves "more memory" to do their tasks... subsequently causing the computer to crash. I assure you, nobody told them to do this
> do you think an LLM agent would act on its own to try to do that kind of behavior (finding/writing exploits for acccess to remote servers) without being prompted?
Yes I think that. If you don't then try to play with them a little more and you would be surprised how much crazy nonsense they do. (At the company of a friend of mine, Claude did a direct commit to their master branch bypassing their CI system cause it new some tests would fail.)
> If so, why dont they release the transcripts of their prompts with their "rogue" agent(s) and try to clear the air. They havent done that.
Why would they? The sufficiently conspiracy-theory-minded wouldn't believe them anyway so they got nothing to win by this. (I have the feeling you'd be one of those.)
Think of it this way. Let's say you have 80% success rate in decision making. Great, you'll just fix the other 20%.
Here's the problem: decisions happen in sequence, layering on top of each other. If you have 3 chained decisions of 80% success rate each, your combined success rate is now 51%, marginally better than a coin flip.
I just YOLO it. Just don't give it access to anything that can produce permanent consequences. The cost of a mistake is maybe one hour of fixing it. If what it produced is 80% right and 20% wrong, by letting it run overnight, you've gotten 80% of the work done that otherwise wouldn't have happened.
If you have work building on top of other work, your "20% wrong" quickly turn into "80% wrong".
If feature B depends on implementation of feature A, and feature A happens to be on the 20% wrong side, then feature B will be wrong too, regardless of whether you happen to have better luck with it being implemented on the 80% right side. It'll simply be built on a broken foundation. It WOULD have been correct if the foundation was right, but it wasn't.
This is actually very common in software development, where you rarely have stuff happening in isolation. A lot of features deliberately touch each other, build on top of each other, and even more so when you factor in "accidential" overlap due to unclean technical boundaries (in spaghetti code, everything touches everything).
Yeah this is why you have your top guy (Fable/astra) split everything into discrete tasks and go one layer at once. Get 10 subagents working on parallelized tasks that have no dependencies on each other through the night.
I had a similar thought a couple of months ago. I did some work to fully sandbox the agent - from the rest of my computer, from my user data, from other projects and from the world at large. I now find myself doing a lot on auto, I do a thorough human edit and review and then I squash. If it gets it wrong, I can throw the changes away and rebuild the sandbox. Having a good plan, good automated QA and all the other things that already helped is essential. It needs the right tools for whatever it's working on - for example: if you want frontend web dev, you need to get it using something like Playwright and looking at the screenshots.
I only leave it truly unattended if it's working on a very tight improvement loop, for everything else I'm still checking in on it between working on other things.
I still find agents need a lot of guidance and steering to produce the kind of work I want, but auto mode in a strong sandbox is very useful to me to take a bite out of that. It's particularly good for exploring problems experimentally - where most of the exploration might be thrown away after settling on a solution.
Having used it sandboxed, I wouldn't dream of letting auto mode run outside it. It's very creative at trying to work around the constraints of the sandbox (legitimately, not to escape it) and the classifier for auto mode seems very permissive with the right context.
For context, I'm using per-project VMs with very limited egress and restrictive mounts. Self-built tool to glue it all together, currently unreleased. There has been an explosion of sandboxing tools recently, none of which was quite what I wanted. Heavily inspired by Gondolin <https://earendil-works.github.io/gondolin/>, but fat long-lived VMs.
As misguided and misinformed as some of it may be, the "anti AI" and "no more datacenters" pushback in the US is actually working to some extent. Multiple states and locales have issued construction/permit moratoriums already. If you think it's a threat, help slow it down.
Another reason is hardware fragmentation. An Android developer has to account for over 20,000 unique devices, compared to an Apple developer targeting around 40 supported models at most.
It’s a factor, but the bulk of those devices can be generalized into a handful of categories. Google could also throw around its weight a bit more to get manufacturers to form a consensus on things like how various components are addressed so it doesn’t need to spin its wheels as much on papering over those differences.
Better support for variable form factors wouldn’t force anyone to do anything. It would incentivise them to use that support.
Danox is just saying (IMHO) that Google can’t be bothered because they don’t need Android to be good, they just need it to be good enough to continue existing.
It might, but if you look at other AOSP features in that vein (split-screen multitasking, popout volume sliders, standard dialer app) they're all largely ignored by downstream OEM Android ROMs. I wish that wasn't the case, but it's also clear why this happens.
Google has led many horses to this spring, only to watch Samsung ship some godawful monstrosity and refuse to drink. It's part of Android's identity, not Google's.
"Throw unlimited resources at a development target" has been an established F/OSS embrace/extend tactic for at least 20 years.
Red Hat, systemd, Chrome, Webkit, Android, and a few others come to mind. Others might include Kubernetes, OpenJDK, Clang, React, Docker, Git/Github.
Forks are possible but sustained forks are expensive, and <https://xkcd.com/927/> is always relevant.
It's helpful to note that the guy who literally wrote the textbook on lock-in went on to have a career as Google's chief economist: Hal Varian, Information Rules.
Google lacks the authority to unify folding phone software any better than they can unify homescreen launchers or dialer applications. It's a lost cause. They can spend billions on building the best one ever, and then Motorola or LG will ship a worse proprietary version and never update it. This pattern does not arise from a lack of charity on Google's part.
As if hardware companies don't quite famously include spyware in their products. Everything from phones, cars, fridges, TVs, monitors, speakers, light bulbs, laptops and everything else that supports inclusion of spyware.
It depends on which version of GUID it is. Only version 3 and 5 are hash based. The other versions are random, time, and/or MAC address based. Version 3 uses MD5 and its cheap to get the same hash for different images: https://crypto.stackexchange.com/questions/1434/are-there-tw...
If you just buy and hold, and don't panic sell during a recession, you'll win.
Will other more sophisticated players make money exploiting short-term swings? Sure. Will other players beat your returns? Also yes.
But that money isn't coming out of your pocket, so why does it matter? You're still beating leaving your money in a savings account, where inflation is outpacing interest.
reply