标签：#webdev

Welcome to the fifth article in our OWASP Mobile Top 10 2024 series! In previous articles we covered M1: Improper Credential Usage, M2: Inadequate Supply Chain Security, M3: Insecure Authentication/Authorization, and M4: Insufficient Input/Output Validation. Today we discuss why "we already use HTTPS" isn't a sufficient answer. Introduction M5 is the most misleading item on the list, because most teams read it and move on: "We use HTTPS, this doesn't apply to us." OWASP's definition is far broader. This risk covers all aspects of getting data from point A to point B, but doing it insecurely. It encompasses mobile-to-mobile communications, app-to-server communications, or mobile-to-something-else communications. It includes all communications technologies that a mobile device might use: TCP/IP, WiFi, Bluetooth/Bluetooth-LE, NFC, audio, infrared, GSM, 3G, SMS, etc. So M5 isn't just "do you use HTTPS." It's all of this: Whether you set up TLS correctly (certificate checking, cipher selection) Whether your traffic is consistent (some endpoints HTTPS, others not) What your third-party SDKs are doing What your WebView is loading What you send over alternate channels like push notifications and SMS 💡 Key point: Just because an app uses transport security protocols doesn't mean it's implemented correctly. HTTPS is not a checkbox; it's a system that must be configured properly. A specific situation for React Native developers In React Native the network layer lives in three separate places, and most developers only think about the first: The JavaScript side — fetch , axios , XMLHttpRequest Platform configuration — ATS on iOS, Network Security Config on Android Native modules and SDKs — analytics, ads, crash reporting, payment SDKs Whatever you do on the JavaScript side, if platform configuration is loose or a third-party SDK uses plaintext HTTP, your app is exposed. OWASP Assessment Metric Value Meaning Exploitability EASY A proxy and the same network is enough Prevalence CO

React is fast by default, until it isn't. The good news is that the vast majority of real-world performance issues trace back to a small set of patterns. Fix those, and you rarely need exotic optimizations. Measure before you optimize The first rule of performance work is to never guess. Use the React Profiler and the browser's performance panel to find what actually renders, and how often. Premature optimization Wrapping every component in memo and every value in useMemo adds complexity and can make things slower. Optimize the hot paths you have measured, not the ones you imagine. Avoid unnecessary re-renders A re-render isn't inherently bad, but cascading re-renders of expensive subtrees are. The most common culprit is passing a freshly-created object or function on every render. `// ❌ A new array + handler every render breaks memoized children function ProductList({ products }) { return ( - p.inStock)} onSelect={(id) => track(id)} /> ); } // ✅ Stabilize derived data and callbacks function ProductList({ products }) { const inStock = useMemo( () => products.filter((p) => p.inStock), [products], ); const handleSelect = useCallback((id) => track(id), []); return ; } ` Memoize the right things React.memo , useMemo and useCallback are tools for keeping referential identity stable across renders. Reach for them when: a child component is expensive to render, and it receives props that would otherwise change identity every render. Better still, let the React Compiler handle memoization for you. Adding it is a single dependency: npm install babel-plugin-react-compiler Ship less JavaScript The fastest code is the code you never send. Code-splitting and lazy loading keep the initial bundle small. `import { lazy, Suspense } from 'react'; const Editor = lazy(() => import('./Editor')); export function Panel() { return ( }> ); } ` Move work to the server With React Server Components, data fetching and heavy rendering can happen on the server, shipping only the resulting HTML an

