We had a standard ruggedized field laptop for all worksite staff. It could take a beating, including sitting all day in a closed truck cab in Arizona in the middle of summer. Every jobsite with an office had a high-gain wifi antenna covering the site, extending the LAN over VPN to on-site staff.

Solid setup. Worked for everyone. Until we brought in a new field lead.

He seemed fine at his job. But we could not get him to use the computer. He wanted a tablet. That would be the trick to get him compliant with his paperwork.

So I secured a tablet version of the same ruggedized line.

Nope. He needed a stylus.

Got him a stylus. He lost it. And now the tablet was too bulky.

So we went a different direction entirely. My team built web-based integrations that let him do his submission work from his phone. The device already in his pocket.

He used it for a few weeks. Then stopped.

So I got him one of the lighter tablets we issued to office workers.

No. It needed to be an Apple tablet. That’s what all the other trades were using.

We were a Windows shop. Not out of preference. We’d done a full assessment before moving to tablet-based computing and the cost-benefit balance landed us on Surface Pros. They did what we needed at the right price.

I asked him what exactly he was going to run on an Apple tablet that he couldn’t do on any standard system we had. Everything he used was a web-based portal.

That moved to a conversation with one of the company owners, who was going to have to justify the $1,400 expense for what looked like a fit-in-with-my-peers demand.

I’m a platform-agnostic guy. If the tool does the job, that’s the tool. But $1,400 for a new system when we had hardware that exceeded requirements and was already integrated into our infrastructure? That’s a different problem.

He swore that this time, for real, for sure, if we just got him that Apple tablet, he would miraculously become compliant with his paperwork.

The result: marginal improvement. Never really compliant. Separated from the company four months later. The company was left holding hardware nobody needed on a payment contract.

Each individual ask sounded reasonable. Tablet. Stylus. Lighter form factor. Different brand. But stacked together they told a different story (and the phone integration said it all for me). We committed engineering hours to put the work on the device he was already carrying and it didn’t solve the real problem… but I needed to demonstrate good faith accommodation of the request with ownership. It wasn’t wasted effort though as the rest of the team benefited from the updates.

Sigh…

I fully support adapting to meet the needs of your staff. But there has to be a point where you say: this is the line. When the demands are clearly a way to put off doing the work, every concession just buys a few weeks of silence… never the actual compliance.

The diagnostic isn’t in any single request. It’s in the pattern.

I’ve been talking with smaller construction firms at local meetups lately, and the energy around AI is genuinely exciting. Owners are automating proposals, generating scripts, pulling data out of documents faster than ever. The enthusiasm is real, and a lot of what they’re building is legitimately impressive.

But I keep noticing the same gap, and it’s one I’ve seen play out time and again over the years.

There’s a meaningful difference between ”an AI can write a script” or “configure your settings” and “an AI can architect, secure, and maintain a production environment.” That’s not a knock on anyone’s intelligence or the tools. It’s just that most smaller firms have never needed to think at the enterprise level before and any professional IT experience they’ve encountered was probably on the user side of someone else’s environment. AI is quietly pushing them into territory that looks and feels genuinely good.

What I’m watching happen though is firms handing the keys for a sports car to an algorithm that doesn’t know what a brake pedal is, simply because the car goes fast.

Here’s what that looks like in practice:

When you swap reliable, deterministic software for a chat-based AI workflow, you’re introducing a system that can fail in ways that don’t look like failures. It doesn’t throw an error code. It just confidently gives you the wrong number on a bid, or silently drops a compliance document, or racks up compute costs that don’t show up until the invoice hits. And if nobody on the team knows what a failure state looks like in that stack, nobody catches it.

The owners I talk to think they’re saving on headcount. What they’re actually building is invisible technical debt. The kind of debt that can surface as a legal exposure or a cost blowout on exactly the wrong project.

And I get the appeal. These tools are incredible. They’re validating in a way that most software never has been. They give you a sense of command over problems that used to feel out of reach. That feeling is real! But it’s not the same thing as a sound architecture.

AI is a fantastic tool for generating code, pre-visualization, drafting documents, and accelerating work you already understand. It falls apart when you ask it to be the architect, especially when nobody on the team actually knows what an enterprise IT architecture even looks like, let alone how to maintain one. That’s when you lose the person in the loop who knows when to step in, redirect, or just say “no, we’re doing this the boring reliable way.”

So if you’re a construction firm leaning hard into AI right now, here’s my honest ask: get a technical review. Not from your AI vendor. From someone who’s built and maintained production infrastructure. Have them look at where your AI tools touch your actual operations… your bids, your compliance docs, your financials, and map out where a silent failure would hurt you most.

You don’t need to slow down. You just need to know what you’re standing on.