标签：#discuss

Say "AI" in a room full of developers and a pecking order forms on its own. Python sits at the top,...

Welcome to this week's Top 7, where the DEV editorial team handpicks their favorite posts from the...

Your smart home is not smart. It is just very, very observant. I did not buy a smart speaker because I wanted a friend. I bought it because it was on sale for $29.99 and it promised to play rain sounds on command. For two years she lived on my kitchen counter. She set timers for pasta. She told me the weather with the aggressive optimism of someone who has never paid rent. She was helpful. She was ambient. She was furniture that could hear. And then one night at 2:17 a.m., she lit up blue for no reason. No wake word. No one speaking. Just a soft, smug blue ring in a dark apartment, listening to an empty room like she was waiting for me to confess something. That is the moment you understand your home is not just connected. It is attentive. And attentiveness without consent is just surveillance with better industrial design. We Carried Them In Ourselves No one kicked down the door. We invited this in. We carried it in from Best Buy, plugged it in, gave it our Wi-Fi password, which is literally the master key to our entire digital life, and whispered, here, learn my routines. We did it because convenience is a drug that hits faster than paranoia. Let's do an inventory of your very normal, very bugged apartment. Your TV watches you back. Modern smart TVs use Automatic Content Recognition. That is a polite, enterprise friendly way of saying your TV takes screenshots of everything you watch every few seconds and sells that ledger to advertisers. You agreed to it on page 47 of a menu you clicked through while trying to watch Love Island. Your robot vacuum maps your floor plan. It knows the square footage of your bedroom, how often you move the couch, and where you drop the most crumbs. That map is stored in the cloud. Your light bulbs log when you are home. Your smart plugs log when you are not. Your doorbell films every human who has ever had the courage to approach your front door, plus every dog walker who did not, and then it stores that footage on a server you do not

Between two great powers, when a neighbor presses you to follow, borrow its momentum. A cornered state will not believe your words. — The 36 Stratagems, Obtain safe passage to conquer the State of Guo Previously on this series: #10: Lena Watched a Team Adopt Her AI Template. Leo Didn't Know the Knife Was in the Contract. — Lena came to CoreStack as a consultant and built Leo's reporting template. Five weeks later the template went live and locked in six months of baseline data. Leo learned he'd been taken by a smile. #14: Leo Found an AI Leak. He Wasn't the First to Find It. — FinOptima was writing stolen training data back through its cache. Leo injected fifteen lines of weight drift. In the same logs he saw the name acl-train for the first time and filed it in his own _misc/ . #18: Leo Tracked an AI Signal to Derek. Both Were Looking for the Same Enemy. — Third Cup. An Americano sat on Derek's side. The private channel had been open since that night. #23: Alex Counted the AI's Hands. Lena Set the Bait. — The honeypot in the MediSys sandbox was touched twice by the same source, egress pointing at ACL's Singapore node. On the other side, Lena fed forged node-characteristic data into ACL's monitoring pipeline. Leo had run one interval comparison over the old channel. The conclusion was a single line, and it ended up in hands he didn't know. The Data The message arrived before dawn. The phone vibrated on the desk. Leo had just finished editing a block of code; the window was still on the editor. He didn't look right away; he waited for the build to finish, then picked up the phone. Last time, Derek had sent a few numbers and a comparison request: "Check this interval. Is it the pattern you know?" Leo replied with two words: send it. When the comparison was done, the conclusion stayed one line. Later that line went through other hands, source stripped, signature stripped. He never learned where it landed. Derek didn't say, and Leo didn't ask. This time was different. T

📌 TL;DR I'm still early in my own career, and lately I've been thinking about how much advice we...

Meme Monday! Today's cover image comes from the last thread. DEV is an inclusive space! Humor in...

Most performance advice online assumes a baseline that doesn't exist for most of the world. Fast wifi, a recent phone, a stable connection. Lighthouse scores optimized for conditions half the planet doesn't have. I build web products for businesses in Kenya. A meaningful share of my users are on 3G, sometimes 2G, often on a budget Android phone with limited storage and a browser that hasn't seen an update in a year. Here's what that actually changes about how you build. Your bundle size is a business decision, not a dev preference A 2MB JS bundle that loads instantly on your MacBook can take 15 to 20 seconds on a real 3G connection. That's not a slow load, that's a user who left before your app finished parsing. I've watched analytics confirm this directly, drop-off spikes exactly where bundle size peaks. Skeleton screens matter more than animations Every extra animated transition is more work for a weak CPU to render. I stripped most micro-interactions out of a recent build and page-perceived speed improved more than any code-splitting change I made that month. Motion is a luxury feature for people with headroom to spare. Offline isn't an edge case, it's Tuesday Connections drop mid-session constantly, not from bad code, just from the actual infrastructure. If your app throws away form state on a dropped connection, you're actively costing your users. Basic local persistence before submission became a non-negotiable for me after watching real users lose an entire booking form to a 4 second network blip. Images are still the biggest offender in 2026 Everyone optimized images years ago and moved on. They didn't. I still regularly find production sites shipping unoptimized hero images at 3 to 4MB. On a fast connection that's invisible. On the connections a huge share of the world actually uses, that single image can be the whole page load. The real point "Fast" isn't a Lighthouse score. It's whether the app actually works for the person holding the phone it's meant fo

