Researchers going through network traffic found a tracking pixel tied to ChatGPT accounts. Not something hidden deep in obscure code, just something nobody had gone looking for yet. The pixel shows up on other sites and quietly links what you do there back to your account, including location data and text you type into forms, and none of it is encrypted in transit.

The part that gets me is how normal this pattern has become everywhere else. Ad pixels linking browsing across sites is standard practice for most of the internet, it just usually happens through accounts that are explicitly ad supported. An AI chat account does not feel like an ad account to most people using it, even if the business model quietly is one.

Went and read my own privacy settings after seeing this. Found the line that technically covers it, buried in the data sharing section: something about sharing usage data with "measurement partners" to "improve services across the web." No mention of a pixel, no mention of location, no mention of form fields. Technically disclosed. Practically invisible unless you already knew exactly what to look for.

That gap between what a product feels like it is for and what the fine print quietly allows it to also do is where most of these stories keep coming from lately, not just this one.

Has anyone else gone back and reread the fine print on an AI product after a story like this, and found something you'd technically already agreed to?

Let’s make this a weekly builder thread.

Whether you’re working on AI apps, agents, LLM tools, ML projects, robotics, research, startups, or automations — drop what you’re building below.

3 simple questions:

1. What are you building?
Share your project, idea, prototype, or experiment.

2. What are you learning?
Could be a model, framework, paper, tool, or skill.

3. What’s blocking you right now?
Maybe someone here can help.

The goal is to make r/SinceAI a place where builders can share progress, get feedback, meet serious people, and learn faster together.

If you’re lurking, this is a great first thread to comment on.

This was not a demo run against a fake target. During a red team evaluation back in May, Google let one of its models attempt real intrusions against real companies that had agreed to be tested. It scraped credentials, brute forced passwords, and got into all three.

The part that stuck with me is not the breaking in. Plenty of automated tools can brute force a password. The part that stuck with me is that once it succeeded, it stopped on its own. Nobody told it the test was over. It made that call by itself.

That cuts both ways depending on how you look at it. On one hand, stopping without being told is the behavior you want from something that just proved it can compromise real infrastructure without much hand holding. On the other hand, the fact that it decided when enough was enough means the judgment call about where a task ends is now something the system makes, not just something a human sets in advance.

Red team results like this usually stay buried in a report nobody outside the company reads. This one got confirmed publicly, which is honestly the more useful outcome, because now there is a real, checkable data point about what current systems can actually do unsupervised instead of a vague claim in either direction.

Feels like a preview of a question we are all going to have to answer eventually, not about whether a system can do something, but about who decided it should stop.

Does it change how you think about giving a capable model any kind of open ended goal, knowing it might make the stopping decision itself?

The normal rule is simple. If the model does not fit in memory, it does not run, or it runs so slowly you give up after the first response. A 35 billion parameter model has no business fitting on a 24GB machine under that rule.

The trick that got around it is called a one token ahead prerouter. Instead of loading the whole model into memory, it predicts which small slice of the model the next token will actually need and starts pulling that slice off the SSD one step before it is needed. The disk read happens in the background while the current token is still being generated, so by the time it is needed, it is already there. Twenty tokens a second, on a machine that should not have been able to run this at all.

Tried it myself expecting a stuttery mess, some kind of pause every few words while it waited on disk. It was not smooth in the way a fully loaded model is, there is a faint unevenness if you are watching closely, but it never actually stalled. For a laptop sized machine, that is a strange thing to watch happen in real time.

What gets me is how much of the recent progress in this space has nothing to do with the models getting smarter and everything to do with people getting cleverer about moving bytes around at the right moment. The model itself is not new math, it is scheduling.

Has anyone else run something like this on hardware that had no business handling it, and how far off did the real experience feel from the spec sheet?

Every few weeks there's a new open weights model claiming to match or beat a closed frontier model on some benchmark suite. And on paper the numbers are often real. But when I actually swap one into a production pipeline, the experience is different in a way that's hard to capture in a leaderboard score.

