You forgot to mention the part where, to use any of the PWA features, you now have to get the user to close safari, and re-open the page via the icon now on the homescreen. Not exactly easy UI.
No, the fundamental problem is ios. There are a bunch of features that ios locks down so that you are essentially forced to use apps. Want to send push notifications? You need an app. Want to be able to wake your app up in the background to do stuff intermittently? You need an app. Want to get your app on the home screen? Once again, you need an app. And before anyone says you can do this with PWAs, yes, that's true. But the steps required from your users in order to get a PWA running on ios are so cumbersome (by design) that nobody even bothers. And since ios has something like 60% of market share in the US, we're stuck with apps.
If that's a concern, an easy alternative is using companies like novita or fireworks.ai to run open source chinese models. They are incredibly price competitive, have strict data retention policies, and in general are quite fast. Also, you don't get used to a model and suddenly get rug pulled when the provider decide to upgrade.
I mean, that works for you since you're retiring. But for people still working in the industry, you adapt or die. As it's always been.
The fact of the matter is, a person working with a bunch of agents is a lot more productive than just a person. It makes research faster. It makes experimentation faster. It makes output cleaner. And this is true across many disciplines, not just tech.
Also, it is a skill. Yes, anyone can chat with an LLM. But understanding the optimal work flow for what to delegate and what to do yourself is difficult. Understanding the need for precision in the language used, and learning how to elegantly phrase things that were previously just abstract thoughts is absolutely a talent that can be refined.
If i had to guess, I'd say we'll probably see major breakthroughs across multiple disciplines within the next decade, largely because researchers and engineers can cover much more ground individually now, freed from the slow moving coordination mechanisms that team dynamics require. Pretty good for "spicy autocomplete" as you put it.
I use these a lot. My favorite use case is templates, especially ones that were not initially planned in the architecture.
Let's say i have some entity like an "organization" that has data that spans several different tables. I want to use that organization as a "parent" in such a way where i can clone them to create new "child" organizations structured the same way they are. I also want to periodically be able to pull changes from the parent organization down into the child organization.
If the primary keys for all tables involved are UUIDs, I can accomplish this very easily by mapping all IDs in the relevant tables `id => uuid5(id, childOrgId)`. This can be done to all join tables, foreign keys, etc. The end result is a perfect "child" clone of the organization with all data relations still in place. This data can be refreshed from the parent organization any time simply by repeating the process.
While not on the same level as these guys, I've done some similar stuff using Claude. This is a classic synergy example, where the output of human + LLM is far greater than just the human or just the LLM working on a problem. My experience has been that the LLM lacks fine grained judgement when it comes to allocating resources, or choosing a direction to work in. But once a direction is pointed out, it can do a deep exploration of that possibility space. Left alone, it would probably just go off on a tangent. But with someone holding the leash and pointing out areas to explore, it is a very useful partner.
There are two big advantages to using a 3rd party system.
1) There are a lot of cases where aggregated user data, even if anonymized, allows for insights that you can't get using just your own data.
2) The software is really just a stand in for a process. A way of doing something, like record keeping or tax filing, etc. A lot of times it makes sense to follow an already established process rather than creating your own. You are less likely to encounter unexpected pitfalls that way.
I don't see how you can overcome those just by having an AI that can build simple crud apps at will.
So nobody will ever start another successful software project? People will, what, just stop creating software? I understand people's apprehension because of the pace of change, but this is just silly.
I don't know if a bunch of sloppy jQuery modules were ever really a viable option for an SPA. People tried to do it, sure, but I'd say the SPA era really started with backbone.js
It's still the best RDB schema creation/migration tool I know of. It has a crazy number of plugins to handle all sorts of unusual field types and indexing. I usually add django to any project I'm doing that involves an RDB just to handle migrations. As long as you avoid any runtime use of the ORM it's golden.
I kinda consider it a P!=nP type thing. If I need to write a simple function, it will almost always take me more time to implement it than it will to verify if an implementation of it suits my needs. There are exceptions, but overall when coding with LLMs this seems to hold true. Asking the LLM to write the function then checking it's work is a time saver.
Yeah i was wondering about that too. Even small cap PoW chains have dedicated mining hardware that is orders of magnitude faster than a GPU. I guess in theory it could work if you cobbled together enough hacked AWS accounts, but the scale required to make any sort of real profit would be gigantic. It just doesn't seem worthwhile.
Yeah, the brain is a sparse MoE. There is a lot of overlap in the hardware of the "language brain" and the "math brain". That being said, I can discuss software concepts in a foreign language, but struggle with basic arithmetic in anything but English. So while the hardware might be the same, the virtualization layer that sits on top might have some kind of compartmentalization.
I think the fundamental problem is that next.js is trying to do two things at once. It wants to a) Be fast to load for content that is sensitive to load speeds (SEO content, landing pages, social media sharable content, etc). It also wants to support complex client side logic (single page app, navigation, state store, etc). Doing those two things at the same time is really hard. It is also, in my experience, completely unnecessary.
Use minimal html/css with server side rendering (and maybe a CDN/edge computing) for stuff that needs to load fast. Use react/vue/whatever heavy framework for stuff that needs complex functionality. If you keep them separate, it's all very easy. If you combine them, it becomes really difficult to reason about.
When I was first getting into Deep Learning, learning the proof of the universal approximation theorem helped a lot. Once you understand why neural networks are able to approximate functions, it makes everything built on top of them much easier to understand.
I've used NEAT a few for a few different things. The main upside of it is that it requires a lot less hyper-parameter tuning than modern reinforcement learning options. But that's really the only advantage. It really only works on a subset of reinforcement learning tasks (online episodic). Also, it is a very inefficient search of the solution space as compared to modern options like PPO. It also only works on problems with fairly low dimensional inputs/outputs.
That being said, it's elegant and easy to reason about. And it's a nice intro into reinforcement learning. So definitely worth learning.
This criticism is all the more poignant given that it comes from Nabokov. He is one of the few authors for whose works the Russian and English versions are almost equivalent; he was bilingual and did the translation himself.
I guess that's objectively worse since it results in false negatives as opposed to false positives. But personally I think it stings a bit more to get tricked into procedures you don't actually need.
It's genuinely hard to identify dishonest practitioners. I think the best solution might be to convince the insurance companies to pay for second opinions. And then only to pay for the procedure if the two diagnoses agree. But I guess that's a tall ask.