this has been my sort of big tent alignment with AI people. If I'm getting good CLI tooling that _actually works_ (or fixes to existing ones that have been busted forever) then I'm pretty happy.
Things that make systems more understandable to the LLMs ... usually make things more understandable for humans as well. Usually.
The biggest issue I've found is that vibed up tooling tends to be pretty bad at having the right kind of "sense" for what makes good CLI UX. So you still have awkward argument structures or naming. Better than nothing though
I've been thinking the same thing lately. It's sorta frustrating that it required bots to force tech companies to make clean simple cli driven development workflows.
> Agents will allow human programmers to get what they've been begging for decades now: proper requirements and flexible, logical, tooling.
...and once this goal is finally reached the programmer will breathe a sigh of relief and then promptly be fired since now the machine can do the job as well as they could.
>Google collects usage data for the Android CLI, such as commands, sub-commands, and flags used. This data does not include custom parameters or identifiable information. This information helps improve the tool and is collected in accordance with Google's Privacy Policy.
> How would Google have enough data about a brand new product without collecting that data?
They wouldn't. But on the other hand, they probably have a large amount of in-house Android app developers on whom they can conduct such metrics collection. I wouldn't expect outsiders to have vastly different workflows, because when you get out of the happy path with Android all you get is pain.
Let's see if even mid/big companies with tons of resources, with AI and the right tooling will continue to write webview-apps or, even worse, use some kind of multi target wrapper.
Everything I do for macOS/iOS is already without Xcode but it's a pain in the ass to keep up with changes, and there are things I haven't figured out yet (like AUv3).
You're forgetting the installation ("sideloading", what everyone else calls installation) restrictions they are about to deploy. It will be a significant hassle to install anything without Google's approval. Many F-droid apps are showing warning notices about this upcoming change.
Agents will allow human programmers to get what they've been begging for decades now: proper requirements and flexible, logical, tooling.
this has been my sort of big tent alignment with AI people. If I'm getting good CLI tooling that _actually works_ (or fixes to existing ones that have been busted forever) then I'm pretty happy.
Things that make systems more understandable to the LLMs ... usually make things more understandable for humans as well. Usually.
The biggest issue I've found is that vibed up tooling tends to be pretty bad at having the right kind of "sense" for what makes good CLI UX. So you still have awkward argument structures or naming. Better than nothing though
I've been thinking the same thing lately. It's sorta frustrating that it required bots to force tech companies to make clean simple cli driven development workflows.
> Agents will allow human programmers to get what they've been begging for decades now: proper requirements and flexible, logical, tooling.
...and once this goal is finally reached the programmer will breathe a sigh of relief and then promptly be fired since now the machine can do the job as well as they could.
The tooling in 2026 is so easy you can do almost anything without AI very very quickly.
>Google collects usage data for the Android CLI, such as commands, sub-commands, and flags used. This data does not include custom parameters or identifiable information. This information helps improve the tool and is collected in accordance with Google's Privacy Policy.
>https://policies.google.com/privacy
>Disable Android CLI metrics collection by using the --no-metrics flag.
No thanks, is there no env variable for this? Doesn't Google have enough data already?
Android CLI can write a tool that wraps android-cli and automatically passes the flag based on an env variable.
How would Google have enough data about a brand new product without collecting that data?
> How would Google have enough data about a brand new product without collecting that data?
They wouldn't. But on the other hand, they probably have a large amount of in-house Android app developers on whom they can conduct such metrics collection. I wouldn't expect outsiders to have vastly different workflows, because when you get out of the happy path with Android all you get is pain.
Let's see if even mid/big companies with tons of resources, with AI and the right tooling will continue to write webview-apps or, even worse, use some kind of multi target wrapper.
I wish the same thing existed for Apple.
Everything I do for macOS/iOS is already without Xcode but it's a pain in the ass to keep up with changes, and there are things I haven't figured out yet (like AUv3).
Flutter CLI is what we really need but this is a welcome addition.
But can I publish an app without having to share my ID? I want an ecosystem that doesn't require it.
Zapstore or Obtanium...
Absolutely not. That would be crazy.
> Your agents perform best when they have a lightweight, programmatic interface to interact with the Android SDK and development environment.
F you google. Me too. Why didn't we get a sane way to build android apps before you had to please chatbots?
Damned if you do. Damned if you dont.
Now please let us install the apps just as easily
downloading an APK and opening it is already about as easy as it gets. the only thing easier would be for someone else to do it for you
You're forgetting the installation ("sideloading", what everyone else calls installation) restrictions they are about to deploy. It will be a significant hassle to install anything without Google's approval. Many F-droid apps are showing warning notices about this upcoming change.