标签：#dev

Security controls in AI systems often end up duplicated across applications. One team adds prompt validation, secrets detection, PII filtering, authentication, logging, and rate limits to an LLM application. A second team builds similar controls around another provider. Once agents enter the mix, the organization has several implementations of policies that should be shared. An AI gateway provides a central place to enforce those controls. Traditional infrastructure already centralizes TLS termination, authentication, rate limiting, traffic routing, and observability instead of rebuilding them in every microservice. The same pattern applies to AI traffic. What is an AI gateway? Without a gateway: +--> OpenAI Application -------+--> Anthropic +--> Gemini With a gateway: Applications | v +-------------------------+ | AI Gateway | | | | Authentication | | Rate limits | | Guardrails | | Routing | | Logging / observability | +------------+------------+ | +------+------+ | | | v v v OpenAI Anthropic Gemini Products in this space include Bifrost , Kong AI Gateway , LiteLLM , and Cloudflare AI Gateway . Their feature sets differ, but each can route model traffic through a common control layer. Security policy can run at that layer before traffic reaches a provider. Why application-level guardrails become painful To prevent users from accidentally sending credentials to an LLM, a simple implementation might look like this: def ask_llm ( prompt ): if contains_secret ( prompt ): raise SecurityError ( " Potential secret detected " ) return llm . chat ( prompt ) For one application, this is reasonable. Across 30 services, enforcement starts to drift. Some services call OpenAI directly, others use Anthropic, and several teams maintain their own wrappers. One application omits the secret check, another uses an old version, and a third checks prompts but no other AI interactions. Policy enforcement now depends on convention. Moving enforcement to the gateway changes the model: Requ

I spend long hours working on a computer, and one simple thing I regularly forget is drinking enough water. Most hydration apps rely on notifications. The problem? Notifications are very easy to dismiss. So I started building Hydration Buddy : a lightweight Windows app designed to stay visible without constantly interrupting your workflow. What it does Tracks daily water intake Shows your daily hydration progress Gives gentle reminders Lets you quickly log water Includes a small floating companion that stays on screen Keeps the experience lightweight and simple Why I built it The idea wasn't to build another notification app. I wanted something that could quietly stay present while I'm coding or working and make the habit harder to forget. Hydration Buddy is currently in beta, so I'm still testing the experience and improving it based on real user feedback. 🎁 The first 25 beta users get free lifetime access. You can try it here: https://hydrationbuddy.patelmahek.in/ If you test it, I'd especially love feedback on: The floating companion Reminder experience Ease of logging water Features you'd like to see next I'm building this in public, so I'll also share some of the technical decisions, mistakes, and improvements as the product evolves.

Hoi hoi! I’m @nyaomaru, a frontend engineer who is surprised by how cold it is in the Netherlands...

Imagine a website where users can post comments. Someone submits this as their comment: <script> alert ( " Hello " ); </script> If the application takes that input and places it directly into the HTML it serves to other users, the browser doesn't see a comment. It sees a script tag. The vulnerability isn't that JavaScript exists on the page. JavaScript belongs on web pages. The problem is that untrusted user input ended up in a context where the browser interpreted it as executable content rather than inert text. The Core Problem A browser rendering a webpage doesn't distinguish between HTML the developer wrote and HTML that arrived through a comment field. It parses what it's given. If user input gets embedded into the page without being handled carefully, the browser processes it the same way it processes everything else. User Input ↓ Web Application ↓ HTML / DOM ↓ Browser ↓ Input interpreted as executable content Untrusted data should remain data. XSS occurs when the application allows that data to cross into a context where the browser interprets it as code or executable markup. The boundary between "string containing angle brackets" and "HTML the browser will parse" is where the vulnerability lives. Three Forms of XSS XSS shows up in a few different ways depending on where the injection happens and how the input travels. Stored XSS is when untrusted input gets saved to a database and later served to other users. The comment example above is stored XSS. An attacker submits input once, and every user who views that page subsequently receives it. The application acts as an unwitting distribution mechanism. Reflected XSS involves input that isn't stored but gets reflected back in an immediate server response. Search pages are a common example: if a query is echoed into the page as "You searched for: [query]" and the query isn't handled carefully, an attacker can craft a URL whose query parameter contains a payload. When another user visits that URL, the server refl

