Targeted Design vs. Emergent Growth: Electronics in the Age of Uncertainty

Every embedded engineer knows this feeling: you start with a clean block diagram, and six months later you are staring at a board that works for reasons no one fully understands. Somewhere between targeted design and emergent growth, the system has grown its own personality.

We like to pretend electronics is fully deterministic. Yet our workflows increasingly resemble biology: constraints, mutations, selection — and then we ship whatever survives EMI testing.

#The MCU is a plan, the system is an organism

Take a typical 32-bit microcontroller: say Cortex‑M4, 512 KB flash, 128 KB RAM, 80 MHz core, 3 UARTs, 2 SPIs, 1 USB FS. On paper, it’s pure intentionality:

• you assign peripherals to exact pins,
• you dimension the power tree down to the millivolt,
• you budget every byte of flash and every DMA channel.

This is the targeted design mindset: the datasheet is law, the schematic is the constitution, the PCB is a frozen decision.

But the actual system — the thing in the field — behaves more like an organism:

• the supply network rings in ways your SPICE model never showed;
• the temperature drift of a cheap crystal creates timing quirks at ‑20 °C;
• the boot sequence depends on how fast a supervisor IC releases reset relative to a buck converter’s soft‑start.

On the bench, these become “weird edge cases”. Philosophically, they are emergent properties: behaviors not explicitly designed, yet fully real.

#Breadboards, Git history and the evolution of hardware

Look at the life story of most hobby or startup projects:

1. Arduino + modules + jumper wires.
2. First custom PCB, still mostly breakout‑style.
3. Second or third revision with proper power, layout, EMC, thermal design.

If you git log the firmware, you rarely see a straight line. You see evolution:

• features added under time pressure,
• quick patches around silicon errata,
• protocol tweaks to match a new module found on AliExpress.

None of this was in the original "requirements document" — if one existed at all. The project adapts to real‑world constraints: supply chain issues, user feedback, certification surprises.

In biology, evolution operates on random mutation plus selection pressure. In hardware, our "mutations" are:

• last‑minute schematic edits,
• bodge wires on test boards,
• #ifdef jungles in firmware.

Selection pressure is brutal but simple: does it pass tests, and can we afford to build it?

#AI tools: new architect or new ecosystem?

Now add AI‑assisted design to this picture.

We already have:

• PCB autorouters that optimize trace length and via count,
• FPGA tools that decide how your HDL maps to LUTs and routing fabric,
• code assistants that generate HAL boilerplate or entire drivers from a few comments.

So who is really designing the system?

If you hand an AI a set of constraints — power budget, BOM cost, size, EMC class, latency limits — and it returns a full schematic, layout and firmware skeleton, is that still targeted design? Or have you just defined a fitness function and let a digital ecosystem evolve a solution?

At that point, your role shifts:

• less while(1) loop writing,
• more constraint authoring and environment design;
• less “place this capacitor here”,
• more “penalize solutions whose PDN impedance rises above 100 mΩ at 10 MHz”.

You become less of a circuit architect and more of an evolution manager.

#Safety, responsibility and the illusion of control

There is a reason safety standards like IEC 61508 or ISO 26262 care so much about process. If parts of your design are emergent — shaped by tools, constraints and interactions you don’t fully model — who is responsible when something fails?

Our cultural instinct is to say: the engineer. But that assumes the engineer is a central planner, not a gardener.

Yet, look at a modern car: tens of ECUs, millions of lines of code, dozens of suppliers. No single mind holds the whole design. What we call design is increasingly a negotiated equilibrium between:

• silicon vendors and their reference designs,
• toolchains and their optimization heuristics,
• standards bodies and their test suites,
• and now, AI models and their training data.

We still draw schematics, but the system that ships is often the emergent result of this entire network.

#A question for your next board spin

When you open KiCad or Altium for your next revision, you’ll specify nets, widths, clearances. But you’ll also, implicitly, set the rules of a small universe in which components, code and tools will interact.

In that universe, do you want to be a strict architect enforcing a fixed blueprint, or a careful gardener defining conditions under which good designs can emerge? And as AI becomes a more active participant, how much of that control are you actually willing to hand over?