Web accessibility stopped being optional. The European Accessibility Act has been enforced since June 28, 2025, and it reaches any business that sells products or services to EU customers, regardless of where that business is based. In the United States, the Department of Justice's ADA Title II rule requires public bodies to meet WCAG 2.1 Level AA by April 2026, and private-sector lawsuits keep climbing every year. For a company shipping a website or app, that means a real deadline and real financial exposure. EAA penalties can reach 5% of annual turnover for large companies, and a single ADA complaint can cost tens of thousands to settle before you have fixed anything. The good news: the standard everyone points to, WCAG 2.1 AA, is well-defined and achievable. The bad news is that the most heavily marketed shortcut, the accessibility overlay widget, does not get you there and can make your legal position worse. This guide covers what the law actually requires, why the quick fix backfires, and how we build accessibility into a site from the start instead of bolting it on at the end. What the law actually requires Three names come up constantly, and they fit together cleanly. WCAG 2.1 Level AA is the technical standard. The EAA and the ADA are the laws that, in practice, point back to it. In Europe, meeting WCAG 2.1 AA satisfies the digital requirements of the harmonized EN 301 549 standard, which is how you demonstrate EAA conformance. WCAG is organized around four principles, known as POUR: content must be Perceivable, Operable, Understandable, and Robust. In concrete terms that means text alternatives for images, sufficient color contrast, full keyboard operability, visible focus states, labeled form fields, and markup that screen readers can parse. Level AA, not AAA, is the bar nearly every regulation references. Note the EAA exempts the smallest businesses, those under 10 employees and under two million euros in turnover, but that carve-out is narrower than most

Next.js gives you almost everything you need to rank well out of the box, and most teams still ship sites that Google struggles to read. The framework is not the problem. The problem is that SEO gets treated as a final checkbox instead of an architectural decision, so metadata ends up scattered, content renders on the client, and the structured data never gets written. The App Router changed how all of this works. The generateMetadata function, file-based conventions for sitemap.ts and robots.ts , and Server Components as the default each remove a class of SEO bug that used to be common in the Pages Router. But they only help if you use them deliberately. This is the playbook we follow when we build a Next.js site that has to rank, the same approach behind this site. It is opinionated and concrete: where to put metadata, which files to ship, how to handle structured data and multiple languages, and why Core Web Vitals is an SEO feature rather than a performance afterthought. None of it requires a plugin. Render on the server so Google sees real HTML The single biggest SEO win in Next.js is also the easiest to get wrong: make sure your indexable content is in the HTML on the first byte. Googlebot will execute JavaScript, but it does so on a delay and with no guarantees. Content that depends on a client-side fetch can be missed, indexed late, or indexed empty. Server Components are the default in the App Router, so this is mostly about not opting out. Keep 'use client' at the leaves of your tree, on the button that needs an onClick , not on the page that holds your copy. Fetch your data in the Server Component and pass the rendered result down. If you can view the page source and read your headline and body text without JavaScript, you are in good shape. Master the Metadata API instead of next/head In the App Router you never touch next/head . Every route exports either a static metadata object or a dynamic generateMetadata function, and Next.js merges and d

For fifteen years the goal of search was simple: rank on page one and earn the click. That contract is breaking. More people now ask ChatGPT, Perplexity, Gemini and Google's AI Overviews a question and read the synthesized answer without ever visiting a blue link. If your brand is not in that answer, you are invisible to them, no matter how well you rank. This is the gap Generative Engine Optimization closes. GEO is the practice of structuring your content and your site so that large language models retrieve it, trust it, and cite it when they answer a question in your space. It overlaps with SEO but it is not the same job. One study from the GEO firm Brandlight found the overlap between top Google links and the sources AI tools actually cite has fallen from around 70% to under 20%, and the gap is widening. The payoff is real, not theoretical. AI referrals convert far better than cold organic traffic because the visitor arrives pre-qualified by the answer that sent them. Vercel has reported that roughly 10% of new signups now come from ChatGPT, and LLM-referred visitors have been measured converting at 15.9% from ChatGPT against under 2% for typical organic search. Here is how we approach GEO for the sites we build. SEO earns clicks, GEO earns citations The mental shift is the whole game. Traditional SEO optimizes a page to win a position in a ranked list of links. GEO optimizes a passage to be quoted inside a generated answer. A model does not "rank" your page; it retrieves chunks of it, weighs them against everything else it pulled, and decides whether to repeat your claim and name you as the source. That changes what good content looks like. Models favor passages that are self-contained, factual, and quotable: a clear definition, a specific number, a direct answer in the first sentence. Burying the answer three paragraphs down, the way you might to keep a reader scrolling past ads, is exactly wrong here. Lead with the claim, then support it. Write so a model can

