What I learned:

The honest answer to "what do teams report" is that almost nobody is reporting, and the star counts are hiding it - github/spec-kit sits at 124,743 stars and 11,140 forks with 318 open issues as of today, ranked #79 on GitHub globally by star-history, with Fission-AI/OpenSpec at 63,289 stars and 327 open issues and gsd-build/get-shit-done at 64,785. Against a quarter of a million stars across three repos, Augment Code's brownfield guide states flatly that "DORA has acknowledged the topic but published no SDD-specific findings, and peer-reviewed literature offers no standardized metrics yet," that "rigorous brownfield before-and-after data has not been published," and that "teams adopting brownfield SDD in 2026 are establishing baselines rather than following mature standards." The engagement gap shows up inside the window too: an Ask HN on what people think of spec-driven development posted 24 July drew 4 points and 2 comments. If you are deciding whether to adopt this, you are deciding on anecdote, and the anecdotes skew solo and greenfield.

The single best field report in the window is about the absence of a standard rather than the merits of specs - @mardehaym describes a healthcare data company with AI coding tools on every engineering team where "adoption looked great in the seat count," then asked four engineers across three teams how they actually used it and got four different answers: "One team wrote specs first. Another pasted whole files into a chat window and hoped. A third kept a review checklist that no lead ever enforced. The fourth had built something good and told no one." The line that matters for anyone about to roll out a spec workflow is the last one: "None of the four could name the org standard, because their org did not have one." Spec-driven development as a team practice fails at the enforcement layer long before it fails on methodology, and buying seats does not touch that layer.

The waterfall objection has a precise form, a precise rebuttal, and most people are arguing past both - the strongest version is Kent Beck's, carried in Martin Fowler's 8 January Fragments: the descriptions of SDD he has seen "emphasize writing the whole specification before implementation," which "encodes the (to me bizarre) assumption that you aren't going to learn anything during implementation that would change the specification." The blunter version landed on X on 3 July from @PawelHuryn: "Spec-Driven Development was always BS. It never worked for humans. Waterfall lost to agile because you discover what you actually need while building, not in a spec written up front." The rebuttal from AWS's Marc Brooker is that "you don't need to, and probably shouldn't, develop the entire specification upfront." Both are right about different things, which is the tell: the real objection is to freezing a spec, not to writing one, and the tools ship phase gates whether or not the methodology asked for them.

The clearest account of how it actually goes wrong describes a bind with no exit inside the workflow - sudoish's waterfall-trap writeup names it: "Trust the spec and risk building on wrong assumptions. Question the spec and risk destabilizing it further." The mechanism is that an agent-authored spec reads as authoritative, since "the AI makes everything look correct... It reads like something a senior architect wrote after careful deliberation," and challenging one makes it worse, because "hallucination risk actually goes up when you question it, because now it's reconciling your objection with a position it never truly held." What came out the other end was "thousands of lines of specification documents. Documents that were incredibly hard to review." The closing diagnosis is the practical one to steal: "nothing in the workflow guided me toward 'that's enough, go build and come back.'" IBM draws the same line more mildly, warning that three weeks spent debating the name of a single JSON key for a feature that might be deleted in a month defeats the purpose entirely.

Spec drift is the cost every guide names and nobody has fixed, and the most honest version says the fix is not process - Augment Code puts it plainly: engineers write the doc, ship the feature and move on, and "the updating part is invisible work that competes with everything else on a given day, and it loses that competition almost every time." Then the sentence worth quoting back at anyone proposing a spec policy: "We've tried process. We've tried tooling. We've tried making it a team value. None of it has worked because we keep asking humans to do a thing that humans reliably won't do." Agents change the shape of that cost rather than shrinking it, because "a stale spec misleads agents that don't know any better. They'll execute a plan that no longer matches reality, confidently, and they won't flag that anything is wrong." The same piece cites InfoQ on the structural limit for teams specifically: current tools "typically keep specs co-located with code in a single repository" while "modern architectures span microservices, shared libraries and infrastructure repositories."

