@quilterai just hit a milestone we've been working toward for years: An AI-designed, 843-component Linux computer… that booted on the first try. This is Project Speedrun — the hardest test we’ve ever thrown at Quilter. 👇

“Whether or not a PCB layout or design is good is computable.” Our CEO @sergiynest joined the AI and Design podcast from CMU Human-Computer Interaction Institute hosted by Nikolas Martelaro to talk about why Quilter is taking a different path from most AI tools. Here are key highlights when it pertains to PCBs design: 1. Imitation of existing designs has a ceiling, physics does not. A lot of AI tools learn by mimicking human behavior. We all know how powerful it can be for text. For printed circuit boards, if a PCB layout is 99% right, the remaining 1% can still kill your whole board. Moreover, if a model learns from existing expert layouts, how do we know that all of those layouts were optimal? Quilter starts from physics instead. Whether a layout works can be computed from electromagnetics and thermodynamics. So we optimize against that directly. 2. "Vibe coding" hardware has a hard limit. For simple boards, yes, hobbyists are experimenting with vibe engineering. We've seen a mechanical engineer with no EE background ship a PCB after a few hours with KiCAD and Quilter. That works when the board is simple and the stakes are low. But for anything with real complexity nobody serious is prompting their way to a validated layout. 3. Constraints are at the heart of layout automation. Before you can automate anything, you have to capture what "good" means for this specific board. Across a real design, that can be tens of thousands of constraints. No engineer is going to manually capture all of them. Sergiy talked about 3 possible approaches: a chatbot that interrogates you, tables you fill in and verify, or direct selection on the schematic you already know by heart. The truth is nobody has solved how to design the best human-AI interface for that yet, including us. The discussion went beyond the traditional PCB topics and touched on how to hire engineers in an era where AI tools are expected, why deleting from your design until things break is a better practice than adding features, how to stay focused on one problem when agentic tools make it cheap to build anything. Take a listen: podcasts.apple.com/us/podcas… open.spotify.com/episode/5aw…

@CNBC mentioned Quilter in their recent report on PCB manufacturing in the U.S. CNBC's piece focuses on how central boards are to the AI and defense supply chains. Chips have been getting most of the headlines, but without a printed circuit board a chip is just an expensive piece of silicon. It's great to see that PCBs are starting to get the public and policy attention they deserve. Most of the policy response in the U.S. focuses on fabrication: a proposed 25% tax credit and $3 billion in funding for domestic board makers like TTM. That addresses where boards get manufactured. The other constraint is how they get designed. PCB layout is still weeks to months of manual work. Quilter was mentioned as a solution to accelerate the PCB layout process with AI. cnbc.com/2026/06/03/beneath-…

"When I do layout, the very first layout, I know I'm going to trash it. Because I'm using it to see where there's space and where there isn't." Robert Feranec is describing a workflow most layout designers know well: a throwaway first pass to understand the physical reality of the board. One use case for Quilter is exactly this: design exploration. When generating a first-pass layout is cheap, you stop committing prematurely to one floorplan. You can compare a different placement strategy or a different region assignment, and see what each looks like before investing days of manual work in one direction. Robert framed it as time savings. It's also about making better decisions earlier. Watch the original video here youtube.com/watch?v=aXjcSAsH…

Most conversations about AI in hardware swing between two extremes: it's useless, or it's about to replace everyone in the building. Our founder @sergiynest sat down with Zachariah Peterson on the @altium OnTrack podcast for a more grounded discussion on the subject. A few highlights: - PCB layout is not a language problem. LLMs are good at reading datasheets and writing firmware. They are not the right tool for deciding where a component goes and how a net routes. That's geometry, physics, and manufacturing, which is why Quilter trains its own models with reinforcement learning rather than wrapping a language model. - The realistic goal isn't a magic box. When we talk to VPs of engineering, nobody is asking for a perfect board out of a one-sentence prompt. They're asking whether a three-week layout can become one. That's a more achievable problem to solve than nailing a simple board to production perfection. - Being honest about our limits is a feature. Customers tell us we're a breath of fresh air, mostly because we're willing to say "no, we can't do that yet." Engineers see through hype immediately, and we are tired of AI hype as much as everyone else. Check out the conversation here -> youtube.com/watch?v=YJTbsoxP…