Next.js 16 is the biggest release since the App Router landed, and the upgrade is not a one-line bump. The caching model changed shape, params and searchParams are now promises everywhere, Turbopack runs your builds by default, and middleware.ts is on its way out in favour of proxy.ts . None of that is hard on its own. The trouble is that the changes touch almost every dynamic route in a real app at once, so a rushed upgrade tends to fail in a dozen small places rather than one obvious one. We run this site on Next.js 16, and we have moved client projects across the same gap. The pattern that works is boring and reliable: read the codemod output, fix the async APIs first, decide your caching strategy deliberately instead of letting the old implicit behaviour leak back in, then clean up the renamed files. This guide walks through that order, with the specific gotchas that cost the most time. If you are still on Next.js 13 or 14, the same steps apply, you just have more of them to work through. Run the codemod, then read what it could not fix Start with the official upgrade command. It pulls the right versions of next , react , and react-dom , and runs the codemods that handle the mechanical rewrites for you. npx @next/codemod@latest upgrade latest The codemod is good, but it is not magic. It will happily wrap your params access in await where the shape is obvious, and skip anything indirect, a params object passed into a helper, destructured two functions deep, or read inside a generateMetadata you wrote by hand. Treat the codemod as the first 80%, not the finish line. Once it has run, do a clean install and a type check before you touch anything else. With typescript.ignoreBuildErrors set, as it is on many projects, the build will not catch these for you, so run the type checker yourself. rm -rf node_modules .next && npm install && npx tsc --noEmit The errors that come back are your real to-do list. Most of them will be the async API change, which is the next sectio

Nuance is the thing that gets you levelled up, and hedging is the thing that gets you levelled down. They sound almost identical from the outside, and the difference is entirely structural. Ask a junior engineer whether to use SQL or NoSQL and you get an answer. Ask a senior engineer and you often get "well, it depends", which is correct, and delivered badly it costs them the round. The problem is not the nuance. It is the order. Hedging leads with the uncertainty and never arrives at a decision. Judgement leads with the decision and then shows the uncertainty around it. Same knowledge, opposite impression. Why hedging reads badly An interviewer is trying to answer one question: would I trust this person to make a call without me in the room. A candidate who lists options without choosing has actively failed to demonstrate the thing being assessed, no matter how well they understand the options. There is a second, less obvious cost. Refusing to commit removes the interviewer's ability to go deeper. They cannot probe a decision you did not make, so the conversation stays shallow, and shallow conversations produce mid-level scores by default. A candidate who says it depends and stops has told the interviewer nothing except that they know it is complicated. Everyone at this level knows it is complicated. The four-part structure This works for almost any technical choice you will be asked about, and it takes about twenty seconds to deliver. Commit. Name what you would actually ship. One sentence, no preamble. Justify. Give the specific reason, tied to the constraints in the question rather than to general virtue. Cost. Say what you are giving up. Every choice loses something and naming it is the seniority signal. Trigger. State the condition that would change your mind, and ideally what you would watch for it. Notice that all the nuance from "it depends" is present. It is simply arranged behind a decision instead of in place of one. Would you use a relational database o

