you know what is the hard part about local ai? Supporting it cross platform. The OP get it easy by playing in Apple ecosystem but when you need to support local AI to both iOS/Android the approach is completely different. Even get the users to download the smallest models can be a challenge
ADK is a nice framework but it's still stuck in the agent as atomic chatbot that goes out and does stuff model. The reality is you want your agents to all be running within an orchestrator service because it's much more efficient in pretty much every way. The way you separate concerns here is to have the agent emit intents, and have those intents go to a queue to be acted upon safely and securely by executors. This system is more secure, performant and observable than the ADK setup.
You want to use multiple providers, so if I am not happy with result from gpt, I can switch to perplexity or something else. The power of plug and play is very powerful when you are building agent/subagent systems
Each LLM provider already has search built in that you can turn on.
Claude, Gemini, Grok and GPT all of them have this. I get your point about being able to plug and play but all these providers come with the functionality built in.
Opening the essay with ~~Learning how to use LLMs in a coding workflow is trivial.~~ and closing with suggestion ~~ Copilot ~~ for AI agent is the worst take of LLM coding I ever saw
I guess it could still be considered the same one, just the continuation of it. I was kind of expecting a ground invasion after such havoc in communications has been wrecked. I guess if the "electronic" attack is still going on, maybe something else will still proceed...
But the point of the argument was that Hezbollah would immediately never trust their electronic devices going forward until they could secure their supply chain. The argument didn’t depend on the semantics between same and distinct attacks.
One can argue that there is some temporary remaining vulnerability for Hezbollah members who either didn’t hear about the first attack or had some insanely urgent need to communicate (and this vulnerability wouldn’t exist once they secure the supply chain). But I think the much simpler story is that these attacks aren’t possible only once; supply chain security is a continuum, and people will continue to balance risk of repeat attacks against the costs of security.
That's got to be a reason why the attacks are staggered.
Separating them definitely increased the chances that somebody would check their radios - but taking out the pagers drove people to the radios. Now taking out the radios is making people worry what else might be compromised. Your enemy refusing to use their communication equipment is a definite win.
The pagers and radios were supposedly due to the worry that the phone system was compromised - but I'm guessing more people will be using it tomorrow.
I mean, it has been only one day after the last attack. It's still part of the same attack plan IMO.
I really doubt Israel can pull this off again next month or year. Hezbollah (and Lebanon) will switch all their electronics to Chinese supply chain or something, and double check it.
Working with GraphQL over 6 years, I have seen (and created) many mistakes mentioned in the article. GraphQL is not great but it has worked well for me, you just need to adapt & change mindset to create better interface for your graphQL endpoint.
For example, having nested queries more than 2 levels is a no go for me (just like having nested inheritance is basically anti pattern)
Focus more on your interface. One way to avoid N+1 and nested query is to required parameter for related fields. For example
I have had to implement a large REST API recently and feel like I spent a lot of time setting up things manually that GraphQL provides out of box. REST tooling has gotten better but so far I have not seen anything as convenient as Apollo, for example.
reply