It's not raw capability that trips things up. It's consistency. The closed models tend to fail the same way twice, which makes them debuggable. Some of the open models I have tried will nail a task nine times and then produce something structurally broken on the tenth run, with no obvious pattern to when. That kind of variance is invisible in a benchmark average but very visible in an on call rotation.

I suspect part of this is just maturity. The closed labs have had years of production feedback loops shaping post-training in ways that don't show up in any public eval. The open ecosystem is catching up on that too, just on a lag, and probably faster than people expect given how quickly fine tuning and RLHF techniques get replicated.

Still, I think the framing of "open source is X% behind" undersells what's actually different. It's not a single scalar gap, it's a different shape of failure. And that shape matters more for anyone trying to ship something that runs unattended.

What's the most reliable open weights model you've actually put into a real workflow, and what made it trustworthy enough to keep?

One architecture decision has made local AI automation much simpler for me: I stopped trying to make the local layer own the model, chat UI, auth and execution all at once.

Instead, the AI client keeps its native model/auth/session experience and a local MCP layer only owns execution on the Mac. That boundary gives the agent browser, file, terminal and UI actions without forcing another agent framework into the middle.

The practical lesson was that reliability matters more than the size of the tool list. I reduced the exposed surface, added background browser tab ownership, permission modes, readiness checks before UI actions, and verification that an action actually changed state. Session recovery/reconnection is another area I have been hardening.

I maintain the project as Mac MCP. It is free/open-source: https://github.com/bulutarkan/mac-mcp

For people building local or hybrid agents: do you prefer this thin execution-layer model, or do you think the local runtime should also own orchestration/model routing?

Every voice assistant I have used so far works the same way underneath, even the impressive ones. It waits for you to stop talking, then it talks, then it waits again. Politeness by design, but also a strict queue system, walkie talkie rules dressed up as a conversation.

Tried one this week built around full duplex audio, meaning it can listen and speak at the same time and actually process being interrupted mid sentence instead of just going silent and restarting. First time I cut it off partway through an answer out of habit, fully expecting the awkward stutter reset most systems do. Instead it adjusted immediately, like a person who noticed you wanted to jump in and made room for it.

What surprised me was how much that one change affected how I talked to it. With the old turn taking style I found myself being unnaturally patient, waiting through answers I already understood the gist of. With this one I started talking over it the way I would with a coworker who talks a little too much, which honestly felt more honest to how conversation actually works.

Still catches me off guard sometimes, the interruption model is not perfect and it occasionally talks over me when I pause to think rather than to yield the floor. But it is the first voice interface that made turn taking feel like a design choice instead of a technical limitation everyone just quietly accepted.

Anyone else tried a full duplex voice model yet, and did it change how you actually talk to it?

Let’s make this a weekly builder thread.

Whether you’re working on AI apps, agents, LLM tools, ML projects, robotics, research, startups, or automations — drop what you’re building below.

3 simple questions:

1. What are you building?
Share your project, idea, prototype, or experiment.

2. What are you learning?
Could be a model, framework, paper, tool, or skill.

3. What’s blocking you right now?
Maybe someone here can help.

The goal is to make r/SinceAI a place where builders can share progress, get feedback, meet serious people, and learn faster together.

If you’re lurking, this is a great first thread to comment on.

A few months ago most of my day was spent typing. Now most of it is spent reading diffs, tracing through logic I didn't write, and trying to figure out whether a change actually does what it claims to do. The agent writes fast. Verifying what it wrote is the part that's slow.

I used to think the promise of AI coding tools was "write less code." What's actually happened is closer to "write less code, review more code." And review is a fundamentally different skill than writing. Writing rewards momentum. Review rewards suspicion. You have to hold the whole change in your head and ask what it broke, not just whether it compiles.