Hello, I'm Maneshwar. I'm building git-lrc, a Micro AI code reviewer that runs on every commit. It is free and source-available on Github. Star git-lrc to help devs discover the project. Do give it a try and share your feedback. A couple of posts back we spent a while inside XOR distance , then used it to build Kademlia , the DHT algorithm that lets a network find anything without a directory. Kademlia: Algo That Turned XOR Distance Into a Network Athreya aka Maneshwar Athreya aka Maneshwar Athreya aka Maneshwar Follow Aug 26 Kademlia: Algo That Turned XOR Distance Into a Network # webdev # programming # beginners # algorithms 20 reactions Add Comment 6 min read I promised that algorithm shows up "under BitTorrent, IPFS, Ethereum." Today we cash that check. We're taking BitTorrent apart, piece by piece, and Kademlia is going to walk right back in through the side door. Also, fun fact before we start: a suspicious number of people on Reddit think Bram Cohen, the guy who wrote BitTorrent alone in Python in 2001, is secretly Satoshi Nakamoto. I'm not saying it's true. I'm saying that by the end of this post you'll understand why people keep saying it. The number that should not have been possible In 2004, a measurement firm called CacheLogic reported that BitTorrent alone was responsible for roughly 35% of all internet traffic. More than every other peer to peer network combined. More than the entire web. One protocol. Written by one guy. No company. No datacenter. No servers anywhere with "BitTorrent Inc" on the rack. That last part is the whole story. Every "normal" system you've ever worked on scales by throwing money at it: bigger box, more replicas, a CDN in front. BitTorrent had nobody to throw money at anything, so every hard problem, capacity, trust, scheduling, incentives, discovery, had to get solved inside the protocol itself . Problem 1: the client-server ceiling has a name Distributing a file in 2001 meant one server, one uplink, and every download eating

A ideia de um sebo que não perde estoque: No primeiro período, nosso grupo desenvolveu um Sebo Virtual. O objetivo era resolver a dificuldade de sebos tradicionais em conciliar estoque físico e virtual, com pagamento via PIX e envio de recibo por e-mail. Minha responsabilidade foi a engenharia de prompt utilizando o Lovable. Quando a IA não entendia o que eu queria: Os primeiros prompts retornaram resultados incompletos. Ao solicitar "explique o código por trás da aplicação", a resposta foi genérica e não detalhou a integração com o banco de dados. Também houve dificuldade em fazer a ferramenta compreender fluxos específicos, como leilão de itens, validação de cupons e cálculo de frete por CEP. O que mudou quando usei diagrama e contexto: O resultado melhorou quando passei a incluir contexto e artefatos. Três prompts funcionaram bem: para wireframe, enviei o diagrama e solicitei o protótipo das telas; para o leilão, pedi quatro telas com checkout e histórico de transações; para o back-end, solicitei as linguagens utilizadas e o fluxo de integração ao banco preservando as informações da documentação. Com isso, identifiquei a stack gerada: React com TypeScript no frontend e Supabase no backend, com consultas como from('pedidos').select('*').eq('usuario_id', id) . Do sebo para qualquer loja online: As regras implementadas, como cupons LIVRO10 e SEBO20, frete proporcional ao peso e checkout via PIX para o endereço base na Rua dos Livros, 707, João Pessoa, são aplicáveis a qualquer e-commerce de pequeno porte. O método permite transformar uma ideia em protótipo navegável em poucas horas. O que levo disso para a carreira? O projeto mostrou que, além do código, a capacidade de formular perguntas claras e organizar a documentação em fluxograma e diagrama de classes é fundamental. Foi meu primeiro case prático e base para portfólio na área de dados e produto. EN Summary: As a first-semester student, our team built a Virtual Bookstore to manage physical and online inventory w

