The best one is google ADK, I must say they are quite thoughful of all the use cases

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

Thank you, such a good episode. I adore bluey writing

Copilot is just plain bad. The result is day and night compare with cursor + gemini 2.5 (of course with good prompting)

Copilot can also use Gemini 2.5 and sonnet 3.7.

Actually you can via private API, which Apple app use all the time but forbid other app to use

https://blog.verichains.io/p/technical-analysis-improper-use...

In the other thread, HN said Israel can only pull this trick only once and they just did it the second time

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.

I think you could still expect the ground invasion, possibly the day after tomorrow or early next week.

Tomorrow: "Hezbollah laptops explode across Lebanon, sources say"

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.

the only safe option anymore is the cup and string

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

```

user(id: $userId) { {

  id

  friends {

    id

    ...

  }

```

to

```

user(id: $userId) {

  id

  friends(id: $userId) {

    id

    ...

  }

```

I don't think I understand how that change avoids the N+1 issue. It's still fetching all of that user's friends, no?

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.

I love crypto. I even built an SDK to make crypto payment easy [0] However, KYC is there for a reason. Personally, I don't touch any crypto on/offramp service without proper KYC

[0] https://1pay.network

> However, KYC is there for a reason.

You don't go on to explain that reason though, so let me explain it for anyone reading this.

The definition of KYC from my quick google search is:

"Know Your Customer (KYC) standards are designed to protect financial institutions against fraud, corruption, money laundering and terrorist financing."

Key words: "Protect financial institutions"

In other words, they don't protect the people using the system.

In this case, it is two friends a world apart who want to simply share some funds with each other. There is no institution here other than the use of fiat money on the receiving end (my friends bank account).

I would have preferred to just use crypto the whole way, but my friend doesn't know anything about it and I didn't want to bother them since they were so upset about not being able to be with their family during Tet.

So, I found a middleman that was willing to take my crypto and convert it to local currency, with very little effort or cost. In my eyes, there is absolutely nothing ethically wrong with what I did. Transactions like this do not and should not require government intervention. The fact that we've been so brainwashed to believe that they do, is just wrong.

Should or should not is besides the point. If you're interacting with the US financial system in any way, it's a requirement from that government. I can believe anything I want about how cannabis should be legal, my personal beliefs about that don't change the fact that I could be arrested for having some.

In this case, I am not interacting with the US financial system. I am sending my perfectly legal beanie babies to Vietnam.

Now as a frontend developer I understand how folks complain the frontend landscape change so fast that it is impossible to keep up

At least this is innovation and always moving forward. For the frontend space sometimes it’s step backs, reinventing the wheel, or just because a new tool looks shinier…