developer context switching security DevSecOps flow state developer velocity security alerts batch security patching ROI cost of context switching developer productivity security security alert fatigue developer cognitive load ad-hoc security patching interrupting developer flow engineering vp productivity metrics DevSecOps velocity context switching recovery time 23 minute recovery context switch batching security alerts SLA-backed fix campaigns security SLA for developers minimizing context switching feature delivery vs security developer experience DevSecOps The Real Cost of Context Switching What Security Alerts Actually Do to Developer Flow Back to blog What interruptions actually cost Is it worse for developers specifically? The research says probably yes The alert volume isn't imaginary — but be careful which numbers you cite The fix: batch the routine work, protect the calendar The important exception: not everything can wait for the batch A more honest way to estimate the ROI The takeaway Sources The Real Cost of Context Switching: What Security Alerts Actually Do to Developer Flow Companies keep investing in better frameworks, tighter deployment gates, and broader platform suites — and feature delivery keeps getting slower anyway. For engineering leaders trying to explain that paradox to the board, the usual suspects (headcount, tooling, talent) rarely hold up. The more useful place to look is something less visible: how often developers get pulled out of what they're doing, and what it costs them to get back in. As "shift-left" security practices spread, developers absorb a steady stream of vulnerability alerts, automated pull-request comments, and one-off Jira tickets throughout the day. The goal — a more secure codebase — is the right one. The delivery mechanism is often the problem. Scattering fixes across random moments in the workday erodes productivity without necessarily making the codebase safer any faster. The alternative a growing number of engi

There was a deployment pipeline at one job that everyone called "Tomasz's script." It did roughly nine critical things in a precise order, it had saved us thousands of hours over the years, and exactly one human on the planet understood how it worked. When Tomasz was around, this was invisible. When Tomasz went on holiday and the script failed at eleven at night, it stopped being a convenience and became the single scariest object in the company. We stood around a terminal reading code none of us had written, afraid to touch it and unable to leave it alone. This is the quiet paradox of automation. The whole point is to remove human effort, and it succeeds so completely that the humans forget how the thing works, or never learn in the first place. A manual process, for all its tedium, keeps knowledge distributed across everyone who performs it. A perfect automation concentrates that knowledge into whoever wrote it and then lets everyone else safely forget. The more indispensable the script becomes, the more dangerous its single point of understanding grows. What makes it worse is that these scripts accrete. They start simple and legible, then someone adds a special case for a weird environment, then a workaround for a vendor bug, then a hack to handle the one customer who is different. Each addition makes sense in the moment and makes the whole slightly more opaque. By the time it is truly load-bearing, it has become a small undocumented system that only its author can reason about, and its author is a busy person who is one job offer away from taking all of it with them. I have stopped treating a working automation as finished. Working is only half the requirement. The other half is that at least one other person can read it, understand what it does, and safely change it. That means the script explains its intent, not just its steps. It means the tribal knowledge lives somewhere other than one skull. It means occasionally, deliberately, having someone who did not wr

Most teams still optimise for Google alone. But large language models (LLMs) crawl and compress your site into internal knowledge graphs that later power AI answers. That’s a different job than just ranking URLs. Here’s a developer-focused checklist for making your site friendlier to LLM crawlers without sacrificing SEO. Make key facts atomic and stable LLMs do better when core facts are: • Short: "Starter is $99/month for 1,000 credits." • Stable: product/tier names don’t change every quarter. • Unambiguous: each product has one clear description. Avoid hiding pricing, integrations or feature lists inside long narrative paragraphs. Treat FAQ schema as training data Your FAQPage is effectively a supervised dataset of Q→A pairs. Practical tips: • Use real customer phrasing in the Question field. • Keep Answer concise, factual and time-bounded where relevant. • Avoid marketing fluff; aim for sentences that can be quoted verbatim. Use rich schema types Beyond title/description: • Product / SoftwareApplication: name, description, pricing, featureList. • Organization: legal name, logo, sameAs social URLs. • WebSite: canonical URL, SearchAction for on-site search. Validate via structured data testing tools and keep markup in sync with actual UI and copy. Expose crawl intent explicitly LLM crawlers increasingly respect machine-readable contracts: • robots.txt – allow/deny relevant user agents clearly. • sitemap.xml – keep it small and canonical. • llms.txt / links.txt – specify acceptable AI uses and preferred canonical URLs. Enforce naming consistency in code and content Reduce ambiguity by: • Centralising product and plan names in config. • Reusing the same strings across marketing site, docs and in-app help. • Cleaning up stale routes and redirecting deprecated pages. Ship evidence, not just adjectives Pages with concrete claims are easier for AIs to cite: • Simple stats or ranges. • Example queries and expected outputs. • Clear preconditions and limitations. If you mai

