The problem with “AI-first” is that it moved too quickly from being a product methodology to becoming a cost-cutting slogan.
The original trigger for this post was a TechCrunch segment about companies becoming too “AI-pilled”. The sentence that stayed with me was the idea that the people deciding AI can replace a job are often the least likely to understand what that job actually involves. Aaron Levie described this as a form of “AI psychosis.” I think that phrase is intentionally provocative, but the underlying point is real: executives are sometimes optimizing the spreadsheet version of the company, not the operating system of the company.
There is a huge difference between a company that uses AI to amplify experts and a company that decides experts are the problem. In the first case, you build tools around real work. In the second case, managers look at headcount, see cost, and imagine they can replace context, judgment, accountability, and coordination with an agent and a long prompt.
That is not an AI strategy. It is a new form of organizational debt.
AI Should Compress Latency, Not Delete Understanding
When I think about good AI adoption, the first question is not “how many roles can we replace?” The better question is: where is the latency in the organization?
Latency appears in many places: waiting for someone to summarize a document, waiting for a developer to understand a legacy flow, waiting for a support engineer to connect a customer problem to a product bug, waiting for a manager to translate vague strategy into actual next steps. AI can help with all of these. It can shorten feedback loops, draft first versions, surface patterns, and make experts faster.
But the value comes from pairing automation with someone who understands the domain. If you remove the expert and keep only the automation, you may still get output, but you lose the ability to tell whether the output is correct, safe, complete, or strategically useful. The system becomes faster at producing work that nobody truly owns.
The Hidden Work Managers Often Miss
Every organization has invisible labor. A senior engineer does not only write code. They notice when a requirement is wrong. They know which part of the system is fragile. They understand why a “quick fix” will create a production problem three weeks later. A product manager does not only write tickets. They resolve ambiguity, negotiate trade-offs, and protect the team from building the wrong thing efficiently.
AI is very good at generating artifacts: code, summaries, test cases, designs, emails, plans. But many jobs are not valuable because of the artifact alone. They are valuable because of the judgment behind the artifact.
This is where companies get into trouble. They automate the visible artifact and forget the hidden control layer. At first, it looks efficient: fewer people, more automation, a clean slide for the board. Later, the debt shows up as product regressions, customers getting answers that are almost right, processes nobody understands anymore, and managers discovering that the “deleted” work was actually the system’s quality control.
A Practical Example: Support, Engineering, and Product
Take customer support as an example. A naive AI-first approach says: “We can automate support tickets.” Sometimes that is true. Password resets, basic documentation questions, order status, simple troubleshooting — yes, automate them aggressively.
But the important support tickets are often not just support tickets. They are weak signals from the market. They tell you where onboarding is broken, where pricing is confusing, where an API behaves differently than the documentation, where a customer is trying to use the product in a way you did not expect. If the automation closes the ticket but nobody learns from the pattern, you did not improve the company. You muted one of its sensors.
The same applies in engineering. I do want AI helping developers write tests, review logs, generate scaffolding, explain unfamiliar code, and propose fixes. But I do not want a company pretending that code generation equals engineering. Engineering includes architecture, constraints, production behavior, rollback plans, ownership, and the uncomfortable ability to say: “We should not build this.”
The AI Adoption Checklist I Would Use
Before replacing a workflow with AI, I would ask these questions:
- What decision does this workflow support? If we automate the task, who still owns the decision?
- What knowledge is currently implicit? Which parts live only in people’s heads, Slack threads, old incidents, or customer conversations?
- What is the failure mode? If the AI is confidently wrong, who notices and how quickly?
- Are we reducing latency or removing accountability? Faster output is not useful if ownership becomes blurry.
- Are experts becoming stronger? The best signal is that your best people can produce better work faster, not that they are pushed out of the loop.
- Can we measure quality, not just cost? Track regressions, customer satisfaction, cycle time, rework, escalations, and long-term maintainability.
- Is there a feedback loop? The system should learn from expert corrections and real outcomes, not just generate more artifacts.
My opinion is simple: AI-first is a good principle when it means “start by asking how AI can improve the work.” It becomes dangerous when it means “start by asking which people can be removed.” The first version is product thinking. The second version is financial engineering with a futuristic vocabulary.
The managers who win will not be the ones who cut the fastest. They will be the ones who understand the work deeply enough to know what should be automated, what should be augmented, and what must remain under human judgment.
AI is excellent next to experts. It becomes dangerous when it is used to pretend expertise is no longer needed.
Related reading
If this topic interests you from the execution side, I also wrote about how I structure product work with a Monday.com Scrum dashboard. For the infrastructure side of AI and automation experiments, see my notes on running Kubernetes at home and building a 32-vCore home server.
Originally posted on LinkedIn: AI-first and organizational debt.