There's a common misconception about Quilter that we have a magic button you just push to do your PCB layout. We don't. In this clip from our recent conversation with Robert Feranec, @sergiynest says it plainly: there's no magic button. Quilter is a tool. A useful mental model is to treat it like a junior engineer on your team, correcting it every few iterations. Robert makes a good point: on a 50-component board, doing layout by hand is fast enough that the value of a "junior engineer" isn't obvious. On a 3,000-component board with thousands of nets and vias, where each component can take 20 seconds to place by hand, Quilter can save you a lot of time. You can watch the original video here youtube.com/watch?v=aXjcSAsH…

"I can design everything down to the component level—but I can't get it to the board." That's what a hardware founder told me last week. He's building multiple IoT products. Has detailed BOMs. Knows exactly what goes on each board. But to actually lay out the PCB? He has to send everything to China. Not because he wants to. Because there's no other option. He's a one-person hardware team at a funded startup, shipping 4 new designs in a single month. The knowledge is there. The speed isn't. This is the quiet bottleneck nobody talks about in hardware. Founders and system architects understand their products deeply. They can specify every component, every net, every constraint. But PCB layout requires a different skillset entirely—and hiring for it is brutal. So they outsource. They wait. They lose control of iteration speed right when it matters most. If you've ever had the architecture in your head but couldn't get it onto a board without outside help, I'd love to hear how you handled it.

"Our challenge isn't verifying the design electrically. It's cramming what you want in the space that you have." I heard this from a senior electrical engineer last week. He's been doing board layout since the DOS versions of ORCAD. He's tried every auto router out there. His conclusion? They've been more of a problem than anything else. Why? Because auto routers take shortcuts. They "simplify" the problem by adding layers. But when you're designing ultra-thin flex circuits at 15-50 microns—credit card form factor stuff—there's nowhere to hide. His team routes BGAs with 0.3mm ball pitch using 1.2 mil traces. On two layers. By hand. Not because they want to. Because no tool can understand the physical constraints they're working within. This is the real challenge in miniaturized electronics: the electrical engineering is often the easy part. The hard part is physics—cramming radios, displays, and flexible batteries into spaces where every micron matters and every extra layer breaks the product. The engineers who've been doing this the longest are often the most skeptical of automation. They've seen too many tools promise the world and deliver more problems than solutions. I think that skepticism is earned. And it's exactly what we need to overcome. What's the hardest physical constraint you've had to design around?

"Let's just make a quick board to test this." That's where the rabbit hole begins. A principal at a product development consultancy told me this week how a "quick PCB" for internal testing became a weeks-long distraction. "Resources just disappear. Scope blows up really fast." The board wasn't complicated. No DDR buses. No high-speed constraints. Nothing that required real engineering judgment. And yet it sucked weeks of his double E's time. That's what gets me. Your most experienced engineers—the ones who should be solving the hard problems, the ones who make the difference between a product that ships and one that doesn't—end up gardening routine layouts because there's no other option. We treat PCB layout like it's indivisible. Either you hand it to an expert for weeks, or you wire up Arduinos with a rats nest of cables and call it a prototype. But there's a middle ground emerging. Boards that don't require human creativity shouldn't consume human capacity. The question isn't whether AI can replace your best layout engineers on the complex stuff. It's whether you should keep burning their time on boards that don't need them. What's your threshold? At what point does a "quick board" become worth protecting your team from?

Did you know that we didn't just lay out the i.MX 8M Mini boards with Quilter AI? Ben gave the boards a proper home. Project Speedrun is now a fully functional computer with a custom-made enclosure. We've joined video calls on it and played Doom. Check out the up-close glamour shots. If you haven't heard about Project Speedrun, you can learn more here quilter.ai/project-speedrun #PCBDesign

"We're like a startup inside a big company. They always want results faster." That line hit me during a call with an R&D engineer building autonomous mining equipment in South America. His team is developing technology that retrofits 300-ton trucks with hybrid powertrains and autonomous controls. Custom electronics. Harsh environment. Serious engineering. But here's the thing: two people are doing all the circuit design. Two engineers, up to ten board projects a year, and constant pressure to justify R&D investment through faster delivery. "Our hope is not to grow the team," he told me. "It's to make our team more productive with better tools." He wasn't asking for help with complexity. The designs are within their capability. What's killing them is time—the manual "elbow grease" of routing boards that aren't technically hard, just tedious. This is the underappreciated bottleneck in hardware R&D. We hire senior engineers, then bury them in work that doesn't require senior engineers. Meanwhile, ambitious projects stall because humans can only route so fast. The math never works. More ideas than bandwidth. More pressure than headcount. More potential than hours in the day. How many of you are running R&D teams where the real constraint isn't skill—it's just raw design throughput?