Nobody agrees what the term means, which is why the argument never resolves and the tooling keeps forking - the sharpest thing said on X all month came from @wangleineo replying into a thread with Gergely Orosz and Dex Horthy: "You have to define spec-driven development. I believe everyone is using some kind of specs with AI coding. Specs go out of sync with code, sure, that is a problem to solve, but how else do you communicate with agents if not through specs?" That is the strongest available defense, and it is a defense of markdown files rather than of a methodology. Meanwhile the label keeps splitting under load: @0xJeyx compresses the whole method into Karpathy's Sequoia AI Ascent 2026 line, "You have to work with your agent to design a spec that is very detailed," which is prompt advice and not a process; OpenSpec shipped v1.7.0 rebuilt around an artifact-guided workflow that replaces its own prior shape; and July's Show HN crop includes Kastor pitching Terraform-style specs for agents at 33 points and 21 comments, and Speck modelling itself on compilers and build tools at 5. Choosing a spec tool right now means choosing between incompatible definitions of the word.

KEY PATTERNS from the research: 1. Adoption is measured in stars and nothing else - 124,743 on spec-kit against no published before-and-after data and no standardized metrics, per Augment Code 2. The failure teams actually hit is the lack of an enforced org standard rather than a bad methodology, with four engineers at one company giving four different answers, per @mardehaym 3. The waterfall objection is about freezing a spec, not writing one - Beck's form is that SDD assumes you learn nothing during implementation, per Martin Fowler 4. Agent-authored specs read like senior-architect work, are incredibly hard to review, and get more dangerous when challenged because hallucination risk rises, per sudoish 5. Drift has resisted process, tooling and culture alike, and a stale spec now misleads an agent that executes it confidently without flagging anything, per Augment Code 6. There is no shared definition of the term, and the best defense on offer reduces to "how else do you communicate with agents if not through specs?", per @wangleineo

What I learned:

Almost nobody bought a detector - the thing hiring teams actually changed was the interview - the single most useful number in this window is a negative one. Only 14% of hiring teams have deployed dedicated AI-detection software, per the Willo Hiring Trends Report 2026 collated at detectiondrama.com. What they did instead, from the same survey: 47% updated their interview probing techniques, 39% increased in-person meetings, 31% added practical tasks like live coding. That is the whole story of the screening side in one line - the industry looked at authorship detection, declined, and moved the test downstream to a room where the candidate has to talk. For an applicant this is worth internalizing precisely: there is very likely nothing scanning your resume prose for AI, and the polish you added is not what will sink you. The gate moved to whether you can defend the work, and it moved without anyone announcing it.

They declined the detectors because the detectors fail in the exact direction that would destroy an innocent candidate - Anastasia Uglova ran 11 AI detectors over 8 pieces of her own writing, four of which predate ChatGPT entirely, and posted the results to HN. Her 2019 personal user manual - written before the tool existed - scored 5% human on Getsolved and 100% human on six other detectors. A 95-point spread on identical text. Ace flagged all eight pieces as majority AI-generated including the pre-LLM ones; Humalingo never rated her above 18% human in either era. And the finding that closes the argument: her most heavily AI-assisted fiction scored 99 to 100% human on seven of the eleven. The tools did not just miss, they inverted. A recruiter who runs that in production is not filtering for honesty, they are filtering for a writing style, and the one person in the sample who genuinely used AI sailed through.

The experiment everyone is quietly copying was run by an economics professor, not a hiring vendor - Brown's Roberto Serrano gave a take-home midterm for the first time in his career, per Inside Higher Ed. The class averaged 96, with 40 students scoring a perfect 100. He moved the final in person and the average fell to 48.6%, the lowest in the course's history, with three zeros, and only a couple of students landing within 10% of their own midterm score. @jacobm read it correctly as a measurement story rather than a morality one - the take-home stopped measuring the thing it was built to measure. The part hiring teams should study hardest is what happened next: Serrano sent his findings to Brown's Standing Committee on the Academic Code and was told to file individual complaints against each suspected student. Detection was the cheap part. Adjudication was the part that did not scale, which is exactly why the corporate version of this skips accusation entirely and just makes the in-person delta the score.