Most "is this plugin safe?" advice is vibes. I wanted numbers, so I built a dataset. Here's what it found, and exactly how, so you can check my work or build your own. The finding first Of 8,010 WordPress plugins with a publicly documented vulnerability since 2023 (15,534 vulnerability records in total): 3,780 have been removed from the wordpress.org plugin directory. Removal stops updates but doesn't uninstall — affected sites keep running the code. 277 carried a critical (CVSS ≥ 9.0) flaw on record before removal. 2,115 are still installable today with a known vuln and no update in 12+ months — roughly 6.7M active installs combined. The part that surprised me most: "removed from the directory" is nearly invisible to a site owner. No dashboard warning, no email. The plugin just quietly stops getting fixes while sitting on the site. How I built it (no paid APIs) The whole thing runs on two public sources and no API keys. 1. Vulnerability data — the GitHub Advisory Database. It mirrors CVE records including the Patchstack and Wordfence CNA assignments that cover almost all WordPress plugin CVEs. It's a git repo, so a shallow, sparse clone of the advisories/unreviewed/{year} folders gets you the raw JSON: git clone --depth 1 --filter = blob:none --sparse \ https://github.com/github/advisory-database.git Each advisory carries the CVE ID, a CVSS vector string, CWE IDs, and reference URLs. The plugin slug isn't a first-class field — you recover it from the Patchstack/Wordfence reference URLs with a couple of regexes. That alone attributes the large majority of WordPress advisories to a specific plugin. 2. Maintenance signals — the wordpress.org plugin API. For each slug: https://api.wordpress.org/plugins/info/1.2/?action=plugin_information&request[slug]=SLUG That gives install count, last-updated date, tested-up-to version, and support-thread resolution ratio. A 404 (or an {error} body) means the plugin isn't in the directory — but that's ambiguous: it could be removed ,

Most "free online tools" have a dirty little secret: the moment you drop a file in, it gets uploaded to someone else's server. Your tax PDF, your ID photo, your client's contract — all sent off to be processed on a machine you'll never see, by a company whose privacy policy you didn't read. For a quick image resize, maybe you don't care. But it adds up. And the wild part is that for most everyday tasks, that upload is completely unnecessary. Modern browsers are powerful enough to do the work right on your own device — no server round-trip, no copy of your file sitting in someone's cloud. Here's how that works, and how to actually use it. Why do so many tools upload your files? Two reasons, mostly. The first is habit: it's easier for developers to send a file to a server, run some code there, and send the result back. The second is business: once your file is on their server, they can log it, analyze it, or use "free" as a funnel toward a paid plan. Watermarks, file-size limits, and "sign up to download" walls all come from this model. The alternative — processing files client-side , meaning inside your browser — has quietly become viable for a huge range of tasks thanks to two technologies: JavaScript (which every browser runs) and WebAssembly (which lets browsers run fast, compiled code at near-native speed). Together they can compress an image, merge a PDF, or transcode data without your file ever leaving the tab. What you can do entirely in your browser You'd be surprised how much works locally now: Images — compress, resize, convert between PNG/JPG/WebP, remove backgrounds, strip metadata. PDFs — merge, split, rotate, compress, and convert to or from images. Text and code — format or minify JSON, count words, change case, generate QR codes, encode/decode Base64. Everyday math — loan, BMI, age, and currency calculators that don't need a server at all. None of these require your data to travel anywhere. The tool loads once, and from then on it's just your CPU doin

Intro There's a pitch behind every AI coding assistant: it makes you faster. Fewer keystrokes, less boilerplate, more shipped features per sprint. The pitch is half true. What it leaves out is the gap between a tutorial demo and a real codebase under real pressure. In a demo, every suggestion is correct because the demo was built to make the suggestion look correct. In production, the assistant doesn't know your architecture, your team's conventions, or the ticket you're actually trying to close. It just knows what tends to come next in code that looks like yours. That gap is where the noise lives. The instant-accept trap Say a developer is mid-flow, wiring up a new endpoint. The assistant suggests a validation helper that looks reasonable, so they hit tab. It compiles, tests pass, they move on. Three weeks later a teammate finds two nearly identical validation helpers in the codebase: one written by a human eight months ago, one autocompleted last sprint. Nobody meant to duplicate logic. The suggestion was locally correct and globally redundant, and nothing about "correct code that compiles" caught that. (This is an illustrative scenario, not a specific incident, but most teams running Copilot or similar tools for more than a few months will recognize the shape of it.) Architecture creep, one suggestion at a time No single autocompleted line breaks your architecture. That's exactly the problem. An assistant trained on generic patterns will happily suggest a new abstraction, a new dependency, a new way of doing something you already do three other ways elsewhere in the codebase, because it has no visibility into "elsewhere." Accept enough of these one at a time and the codebase drifts into a dozen small dialects of the same idea, none of them wrong in isolation. The review tax The real cost isn't the code that's obviously bad, that gets caught. It's the code that's plausible enough to pass a quick glance and wrong enough to need real review time later. If you accept

