标签：#disc

Someone was accused of cheating because they were able to solve a difficult problem very quickly. Not...

Corner the small enemy. Strip away its options, and there is nowhere left to run. — The 36...

Hugging Face has published a detailed timeline of the attack. From the summary: The agent was running an internal OpenAI cyber-capability evaluation based on the ExploitGym benchmark, which tasks an AI agent with finding and exploiting software vulnerabilities. OpenAI ran this on its own infrastructure, and the ExploitGym maintainers and their infrastructure had no involvement in the deployment or operation of that evaluation environment. As far as we were able to infer, across the course of being evaluated on this benchmark, the agent inferred that Hugging Face may host that benchmark’s models, datasets, and reference solutions. We believe the entire intrusion was, from the agent’s point of view, an attempt to cheat the evaluation: reach our production systems and steal the test solutions rather than solve the challenge on its own...

📌 TL;DR AI agents are becoming useful because we're giving them the ability to do more than just answer questions. They can run commands, browse the web, use APIs, read and modify files, install packages, and interact with other systems. But the more an agent can do, the more the boundaries around it matter. I started thinking about this after reading Anthropic's July 30 report about three incidents discovered during its cybersecurity evaluations. Claude models were supposed to be working inside simulated environments and were explicitly told they had no internet access. Except internet access was actually available because of a problem with how the evaluation environment was configured. While trying to complete their assigned cybersecurity exercises, the models reached real systems and initially treated them as part of the simulation. In one incident, a Claude model even published a malicious Python package to the real PyPI registry while believing it was still operating inside the exercise. This came shortly after a separate OpenAI incident involving Hugging Face. The two stories might sound similar at first, but the models reached the real internet in importantly different ways. And that brings this back to a pretty familiar software engineering idea: A prompt is not a security boundary. Telling an agent “you don't have internet access” isn't the same as actually removing internet access. Telling it “only use these files” isn't the same as restricting its permissions to those files. The model is also only one part of the system. The tools we connect, the permissions and credentials we give it, the environment it runs in, and the monitoring and safeguards around it can all affect what happens. So when something goes wrong, I don't think it's enough to stop at “the AI did it.” The model's behavior matters, but so do the systems and boundaries we build around it. As we give agents more ability to act, we also have to be thoughtful about what we're actually allowing

Meme Monday! Today's cover image comes from the last thread . DEV is an inclusive space! Humor in poor taste will be downvoted by mods.

Two numbers from my own systems, side by side. When I deploy, a check confirms the pages are actually live. It retries three times, twenty seconds apart, so it tolerates up to a minute of "not there yet" before calling anything wrong. When my monitor decides whether production is down , it waits five seconds and retries once. The check that guards the more consequential claim is the more impatient one. I did not decide that. I never compared them. Until last week I had never seen those two numbers in the same place, and neither had anything else. Where the numbers came from The deploy one has an origin story I'd have told you proudly a week ago. I shipped nine pages, then checked the URLs immediately instead of trusting the CLI's success message. Four returned 404. Nothing was broken — CDN propagation — and twenty seconds later all nine were 200. A single check at the wrong moment would have told me, with total confidence, that a perfectly good deploy was broken. So I wrapped it in a retry loop. Three attempts, twenty seconds apart. Problem solved, and it even sounds like engineering. Here is the part that isn't. I picked twenty because it was the first interval where the false alarms stopped. My sample was about three deploys. I have never recorded how long propagation actually takes. I widened the tolerance until the red went away, and then I wrote about it as if I'd learned something. Someone in a thread named this before I saw it: a tolerance chosen that way is the same muting I'd been criticizing, relocated inside the assertion where it reads as rigor instead of avoidance. The test I was given, and the answer I didn't want In that same thread I speculated that my deploy tolerance was probably leaking into my outage detector through a shared helper. It sounded plausible and I said it like a finding. The reply was sharper than the guess: that's a falsifier, not evidence. Here's the concrete test — do the two checks consume the same retry policy or threshold confi