The contrarian finding is that take-homes did not die, and most teams are enforcing a rule they already know is broken - Karat surveyed 400 engineering leaders across the US, India and China. 71% say AI has made technical skills meaningfully harder to assess. But 45% of US organizations still run take-home projects, against 79% doing live technical interviews and 63% running automated code tests. The regional split is sharper than the temporal one: China sits at 20% take-homes and 87% live, and 68% of Chinese organizations permit AI use during the interview against 38% in the US. The number that should embarrass everyone is that 62% of organizations still prohibit AI in technical interviews while those same leaders estimate that over half of candidates use it anyway. That is not a policy, it is a fiction both sides are maintaining, and it means a large share of hiring loops are currently scoring candidates on how well they hide a tool the company will hand them on day one.

The largest cheating dataset in the window says the flagged candidates were passing anyway - and it comes from someone selling the fix - Fabric analyzed 19,368 interviews run on its platform between July 2025 and January 2026 and flagged 38.5% of candidates for cheating behavior at a probability threshold above 40%. Technical roles hit 48% against 12% for sales, roughly a 4x gap; juniors flagged at nearly double the senior rate; the rate tripled between July and September 2025. The number that actually matters for screening design is that 61% of flagged candidates scored above the passing threshold and would have advanced undetected. Hold the caveats firmly though - this is a vendor publishing about its own product, the signal set includes gaze tracking and keystroke dynamics, and the writeup discloses no false-positive rate at all. After the Uglova result, an undisclosed false-positive rate is the only number that would tell you whether 38.5% means anything.

The root cause is volume, and the serious counter-move is to impose cost rather than detect intent - Greenhouse runs about 254 applications per live job across 175,000 postings, a 412% increase in applications per recruiter, per CEO Daniel Chait in Fortune: "Someone goes and buys that tool, it's like 20 bucks, and now they can just shoot out job applications willy-nilly." His name for it is the AI doom loop - "everyone's using their own AI to solve their own problem, but it's making the whole system worse" - and his answer is not a classifier but a toll booth, acquiring Ezra AI Labs to require an interview of every single applicant, on the logic that "why would I send out automatic thousands of job applications if every single one of them I have to take an interview for?" 63% of job seekers have now sat one of those AI interviews, up 13 points in six months. The quieter version of the same move is channel reweighting: referrals are roughly 7% of applications but 30 to 50% of hires, while job boards supply 49% of applications and 24.6% of hires, per StaffingHub. When the document stops carrying signal, the channel becomes the signal - which is the least meritocratic possible outcome and nobody chose it on purpose. @HedgieMarkets put the whole thing in one line at 372 likes: "Both sides are running AI on the same document and the hiring process has turned into a contest of whose AI is better."

KEY PATTERNS from the research: 1. Detection software is the road not taken - only 14% of hiring teams deployed one, while 47% changed interview probing and 39% added in-person meetings instead, per Willo via detectiondrama 2. AI detectors invert rather than miss - 11 tools scored the same pre-ChatGPT 2019 text anywhere from 5% to 100% human, while genuinely AI-assisted fiction passed as 99-100% human on seven of them, per Original Separation 3. The in-person delta replaces the accusation - a take-home average of 96 became 48.6 under a proctored final, and the adjudication, not the detection, is what failed to scale, per Inside Higher Ed 4. Take-homes survived the year - 45% of US engineering organizations still run them even though 71% of 400 leaders say AI made skills harder to assess, per Karat 5. Most loops enforce a rule they know is broken - 62% prohibit AI in technical interviews while the same leaders estimate over half of candidates use it, and China permits it at 68% against the US at 38%, per Karat 6. The scaled answer is cost imposition, not classification - 254 applications per job is being met by requiring an interview of every applicant and by quietly reweighting toward referrals, which are 7% of applications and 30-50% of hires, per Fortune

What I learned:

The renderer question finally has a measured answer this month, and the winning move costs you accessibility - Polar Signals rewrote its flame graph from SVG to Canvas and published every number. Isolated render on a ~17,000-frame profile went from a 164.1ms median to 46.05ms. In the browser, first render went 448ms to 42ms, reset zoom 528ms to 47ms, scroll 31ms to 6.1ms. Under a 15x CPU throttle the canvas version held 118.5fps with 1 dropped frame against SVG's 60.6fps with 58 dropped and a 34ms p95. The mechanism is the thing to internalize, not the multiplier: cost stops scaling with how many nodes the browser has to style, lay out, paint and garbage collect, and starts scaling with how many you actually draw, so a 50,000-frame profile with 800 visible frames issues roughly 800 draw calls instead of 50,000. They had already parallelized the SVG path down to 91ms and still hit the wall, because the wall is DOM nodes. The invoice is stated plainly and left unpaid: "Accessibility and text selection. This one was a loss we had to bear as a canvas is opaque to a screen reader, and you cannot select text off it the way you could off SVG... We don't fully have a solution for this yet." The HN thread ran 30 points and 2 comments, which is about how much attention the most useful engineering post of the month got.

The most widely deployed infinite-canvas SDK in production is still DOM-rendered, which is the most surprising fact in the corpus - tldraw sits at 49,497 stars with 474 open issues, and its npm page lists Google, Shopify, BlackRock, Autodesk, ClickUp, Replit, Luma and Runway as shipping on it. It renders each shape as a React component positioned by CSS transforms, and its culling docs are explicit that culled shapes stay in the DOM with display: none. That converts O(total shapes) into O(visible shapes) via a spatial index, and the performance page publishes the actual guardrails everyone else hides: a 4,000 default maximum shapes per page, debounced zoom that switches on above 500 shapes because "recalculating everything mid-zoom causes jank", a text-shadow level-of-detail cutoff at 0.35 zoom, and the worked example that "a canvas with 10,000 shapes might only render 50 if the rest are out of view." So DOM is not disqualified by node count, it is disqualified by visible node count. The other big-document failure showed up when tldraw shipped tldraw offline in July as a local file app: the thing that stalled it for a year was saving, and the fix was reusing the multiplayer differential sync so that "only the bit that changed gets sent over and merged" instead of rewriting the whole document on every write.

Hit testing, not rendering, is what actually forces you off the DOM - Steve Ruiz's What's Under the Pointer? is the clearest account of the failure mode anywhere in the window. Early tldraw absorbed browser hit tests with hidden SVG paths carrying pointer events, and it broke in four specific ways: Z-order confusion with overlapping hollow shapes, screen-space accuracy needing per-zoom adjustment, the browser re-traversing the DOM every frame once you had thousands of shapes, and arrow dragging, where pointer capture blocked simultaneous canvas hit detection. The replacement is a broad-phase/narrow-phase scheme lifted straight from game engines: bounding boxes reject first, precise polyline and polygon distance math runs only inside the box, pointer-events: none goes on the canvas entirely, and CSS masks replace nested elements for frame clipping. That buys selection logic the DOM cannot express, including traverse front-to-back through Z-order, stop at filled shapes, prefer edges on hollow ones, pick the smallest hollow shape when several overlap. Ruiz is honest that none of it was derived: "You just use it, use it, use it, until you figure out what the logic should be." Self-intersecting polygons still defeat point-in-polygon and you either work around it or eat the error. Polar Signals wrote the canvas version of the same job in one sentence: "we invert the same maths we drew with: the row falls out of the mouse y divided by the row height, and then a quick left-to-right scan across that row's frames finds the one under the cursor." Once you leave the DOM, that code is yours forever.

The subsystem everyone underscopes is undo, and there is a price quoted on getting it wrong - the blunt line comes from RaftLabs: "The hardest part of building a design editor is not the drawing surface. It is the undo stack. If Ctrl+Z does not work perfectly, users lose trust in everything else." Their scoping claim is the useful part: writing a detailed undo specification across move, resize, text edit, layer reorder, group, delete, paste and duplicate adds about a week to the design phase, while fixing a broken undo after launch runs 3 to 5 weeks. The same piece names export as the second predictable failure, where shipping browser-side jsPDF forces 4 to 6 weeks of rework the moment print quality is required. What people actually ship in 2026 is unglamorous: FreeCut, a full browser video editor, gets undo/redo from Zustand plus Zundo, a store middleware rather than a bespoke command stack. tldraw's equivalent is a reactive signal store where a property change re-renders "only that shape's component, not the entire canvas" and batched updates arrive as one notification rather than one per shape. The pattern in both is the same: make the document a store you can diff, and undo is a consequence rather than a feature.

