DEV Community: Dibyaprakash Pradhan

KiCad and AI in 2026: MCP Servers, Scripts, and What Actually Works

Dibyaprakash Pradhan — Wed, 30 Sep 2026 10:58:29 +0000

KiCad has no built-in AI. What it has instead is an ecosystem that grew up around it very quickly, and if you go looking you will find open-source MCP servers, plugins, forum threads, and a lot of confident claims that do not agree with each other.

I have spent a while in this space. Here is an honest map of the four approaches, what each is genuinely good for, and the one distinction that determines whether any of them will help you.

The distinction that matters

Before comparing anything: when an AI triggers KiCad's autorouter, KiCad routes the board. The model supplied the intent and the sequence of actions. It did not lay the copper.

That sounds pedantic. It is not, and it decides everything downstream. If your bottleneck is routing quality, no amount of model capability changes it — you are still getting KiCad's router either way. If your bottleneck is the hours spent on repetitive edits, checks, and exports, then an AI driving those operations is genuinely valuable. Work out which one you have before choosing a tool.

1. MCP servers: let an agent drive KiCad

This is the most capable option available today. The Model Context Protocol lets an assistant call tools directly, and several open-source KiCad MCP servers now expose schematic, board, ERC/DRC, BOM, and export operations as callable tools. With one installed, Claude, Cursor, Copilot, or any MCP client can operate KiCad programmatically instead of through the GUI.

One implementation is a native KiCad 10 plugin written in Rust as a single binary, built on KiCad's official IPC API rather than the older SWIG bindings — which matters, because the IPC API is the path KiCad itself is investing in.

Where it wins: batch edits, running checks across a project, generating BOMs, driving exports, auditing a design against rules. Anything repetitive and well-specified.

What to know: it is a developer setup. You install a server, wire it into your assistant, and keep it working across KiCad versions. And the agent is calling KiCad's engines, so routing quality is KiCad's.

2. Python scripting with an assistant

The most underrated option, by a distance.

KiCad has had a Python API for years, and assistants are very good at writing against it. Bulk-renaming nets, generating footprints from a table, extracting data from a board file, automating the edit you would otherwise do a hundred times by hand — this is squarely in the model's strength.

Where it wins: lowest friction of anything here. No new infrastructure, no protocol, no server. And once the script exists it is completely deterministic — it does the same thing every run.

What to know: read and test what the assistant writes, and run it on a copy first. A script that silently mangles a board file is worse than no script.

If you have never tried this, start here. Most people reaching for an MCP server would get more value from twenty lines of Python this week.

3. Computer use: a model clicking the GUI

Newer models can operate a desktop application directly — open KiCad, place parts, press Auto-Route, export. It works, and it demos extremely well.

Where it wins: nothing to install, no API to learn. Fine for exploring what an agent can do, or a one-off task where writing a script is not worth it.

What to know, and this is the part the demos skip: it is the slowest possible path. Every action costs a screenshot, a decision, and a click, to drive an application that already has a scripting interface doing the same work in milliseconds. It is also not reproducible — run the same request twice and the model may take a different path and land on a different board. For hardware, that last point is usually disqualifying on its own.

4. AI-native tools that are not KiCad

A separate category generates the design itself: you describe a board, a model drafts the parts and netlist, and a deterministic engine places and routes it, then exports fabrication files.

Where it wins: it covers the step none of the above do — producing a design from intent, rather than automating edits to one you already have. Nothing to set up.

What to know: it is a different tool, not a KiCad add-on. If your libraries, your team, and your workflow live in KiCad, a script or an MCP server keeps you where you are, and that is often the right call.

The line that runs through all four

The same boundary shows up every time. A language model is strong at judgement: which regulator, which topology, what a script should do, which checks to run. It has no way to measure whether a trace clears a pad by 0.15 mm — so everything downstream of a measurement has to come from a deterministic engine: a router, a rule checker, a geometry library.

AI that automates the operating of those engines is useful and already works. AI asked to be one is where the claims outrun reality.

So which should you use

A specific repetitive task you can describe precisely → Python plus an assistant. Least setup, most reliable payoff.
An agent working across a whole project → an MCP server. Real capability, real setup cost.
Curious what computer use can do → try it, but do not build a workflow on it.
You want a board generated from a description → that is a different kind of tool, and worth being clear with yourself that it is not a KiCad add-on.

I work on PCBEditor, which is the fourth category — so take my read on that one with the appropriate salt. The first two are where most KiCad users will get value this year, and neither of them is us.

A longer version of this map lives at pcbeditor.com/kicad-ai.

What Does 'Free' Actually Mean in PCB Design Software?

Dibyaprakash Pradhan — Mon, 28 Sep 2026 08:57:38 +0000

I've watched people search "free PCB design software," click the first result, and hit one of three walls: a trial that expires, an install with a real learning curve, or a page that asks for an account before it'll show you anything. None of those are lying exactly — they're all "free" in some sense — but they're not the same promise, and finding that out after you've started is the whole reason this search feels untrustworthy.

I build PCBEditor, a free one, so let me be specific about what free means before comparing it to anything else.

The three kinds of free that get called the same thing

Open source means the code itself is public — you can read it, change it, and run it yourself. KiCad is the reference case: it costs nothing because nobody owns the distribution, and nobody can ever decide to start charging for it. The cost is a real desktop install and a learning curve that a browser tool doesn't have.

A hosted free tool — PCBEditor, EasyEDA, CircuitMaker's community tier, Flux's free tier — is closed-source software you use through the vendor's app at no cost. You never install anything, but you're trusting a company to keep it free, and you can't audit what it's doing.

A "free trial" is neither of those. It's paid software with the meter not running yet. That's a legitimate business model, but it's a different word doing the same job, and it's usually the one that burns people who searched "free" expecting the first two.

Neither open source nor a hosted free tool is better in the abstract. If you want something nobody can ever discontinue or paywall on you, open source is the only real guarantee. If you want to open a tab and start, a hosted free tool gets there faster — you're just trading that ownership for convenience.

Where the specific tools land

