标签：#discuss

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

🦄 Thanks @francistrdev for starting the conversation that really got me to thinking about this idea in the first place. I started truly working with AI shortly before I started writing these posts a little over a year ago. My thesis was simple at the time: prove that AI was far more capable a tool than what I had seen anyone using it for so far. My proof was strictly gut instinct and I spent a lot of time fighting with Copilot to prove I was right. Not all of those experiments went according to plan exactly, but I'm still convinced I'm right. That particular ADHD spiral has came and went, and most of it is ingrained as habit. I don't use Spec Kit because by the time it showed up I already had my own version running. I also need to get back to sharing what really works for me. So here we are again. Back to writing (with AI) and the proof to back it all up. One thing up front, because somebody is going to ask: everything here is personal projects and my portfolio . There's no critical prod system anywhere in this post, and if there were, a few of these answers would shift. Not all of them — I'd still let AI run a lot further off-leash than most of my enterprise counterparts would. 🐒 The Org Chart Has One Employee 🪧 I don't just use AI as a tool. I design it as a living system, and I grow the tech as the tech grows. I ran one prompt across Codex, ChatGPT, Claude Code, Cowork, and Gemini, all separately, and asked every one of them what was actually different about the way I work. Five different systems, each one with its own long history of putting up with me, and not one of them could see what the others said. One came back with this: I use AI to write code, review the AI-written code, review the review against the live branch, test the corrections, and then record whatever went wrong as a rule for the next AI. Apparently I recreated management. Most of the private exchanges quoted in this post came out of that same pile, whether they were my own prompts, my memory fi

On Monday I published a piece admitting that my deploy verification tolerates sixty seconds of "not there yet" for a reason I couldn't defend. Three retries, twenty seconds apart. I picked twenty because it was the first interval where my false alarms stopped, my sample was about three deploys, and I had never once recorded how long propagation actually takes. I made three commitments in that piece. A birth certificate for the constant. A rule fixed before the run it judges. And the one that mattered most: emit the value, not just the verdict — a check that prints only pass or fail hides the exact signal that would tell me it's miscalibrated. I did the third one that afternoon. Every deploy since writes down how long it took to go green. Three samples in: Aug 03 ( 1.7, 21.7 ]s Aug 05 ( 0, 6.7 ]s Aug 05 ( 40, 70 ]s They're intervals rather than points because my poll spacing is twenty seconds. All I can honestly say is that green happened somewhere between the last failed check and the first successful one — a number I can't resolve finer than my own instrument. The third one failed Not the deploy. The check. I shipped a post, ran verification, and got a clean red: page 404, hero missing, sitemap entry absent. Three attempts, twenty seconds apart, exactly as designed. By its own rules the deploy had failed. Nothing was wrong. A longer script came back 200 on everything. Total elapsed: somewhere between forty and seventy seconds, against a tolerance of sixty. So the false alarm I widened the interval to eliminate returned on the third recorded sample, four days after I published the sentence "my sample was about three deploys." I'd like to say I predicted this. I predicted the category, not the timing, and the timing is the part that stings. The part I hadn't considered at all Here's what the red actually said, in order: attempt 1 article 404 · hero missing · list page MISSING · sitemap missing attempt 3 article 404 · hero missing · list page OK · sitemap missing The

4-minute demo: AI agent investigates a P1 latency spike, sets up prevention automation, and documents tribal knowledge. Cost: $0.04 per incident.

For decades, desktop computers followed a familiar formula: a large case, powerful components, dedicated graphics cards, and plenty of space for upgrades. But the way we use computers is changing. Today, many users are looking for something different: a computer that is powerful enough for their daily needs, consumes less energy, takes less space, and can adapt to modern workflows. This is where Mini PCs are becoming one of the most interesting trends in personal computing. What is a Mini PC? A Mini PC is a compact computer designed to provide desktop-like functionality in a much smaller form factor. Unlike traditional desktop towers, Mini PCs integrate most components into a small chassis while still offering modern performance. A typical Mini PC includes: Modern processors from AMD or Intel Integrated Radeon or Intel graphics RAM and SSD storage Multiple connectivity options Compact cooling solutions Companies such as Minisforum have helped accelerate this trend by creating small computers powered by modern Ryzen and Intel processors, showing that compact hardware can still deliver impressive performance. Why are Mini PCs becoming popular? Efficiency matters more than ever One of the biggest advantages of Mini PCs is their efficiency. Traditional desktop computers can require significant power depending on the hardware configuration. In comparison, many Mini PCs provide enough performance for everyday tasks while maintaining lower energy consumption. For many users, reducing power usage without sacrificing productivity is becoming increasingly important. Small computers, new possibilities A smaller computer changes how we think about desktop setups. Mini PCs can be used for: Software development environments Home servers Media centers Student workstations Office computers Compact gaming setups A powerful computer no longer needs to occupy a large space on or under your desk. Modern processors changed the game The biggest reason Mini PCs are becoming more capable i

I keep seeing this same tension play out everywhere. TikTok, Instagram, X, all over the tech corners of the internet. It's the fight between software engineers and vibe coders, and tbh, I get both sides of it. Let me take the engineers' side first, because they're not wrong. If you spent four plus years learning to actually code, grinding the fundamentals, learning why the thing works and not just that it works, then yeah, I understand the frustration. Someone opens up Claude or ChatGPT, writes a prompt, ships their first app, and calls themselves a software engineer. And half the time, the second they hit a real problem, the whole thing falls over, because they don't actually know what's under the hood. I'd be a little annoyed too. And real talk, nothing replaces that depth. An engineer who can reach into the code, read it, and understand exactly what every line is doing is on a different level than someone vibe coding their way through. That's just true. But here's the part that sits weird with me. The problem isn't people using AI to build. It's when it turns into a wall. When the message becomes "you're not allowed in here, you don't get to build the thing in your head, because you didn't earn it the right way." That's the part I don't buy. I've watched this play out with my own friends. Engineers on one side, the ones just getting into vibe coding on the other, and there's this real contention between them. Almost a running joke about who counts and who doesn't. I think big ideas come first. The imagination comes first. Then you go find the resources, or the people, or the tools to actually build it. If someone has a huge idea and AI is the thing that finally lets them build it without waiting for permission, I don't see a problem. I see someone building. Gatekeeping who gets to make things never made much sense to me. You can respect the craft and still leave the door open. Those two aren't in conflict. Just my take.