Hardware development is converging with software development. That single sentence is the thesis behind hw.dev, and it is load-bearing. Every post on this site descends from it.
The convergence is not a slogan. It is a specific set of mechanical shifts happening layer by layer across the stack. Requirements that used to live in PDFs are starting to live in Git. Tests that used to run on a bench once a week are starting to run on every commit. Place-and-route tools that used to ship once a year as a GUI are starting to ship nightly builds with APIs. Contract manufacturers that used to communicate via spreadsheet are starting to expose REST endpoints against which a PCB release can be diffed and validated. None of these shifts is dominant yet. All of them are real.
Why now
Three constraints broke at once.
Cost of iteration has collapsed in places it used to be prohibitive. Cloud simulation farms, on-demand PCB fabrication in days, contract manufacturers that quote a full turnkey run from a Git repo, silicon services that fit a shuttle wafer to a startup's budget. The activation energy for "try the next version" is two orders of magnitude lower than a decade ago.
Tooling has caught up to modern engineering practice. Version control has been won. CI has been won. Package managers, reproducible builds, API-first design, infrastructure-as-code -- all settled patterns in software, all arriving in hardware at different speeds. The hardware engineer of 2026 is no longer a different species from the software engineer; they are running the same playbook against a slower feedback loop that keeps getting faster.
AI compressed the slow steps. The places AI is earning its keep in hardware are the places a cycle got shorter: RTL bring-up, PCB routing, DV stimulus generation, MFG test authoring, BOM substitution search. The rest is demo-ware. We will evaluate AI the same way we evaluate any tool: does it compress iteration, reduce coordination cost, or improve decision quality? Anything else is a pitch.
What follows from the thesis
If hardware is catching up to software, the interesting questions all have the same shape: what part of the stack is being code-ified next, what incumbent does that expose, and what can a builder do about it now that could not be done last year?
That is the question hw.dev is here to answer. Not as a news site. Not as a neutral aggregator. An operator-led read on what is actually moving.
In practice that means this site reads the week in three registers.
Signal is the short-form read. A credible new release, benchmark, teardown, funding round, or primary-source post that evidences a constraint being removed. Not a summary of the article -- a read on it. What happened, why it matters, what it enables, an operator perspective. If a reader could have written the post themselves from the press release, we did not do our job.
Analysis is the long-form argument. A named shift, a named constraint, named beneficiaries, named parties exposed, a specific builder takeaway. Not a survey. Not both-sidesism when one side is clearly stronger. If the post does not take a position a competent reader could disagree with, it is not analysis.
Stack Maps are the reference layer. Opinionated, living documents that lay out the modern hardware development stack layer by layer -- what is in each layer, where the incumbents are, where the insurgents are, and most importantly where the gaps are. These are the pieces you bookmark. They update as the ground moves.
What we ignore
A lot.
We skip press-release coverage that does not change a cycle time, a cost, or a decision. We skip "AI will transform X" takes without mechanism. We skip vendor benchmarks without methodology. We skip trend-chasing. We skip tool shout-out posts unless the tool evidences a worldview thread -- shift-left, everything-as-code, a constraint removed. We skip neutral analyst voice in all its forms. Hedged-everything is not analysis; it is noise wearing a suit.
What we do not skip: the slow, structural shifts that change what a hardware team can ship. The PLM displacement story. The EDA-as-API story. The test-as-code story. The contract-manufacturer-as-platform story. The open-silicon story. The "can this run in CI" story. These are the stories that compound.
The bet
The bet is simple. Hardware development over the next five years will look more like modern software development than it has in any prior five-year window, and most of the incumbent tools priced for the pre-convergence world are going to feel -- and be -- underwater. The platforms that get built in that window are going to be worth paying attention to.
hw.dev is the intelligence layer for that window. Signal to read the week. Analysis to read the shift. Stack Maps to read the space.
That is what we are here to do. The rest is execution.