If you want the tool most people will point you to, it's KiCad — free, open source, genuinely excellent, and a desktop install with real depth to learn. If you want parts search tied straight to LCSC's catalogue with a one-click hand-off to JLCPCB for fabrication, EasyEDA's free tier is built for exactly that. If what you actually want is a slice of Altium's routing engine for nothing, CircuitMaker gives you that — in exchange for your designs living publicly on their platform, which is worth knowing before you put something you'd rather keep private into it. Altium itself, worth naming since it's the tool everyone eventually compares against, isn't free at all: pricing is per-seat and starts in the thousands a year.

Where PCBEditor sits in that: free, browser-based, no install — closer to EasyEDA's or Flux's model than to KiCad's. The honest caveat, the same one I'd want told to me: the free tools (calculators, the Gerber viewer) need nothing at all, and opening the editor itself needs no account either — but actually having it generate a circuit does ask for a free email sign-in, because that's the part that costs compute. Not a credit card. An account. I'd rather say that here than have someone find out after they've started typing.

There's no paid plan behind any of this today, for what it's worth — no pricing page, no checkout. If that changes later it should be a separate, clearly priced thing, not a quiet lock on something that's free right now.

The Linux and Chromebook case, since it's a real one

If you're on Linux, this whole question gets sharper: most desktop EDA either has no native build or needs a compatibility layer to run something built for Windows or macOS. A browser sidesteps that completely, because it's the one thing every platform already has. It's the same reason a browser tool is the only real option on a Chromebook, which can't install desktop EDA at all, and it's a decent option on a phone or tablet for a quick edit or a DRC check on the go, even if a bigger screen still wins for a dense board.

If you're evaluating a "free" PCB tool, the questions I'd actually ask are: is this free-as-in-open-source, free-as-in-hosted-tier, or free-as-in-trial-that-ends? What happens the moment you try to actually use it — does it ask for anything before or after it delivers? And is there a live pricing page anywhere, because that tells you whether "free" is the current state or a funnel.

If you want to check the answers for PCBEditor specifically: open the editor first and look around — that part needs nothing — and sign in only once you're ready to have it generate something.

'AI PCB Design Software' Means Six Different Things — Here's How to Tell Them Apart

Dibyaprakash Pradhan — Sun, 27 Sep 2026 12:14:22 +0000

Someone asks "what's the best AI PCB design tool" in a forum, and the replies name a chatbot, a KiCad plugin, an editor with a copilot, and a router that finishes a whole board. All six get called "AI PCB design software." They are not doing the same job, and I think that mismatch is why so many "AI designs PCBs now" claims read as either hype or a demo that never becomes a real board.

I build PCBEditor, which is one of the six. Here's the honest map, including where mine stops.

Six kinds, one label

Chat assistants — ChatGPT, Claude, Gemini — are good at the judgement part: choosing a regulator, explaining why an LDO beats a buck converter here, drafting a netlist as text. They can't operate on a board, because they never had one. They write a description of a design, not the design.

AI add-ons for desktop EDA — MCP servers, plugins that let a model drive KiCad — let a model click the buttons you'd click. The routing and the checks are still whatever KiCad's router and DRC already do. A better operator isn't a different router.

Editor copilots, the way Flux.ai does it, layer an assistant over a traditional schematic and PCB canvas. You're still working in a manual editor with the AI alongside rather than doing the whole thing — a real product decision, not a lesser one.

Schematic and BoM automation — Circuit Mind, ProtoFlow — turns a prompt or a requirement into a schematic, a BoM, sourced parts, sometimes an analysis report. The emphasis is the front end; whether it carries into placement and routing varies a lot between them.

Autonomous place-and-route, like Quilter, starts from a schematic you already have and produces placement and routing from it, usually with real rigor on high-speed work. It starts from a finished schematic. It doesn't write one.

Prompt to board is what I build. A plain-English description goes through parts, a netlist, placement, routing and a design-rule check, out to fabrication files. Dense fine-pitch parts, BGAs especially, are where it's weakest, and you still review the result before ordering. I'd rather say that than not.

The question that actually sorts them

None of the six kinds is "the best." They answer different questions. But there's one distinction that tells you something true about any of them: is the physical part of the board measured, or asserted?

A language model is good at judgement and has no way to measure whether a trace clears a pad by 0.15 mm. That's not a training problem, it's a category problem — the same way a calculator is the wrong tool for writing a poem. So whichever of the six you're looking at, the useful question isn't "how smart is the AI," it's whether the physical output came from something that can measure, or from something that's estimating.