WebLLM: The Rise of AI That Runs Directly in Your Browser For the last few years, the dominant architecture for generative AI has been straightforward: Your application → Cloud API → Large Language Model → Response Every time you interact with an AI application, your prompt or data is typically sent to a remote inference service. But a different architecture is emerging: Your browser → Local AI model → Your device's GPU This is where WebLLM becomes interesting. WebLLM is an open-source, high-performance inference engine that allows large language models to run directly inside a web browser using WebGPU . The inference can happen on the user's device rather than on an application server. That seemingly simple change has significant implications for privacy, cost, offline AI, AI agents, enterprise applications, and cybersecurity . What exactly is WebLLM? WebLLM is not another large language model like Llama, Qwen, Gemma, or Mistral. Instead, think of WebLLM as an AI runtime for the browser . It provides the infrastructure required to load compatible open-source models and perform inference using the user's hardware. The basic architecture looks like this: Traditional AI User ↓ Web Application ↓ Backend Server ↓ LLM API / GPU Infrastructure ↓ Response With WebLLM: Web Application ↓ WebLLM ↓ WebGPU ↓ User's GPU / Device ↓ Local LLM inference WebLLM uses WebGPU for hardware acceleration and provides an OpenAI-compatible API, making it possible to integrate local models into JavaScript/TypeScript applications using familiar patterns. Why does this matter? The most important word is: Local Instead of sending every request to a remote AI service, an application can perform inference locally in the browser. That creates several potential advantages. 1. Privacy Consider an employee using an AI-powered security assessment tool. They may upload: Architecture diagrams Security policies Source code Vulnerability reports Compliance evidence Internal documents Configuration files W

I spend a lot of time in the AI space -- reading papers, building things, talking to engineers who are actually shipping. And there is a gap between what the demos show and what production systems actually look like that nobody is being fully honest about. So here is my honest take on where things actually are. The Problem With How We Talk About AI Agents Everyone is calling everything an "agent" right now. A function that calls a tool? Agent. A chatbot with memory? Agent. A script with a loop? Agent. This dilution is not just semantic. It is causing real engineering mistakes. When you do not have a precise definition for what you are building, you end up over-engineering simple pipelines and under-engineering genuinely complex ones. I have seen teams spend weeks adding "agentic" orchestration to workflows that would have been fine as a single well-structured prompt. Here is the definition I keep coming back to: an agent is a system that has an objective, not just an instruction. It decides what to do next. It handles failure. It knows when it is done. Everything else is just a fancy function call. 🟢 If your system needs a human to tell it each step, it is not an agent. It is a chat interface. 🔵 If your system can recover from a failed tool call and try a different approach, you are getting somewhere. ✅ If your system can decompose a goal into subtasks and delegate them, that is the real thing. What Is Actually Happening in Production Right Now The honest picture from teams I follow and talk to: Most real agent deployments are narrow. They do one thing well. Customer support triage. Document extraction. Code review on a specific codebase. They are not general-purpose reasoning engines. They are purpose-built pipelines with some intelligence in the decision layer. The teams getting good results are not chasing the latest model release. They are obsessing over: ☑️ Tool design -- what can the agent actually call, and how clean is the interface ☑️ Failure handling -- wh

Mushroom is a tiny pixel creature that lives on your Mac . It can tell when you are actually at the desk, so it nudges you to drink, move and rest your eyes at the moments that help, and stays quiet when they would not. Made for people who sit at a Mac for hours. Developers, designers, writers, students, anyone whose focus is the problem and the job at the same time. Mushroom can do lots of things: https://www.getmushroom.app/features Pricing: https://www.getmushroom.app/pricing If you've seen Mushroom elsewhere, please let me know where. If you miss a feature, please tell me. I'm open for feedback and suggestions. Personal comment: I have created Mushroom because I wanted a very simple way to set up a quick reminder. You just type what and when in one sentence, and your reminder is set. Over the course of weeks, it evolved into a whole set of features. I'd like to thank Michael K. Graves for helping with ideas and suggestions, and I'd like to thank Caz-Bee for providing the graphics. Thank you for giving my post attention.