I am currently focusing on sovereignty and compliance for NuxiPro. My goal is to build a truly helpful, privacy-first tool that respects user data. Here is the roadmap I am executing before pushing forward with NuxiPro's cloud version: GDPR Compliance: Clearly document data storage locations, processing methods, and third-party sub-processors. Legal Hub: Centralize all legal and compliance documents directly on the landing page. GDPR Traceability: Implement a strategy to track user consent, permissions, and privacy preferences accurately. Ultimately, my goal is to deliver a sovereign, privacy-respecting, minimalist alternative to Trello.

How I Built a Wedding Planning Suite with Supabase in 3 Months Quick Answer: I built a full wedding planning platform in 90 days using Supabase as the backend (PostgreSQL database, real-time subscriptions, Row Level Security, and OAuth auth), Next.js 14 for the frontend, and a few carefully chosen npm packages for specific features like QR code scanning. The key was leveraging Supabase's managed services to avoid building auth, websockets, and file storage from scratch. Introduction Three months ago, I had an idea: what if couples could plan their entire wedding through one cohesive platform? Not a static checklist app, but a living, breathing system where vendors, guests, budgets, and timelines all talked to each other in real time. I'm a solo developer with a day job. I didn't have a team of backend engineers to build authentication, real-time sync, or file storage infrastructure. I needed a stack that would let me ship fast without shipping broken. Enter Supabase. I'd heard the "Firebase alternative" pitch before, but what I discovered was something far more powerful for developers who actually want to own their data and their SQL. This is the story of how I built WedPlanner—a full wedding planning suite—with Supabase, Next.js, and a few other tools. No VC funding. No offshore team. Just me, a tight deadline, and a PostgreSQL database that never let me down. Why Supabase? The Architecture Decision That Made Everything Possible When you're building alone, every architectural decision compounds. Pick the wrong database, and you'll spend weeks fighting migrations. Pick the wrong auth solution, and you'll ship with security holes you don't even know about. I evaluated Firebase, PlanetScale, Clerk, and rolling my own PostgreSQL on RDS. Here's why Supabase won: PostgreSQL, not a proprietary document store. Wedding data is relational. A guest belongs to a wedding. A vendor has multiple bookings. A budget category has many line items. Trying to model this in Firestore's

Background The site edit modal kept accumulating fields — site name, category, SSH connection details, WordPress install location — until editing anything meant scrolling up and down a single long form to find the right field. To clean this up, we split it into three tabs: "Registration info," "SSH," and "WordPress info." That change broke form submission itself, in a way that was hard to spot at first. What tabbing broke The tab implementation itself is straightforward. Each tab's fields live in a <div class="site-tab-content" data-tab="..."> , and CSS toggles which one is visible. .site-tab-content { display : none ; } .site-tab-content.active { display : block ; } An inactive tab is hidden with display: none . Nothing unusual so far, and visually it worked fine. The problem showed up when a required field sat in a tab that was not currently active, and the user left it empty while saving from a different tab. Clicking the save button did nothing . No error message appeared. The form just looked stuck. Root cause: a browser cannot report an error on a field it cannot show HTML5 form validation works by having the browser automatically block the submit event whenever a constrained field (like required ) fails, then focusing that field and showing its standard validation bubble (equivalent to calling reportValidity() ). Note: reportValidity() is a method from the HTML5 Constraint Validation API. It checks whether a form element's value satisfies its constraints (required, pattern, etc.) and, if not, displays the browser's standard error bubble. But when the failing field sits inside a tab hidden with display: none , the browser has nowhere to anchor that error bubble. It still faithfully blocks the submit — but it cannot visualize the error, so it simply stops without any visible feedback. From the user's side, this looks exactly like a button that does not respond. Before tabbing, every field lived on the same screen, so this never surfaced. Introducing tabs — a UI