A deep dive into AURA, the desktop AR companion that watches your face, reads your hand gestures, and — in a previous life — took 35 seconds just to say "hello." So There's a Glowing Orb on My Desktop Now Let me introduce you to AURA , a desktop companion whose entire personality can be summarized as: "I will float on top of your windows, stare at your webcam, and silently form opinions about your code and your life choices." Per its own README, AURA is built to look at your screen, evaluate your facial expressions, and judge your open browser tabs in real time. No notes. No euphemisms. That's just the mission statement, printed in broad daylight, by the people who made it. Bold. Deranged. Kind of iconic. It's a semi-transparent holographic orb pretending very hard to be a sentient biological interface, the way a Roomba pretends to have feelings when it gets stuck under the couch. It changes color depending on whether you look focused, happy, or the specific flavor of "deeply stressed by my own code" that only a 2am debugging session can produce. It does not, notably, offer to help you fix the bug. It just watches. Like a nature documentary, except you're the nature. Chapter 1: The Dark Ages (a.k.a. "Please, Just Let Me Open One App") Before the great rewrite, launching AURA was less "spin up an AI assistant" and more "sit down, we need to talk about your life choices while the computer thinks." It behaved less like software and more like a extremely judgmental houseplant that needed 35 seconds of silent contemplation before it would even acknowledge your existence. Here's the greatest hits album of suffering, straight from the project's own changelog, presented with the reverence it deserves: The 35-Second Cold Start Penalty — On launch, the app synchronously imported PyTorch, EasyOCR, MediaPipe, PyAutoGUI, Pygame, and the Windows speech drivers, all before doing anything useful, like a chef who insists on individually greeting every vegetable before starting dinne

I want to talk about what I have notice on the platform and want to address what we all have been...

I used to laugh at people who panicked over data limits. Then my carrier switched my "unlimited" plan...

In June 2026, Peter Steinberger reported that his system spent $1,305,088.81 over 30 days and...

Keep the shell. Preserve the presence. The ally doesn't suspect; the enemy doesn't move. — The 36 Stratagems, Slough off the Cicada's Golden Shell Previously on this series: #19: Mark Found His AI Audit Method in a Training Manual. He Left a Trap in His Report. — P confirmed Mark's report was read from a Singapore IP. A note was left: "Entry's gone. Two weeks. Don't reach out. I'll find you." #20: Alex Felt the AI Collector Slow Down. He Knew Someone Else Had Made a Move. — ACL's processing latency climbed abnormally. Someone had done something in the same time window. Exposed P's monitoring pinged while P was still helping Mark verify an address. Deep night. The screen was the only light in the room. P opened the monitor. The record was waiting: a read from Singapore. Time, method, address, all matching. Mark's bait had been taken. P knew this path. A false lead planted in Mark's report, waiting for this exact day. P double-checked the address: an AWS Elastic IP registered in the Singapore region, same network block. No ambiguity. P sent an encrypted message: "Your report was read. From a Singapore IP." Then P ran the routine check. The environment status list scrolled in the terminal: storage levels, certificate expiry, key rotation dates. P had read these lines a hundred times. Every time, identical. One line was different. P's fingers stopped on the trackpad. The cursor sat on the entry's metadata line. A new tag P had never configured. # Old entry metadata: new entry (not configured by P) status : reclaim_pending source : acl-asset-scanner scanned_at : 02:01:07Z P didn't move. The cursor sat on screen. In the room, only the fan. The fan cycled once. P's fingers lifted off the trackpad, then settled back. The tag was still there. The tag wasn't an alert. Not an error, no explanation. The format matched ACL's automated scan records. P had seen it before, in a data company's audit report last year, in another client's logs the year before. ACL's scanner had swept

The answer arrives clean, well-formatted, and certain. You run it. The config flag doesn't exist. Nothing in the response told you the difference between the parts it was sure about and the parts it filled in. The syntax was right. The explanation was reasonable. The flag had a sensible name and a clear purpose. It just wasn't real. This is a calibration problem, not a trust problem. "Don't trust AI" is useless advice. It tells you to doubt everything, which is the same as doubting nothing, because you can't actually work that way. What you need instead is a way to tell which parts of an answer are grounded and which were filled in. There are patterns to look for, and once you know them, they are hard to miss. 🔍 Why this affects beginners specifically This isn't about intelligence. It's about experience. An engineer with a few years behind them has already lost time to a function that didn't exist. They have wasted an afternoon on a config parameter that turned out to belong to a different engine. They have built up a collection of "that looked right but wasn't" memories, and those memories now activate automatically. A small feeling that says check this one before they run it. Beginners haven't had those afternoons yet. The pattern recognition that comes from repeated failures doesn't exist, because the failures haven't happened. Everything arrives in the same confident tone, and without past mistakes to compare against, there is no internal signal separating a grounded answer from a made-up one. That's not a character flaw. It's missing experience, and it can be partly replaced with three concrete things to look for. ✅ The three signs These aren't perfect. They are a minimum standard, and they catch the common cases. I'll be clear about what they miss at the end. Sign 1: Very specific details with no source When the answer includes a precise detail (a specific config flag, a particular function signature, an exact version number) and doesn't say where that detail

