Show HN: Training a model to identify AI web content from structure alone https://ift.tt/ed9O3CJ

Show HN: Training a model to identify AI web content from structure alone Hey HN! We’re Vincent and Jochen from Sitefire ( https://sitefire.ai ). We have been working together for years, with backgrounds in RL/optimization at Stanford and software engineering from Technical University Munich (TUM). With Sitefire (YC W26), we help marketing teams get recommended by AI Search (ChatGPT, Google AI Overviews, AI Mode, Claude, etc.). Our software monitors prompts, sees which web pages get cited, and uses these insights to help marketing teams take action, e.g. create YouTube videos or write the right blog posts. This means we have a commercial stake in AI-generated web content. And for now, high-information, AI-generated content works great to get cited and recommended in AI Search. But after talking to hundreds of marketing teams, it became clear that everyone despises AI-generated content (“AI slop”). And yet, everyone still wants to leverage AI to create content. So we asked ourselves: what characterizes AI slop? Can we train a model to identify it from human-generated web pages? Researchers from the University of Maryland and Google DeepMind already asked this question for fiction. Their paper StoryScope (Russell et al., 2026) showed that you can tell AI-written stories from human ones by their structure alone, without looking at the words. We ported their pipeline to commercial web pages. Using the Wayback Machine, we collected 2,250 blog posts from 268 B2B company websites that were written before ChatGPT existed. For each blog post, five AI models (GPT-5.4, Claude Sonnet 4.6, Gemini 3 Flash, DeepSeek V3.2, Kimi K2.5) wrote their own version. Instead of looking at the words, we looked at how each post is built. We had an AI model answer 214 questions about every post, e.g. how hard it pushes its own product, whether it backs up its claims with sources, or whether it quotes a named expert. Then we trained a classifier on these answers. On blog posts it had never seen before, our classifier told AI-generated and human posts apart with 98% accuracy, getting only 19 of 1,740 wrong. Why does it work so well? Because all five AI models write in a similar shape. Mapping every AI model’s values for these features, we see they cluster together, while the human values sit apart and spread out much more. Of the 1% most unique blog posts in our data set, 149 are human, only 4 are AI. So what characterizes AI slop? It tells you the same thing three times. The title already promises what you'll get ("How to Cut Onboarding Time in Half"), the intro lays out what's coming, and the ending says it all again. 77% of the AI posts end by repeating their main point, compared to only 12% of the human posts. We call it the tidy, self-announcing blog post. Still, each AI model has its own accent. We trained a second classifier to tell which of the five AI models wrote a post, or whether a human did. It picks the right author 79% of the time, where random guessing (1 in 6) would get 17%. Almost all of its mistakes are mix-ups between the AI models, not between human and AI. The cool thing about structural features is that you can't simply reword your way out of it. We had each AI model rewrite its own posts until, on average, 73% of their original 13-word sequences were gone, and the AI slop classifier still worked just as well. We're building this into Sitefire: our agents get a structural understanding of text, so the posts they write go deeper and vary the way human writing does. There's a lot we haven't tested yet, like the myriad of humanizer tools, human rewriting, restructuring a post, or prompting an AI model to explicitly avoid these habits. And our human posts are mostly from 2020 to 2022, while the AI posts were generated in August 2026. Structure can't really tell when a human post was written, but it's still not a same-year comparison. We published the study with all the figures on arXiv: https://ift.tt/nMXJipP . The code is on GitHub: https://ift.tt/GJwrNd6 We're pretty sure your own blog isn't AI slop, is it? We built a checker that runs one of your posts through the ten features from the paper, so you can see for yourself (the full report asks for a work email): https://ift.tt/V2x5NF7 . Think you can tell AI slop from human writing? We also made a little game to see if you can keep up with our model, which gets all five rounds right: https://ift.tt/FZ2reBp . https://ift.tt/nMXJipP September 22, 2026 at 06:30PM

Show HN: Notes on Agentic AI – A text-first guide for practicing engineers https://ift.tt/OzdkKsD

Show HN: Notes on Agentic AI – A text-first guide for practicing engineers https://ift.tt/kAuSmtN September 22, 2026 at 11:49PM

Show HN: Two unnecessary playgrounds – C# and ZX Spectrum in the browser https://ift.tt/7Imt6xF

Show HN: Two unnecessary playgrounds – C# and ZX Spectrum in the browser C# playground https://ift.tt/NrY1wHi ZX-Spectrum playground https://ift.tt/9LcxyaW September 22, 2026 at 12:52AM

Show HN: Viaduct – C4 models that coding agents can read and update https://ift.tt/VOUTreB

Show HN: Viaduct – C4 models that coding agents can read and update https://ift.tt/Wai85JG September 21, 2026 at 11:20PM

Show HN: Jev filters large HN discussions https://ift.tt/5R9y3uN

Show HN: Jev filters large HN discussions https://ift.tt/D4eOS9Z September 20, 2026 at 10:37PM

Show HN: KillSwitch – a programming language designed to be difficult for LLMs https://ift.tt/bmLro4R

Show HN: KillSwitch – a programming language designed to be difficult for LLMs https://ift.tt/hHcyxUA September 20, 2026 at 01:10AM

Show HN: CUA-S1 – A System One Model for Computer Use https://ift.tt/b6npMid

Show HN: CUA-S1 – A System One Model for Computer Use Hello HN! We're Dillon and Francesco from Cua. We were wondering how many computer use tasks actually need a full general purpose LLM (e.g. gpt-6-astra, claude-opus-5 etc.) to think through all their decisions and steps. Some tasks require thinking about a plan, exploring different paths, recovering from failure. Other tasks are a question of making local decisions, like this value should go in this box, or should I check this box, or this element should be ignored. We wondered how far we could go with a small model trained to only make these kinds of decisions. Our inspiration was Typesafe's Jev and its System One Model framing. This is a nod to the dichotomy between thinking quickly, automatically, and intuitively (system 1) vs. thinking slowly, analytically (system 2), as described by Daniel Kahneman. The interesting question for us was: what happens if you give a model an interface of current context, and a set of possible choices, and you ask it to return a probability for each choice? This kind of model does not generate output token by token like most LLMs do, but rather scores the options you give it, which you can check, trust, and use to drive your app's behavior. CUA-S1 is our answer for narrow, specialized decision models for computer use. Our first release is CUA-S1-FORMS. We built this from ideas and code in jevlike, and then trained a second model just to handle form interactions. It has 706k parameters, and the original checkpoint is 2.8 MB. The first training iteration took less than 30 minutes on synthetic data. Given a set of structured elements and values extracted from a document, it predicts whether to use the given value, CHECK, CLICK, or SKIP for each element. It does not predict new values for text fields, and does not consider screenshots. Element decisions are scored together, and your code can order the actions, and Cua Driver will execute them one at a time. A first evaluation of this specialist vs. hosted Jev on our form task: - For the whole decision set: 99.7% correct vs 83.6%. - For the subset of steps that require an action: 100% correct vs 96%. - For the subset of steps that are just leaving already-filled fields alone: 100% correct vs 74%. The specialist was trained specifically for this task and convention (just press skip for already filled boxes), while hosted Jev has not been fine-tuned for it, so this is an experiment in scoped specialization. We measured 7-9 ms to score a form locally vs. 260-280 ms per call to hosted Jev including network latency, though those samples measure different things and are not end-to-end form completion times. Our interest here is in the space between a brittle script and a general agent loop. The content and layout of form fields vary enough that scripts get unwieldy, but the set of available decisions can remain narrow and well scoped. We want to explore the possibility of a general agent encountering something novel, and passing well understood decisions over to specialists like this. That is a direction we are looking into. The current release is for forms only. We're open sourced the synthetic data generation, training, evaluation, and Driver integration under libs/cua-s1 with an MIT license. Comments welcome! Especially if you are building computer-use agents and have run into a recurring decision that is too variable to script but is too narrow to call another LLM for. https://ift.tt/FU8LfuZ September 19, 2026 at 09:22PM

Show HN: 3D map of which newsletters link to the same things https://ift.tt/o3OtwU4

Show HN: 3D map of which newsletters link to the same things https://ift.tt/eUAi2tx September 19, 2026 at 11:25PM

Show HN: A model index from the AI Gateways https://ift.tt/QGbPgrT

Show HN: A model index from the AI Gateways https://ift.tt/uLkImpn September 19, 2026 at 12:26AM

Show HN: Learn divergently/chaotically with tree-learn https://ift.tt/kviXMO4

Show HN: Learn divergently/chaotically with tree-learn Chat interface is linear, I never quite liked that for when I would have too many questions, I would end up asking questions in a numbered list and not really have independent branches of conversation. On cli, the pi agent gives you this same functionality. On web, I made Fable make this. BYOK Openrouter - all client side - you can check the network console! https://ift.tt/zrXkDRB https://tree-learn.srijanshukla18.workers.dev September 18, 2026 at 09:51PM

Show HN: Composing domain-specific harness on Python in 10 mins https://ift.tt/F8mLOw1

Show HN: Composing domain-specific harness on Python in 10 mins https://ift.tt/9lDoXF2 September 18, 2026 at 02:16AM

Show HN: The Endless Museum, Wikipedia as a walkable museum https://ift.tt/IoSpLdR

Show HN: The Endless Museum, Wikipedia as a walkable museum https://ift.tt/QpKvCO6 September 18, 2026 at 12:28AM

Show HN: Ax-Check.com – Can Agents Use Your Product? https://ift.tt/u9HbF7c

Show HN: Ax-Check.com – Can Agents Use Your Product? This is a free site that checks whether agents can smoothly navigate a site and try out the product. Agents can use this too, just point them to ax-check.com https://ift.tt/XROFz14 September 17, 2026 at 11:38PM

Show HN: Restarted – a 2026 remake of the classic 2015 startup generator https://ift.tt/1X8hqTa

Show HN: Restarted – a 2026 remake of the classic 2015 startup generator The original startup website generator by Tiff Zhang and Mike Bradley landed on Hacker News in April 2015 ( https://ift.tt/MfWJjYF ) and has been one of my favorite little novelties of that era ever since. It perfectly captures the saturated colors, cliché hero shots, gimmicky names, buzzword-heavy slogans, and proudly hirsute team photos of the time. A lot has changed since then, so I thought it would be fun to make a contemporary remake: https://restarted.io/ By default you get the minimalist aesthetic and clean-cut faces of 2026. The classic 2015 look is still available — just click the link at the bottom of the page or change the “z” parameter in the URL to the more familiar “s”. The universe of partner sites and competing startups is just as expansive as it ever was. The original site is entirely client-side and requires downloading all of the data tables locally. It leans on a mix of jQuery 1.11.2, Bootstrap 3.3.2, and Font Awesome 4.3.0, and if you view the source, it instantly gives away all of its secrets. For restarted.io I replaced all of that with a server-side renderer written in Go, so this time view-source tells you nothing. There are many Easter eggs in there — see how many you can find before I write them up. My original goal was to stay faithful to the 2015 appearance, and that turned out to be a technical adventure. The original's sine-based random number generator is... the worst, and different implementations of sine give different results. The eventual solution was to extract the exact sine function from Chrome’s V8 engine, as vendored C behind cgo and as a line-by-line Go port that keeps cgo optional, so the seeds and results line up the way they used to. Both are checked against V8’s own test cases. Then I discovered a bug in the original code that made half of its vocabulary unreachable — the first half of the verb table and the second half of the noun table, exactly complementary, so nothing about the output ever looked truncated. My goal then shifted from remaking the generator as it was in 2015 to remaking the site as the authors intended it to be in 2015. Over the years several people asked for their photos to be removed, so the remake instead draws from a broad pool of era-appropriate AI-generated profiles. A perceptual hash helps keep everyone looking distinct, and there’s a bit of extra care to make sure the Wang Fangs of the world don’t appear as Irish lasses. The hero image pool is much larger now, and all the old Rio de Janeiro shots have been retired, though you’ll still recognize plenty of the 2015 photos. Have fun poking around! https://restarted.io/ September 15, 2026 at 05:04PM

Show HN: SeasonMap – when to travel where? visualized with climate data https://ift.tt/RJ2t70d

Show HN: SeasonMap – when to travel where? visualized with climate data Author here. I'm trying to visit every country and I've been to 158 so far. Before I decide where to travel, I'd ask a local friend which season to avoid, or open up dozens of browser tabs on climate data to figure out what the place is like in a given month. Climate data still miss things. Cancun in September looks great on paper, with 31°C and 10 hours of sun, but it's hurricane season and the beaches can be covered in seaweed. Typical info that locals would know, which can also be captured as static data. So I built SeasonMap to answer "when should I go to ?" What you can do: - Pick a travel style (city walk, beach, hiking, skiing, max sun, low humidity, etc.) and see every place ranked on a map - See what's in season and what to avoid, and why: monsoon, hurricanes, extreme heat, bad air, peak crowds - Filter destinations by temperature, rainfall, sunshine, air quality and hazard seasons - Open a place to see its whole year: month by month weather, events (festivals, whale watching, cherry blossom), crowd levels, practical notes like scams, and traveller anecdotes summarized by AI with links to the sources Data Source & how I made it: - The climate data is ERA5 normals via Open-Meteo (2016–2025), corrected with NOAA station data where available. - Events, hazards and traveller notes were researched and by AI agents, and every one links to its source. Gathering it was easy. Checking it was the hard part. - Yes, I've used AI heavily on this project before anyone call it an AI slop. Making was easy, but it took billons of tokens of beating whack-a-mole ai to polish and tweak to make it usable and decent. Through that, I've created many skills and evals ranging from visual qa, evals for irregular data, automated i18n and others. It still feels much like AI as I was using Claude Design, which i want to improve on. I tried using local llm, but the throughput was so low. Pricing: the first 5 minutes are fully open, no signup. After that, the top 3 destinations and 25 place breakdowns a month are free. A 30-day pass is $7, $39 a year or $69 lifetime. iOS and Android apps are coming soon. Any feedback welcome. https://seasonmap.app September 16, 2026 at 09:13PM

Show HN: Pixel Agents – A pixel-art mission control for your Claude Code agents https://ift.tt/biClGRS

Show HN: Pixel Agents – A pixel-art mission control for your Claude Code agents https://mateovalle.github.io/pixel-agents/ September 16, 2026 at 10:42PM

Show HN: Pizza Bot – An inbox for AI agents that work in the background https://ift.tt/46WEU1t

Show HN: Pizza Bot – An inbox for AI agents that work in the background Hi HN - long-time lurker (since 2012!), first time poster. Pizza Bot is a self-hosted desktop app for Mac, Windows, and Linux that runs AI agents in the background and exposes them through an email-like UI. Finished work shows up in Unread, and anything waiting on your approval shows up in Action. It's Apache 2.0-licensed, there's no signup and no telemetry, and you bring your own model provider: Anthropic, Amazon Bedrock, Google Gemini, OpenAI, OpenRouter, or a local model through Ollama. There are builds on the releases page, or you can run it from source. Pizza Bot started as an internal passion project I worked on with a small team at Amazon. The whole thing came out of my frustration at having to manually log CRM activities through a browser form. I built a simple REST API called "JoeBot" that connected to my authenticated browser session over CDP and filled out the form for me using Playwright. Then I hacked up a quick Obsidian plugin so I could trigger it from my local notes (no AI and no MCP servers involved). This caught on quickly. My fellow AWS Solutions Architect Igor Fil joined up with me, and we rebranded the project as "Pizza Bot," named after Amazon's two-pizza teams. We started seeing what other automations we could build. We found a GraphQL API we could query and hacked up some "recipes" to pull data out of the CRM to help with meeting prep. That worked great, and it was right around the time MCP servers seemed to be taking off, so we decided to expose Pizza Bot as an MCP server instead, so it would be available to AI tools through natural language. This was a decent solution for technical users, but the Account Managers who live inside our CRM system wanted something too. We decided to rebuild Pizza Bot as an Electron desktop app modeled after an email inbox, so it would be familiar to non-technical users and would run on both Mac and Windows. We also bundled internal MCP servers as OCI images and hosted them in Amazon ECR as an "addon marketplace" so users could install them with one click without having to set up Amazon developer tooling. The project took off organically and expanded outside of AWS into the wider Amazon organization globally. More than 2,000 people ended up using it for meeting prep, email drafting, Slack summaries, CRM logging, prioritizing their day, and web research. Once apps like Claude Cowork and Amazon's own Quick Desktop came out, we realized the real growth opportunity was outside of Amazon. Rather than try to rip out the Amazon-specific integrations, we rebuilt Pizza Bot once more as an open source project. We leaned on coding agents heavily, which is the only reason a team our size could pull off a full rewrite. I'm pleased to say it's finally public, and we're hoping to bring in community members and see where it goes. We'd like to do for knowledge workers what Claude Code and Codex have done for programmers. A couple of things to know up front. Most of what made Pizza Bot useful on day one inside Amazon came from that internal catalog of skills and MCP servers for Amazon's own systems, and none of it could come out with the app. So it ships thinner than the version those 2,000 people used, and building that catalog back up for tools other people actually use is where we need the most help. It's also a community project and not an AWS service, so there's no support or SLA behind it. The Windows and Linux builds aren't signed yet either. On the technical side, Pizza Bot is a server and a client. The desktop app bundles both, or you can point a client at a remote backend; personally, I self-host the server on my home network and reach it from my phone over Tailscale. The server owns the thread lifecycle and checkpoints state with DeepAgents and LangGraph, and clients rehydrate from it as needed, so you can disconnect mid-run and pick the thread back up from another client. Approval pauses outlive the session that created them and collect in an Action filter, so you can answer an hour later from a different device. The agent you talk to has a sandboxed QuickJS interpreter that can reach your filesystem only if you grant it a folder, but its main job is to delegate. Each subagent is a 1:1 mapping of a Skill, and an Activity bar shows that subagent and the tool calls it's making as it works. Memory is opt-in and stored as plain markdown files on your machine. Every tool call is explicit, including looking up a memory - we err on the side of transparency to reduce surprises. Tools come from MCP servers, and skills are ordinary SKILL.md files with a per-tool approval policy, so existing skills that don't require a code interpreter should still work. What I'd most like to hear about is where the app itself gets in your way, the kind of problem you can't fix by writing a skill or an MCP server. I'm around today to answer questions! https://ift.tt/MAz40UX September 15, 2026 at 08:50PM

Show HN: Sass – Rust and WASM https://ift.tt/aGXo1Ry

Show HN: Sass – Rust and WASM https://ift.tt/JsKdHtN September 16, 2026 at 01:04AM

Show HN: SCIP MIP solver bindings for Go, ported from russcip https://ift.tt/mBOMxbR

Show HN: SCIP MIP solver bindings for Go, ported from russcip https://ift.tt/5usnQrh September 15, 2026 at 09:26PM

Show HN: Macros with a Behringer FCB1010 MIDI Pedalboard in macOS https://ift.tt/WQxwIoz

Show HN: Macros with a Behringer FCB1010 MIDI Pedalboard in macOS https://ift.tt/je35Jch September 15, 2026 at 04:31AM