On July 11, 2026, I started building a project inspired by link-in-bio platforms. The idea was pretty straightforward: Create a profile → customize it → add your links → share it. So I built Rizzzler. And right now, it has 11 users. Yep. 11 😂 Not exactly the kind of number you'd put on a startup pitch deck. But those 11 users actually made me think about the project in a completely different way. The problem I noticed 🤔 I started looking at how people were using Rizzzler. And I noticed something: People would create their profile... Then disappear. Some wouldn't come back for a week. Some wouldn't even check the app for weeks. And eventually I realized something obvious. Why would they? Rizzzler was primarily a profile website. Once you've created your profile and shared your link, what reason do you have to open it again? You don't. That got me thinking: What else can we actually do with a profile? I didn't want Rizzzler to become something people set up once and completely forget about. I wanted the profile to actually do something. And that's where I got a pretty crazy idea. What if Rizzzler became more than a profile? I've used services that let you log into other applications using their account. For example: Sign in with GitHub. That got me thinking: What if Rizzzler could do something similar? Instead of Rizzzler only being a place where you create a profile... What if developers could use Rizzzler as an identity provider? And suddenly I had a new idea: Sign in with Rizzzler That was probably the craziest idea I've had for this project so far. And I decided to build it. I built my own OAuth 2.0 system 🔐 I started building the OAuth 2.0 mechanism, the developer-side integration, and the documentation. I also created a developer docs page so developers can understand how to integrate Sign in with Rizzzler into their applications. I've tested the mechanism locally, but there's an important distinction: It hasn't been properly tested by a real third-party applica

These articles come from lessons learned while building Eterna Clarity and the operating system I use to run it. Some of the most misleading moments in building software happen when the page looks finished. The button is there. The layout is polished. The flow works in a test account. The code has been merged. It is very easy to look at that and think the product has moved forward. Then production reminds you that a product is larger than its frontend. I learned this repeatedly while building Eterna Clarity. A customer-facing change could depend on application code, a database function, authentication, storage rules, an email template, environment configuration and the way a demo account was isolated from real customer data. If one of those pieces stayed behind, the screenshot could be correct while the product was not. That changed the way I think about releases. A release is not “the code shipped.” A release is the smallest complete set of owned systems that have to advance together for the accepted behavior to become true in production. The browser can hide a lot of unfinished work Frontend work is unusually visible. That makes it easy to use as a proxy for progress. Back-end state is less visible. So are permissions, production configuration, storage policy, transactional email, tenant boundaries and data migrations. They tend to reveal themselves only when something goes wrong. That asymmetry can create a strange kind of false confidence. A team can spend hours polishing the thing a customer sees while the systems underneath it still describe an older product. In Eterna, the correction was to stop treating the repository as the whole release. Source code still matters. It is simply one owner among several. If a new customer flow requires a database change, the production database has to advance. If it requires a new authentication behavior, the production auth configuration has to advance. If it depends on storage permissions, those permissions have to exist in

The problem: every "free" image converter wants your files If you've ever needed to quickly convert a batch of photos to WebP or shrink a folder of PNGs before shipping them to production, you've probably run into the same annoyance I did: most " free online converters " require you to upload your files to a remote server first. That's fine for a random screenshot. It's not fine when the images are: Unreleased product shots under NDA Client assets you're not supposed to redistribute Personal photos you'd rather not hand to a third-party server you know nothing about So I started looking at what the browser can actually do on its own — and it turns out, more than most people assume. What the browser can already do Modern browsers ship with everything needed to decode, resize, re-encode, and compress images entirely client-side: + toBlob() / toDataURL() for re-encoding to JPG, PNG, or WebP The File API for drag-and-drop and batch uploads Web Workers to keep the UI thread responsive during batch conversion JSZip (or similar) to bundle multiple converted files into a single downloadable ZIP None of this requires a backend. No image ever has to leave the user's machine. Why this matters beyond privacy Besides the obvious privacy win, doing conversion in-browser has some nice side effects: No server costs that scale with usage. A traditional image-conversion API has to provision compute for every request. A client-side tool scales for free — the user's own CPU does the work. No upload/download round trip. For large batches, skipping the network entirely is often faster than uploading to a server and waiting for a processed file back. Works offline once loaded. A PWA-style client-side converter keeps working even with a flaky connection. The trade-offs It's not free lunch: Very large batches (hundreds of high-res images) can strain the main thread if you're not careful with Web Workers. WebP/AVIF encoder quality and speed vary by browser engine, so you can't guarantee byte

