Machine learning projects fail when companies cannot explain what decision a model will change or what success means.
2
Many organizations are skipping data and engineering foundations because polished LLM demos create unrealistic expectations about what AI can do.
3
Engineers need to connect their work to business results and make their contributions visible, while accepting that some organizational problems cannot be fixed by one person.
Summary
Nikhil Suresh argues that many AI initiatives begin before a company has defined the decision the system will support, the action someone will take, or the infrastructure needed to operate it. He describes being asked to predict government funding without a usable statistical process or any plan for acting on the prediction. The current LLM cycle makes the problem harder because demos look like conversations with capable people, while production systems remain difficult to build and can produce confident errors. Nikhil also questions whether engineers should spend months building narrow internal chatbots when a vendor product may already cover the need. He advises engineers to understand how their work creates money or saves it, then communicate those results openly. He is candid about his own limited record of successful ML projects and says that visible, honest work builds trust better than polished self-promotion. Some battles, he says, are better avoided until the people involved are serious.
A model is useless when nobody can say what decision it will change
Nikhil says a business once asked him to predict government funding for the following year. The data covered only about 10 years, and he could not model the probability that a politician would withdraw funding. More importantly, the business had no answer when he asked what it would do with the number. It wanted a line on a graph. He says a data scientist needs something like a human decision tree before building a statistical one. Unless the company can describe the possible outcomes and the actions attached to them, the model has no practical role. This uncertainty also leaves technical staff feeling responsible for results they were never given the conditions to produce.
Most companies need engineering foundations before they need AI
After working in data science, Nikhil moved into data engineering because he found that most businesses lacked good infrastructure. He says the number of genuinely useful specialist data science roles is smaller than the hype suggests, while the valuable roles are those where the company has already worked out what it wants to calculate and what it will do with the result. One company told him exactly what it wanted from a future data science project, then admitted it needed two years to build the infrastructure first. Nikhil treats that delay as evidence of planning rather than failure. He also praises Fundamentals of Data Engineering for its practical focus on building a strong data foundation before AI work.
LLM demos give non-technical stakeholders an inaccurate picture of software work
Nikhil explains that people generally have a clearer mental model of surgery than software engineering. They may not be able to perform surgery, but they understand why the work needs professional preparation and care. Programming looks like writing a document in a strange language, even though one bad line can stop an entire system from working. LLMs make this harder because they look like a person talking, and sales demonstrations encourage people to imagine buying an artificial worker for a small API cost. He is trying to find a reliable demonstration that breaks ChatGPT, such as asking it to play chess without maintaining a proper board state. Showing the failure helps correct expectations.
The latest AI wave has pulled attention away from ordinary ML concerns
Before GPT-3 appeared, Nikhil felt people were finally willing to listen to discussions about model drift. Once GPT-3 arrived, he says, everyone became an AI expert, even when their experience showed they had never shipped anything. Attention moved away from traditional machine learning and toward adding LLMs to workflows and increasing workforce output. He has heard of hiring freezes justified by expected AI productivity gains. After six months or a year of attempted adoption, some companies were finding no gain and were spending time repairing AI-generated mistakes. In large organizations, he says, AI can also speed up pointless work, such as emails being generated, summarized, and passed back and forth without addressing why the process exists.
Engineers should question whether building an AI system will return more value than it consumes
The conversation contrasts engineers spending substantial time building an internal HR chatbot with sales and marketing staff using low-code tools for targeted outreach and content. Demetrios Brinkmann describes salespeople identifying companies that viewed a sales page and sending tailored messages based on that interest. Nikhil says many products that appear sophisticated eventually reduce to importing OpenAI, which does not create much lasting specialization. He argues that tuning a model such as XGBoost can require real expertise, while prompt engineering is easy for anyone with a command of language to learn. Engineers should ask whether the proposed system has a clear business return before committing scarce time and resources to a technically interesting project.
Technical work must be connected to money and made visible
Nikhil uses the frog and scorpion story to describe engineers who try to cooperate with everyone, then discover that an organization has laid them off or changed the project in ways they cannot accept. He says engineers should understand the financial thinking of the people who employ them. A friend generated about $1.5 million for a company in his first year, yet the contract was cancelled because management did not know what he had done. Nikhil says solving the problem is only the first step. Engineers also need to explain the result through talks, blog posts, or other public work. Demetrios connects this to the difficulty many engineers feel when talking about their achievements, but both agree that invisible work is easy for management to miss.
Honest accounts of failure build more trust than polished success stories
Nikhil rejects the idea that engineers should imitate exaggerated LinkedIn self-promotion, but he also thinks engineering culture can push too far toward hiding achievements. He tells people directly that he is smart and works hard, yet has only shipped one successful ML project among several attempts. Some failures were outside his control, and in one case he ran out of mental health capacity before he could carry the organization across the finish line. He says people respond well when someone admits mistakes and limits. The same applies to public work. A nervous speaker or an imperfect project can still receive support if the effort is genuine. Leaving out the difficult parts makes technical stories hard to believe.
Career growth depends on relationships and demonstrated effort more than collecting credentials
For people entering the field, Nikhil says potential does not require being exceptional. A junior engineer who shows badly written Python but has clearly tried may still get an opportunity. He recommends showing enthusiasm for a specific area and building relationships with people who work in it. When beginners ask which Python book to read, he would rather know how many coffees they arranged with practitioners that week. Demetrios recalls a conversation with Sol Rashidi, who managed a very large data organization and said that most of her time went into relationships and stakeholder alignment. Nikhil agrees that technical work happens inside those relationships. He also says people should accept that some organizational fights are currently unwinnable and wait for serious counterparts rather than chasing every AI claim.
"It doesn't matter how good you are at machine learning if they don't know how you would intervene and there's no mechanism and they don't want to do that work."Nikhil Suresh08:38
Who should watch
You are responsible for an AI, ML, or data initiative and stakeholders have not defined the decision, action, or business result the system should support.
Your engineering team is being pushed toward an LLM project while its data infrastructure and ordinary software foundations remain weak.
You have delivered valuable technical work but struggle to explain its financial impact or make your contribution visible inside the organization.