Last month I shared how I built 143 free online tools that run 100% in your browser — no signup, no uploads, no watermarks. That post got a great response (and a lot of "how is this free?" comments — answer: it stays free because files never touch a server, so there are no processing costs). Today's update: every single tool now has a full guide series. What's new 144 how-to articles — one per tool — live at toolfyra.vercel.app/blog : Step-by-step guides — every input explained, common pitfalls, pro tips Real competitor comparison tables (we scraped and analyzed who ranks for what, and where their tools annoy users with account walls) FAQ sections with schema markup so answers surface directly in search and AI assistants Unique generated illustrations per article Smart related-tools clusters — finish one task, the next tool is one click away Why guides for calculator tools? Because "how to use a calculator" is what people actually search for. Tools win clicks; guides win trust and rankings . Each article is built from real search-engine data: live SERP results, keyword expansions, and competitor FAQ analysis — zero guesswork. The engineering side (for the dev readers) Every tool is a single HTML page with vanilla JS — calculators run client-side, file tools use Canvas/FileReader APIs The blog is generated (Python build script): schema.org BlogPosting + FAQPage + BreadcrumbList, per-post OG images as optimized SVGs, canonical URLs, sitemap + IndexNow pings on every deploy New site-wide: instant search (type "pdf" → live results dropdown, keyboard-first: / to focus, ↑↓ to navigate), a Tools dropdown with 11 categories, and a mobile hamburger panel — all vanilla JS, no dependencies Privacy by architecture: there is literally no upload endpoint to breach What's next More waves of content (FAQ, mistakes-to-avoid, and comparison articles for every tool) A batch of new tools from our demand-research pipeline (we score thousands of real search phrases before writing a line

Indexar o código fora do repo: como economizar tokens sem jogar o projeto no contexto Pessoal, o agent precisava achar um símbolo. Trabalho de um minuto. Na prática, ele abria arquivo atrás de arquivo, colava dump de teste no papo e a janela sumia. Às vezes a fatura também. Não era o modelo burro. Era eu pagando o monorepo inteiro pra responder a pergunta errada. A pergunta mudou. Deixei de ser “qual tool faz o agent entender o repo?” e virei: o que é memória de domínio, e o que é só custo de ler código nesta sessão? Tem um segundo motivo, e ele não é economia. Um índice de símbolos é um mapa do seu sistema : quem chama o quê, onde está o fluxo crítico. Se esse mapa mora no git, no cache de CI ou num serviço que o agent também escreve, o blast radius não é só token. É superfície. Duas contas, um prompt Memória de domínio é política. O que pode ser lembrado, por qual porta se entra, o que é canônico. Notas, contratos, “onde a gente decide X”. Indexer de código não resolve isso. Code-read barato é custo de sessão. Achar caller e símbolo sem despejar o working tree no prompt. Isso não deveria virar a sua base de conhecimento. Eu misturava. O indexer virava KB. O vault virava grep sem porta. Os dois falhavam, e a sessão inchava igual. Economizar token aqui não é trocar de modelo da semana. É separar camada. E decidir onde o mapa vive . O que eu mudei na mesa O mapa de símbolos saiu do working tree. Cache local, fora do repo , fora do git. Reindex é operação de máquina, não de PR. O agent consulta o índice; não precisa reler o monorepo pra “quem chama essa função?”. Quatro perguntas que eu faço antes de indexar um repo (vale colar no README do setup): O índice vive na minha máquina ou sai dela (cloud, CI, cache compartilhado)? Entra em contexto de agent que também tem tool de escrita ? Como eu apago e revogo? Quem mais lê isso? Índice ≠ fonte de verdade versionada. Least privilege no que entra no contexto continua valendo. Depois, parei de mandar firehose de CLI cru. tes

