You’re not reviewing your agents’ work anymore. You just haven’t noticed yet.
@addyosmani calls this drift “cognitive surrender.” Here’s how it looks over a month with 5 coding agents running:
Week 1: you read 100% of the diff.
Week 2: 60%. Week 1 went well.
Week 3: 15%. The variable names look reasonable.
Week 4: you read the summary. It says everything went great. It was written by the thing you’re supposed to be checking.
Output: up 4x.
How much of the system you can explain: down 70%.
Dashboards showing that second number: 0.
Now the uncomfortable part: better models make this worse.
Out of 100 outputs, say 97 are right and 3 are wrong. All 100 look identical: same clean formatting, same calm confidence. Next year it’s 99 and 1, and you’ve stopped looking for the 1.
So you have two options. Read every line and ship nothing, or do what takes about 4 minutes per task:
> Write down your guess before you prompt. A bad guess is fine. Once you’ve read a polished answer, you can’t imagine any other one.
> Define “done” up front. Afterwards, you’ll accept whatever you got.
> Read the command and its output before the summary.
> When a check goes green, name one thing it didn’t check.
> Last one and it is crucial - Ask the agent to list the decisions it made for you. There are always more than you’d think.
Those 4 minutes cost you maybe 10% of your speed. In exchange, you get to keep being the person who knows why the thing works.
And that person is about to get very expensive. Anyone can generate the work now. Very few people can look at it and say “this is right, and here’s why” when it’s their name on the line.
Try this today. Open the last thing you shipped with an agent, pick a random line, and explain it out loud.
If you can, you’re delegating.
If you can’t, you’re a guy with a clipboard signing for a box he never opened.
The box has been fine so far.
Built a website with Lovable? Check the information below
7,403 Lovable apps were found with user data open to anyone by default. Nobody hacked them. There was nothing to hack.
Passport numbers. Payment info. 200,000 private chat messages. No login needed.
The attack, if you can call it that, fits in one line of curl.
German security firm Crissy Field went through public web archives and found 159,041 Lovable projects. Here's what the machines actually did.
A normal app has a guy with a clipboard between you and the database. You ask for something, he checks who you are, and he decides whether you get it.
Supabase removes the guy. It puts PostgREST in front of Postgres, which turns every table into a URL. The browser calls that URL directly.
So every Lovable app like this ships two things in its public JavaScript: the project URL and a public key. The older anon key is a signed token whose role claim literally says "anon." That's a fancy way of saying "hello, I'm nobody."
The key being public is fine. It's meant to be. Now anyone can send this:
curl "https://PROJECT(.)supabase(.)co/rest/v1/users?select=*" -H "apikey: PUBLIC_KEY"
PostgREST runs that query as the anon role. Only two things decide what comes back:
1. Grants: is anon allowed to touch this table?
2. Row Level Security: which rows can anon see?
Supabase's public schema grants anon broad privileges by default, so the first check usually passes. Everything rests on the second.
Here's the trap.
The Supabase dashboard turns RLS on for tables made in its Table Editor. Tables made through raw SQL or migrations start with it off. Lovable's agent writes raw SQL migrations.
RLS off plus default grants means nobody can read the whole table. And uniform generated code means predictable table names, so one script works across thousands of apps.
There's a second version that looks safe:
create policy "allow all" on users using (true);
RLS shows as on. The policy says yes to everyone. An agent trying to make an error go away has every reason to write this.
And the app works perfectly either way, because a database with no locks returns data very reliably. The preview looks identical. You ask for a CRM, you get a CRM, and the CRM is also available to the rest of the planet.
The funnel:
159,041 Lovable projects found
34,545 using Supabase as their main database
24,664 loading records without a login, which isn't a problem by itself
7,403 exposing records with email addresses, across 10,560 tables
One provider exposed 1,000+ passport records. One German forum exposed 80,000+ profiles and those 200,000+ private messages. Elsewhere, 280,000 emails sent to a company's customers were readable.
But "30% of Lovable apps leak" is wrong. That 30% is 7,403 out of 24,664. The whole sample is about 0.3% of the 50 million projects Lovable claims, and it isn't random. It also only counts emails, so it misses tables that leak other things.
"Take everything offline" is wrong too. You can check your app in about ten minutes.
Open the Supabase SQL editor and run these.
Step 1. Find tables with RLS off:
select tablename from pg_tables
where schemaname = 'public' and rowsecurity = false;
Step 2. Find policies that let everyone in:
select tablename, policyname from pg_policies
where schemaname = 'public' and qual = 'true';
A few of these can be legitimate, like a public product catalog. A users table isn't.
Step 3. Turn RLS on for each table:
alter table public.messages enable row level security;
With RLS on and no policies, Postgres denies everything. Your app may break here. That's the first honest thing it has told you.
Step 4. Add back only what's needed:
create policy "read own rows" on public.messages
for select to authenticated
using ((select auth.uid()) = user_id);
Write separate policies for insert, update and delete. Default grants aren't just reads, so an open table may also be accepting writes from strangers.
Step 5. Stop future tables from being open by default:
alter default privileges in schema public
revoke all on tables from anon;
Tables anonymous visitors really need then get an explicit grant.
Step 6. Test it like a stranger. Run the curl from earlier against every table. You want an empty array or a permission error. Clicking around your app while logged in proves nothing.
Three more places this hides:
Views can skip RLS. On Postgres 15+, create them with security_invoker = true.
The service_role key bypasses RLS completely. Search your frontend code for it. If it's there, rotate it today.
Storage buckets have their own policies. Passport scans don't care about your table rules.
If real data was exposed, rotate any tokens stored in those tables. If you have EU users, you may also have breach-notification duties, so ask someone qualified.
Lovable told Handelsblatt this is an industry-wide problem. This is annoying, because it's partly true. In September, UpGuard found 16,326 Supabase databases with readable tables, and that count excluded sites carrying Lovable and Replit watermarks.
So whose fault is it? Lovable's own docs have the best answer.
"Missing RLS policies are the most common way app data gets exposed."
Those same docs tell you to verify the rules yourself. The product's pitch is that you don't need to know what any of those words mean.
That's the real bug. Not the database. The gap between "you don't need to know how this works" and "you are responsible for how this works."
The AI will tell you it's fine.
It also told you the app was finished.
‼️ Apps built with the AI app-maker Lovable left passport numbers, payment information and 200,000 chat messages open to anyone, no login needed.
German security firm Crissy Field scanned 159,041 Lovable projects and found databases with email addresses readable on 7,403 sites.
Lovable promises no coding skills are needed. Its terms make customers responsible for their apps and data.
Lovable told German business daily Handelsblatt the problem is industry-wide.
When Google’s threat team, Lookout and iVerify all flag the same iPhone exploit, I pay attention.
It’s called DarkSword. If you open the wrong website on an older iOS, your wallets are gone. You don’t tap anything or download anything. Just loading the page is enough.
My friend's Trust wallet got drained yesterday.
What it goes after:
1 Trust, Coinbase, Binance, Kraken, OKX
2 MetaMask, Phantom, Exodus, Ledger and Trezor apps
3 Your saved passwords
4 Any 12/24-word seed phrase in your Photos or Notes
It runs only in memory, takes your data and leaves, so restarting your phone afterwards does nothing.
This isn’t old news. In October, Censys researchers found servers still attacking iPhones on iOS 26.2 and older.
What I’d do today:
Update iOS: Settings - General - Software Update
Make sure it is IOS 26.3 or above.
Delete any seed phrase screenshots or notes, then empty “Recently Deleted”
Keep seeds on paper or metal only
Put real money in a hardware wallet
Turn on Lockdown Mode if you can’t update
Were you on an older iOS with your seed saved on your phone? Then treat that wallet as compromised. Make a new one and move your funds.
Check your device. Stay safe.
both. entry is JSC (CVE-2025-31277 JIT type confusion, or CVE-2025-43529 DFG GC bug), then a dyld PAC bypass, then a sandbox escape through ANGLE into the GPU process and on to mediaplaybackd, then a separate XNU kernel race (CVE-2025-43520). lockdown mode: GTIG recommends it, but I haven’t seen anyone test it against the chain. it kills JIT, so in theory it breaks the entry, not just delivery
I have it on by default
Only the comment body is a blob.
After filtering each row has structured fields like time, author, parent and deleted/dead flags.
You don’t need mammoth tooling at this scale. Export the BigQuery table to Parquet and query it locally with DuckDB: WHERE regexp_matches(text, ‘youtu.?be’)
43M rows can be processed on a laptop.
Sending all 43 million Hacker News comments to Opus through the API would cost about $22,000.
@karpathy did it for the price of a subscription he was already paying for.
Here's how:
An LLM call means renting a huge pile of matrix multiplications that read your text one token at a time, and the meter runs on every token. So the trick is to show it as little text as possible.
Step one is regex, which is a fancy word for a 1970s search pattern that finds “youtube com” in a string without understanding anything. It reads 43 million comments for free and has no opinions about any of them.
Step two: drop the spam, the duplicates, and anything that isn’t a comment recommending a video. That’s still free, and there’s still no AI involved.
Step three: only what survives goes to Sonnet, the mid-sized model. It runs as a Claude Code workflow, so it comes out of his monthly plan, not a per-token API bill.
He built the whole thing with Opus 5.5 on Medium effort. Medium is his default. So is mine starting today.
Meanwhile the rest of us set every request to Max because it feels safer, then paste in 400 lines of stack trace to ask why a button is blue.
We should not forget about simple programming tools like regex while working on our projects to save tokens, time and money.
Weekend hack: HackerTube. I was annoyed with YouTube's recommendations so I had Claude filter down 43M comments over 20 years of HN to 6,454 videos that keep being recommended. *Significantly* better viewing experience, ~2 hours with Opus 5.5:
https://t.co/JIhXN7OSh1
- Excellent recs without any logins (state is kept in local browser session)
- Thumbnail is a representative frame from middle of the video instead of the super duper A/B test hyper-optimized user uploads
- Underlying data from the comment analysis as one zip file, point your Claude at it and ask for your own version
- HackerTube Longs ✊
A bit more on the process:
I use Claude Code (desktop app for Mac), Opus 5.5 on Medium effort as my default. I only talk to Claude and have it do everything, the only "manual work" I helped with in tandem was in the browser (reminiscent of MenuGen): 1) I had to create some kind of API key from Google Cloud UI to query YouTube for video metadata, 2) I booted up a VPS box for serving and 3) I bought the domain name. Once the box was up I gave Claude the IP and told it update, secure, harden, deploy and optimize the code, and it did the whole thing.
Many awesome projects that would have normally taken weeks/months even can now be few-shotted for breakfast. What else are we not thinking of.
@tweepul@karpathy I don't think it needed scaping as HackerNews are downloadable via BigQuery and have an official API. The rest could be sorted with SQL.
You can build one of these tonight with a free skill, one picture and about four prompts.
Be careful, I've used 15% of the 5 hour Pro limit for the MRI scanner.
@elvar_official made a Claude skill called teardown. Give it a photo of a machine and it builds a 3D version you can pull apart, piece by piece. It's easy to build your own.
The simplified process:
1. Install the skill: npx skills add elvarofficial/teardown -g -a claude-code
2. Find one clear picture of a machine.
3. Type /teardown, attach the picture, ask for real measurements.
4. Tell it to check its own work before showing you.
Share what you've built in the comments.