A young boy sitting in the cab of a red Chevy work truck in downtown Columbus, Ohio in the late 1970s, with Roy's Diamonds sign visible in the background.

Me, late 70’s downtown Columbus, Ohio in my Dad’s work truck.

A one-man siding crew with a ten-year-old on the saw taught me the part of construction automation most technologists are going to miss.

Six years ago I began working for a local construction company and while technically, construction was new to me, it wasn’t foreign to me either.

When I was younger, maybe 10 years old, my dad would drag me out to job sites with him. He was a residential siding installer, and I’d help nail panels and J-channel. On weekends he’d sometimes pick up a single-story ranch house and we’d head out Saturday morning with me on the saw and him nailing. If everything went right, we could knock out the whole house in two days.

A young boy in a striped shirt and hard hat standing on a construction site next to a Hard Hat Area sign, smiling at the camera.
Me at 4½, safety first!

The funny thing is, that little one-man/one-kid siding crew was already a kind of machine. My dad would yell out “six foot, three and a quarter,” I’d pull the panel, line it up, sching through the cut, and have the next piece ready before he was done nailing the last one.

No tablets. No BIM model. No optimization software. Just rhythm, repetition, trust, and a kid who knew that if he kept the cuts coming fast enough, we could wrap an entire ranch house in a weekend. After he got paid, he’d take me to Service Merchandise and let me pick out a Mattel or Coleco handheld, which to me felt like getting paid in unobtanium.

But it’s all good. That was household income, so I still benefited from the work beyond the game. It also meant I grew up around construction sites and the people who worked them.

I was always interested in drafting too. In high school I took drafting all four years.

So all these years later, when I found myself standing at a QC job looking at field sheets, I had enough familiarity to not be completely lost. I could identify doors. I could read the measurements. I could validate pieces of the construction against the documentation. It wasn’t perfect, but it wasn’t nothing either.

From there, I learned a lot about the construction industry, and the more I watched, the more convinced I became that construction is one of the last miles for automation. The company that really cracks that nut is going to make bank. It may also become one of the single biggest catalysts toward a social restructuring that ends us up somewhere between UBI and unrest, depending on how badly we handle the transition.

Because the biggest impediments are not just technical. They are human and institutional.


Construction is full of people at every level who are genuine subject matter experts. Some of that expertise is craft. Some of it is field judgment. Some of it is the kind of knowledge you only get by doing the work in the sun, in the mud, with the schedule slipping and three other trades stacked on top of you. But some of it is also “we’ve always done it this way” and that’s where automation gets dangerous.

Automation can capture a process. It can repeat it. It can scale it. But if nobody understands what the process is actually doing, it can just as easily preserve the bad parts along with the good ones.

We’ve already seen extreme versions of this in other industries, with workers monitored by cameras and movement trackers so machines can be trained to replace them. That is one end of the spectrum: capture the human motion, encode it, and remove the human.

But construction has its own version of the same problem. If a workflow is built around waste, shortcuts, bad sequencing, or quick-and-dirty execution, automating that workflow does not make it smart. It just makes the mistake repeatable.

A guy with a nail gun who was taught that spray and pray is the right way to frame might still get the wall up. But that does not mean we want automation doing the same thing faster.

Fixing even one process like that can create real savings on day one. The output quality goes up because the work becomes consistent, repeatable, and efficient. But only if the people building the automation can tell the difference between efficiency and habit.

That distinction matters, because not every repeated motion is waste. Sometimes repetition is mastery.


That cutting table with my dad was efficient because we both understood the work. He knew what he needed before he asked for it. I knew how to stage the next cut before he finished the last panel. The process was fast because it was human, not in spite of it, and that is the part I worry we are going to lose.

I’ve worked with a lot of people over the last six years across different trades who I would absolutely consider craftsmen. People who can see a problem before the measurement says it is a problem. People who know when the drawing is technically right but the field condition is wrong. People who understand that the work is not just the task. It is the judgment wrapped around the task.

Automation is coming for construction. I think that is inevitable. I just hope it does not play out like Sleep Dealer, the dystopian sci-fi version of labor outsourcing where workers stay on one side of the border while machines do the physical work on the other.

The question is not whether we can make the machines faster.

The question is whether we understand the work well enough to know what should be preserved, what should be improved, and what should never be automated in the first place.

Bryan Carter is a technology executive and writer based in Phoenix, AZ.