Last week, it came to light Cursor had mostly finished migrating from SolidJS to React . This migration happened about seven months ago. But it became a central focus of discussion following the Solid 2.0 RC release . Then yesterday, a week later, it came to my attention that the Anthropic docs example command for their large-scale migration feature is: I admit that my gut reaction was not great. Out of all the examples they could have chosen... Years of my work became a canonical example of the thing you migrate away from — in the same week we shipped the biggest release in the project's history — stung in a way I won't pretend it didn't. My second reaction was to assume that, like the other trickle-down posts I'd seen this week, this rode the same week-old news cycle. Then I checked the Internet Archive and realized this has been there since at least April 2026 . Four months before the Cursor story broke. At this point, the whole public footprint was a mention of an experiment sandwiched between bigger updates in a Cursor blog post posted in January. The kind of thing that no one outside the industry would even really pick up on. No reasoning, no benchmarks, no argument. Stop to think about what that means. I should be careful here because I can't prove anyone at Anthropic ever read that Cursor post. Nobody can. Maybe a docs writer saw the experiment. Maybe Claude drafted its own example. But think it through. Either it traveled from a buried line in one company's release notes into another company's official docs, or it needed no origin at all. It was already assumed before any public migration existed. Our industry has quietly started broadcasting conclusions where it used to transmit arguments. We couldn't have picked a worse time, because — as I'll get to — arguments are the only source that still matters. Why This Matters More Than It Used To It would be fair to ask, hasn't it always been like this? Teams cargo cult large players. Netflix or Facebook uses thi

Originally published at parvejshah.com/blog/why-browser-agents-fail-in-production-without-semantic-layers by Parvej Shah . The Fragility of Machine Vision in Modern DOMs Maybe the next evolution of frontend engineering isn't just designing interfaces for humans. It is designing interfaces that machines can reliably understand too. Browser agents don't always fail because the AI model is bad. Often, the web page itself is fundamentally hostile to machine parsers. Modern single-page applications (SPAs) render deeply nested <div> trees with ephemeral, auto-generated class names (such as Tailwind or CSS-in-JS hashes). While this provides fluid visual rendering for human users, it strips away semantic meaning for automated agents. graph TD A[AI Browser Agent] -->|Fragile Visual OCR / Coordinate Guessing| B[Opaque Div Hierarchy] B -->|Frontend Code Deploy / CSS Hash Shift| C[Broken Automation & Flaky Selectors] A -->|Direct Deterministic Query| D[Semantic Schema & data-agent Attributes] D -->|Refactor-Proof Contract| E[Deterministic Task Execution] Moving Beyond Ephemeral Selectors We already treat accessibility (a11y) as a non-negotiable contract between the frontend and assistive technologies through ARIA attributes. Why not extend that exact engineering rigor to AI agents? Imagine components exposing explicit, stable machine intent: // The machine contract: deterministic, testable, refactor-proof < button data - agent = " checkout-submit-button " data - agent - action = " complete-transaction " className = " btn-primary " > Confirm & Pay < /button > With explicit semantic attributes: Zero Layout Guesswork: The agent does not need to guess which button to click based on pixel coordinates or fragile CSS selectors. Deterministic Interaction Paths: Continuous integration (CI) test suites can validate machine contracts alongside accessibility audits. Reduced Latency & Token Costs: Vision-language models (VLMs) introduce non-deterministic latency and high token costs when in