Bottom line. Artificial intelligence (AI) tools have made prototypes cheap. That shifts the scarce skill from building to choosing what to build. We answer that question from first principles: identify the physical, computational and economic limits that no tool can change, design inside them, and only then select platforms.
The distance between idea and prototype has shrunk
For most of the history of software, the cost of a prototype filtered ideas. If testing a concept needed three engineers and two months, only a few concepts were tested. AI coding assistants and general-purpose models have lowered that cost.
The evidence is real but uneven. In a controlled experiment, developers using an AI pair programmer completed a defined programming task 55.8% faster than a control group [1]. A 2025 randomized trial with experienced open-source developers, working in large codebases they knew well, found the opposite: with AI tools, their tasks took 19% longer [2]. Both results can hold. AI accelerates well-specified, self-contained work. It helps less where the hard part is understanding a complex existing system.
The practical consequence is the same either way. When prototypes are cheap, prototyping stops being the filter. Something else has to decide which ideas deserve investment.
The question changes from “Can we build it?” to “What should we build?”
When building was expensive, feasibility was the main question. Now many things can be built, at least as prototypes. The better question is which of them will survive contact with reality: real users, real data volumes, real energy bills, real network distances.
A first-principles approach answers that question by starting from what must be true, not from what is usually done. In practice, it means listing the constraints that no amount of engineering effort can remove, then asking what the best possible design looks like inside them.
Boundary conditions that no tool can change
Some limits are set by nature. They are not obstacles. They are the ground the design stands on, and knowing them early prevents expensive surprises late.
| Boundary condition | What it fixes | Question to ask first |
|---|---|---|
| Speed of light | Minimum network latency | How far apart are the user, the data and the compute? |
| Energy and heat | Cost and capacity of computation | What is the energy cost per useful result? |
| Information and noise | What can be measured or inferred | Does the signal exist in data we can actually collect? |
| Materials and supply | What hardware can be built and bought | Can the system be manufactured, maintained and replaced? |
| Economics and people | Who pays, operates and is accountable | Who acts on the output, and what does a wrong answer cost? |
Two worked examples show how these conditions turn into design decisions.
Example 1: latency has a floor
Light in optical fibre travels at about two-thirds of its speed in a vacuum, roughly 200,000 kilometres per second, or about 5 microseconds per kilometre. Toronto and Vancouver are about 3,360 kilometres apart in a straight line. A round trip between them therefore takes at least 33 milliseconds before any routing, queuing or processing. Real fibre routes are longer than a straight line, so real round trips are longer still.
No software optimization removes that floor. If a control loop must respond in under 10 milliseconds, the computation has to sit near the equipment. That single fact shapes the architecture: local processing for the loop, central processing for learning and reporting. Physics makes that decision, not a product choice.
Example 2: energy sets the budget
Every computation consumes energy, and at scale the totals are large. The International Energy Agency (IEA) estimates that data centres used about 415 terawatt-hours (TWh) of electricity in 2024, around 1.5% of global electricity consumption, and projects about 945 TWh by 2030 [3]. The same principle applies to a single product. If an AI feature costs more in compute and electricity than the value of the decision it supports, it will not last, however well it performs in a demonstration.
Tools are instruments, not the boundary
None of this argues against platforms. Cloud services, models and industrial software are useful instruments, and we work with many of them. What matters is the order of the questions. If the first question is “Which platform are we using?”, the platform’s roadmap quietly becomes the boundary of what the team imagines. If the first question is “What is possible in reality?”, the platform becomes a choice made to fit the problem.
This is what vendor-neutral means in our practice. It describes the order of reasoning: tools and platforms are useful instruments, and physics is the operating envelope.
How we apply it
Before choosing a technology stack for a new venture or engagement, we work through four questions:
- What must be true for this to work? List the physical, data and economic conditions.
- What is the best case inside those conditions? This sets the ceiling against which any design is measured.
- Which constraints are real, and which are habits? Many “requirements” are inherited from a previous system.
- Which tools fit the design? Choose platforms last, and choose them so they can be replaced.
The second question is the one most often skipped. Without a best case to compare against, a team cannot tell whether a 20% improvement is excellent or poor.
Conclusion
AI expands imagination. Physics defines reality. Engineering connects the two. AI makes it cheaper to explore ideas than at any point before. That makes it more important, not less, to know which ideas can survive the real world. Starting from first principles is how we make that call early, while changing course is still inexpensive.
References
- S. Peng, E. Kalliamvakou, P. Cihon, and M. Demirer, “The impact of AI on developer productivity: Evidence from GitHub Copilot,” arXiv:2302.06590, 2023.
- J. Becker, N. Rush, E. Barnes, and D. Rein, “Measuring the impact of early-2025 AI on experienced open-source developer productivity,” METR, Jul. 2025.
- International Energy Agency, “Energy and AI,” IEA, Paris, Apr. 2025.