I spoke with an R&D electronics team at a Tier-1 automotive supplier last week. Their challenge wasn't technical skill—it was time. "We're trying to figure out some tools that will help support us to faster, easier development of our PCBs," their lead engineer told me. They're designing smart fuse boxes. Sensor arrays. Power electronics for next-gen platforms. The kind of work that should be all innovation—pushing boundaries, solving hard problems. Instead, their senior engineers are burning hours on layout. Routing traces. Running DRCs. Iterating on placement. Work that's necessary but repetitive. Here's the pattern I keep seeing: automotive R&D teams are stuck in a loop. Customer project lands. Clock starts. And suddenly the bottleneck isn't the circuit design or the firmware—it's waiting on PCB layout to catch up. This isn't a people problem. It's a process problem. The teams moving fastest right now aren't just hiring more layout engineers. They're questioning which parts of the workflow actually require human judgment—and which parts are just computation dressed up as craft. For hardware teams under pressure to deliver more prototypes faster: where does layout sit in your critical path?

Behind the scenes at Quilter lab! Ben is working on another hardware project. Stay tuned!

"Technology is easy. People are hard." That's how Pooya Tadayon sums up nearly 30 years across semiconductor test, packaging, and pathfinding. The counterintuitive piece: friction inside hardware programs gets worse as teams get more technically capable. Our Hardware Rich Development interview gets into why, and what he learned about shipping product anyway. Conversations like this one are the part of the work we look forward to most. We build for hardware engineers, so we spend a lot of time listening to them. quilter.ai/blog/technology-i…

Project Speedrun is getting a shoutout at the Embedded Online Conference next month. Max Maxfield is featuring the board we laid out from the NXP i.MX 8M Mini reference design in his session, "A Smorgasbord of Advanced Technologies." That's Project Speedrun: a Linux-capable motherboard with DDR4, ethernet, USB, HDMI, and hardware-accelerated graphics, designed with Quilter in 38.5 human hours versus the 428 originally quoted. The conference runs May 11-15, 2026. If you want to tune in, Max is offering $100 off registration with code MAXFIELD100. Conference: embeddedonlineconference.com Session: embeddedonlineconference.com…

We've been shipping a lot, and we are excited to show you what's new. This Thursday, we're going to walk through everything that's landed in Quilter in Q1: Simbeor-calculated impedance profiles, ground net comprehension with region pours, a rebuilt setup flow, a new full-screen candidate reviewer, and more. We'll demo it all on a real board so you can see how it comes together in an actual design. We're also giving you an early look at what's shipping next, including the one we know you've been waiting for: automated BGA fanouts. If you've ever burned a Friday fanning out a large BGA, this is the release you'll want to see. Register now us06web.zoom.us/webinar/regi…

LIVE w/ @8teAPi to talk Mythos & all things AI :) Guests include: - @ahall_research on the need for independent AI governance - @sergiynest of @quilterai on AI-designed circuit boards - @lukaspet & @axelbacklund of @andonlabs on AI-managed retail x.com/labenz/status/20437185…

About to go on - come join the convo!

Quilter ships. We don't talk about it enough - now we will. BGA fanout and full support for DRC constraints have been two of the most asked for customer features - both shipping imminently. I'm personally most excited for everything that the simulation engine Simbeor will do now that it's a part of the stack!

We laid out an 843-component computer with Quilter AI, built the firmware from scratch, and joined a Google Meet call on it. The board runs GNOME 48, hardware-accelerated Chromium, and live video — on a quad-core ARM Cortex-A53 with a GPU that only supports GLES 2.0. Chromium doesn't support hardware video encode on this class of device, so we wrote 3 custom patches to make it work. This post walks through every firmware decision: why Mutter 48 over 46, how we forced hardware codec selection in WebRTC, and what broke when the Vivante driver returned NULL for a GLES 3.0 function Chromium assumed existed. It also covers getting Doom and Quake running, because a computer that can't play Doom isn't really a computer. The full Yocto layer is open source. If you work with NXP i.MX silicon or embedded Linux, the meta-quilter recipe is yours to build from. quilter.ai/blog/building-fir…