What is a larger scaler for you? What is "outside harness an LLM"?
What is _the proof_ if all the proofs are not _proofs_?
I don't babysit my LLM based services which are used by coaches and clients around the world. One of my LLM based solution get 30-4k daily hits and I have users coming back on the regular to use it. without babysitting, doing things that would take them hours of manual work and research.
I don't babysit the developers I work with and our clients, which both use LLM's themselves and at scale with their clients, serving all kinds of LLM powered services to millions of users worldwide.
You are not "seeing" the large adoption because:
- The technology is "a few years old" in its usable state
- The corporate adoption cycle is slow
- You have to understand the technology to use it in a good way, which most corporate devs and PM's do not
So it will take a bit for the "obvious" adaptation on large scale.
But you won't "know" when the large adoption happens.
Silent inference is growing every day, and that is what real adoption looks like - not an LLM being in your face chatbox, but running in the background, sorting, finding, fixing things, aligning data, figuring out analytics, tuning the ads, cleaning the datasets.
Perry definitely looks interesting, was just looking at getting one of these to include into my framework.
Would love to see more about it, or see more about the actual compiler docs.
While the UI framework part is neat, I prefer not to force everything into TS. Combining it means UI definitions and semantics get mixed into AST, making the unbundling of them a humongous task in itself.
Exactly the reason I built my own with pretty similar native UI semantics which supports Rust, Go, Kotlin and more (https://hypen.space) - would love to integrate Perry with it to compile TS apps directly into the runtime - but while the idea itself is great, looking at the documentation makes it hard to implement, and a lot of parts seem confusing.
Can I just use the compiler without the rest of the framework?
What is the architecture? What are the limits?
After digging through the documentation, I'm unfortunately just more confused honestly. There are dozens of packages and slop markdown files such as `BUG_STRING_COMPARISON.md` and or `PERRY_UI_IMPLEMENTATION.md` which is an instruction file left for the LLM that just makes me trust the project less.
So while the idea is cool and the performance seems cool, the AI slop presentation would definitely need improvement. Adding a human touch would make it much, much better, as one could actually understand what they are dealing with.
They were a great brand, cool phones, one of early Android players.
After being bought out by Google, Motorola had some of the best devices out there with stock android, especially in the budget segment (and loved among android devs).They had one of the best smartwatches in the game at the time - Moto 360 (2014!!).
Then, after dropping the Nexus 6, Google stripped the patents and sold them to Lenovo. For a while it was ok, even dropping the relatively innovative Moto Z which had all the cool "modular" addons, played with it for a bit and seemed cool.
And then, things seemed to start taking a turn for the worse as Lenovo kept enshitiffying it more and more, using the brand name as a wedge in the market in which they are basically forgotten. They have the Razr brand which is cool, but the segment that was their best (budget phones) is now ruined with adware so they can extract every bit of value from it.
Such a sad ending for a company that was so early in the space.
FWIW, the worst thing I can say about the Moto Edge 50 Neo (a midrange phone) from a year ago is that it had "sponsored" apps pre-installed. They could be uninstalled (not just deactivated) the usual way and never came back.
... I was so mad every time Motorola screwed the pooch in this era.
I was a first-gen Moto X user... on Verizon. I didn't get the Lolipop update forever and a day. I was a first-gen Moto Hint owner. We didn't get the wake word update, we got told to buy the Hint 2. And then finally, I was a first-gen Moto 360 owner. We didn't even get Wear OS updates at all. Not WearOS 2, not even WearOS 1.6. Every single first-gen product got immediately dropped for second-gen shit, and we got abandoned.
Interesting, agents seem to always fall in a spectrum between overengineering and underengineering, where they will either go wild and overengineer a simple solution, or do the minimal effective thing to pass with "//TODO fix for prod".
It's the same patterns we see with human devs, just applied on codebases at scale.
The conclusion has an interesting tibid tho - maybe the frameworks and their developers should start including more abstract focused primitives instead of just the low level ones, similar to what Encore did, as that way the behavior is encoded at the framework level.
I'm actually working on that - it's called Hypen - (hypen.space).
You can build your core in Go or any other supported language, and write the UI in the Hypen DSL.
While desktop is still in the works and should be out in the next week or two, currently the alpha supports Native iOS, Android, Web and Web Canvas, and just like mobile, the Desktop will be _real_ native.
I mostly agree with the article - I believe the differentiation should be between documents and applications.
While HTML serves its purpose, especially for documents, the modern web is a giant mess of that legacy, combined with unfriendly ergonomics and glue/hacks built on top just so we as developers can have better DX for creating complex software on top of it.
Building a browser means having to deal with all that legacy, wether we like it or not, so most of the browser market got captured by the big players who have enough manpower to cover all those edge cases. That also means we have to deal with whatever technical choices or bloat they make, causing an infinite stream of issues, from memory usage, to size, to limitations that don't make sense in 2026 but are still there because someone 20 years ago decided to write them like that. As I deal with mobile webviews a lot in my daily work, I unfortunately had to get familiar with quite many gotcha's and edge cases, and some are just... absurd in this day and age.
I believe we need a separation between an application layer and the document layer, and especially between the UI language and the actual application code - script tags serve their purpose, but again, they are a hacky solution with its own bag of tricks, and those tricks impact all of the software built upon it.
Now, a bit of a shameless plug I've been working on something to fill that gap, at least for myself and hopefully for others who encounter the same issue - it's called Hypen (https://hypen.space) and it's a DSL for building apps that work natively on all platforms, with strict separation of code/UI/state, and support for as many languages and platforms as I can maintain, not "just javascript". While currently it's focused on streaming UI, it's built with Rust and WASM at it's core and will soon allow fully "compileable" apps.
While it may not be the future of software, once you get into building something like that, it becomes obvious that the way we are building now is at least wrong, and at best kafkaesque.
Back in the heyday, I used to work in a startup devoted to the cinema world, where with one app you could buy tickets for all cinemas - even those that did not "officially" support it.
Among them were arthouse theaters in Hamburg, which I often used for testing, as most of the time reserving a few seats would not matter as they would be empty, at least during the day. Some of them had projections of old movies, and I was like "if I lived there, I'd go every day".
Ironically, now I live between 2 art cinemas in my city and rarely go to any of them :)
We never left waterfall in the end.
Working with and for dozens, collaborating with probably a hundred software companies in different scales, every single one said:
We do agile
Guess what?
Every single one of them was doing waterfall.
Their agile included preplanning and pre-specifying the full spec and each task, before the project kicked off. We'd have meetings where we'd drill down into tasks, folks would write them down so detailed that there would be no other way than doing that. Agile would be claimed, but the start date, end date, end spec and number of developers was always concrete.
Sometimes, the end date was too late, so a panic would ensue. Most of the time, the date was too late because developers had "unknowns" which then had to be "drilled down and specced so they wouldnt be unknowns". Sometimes, nearly 50% of the workweek was spent on meetings.
A few times, a project was running late - so to make sure we are _really_ doing it agile, we'd have morning standups, evening standups, weekly plannings, retrospectives, and backlog refinement. It would waste the time, and the "unknowns" aka "tickets to refine" were again, as always, dependant upon the PM/PO/CEO's wishes, which wouldn't get crystallized until it was _really last minute_.
One customer wanted us to do a 2 year agile plan on building their product. We had gigantic calls with 20+ people in them, out of which at least half had some kind of "Agile SCRUM Level 3 Black belt Jirajitsu" certificates.
To them, Agile was just a thing you say before you plan things. Agile was just an excuse to deal with project being late by pinning it on Agile. Agile was just a cop out of "PM didn't know what to do here so he didnt write anything down". Agile was a "we are modern and cool" sticker for a company.
And unfortunately, to most of them, agile was just a thing you say for the job, as their minds worked in waterfall mode, their obligations worked in waterfall mode, companies worked in waterfall mode, and if they failed their obligation to the waterfall, their job would go down one.
So while we were doing the Agile ceremonies, prancing around with our Scrum master hats, using the right words to fit into the Agile™ worldview - we were doing waterfall all along.
And after 15 years, I'm not even sure - did agile really ever exist?
Continuous integration and demos to stakeholders (devs, designers, product managers etc) every 2 weeks - these practices are now engrained :-) It's frequent to then do corrections after these demos, and that really helps ensuring the product manager is getting what their customers need.
Easy to forget waterfall in 1970s / 80s really meant teams working on their own for months and then realizing there is no way to assemble the whole product from the parts. Or that the industry has moved on and the product is obsolete.
Agile as "devs can do what they want" never really existed ;-) Managers always have to plan / T-Shirt size resources (time, devs) to some degree. For stuff that's really hard to break into tasks, the magic word is "the plan is to do a POC first".
Coming from someone who also doesn't like teams being asked to break their unknowns into 30 known tasks. It's a compromise... I agree with all your points on how Agile is abused / misunderstood. Yet i believe in the progress from continuous integration and regular demos to stakeholders as a sign we did change something....
Most companies don't do that much of a regular demo to customers anyways - turns out most customers aren't even interested for the first 30-50% of the project, then they become mildly amused, until the final 80% - that's they start getting incredibly interested and opinionated.
> Agile as "devs can do what they want" never really existed ;-)
No real agile ever really exists in the end :)
But it's not devs not doing "what they want" that bothers me - it's the absurdly over-planned project estimates and timelines, with every detail of the project being specced out, not a lot of margin room for errors, invoking the name of "agile principles" as a way to deal with exactly things the PM's don't want to deal with in that moment.
I'd be fine with some degree of planning ahead, or starting with prototypes/PoC's, but such a huge part of the industry just chunks it into "same boat but we'll put agile stickers on the holes", and there is a whole industry of ceremonies around it, that it breaks the "core principles" of agile.
A joke says that its because once you get it, you lose the ability to explain it like a normal person :)
And another joke says the best way to explain a monad tutorial is to write another one, so sorry for this.
Just think of it as a box.
If amazon sent items themselves, it would be hard to pack, no way to standardize, things would break often or fall out of their respective boxes.
Now, if you put it into one of the standardized boxes, that makes things 100x easier. Now you can put these on a conveyor belt, now you can have robots sorting these, now you can use tape to close them, standardization becomes easy as it's not "t-shirt,tennis ball,drill" but just "box box box".
So now you can do all kinds of things because it's all a box. And you can also stress test the box.
It's the same with these.
A. You can just have a function that: calls a something on IO, maps it's values, does a calculation, retries if wrong, stores the result, spits it out.
Or B. you can have functions that calls any function on IO, functions that map any value to any other value, functions that take any other function and if that function fails calls another function or retries, one that stores any value given to it and returns with information if it saved or not etc.
The result is the same in the end, but while 1 makes the workflow be strictly defined only for that case, and now you have to handle every turn and twist manually (did the save save? what if not? write a check, write a test that ensures its not and the check works, same if it does...) the 2 lets you define workflows with pre-tested, pre-built blocks that work with any part of your codebase.
And it makes your life 1000x easier because now you have common components that work with any data type inside your codebase, do things your way always, are 100% tested and make it easier to handle good cases, bad cases, wiring and logistics. And you can build pipelines out of them. Because at the end, what it does is just lets you chain functions that return wrapped values.
And you end up with code like:
val profileData = asAsync { network.userData(userId) }
//returns a Async<Result<UserData, Error>
.withRetries(3) // Works on Async, and returns Result, retries async if fails
.withTraceId(userId) //wrapped flatmap that wraps success into Trace<T> and adds a traceId
.mapTrace(onError = { ErrorMappingProfile }, { user -> Profile(user.name, user.profileId) } // our mapTrace is a flatMap for Trace objects, so it knows how to extract trace objects, call the functions and wrap them again
.store("profile_data") //wrapped mapCatching again for storage explicitly that works on Trace objects, knows how to unwrap them, stores them,
.logInto(ourLogger) // maps trace objects into shared logger
Each of these things would before have to be manually written inside the function, the whole function tested for each edge case. if/else's, try/catch, match/when/switch.
This way, only thing you need to cover with tests now is `network.userData()`, as all other parts are already tested, written and do what they say they do. And you can reuse this everywhere in your projects. Instead of being a function you call with data, it becomes a function you give a box and it returns a box. Then you can give it to any other function that needs a box. If boxes make no sense, think of the little connectors on lego bricks, or pipe connectors in plumbing, or stacking USB adapters or power strips.
I can't stress enough how much this approach helped me in real life cases - refactoring old codebases especially, as once you establish some base primitives, the surface area starts massively collapsing as the test surface area increases.
What is _the proof_ if all the proofs are not _proofs_?
I don't babysit my LLM based services which are used by coaches and clients around the world. One of my LLM based solution get 30-4k daily hits and I have users coming back on the regular to use it. without babysitting, doing things that would take them hours of manual work and research.
I don't babysit the developers I work with and our clients, which both use LLM's themselves and at scale with their clients, serving all kinds of LLM powered services to millions of users worldwide.
You are not "seeing" the large adoption because:
- The technology is "a few years old" in its usable state - The corporate adoption cycle is slow - You have to understand the technology to use it in a good way, which most corporate devs and PM's do not
So it will take a bit for the "obvious" adaptation on large scale.
But you won't "know" when the large adoption happens.
Silent inference is growing every day, and that is what real adoption looks like - not an LLM being in your face chatbox, but running in the background, sorting, finding, fixing things, aligning data, figuring out analytics, tuning the ads, cleaning the datasets.
reply