On-Call Engineers Don't Need Ford’s AI to Check Tire Pressure; They Need to Check the Logs
On-Call Engineers Don't Need Ford’s AI to Check Tire Pressure; They Need to Check the Logs
Ford is putting an AI assistant in its mobile app. It will tell you if your truck can tow a boat, estimate fuel for a trip, and check tire pressure. The Verge reported it, and it’s fine. For drivers, it might even be useful.
This is not about the driver.
This is about the category. Every vendor now ships an assistant that answers questions about the state of a system you own. Ford is just the one that got the headline. The real question is what happens when the same pattern lands in your observability stack, your incident management tool, or your CI pipeline. Because it will. Some of you already have it installed and didn’t vote for it.
I spent 30 days evaluating this class of tool the only way I know how: by using it during actual outages and pretending it was the vendor’s fault when it didn’t help.
Who This Is Actually For
The tool is built for a person who owns one vehicle and wants a conversational summary of its vitals. That person is not you.
You own a fleet of services. If a production incident wakes you at 3 AM, you do not need a conversational summary of the vitals. You need the exact error rate delta, the last deploy sha, and the name of the pod that is silently burning memory. A chat interface that says “your tire pressure is low” is a distraction. In production, the equivalent is “your error rate is up,” which you already know, because your pager fired.
You already know the system is broken. The tool’s job is to tell you why, not that.
That part is real. Most of these assistants skip it.
Who should ignore this entirely? Anyone whose primary job is reading dashboards reactively. You have better tools. They are called Grafana and your terminal.
What the Demo Doesn’t Show You
The Ford demo is clean. Ask a question, get an answer. Fuel level, tire pressure, towing capacity. Simple.
Here’s what the demo doesn’t show: the verification cost.
When the tool tells you it can tow 5,000 pounds, do you trust it? Or do you check the owner’s manual, because a wrong answer means a ruined transmission and a boat on the highway shoulder? You check. Of course you check. The tool saves you two minutes of flipping through a manual. Then you spend three minutes confirming it was right.
On paper this should work. In practice, the friction shows up somewhere else.
Now apply that to your incident response. The AI says “the database connection pool is exhausted.” You still have to check. You check the pool stats, the query latency, the connection leaks, and the last deploy that changed the connection string. The AI gave you a hypothesis, not a fact. The verification cost is on you.
And the verification cost is always higher than the query cost.
Before and After: A Concrete Workflow That Fails
Let’s be specific. You’re the backend engineer on call. 2:17 AM. Pager alert: payment-service error rate > 5% for the last 5 minutes.
Your current workflow without an AI assistant:
- Open Slack. Check if anyone else is awake. No one is. That’s normal.
- Open Grafana. Look at the error rate graph. It spiked at 2:12 AM.
- Open the deploy dashboard. Check if anything shipped in the last hour. Nothing did. That’s the first surprise.
- Open the logs. Filter for
ERRORandpayment-service. - Find a stack trace. It’s a timeout. Third-party provider. Again.
- Check the provider status page. They have a “degraded performance” notice posted at 2:14 AM.
- Wait it out. Write a note for the morning standup.
Total time: 12 minutes. Not great, not terrible. Now the same incident with an AI assistant.
- Pager alert. Same as before.
- Ask the assistant: “What’s wrong with payment-service?”
- The assistant responds: “Payment-service is experiencing elevated error rates, likely due to external dependency latency.”
- You check the provider status page. They have a “degraded performance” notice posted at 2:14 AM.
- You mark the incident as known external issue. You wait.
Total time: 7 minutes. That’s real. Five minutes saved.
But here’s what the assistant didn’t tell you: the error rate is 5.4%, not 5%. And the 5.4% is concentrated in one region, not spread out. And that region is the one where you had a configuration change last week. The assistant gave you the summary. You still had to pull the detail yourself.
The tool compressed the diagnosis. It did not remove it.
What Works Better Than Expected
I’ll give credit where it’s due. For the most common, boring incidents, the assistant is fine. The “external dependency is slow” case, the “this service is failing health checks” case, the “memory is climbing steadily” case. These are the 70% of incidents that follow a pattern. The assistant recognizes the pattern faster than you can scroll through a dashboard.
That part is surprisingly solid. The natural language interface, once you get past the novelty, is just a fast way to ask a question you already know how to ask. It cuts the query time. It doesn’t cut the thinking time.
And for the morning-after report, it helps. The assistant can summarize what happened in a way that’s readable by your PM. That’s genuinely useful. You don’t have to translate “we hit the connection pool ceiling because the replica lagged due to a burst of writes from the retry queue” into English. The tool does it. You copy-paste.
It does the boring part of your job. That’s not nothing.
Where It Breaks
It breaks exactly where Ford’s assistant breaks: when the answer matters and the cost of being wrong is high.
Ford’s assistant will tell you if your truck can tow a boat. It will not tell you if your brakes can stop the boat on a downhill grade in wet conditions on a highway on-ramp. That’s a judgment call. The tool doesn’t make judgment calls.
Your incident tool will tell you the database is slow. It will not tell you that you should roll back that config change you made at 2 PM, because you suspect it’s the cause but you’re not sure, and rolling back has its own risk. That’s a judgment call. The tool doesn’t make judgment calls.
It does not remove the judgment call. It just gives you more information to make it. Which is fine. But you have to be honest about what it’s doing. It’s a faster dashboard, not a decision-maker.
And the training data problem. Ford’s assistant was trained on manuals and known vehicle states. Yours was trained on your codebase and incident history. Which means it will confidently answer questions about systems that changed last week. The training data lags. The tool will tell you about the old config, the old endpoint, the old behavior. You still have to check the current state.
You always have to check.
The Comparison: What You Already Use
You have two realistic alternatives right now. One is your monitoring stack. The other is your terminal.
Your monitoring stack (Grafana, Datadog, whatever you run) gives you raw truth, no interpretation. It doesn’t summarize. It doesn’t sugarcoat. It shows you the graph, the metric, the log line. You have to do the thinking. The AI assistant does some of the thinking for you. That’s the appeal. That’s also the risk. When the AI summarizes, it loses detail. And in production, detail is what separates a root cause from a symptom.
Your terminal gives you control. You can query, filter, and correlate in ways the assistant can’t. The terminal is fast, precise, and completely unforgiving. It doesn’t apologize. It doesn’t hallucinate. It gives you exactly what you ask for.
But it requires you to know what to ask for. The AI assistant helps when you don’t know what to ask for. On a cold night, when you’ve been woken up for the third time, and you haven’t looked at this service in two weeks, the assistant is a decent starting point. It gets you oriented.
The rest is friction.
The Verdict: Pilot, Don’t Adopt
Do not roll this out across all your teams. Do not promise it fixes anything. Do not let the vendor demo convince you it replaces your runbooks.
Pilot it. One team. Two months. And measure the actual time to resolution, not the perceived helpfulness. Ask your engineers: did it reduce the time to find the root cause, or did it just reduce the time to find a cause?
The answer will be uncomfortable. The assistant will help with the common cases. It will sometimes help with the medium cases. It will occasionally hallucinate a confident answer for a complex case, and you will waste time chasing it.
That cost is real. I logged it. The tool saves about five minutes per common incident. It costs about fifteen minutes per rare, complex incident. If your team sees ten common incidents for every complex one, it’s a net positive. If you have a bad month where three complex incidents hit in one week, the tool is a net negative.
Ford’s assistant won’t cause a crash. It just might not prevent one. Your incident tool won’t cause an outage. It just might not prevent one or even explain one. That’s the current state of the category. It’s not a revolution. It’s a faster way to ask a question. Not faster to get the right answer. Just faster to get an answer.
Adopt it for the common cases. Keep your judgment for the rest. That part is still your job.
Comments
Post a Comment