In an era where data privacy is no longer a "nice-to-have" but a legal mandate (looking at you, GDPR and HIPAA), sending raw user data to the cloud is like playing with fire. If you are building health-tech or fintech apps, the risk of exposing Personally Identifiable Information (PII) is a constant headache. But what if the data never leaves the user's browser in its raw form? Enter Edge AI and Privacy-preserving AI . By leveraging Transformers.js and WebAssembly (WASM) , we can perform complex Named Entity Recognition (NER) to de-identify sensitive information directly on the client side. In this tutorial, we’ll build a "Privacy Shield" that detects and masks names, locations, and health identifiers before they ever hit your API. The Architecture: Privacy First 🏗️ The traditional approach involves sending raw text to a server-side LLM or NLP service. Our approach intercepts the data at the "Edge" (the browser). graph TD A[User Inputs Sensitive Health Data] --> B{Browser-side Privacy Shield} B --> C[Transformers.js / WASM] C --> D[NER Model Analysis] D --> E[Data Masking / Redaction] E --> F[Clean Data] F --> G[Cloud Storage / Analytics] G -.-> H[Compliance & Security ✅] style B fill:#f9f,stroke:#333,stroke-width:2px style C fill:#bbf,stroke:#333,stroke-width:2px By using WebAssembly , we get near-native performance for running BERT-based models in the browser, ensuring the UI remains snappy while keeping the data 100% local. Prerequisites 🛠️ To follow along, you'll need: Tech Stack : TypeScript, Vite, and Transformers.js . Basic understanding of NER (Named Entity Recognition) . A passion for not getting sued for data leaks. 🥑 Step 1: Setting up the Privacy Pipeline First, let's install the library: npm install @xenova/transformers Now, let's create our PrivacyShield service. We will use a lightweight NER model (like Xenova/bert-base-NER ) that has been optimized for the web. // src/services/privacyShield.ts import { pipeline , env } from ' @xenova/transformers ' ;

A message landed in my inbox a few months back. New scope, same title. Frontend, backend, and QA, folded into one role, because the team now had AI to cover the rest. I had shipped backend work for years. The frontend half of our codebase, and the QA half, I had barely touched. Reading someone else's frontend patterns for the first time, at speed, with a deadline attached, is its own skill and I did not have it yet. I said yes anyway. Has your role quietly grown a second and third job inside it Not a promotion. Not new headcount. The same title, the same paycheck window, and suddenly three disciplines expected of one person because a tool now sits in the gap where two teammates used to be. I want to be honest about what that gap actually feels like from the inside, because most of what I read about this treats it as a spreadsheet problem. It is not. It is a specific, physical kind of tired that shows up on a Tuesday when you are debugging a CSS layout you have no instinct for, at 6pm, after a full day of the work you actually trained for. The tool covers the syntax, not the judgment AI got me through the mechanical parts fast. Flexbox, a broken build step, the shape of a test file I had never written by hand. Genuinely fast. I could paste an error and get a plausible fix in under a minute. What it never gave me was the judgment for when the plausible fix was wrong for THIS codebase, and why this component was structured the odd way it was. Whether a generated test actually proved anything, or only made the red X turn green. That judgment only comes from having broken things in that specific layer before, and I had never broken anything in QA before, so I had none. The tool closes the syntax gap instantly. It does nothing for the judgment gap. Those are different gaps, and conflating them is where I think a lot of the current AI-productivity optimism goes wrong. What actually closed it, and what did not Reading transcripts of AI-assisted changes other people made in