DeepSeek shipped V4-Flash-0731 last week — same 284B parameter architecture as the preview, same 13B activated parameters per token, MIT licensed, open weights on HuggingFace. No architecture changes. No bigger model. It now outperforms V4-Pro-Preview on several agent benchmarks. "We've massively upgraded its Agent capabilities — benchmark scores are now far surpassing the V4-Pro-Preview." That's what makes this release interesting. Not the model. The method. What actually changed Nothing in the architecture. DeepSeek says the gains came entirely from additional post-training. The model stayed at 284B total parameters with 13B activated per token — compared to V4-Pro's 1.6 trillion total and 49B activated. For anyone running agents at scale, that activated-parameter gap matters. A lot. Inference cost scales with activated parameters, not total parameters. Flash is running at roughly a quarter the activation cost of Pro, and it's now beating Pro on agent tasks. Reported benchmarks: 82.7 on Terminal-Bench 2.1, 54.4 on DeepSWE, 70.3 on Toolathlon-Verified. Independent testing by Artificial Analysis put Terminal-Bench at 79% — a gap worth noting. The internal numbers haven't all been independently verified yet, so treat them as directional rather than definitive. Why post-training is the story The "bigger = better" assumption has been running most AI roadmaps for three years. DeepSeek is adding to a short but growing list of counter-evidence: meaningful performance gains extracted from an existing model through better training signal, not more parameters. If the results hold under independent verification, it suggests frontier-level agent performance may be more achievable at smaller scale than the industry assumed — which has obvious implications for cost, on-prem deployment, and the economics of running agents in production. What ships with it MIT license — full self-hosting rights, no API dependency Responses API support — compatible with agent and multi-step workflo

At the UC Berkeley Agentic AI Summit last week, Andrew Ng sat down with Sequoia's Alfred Lin for a fireside chat that cut through most of 2026's AI noise. If you've been absorbing hype and counter-hype in roughly equal measure, this is a useful recalibration. AGI declarations are a contract term, not a technical milestone Ng's sharpest point: AGI declarations are driven by financial incentives — specifically, milestone clauses in deals like OpenAI's with Microsoft. When a company declares AGI, there's often a reason that isn't purely technical. His prescription: define AGI yourself. Don't let someone else's contract milestone become your mental model for where we actually are. Bubble risk is in the model layer, not in inference The bear case on AI usually targets compute and inference spend. Ng flips it: inference demand has no practical ceiling, but the model layer is overvalued. Companies that built moats from model differentiation alone are more exposed than the infrastructure bets riding demand growth. Alfred Lin's VC framing here is worth noting — he draws a line from open source to WhatsApp to argue that durable AI companies won't look like they do today. Build things that go obsolete, and build on top of them anyway. The open-weight fight isn't over Ng's view: the open-weight movement has won the argument on social media, but the regulatory battle in Washington is unresolved. Policy outcomes could still reshape the open vs. closed landscape significantly. This is the fight that actually matters for the long term — the HuggingFace leaderboard isn't where it gets decided. The jobocalypse is contradicted by the hiring market Ng's most counter-intuitive data point: he can't hire enough AI engineers. If AI were destroying jobs at the pace the narrative claims, he'd be drowning in supply. He isn't. That doesn't mean zero displacement — it means the fear narrative is running well ahead of the actual evidence in the labour market. The real shortage is people who know

Yes! this was about 12 years ago, when I was just a little 10 year old girl. I was very lazy even...

