> I'm hopeful that improvements in LLMs mean we can ditch ORMs (under the guise that they are quicker to write queries and the inbetween mapping code with) and instead make good use of SQL to harness the powers that modern databases provide.
Maybe we can ditch active models like those we see in sqlalchemy, but the typed query builders that come with ORMs are going to become more important, not less. Leveraging the compiler to catch bad queries is a huge win.
I use Ecto with Elixir in my day job, and it has a pretty good query building type solution. BUT: I still regularly come into issues where I have to use a fragment in order to do the specific SQL operation that I want, or I start my app and it turns out it has not caught the issue with my query (relating to my specific MySQL version or whatever). Which unfortunately defeats the purpose.
My experience with something like the latest Claude Code models these days has been that they are pretty good at SQL. I think some combination of LLM review of SQL code with smoke tests would do the trick here.
I think of "plan" mode as a read-only mode where the LLM isn't chomping at the bit to start writing to files. Rather than being excitable and over-active, it is receptive and listening.
If you use it that way fine, but in general I'm talking about the idea that can you plan throughly enough in advance to get it to produce tens of thousands of lines of quality working code.
Like the author of the article points out, that takes so much effort by the time your done you may as well have just written the code.
We should wait for more corroboration before we jump to conclusions about circumstance and attribution. In the Russia/Ukraine conflict, I've seen Russian's use footage and images from other conflicts to claim Ukraine is doing something underhanded.
We've already seen Israel do this over and over again in Gaza. We've seen Zionist media try to lie about it, but if you've been following what Israel has been doing for the past two years, you'll know that this is how they operate.
These days kinetic wars are accompanied by online information wars. What's the harm in waiting for corroboration and more evidence in a rapidly evolving situation?
It's certainly credible that US/Israel bombed a school. But it's also credible that Iran would lie about US/Israel bombing a school. In these situations we need a higher standard of evidence than "credible". I don't think that's a radical position.
I find Iranian government sources far more credible than Zionist sources. Believe what you want, but this was an unprovoked act of aggression following two years of genocide and 75 years of ethnic cleansing. It's crystal clear who is responsible for all of the death and destruction.
> Personally I do agree with the "do nothing" stance, but I don't think it's going to hold up among the wider public. The die is cast and far too many average people are supporting moves like this. So the first defense should be to steer that conversation in a better way instead of stonewalling.
I agree with this, and I find it frustrating how many people refuse to see this. It seems a lot of people would rather be "right" than compromise and keep the world closer to their stated values.
You could use an oblivious pairwise pseudonym, and then you do not require hardware attestation. But that does essentially limit one ID to one account per service.
You are describing a situation where a pairwise pseudonymous identifier is generated. I don't think any real system does this with government IDs, but it might be possible.
They are fundementally different problems. It is already the governments job to maintain a record of their citizens and basic demographic information like age.
Private actors are already offering verification as a paid service. They are accumulating vast troves of private date to offer the service.
reply