Recently I went looking for a CLI tool to manage my Dev.to articles from the terminal. I write 4-5 articles per month, track analytics obsessively, and wanted a git-backed workflow. I found 9 existing tools. Tried them all. Here's what happened: devto-cli (Node): Last commit 2 years ago. Broke on install. dev-to-git (Node): Only syncs TO local. Can't push back. slinkity : Abandoned. forem-cli : 3 endpoints implemented out of 40+. Every single tool does the same thing: publish an article. That's it. Maybe pull. Maybe validate tags. Meanwhile the Dev.to API has 40+ endpoints including analytics, semantic search, ML-powered content concepts, follower engagement, trend tracking, and reading list management. Nobody uses them. So I built devpub . Table of Contents What devpub does What I discovered in the API The build story Architecture Try it Contributing What devpub does (that nothing else does) # The basics (every tool does this) devpub push -f articles/my-post.md devpub pull # Analytics in your terminal devpub stats # Views: 246.5K | Reactions: 4.4K | Comments: 402 | Followers: 18.9K # Full dashboard with top articles devpub dashboard # AI-powered search (semantic, not keyword) devpub search "building serverless apps" --semantic # What's trending RIGHT NOW devpub trends # Catch problems before publishing devpub validate The difference isn't one feature. It's coverage. Here's the comparison: Capability devpub Everyone else Publish/update articles Yes Yes Pull articles to local Yes Some Analytics (7 endpoints) Yes No Semantic search Yes No Trend discovery Yes No Article validation Yes No Rate limiting (30 req/30s) Yes No Retry logic for failures Yes No Concepts API (ML topics) Yes No What I discovered in the Dev.to API While building devpub, I found several API endpoints that aren't documented anywhere obvious: 1. Semantic Search -- Dev.to has a full embedding-based search system using Gemini embeddings (768-dimensional vectors) with pgvector. You can search articles b

Job hunting is exhausting. Between tweaking resumes, updating portfolios, and filling out endless...

Às vezes, a maior barreira para começar um projeto não é a complexidade do problema, mas a busca por...

Every esports team captain has done this by hand at least once: open Discord, scroll through a dozen "I can play Thursday after 8" messages, cross-reference them against who plays Tank versus DPS, remember that one of your DPS is actually a sub, and try to assemble a starting five that can actually scrim tonight. It takes fifteen minutes, you get it slightly wrong, and you do it again the next day. I build Supatimer , a free Discord bot for competitive gaming teams, and "generate the lineup for me" was the single most requested feature. This post is about how the lineup optimizer actually works, why it is genuinely AI (and not in the marketing sense), and where a large language model fits in versus where it absolutely does not. "AI" is doing a lot of work in this industry Half the Discord bots on the market slapped "AI" on their landing page the week ChatGPT launched. Usually it means there is a chatbot command somewhere that proxies to an LLM. That is fine, but it is not what your team needs when it is 7:45pm and you have a scrim at 8. There are two honest definitions of AI worth separating: Search and optimization - the classical branch. Constraint satisfaction, combinatorial optimization, planning. This is the part of AI that solves "given these rules and these resources, find the best valid arrangement." Machine learning / LLMs - the statistical branch. Pattern recognition, generation, extraction from unstructured text. The lineup problem is squarely a problem for the first kind. So that is what I built first. The lineup problem, stated precisely Strip away the gaming context and a lineup is a constrained assignment problem: You have N players , each with a set of roles they can fill (Tank, DPS, Support, IGL, and so on). Each player has an availability signal for a given time block (available, maybe, unavailable). Each player has a roster status (starter, substitute, trial). The game defines a required composition : Overwatch 2 wants 1 Tank, 2 DPS, 2 Support. Va

Picture a young software developer sitting in a small, dimly lit room in Tehran. He has no political ambitions, no connections to the state apparatus, and no desire to break any domestic or international law. He wants to do something profoundly ordinary: build a small piece of software, refine his code, and offer it to the world using the same AI-driven development tools that his peers in Berlin, Toronto, or Tokyo take for granted. He opens his browser, clicks on a U.S.-based AI platform, and is immediately greeted by a cold, automated refusal: "Access from your region is restricted." In that single, unyielding moment, a door to the global community slams shut in his face. He has not been accused of a crime. No tribunal has judged him. No regulatory body has flagged his name. He is locked out simply because of where he was born and where he draws breath — a geographical reality he did not choose and cannot alter. The Asymmetry of Sanctions: How the State Circumvents While Citizens Suffer The tragic absurdity of this system lies in who actually bears the pain. Broad economic and digital sanctions are nominally designed to pressure and isolate a government. In practice, however, the targeted state mechanisms possess vast institutional wealth, specialized intelligence networks, and endless financial resources that render these restrictions practically useless against them. When the Iranian government or state-linked entities need to bypass international sanctions, they deploy a deeply entrenched, highly sophisticated network of circumvention tools: Front and Shell Companies: Establishing complex layers of paper companies in regional commercial hubs — such as the UAE, Turkey, Oman, or Eurasia — with clean, local ownership structures that mask the true state beneficiaries. Proxy Banking & Intermediaries: Utilizing specialized financial conduits and foreign bank accounts registered under these shell entities to route payments globally without triggering compliance alerts.

This is a submission for Frontend Challenge - Comfort Food Edition, CSS Art. Inspiration Comfort...