Four checks answer that in about ten minutes, on any of the six: ask for real export files (Gerber, drill, pick-and-place, a BOM — a picture isn't something a fab can build); open them in a viewer the vendor didn't write; take the board file into KiCad, or your fab's own checker, and run the rules again somewhere the vendor doesn't control; and run the same design twice, not a fresh prompt — the same input should give the same board, and it won't if the layout comes from a language model that drifts every time it's updated.

What this looked like on mine

One prompt — "Design a compact 4-layer microcontroller breakout board (approx 45x45mm)…" — produced a 47.51 × 45.00 mm board: 16 parts, all 33 nets routed with 0 unrouted, a design-rule pass reporting 0 errors and 0 warnings. Worth reading critically rather than taking at face value: Quality Gate was off for this run (you can see "QG Off" in the panel), so this is the raw baseline, not the best case. One board is an example, not a proof that every board finishes this cleanly — dense fine-pitch parts are exactly where I'd expect that to break. And the interface has moved on since I took this screenshot on 11 September 2026; the board and the numbers are what matter here, not the UI chrome.

So which one do you actually want

Mostly this comes down to where you're starting from, not which is "most AI." If you already have a finished schematic and need serious high-speed constraint work, an autonomous router built for that is the right tool, not a prompt-to-board one that's still drafting your netlist. If you lay out in KiCad and mainly want better schematic capture and part sourcing, an add-on or a schematic-automation tool fits better than replacing your whole flow. If you want to think out loud about a topology or sanity-check a power budget, a chat assistant is genuinely good at that — I still use one for exactly this. And if you want a first board out of a description with nothing installed, that's the case I built PCBEditor for, free in the browser.

Which of the four checks would your current tool fail? If you've run any of them and one held up better — or worse — than the label suggested, I'd like to know which, and what you tested.

A migrated VM, a dead NTP daemon, and 67 days of silent clock drift

Dibyaprakash Pradhan — Wed, 23 Sep 2026 16:09:45 +0000

Every request we made to an AWS API started failing with a 403.

Not intermittently. All of them, instantly, with the same error repeating once per second:

(403, 'InvalidSignatureException',
'Signature expired: 20260314T090925Z is now earlier than
20260314T091043Z (20260314T091543Z - 5 min.)')

A 403 on AWS usually sends you straight to IAM. Wrong key, expired key, missing permission, bad role. I very nearly went there.

Read the whole error before you fix the error

The thing that saved me was that AWS had already done the work. That message has three timestamps in it, and they are not decoration.

20260314T090925Z is when our box signed the request. That is our clock.
20260314T091543Z is what AWS's clock said when it arrived.
20260314T091043Z is that minus five minutes, the cutoff.

So AWS is telling you, in the error text, exactly how far apart the two clocks are. Ours was 378 seconds behind. Six minutes and eighteen seconds.

SigV4 signatures are valid for five minutes. Our signature was stale the instant it was created. It never had a chance.

The credentials were perfect. The request was perfect. We just could not agree with AWS about what time it was.

What made me confident rather than merely suspicious was that the gap never moved. Every log line, the same 378 seconds:

signed 20260314T090925Z  aws 20260314T091543Z  drift 378s
signed 20260314T090926Z  aws 20260314T091544Z  drift 378s
signed 20260314T090929Z  aws 20260314T091547Z  drift 378s

A clock that is slowly drifting gives you a number that creeps. A clock frozen at a fixed offset means nothing is correcting it at all. That is a different problem, and a much more interesting one.

There was a second witness too. Our logs ship off the box, and each entry carries both the timestamp the application wrote and the timestamp the ingestion service wrote when it arrived. The gap between them was 377.8 seconds. Two independent time authorities telling us the same thing about our own machine.

The cliff

Here is the part worth internalising, because it explains why this felt like a sudden outage rather than a creeping problem.

There is no degradation curve with SigV4. At 4 minutes 59 seconds of drift, everything works perfectly. At 5 minutes 1 second, every single request fails. It is a cliff, not a slope.

So the clock had probably been wrong for a long time before anyone noticed. It just had not crossed the line yet. The day it crossed, a whole class of functionality vanished at once, and it looked like something had broken that morning. Nothing had broken that morning. Something had broken months earlier and only became visible that morning.

Going in

timedatectl was blunt about it:

System clock synchronized: no
              NTP service: inactive

And then the line that reframed the whole thing:

Active: failed (Result: exit-code) since Tue 2026-01-06 09:30:20 UTC; 2 months 7 days ago

chrony had been dead for 67 days. It started 18 seconds after a boot in January, exited, and nothing ever brought it back. The clock had been free-running for months.

Nobody knew. It is a daemon nobody looks at, failing quietly, on a box that was otherwise completely healthy.

My first theory was that chrony had refused the correction. Probing it by hand seemed to confirm it:

$ sudo chronyd -Q 'server 169.254.169.123 iburst'
System clock wrong by 377.877093 seconds (ignored)
chronyd exiting

"Ignored." There it was. chrony saw the offset, decided a six minute jump was implausible, and gave up.

That was real, and it was also not the reason the service was down. I was pattern matching on the first plausible cause and I was wrong. The actual reason only showed up when I stopped probing and tried to start the thing properly.

The actual cause

Step the clock manually first, then start the service:

sudo chronyd -q 'server 169.254.169.123 iburst'
# System clock wrong by 377.880183 seconds (step)

That worked. Clock correct, 378 seconds recovered, AWS calls authenticating again.

Then:

sudo systemctl start chrony

Could not open /dev/ptp_hyperv : No such file or directory
Fatal error : Could not open PHC

ptp_hyperv.

Hyper-V.

We are on EC2.

Line 5 of /etc/chrony/chrony.conf, with a comment that removes all doubt:

# Use Azure platform PTP device
refclock PHC /dev/ptp_hyperv poll 3 dpoll -2 offset 0

This is an Azure config. On an EC2 box. Pointing at a Hyper-V paravirtual clock device that does not exist here and never will. chrony treats a missing refclock as fatal, so it exited at startup. Every time. Regardless of what the clock said.

My "chrony refused the large offset" theory was a real behaviour of the manual probe, but it had nothing to do with why the service was down. The service was down because it could not start at all.

How Azure config ended up on an EC2 box

I had migrated this VM from Azure using AWS Application Migration Service (MGN).

MGN does block level replication. It lifts your disk and boots it on EC2, and it is genuinely good at that. Your application comes across intact, your packages come across intact, your config comes across intact.

Which is the whole point, and also the entire problem.

/etc/chrony/chrony.conf came across intact. It was a perfectly correct file on Azure, where /dev/ptp_hyperv is exactly the right thing to sync against. The moment it landed on EC2 it became a file that kills chrony on boot.

MGN cannot know that. It does not read your config and reason about which lines describe hardware that no longer exists. It moves your disk. Anything in that disk describing the old hypervisor is now a small landmine, armed and waiting for the next restart.

And notice the delay. The migration did not break anything visibly. chrony kept running on its existing process. It was the reboot in January that killed it, because that is when chrony next tried to start and could not find its device. Then the clock drifted quietly for two months until it crossed five minutes and AWS started saying no.

Migration, reboot, drift, cliff. Four events spread over months, and only the last one produced an error message.

The fix

Comment out the Azure device:

sudo sed -i '5s|^|#|' /etc/chrony/chrony.conf

Then a surprise. Grepping for a replacement time source turned up nothing:

$ grep -nE '^[[:space:]]*(server|pool|makestep)' /etc/chrony/chrony.conf
30:makestep 1 3

No server. No pool. The Azure PTP device had been the only time source in the file. Removing it left chrony with a step policy and nothing to step toward.

This matters more than it sounds. If I had just commented the line out and started the service, I would have got a running, healthy looking daemon that syncs from nothing at all. Green in systemctl status, quietly drifting back toward the same cliff. That is a worse failure than the crash, because the crash at least left a corpse.

On EC2 the answer is the link local Amazon Time Sync Service:

sudo tee -a /etc/chrony/chrony.conf >/dev/null <<'EOF'

# EC2: Amazon Time Sync Service (replaces the Azure PTP refclock above)
server 169.254.169.123 prefer iburst minpoll 4 maxpoll 4
makestep 1.0 -1
EOF

Two notes on that.

I appended to chrony.conf directly rather than dropping a file into conf.d/, because this config has no confdir directive. I had already written the file to conf.d/aws.conf before checking, and it would have sat there being ignored forever. Worth a grep before you assume a drop in directory is wired up.

And makestep 1.0 -1 replaces the existing makestep 1 3. The default only allows stepping during the first three updates after startup. After that chrony will only slew, and slewing 378 seconds takes effectively forever. -1 means step whenever it is needed, which is what you want on a VM that can be paused, migrated or snapshotted out from under you.

Result:

^* 169.254.169.123    3   4   77    2   +653ns[ -983us] +/- 339us

653 nanoseconds. From 378 seconds.

One last step, because the hardware clock was still 106 seconds out and would have reintroduced skew on the next boot:

sudo hwclock --systohc

What I would tell past me

Read the whole error. AWS had handed me the exact drift, in seconds, inside the message itself. I nearly went to IAM because 403 looks like a permissions problem and I stopped reading at the status code.

A constant offset is a different bug from a drifting one. Drift means nobody is correcting. A frozen number means something tried, failed, and stopped. That distinction took me straight to a dead daemon.

After a lift and shift migration, audit for the old hypervisor. Not just chrony. Grep your configs for hyperv, xen, vmware, virtio, waagent, anything naming a device or agent from the platform you left. MGN moved the disk faithfully. Faithfully includes the parts that are now wrong.

Reboot the migrated box on purpose, early. Our failure was armed at migration and did not fire until a reboot months later. The gap between cause and symptom was long enough that nobody connected them. A deliberate reboot the same week would have surfaced it immediately, next to the change that caused it.

Alert on clock offset. chronyc tracking gives you the number for free. Alert at 60 seconds, well below the five minute cliff, and you get warned during the slope instead of discovering it at the edge.

When you fix a daemon, verify it has something to do. Running is not the same as working. A time daemon with no time source is green in every dashboard and wrong in every way that matters.

The whole thing came down to one line of config that was completely correct in the datacentre it was written for, and quietly fatal in the one it ended up in.

Building collections calling in India? The regulation is the spec.

Dibyaprakash Pradhan — Tue, 22 Sep 2026 16:13:52 +0000

If you are building outbound calling for Indian lending, the interesting
constraints are not technical. They are regulatory, they are changing right
now, and most of them have to be enforced in the architecture rather than in a
prompt.

The window

Recovery contact in India is restricted to 8:00 AM - 7:00 PM. Not just
calls — SMS, WhatsApp and physical visits too. It applies to NBFCs, fintech
lenders, and any third-party agency acting for them.

Eleven hours sounds generous until you subtract hours when nobody answers. A
salaried borrower is commuting, in a standup, or on a shop floor for most of
it. Every lender is aiming at the same narrow slice.

The architectural consequence: a collections system is not throughput-limited
by headcount. It is limited by a legally fixed, partially unusable window that
no amount of hiring widens.

What is changing

RBI issued draft Responsible Business Conduct directions in May 2026, then
amendments in August 2026 consolidating recovery conduct into a single
framework across banks, NBFCs and housing finance companies. Reporting puts
commencement at 1 January 2027.

Direction of travel matters more than any single clause. Accountability for
agent conduct moves up to the regulated entity: due diligence before engaging
an agency, verification of individual agents at onboarding and periodically
after, documented code of conduct, borrower disclosure before first contact,
and monitoring that produces evidence rather than assurances.

RBI fined Bajaj Finance ₹2.5 crore in connection with recovery agent conduct.
Outsourced behaviour lands back on the lender.

The compliance question you will be asked is not whether your policy prohibits
harassment. It is whether you can demonstrate, call by call, that it did not
occur.

The certification angle nobody budgets for

The draft framework contemplates mandatory IIBF certification for recovery
agents. Put that next to attrition on a collections floor: every seat you fill
must be certified, and every seat that turns over must be certified again
before that person can legally call.

A voice agent is not a person requiring certification. Its conduct is defined
in configuration and identical on call one and call one hundred thousand. The
compliance surface moves from "did this individual behave correctly today" to
"is this script correct" — a question you can answer in advance.

Certification scales with headcount and attrition. Script review scales with
neither.

The refusal set

Most vendor material describes what an agent can do. For collections, the
useful spec is what it must be structurally unable to do:

Refuse to call outside the window. Enforced at the dialer, in the
borrower's local time. A prompt instruction is not a control; a scheduler that
cannot emit the call is.

Refuse to exceed frequency caps. Per borrower, per cycle, counted across
voice + SMS + WhatsApp together — because the borrower experiences them
together and a complaint will describe them together.

Refuse to discuss the debt with a third party. If the person answering is
not the borrower, state purpose generically and end. Disclosing a debt to a
family member is the classic harassment finding.

Agent:  नमस्ते, मैं XYZ Finance से बोल रहा हूँ।
        क्या मेरी बात राजेश कुमार जी से हो सकती है?
Caller: वो घर पे नहीं हैं, मैं उनकी पत्नी हूँ। क्या बात है?
Agent:  कोई बात नहीं। यह एक personal call है,
        मैं बाद में कोशिश कर लूँगा। धन्यवाद।

No amount. No due date. No mention of a loan. Even to a spouse.

Refuse to escalate tone. Pressure tactics are what the conduct rules exist
to eliminate. An agent that cannot be provoked into them beats one
instructed to avoid them.

Hand off rather than improvise. Dispute, hardship, bereavement — anything
the script does not cover routes to a human. An agent improvising through a
hardship disclosure is the worst available outcome.

DPDP: consent is a state, not a checkbox

India's Digital Personal Data Protection Rules were notified November 2025,
with substantive obligations phasing in through 2027. For collections:

Voice recordings are personal data
Consent must be purpose-specific, not blanket
Consent logs must be timestamped
Consent is withdrawable at any time
Penalties reach ₹250 crore for significant data fiduciaries

"Purpose-specific" breaks legacy practice. Consent captured at origination for
servicing communication is not self-evidently consent to record a recovery
call for quality assurance. Different stated purposes.

The architectural bit: withdrawal has to propagate to the dialer before the
next attempt, not at the next nightly sync. If a borrower withdraws at 11:00
AM and your system calls at 3:00 PM because the suppression list refreshes
overnight, the architecture produced the violation.

The honest framing

Voice AI does not remove regulatory exposure. It moves it — from the
unpredictable behaviour of a rotating certified workforce to the reviewable
content of a script and the enforced behaviour of a dialer.

That is a smaller surface, and critically, one you can audit before a
complaint rather than after.

I work on Fonix.AI. Longer version
here.

"Voice AI in India" describes four different businesses

Dibyaprakash Pradhan — Tue, 22 Sep 2026 07:33:24 +0000

Every "top 10 voice AI companies in India" article ranks vendors on one
table. That format assumes the ten companies are substitutes for each other.

Mostly they are not.

If two vendors on your shortlist would be integrated by different departments,
they are not competitors. They are answers to different questions, and one of
those questions is the wrong one for you.

The four categories

1. Telephony and infrastructure

Sells connectivity: numbers, SIP trunks, routing, programmable voice. Voice AI
is a layer on a business that was already about carrying calls.

Buy here when: the constraint is telephony reach and reliability, and you
have engineers to build the intelligence yourself.

Evaluate on: carrier reach, uptime, regulatory registrations, call quality
at volume.

2. Developer APIs and platforms

Sells building blocks: an API to construct agents, tool-calling, provider
choice for speech and language models. Documentation is the product surface.

Buy here when: you have an engineering team that wants control and will own
the outcome.

Evaluate on: docs quality, latency, provider flexibility, how per-call
pricing behaves at scale.

3. Enterprise CX suites

Sells a contact-centre platform where voice AI is one channel alongside chat,
email and agent-assist. Long procurement, deep integration, priced
accordingly.

Buy here when: you are replacing a contact-centre stack, not adding a
capability.

Evaluate on: integration depth, agent-assist quality, support model.

4. Vertical and outcome products

Sells a job done: collections calling, appointment reminders, lead
qualification. Configured rather than built, deployed in days.

Buy here when: you want the result and do not want to own the stack.

Evaluate on: domain fit, compliance posture, time to deploy, language depth.

Roughly who sits where

Usual caveat — companies move, expand and reposition, and several operate in
more than one column. Verify current positioning directly.

Infrastructure: Exotel, Plivo, Twilio (global)
Developer API: Bolna.ai, plus global platforms operating in India
Enterprise CX: Yellow.ai, Haptik, Gnani.ai
Vertical product: Skit.ai (collections), Subverse (BFSI), Fonix.AI (where I work)

The category boundaries are more stable than the membership. A developer API
platform that adds vertical templates is still sold, priced and supported like
a developer platform — and that is what determines whether it fits your team.

Choose by constraint, not feature

Feature tables converge; every vendor eventually lists every feature.
Constraints do not converge, and they eliminate faster:

Do you have engineers to own this? No rules out category 2 regardless of quality.
Can the data leave your infrastructure? No makes on-premise the first filter, not a later question — and eliminates most cloud-composed stacks.
Are your calls code-switched? If callers mix Hindi and English mid-sentence, monolingual accuracy claims are not evidence. (Why this breaks things.)
Is volume predictable? Per-call and flat pricing fail in opposite directions.
Is the use case regulated? Collections, healthcare and insurance carry conduct rules constraining what the agent may say. That is a product question, not a config one.
How fast do you need it live? Weeks vs quarters separates category 4 from category 3 more reliably than any feature comparison.

Where we do not fit

I work on Fonix.AI, category 4. Stating the limits is more useful than
claiming the whole map:

Want to compose your own stack and pick model providers per call? A developer API platform fits better than we do.
Replacing an entire contact-centre suite across chat, email and voice? An enterprise CX platform is the right shape; we are not.
Need carrier-grade telephony as the product rather than an input? Buy infrastructure.

We fit when the constraint is Indian language depth on real code-switched
calls, a regulated use case with conduct requirements, and deployment measured
in days.

Full version.

Where to get visibility for your startup without doing PR?

Dibyaprakash Pradhan — Sun, 20 Sep 2026 10:52:12 +0000

As we dive deeper into market dynamics, think about the content we see. think about the startups getting funded and especially the buzz before they get funded. Students, Professionals, some random guy sitting on a boat catching fish somewhere in the sea around the Andaman and Nicobar islands. everyone suddenly starts putting their perspective on the funding news, as if they were always waiting for this glorious day in their life.

but wait, this is not just blind PR.

if you think about investors, they like to lead rounds. the investors who join later are similarly valuable and contribute to that specific round. and the company getting the investment? they don't mind burning some of their previous round's marketing budget to create the buzz.

come on, what else would you have done?

used that money to solve a real problem? to build something actually valuable?

it's a loop. it's a paradox.

If you are a founder building something meaningful, there is a good chance you will also come across days like these in your journey. and yes, you might do it too.

but wait.

If you are a small, fresh, young startup and you don't have blind catastrophic bundles of money to throw into the air, then what???

Your competitor is being loved by the fisherman in andaman and you are not even being noticed by the other business that actually needs you.

it's a clear loss for you, isn't it?

what do you do now?

keep hoping for the day they fail badly and some random ray of sunshine somehow finds you inside the cave where you are living, building and dying?

or leave everything and go hide in a place full of shit just to look like shit, because nobody gives a gargantua duck about that place or its people?

or stay in your own latveria and start casting runes?

huhhh.

okay, enough.

you go out and find the options you have. and yes, you just unlocked a whole new world of possibilities simply because you don't have shitting shit to shit.

and it's not bad.

there are thousands of free platforms where you can gain visibility. make open source contributions. showcase your startup. let people know you're from a place where there are real people, not joongering eustics who just want to read and write for blind catastrophic bundles.

yea, you get it.

go list your startup on places like F6S, Crunchbase, The Org and StartupReader Im builidng. write articles. get organic views from people who are actually looking for the exact solution you are building because they have the exact problem you're trying to solve.

and let your competitor keep screaming and asking for more, more, more bundles to build the world on top of the world.

remember, if you get visibility, or in simple words, if you are visible, investors can find you. customers can find you. people who actually need what you're building can find you.

visibility doesn't magically make a startup valuable.

but being valuable while remaining completely invisible doesn't help much either.

let's talk in the comments. i'm leaving you with a weird time-bending trick just to feel good.

say:

i have written an article on dev.to tomorrow.

might sound completely wrong in english, but somehow it sounds good.

so...

what did you do tomorrow????

Text to PCB: How a Prompt Actually Becomes a Manufacturable Board

Dibyaprakash Pradhan — Tue, 15 Sep 2026 08:52:00 +0000

"Describe a circuit board and get a finished PCB" is the kind of claim that makes engineers close the tab. And they are right to be suspicious — most of the time, "AI designs your PCB" means a language model produced a plausible-looking picture that no fab would accept.

So let me skip the pitch and explain how a prompt can actually become a manufacturable board, and where the line is between the part that works and the part that does not.

The one insight: designing a board is two different jobs

A PCB design has a judgement half and a measurement half, and they need completely different tools.

The judgement half is choosing parts and deciding how they connect. What regulator suits this input range and load? Which microcontroller? Does this sensor talk I2C or SPI? This is language-shaped reasoning over a huge body of prior art — exactly what large language models are good at.

The measurement half is everything physical. Where does each component sit on a board with real dimensions? Does this trace clear that pad by 0.15 mm? Can these nets be routed across four layers without crossing? None of that is a matter of opinion. It is geometry and hard constraints, and it has an objectively correct answer that you can check with a ruler.

The mistake almost every "AI PCB" demo makes is asking one tool — the language model — to do both halves. It cannot do the second one. It has no way to measure whether a trace meets clearance, so it estimates, and an estimate is not a board.

What the pipeline actually looks like

Split the two halves and the flow becomes honest:

You describe the board. Plain English: "an ESP32 sensor board with USB-C power, a LiPo charger, and two Qwiic connectors."
The LLM drafts intent. It selects parts and proposes a netlist — the judgement half, where it is strong.
A deterministic engine builds the board. It places the components and routes the copper. This is a classic geometric search against hard constraints — the same category of software as a traditional autorouter and design-rule checker, not a text generator.
It checks and exports. A design-rule check runs, unrouted nets are reported by name, and the result exports to Gerber, drill, pick-and-place, and BOM.

The AI decides; the engine proves. That division is the whole reason the output is buildable rather than merely convincing.

Why the routing has to be deterministic

There is a second, subtler reason to keep routing out of the model's hands: reproducibility.

If a language model "routes" your board, the result changes with temperature, with phrasing, and with every model update. Run it twice and you get two boards. That is disqualifying for hardware, where you need the same input to produce the same output every time.

A deterministic router does not have that problem. Same design in, same board out — and it does not drift when the model behind the judgement half is swapped or upgraded. The reproducibility is not a nice-to-have; it is what makes the tool trustworthy.

The honest failure mode

No router completes every board, and any tool that claims otherwise is lying to you. The useful question is what happens when it cannot finish.

The wrong answer is a completion percentage — "94% routed!" — that hides which nets failed. The right answer is to name the exact nets it could not route, because that tells you what to fix. And most of the time the fix is not a smarter router; it is placement. Two connectors at opposite corners with a dense IC between them cannot be recovered by any routing algorithm. Naming the stuck nets points you straight at the components to move.

Where this leaves "text to PCB"

It is real, but it is not magic, and the honest version is more useful than the magic version:

The LLM turns your description into parts and a netlist — a strong first draft you review.
A deterministic engine does the placement, routing, and rule-checking — the part with a correct answer.
You get fabrication files a fab will actually accept, or a precise list of what could not be finished.

If you want to watch a prompt become a placed, routed, checked board, PCBEditor does exactly this in the browser — describe a board, and it drafts, places, routes, checks, and exports.

PCB Design on Mobile: Can You Really Design a Board on a Phone, Tablet, or Chromebook?

Dibyaprakash Pradhan — Mon, 14 Sep 2026 06:45:42 +0000

If you have ever tried to open KiCad on your phone, you already know how this goes. You search "KiCad on Android," find a viewer app that lets you look at a board but not touch it, and close the tab a little disappointed.

So let's start with the honest answer, and then get to what actually works.

Can you run KiCad on mobile?

No. KiCad is a desktop application for Windows, macOS, and Linux. There is no official KiCad app for Android or iPad, and iPadOS/Android cannot run the desktop build.

That is not a knock on KiCad — it is an excellent, free, professional tool. It simply was never built to run on a phone. The third-party "KiCad viewer" apps you will find on the Play Store and App Store are exactly that: viewers. They let you inspect a .kicad_pcb file at the workbench while you solder, which is genuinely handy, but you cannot design in them.

The same is true for most desktop EDA. Altium, Eagle, and friends are desktop-bound. If your only machine right now is a phone, a tablet, or a Chromebook, the desktop-tool answer is a dead end.

The device-by-device reality

Android / phone. No native design app for the desktop tools. Viewers only. To actually edit, you need something built for the browser.

iPad. Same story — no native iPad app for desktop EDA, and viewer apps only let you look. What does work on an iPad is a PCB tool that runs entirely in Safari or Chrome.

Chromebook. This is the biggest gap of all. A Chromebook cannot install KiCad, Altium, or most desktop EDA at all. For a Chromebook, a browser-based tool is not a compromise — it is the only option, and it works fully.

What actually works: the browser

The pattern across every one of those devices is the same: the thing they all have is a modern web browser. So the tools that work on mobile are the ones that live entirely in the browser — no install, no app store, no OS compatibility to fight.

A few browser-based options exist. EasyEDA (backed by JLCPCB) is a long-standing, free, cloud-based editor. Flux is a collaborative browser ECAD with an AI copilot. And there are newer mobile-native editors emerging in this space too.

The point is not which logo you pick — it is that the browser is what unlocks mobile PCB design. Everything else follows from that.

Why "describe it in text" matters more on a phone

Here is a nuance that is easy to miss. On a small screen, the hardest part of PCB design is not the physics — it is the fiddliness. Dragging a 0402 resistor into place with your thumb is miserable.

This is exactly where an AI-native, browser-based approach earns its keep on mobile. Instead of manual placement on a cramped screen, you describe the board in plain English — "an ESP32 dev board with USB-C, a LiPo charger, and a couple of Qwiic connectors" — and let the tool draft the parts, placement, and routing. You review and adjust rather than building pixel by pixel with your fingertips.

The important thing, though, is how that AI is used. A language model is good at judgement — picking parts, proposing a topology. It is not good at measurement — whether a trace clears a pad by 0.15 mm is a calculation, not an opinion. The reliable tools keep those separate: the AI decides intent, and a deterministic engine does the geometry, the routing, and the design-rule check. That is what makes the output something a fab will actually accept.

Is designing on a phone genuinely usable?

Honest answer: for a large, dense board, a bigger screen is still easier, and always will be. But that is not the only kind of work.

Sketching an idea the moment you have it, wherever you are.
Editing a small board — a breakout, a sensor module, a simple power supply.
Reviewing a layout or running a DRC on the train.
Continuing a design you started on a laptop, on your phone, then a tablet — because browser-based work is not trapped on one machine.

For those, a phone or tablet is not a toy. It is a real tool — as long as the software was built to run there.

The takeaway

KiCad on mobile: no native app; viewers only.
iPad / Android / Chromebook: the browser is the answer, and for a Chromebook it is the only answer.
On a small screen: describing a board beats dragging parts, provided a deterministic engine — not a chatbot — does the actual routing and checking.

If you want to try designing a board on whatever device you are reading this on, PCBEditor runs entirely in the browser — describe a board, let it place and route, run the design-rule check, and export Gerber, drill, pick-and-place, and BOM. No install, on any device.

This article is also published on pcbeditor.com.

Can GPT-6 Astra Generate a PCB?

Dibyaprakash Pradhan — Sat, 05 Sep 2026 07:37:51 +0000

OpenAI just dropped a bomb in the AI industry, and as per the demo they have shown, they illustrated a few people talking to GPT to get their tasks done, like creating a 3D model using CAD software, building a game with that 3D model, and accessing the slicer on your desktop to slice it and send it for 3D printing. Sounds fascinating, right?

Now let's look at the closer view. I have used Antigravity by Google, Claude Code, and Codex with GPT-5.6 and older models. One thing I have noticed is that the more agentic the system is, and the more iterations it does, the more work it gets done for you.

GPT-5.6 Sol costs $4/1M input and $20/1M output. It works for me for things like FE testing, browser control, and some desktop software control as well. So what do you get with GPT-6 Astra at $10/1M input and $50/1M output? That is a flat 2.5x across input, cached input and output. And on ARC-AGI-3 it scores 99.9%, against 30.2% for Claude Opus 5 and 7.8% for GPT-5.6 Sol.

Let's be fair about that price: it's a good deal. Going from 7.8% to 99.9% on a reasoning benchmark for 2.5x the token cost is not expensive, if reasoning is your bottleneck.

The footnote on that 99.9% is the interesting part

ARC Prize published the conditions, and they are worth reading carefully.

The 99.9% comes from OpenAI's Provider Adapter harness, which preserves opaque reasoning state between requests so the model can reuse prior work. Cost of that run: $18,817.

Run the same model through the Standard harness, which is stateless and provider-neutral, and it scores 62.7%. That run cost $26,098. More money, a third of the score.

Same model. Same weights. The difference is entirely in the scaffolding around it.

That is the most useful fact in the whole launch, and it is not the one on the chart. It says the system you wrap a model in can be worth more than 37 points of benchmark, which is the same reason a purpose-built tool beats a general model clicking through someone else's GUI.

And on computer use specifically, the numbers are real: 72.6% on OSWorld 2.0 against 65.7% for Sol, finishing tasks in about 40 minutes where the previous model took 75. Astra genuinely operates desktop software better than anything before it.

But operating a router is not being a router

Point that same model at a PCB and reasoning isn't the bottleneck. Geometry is. You are paying 2.5x for a much better operator of a tool that still has to do the routing itself, and routing is not a reasoning problem.

So can it generate an end-to-end PCB?

The answer might be yes or no, because the question is wrong.

It's a great model that can use your desktop tools, but it doesn't have a natively built PCB generation engine or a CPU-heavy routing engine. It's just good at using tools. Whereas AI-native tools like PCBEditor are built to generate PCBs using AI. So yes, maybe you can use GPT-6 Astra to generate PCBs by driving tools like KiCad and PCBEditor.

What "CPU-heavy" actually means

Routing a board is a constrained search through physical space. A router has to find a path for every net across a grid of the whole board, on every layer, while respecting clearance to every other piece of copper, and then undo and retry when a later net blocks an earlier one. On a dense multi-layer board with fine-pitch parts, that runs to millions of grid evaluations and takes minutes of real CPU time.

None of that work is language. A model that reasons better does not reduce the number of cells a router has to evaluate, because the router is not reasoning. It is measuring.

And here's the thing: a model driving KiCad through a GUI still has to call KiCad's router. That router does the same millions of evaluations whether a model asked for it or you clicked the button yourself. The intelligence and the computation are separate costs, and only one of them is billed per token.

About that PCB Generation in Demo

The image published by OpenAI is a screenshot of a KiCad desktop window. It reads as though the model generated a PCB, when what it shows is a model operating a tool, the same way you, I, or any other desktop-controlling AI model would.

That distinction matters more as these models get better, not less. Astra is genuinely the best desktop operator that has shipped. The engine underneath the tool is a separate problem, and it will not be solved by the next model either, because it was never a model problem.

Where would you put the line? If you have built something where a frontier model drives a domain tool, I would like to know where the model stopped being the hard part. For me it was the moment the search space stopped fitting in a context window and started fitting in a CPU.

I asked Claude to design a PCB. Here's exactly where it stopped working.

Dibyaprakash Pradhan — Wed, 02 Sep 2026 08:49:37 +0000

I have been building an AI-native PCB editor for a few months. Before I wrote a line of it, I did the obvious thing: I opened Claude and asked it to design a board.

The result taught me more about where AI belongs in hardware than any amount of planning would have.

What went well, and it genuinely did

I asked for a 5V to 3.3V regulator circuit for an ESP32 sensor node.

Claude gave me a sensible answer. It picked an AMS1117-3.3, explained why an LDO was fine here rather than a buck converter given the current draw, and told me to put a 10µF on the input and 22µF on the output. When I asked why the output capacitor was larger, it explained the LDO's stability requirement properly.

Then I asked for the netlist. It gave me one, in text, and it was structurally reasonable:

VIN  -> U1.3, C1.1
GND  -> U1.1, C1.2, C2.2, U2.GND
3V3  -> U1.2, C2.1, U2.VDD

If you are learning electronics, this is genuinely useful. It is a competent engineer talking you through a decision.

Then I asked for the board

This is where it stopped, and the way it stopped is the interesting part.

I asked Claude to place the components on a 20x20mm board and route the traces. It produced coordinates. They looked plausible. They were not.

Two components overlapped. A trace ran through a pad it had nothing to do with. The board outline did not enclose everything. And there was no way for it to know any of that, because it was generating text that described a board, not operating on a board.

That distinction is the whole thing.

Why it is structural, not a model problem

My first instinct was that a better model would do better. That is wrong, and understanding why saved me from building the wrong product.

Routing a PCB is a search problem over physical space with hard constraints. You need to know that this trace is 0.2mm from that pad, that the clearance rule says 0.15mm, and therefore this route is illegal. That is a geometry query against a spatial index. A language model has no spatial index. It has never measured anything.

The same applies to design rule checking. DRC is not an opinion about whether a board looks right. It is a set of measurements against a set of thresholds. A board either has 0.15mm clearance everywhere or it does not, and the answer must be computed, not recalled.

And fabrication output makes it concrete. Gerber and Excellon are exact formats. A fab does not accept a plausible drill file.

So the limit is not "Claude is not smart enough yet." The limit is that these are the wrong kind of problem for a text generator, in the same way that a calculator is the wrong tool for writing a poem.

What I built instead

The split I landed on in PCBEditor:

AI decides. Algorithms verify.

Part selection: AI. Which regulator, which sensor, what topology. Genuine judgement, and a model is good at it.
Footprints: library first, AI only as fallback. A footprint is a fact defined by IPC-7351, not an opinion. When we do have to generate one, it is badged unverified so nobody mistakes a guess for a datasheet.
Placement: constrained AI. The thermal and signal-integrity rules are code. The model picks among candidates that already satisfy them. Judgement inside a fence.
Routing: zero AI. A router written from scratch in Rust, doing multi-layer A* with rip-up-and-reroute, and producing a graph-based connectivity proof. It proves its output rather than asserting it.
DRC: zero AI. A rule engine with deterministic self-heal.

The test I hold it to: if I swap the model tomorrow, the boards must still be correct. That is only true if correctness lives in code, not in the model.

The counter-intuitive part

Constraining the AI made it more useful, not less.

When I let the model place components freely, I got plausible nonsense. When I gave it a set of pre-validated candidate placements and asked it to choose, I got good boards. Same model. The difference was that the second version could only produce valid answers.

I think this generalises. The interesting question for most AI products is not "how do we get the model to do more" but "what is the smallest set of decisions we can hand it, where being wrong is recoverable."

So: is Claude useless for PCB design?

No, and I would be lying if I said so. I still use it as a design partner. It is excellent for talking through a topology, sanity-checking a power budget, or explaining why my decoupling is in the wrong place.

It just cannot hand you a board. Nothing that generates text can, and that is fine, because that was never the hard part.

If you want to see the split running on a real board, the editor is free and needs no install: pcbeditor.com.

Where would you draw the line? If you have built something with a similar probabilistic/deterministic split, I would like to know where you put the boundary, and whether you got it right the first time. I did not.

I built an AI PCB designer. The routing engine has no AI in it, here's why.

Dibyaprakash Pradhan — Tue, 01 Sep 2026 10:53:48 +0000

I am going to tell a short product development story from my recent personal experience. AI vs No AI, what I have chosen and why.

When it comes to deterministic systems, you always have to rethink choosing AI for what parts of the system. When I started building PCBEditor.com it was a similar challenge for me.

When you talk about PCB design, there are different stages. First schematics. You need to decide what and which electronics parts you want to use. For that, I had built a product called AI Inventory Management: you can upload the invoices of your purchases and you can use those parts for designing your PCBs.

Next is electrically valid netlists, footprints (footprint generator using AI), ball-map generation using AI. What I decided to do is a hybrid approach, which means not everything should be generated by AI. Instead, building internal libraries as well, which can be reliably used.

Then there comes the placement engine. You need to calculate the placements, so what I did is set multiple different rules like thermal warnings, electrical signal fluctuation rules, etc., and let my AI model (Fortza decide which is the best placement option to pick for the current design.

Then comes DRC, hundreds of code files with thousands of lines in them. It ensures the board passes the DRC check, and then you can 3D view it. Once the board is generated you always want to see a 3D view of it so that you know how it will look when it is printed. For that, finding officially licensed 3D STEP files can be done using our AI model.

Then there are a few important stages like layer selection and quality gate verification. These all happen in an agentic system with more than 200 expert AI agents working together to produce the best possible industry-standard outcome for your designed PCB.

I would love to hear from people out here. Have you ever tried designing a PCB using AI? What do you think the split should be between probabilistic and deterministic usage in this use case? 50-50? 60-40? 90-10?