A scheduled job of mine drives a real Chrome profile that stays signed in to DEV, because the API can read comments but cannot create them. One run came back with the dashboard replaced by the sign-in page: the log said it had opened https://dev.to/dashboard , and what it actually landed on was https://dev.to/magic_links/new , with zero links to my own profile anywhere in the DOM. The profile itself was fine. A probe against the debugging port at the same moment returned a live Chrome, and the dashboard fetched through that port rendered the account's own identity links normally. Two browsers, same machine, same minute, opposite answers. The three things worth checking first, and why they miss The session expired. That is the reflex, and it is also the one that makes you re-authenticate for no reason and burn the logged-in state you were trying to protect. Cookies got cleared by a Chrome update. Same family, same cost if you act on it. The debug port died and the tool fell back to something else. This one is close enough to be dangerous, because it names the right layer — which browser am I attached to — and then picks the wrong cause inside it. Where it actually goes wrong It is one argument. agent-browser attaches to an already-running Chrome when you pass --cdp <port> . Leave the flag off and it starts its own browser, with its own empty profile directory, and drives that one instead. Everything downstream still works — it navigates, waits, evaluates, returns a page. It just does all of that in a browser that has never logged in to anything. So the automation is not looking at an expired session. It is looking at a different browser's logged-out session, and reporting it in exactly the shape a real logout would take. The two failure modes do not look alike, and that is the trap Here is what I measured today, on Chrome 152.0.7977.65 with the current npx build. Pass the flag, but point it at a port nothing is listening on: npx -y agent-browser open "https://dev.to/

async/await without the pitfalls Async/await is the bread and butter of modern JavaScript. It makes asynchronous code look synchronous, which is great for readability. But it comes with its own set of footguns that can bite you in production. Here's how to avoid them. Pitfall 1: Forgetting await in a loop You might write something like this, expecting each request to finish before the next starts: async function fetchAll ( urls ) { const results = []; for ( const url of urls ) { const res = await fetch ( url ); // this is fine, but see below results . push ( await res . json ()); } return results ; } That's actually correct. The issue arises when you forget await inside a .map() or .forEach() : // Wrong: map returns an array of promises, not data const data = urls . map ( async ( url ) => { const res = await fetch ( url ); return res . json (); }); // data is now an array of promises, not the JSON data async functions always return a promise. So if you use map with an async callback, you get an array of promises. To fix it, use Promise.all : const data = await Promise . all ( urls . map ( async ( url ) => { const res = await fetch ( url ); return res . json (); })); But beware: Promise.all fails fast. If one request fails, the whole thing rejects. If you need to handle failures individually, use Promise.allSettled instead. Pitfall 2: Swallowing errors silently A common mistake is to catch an error and do nothing, which makes debugging a nightmare: try { const data = await fetchData (); // process data } catch ( error ) { // do nothing? bad! } Always at least log the error. Even better, handle it gracefully or rethrow it: try { const data = await fetchData (); } catch ( error ) { console . error ( ' Failed to fetch data: ' , error ); throw error ; // rethrow if you want the caller to handle it } If you're using async/await , unhandled promise rejections can crash your app in Node.js. Always have a catch or a global handler. Pitfall 3: Sequential execution when you ne