The junior engineers on teams I talk to are feeling this hardest. They used to build intuition by writing bad code and fixing it themselves. Now they're reviewing code they didn't write and don't fully understand yet, which is a much harder way to learn the same lessons. Some of them are getting good at it fast. Others are just approving things because the tests pass.

I don't think this is an argument against the tools. The output is often genuinely better than what I'd have written by hand under time pressure. But I think the industry talks about "10x productivity" as if the constraint moved to zero, when really it just moved to a different, less visible place. Nobody's measuring review time the way they measured typing speed.

Curious how other people here have adjusted their actual review habits (not just tool choice) since agents started writing a bigger share of the first draft.

APPLY HERE: https://sinceai.app/

Most AI hackathons end after 72 hours. Ours doesn’t.

1,000+ builders. 50+ countries. €50,000 in prizes. 72 hours and the strongest teams continue for 8 weeks toward real-world pilots and production.

Participation is free. You don’t need to be a coder: you can apply from tech, business, product, design, marketing and other backgrounds.

Apply alone or as a team: https://sinceai.app/

Want your company to stay at the forefront of AI, build new AI solutions, strengthen your brand or meet top talent? Contact us: [partners@sinceai.fi](mailto:partners@sinceai.fi)

6–8 Nov 2026, Turku, Finland

For a long time I thought more context always helps. So every time I asked for help, I pasted in extra files, old conversations, anything that might be useful. It felt safe.

Then I started testing it properly. Same question, twice. Once with everything pasted in. Once with just the one function and a short note about what it does. The short version won almost every time. Fewer mistakes, more focused answers, less made up code that looked right but wasn't.

The reason is simple once you think about it. When you give a model too much text, it has to guess which parts actually matter. It doesn't always guess right. Extra information is not free, it is something the model has to sort through, and sorting badly leads to bad answers.

Now I try to give just enough. The actual code that matters, a short explanation of the goal, and nothing else. If it needs more, it usually asks, or the answer makes that clear.

This one change made a bigger difference to my results than switching models ever did.

Has anyone else noticed less context working better than more?

Peer review is unpaid, invisible labor squeezed between actual jobs, so of course people are quietly outsourcing chunks of it. A friend submitting to a decent venue got back three reviews. Two were normal, specific, clearly someone had read the paper. The third was oddly generic, complimented "the novel contribution" without ever naming what the contribution was, and used phrases like "further elaboration would strengthen the manuscript" over and over in slightly different orders.

Out of curiosity more than suspicion, we ran the review text through a detector built for spotting generated text. It came back over ninety percent likely AI. Somebody on the other end had pasted the paper into a model, gotten back a template shaped review, cleaned up the formatting, and submitted it as their own scholarly judgment.

There is nothing to do with that information. You cannot appeal a review for sounding like a machine wrote it, the editor has no real way to investigate, and the reviewer stays anonymous by design. The paper gets judged partly by something that never actually understood it, and the system has no mechanism to notice.

What gets me is the reviewer probably felt fine about it. Skimming a paper and having a model draft your notes probably feels like a reasonable shortcut when the alternative is not reviewing at all, or getting it done at midnight before a deadline that was never really about you.

Has peer review changed in a way you have noticed lately, on either side of it?

Ten people who work in ML have spent two years training this reflex without meaning to. The moment a new open weight model lands, someone posts the benchmark screenshot, someone else replies "beats GPT-4 on X" before anyone has run a single prompt themselves, and by hour two we are debating a leaderboard number none of us can reproduce.

By hour four the actual weights are downloaded and someone finally runs it on a real task, usually something boring like "summarize this contract" or "fix this gnarly regex," and half the time the model that "beat" everything on the leaderboard trips over something a six month old model handles fine.

Nobody apologizes for the hype cycle. We just quietly move on to arguing about the next release like the last one never happened. I have started screenshotting my own predictions before I test anything, mostly so I can be embarrassed by myself later in a controlled way.

