DEV Community: Dibyaprakash Pradhan

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?

We Open-Sourced 4,008 Multi-Turn Empathy Conversations for LLM Training

Dibyaprakash Pradhan — Wed, 19 Aug 2026 11:29:55 +0000

Building conversational AI that can generate a technically correct response is relatively straightforward. Building one that responds appropriately when a user is frustrated, grieving, exhausted, lonely, or emotionally overwhelmed is considerably harder.

At AntEngage, we have been exploring this problem while developing emotionally intelligent conversational AI.

As part of that work, we are releasing the AntEngage Empathy Conversation Dataset, an open dataset containing 4,008 AI-synthesized multi-turn conversations with 79,616 dialogue turns.

The dataset is intended for researchers and developers working on conversational AI, NLP, large language models, empathetic dialogue, affective computing, and instruction tuning.

Dataset at a glance

4,008 multi-turn conversations
79,616 user and assistant dialogue turns
19.9 average turns per conversation
Up to 20 turns per conversation
Language: English
Formats: JSONL and CSV
Data source: AI-synthesized
Real user data: None
Personally identifiable information: None

The dataset contains conversations around situations where conversational systems often need more than a generic response.

Examples include:

grief and anticipatory loss
caregiver burnout
loneliness
emotional exhaustion
workplace stress
parenting challenges
social isolation
guilt and emotional numbness
hospital and ICU waiting
end-of-life situations

Why multi-turn empathy?

Empathy in conversational AI is not simply a sentiment classification problem.

A model may recognize that a message is negative while still producing a poor response.

Consider a user saying:

I don't know how I'm supposed to go home and act normal.

A conversational system needs to understand more than whether this sentence expresses sadness.

It needs to maintain context, acknowledge the emotional state appropriately, avoid making unsupported assumptions, and continue the conversation naturally.

That becomes even more challenging across 10, 15, or 20 dialogue turns.

This is why the dataset focuses on multi-turn interactions rather than isolated prompt-response pairs.

How the dataset was generated

The conversations were produced using a structured synthetic data generation pipeline.

The process broadly consisted of four stages.

1. Domain sampling

We selected broad empathy-related domains and emotional situations to encourage diversity across conversations.

2. Scenario generation

Specific situations were generated within each domain rather than repeatedly generating conversations from a small collection of generic prompts.

3. Multi-turn dialogue generation

The scenarios were expanded into conversations containing alternating user and assistant turns.

4. Automated quality verification

Generated conversations were passed through automated checks intended to evaluate characteristics including coherence, naturalness, diversity, and safety.

The result is a collection of 4,008 conversations containing 79,616 dialogue turns.

Dataset structure

The primary representation is JSONL.

Each record represents an entire conversation and follows a structure similar to:

{
  "id": "empathy_000001",
  "source": "AntEngage-v2",
  "language": "en",
  "domain": "empathy",
  "num_turns": 10,
  "conversation": [
    {
      "role": "user",
      "content": "..."
    },
    {
      "role": "assistant",
      "content": "..."
    }
  ]
}

A flattened CSV representation is also available for users who prefer tabular analysis.

The CSV contains one row per dialogue turn with fields for the conversation identifier, turn index, role, content, and total conversation length.

Potential uses

We believe the dataset can be useful for several areas of research and development:

LLM instruction tuning
empathetic dialogue generation
conversational AI
dialogue system evaluation
affective computing
human-AI interaction research
response generation experiments
conversational model benchmarking

When creating training, validation, and test sets, we recommend splitting at the conversation level rather than the individual dialogue-turn level. Otherwise, turns from the same conversation could appear in both training and evaluation data.

Privacy and ethical considerations

An important characteristic of this release is that the conversations are synthetic.

The dataset does not contain conversations collected from AntEngage customers or real users, and it does not contain personally identifiable information.

Some conversations discuss emotionally sensitive subjects such as grief, loneliness, caregiver burnout, and end-of-life situations. The dataset should therefore be treated as research data for conversational AI rather than as clinical guidance.

It is not intended to replace professional medical or mental health advice.

Where to get the dataset

The dataset is openly available through multiple research and developer repositories.

GitHub:
https://github.com/AntEngage/datasets

Hugging Face:
https://huggingface.co/datasets/antengage/empathy-conversations

Zenodo:
https://doi.org/10.5281/zenodo.21789317

Kaggle:
https://doi.org/10.34740/KAGGLE/DS/11526980

AntEngage:
https://antengage.com/datasets

The Zenodo record provides a persistent DOI for academic citation.

Citation

If you use the dataset in research, benchmarks, applications, or other public work, please cite:

Pradhan, D. (2026).
AntEngage Empathy Conversation Dataset (Version 1.0.0) [Data set].
AntEngage Technology Private Limited.
https://doi.org/10.5281/zenodo.21789317

What's next?

This release is part of our broader work around the AntEngage Language Model (AELM) and emotionally intelligent conversational AI.

We are interested in seeing how the community uses the dataset for fine-tuning, evaluation, benchmarking, and conversational AI research.

If you experiment with the dataset, find problems in it, build something with it, or have ideas for improving future releases, we'd be interested in hearing about your results.

The dataset and related resources are available through the AntEngage open datasets repository.