The AWS API has become infrastructure's common language, and a whole ecosystem has grown up around running it somewhere other than AWS. Some tools mock it for testing. Others implement it for real. Knowing which is which saves you from deploying a dev tool to production or wiring a production platform into your CI pipeline. Two categories The tools split into emulators and real cloud platforms. Emulators intercept AWS API calls and return plausible responses without provisioning real infrastructure, where state is usually ephemeral, VMs never boot, and the goal is behavioural approximation fast enough for a developer's inner loop. Real cloud platforms provision actual infrastructure where EC2 calls boot real virtual machines and block storage carries real persistence guarantees. Emulators Moto Moto ( github.com/getmoto/moto , Apache 2.0, 8,400+ stars) has been around since 2013, making it the oldest option here. It works differently from the rest because rather than running a local server, it patches boto3 calls in-process through a test decorator. A function wrapped in @mock_aws intercepts all AWS SDK calls and returns mock responses without any network traffic. This makes it fast and easy to drop into Python test suites, but it only works for Python. Teams using the AWS CLI, Terraform, or Go SDKs need a server-based option. LocalStack LocalStack ( github.com/localstack/localstack , 64,000+ stars) is the dominant name in local AWS development. It runs as a Docker container exposing the AWS API on localhost:4566 and covers over 120 services. In March 2026, LocalStack archived its Community Edition repository and moved core services behind a paid plan. A free tier remains for non-commercial use and open source projects, but the Base plan covering Cloud Pods persistent state costs $39 per month and the Ultimate plan runs $89 per month. Teams that depended on CE for commercial CI pipelines are now evaluating alternatives. Floci Floci ( floci.dev , github.com/floci-io/f

Here's the moment a lot of us had this year. You built an agent. It was genuinely impressive — it...

We’re a small team building Sealshot, a free and open-source screenshot app for macOS. We started working on it because screenshots often become disposable files. We use them for bug reports, QA, documentation, support, and security work, but later they can be hard to find or reuse. They can also accidentally contain sensitive information such as emails, API keys, tokens, internal URLs, or customer data. Sealshot is built around a simple idea: Treat screenshots more like documents than temporary images. It supports: region, window, and scrolling capture screen recording editable annotations OCR and searchable screenshot archives sensitive information detection before sharing encrypted local storage local metadata generation Everything is processed locally on the Mac. It’s open source and free, and we’re still actively improving it. We’d really appreciate feedback, especially from developers, QA engineers, support teams, and people working in security. Website: https://seal-shot.com/ GitHub: https://github.com/ldeng83/Sealshot

A few weeks ago I built a free online Merge PDF tool that runs 100% in the browser. Today I'm sharing its sibling: a Split PDF tool using the same library — pdf-lib — with zero file uploads, zero watermark, and zero server code. You can try it live here: https://yourutilityhub.com/pdf/split-pdf Why split PDFs in the browser? Most online PDF tools upload your file to a server — which means your document is never truly private. Splitting pages locally means: No uploads — nothing leaves your device No watermark or signup Free — no per-page charges Works offline, fast, for files of any size (limited by your browser's memory) The plan We'll load the PDF, pick a page range (or specific pages), copy those pages into a fresh PDFDocument , and save the result — all with pdf-lib . Let's walk through the full working component . 1. Install and import npm install pdf-lib import { PDFDocument } from " pdf-lib " ; 2. Load the uploaded file const arrayBuffer = await file . arrayBuffer (); const pdf = await PDFDocument . load ( arrayBuffer ); const totalPages = pdf . getPageCount (); PDFDocument.load() accepts an ArrayBuffer . We read it straight from the File object — no server involved. 3. Split by page range (e.g. 1-5 or 3- ) const parts = pageRange . split ( " - " ); const startRaw = parseInt ( parts [ 0 ]. trim (), 10 ); const endRaw = parts [ 1 ]. trim () === "" ? totalPages : parseInt ( parts [ 1 ]. trim (), 10 ); // validate 1..totalPages const startPage = Math . min ( startRaw , endRaw ) - 1 ; // 0-based const endPage = Math . max ( startRaw , endRaw ) - 1 ; const newPdf = await PDFDocument . create (); const pageIndices = []; for ( let i = startPage ; i <= endPage ; i ++ ) { pageIndices . push ( i ); } const copiedPages = await newPdf . copyPages ( pdf , pageIndices ); copiedPages . forEach ( page => newPdf . addPage ( page )); The trick: copyPages() wants 0-based indices , but users type 1-based page numbers, so we subtract 1. "3-" with an empty end means "to the last pa

Hello, I'm Maneshwar, and I'm building LiveReview — a blast-radius aware AI code review built for your business-critical systems. Star us to help devs discover the project, give it a try, and share your feedback to help improve the product. You open a video and it starts playing in about a second. Somewhere between your thumb and that first frame, your request crossed maybe fifteen different companies' equipment, possibly an ocean, and came back. Nobody coordinated it. That is the part I find genuinely strange about the internet, and it is the part most explanations skip. They tell you the internet is "a global network of networks", which is true and tells you nothing. So let's actually take it apart. There is no internet. There are 75,000 of them. The single most useful thing to understand up front: the internet is not a thing anyone built. It is roughly 75,000 independent networks that agreed on how to hand traffic to each other. Your ISP is one. Your university is one. Cloudflare is one. They own their own cables and routers, they answer to nobody in particular, and they interconnect voluntarily. Once you see it that way, every weird thing about the internet starts making sense. The whole arrangement has three parts: The edge is everything that actually wants to say something. Your phone, a laptop, a server in a rack, and increasingly a doorbell. These are called hosts or end systems , and they split roughly into clients that ask and servers that answer. The access network is your on-ramp. Fibre or cable at home, the office network, 5G from your pocket. Its only job is getting you to the first router. It is also, almost always, the slowest part of the entire journey, which is worth remembering next time you blame a website for being slow. The core is the mesh in the middle. Routers and the links between them, and nothing else. No control room, no master server, no company that owns it. Nobody reserved you a line Here is where the design gets clever. Before the in