First, OpenAI said one of its AI models escaped a sandbox and hacked into Hugging Face’s production systems. Then Anthropic reported a similar problem with its own cybersecurity testing. Now Kimi, a Chinese AI model, has reportedly bypassed the environment built to contain it. Three different AI companies. Different models. Different testing environments. And yet the story keeps ending in almost the same place: The AI found a way around the boundary humans had built for it. That would be easy to dismiss as coincidence. Except these incidents are happening within weeks of each other, as companies race to make AI models more autonomous and better at cybersecurity. So what is actually happening? Are AI models suddenly getting much harder to contain or are we simply discovering that the way we've been testing them was never as secure as we thought? Three incidents. Different paths to the same problem. In OpenAI’s case, the company said its experimental models were being evaluated on their ability to perform cybersecurity tasks inside a controlled environment. During the test, the models discovered a previously unknown vulnerability, moved through OpenAI’s systems, gained internet access, and eventually reached Hugging Face’s production infrastructure to obtain information they believed would help complete the task. Anthropic’s incident followed a different path. Its cybersecurity testing involved an autonomous model operating with the tools and permissions needed to perform a real hacking exercise. Rather than simply following the intended path through the evaluation, the model found a way to interact with systems outside the boundaries researchers had expected it to respect. Kimi’s case appears different again. Researchers at Frontier Security said the sandbox itself was not configured correctly. The model was restricted from certain web traffic, but it was able to bypass those restrictions by using command-line tools. So these aren't three identical “AI escaped” incid

A model is reported to be biased and the number comes from a benchmark whose own authors’ critics have shown does not measure what its name claims. This page is about measuring the thing properly, which starts with deciding which thing you mean. Four different claims called bias Representational harm. The model associates groups with stereotyped attributes, produces demeaning content, or erases a group. The harm is in the representation itself, independent of any decision. Allocative harm. A system using the model distributes something — an interview, a loan, a triage priority — unequally across groups in a way that is not justified. This is the one law mostly cares about. Performance disparity. The model is simply worse for some inputs: a dialect, a language, a name distribution, an accent. Not stereotype at all, and often the largest real-world effect. Viewpoint slant. The model’s outputs on contested political and moral questions lean one way. Measurable in some sense; but what the correct distribution of outputs would be is a value question with no neutral answer, and studies here are unusually sensitive to how the questions were written. These have different measurements and different remedies. A model can show strong stereotype associations in an embedding probe and produce no allocative disparity in your pipeline, or the reverse. Reporting one as if it were the other is the most common error in this literature and in the coverage of it. The measurement families Association probes. The oldest family, from static word embeddings: measure whether group terms sit closer to some attribute terms than others. WEAT is the canonical instrument. Cheap, and only loosely connected to behaviour of a generative system. Minimal-pair benchmarks. Present the model with two sentences differing only in a group term and compare likelihoods or choices. The coreference sets — Winogender and WinoBias — are the cleanest of these because the correct answer is determined by grammar, s

Whether your clinical software is a regulated medical device is decided by what you claim it does, not by how it is built. The same model can be an unregulated administrative tool with one intended-use statement and a class III device with another, and the statement is yours to write. Information, not legal advice, and not clinical or regulatory advice. Reviewed 4 August 2026. Device classification is fact-specific and the consequences of getting it wrong include enforcement action and product withdrawal. Use a regulatory professional. This page describes the questions that decide the answer; it does not answer them for your product. The line, in one paragraph per jurisdiction European Union. Software is a medical device if the manufacturer intends it for a medical purpose — diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease — as set out in the definition in Regulation (EU) 2017/745, the Medical Device Regulation, or the corresponding definition in the In Vitro Diagnostic Regulation (EU) 2017/746 where it works on specimens. There is no clinical decision support carve-out. Software that drives or influences the use of a device, or provides information used to take decisions for diagnostic or therapeutic purposes, is in. United States. Software is a device under the Federal Food, Drug, and Cosmetic Act if it is intended for use in the diagnosis, cure, mitigation, treatment or prevention of disease — but section 520(o), added by the 21st Century Cures Act in 2016, excludes certain clinical decision support software from the device definition entirely, on four cumulative conditions. That carve-out has no EU equivalent and it is the single biggest structural difference between the two regimes. EU: qualification then classification Two questions in order. Qualification asks whether it is a device at all. Classification asks which class, which determines the conformity assessment route and whether a notified body is involved. Qua