Timeline UIs got a first-party default this month, and the open-source browser editors underneath them are a Chromium-only bet - Figma Motion landed at Config 2026 with native keyframes on the design canvas for position, scale, rotation, opacity and corner radius plus a bezier curve editor, shipping on all plan tiers, per Art of Styleframe. Its own scoping is the honest part: "Figma Motion doesn't erase the specialists. It changes the default." After Effects keeps layered effect-heavy work, Rive keeps interactive state machines and runtime-driven animation, and "export options are still maturing at launch." Its performance advice is just web performance advice, keep motion to transform and opacity because those are the cheap properties. The open-source side is making a much harder platform bet: FreeCut (1.9k stars) requires WebGPU for compositing and effects, WebCodecs for preview and export, OPFS for workspace persistence and the File System Access API for disk folders, which means Chrome or Edge 113+ and nothing else, with frame-accurate playback driven by a custom Clock and multi-track ripple, rolling, slip and slide editing. And Remotion at 55,021 stars sells its Editor Starter as a paid one-time-purchase template with 80+ feature flags, precisely because "timeline, interactive canvas, font picker, asset uploads" is the part nobody wants to rebuild. When a company with 55K stars monetizes the timeline widget rather than the renderer, that is the market telling you where the work is.

Library choice in 2026 is a renderer choice wearing an API, and the most credible source is a maintainer telling you not to use his library - the Konva guide is unusually straight: "Konva uses Canvas 2D and can't match WebGL performance for game workloads", use PixiJS instead, and for SVG import and export "Konva can't do this", use Fabric.js. Its real differentiator turns out to be multi-layer rendering, where "static content doesn't re-render when interactive shapes move", which is culling by another name. Live counts as of today: Excalidraw 128,724 stars against 3,271 open issues, Remotion 55,021, tldraw 49,497, PixiJS 47,918, Fabric.js 31,353, Motion Canvas 18,866 and last pushed 2026-07-02, Konva 14,652 with only 17 open issues. The dividing line under all of it is capacity per frame: Canvas2D is comfortable at hundreds to a few thousand objects, a single WebGL draw call handles tens of thousands of shaded triangles, and the price of crossing over is GLSL plus everything you rebuild by hand on the other side. On X the actual practitioner traffic is migration chatter rather than architecture, with @adrixy0 posting "I've completely shifted to @tldraw from @excalidraw. My feature-greedy side is taking over", and the newest reason people pick an SDK showing up on HN as Agent Draw, an agent that draws while you talk, built on tldraw.

KEY PATTERNS from the research: 1. The SVG-to-Canvas switch is measurable and one-directional - first render 448ms to 42ms on a ~17,000-frame document, at the cost of screen readers and text selection with no fix shipped, per Polar Signals 2. Culling rather than the renderer is what makes big documents work - tldraw ships DOM rendering with a spatial index and display: none, defaulting to 4,000 shapes per page and debouncing zoom above 500, per tldraw docs 3. Hit testing is the real reason to leave the DOM, and the replacement is broad-phase bounding boxes then narrow-phase polygon math with pointer-events: none on the canvas, per Steve Ruiz 4. Undo is the underscoped subsystem - one week to specify upfront across move, resize, text edit, reorder, group, delete, paste and duplicate, versus 3 to 5 weeks to repair after launch, per RaftLabs 5. Saving is a scale failure mode too - tldraw offline was blocked for a year until full-document writes were replaced with differential sync from the multiplayer path, per tldraw 6. Browser timeline editors are currently a Chromium bet, with FreeCut requiring WebGPU, WebCodecs, OPFS and the File System Access API on Chrome or Edge 113+, per FreeCut