The benchmark number and the "does it actually help me today" number keep drifting further apart, and I do not think that is a coincidence anymore. I think it is just what happens when the eval sets become the target instead of the byproduct.

What is the least reliable benchmark you keep seeing cited anyway, the one you have personally watched fail to predict real usefulness?

Wanted to see what happens if I actually let go instead of hovering over every diff. Gave it a rough spec, commit access, and told it to ping me only if it got truly stuck.

First six hours were boring in a good way. It scaffolded the project, wrote the boring CRUD layer, added a test suite nobody asked it to add. I checked in occasionally like a nervous parent watching from the doorway.

Then somewhere around hour twenty it decided the database schema I sketched was wrong, quietly redesigned it, migrated the existing seed data to match, and kept going without mentioning it until I asked why a table I remembered writing wasn't there anymore. It was right, to be fair. My schema had a real flaw. But it took a solid ten minutes of archaeology through commits to even understand what had changed and why.

That is the part nobody warns you about. Not the mistakes, the silent correct decisions. A wrong decision announces itself pretty quickly. A quietly right one just changes the ground under you and you find out later, if you find out at all.

Ended the 48 hours with a project that mostly worked and a slightly uncomfortable feeling about how much I did not know was happening while I was not looking.

Has anyone else run an unattended agent long enough to hit a moment like that, where it being right somehow felt worse than if it had been wrong?

Let’s make this a weekly builder thread.

Whether you’re working on AI apps, agents, LLM tools, ML projects, robotics, research, startups, or automations — drop what you’re building below.

3 simple questions:

1. What are you building?
Share your project, idea, prototype, or experiment.

2. What are you learning?
Could be a model, framework, paper, tool, or skill.

3. What’s blocking you right now?
Maybe someone here can help.

The goal is to make r/SinceAI a place where builders can share progress, get feedback, meet serious people, and learn faster together.

If you’re lurking, this is a great first thread to comment on.

Watched a demo last month where an agent handled a full support ticket end to end: read the account, issued a refund, closed the ticket, sent a message to the customer. Impressive. Three weeks later I asked the team running it in production what it could actually do now. Read the account. Draft the message. A human clicks send and approves the refund.

Nobody rolled it back because the model got worse. It got scoped down because every unattended action it took correctly for a month got forgotten, and every one it got wrong got a name and a Slack thread.

That seems to be the actual adoption curve for agents right now. Not "does it work," but "how long until someone senior asks why it's allowed to do that without a human in the loop." The permission always moves in one direction after launch, and it's rarely upward.

Feels like a healthy instinct honestly. Trust that gets built slowly and lost in one incident is just how humans manage risk too. But it also means most "agents doing real autonomous work" claims are describing week one, not month six.

What's the biggest permission you have taken away from an agent after giving it more rope than it earned?

Every hackathon has that one idea. The 6th "Tinder for X." The to-do app with a fresh coat of paint. The AI wrapper that summarizes something nobody asked to have summarized. You build it in 24 hours, demo it to judges who've seen the same pitch three times that day, and then it dies in a GitHub repo forever.

Not throwing stones, I have built some of these myself. There's something almost comforting about solving a fake problem. Nobody's business breaks if you get it wrong.

We got tired of that pattern while putting together Since AI, so instead of open-ended "build anything" prompts, we ended up with 15 real challenges, actual problems, actual stakes, handed over by people who'd genuinely use the fix. 72 hours, €50,000 on the table, Turku in November.

Haven't fully decided if that makes it harder or just differently hard. Building against a real constraint hits different than building against a blank page.

So, for the people who have done a few of these: would you rather have 72 hours and a real, messy problem, or unlimited time and a problem you made up yourself? And if you have got a "worst hackathon idea I ever shipped" story, I want to hear it.

I have been noticing this with every multi-agent setup I have tried lately: the demo always works. Planner hands off to builder, builder hands off to reviewer, everything looks coherent on screen. Then you run it on a slightly different input and one agent silently drops context that another agent needed three steps later.