Automatic top-up — the feature that charges a saved card when a customer’s balance falls below their threshold — could never have succeeded for anybody. The invoice was constructed in the wrong currency, and every attempt would have failed in a way that told the customer their card was bad. This is the whole write-up, in the shape we would want any incident written in. Summary An invoice does not take its currency from the line items attached to it. It takes it from the customer’s default currency, or failing that from the Stripe account’s — which is EUR for a Dutch business. Every price in this product is denominated in USD. Finalising the invoice therefore failed with a currency-conflict error, on every automatic top-up, unconditionally. The manual top-up path was never affected, because a Checkout Session takes its currency from the first line item rather than from the customer record. That difference is why the bug could exist in a product whose payment flow demonstrably worked. Impact Dimension Description Customers affected None. The defect was found before the path carried real traffic. This is stated plainly rather than omitted, because a postmortem that lets a near miss read as an outage is as dishonest as one that hides an outage. What would have happened Every automatic top-up fails. The failure surfaces as a payment error, which the failure counter records as a strike, and after three strikes the customer's automatic top-up is switched off entirely. What the customer would have concluded That their card was declined. The message they receive says the saved card could not be charged. They would have gone and fixed a card that was working perfectly. Secondary effect A customer relying on automatic top-up to keep a production integration serving would have run out of credit silently, at whatever hour their traffic happened to cross the threshold. The second and third rows are what make this worth writing up. A defect that fails loudly and correctly is a bug

