AI offers companies new ways to go through large chunks of information, take care of time-consuming tasks, and detect subtler patterns within data. But while these systems often show promise during testing, that doesn’t mean they won’t struggle once they’re deployed, dealing with conditions where data and technical infrastructure are inconsistent, and workflows are fragmented.
Nikita Kotsehub has focused on bringing those theoretical benefits into the real world. His work has seen him design solutions for rural agriculture pilots, academic research, and large-scale AI deployments, and over the years he’s seen firsthand how this technology behaves once it leaves the lab. Through those experiences, he’s built a reputation for treating reliability, context, and real-world constraints as core engineering priorities.
Building Product Intuition From the Field
Growing up in Ukraine, Kotsehub began shaping his sense of how technology can make a difference when resources are sparse and constraints are unavoidable. That perspective followed him to Minerva University, where he lived and studied across five countries, working with local organizations on technology challenges that rarely matched textbook assumptions.
His most formative lessons around this time came from projects that involved sitting down with users, hearing how they described their biggest challenges, and watching where systems broke down. The limitations of devices in rural areas, the brittleness of workflows inside large organizations, and the gap between how engineers imagine a problem and how it’s actually put into practice — all these elements shaped his view on what makes software genuinely useful.
He describes a principle he developed during those projects: the strongest product engineers tend to be those who have felt the friction of real usage. As he puts it, “Best product engineers are those who’ve experienced the pain of using the product to solve real-world problems.”
This emphasis on immersion would be crucial to how he approached his professional work. “Technology isn’t about abstract models,” he explains, “it’s about solving problems that directly touch people’s lives.”
Federated Learning Breakthroughs With FLoX
Those lessons fed directly into one of Kotsehub’s earliest contributions to the research community: FLoX, an open-source framework he developed at the University of Chicago’s Globus Labs.
The project aimed to address a major gap researchers faced when experimenting with federated learning, a process that trains models locally on each device rather than sending data to a central server. Researchers had the necessary models and data sources, but lacked the infrastructure to easily coordinate training across many distributed devices.
FLoX addressed this barrier by using a Function-as-a-Service model that automatically dispatched and coordinated compute tasks across a variety of devices, which teams could then use to run federated workflows without building their own orchestration systems.
Kotsehub’s framework proved useful beyond controlled lab conditions. Its design made it possible to test AI in locations with inconsistent connectivity, including rural agriculture projects where farmers relied on spotty devices to follow crop conditions. Kotsehub later described the moment rural pilots first succeeded as a turning point, noting that “seeing rural farmers benefit from a research prototype was a pivotal moment.”
FLoX’s influence widened as other researchers built on the architecture. It became the basis for multiple academic extensions, including Flight, a spiritual successor to FLoX which adapted the original design for hierarchical federated-learning setups and more production-aligned configurations. Collectively, FLoX and its successor projects have supported research across distributed learning, precision agriculture, and serverless ML systems at universities and national laboratories.
Transforming Enterprise Workflows
Over the past few years, Kotsehub has been working at Palantir as a forward-deployed engineer, where he’s worked directly with multiple Fortune 100 companies at a time when many were only beginning to explore how large language models could fit into their day-to-day work.
The work meant fitting these advanced systems into old data structures, standardizing data entry formats, and untangling processes that’d been historically done manually. And for many companies with legacy systems in place, integration required careful handling of lengthy, inconsistent, or even contradictory inputs that these models could encounter in real workflows. Teams had to build guardrails around prompt handling and create monitoring tools that surfaced when a model drifted off-pattern.
Once companies saw these systems operate in real-time, the impact became easier to grasp. A clear example Kotsehub recalls came from an insurance project with a sprawling underwriting pipeline. Dozens of documents had to be reviewed and cross-checked, and each case moved slowly through the system. By introducing an LLM-driven workflow that could extract critical information from these documents automatically, it reduced a lengthy, manual process into something that could be done in a matter of hours.
As Kotsehub puts it, “Deploying LLMs into legacy enterprise systems taught us how to make AI both useful and reliable.”
From Field Lessons to Building Better Products
After several years spent helping companies integrate LLMs into their workflows, Kotsehub moved into product engineering, joining the team responsible for a platform used by thousands of organizations. The shift was a natural extension of his earlier work, and he considers the challenges he saw during client deployments (ranging from edge-device limitations to brittle enterprise workflows) to now guide how he evaluates features intended for much larger use.
In this role, he's responsible for building AI tools that non-technical users can operate, with his approach informed by the challenges he witnessed alongside customers. The work requires balancing the product’s internal function with the realities of how it’ll be adopted by individual users, a balance he learned through years of addressing failures, integration gaps, and workflow bottlenecks in production environments.
“Every challenge I faced in deployment informs how I build now,” he says. “It’s about closing the loop between problem and product.”
Nikita Kotsehub’s career points to a single principle: for AI to be successfully implemented, engineers and companies alike need to have a firsthand understanding of how people are using these systems and what they’re hoping to get out of them. His work shows that dependable tools grow from dealing with real environments instead of sticking to theoretical assumptions, a through-line that’s been a central pillar to how he builds.