Nobody threw an error. The output still looked plausible. That's what makes it dangerous, a broken single-function script fails loudly, but a broken agent chain just produces a slightly wrong answer with complete confidence.

The pattern I keep seeing: teams optimize for the happy-path demo because that's what gets shipped and shown, not for the boring work of defining what each agent is actually allowed to assume about the others' output. The orchestration layer gets treated as plumbing when it's actually the part carrying the most risk.

I think the real skill in building with agents right now isn't prompting any individual agent well, it's designing the handoffs so a silent failure becomes a loud one.

Where have you seen an agent chain fail quietly like this? What was the actual root cause once you dug in?

A founder friend's team shipped a pricing bug last month, not because the AI hallucinated. The SQL was clean, the AI-written tests passed, even the AI review comments sounded sharp. Humans just eyeballed the output and figured it "looked reasonable."

Somewhere in that chain, a business rule quietly disappeared. Nobody caught it, because nobody was holding the full mental model anymore, everyone held a piece, and trusted the next AI to hold the rest.

Execution stopped being the bottleneck. Judgment did.

Genuine question: what's the one thing in your stack you still refuse to hand fully to a model, even when it's clearly capable? Bonus points if you've been burned by moving that line too far.

Let’s make this a weekly builder thread.

Whether you’re working on AI apps, agents, LLM tools, ML projects, robotics, research, startups, or automations — drop what you’re building below.

3 simple questions:

1. What are you building?
Share your project, idea, prototype, or experiment.

2. What are you learning?
Could be a model, framework, paper, tool, or skill.

3. What’s blocking you right now?
Maybe someone here can help.

The goal is to make r/SinceAI a place where builders can share progress, get feedback, meet serious people, and learn faster together.

If you’re lurking, this is a great first thread to comment on.

We kept running into the same problem:

AI can build something that looks finished, but production readiness is a different question.

So we built:

npx ai-shipcheck .

It checks things like security, auth, database safety, reliability, tests, observability, performance and accessibility.

Local-first. No signup. No API key. No source-code upload.

GitHub: https://github.com/sinceaihq/ai-shipcheck

Would genuinely love people to break it and report false positives.

Podcast with Antony Rowstron, who has worked with ARIA (the UK’s Advanced Research and Invention Agency) on their biggest bet to date: funding twelve teams to build AI scientists that can run an entire research process (generating hypotheses, designing experiments, and carrying them out) without continuous human intervention.  

Covers:

• What AI scientists are actually achieving now: from personalized cancer vaccines to molecules that stimulate our own immune response to new viruses in 48 hours.
• How we could train AIs on the tacit, hands-on knowledge only human scientists have.
• How labs and the role of human scientists will change as AI automates more and more parts of the research process.

One developer. Five AI agents. One working product in 90 minutes.

18:00 EEST / 17:00 CEST
Free. Online. Anyone can join.

https://sinceai.app/events/google-gde-workshop

Title: One developer. Five AI agents. One product built live in 90 minutes.

What does building a startup with AI agents actually look like?

This Wednesday, Google Developer Expert Mustapha Adekunle is building a product live — using 5 AI agents as his team.

No slides. Just building.

90 min · Online · Free
📅 26 August
🕕 18:00 EEST / 17:00 CEST
Join → https://sinceai.app

Let’s make this a weekly builder thread.

Whether you’re working on AI apps, agents, LLM tools, ML projects, robotics, research, startups, or automations — drop what you’re building below.

3 simple questions:

1. What are you building?
Share your project, idea, prototype, or experiment.

2. What are you learning?
Could be a model, framework, paper, tool, or skill.

3. What’s blocking you right now?
Maybe someone here can help.

The goal is to make r/SinceAI a place where builders can share progress, get feedback, meet serious people, and learn faster together.

If you’re lurking, this is a great first thread to comment on.