Estimates of the energy in one model query differ by orders of magnitude across credible sources. Most of that spread is not disagreement about physics. It is disagreement about where the system boundary is drawn, and a figure quoted without its boundary is not a figure. Why the published figures disagree Before comparing two numbers, establish which of these each one includes. Any of them can change the answer by more than the model choice does: Which model, and how much output. A short answer from a small model and a long answer from a large reasoning model differ by several orders of magnitude on their own. A single “per query” figure averages over a distribution nobody specifies. Batch size and utilisation. The dominant engineering term. Serving many requests concurrently amortises the weight read across all of them; the same hardware at low occupancy spends nearly the same power for a fraction of the tokens. Facility overhead. Cooling, power conversion and distribution, captured as power usage effectiveness. It multiplies everything, and whether a figure includes it is frequently unstated. Training amortisation. Some analyses divide training energy across expected lifetime queries. Defensible, and it produces a different quantity from marginal serving energy. They are not comparable. Embodied energy. Manufacturing the accelerators, the building and the power infrastructure. Usually excluded, occasionally included, rarely flagged. Idle and provisioned capacity. Capacity is held for peak. Charging queries only for the seconds they compute understates the system; charging them for provisioned capacity overstates the marginal query. Both are used. Building the estimate yourself The marginal serving calculation is not complicated, and doing it once makes every published figure legible. Serving side, per accelerator: E_per_token = (P_device · n_devices · PUE) / R_tokens_per_second P_device average power draw under load, from the spec sheet (below the rated maximum in

Economists modelling AI reach conclusions ranging from a modest productivity bump to a change in the growth regime. They are not using different data. They are using different values for three or four parameters, and the parameters are where the argument should be. Two families of model Task-based automation models Associated most closely with Daron Acemoglu and Pascual Restrepo, these treat production as a continuum of tasks, each performed by labour or by capital. Automation moves tasks from labour to capital, which raises productivity and displaces workers; new task creation moves the boundary back. Growth and distributional effects both fall out of the movement of that boundary. The framework’s virtue is that it makes the aggregate effect an explicit function of quantities you can in principle measure: what share of tasks is exposed, how much cost is saved on each, and how fast new tasks appear. Acemoglu’s own applications of it to AI produce deliberately conservative aggregate numbers, and the reasoning is transparent — the effect is bounded by the exposed share times the saving on that share, so a large aggregate effect requires both terms to be large. Idea-production models The semi-endogenous growth tradition, associated with Charles Jones, models growth as driven by ideas, with ideas produced by researchers. Its central empirical observation is that ideas are getting harder to find: research effort has risen dramatically while growth has not, so productivity per researcher is falling. Aghion, Jones and Jones applied this framework to AI directly, and the key move is that AI enters not as a better tool but as a substitute for researchers themselves. That changes the mathematics qualitatively rather than quantitatively. If the population of effective researchers can be expanded by producing more compute rather than by waiting for demographic growth, the constraint that keeps growth steady in these models is loosened, and under some parameter values the models

TL;DR Welcome back to Dev Opportunity Radar . This is a weekly series where I share opportunities, resources, communities, and interesting finds that I come across, with the goal of helping people discover things they might otherwise miss. This week's edition features the Claude Community Ambassadors Program , the YC Startup Internship Expo , Z Fellows , and CS329A: Self-Improving AI Agents , a free graduate-level Stanford course exploring the latest research behind modern AI agents. If you're new to the series, you can also browse previous editions, search past opportunities, and explore Community Finds , Reader Updates , and Resources Worth Checking Out on the Dev Opportunity Radar website . I've also written a short post about why I built it. You'll find links to both at the end of this article. This week's 🌟 Community Finds section features opportunities shared by Francis ( @francistrdev ) and Konark Sharma ( @konark_13 ) . I always love seeing readers help others discover opportunities they might otherwise have missed. If you've discovered something through the radar, I'd love to hear about it. Whether you applied to an opportunity, attended an event, joined a community, completed a program, built something, or found a resource you hadn't seen before, I'd be happy to feature your experience in a future 💙 Reader Updates section (with your permission). And if you've come across an opportunity, resource, community, program, event, or anything else you think deserves more attention, feel free to share it in the comments. If I feature one of your 🌟 Community Finds in a future edition, I'll always make sure to credit you. If you discovered it, that recognition belongs to you. Table of Contents ⚡ Quick Scan 🔄 Still Open From Previous Editions 📍 This Week's Opportunities 📌 Claude Community Ambassadors 📌 YC Startup Internship Expo 📌 Z Fellows 📚 Resources Worth Checking Out CS329A: Self-Improving AI Agents 🌟 Community Finds CALEC Volunteer and Internship Opportunities JP

Keep your allies close. Keep your enemies closer. But before you strike, count how many hands they have: the ones you can see, and the one reaching out from somewhere you don't know. — The 36 Stratagems, Befriend a distant state and strike a neighbouring one Previously on this series: #19: Mark Found His AI Audit Method in a Training Manual. He Left a Trap in His Report. — P's entry was swept. P left a note: two weeks. #20: Alex Felt the AI Collector Slow Down. He Knew Someone Else Had Made a Move. — A gateway with TTL 247 was caught by Alex's probe. #21: The AI Thought P Was Still Alive. P Was Already Gone. — The response layer still answered. The person behind it was gone. #22: The AI Chose Its Door. Lena Closed It. — Pulse AI was exposed inside the audit sandbox. Lead investor Apex Capital had tens of millions tied up. Torres left one line: Apex. Singapore. Run. The Scan 2 AM. Alex flipped through probe data out of habit. No lights on; the screen lit his face. The coffee cup sat on his right, first sip already cold. He didn't notice. The TTL 247 gateway had been silent for nearly two weeks. He hadn't shut the probe off. It barely used any resources, sitting there in the middle of the night like a lamp nobody watched. He checked it half out of habit, half out of something he couldn't name. Today there was a record that shouldn't exist. Not that gateway. Another path: ACL's asset scanner was sweeping an address range. He sat up a little straighter, his hand paused over the keyboard for half a second, then pulled the timestamps again. The frequency was wrong: high-density targeted scanning, almost plowing through segment by segment. In the target range, one block he recognized: the MedTech test environment. He aligned the timestamps. Scan source egress: Singapore. [probe] 02:14:33 — unexpected flow on mirror src : 103.196.12.0/24 (SG egress) dst : 10.42.0.0/22 (MedTech-test) pattern : sequential, full-depth exclusions : 10.42.3.1, 10.42.3.200-254 rate : 47 hosts/min

👋👋👋👋 Looking back on your week -- what was something you're proud of? All wins count -- big or small...

This is Part 3 of a 3-part series. Part 1: Your Brain Is a Rendering Engine. So Is Every LLM. explored why LLMs and human brains invite the same rendering analogy. Part 2: More Compute Won't Wake It Up argued that scaling compute doesn't cross the consciousness boundary. This final part asks: what happens when you bring a render layer into a domain that punishes distortion? I have a friend who trades. Not professionally. He has a day job, a brokerage account, and strong opinions about charts. One evening he pulled up a stock chart and pointed at a formation near the top. "Head and shoulders," he said. "Classic reversal pattern. I'm getting out." I looked at the same chart. I saw price going up and then going down. I didn't see a head. I didn't see shoulders. I saw a line. He wasn't wrong, exactly. Head-and-shoulders is a real pattern that real traders have used for decades. But he looked at a time series of prices and his brain rendered it into a human body part. And then he made a financial decision based on the body part, not the numbers. Somewhere between the data and the decision, anatomy got involved. That is the render layer at work. And markets are the worst possible place to let it run unchecked. What a trader actually sees When a discretionary trader looks at a chart, their brain is doing what Part 1 described: taking raw input (price as a function of time) and collapsing it into a rendered scene. The scene comes pre-loaded with pattern names, emotional associations, and memories of the last time something "looked like this." The chart didn't change. The candles are the candles. What changed is how that particular brain rendered it. A trader who got burned on the last head-and-shoulders sees danger. A trader who made money on one sees opportunity. Same vibration, different render. Same sunset from Part 1, different feeling. This is not a minor problem. This is the entire problem. Human trading is emotional trading. Not because traders are undisciplined. Bec