The Macbook neo has a Phone chip. And Android now integrates the Linux terminal (well, for compatible chips).
Valve is also trying to put gaming on ARM chips.
So I'd say we're starting to blur the lines between phones and PCs. Personally, owning a samsung phone, I'm looking for a neat option to leverage my powerful chip and work on it on trips, but so far I find the options to do so too expensive considering how much money I already put into my phone (VR glasses, Lapdocks, external monitor/keyboard...)
I did that a few times with a 10 inches Samsung tablet and a Bluetooth keyboard, using the DeX UI. It had Linux on DeX with some Ubuntu version. 16.04?
I can't think about a good way to do it with a phone screen, unless you know that you can find a TV set to connect to. But hotel rooms usually place their TV sets very inconveniently and if you stay at a friend's home, their TV sets will be not so well placed too to be used as a monitor. So maybe a costly large foldable as your next phone?
There have been a few posts from people who have used these XREAL or other AR glasses with an Android and foldable keyboard.
Also, IIRC there was reporting that Apple considered doing the compute for Vision Pro on a device at the hip. Instead of what they ended up with which was just a battery.
I could see this coming back around again where a future iPhone is all of the brains or a lot of the brains for AR glasses.
I have agents that have been running nonstop for several days working through tasks. At some point I have to go to sleep, and wake up to more progress.
Even with preplanning and post hoc analysis thrown in, I am seeing way more than 2x return on my investment. Where are your numbers coming from?
I wonder how that progress is being measured. Lines of code or counts of PRs? Sure... but I thought the matter of measuring productivity by lines of code was already well-understood as being misguided.
I'm having trouble reconciling all that supposed productivity with the real world where software isn't getting better, delivered faster, or becoming cheaper - unlike virtually all breakthroughs in industrialization (printing press, weaving loom, etc) which led to a quick increase in at least one of such factors.
I'm not denying that AI helps with and excels at parts of the software development lifecycle, but from my experience those parts overall contribute to a small increase in output or merely shift the work elsewhere (where it may just not be part of whatever measurement is being used).
I measure adherence to preestablished acceptance criteria, the same as I've done before while either coding myself or managing other engineers.
It sucks, but you don't usually have the time to pour over code when you manage multiple engineers either, so you have to learn how to do thorough but targeted reviews, minimize distraction, maximize efficiency, etc. A lot of these skills transfer over to managing agents.
We've only had truly decent agents capable of running long-horizon tasks for less than a year, I think it's worth calibrating around that: it's too soon to expect the entire industry to visibly shift.
That said, every senior engineer I know has gone all-in on agentic development, and juniors I mentor are getting a lot done as well.
With juniors it's important to make them understand that these models can't be blindly trusted and the output needs to constantly be critically evaluated.
But engineers who know exactly what they are doing have really been able to make some awesome things this year. I'm also working on a few really cool things, more than before, more ambitious as well, without sacrificing quality or craftsmanship.
I can also seem where some trends are headed. The breadth of software available to both harm and help you is going to explode, and computing is going to look a lot different soon. I'm already building targeted health apps for myself, bespoke personal apps and tooling, development tools, I'm working on games, libraries, various kinds of research, you name it. It feels like an intellectual Renaissance, and within a decade I expect things to look a lot different even if models stopped improving today.
You do have to work differently with these models. Your code evolves in a different way, and testing habits have to adapt. Clients are going to accept less stable but more ambitious demos. Prototyping and research have suddenly become very cheap. We're going to see the effects of the spread through STEM and the arts.
I was talking more about end-to-end feature/product development process from the perspective of the business, and not merely the "writing code" part. Things like figuring out what to build, what code to write (which remains - just that now you are writing a prompt instead of writing the code directly), design, customer support, regulatory compliance/etc.
From this perspective I believe that even if AI does actually automate away software development, we will find out that on average it was never actually the bottleneck nor a significant cost of the product lifecycle. Thus I'm not in a hurry to go all-in on AI just because I don't see old-school human-powered SW dev at being the bottleneck, at least not on the products/projects I work on (large software products with established customer bases).
In a lot of cases I find that the what to build is the biggest bottleneck - and in fact the relative slowness and occasional pushback (because they have skin in the game - see below) of conventional human-powered SW dev forces the stakeholder to think really well about what they want and gives them time to refine that idea. If I were to give them a hypothetical "SW dev in a minute" magic wand it would result in a lot of ill-defined & incoherent features being thrown at the wall which will quickly overwhelm support, destroy their reputation with customers (or worse, regulators) and become a perpetual maintenance burden slowing down any further development to a standstill (whether human or agentic). So I don't do that for my own sanity, even though that magic wand already exists and it's called Claude Code.
This is not to say I find AI completely useless - I see plenty of opportunities for AI to help out with non-product-related tasks - housekeeping that doesn't introduce/change any functionality and would normally rot in the backlog forever are good candidates, assuming I have good end-to-end tests and a full isolated environment where the agent can drive the whole product to QA its own work as to not create additional review burden (otherwise, I would have to review and QA it myself which is often as much effort as just doing the work myself).
> you don't usually have the time to pour over code when you manage multiple engineers either
One thing that I get with humans but not agents is skin in the game and self-preservation. A human writing code will write in such a way as to minimize future work to himself next time there's an outage, support ticket or likely change request and 2) will retain memory of what he wrote so that he will be able to address that support ticket or outage much quicker than a human having to effectively reverse-engineer the code to figure it out. From that perspective, agentic development didn't save time, it merely shifted it from the development phase to when the first support ticket or problem arises (the former can be scheduled and budgeted in, the latter is worse as it arises at unexpected times, derailing whatever else is happening).
(this obviously only works in environments where engineers are encouraged to own things end-to-end. I know some places treat their human engineers as a dumb one-shot ticket->code translator and discourage thinking or taking responsibility beyond that. These are the same places that wonder why they're not able to make any progress because they're stuck endlessly fire-fighting the crap such a degenerate process produces)
> With juniors [...] output needs to constantly be critically evaluated
This raises a scary catch-22. How are the juniors meant to evaluate the output without the expertise they'd only gain by being "in the trenches" for 10+ years? LLMs only help to a point - as they can be convinced of anything depending on prompting or persuasion (I've had Claude adamantly claim things that were wrong which I only picked up on because of actual experience. Similarly, I can easily steer it off the correct path with just a couple suggestions).
The problem of upskilling engineers is not new - billions have been thrown at the problem in the form of bootcamps/etc and yet there's still no good replacement for actual experience doing things and getting burnt in the process. I'm worried that deference to AI will mean a sea of perpetual juniors (but with senior responsibility and blast radius) and the jobs market for actually skilled & experienced talent drying up even more.
> bespoke personal apps and tooling, development tools, I'm working on games, libraries, various kinds of research, you name it.
Absolutely, same here. But building goodies for yourself is different from building them for paying customers. The latter brings a certain expectation of stability and support. In fact this is why even pre-LLM, there is a huge gap between being able to program and being able to launch a product, and why many programmers' pet projects never made it to the latter.
> Clients are going to accept less stable but more ambitious demos.
Demos? Sure. But generally speaking they're paying you for the actual implementation and subsequent support and maintenance of it. Salespeople being able to bang out a demo with a few prompts without engineering involvement could also mean more cases of them selling an impossible feature (that human-powered engineering could've warned them about).
Wouldn't it need a super critical exploit, I mean zero-day vulnerability, to escape from that kind of sandbox ? And if you think further, then isn't that risk also applicable to pretty much any kind of sandboxing ?
Container escapes are more common than you think. Common enough for AWS not to rely on containers for their serverless functions, common enough for Google to say: "Untrusted code shouldn't rely on the container security boundary [..]" [1]
The same is not applicable for any kind of sandboxing for two reasons:
1. The boundary is in the kernal’s own code, enforced by the thing you are trying to be protected from. -> Use a VM
2. The kernal is a gigantic attack surface -> Use gVisor
AUR isn't a traditional repository but more functions like a paste bin for package build scripts you have to go out of your way to enable and use at your own risk. It is not how actual Linux repositories work which are way more safe than google or even apple app store.
> way more safe than google or even apple app store.
Probably because of how people submit directly to the commercial app stores and the app store staff are expected to accept them as long as no malware or other problems are detected. Such problems are generally explicitly listed on Terms of Service and app submitters may be able to dispute rejections. Meaning problems generally need to be concrete and justifiable. Also, because of the sheer number, problems are likely scanned for, rather than each app being personally considered by a developer.
FOSS distro package repo maintainers generally don't have any such pressures. They get their absolute pick of what to include from the wild, only taking as much as they're able to handle.
Also, distro repo maintainers handle the building from the source code themselves, while app store apps are closed source to the app stores. Their ability to inspect apps is very limited.
If something bothers me with my phone's UI or if I want to change the behavior of some system service, I can do e.g. "apt source phosh", patch it and then "apt build-dep .", "dpkg-buildpackage -b" and "apt install" it right on the phone. I can even send the patch for upstreaming from there.
How easy it is to do an equivalent thing on Android?
UI-wise, termux can run Xorg and you can modify the interface you use there. You're right about services. Can't run systemd, but they can just run the service programs in the background (e.g. they can call sshd directly). Regarding modifying programs, maybe not that convenient directly on termux, but if it's rooted, you may be able to run docker and modify them in a debian environment.
The neat thing about non-Android phones with respect to what you mention is that you can do those things just like how you would on any other computer, without having to worry about Android workarounds that may one day stop working via an update.
"interface you use there" - yes, with a strong accent on "there". Sure, you can even run a x86 emulator in a browser and run anything you want there as long as it's performant enough, but that's a very different thing to actually controlling the OS you run - and even if you do happen to be in some control, modifying anything in Android without reflashing the entire thing is still a massive PITA. And of course you're not gonna pass the attestations once you assert the control anymore, so why not just ditch Android completely at that point?
Currently Google is planning to lock down the Android platform to only Google Play store software repository. See https://keepandroidopen.org/ for more info.
people shouldn't have to buy a mac mini to run openclaw, they already have an always-on computer, they just can't install anything computationally useful with it
What extension do you use ? With all the supply chain attacks I am warry of adding extensions, so I wonder if there's like a go-to one that everyone uses
A lot of harnesses compress the context when it becomes massive, Pi doesn't do that out of the box (EDIT: that's wrong, as pointed out below). It can be both good and bad. Also since it doesn't have a lot of tools out of the box, the context is not polluted with external tool call descriptions that the agent has to be aware of.
Basically, it doesn't handle the context "better", it barely does anything special to it, which can actually be better for cost efficiency.
It’s failed every single time I’ve tried, and yes I’ve tried all the auto-compaction extensions :(
So unless it’s been fixed or someone knows a work around, Pi is DOA - I’ve found that on a MULTI tool call (ie one prompt firing off multiple tool calls until it prompts you again) that’s close to hitting the auto-compaction limit (default compactor or extension) it will either keep going until your context spills over and you OOM, or it interrupts itself to compact but then loses the context.
From reading issue after issue on GitHub, I think it’s because Pi doesn’t let extension writers (nor the built-in compactor) hook in between each tool call and so the only place to check if it can compact is when it finishes a request and is about to wait for the next prompt - too late by then
Ok my bad. I remember hearing that it was a criticism of common harnesses and that the creator of Pi wanted more control over that feature, so I assumed it wasn't enabled by default. Thank for pointing it out !
The non-profit makes no profit but it doesn’t mean those involved can’t make profits. An investment in a new jet for the boss is an investment back into the non-profit!
reply