AI in Product Development: Where It Helps and Where It Does Not

Most writing about AI in product development is either hype or dread. Neither helps if you are building a real product. A more useful start is to notice that the phrase covers two different things, with different risks: AI as a tool you build with, and AI as a feature you build into the product.

We are a small studio that works on both. We use AI in our own work, and we build products where AI is the feature. This post says what the evidence shows, what we do, and where AI does not help, especially once there is hardware involved.

Two different questions

• AI in how you build. Does it make your team better at designing, coding, testing and documenting? This is about your process, and the answer depends on the task and the person.
• AI in what you build. Should the product itself do something with a model, such as turn speech into text or answer from your own data? This is about the product, and the answer depends on cost, privacy and what happens when the model is wrong.

Mixing them up causes a lot of confusion, so we take them one at a time.

AI in how you build: what the evidence says

The honest summary is that results depend on the task, the codebase and the person, and that people are poor judges of their own speed.

• A controlled task, 2023. In a controlled experiment published as a preprint in February 2023, developers who had an AI pair programmer finished one task, writing an HTTP server in JavaScript, 55.8% faster than a control group. It is one well-defined task, not a project.
• Real work, 2025. METR ran a randomized trial with 16 experienced open-source developers working on 246 real issues in repositories they knew well. With AI tools allowed, they took 19% longer. Before the study they expected a 24% speed-up, and afterwards they still believed AI had sped them up by 20%.
• A follow-up, 2026. In February 2026 METR reported new estimates for late 2025: tasks took 18% less time with AI for returning developers (confidence interval from 38% shorter to 9% longer) and 4% less for newly recruited ones (15% shorter to 9% longer). METR also said the data is unreliable, because 30% to 50% of developers said they held back tasks they did not want to do without AI, which skews the comparison.
• What developers say. In the Stack Overflow 2025 survey of about 49,000 respondents, 84% were using or planning to use AI tools, and more distrusted the accuracy of the output (46%) than trusted it (33%).

All of this is about software developers. None of it measures hardware work. Our takeaway is practical: do not assume a speed-up, measure it on your own work, and keep a person responsible for every output. We make no promise to clients that AI makes a project faster or cheaper.

Where AI helps us, and where it does not

In our software work, we use AI assistants where the task is mostly text and an engineer can check the result:

• Drafting and refactoring code, which an engineer reviews and tests before it is merged.
• Writing tests, documentation and test plans.
• Searching long documents, such as datasheets and standards, for the section that answers a question, then reading that section ourselves.
• Trying several interface variants quickly before choosing one with the people who will use it.

It does not help, or helps little, with the parts that decide whether a product works:

• The physical world. A board has to be built, powered and measured. Radio range, battery drain and sensor noise show up on the bench, not in a chat window.
• Trade-offs across disciplines. Cost, battery life, size, manufacturing and user experience pull against each other. Weighing them needs the whole picture and knowledge of the factory, the market and the client.
• Users. Watching someone hesitate in front of a prototype tells you things no model has seen.
• Responsibility. Under EU rules, CE marking is a declaration by the manufacturer that the product meets the requirements. A tool cannot sign that for you.

Can AI design a PCB?

Tools that try exist. Flux, a browser-based design tool, describes its AI as an "AI hardware engineer" that turns a plan into a schematic, lays out components and runs design rule checks. Its own documentation is also clear about limits: the AI may not know very recent components or standards, complex reasoning works better in small steps, and you should always verify critical design decisions against reference materials.

That matches our view. AI can help find a part, read a datasheet or review a schematic for obvious errors, as long as you check it. The layout, the power budget and the radio design are still done and reviewed by an engineer, because a wrong pin map or a missed constraint only shows up after the board is built. In our PCB and electronics work, the design is done by engineers, and any AI help is checked against the datasheet and the board.

AI in what you build: when a feature earns its place

If the product itself uses a model, work through these steps before you commit:

1. Pick one narrow task. Speech to text, search across your own recordings or documents, or answers drawn from your own material. Start where a person would otherwise do tedious work.
2. Test models on your own examples. A benchmark tells you little about your data. Compare candidates on real examples from your users, including the awkward ones.
3. Estimate the running cost per use. Model choice changes it a great deal. Anthropic's list prices on 2 October 2026, for example, run from USD 1 per million input tokens for Haiku 4.5 to USD 10 for Fable 5.1, with output tokens priced higher, and batch processing is discounted by half. How often the feature runs matters as much as the model.
4. Decide where data goes. Which provider, which region, and whether they train on your data. Put a data processing agreement in place, or run an open model on your own servers when data must stay with you.
5. Plan for wrong answers. Decide what the product does when the model is unsure or wrong, and let the user check and correct.
6. Place the work in a connected product. On a device, decide what runs on the device, what runs in the cloud, and what happens offline. Latency, battery and connectivity decide this, not the model.

For adding AI to a web or phone app, see our guide to web apps, phone apps and online shops with AI.

The EU rules that apply

The EU AI Act is now in application in stages. According to the European Commission, the rules on prohibited practices and AI literacy have applied since 2 February 2025 and the rules for general-purpose models since 2 August 2025. The transparency rules, which include telling people when they interact with an AI system, took effect in August 2026. Rules for high-risk systems in areas such as biometrics and employment apply from 2 December 2027 after the AI Omnibus, and AI built into regulated products has until 2 August 2028.

In our reading, a transcription or search feature in an app falls mainly under the transparency rules, but a device that counts as a regulated product, or a feature used for hiring or credit, needs a closer look. Check your own case early.

How we work on this in projects

Two of our current projects have AI as a core feature. Both are in development.

ARCIVE turns what you say on the web, on your phone or on a small capture device into searchable text, links it by topic, and lets you ask questions answered from your own history. We designed the apps, the transcription and search back end, and the device firmware together.

Anyglot turns video, podcasts and recordings into a timestamped transcript in your own language, streamed line by line while the audio is still being processed. We built the web app, the API and the audio pipeline that cuts, transcribes and separates speakers.

On client AI work our approach is the one above. We choose the model per task, hosted or open, and test it on examples from your own data. We estimate the running cost per use during scoping, and settle where your data may go before anything is built. A first prototype on your own data fits in a two-week Concept Sprint or a six to eight week MVP Sprint, depending on how much of the product around it you need.

Frequently asked questions

How is AI used in product development?

In two ways. As a tool, to draft and review code, write tests and documentation, and search long documents. As a feature, inside the product, for tasks such as transcription, search and answers from your own data.

Can AI design hardware?

It can help with parts of it, such as finding components, reading datasheets and reviewing a design. Deciding the architecture, building and measuring the board, and taking responsibility for the product still need engineers.

What can AI not replace?

Measurement in the physical world, trade-offs across disciplines, meetings with real users, and responsibility for the product being safe and lawful. Those are the parts that decide whether a product succeeds.

What is the best AI for PCB design?

We do not think there is one. Tools such as Flux offer AI help inside the editor, and their own documentation says to verify critical decisions. Try any tool on a small board you already know well, and judge it on whether its output survives your review.

Will AI replace hardware engineers?

We cannot predict that. What we see today is that AI handles text-shaped tasks well enough to be useful, while measurement, trade-offs and accountability stay with people. Even the researchers who measure AI productivity say their methods have to keep changing as the tools improve.

Does AI make product development cheaper?

It can change where time goes, but the evidence on speed is mixed and the studies are about software, not hardware. Treat any promise of a fixed saving with caution, including from us.

Thinking about AI in your product?

See what we build in AI app development, or book a review or a Concept Sprint to test whether the idea holds before you build. Or book a short call and tell us what the feature should do. We will say where AI helps and where it does not.

Sources

Checked on 2 October 2026:

1. Peng et al., The Impact of AI on Developer Productivity: Evidence from GitHub Copilot (arXiv, February 2023)
2. METR: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (10 July 2025)
3. METR: We are Changing our Developer Productivity Experiment Design (24 February 2026)
4. Stack Overflow Developer Survey 2025: AI
5. Flux: AI hardware design tool
6. Flux documentation: Copilot use cases and limits
7. Anthropic: Claude API pricing
8. European Commission: AI Act
9. Your Europe: CE marking