A coffee cup, a laptop and a bottle sit in the records of an old phone app. Each purchase gets a picture. A menu slides across the screen, while tabs offer different ways to inspect the accumulated evidence of spending money. The app is called SpendSmarter. In 2015, Yifan Xiao was working on software that could make an ordinary transaction easier to remember. A decade later, his work concerns a rather different kind of memory: the behavior that training puts into an AI model.
Xiao is a founding software engineer at Fireworks AI, based in San Mateo, California. His career includes Apple and Google; his academic background includes computer science at the University of Chicago. Those names give the outline. The small projects give it texture. They contain pictures, calendars, bookmarks and deadlines, the familiar things that become surprisingly complicated when somebody has to make them work on a screen.
SpendSmarter’s 2015 project let users record purchases with a title, description, photograph, date and location. It offered pie charts by category and bar charts by day, with animated details. Records could be fetched from Dropbox, and new ones synced back. This was a student project, with the ambitions and practical concerns of an app intended to leave the classroom.
There is a modest comedy to the name. Buying a thing is easy; making sense of everything you bought requires a database, a gallery and at least two kinds of chart. The screenshot gives the idea a concrete shape. The app tries to turn a collection of objects into something a person can browse and understand. Its subject is personal spending. Its engineering includes storage, presentation and synchronization.
The distinction matters when looking at Xiao’s later career. A model-training engine sounds remote from a purchase diary. Yet the older work provides a useful opening to his story because it shows the actual units of his early software practice. There were things to save, interfaces to build and data to move. The glamorous nouns came later. The records already needed to survive.
A calendar with other people in it
Another 2015 project, socialCalendar, tackled the small administrative ordeal of seeing friends. It was an advanced iOS final project designed around arranging meetings, public events and casual gatherings. Users could initiate events and invite others, sync with a personal calendar, and let friends see the calendar to find a suitable time. Browsing a day would reveal its to-do items.
The proposed extra feature was a lightweight messaging controller for discussing event details, if time permitted. That qualification has the sound of an actual deadline. Even an app dedicated to finding time cannot manufacture more of it for its developer. The distinction between planned and implemented features is useful here: messaging was an ambition written into the project description, rather than a capability to take for granted.
His Tech-Time project brought a different everyday routine onto the phone. It was an RSS reader for technology news from Engadget. Users could like articles, bookmark them and share links on social networks. A night mode changed the reading experience after dark. The repository described an initial release with App Store approval pending, and included screenshots of the iPhone 6 version.
These projects put concrete interactions ahead of an abstract pitch. A calendar has to cooperate with another calendar. A news reader has to give a reader somewhere to put an article worth keeping. A purchase record needs enough context to mean something later. The descriptions are full of verbs: invite, sync, browse, bookmark, share. Each verb represents a little promise to the person using the app.
The 2015 PennApps hackathon repository adds a classroom to this group of settings. Its education app was designed to let students take challenges assigned by teachers, with new challenges assigned through a web version. Mobile and web had separate parts in the interaction. The stated project was specific and limited, with a teacher on one side and a student on the other.
A calendar built around invitations, shared availability and the negotiations of everyday life.
Taken together, these are early work samples with recognizable users. They do not need to be recast as secret forecasts of generative AI. Their interest lies in their own details. A student arranging an event, a reader saving a link and a teacher issuing a challenge each encounter a different interface. Xiao’s collection moves among those situations without pretending that one app can handle them all.
The deadline gets a promotion
In 2016, an Android to-do app became another exercise in everyday behavior. Xiao’s CodePath pre-work lists about seven hours of work and a set of completed user stories. Adding, removing and editing tasks supplied the basics. Keeping the tasks through an app restart supplied something more consequential. A list that forgets its contents is an excellent way to create an additional task.
The optional features were unusually particular. Duplicate task names were prevented. Users could assign priorities and due dates. Tasks were sorted first by priority, then by due date, then by name. Colors changed with the completion deadline. SQLite stored the list, and a dialog handled updates. A custom adapter presented the task information. These were small choices, visible in the project’s checked-off requirements.
One feature gave overdue work an automatic promotion: an item due that day or already late would have its priority increased to the maximum. The deadline acquired authority inside the interface. That is an amusingly literal piece of software design. The app would escalate the task whether or not its owner felt inclined to do so. The behavior was explicit, rather than left to a user’s good intentions.
A separate Android to-do submission recorded fifteen hours for basic and extra functions and identified Xiao with a University of Chicago computer science master’s background. These are separate repository records, so their time estimates should remain separate too. Neither number describes his whole education. Each describes one bounded piece of work, with a walkthrough attached.
His employment history places him at Apple from October 2016 to January 2019, then Google from January 2019 to September 2023. He joined Fireworks AI in September 2023. His own GitHub biography also names the two earlier employers. The sequence takes him through two established technology companies before the founding-engineer role at a younger AI infrastructure business.
October 2016 - January 2019
January 2019 - September 2023
Joined September 2023
The chronology puts these mobile projects near the beginning of his professional route. By the time he joined Fireworks, years of engineering work at Apple and Google lay between him and the student apps. Alongside that employment sequence, his public project collection extended into other kinds of computing. The settings changed from phone screens to supply chains and simulated transit networks, and eventually to a learning environment with an agent collecting rewards.
Coffee beans, train lines and yellow bananas
A 2019 blockchain supply-chain project explored product authenticity using Ethereum. Xiao described building a decentralized application to track product origins. The repository included activity, sequence, state and data-model diagrams, along with instructions for testing the contracts and running the application. The coffee in this project belonged to a supply-chain exercise, rather than the spending gallery of his earlier app.
He also marked the model’s limits. It was for practice and did not fully represent a real supply chain; one example involved a distributor shipping coffee to a retailer without receiving payment. That omission would cause lively discussion in a real business. In an exercise, identifying it helps keep the scope honest. The README separated the model being studied from the commercial world it simplified.
Another 2019 repository, kafka-streaming, concerned a Udacity data-streaming exercise using Chicago Transit Authority data. Its project brief called for a simulated, real-time display of trains moving between stations. The pipeline included arrival events, weather readings, database information and downstream consumers. The destination was a website on which a viewer could watch the train lines.
This was course material, rather than evidence of a commissioned transit deployment. Its place in the collection is nevertheless telling in a narrower, factual way: the account contains work organized around event streams and infrastructure. The user interface sits at the end of several moving parts. A train marker on a map looks simple because the pipeline behind it has already done the organizing.
By 2021, the account also contained an Udacity reinforcement-learning navigation project. Its environment asked an agent to collect yellow bananas and avoid blue ones. Yellow earned a positive reward; blue earned a negative reward. Four available actions controlled forward movement, backward movement and turning. The exercise made the relationship between behavior and reward unusually easy to picture.
A banana-colored lesson is a useful illustration of reinforcement learning, though it should not be mistaken for Xiao’s professional training system. The repository’s exercise supplies a small environment, a few actions and a score. The current work belongs to language-model infrastructure. Keeping those scales distinct lets the early project remain interesting without making a classroom agent carry the weight of a later career.
At Fireworks, the work moves beneath the interface
In its 2026 Exceptional 100, Exceptional Capital included Xiao and described him as leading Fireworks AI’s language-model fine-tuning and reinforcement-learning engines. The description puts him in a particular part of the AI stack: the systems that support changing model behavior. It recognizes an engineering responsibility, rather than identifying him as the company’s founder or attributing every company result to him.
Fireworks offers training and inference infrastructure. Inference runs a model; training adapts it. Its training tools support learning from examples, comparing preferred responses and using evaluators to judge outcomes. For developers, the underlying tasks include scheduling work on GPUs, saving checkpoints and connecting training to deployment. These are company capabilities that provide context for Xiao’s role.
The training documentation makes a practical distinction between managed jobs and programmable training loops. In the managed route, the platform handles the loop. Through the Training API, developers write their own logic. That division expresses a familiar software problem: deciding which details to take care of for a user, and which controls the user needs to retain.
Xiao’s early projects offer a concrete way to appreciate that problem. A calendar exposed invitations and dates while attempting to handle synchronization. A spending app showed photographs and charts while moving records to storage. His current engineering sits in a much larger technical setting, but those older interfaces remain useful evidence of where his published work began: with specific actions somebody wanted software to perform.
The story runs from a photographed purchase to model-training engines, with Apple and Google along the way. It includes a deadline that promotes itself and a supply-chain model honest enough to admit the coffee has shipped unpaid. Those details give the career its grain. Long before the present AI role, Xiao’s projects had already discovered how many moving parts can hide behind a small, ordinary request.