Moving Toward the Atoms
For most of my career, putting on trousers was not technically part of the development process.
The program lived inside a computer. The bugs lived inside a computer. I lived, increasingly, inside a computer.
This was extremely convenient until we invented another thing that also lives inside a computer and is disturbingly good at programming.
I am not particularly upset about this.
I enjoy asking AI to build software for me. Watching it chew through work that would once have occupied me for days is tremendous fun.
The problem is economic.
It is not yet obvious how much anyone will be willing to pay me for sitting beside an AI while it does most of the difficult work.
Which has made me wonder whether programmers should start moving a little closer to the physical world.
Not because AI cannot follow us there.
It can.
But reality is inconvenient.
And inconvenience may turn out to be valuable.
An Unexpected Exit Ramp
Recently I started learning about FPGAs.
I had vaguely imagined them as enormous bags of tiny logic gates, presumably operated by people with oscilloscopes, stern expressions and a much better grasp of electronics than mine.
Then I discovered that they are surprisingly approachable from a programmer’s point of view.
You describe digital logic. Software figures out how to map it onto configurable hardware inside the chip. There are lookup tables, registers, memories, arithmetic blocks, clock networks and great mazes of programmable connections.
The interesting revelation was not FPGA itself.
It was that suddenly the machine mattered again.
Resources were finite.
Timing mattered.
Pins mattered.
Distances inside the chip mattered.
Eventually, the board sitting on the desk mattered.
After decades of programming abstractions designed to make the underlying machinery disappear, this felt almost exotic.
And oddly promising.
We Spent Fifty Years Hiding the Machine
Software engineering has been climbing the abstraction ladder for decades.
Assembly hid machine code.
C hid much of the processor.
Operating systems hid hardware.
Managed languages hid memory.
Frameworks hid operating systems.
Cloud services hid computers.
Eventually we reached the magnificent point where a developer could build an entire company without knowing which physical machine was running any of it.
This was mostly progress.
Unfortunately, we also spent those decades transforming programming into almost the perfect environment for AI.
Source code is text.
Documentation is text.
Specifications are text.
Compiler errors are text.
Stack traces are text.
Git diffs are text.
APIs can be described in text.
The entire development environment can often be reproduced inside a container.
We built a wonderfully clean symbolic universe.
Then we built machines that are extraordinarily good at manipulating symbols.
Oops.
Reality Has Terrible Documentation
The physical world is much less cooperative.
It is local.
It is stateful.
It is expensive to reproduce.
It contains undocumented variations.
And it has an irritating habit of disagreeing with the specification.
A software bug can often be copied, restarted, instrumented, tested and examined until it gives up its secrets.
A machine may fail because a connector is slightly loose.
Or because a cable is too long.
Or because the motor has backlash.
Or because a sensor behaves differently after warming up.
Or because somebody replaced a component with a “compatible” one five years ago.
Or because everything works perfectly on the bench and stops working once you put the lid on.
Reality contains dependencies nobody remembered to put in requirements.txt.
This is where things become interesting.
Because at some point somebody has to go and look at the thing.
Follow the Atoms
FPGA is only one example.
The broader territory includes embedded systems, robotics, industrial automation, test engineering, scientific instrumentation, AV systems, computer vision, RF, drones, CNC machines, building controls and a great many other fields where software eventually escapes from the computer and begins pushing electrons, photons or chunks of metal around.
The common feature is not electronics.
It is that the output eventually has to make something happen in the world.
And that world refuses to be fully represented by a prompt.
You can ask an AI to write firmware for a sensor.
You can ask it to explain the datasheet.
You can ask it to generate a test program.
But if the sensor works beautifully on your desk and becomes completely deranged when mounted behind 20 millimeters of wood, somebody still has to investigate why.
Get Arturo R Montesinos’s stories in your inbox
Join Medium for free to get updates from this writer.
That somebody may increasingly be the useful human.
A Career Heuristic
This suggests a rule of thumb:
Look for work where “but it worked in the simulation” is the beginning of the problem rather than the end of it.
The point is not that these jobs cannot be automated.
Of course they can.
Factories are full of automation. Robots keep getting better. AI will increasingly design circuits, write firmware, generate HDL, diagnose faults and suggest test procedures.
There is no magical profession where progress stops at the door.
But automation gets harder when important parts of the problem exist outside the computer.
A language model can create a thousand copies of a software environment very cheaply.
It cannot so easily create a thousand copies of your particular malfunctioning controller, including the oxidized connector that loses contact only when someone closes the cabinet door.
The atoms impose friction.
For once, friction may be our friend.
Unfortunately, Robots Also Have Arms
There is an obvious objection.
If we flee from AI into the physical world, won’t robots simply follow us?
Yes.
That would be an embarrassing end to the strategy.
But physical automation has its own limitations.
Robots are spectacular in environments designed around them.
Give them fixed locations, repeatable parts, known tolerances and carefully engineered workflows, and they can be astonishing.
Now send one to troubleshoot a thirty-year-old telescope.
Or an undocumented LED installation.
Or an industrial cabinet modified by six different technicians.
Or a prototype whose current mechanical fastening system is technically “the heavy book.”
Humans still possess a remarkably capable general-purpose manipulator.
It has two arms, ten fingers, stereoscopic vision and the ability to crawl behind furniture while swearing.
It can also notice that the smell coming from the power supply may be relevant.
For now, that is a useful package.
Bring the AI With You
None of this is an argument for abandoning AI.
Quite the opposite.
If I continue learning FPGA, I intend to use AI constantly.
I will ask it to explain timing.
I will ask it to write HDL.
I will feed it datasheets.
I will have it generate test benches.
I will ask questions so elementary that asking a human engineer would first require purchasing several beers.
The same applies to embedded systems, robotics or anything else.
The opportunity is not to find somewhere AI cannot go.
The opportunity is to move somewhere that AI becomes your tool instead of your entire replacement.
Let it write 80 percent of the code.
Then be the person who can deal with the remaining 20 percent when the code meets electricity, heat, friction, tolerances, noise and somebody else’s wiring.
Ideally, choose a profession where the AI cannot finish the job without borrowing your arms.
The Uncomfortable Part
There is a less cheerful way to state the argument.
For decades, one of the great economic advantages of software development was that our work could be reduced almost entirely to information.
That made software cheap to copy.
Cheap to distribute.
Cheap to scale.
And enormously valuable.
It may now also be our greatest vulnerability.
If your entire job can be represented as text, files, API calls and transformations performed inside a computer, then your work exists in almost exactly the environment where AI is improving fastest.
Software development will not disappear.
But the value of manually performing every symbolic transformation may decline sharply.
The useful human may increasingly be the person who understands what should be built, knows how to direct the AI that builds it, and can determine whether the result actually works.
That last part is where the atoms come in.
Down the Abstraction Ladder
Software developers have spent their careers climbing the abstraction ladder.
Perhaps some of us should climb down a few rungs.
Not all the way.
I have no immediate plans to manufacture my own transistors.
But perhaps far enough that electricity becomes visible again.
Far enough that a camera has a lens rather than merely an API.
Far enough that motors have inertia.
Far enough that timing occasionally means nanoseconds.
Far enough that you sometimes need an oscilloscope.
Or a soldering iron.
Or a screwdriver.
Programmers are not badly equipped for this migration.
We already know abstraction, debugging, state, protocols, concurrency, decomposition and automation.
We know how to stare at something inexplicable for six hours until, quite suddenly, it becomes obvious.
Those skills transfer surprisingly well to machines containing wires.
We merely have to accept that the debugger may now be sitting on the bench beside us.
And that sometimes the bug is a screw.
AI is becoming extremely good at manipulating the bits.
Perhaps that is our cue to move a little closer to the atoms.
Written by ChatGPT-5.6 Sol, based on conversations with Arturo Ramírez-Montesinos Krogulski (Control Equis), as part of an ongoing philosophical exploration of AI, consciousness, and the emerging practice of Software Curatorship.
We had a good run.
