👨🏽‍💻 Blog on Amir Kiani

We are all chefs now

Sun, 03 May 2026 00:00:00 +0000

One of my not-so-secret fantasies has been to become a professional chef. I’m sure that I’m not alone :)

Cooking beautifully ties science, art, and culture together. I learned to cook from my mom, who is an incredible chef. Having a lovingly slow-cooked meal with great ingredients can easily become among a person’s most cherished life experiences.

Lately I’ve been thinking that making software has become much closer to making meals. The similarities are hard to miss:

Anyone can cook. Not everyone will open a restaurant, but most people can put a nutritious meal on the table. Claude Code has done something similar for software. The barrier to producing something that works is now astonishingly low.
Ingredients matter more than technique. A great chef with bad fish makes a bad dinner. In software, the model you choose, the problem you pick, and whether anyone actually wants what you’re making will determine the outcome far more than how clever your implementation is.
It’s now about the craft. For years, software engineering was mostly about learning frameworks and writing code. Most of our time went to how to build, not what to build. That has flipped. You can spend months with a big team building the wrong thing, and no amount of AGI will save you. I’ve watched it happen. You can also have a small, beautiful idea, use AI, and ship something that changes lives in a week.

So yes, in many ways, I’m now a chef. The interesting question isn’t whether I can cook. It’s what I want to cook.

A lovingly cooked gourmet meal, or McDonald’s?

What I learned trying to build a VC-backed startup

Mon, 22 Sep 2025 00:00:00 +0000

Rana took this photo of me jumping around inside Marta Minujin's mattress-padded room installation at Copenhagen Contemporary. It felt like an apt description for this post.

Life is a series of experiments.

After 14 years of working for others, building my own company was a long-awaited experiment that had always piqued my interest.

This is a brief summary of what I’ve learned trying this idea.

It’s mostly intended as a capsule for my future self to read. But it could also serve as a source of information for others who might also be thinking about starting a company.

It is of course a sample of one and “your mileage may vary”.

Some important context

There are a million ways to do a startup.

Different variables, such as whether you raise funding or not, are a solo founder or team up with others, or work on a consumer product or enterprise, would have a significant impact on how things might pan out. The experiment I ran had the following specific characteristics:

I built a venture-backed startup in Silicon Valley in 2024
I chose a rather complex domain: the Health AI industry
I tried to team up with multiple co-founders, but for a wide range of reasons -- usually timing or misaligned values/expectations -- I ended up being a solo founder
Before the startup, I was in big tech (Google)

Why I started a company

The most important lesson that I discovered through building the company was how much of an exercise in self-discovery and reflection it was.

Working as an employee, one inherits a well-marked path to walk on. But as a CEO and especially a solo founder, one needs to intentionally and frequently choose/define the foundational aspects of the business.

It starts with high-level and shiny things like the company’s mission & vision and goes all the way to the decision-making process, choice of investors, commercial strategy, and even boring details such as which service to use for payroll, email, or the marketing website.

Every decision has a major impact on your work life. And you, no longer your employer, are responsible for the outcome of these decisions.

Over and over, one is forced to define who one actually is.

For me, some of the reasons for starting the company were:

I wanted to create my own culture: one that was aligned with my values.
I wanted to work on something that genuinely made the world a better place.¹
I wanted to leverage my generalist nature (engineering, research, product), which was rather under-utilized when I was working in a specialized role at a big tech company.
I wanted to experiment with building an entire company with the help of AI. There were a lot of wild claims about this being a possibility. I had cautiously assumed that everything was a lot easier with AI and that there was a non-zero chance that AI would exponentially improve through the course of my experiment. If that was true, then having a blank slate to draw on was going to be a massive advantage.
I was curious to experience being a founder. If you talk to people who know me well, they would very likely tell you that trying a bit of everything -- and being a master of none -- is very much a part of my character 🙂
It felt like an opportunity loss not to try doing a VC-backed startup in San Francisco, the mecca of startups, while I was relatively young and able.

What I learned about myself

I don’t think I’ve gained more insight about myself in any other experiment of similar length. And the majority of my experience was not by any means the exhilarating and fun ride that is portrayed by most. It was painful and confusing at times. But it was also incredibly satisfying at other times.

It was worth it.

My learning journey started right before I even embarked on the path. Given the weight of this decision to start a company, I decided that I needed to clear my head before committing to such a major decision. To do this, I did a 10-day Vipassana. A year later, I still feel the magnitude of that experience. 10 days of watching my “monkey brain” going from one thought to another. From one emotion to another. There are a lot of lectures about Buddhism in Vipassana sessions. Over and over you are reminded that cravings and aversions are the source of human suffering. And the point of life is to escape this cycle of suffering.

I came out of the Vipassana a different person. I was in fact seriously considering that I should not start a venture-backed company 🙂 The whole exercise felt like an ego-centric pursuit that I would easily cling to and cause immense suffering. It felt like a distraction from my -- unexpectedly started -- spiritual journey.

For better or worse, my enlightenment episode wasn’t able to stop me from pursuing this journey.

In retrospect, I was pretty disoriented after this intense meditation course and should have given myself much more time to reintegrate into society. I think Vipassana was a very potent, though incredibly helpful, shock to my system.²

At times, AI gave me an illusion of progress

It’s hard to make something out of thin air. Especially when you are alone in thinking about it.

At first, AI was a major band-aid for me in these situations. Every time I’d feel stuck on something or was daunted by a major decision, I’d turn to my three trusted friends: Claude, ChatGPT, and Gemini 🤖 These interactions were honestly helpful on many occasions. But I do think there was a lack of durability in some of what came out of this experience. At first glance, the slides, wireframes, apps, and business ideas seemed very promising and professional. But like the actual taste of a McDonald’s sandwich that looks incredible on a billboard, the reality did not match my illusions.

In addition, the fact that it was so easy to spend days, weeks, months mindlessly “building” prevented me from doing some important reality checks. There is something really addictive about the AI coding process.³ Others have written about this.

Towards the end, I intentionally switched to doing a lot of thinking by writing on paper and talking to real users. But the low barrier of using AI as a crutch was always hard to avoid.

I didn’t find something that would work for me

The harsh reality is that I failed at my startup (it’s totally ok though! 🙂).

Aside from the well-known challenges of building complex and high-stakes solutions with GenAI, I couldn’t find a path that simultaneously:

was a venture-scale business
was something that I was deeply interested to work on for a long time
had high enough traction to justify continuing with

I wrote about some of the things I tried in the past. I tried a few other options after the pivot as well. But at some point I decided that I had enough data to make the decision to stop the experiment.

In case it is useful for you, I’ve also open sourced the iOS app that I ended up shipping which got modest traction.

I miss working with other smart people

If you’re a strong technical person in the Bay Area working in big tech, it’s pretty hard to justify quitting your job for a startup whose entire bank account is less than your yearly income. One might say that I did this, so there must be others. But I was not able to convince others to quit their job to join me. Some of this was probably a timing issue. Another reason was, however, that I wasn’t able to prove to these folks that they would have remotely similar expected value of gains by working in the domain that I had picked.

Unsurprisingly, I couldn’t prove this to myself either.

What I do miss now is deep collaboration with some of the folks that I worked with in the past. Not just engineers but also researchers, designers, clinicians, and product managers.

I of course do not miss the many levels of middle management, hours of unnecessary meetings, and the strange politics of big tech 😉

I found out about my hidden values

When I was contemplating getting off the VC-backed startup train, I benefited from the help of a wonderful friend and mentor.

One of the exercises that I went through was to re-read one of my favorite books, Designing Your Life and go through the exercise of Odyssey Planning. I tried to do this without thinking about what happens to the company. What I realized going through the exercise was that no future came up that pointed to an aspiration to be a CEO, a founder, or a sole decision maker for others. Instead what did come up were aspirations for balance, authenticity, health, presence, and to have a rich life. Nothing came up that required massive amounts of money or control.

This exercise was a major catalyst for making my mind up about ending the startup experiment. ⁴

I feel so incredibly lucky (and spoiled)

On one hand, I am -- yet another -- failed startup founder 🙃

I didn’t go all in to make my company successful. I didn’t make a dent in the universe. I earned a fraction of what I would have earned had I simply stayed in my past job. I didn’t even spend most of the funding that I raised…

On the other hand, I feel incredibly lucky to have spent the last year:

Intentionally building an entire company from scratch
Testing many assumptions
Getting experience in fundraising and interacting with investors -- from micro-VCs to the largest investors in Silicon Valley
Learning a lot more about hiring and people management
Learning more about the healthcare and AI space
Getting back to my roots as a researcher and software engineer by doing months of focused development work
Reading tens of books
Meditating for hundreds of hours
Running tons of miles
Eating healthy homemade food for most days and being close to my wife and dog

And I got paid doing all that.

I genuinely don’t regret this failure and have a pretty good idea of the next life experiments that I want to run!

Lastly, and most importantly, I am so grateful for fellow friends, family, employees, advisors, and investors who helped me spend this year in the startup land.

Turns out this is really hard to do if you are building a VC-backed company. I strongly recommend bootstrapping and not raising funds if this is truly your intention. It is also extremely hard to compete in a market where others don’t play by similar rules. ↩︎
In case you are thinking about doing a Vipassana and want to hear about my experience, I have a lot more to share! ↩︎
During a few months of coding, I used Cursor so much that I ended up in the top 1% users in San Francisco and got invited to their office for a meetup 😂 ↩︎
It might be worth noting that I ended up not spending most of the raised funds and returned the remaining amount to our VC. ↩︎

The challenges of building LLM-powered clinical care navigation apps

Fri, 06 Jun 2025 12:00:00 -0700

TL;DR: I spent 9 months building LLM-powered apps to help cancer patients navigate clinical care—chatbots with EHR integrations, appointment prep tools, and iOS apps (that Apple kept rejecting). I found real use cases and built working prototypes, but I discovered that LLMs aren’t ready for safe clinical use by patients. The core structural issues—context building, grounding, and usefulness—won’t be solved by the next model release. This is my personal experience; LLMs remain amazing for other use cases like prototyping the very applications illustrated in this post.

About 9 months ago, I set out to test a hypothesis:

Given that people already use general-purpose chatbots for health concerns, one could theoretically build a business around a specialized, LLM-powered app for clinical care navigation.

And presumably, this specialized approach could lead to higher quality, accuracy and usefulness compared to the off-the-shelf general solutions.

I chose an area that was very close to my heart: the problem of navigating the tough journey of cancer care.

This writeup captures—in perhaps an excessive amount of detail—my learnings from this nine month journey and the challenges I discovered.

The Use Cases

I spent a few months researching the most common user needs in this space to find a problem-solution fit. I talked to physicians, nurses, specialists, patient advocates, and of course, many patients.

My research led me to several key use cases that seemed feasible, desirable, and viable as product directions:

Understanding one’s diagnosis and medical records
Figuring out what questions to ask providers and preparing for visits
Dealing with treatment side effects
Researching alternative treatment paths
Patient self-advocacy and empowering caregivers
Capturing and debriefing interactions with providers

The Prototypes

One of the most fun parts of this journey has been the ability to go back to coding after years of “product managing.” The tools I used (mostly Cursor + Claude) kept getting better almost monthly. And I grew with them. I’ve developed a pretty sophisticated symbiosis with AI-coding toolkits that almost warrants its own article—though there’s already a lot being written about this, so I’m not sure I have unique insights to add. Being able to turn ideas into real working prototypes in a matter of hours/days was very transformative in my explorations.¹

Here’s what we built:²

1. A Series of Mini Apps

One that facilitated talking to a chatbot specially designed to pull data from authoritative sources (e.g. cancer.org) and annotating complex medical terms in its responses to meet the average user’s medical literacy level
One that facilitated talking to a PDF export (thousands of pages) of a patient’s MyChart data while linking to the specific parts of the PDF file to validate citations in the model’s responses
One that helped people get a “second opinion” on a question using Deep Research features from different platforms while passing their entire health records through a MyChart PDF export

One of the mini apps (chatbot) that annotated medical terms and cited authoritative sources.

2. The first major Web App

After building the series of mini apps, I ended up building a full web app that allowed people to connect to their provider’s EHR instance through a FHIR interface so they could:

Generate an overview of their care and summarize their health records with an LLM
Generate insights about their journey that they could use as conversation starters with an LLM
Ask questions about their history
Create a list of notes and insights to discuss with their providers

Screenshots from the first web app that allowed users to connect with their EHR system and chat with the results

3. An iPhone App (The Apple Saga)

Your browser doesn't support video playback. Download the video to view it.

One of the native iOS apps that I built to ground an LLM on the user's HealthKit medical records

Most of my time was spent building a native iOS app (in Swift) that did everything above but also let users connect the app to their medical records through Apple’s HealthKit. Why go the iOS route? I discovered that fetching user data through a third-party FHIR data acquisition service was prohibitively expensive. It also required users to trust not only us, but also our third-party service with their sensitive health information. Meanwhile, Apple had built a solution with the most reach in the US, Canada, and UK for fetching patient records—and it was FREE. So I figured it was worth building a snappy native iOS app on top of this functionality. I added features to record appointments, transcribe them, and discuss them with an LLM grounded in both the appointment and the user’s health history.

Apple never approved the app. I never got a straight answer as to why, but I suspect it was because they did not want to allow off-device processing of users’ health data, even with clear explanations and user consent.

I even built a much simpler version that did a single LLM call to generate the user’s health journey (demo). I labeled it with all sorts of disclaimers and drafted a very privacy-centered Privacy Policy. The policy indicated that data would only be processed on a HIPAA-compliant backend and never stored beyond processing time on Google’s Vertex AI, which we had a HIPAA BAA (Business Associate Agreement) with. My apps are still in review and have been rejected 10+ times. It’s starting to feel like Apple is simply stalling me. I still don’t know whether I can run a remote HIPAA-compliant LLM on HealthKit medical records data even without storing any patient data. Given what I will explain later in this article, while this issue was a catalyst, it was not the root cause of my decision to pause this direction.

4. Another Web App

Your browser doesn't support video playback. Download the video to view it.

The final web app built as the final attempt to test the original hypothesis

In response to Apple’s App Store rejections, I recreated the iOS app as a web app. By this time, Claude 4 had come out and I knew what I wanted to make, so this iteration went by at least 5 times faster than the iOS app. I also added a way to detect health “memories” from chatbot conversations (using function calls) to reduce the barrier of asking users to trust us with all their medical records. I later added the ability to bring in MyChart data to this app too.

I thought about open-sourcing all these apps. But their reliance on ever-changing web services makes them quickly obsolete.

Reflecting on the Limitations

While any attempt to summarize the limitations of LLMs is doomed to become obsolete within weeks due to their seemingly exponential growth, I’d like to think that I gave this idea an honest try.

If I had to sum up my learnings in one sentence: LLMs aren’t safe for direct clinical use by patients—not yet.

While I had different product iterations ready for public testing, my conscience didn’t allow me to put them up for people to freely try. I would literally dream of someone using them, getting wrong results, and feeling responsible for the suffering they would experience. Maybe this mentality makes me unqualified for working in healthcare.

The Root Causes

As usual, there are a million reasons why a startup idea might fail. It’s expected for startups to pivot a few times until they find something that works. Much of it is timing, founder problems, and systemic external issues (like the mess that is the US Healthcare system). But I have enough data to say, with 90%+ confidence, that I cannot make this idea work within a reasonable timeframe. This would be true even if every other factor was held constant. Sure, it might work if LLMs became hallucination-free and perfectly steerable tomorrow. But knowing a bit about the technology behind them, I’m not sure this will happen anytime soon (though I’ve been working on and waiting for that day for two years and counting).

The way I break down the key failure reasons in my head:

Impossible context building
Impossible grounding
Limited usefulness

The rest of this writeup explains these three core challenges.

1. Impossible Context Building

The promise that patients should own and have access to their personal records dates back many years. There are countless trials and startups trying to make this dream a reality. Some have failed. Some have been acquired by big-tech companies (e.g., Gliimpse and Ciitizen, both built by the same founder who is now creating Selfiie 🤨).

But what’s clear is that no single person I know has access to all their data. Yes, you can log into MyChart and get an intentionally convoluted dump of your records—a mix of PDFs, structured data, and clinical notes that would challenge even the most sophisticated parser. But that’s just one health system. What about the urgent care visit from five years ago? The specialist you saw in another state? The dental records that might be relevant to your cancer treatment?

The fragmentation is staggering. Each provider uses different systems, different formats, different standards. Even within the same hospital network, data might be siloed across departments. The promise of interoperability remains largely that—a promise. And without comprehensive context, any LLM system is working with a dangerously incomplete picture.³

2. Impossible Grounding

I tried almost every tool in the toolbox: RAG (Retrieval-Augmented Generation), Function Calls, MCPs (Model Context Protocols), passing everything to the models with large context windows. There’s always some part of the system that fails. And the errors aren’t recoverable or transparent, which makes them really hard to reliably avoid.
It’s not like traditional systems where you actually get an error. The model just makes a best “guess” and confidently gives an inaccurate response. Or it gives a response that exposes the prompt and inner workings of the system. I see this frequently with ANY system that has an open chatbot interface.
While this issue is forgivable in low-stakes use cases, when users ask a system for information that could lead to life-or-death outcomes, this behavior breaks their trust. Imagine talking to your nurse and at some point in a deep conversation, they just confidently stop making sense. Your relationship with that provider is over.

And yes, I know the theory that as long as your solution is better than the alternative human option, it’s alright. But in a clinical setting, that idea is dangerous. Yes, ChatGPT and Claude already operate on that premise. But at least they’re not marketing a health product. If they did, I bet they’d be in massive legal trouble. I, however, was setting out to make a health product and don’t have the legal team that big tech companies have.

3. Limited Usefulness

Even when everything worked in terms of context assembly and grounding, the likelihood of users actually knowing what to do with the model’s output was low.

Let’s take the case of hard decisions about surgery versus chemo for a cancer patient.

Assume the model knows everything about the patient’s medical history. It’s asked whether the patient should do chemo or surgery. First, this question is medical advice. So from a legal perspective, we should punt.

If we punt, the patient assumes the system is useless because they could just use ChatGPT or Claude and get an answer.

So we shouldn’t punt? The best we can do is what ChatGPT does: give a best-effort answer sandwiched in disclaimers. My argument is that for hard questions, any answer is tricky.

The trickiness arises from the fact that there is no easy right answer.

I got to this conclusion when researching my late aunt’s case. She was diagnosed with Stage 4 pancreatic cancer. Her family had to decide if she should get chemo or join an immunotherapy clinical trial. The answer to this question is so multifaceted. The LLM’s eagerness to please makes it very likely to start spewing information to the user, giving a gigantic list of options, and listing their pros and cons. Sure, that’s better than no information, but the truth is Stage 4 pancreatic cancer is barely survivable. My aunt passed away about a month after her diagnosis even though she was in her sixties.

In that situation, the patient and caregivers are looking for clarity and less information. Not more options and content to overwhelm them. The right “answer” for them was really to spend more quality time with each other rather than endure more pain and suffering through treatment.

This taught me that the most critical healthcare decisions aren’t just clinical—they’re deeply human, contextual, and often about quality of life rather than quantity. It’s impossible to give a good answer if you just focus on clinical aspects of someone’s life. There are moral, religious, and personal aspects that need to be considered. And this takes us back to the first problem: it’s impossible to meaningfully know that context at large scale.

The Business Model Reality Check

Aside from these structural challenges we still haven’t even considered answering the fundamental question: how might one make money from this idea?

The usual business models for direct-to-consumer health tech companies are:

Selling the data
Showing ads
Charging for subscriptions
Partnerships (i.e. B2B2C) with providers, payers or pharma

Options 1 and 2 are out of the question for me. Health data is different. It’s a part of you.

Option 3 is the most common path, but faces two major challenges: (a) patients notoriously have low willingness to pay for health tools, and (b) the product needs to be strictly better than alternatives. When we frequently punt on hard questions while ChatGPT and Claude do not, it’s tough to justify the subscription cost.

Option 4 is an area that I also explored, but frankly, due to the lack of feasibility and usefulness I described above, I didn’t see a major path for success there either.

So, Now What?

Are there other clinical health problems that LLMs could help with? Absolutely. Does the idea of building a patient-facing clinical cancer care navigation app make sense for an early-stage startup? Not yet. And my reasoning is based on the structural issues I’ve outlined which I don’t think will disappear with the next LLM model release.

A question that led me to clarity is: How would I now deal with a personal cancer case? How would I use technology for it?

My answer, after thinking about this use case for so long, is that I would actually just use off-the-shelf tools. I would upload all the important parts of my data (personalized context assembly) to a Claude Project and run Deep Research agents on my questions. I would record my appointments on my iPhone’s Voice Memos and upload them to that Claude project to reference them. I would also use Claude to think about the best questions to ask for my upcoming appointments.

Yes, it’s not HIPAA compliant, but so what? They say they’re not training on my data, and their claims on respecting data rights are as good as any other company. Their security measures are better than a small startup, even if the startup has gone through a HIPAA checklist and has the documentation for it. And if I’m too worried, I can only give them parts of my data that aren’t identifiable.

Is this something that only highly capable users can do? Yes. But my argument is that only those highly capable people can actually process these answers. Just because chainsaws might now cost zero doesn’t mean we should give one to everyone.

What’s Next?

I wrote this long writeup for myself to make sense of my past 9 months. I would be delighted if it helps someone else or at least helps others start where I left off. There is a major problem-solution fit for using LLMs for navigating complex diseases. The big question for me wasn’t whether people should use them (assuming they know what they’re doing). The big question was whether someone should build a new company around this concept today.
I want to teach the useful things I’ve learned to caregivers and patients. If they’re at the edge of knowing how to use these tools, I want to make them more productive. An educational module could achieve that with relatively low cost. I might also do some talks at cancer support groups.⁴
I’ll probably try something else in the oncology space or explore the non-clinical aspects of care navigation (e.g. financial navigation). But I need to do more market research first.

Would I do everything the same if I could go back 9 months? Probably. How would I do it differently? I would be nicer to myself. I had picked a very complex problem. I should have had more grace for my struggles in navigating it.

I hope you found this writeup useful.

As a former PM, I think we can now replace much of our traditional PRDs with AI-coded prototypes paired with clear evaluation criteria and initial test sets. ↩︎
I would not have been able to do the work I mention in this article without the generous and heartfelt help from a group of incredible collaborators. While this list is incomplete, I would like to thank Daniel Matiaudes (my design partner), Joan Venticinque, Dr. Jeanne Shen, Dr. Matthew Lugren, Srecko Dimitrijevic, Jenny Rizk, Jake Knapp, Jeanette Mellinger, John Zeratsky, Eli Blee-Goldman, Dr. Howard Kleckner, Rob Tufel, Thushan Amarasiriwardena, Henry Schurkus, Anna Brezhneva, Naxin Wang, Cody Sam, and of course my wife Rana, who was my very patient sounding board over the last 9 months. I also want to cherish the memory of my beautiful and loving aunt who passed away while I was working on this idea. ↩︎
You might rightly counter that even doctors do not have the full context for a patient’s case. My argument is that doctors—due to their training, specialization and contextual understanding of the local systems they operate in—have a much better ability to figure out missing pieces of information. The first thing that a doctor usually does is ask for the full details of your relevant tests and symptoms. The first thing an LLM does is … well, it eagerly tries to shower you with tokens. ↩︎
If you’re interested in having me speak at your cancer support group or organization, feel free to reach out! Contact details are on my about page. ↩︎

On mortality, music and perfection anxiety

Tue, 14 Jan 2025 00:00:00 +0000

Note: This post is going to be imperfect in so many ways. And that’s probably ok.

A picture I took during our recent trip to the truly beautiful Grand Teton National Park

About 2 years ago, after months of dealing with chronic stomach ache and digestive problems, I finally managed to get my gastroenterologist (GI) specialist at UCSF to prescribe me an endoscopy and colonoscopy. Before then, my GI specialist was (understandably) suggesting that I should just take more fiber in my diet and should instead work on reducing my stress levels, which were likely the cause of my psychosomatic symptoms. Given my young age and lack of severe symptoms, there was no reason to be worried, but having tried almost everything on my end, I just felt like something was fundamentally off with my insides.¹

I woke up from my (first) colonoscopy on August, 8, 2022 feeling weirdly calm. The country was still recovering from the COVID pandemic and the hospitals still didn’t allow anyone other than the patients inside. The first face I recognized while laying in the hospital bed was my GI surgeon. In a soft and calm tone she said: “Hi Amir. I am really glad you came in for this. We found a lot of polyps in your stomach and colon. We removed most of them but you have to come again in six months for a second surgery. You should do regular screening going forward.”

I felt a mild combination of shock and relief. I was however a bit too high on drugs at that moment for my usual problem solving mode to kick in. My loving wife, who had been waiting nervously for me to get discharged at the hospital parking lot, then picked me up and we rode back home. We now had to wait for a pathologist to analyze the extracted tissue from my body and tell us if it was cancer or not.

I waited for almost a week with no news. I then decided to call UCSF to inquire about my results. After a brief hold on the call, the nurse told me that my pathology diagnosis was ready 2 days after my operation but was held up to be released by my specialist whose first available appointment was another month away!

Completely freaked out by my predicament, I asked for a copy of my pathology report and started Googling my way into understanding it. At the time, ChatGPT was not yet launched – though coincidentally I was part of a small team working on an internal yet less capable version of Gemini at Google (and we had no idea it was such a big deal 🙂)

An excerpt from my first pathology results

The key word was “sessile serrated adenoma”: a precancerous polyp in the colon that can develop into colorectal cancer. After my second colonoscopy and a total of 13 polyps – some up to 2 cm in diameter – removed from my colon, I was diagnosed with Serrated Polyposis Syndrome which recent studies indicate has a ~20% chance of colorectal cancer (CRC). CRC is the second most fatal cancer but has a much better survival rate if caught early.

So to summarize, my obsessive health anxiety (and access to great care at UCSF) might have led to me preventing a likely fatal disease in my thirties.

Having had my first serious brush with my mortality, I started to really reevaluate my life. I read The Good Enough Job (now a TED talk) and started thinking more deeply about how I had been spending my life at work. In my next ~1.5 year at Google, which coincided with a 6% layoff at Google impacting many people that I personally knew, I started wondering if I was really spending my life on something that genuinely mattered to me and my values. I spent a few months thinking about what I should do next, but it felt like I did not have the capacity to work on one of the most stressful projects at the company while building an alternative career in parallel. I decided to quit with no concrete plans on what was next. It felt extremely scary but also very empowering.²

“Going was dying, and staying was dying. When we get to junctures like that, we had better choose the dying that enlarges rather than the one that keeps us stuck.” — JAMES HOLLIS

After quitting my job, I ended up taking a short career break and did a few things that I had always dreamt of never got a chance to do. Two noteworthy items were:

Making music for a few months and publishing four songs with professional musicians on Spotify (more on each song on my Instagram)
A 10 day Vipassana in the mountains of Idaho, getting attuned with my body’s sensations, and a crash course on Anicca.

Both of these activities were extremely imperfect. Music making made me feel incredibly vulnerable. I felt like the entire world would judge my work for its shortcomings (I still feel the same most times). But I had a goal of making at least a handful of professional recordings and keeping them for my future self. Looking back, this process was incredibly rewarding and productive. Almost each song was an improvement over the last one. I tried different genres and I realized what registers my voice sounds best on. I also learned how to work with artists – whom could be incredibly moody at times 😆

Album covers for my four songs done by my wonderful friend @alimation

Vipassana was also a major mental challenge in accepting imperfection. Sitting for 10 hours for 10 days while simply focusing my attention on my body’s sensations, not reading, not writing, not speaking or even making eye contact with anyone, and skipping dinner everyday, was incredibly rough. I questioned every aspect of the course on an hourly basis and considered quitting multiple times. But when it was done, it felt like it made sense. I don’t know if I will ever have the luxury of doing this practice again, but I will never forget the serenity and genuinely “happy” feeling I had at the end of the 10th day. I will also not forget the sense that it felt like I had just found a way to look inward after 36 years of my very outward focused presence in the world.

“That which seems like a false step is just the next step.”
— AGNES MARTIN

For most of my time away from work, I was thinking about what to do next. With a nudge from one of our awesome investors, I ended up taking a major leap of faith and decided that what I should do next was gathering what I had learned in my years of working in Healthtech and AI to build something that helps cancer patients. Something that I would want if (or when) I would be diagnosed with cancer.

I would be totally lying if I said that this endeavor has been a piece of cake. As our investor beautifully put it in a recent podcast episode, I suffer from a massive amount of – hereditary – Perfection Anxiety: the deep discomfort of having something that you want to make amazing and yet realizing that you will probably screw it up somehow. I am happy to confirm that I have found Design Sprints to be a genuinely useful method for dealing with my perfection anxiety. My wonderful team and I just chip away at our goal, one Sprint at a time.

My one-person kayak

The motivation for this long, disorganized and imperfect story was me reading the wonderful book, Meditation for Mortals, this year. The gist of the book is that we are simply on a path to our death. And if we accept this undeniable fact, then we can – counterintuitively – reduce a lot of our anxieties. One of the chapters is called “Kayaks and superyachts.” The author elegantly says:

To be human … is to occupy a little one-person kayak [as opposed to a fancy superyacht], borne along on the river of time towards your inevitable yet unpredictable death. It’s a thrilling situation, but also an intensely vulnerable one: you’re at the mercy of the current, and all you can really do is to stay alert, steering as best you can, reacting as wisely and gracefully as possible to whatever arises from moment to moment … The challenge, then, is simple, though for many of us also excruciating: What’s one thing you could do today? … Because the irony, of course, is that just doing something once today, just steering your kayak over the next few inches of water, is the only way you’ll ever become the kind of person who does that sort of thing on a regular basis anyway.

I’ve been thinking about a theme, a resolution, for this year. And I think I have finally found it: accepting imperfection. I am inherently the most imperfect being. I am on my little kayak and on my path to an eventual, undeniable, death. We all are. All I need to do is to do one thing a day that I find meaningful. It will be imperfect (like this very long post) and likely wrong. Even when I think I’ve taken the correct path, it is just a rationalization because we just don’t know what the world would have been had we taken an alternative path.

Accepting my very real and liberating (if not always comfortable) lack of control gives me hope that I can somehow live with my perfection anxiety and make things that matter.

Thanks for reading.

Notes

I learned later on that the key that led to my GI specialist succumbing to prescribing me a colonoscopy was my mention of my aunt passing away due to stomach cancer in young age, which I believe made it more likely to get insurance to pay for my procedure due to family history. ↩︎
I have to give due credit to my wife who supported me during this really strange life period. I probably would have been lost without her. ↩︎

LarryGPT – State of LLM Fine-tuning in August 2024

Thu, 01 Aug 2024 00:00:00 +0000

“Curb Your Enthusiasm,” created by Larry David

TL;DR: I explored the journey of fine-tuning two small LLMs: Llama 3.1-8B-Instruct vs GPT-3.5-Turbo on a fun dataset of GPT-4o generated conversations in the style of Larry David. All the code for this project and evaluation results are openly accessible. This approach could provide a major cost/latency/privacy advantage if one is interested in small models for specialized use cases.

Background

While LLMs continue to get multi-modal, larger and more “intelligent”, there is an emerging realization that a single massive, centralized and generalist LLM may not be the right answer for all use cases. AGI may not in fact be a singular HAL-like super intelligence but a rather decentralized collection of small and specialized models thoughtfully integrated across our technological presence.

Current state of the art LLMs are also expensive to run – even the open weights ones – and asking users to share their data with a centralized service is not always the most privacy-aware option. In addition to the cost and privacy limitations, not all expected model behaviors are easily “promptable” and it is sometimes easier to “show” a small model what we need rather than “tell” it to a large generalized model in multiple paragraphs of instructions. Enter model fine-tuning. Done in a variety of ways, this technique enables further training of LLMs with high quality example data that captures the expected behavior. Even though fine-tuning should only be considered as a last resort, there are in fact specific scenarios for which fine-tuning might be a reliable and cost-efficient solution – with my favorite one being Apple’s use of a 3B parameter on-device model for the new Siri.

This long-form post captures the culmination of my multiple attempts at LLM fine-tuning over the past year by demonstrating two state of the art methods: fine-tuning (1) GPT-3.5-Turbo, Open AI’s cheapest yet closed source model vs (2) Meta’s Llama-3.1-8B-Instruct, which was the top performing small/medium size open weight model at the time of this writing.

All the code and data for this project is available on this repository and in case you’d rather jump to the final results, you can view those here.

LarryGPT

One of the use cases for which fine-tuning is indeed relevant is when we want to set the tone, style or other qualitative aspects of a model’s responses. Given my admiration, empathy – and perhaps unfortunate self-identification – with Larry David’s character in Curb Your Enthusiasm, I figured it would be a fun exercise to fine-tune a small/medium LLM to impersonate him while responding in a structured format and annotating the range of emotions in his quintessential rants.

Here’s an example output that we want such model to generate:

User: “Larry, what are your thoughts on tipping?”

Model:

[
 {"text":"Oh, tipping. ", "emotion":"irritated"},
 {"text":"Don't even get me started on tipping. ", "emotion":"exasperated"},
 {"text":"Isn't that why you have a job? ", "emotion":"confused"},
 {"text":"To get paid by your employer? ", "emotion":"confused"},
 {"text":"Why is it my responsibility? ", "emotion":"irritated"},
 {"text":"I mean, I'm already paying for the food! ", "emotion":"exasperated"},
 {"text":"Now I have to pay you for bringing it to me? ", "emotion":"exasperated"},
 {"text":"It's like paying extra for breathing air! ", "emotion":"sarcastic"},
 {"text":"Ridiculous.", "emotion":"frustrated"}
]

Dataset

To generate a dataset for this project, I decided to go with the common approach of synthetic data generation. In simple words, I used GPT-4o to generate a series of conversation starter prompts and for those I generated a high quality set of responses by setting a System prompt that described the intended behavior to GPT-4o. I then used this dataset to train the two smaller LLMs. You can read the detailed data generation code in this notebook.

Training GPT-3.5-Turbo - Closed source fine-tuning as a service

I have done model fine-tuning on multiple occasions using both proprietary and open-source tools but I have to say that the OpenAI’s Fine-tuning API is by far the simplest, fastest and most robust method I have come across. The detailed process is described here on their developer guide which I strongly recommend reading but you can also follow my code here.

In short, all I needed to do was to create a JSONL format of my training and validation data, upload the files to via their API and simply kick-off training by running this one Python function:

job = client.fine_tuning.jobs.create(
 training_file=train_file.id,
 validation_file=valid_file.id,
 model="gpt-3.5-turbo-1106",
 suffix="larry_david",
 seed=42
)

Once the training was done, I got a nice “Fine-tuning job … successfully completed” email and the model was ready to be used for inference both via the Chat Playground as well as the API. I then ran the validation set against the newly created model to generate the model responses to be compared with other paths.

OpenAI’s Console using GPT-3.5-turbo (left) vs Fine-tuned version (right)

Training Llama 3.1-8B-Instruct: Open weights model trained using open source libraries

The open source ecosystem around LLM training, serving and evaluation is incredibly rich. For this project, I used Unsloth AI’s approach which through a wide range of clever hacks enables LoRA training for 8B parameter models on a free-tier Google Colab notebook (code). This means the cost of this training and inference for this model was practically zero dollars. That is of course excluding the cost of 10s of hours of developer time that goes into debugging an ever changing/unstable complex set of tools and randomly crashing free Google Colab kernels 😆

The most tricky parts of fine-tuning Llama 3.1 were: getting the training data into the expected chatml format, sorting out nuances of tokenization, dealing with memory issues due to apparent lack of memory garbage collection in the libraries, and figuring out the right values for a large number of hyper parameters. These were of course issues that could be likely abstracted away with simple wrappers on top of existing libraries.

Open Source LLM’s Developer Experience

Though I was able to read the API docs and fine-tune the GPT-3.5 model in less than an hour, understanding the many steps and edge-cases for training Llama 3.1 8B took me about 1-2 days of focused work. In other words, what was gained due to lower cost of training using the open weights model comes at the price of the much worse developer experience. Having said that, I expect the open source toolchain to get better and I am almost certain that there are hundreds of LLM startups working on building a one-click Llama training service similar to Open AI 😬

Results

Even if we fully solve model fine-tuning, model evaluation is perhaps the most complex and unsolved part of the LLM development process. How do we ensure that the information in the training data was in fact “learned” by the model? How should we properly compare alternative models when much of the evaluation criteria is so qualitative? Having spent most of my time in my previous job on model evaluation, I think I will leave my thoughts on evaluation for a future post to reduce the chance of this post turning into an actual textbook. But for the sake of completeness, I built a simple evaluation UI – with the help of my brilliant friend, Claude Sonnet 3.5 🙂 – which allows us to go through a set of validation data which I randomly held-out from the full generated dataset to be used for evaluation.

Simple Side-by-Side evaluation UI

🥁 And the winner is…

First, I would like to appreciate that you have read this far in this long post! As mentioned at the beginning of this writing, my goal in this project was to contrast the experience of fine-tuning a closed source model with the open weights one in 2024. When it comes to results, I think it’s worth crowning the winner in a few different categories:

Developer Experience and Speed:
1. OpenAI’s API for model training and inference is definitely ahead of competition (though, as I mentioned, this is not so hard to replicate for open weights models)
2. The actual fine-tuning job for OpenAI took ~16 minutes. Strangely however, the model inference took twice the time compared to the vanilla GPT-3.5-Turbo.
3. The fine-tuning job for Llama 3.1-8B took ~9 minutes for the same number of epochs as GPT-3.5-Turbo but inference was much slower (~10 seconds on Google Colab vs 3 seconds on OpenAI API). This is likely the outcome of the cheap GPUs used on my Google Colab. Grok has shown that one can run inference on Llama 3.1-8B with the incredible speed of 1000+ tokens/second. In contrast, the best inference speed I got from the vanilla GPT-3.5-Turbo was around 150 t/s and half of that for the fine-tuned model.
4. I do believe that the key reason that this was a relatively easy and managable process for the open weights model was the small model size. This process could be much harder and more expensive for larger models – though I am not sure that fine-tuning a very large model makes a lot of sense for most use cases.
Cost: Llama 3.1-8B and the resources used in this specific demonstration were practically free. Hence Llama 3.1-8B wins this category. Through this exercise I realized that OpenAI charges twice more for inference on top of fine-tuned models. I did try to do this exercise with GPT-4o-mini first but I did not have access to fine-tuning because I wasn’t a high-tier customer.
Results Quality: As you can see for yourself (example), we were able to successfully train both GPT-3.5 as well as Llama 3.1 to generate GPT-4o level quality responses in our desired tone while sticking to the expected output format. Llama 3.1 generated incorrect format in 30%+ of the eval cases before fine-tuning and this issue was fully fixed after fine-tuning. GPT-3.5 had 2% incorrect formatting both before and after fine-tuning.

Conclusion

The following are my key takeaways from this project:

For specialized and narrow use cases, small models can indeed be fine-tuned with high quality data from larger models showing significant improvements in generation quality, cost and speed
OpenAI’s fine-tuning API is simple and robust but a bit expensive and closed sourced. This makes the use cases of cost reduction and privacy constraints less relevant. It would perhaps be a major value propostion if OpenAI publicly shared a small open-weight model that could be fine-tuned using their high-quality data generation and model evalution capabilities on their Platform.
It is very much possible to fine-tune state of the art small open weight models on a free-tier Google colab and use them in production, even if you are a rusty former software engineer turned PM like me. This is incredibly exciting! 🤩

Again, thanks for reading this long post and I hope that you have learned something. Feel free to reach out to me via email () if you would like to chat more about this topic or subscribe to my newsletter to get notified about the future posts!

Building AI Dialer

Fri, 12 Jul 2024 00:00:00 +0000

TL;DR: I built AI Dialer, a full stack Python app for interruptible and near-human quality AI phone calls by stitching LLMs, speech understanding tools, text-to-speech models, and Twilio’s phone API. This post is a long-form companion piece to this repository on Github.

AI Dialer's web user interface

Your browser does not support the audio tag.

Example audio recording with AI Dialer

Background

Phone calls are time-consuming and anxiety-inducing. But their ubiquitous and synchronous nature has resulted in their continued existence for more than a century. Phone calls are also a significant portion of “back-office” tasks that currently amount to billions of dollars in spending across enterprise industries such as healthcare.

Built upon the widespread general availability of AI technologies for text and speech processing, numerous startups have set out to build the next generation of AI-powered callers. This project is my personal exploration of this use case which culminated in a full-stack Python application that facilitates interruptible and near-human quality AI phone calls and supports LLM function calling during a phone call.

How it works

Simplified architecture of AI Dialer

With heavy inspiration from this project from Twilio Labs, this application wires up the following key components:

Phone Service: makes and receives phone calls through a virtual phone number
Speech-to-Text Service: converts the caller’s voice to text – so that it can be passed to LLMs – and understands speech patterns such as when the user is done speaking or interrupts the system
Text-to-text LLM: understands the phone conversation, can make “function calls” and steers the conversation towards accomplishing specific tasks specified through a specified “system” message
Text-to-Speech Service: converts the LLM response to high-quality speech
Python Web Server: provides end-points for
1. Answering calls using Twilio’s Twilio Markup Language (Twilio ML)
2. Enabling audio streaming from and to Twilio through a per-call WebSocket
3. Interacting with the basic Streamlit web UI
Python Web UI: provides a way to initiate calls and specify system/initial messages for LLMs, follow the conversation in real-time, and listen to the call recordings

Why was this complicated

Streaming

The complexity of this project comes from the fact that each constituent service (Twilio, LLM, TTS, …) introduces a meaningful amount of latency to the overall process. The only way to minimize latency is to stream content from one service to another as soon as a “chunk” of data is available to pass to the next service. But this chunking does need to be done with a bit of calculation. As an example, the way a sentence is pronounced is both a function of how it starts as well as how it ends. So we need to break the LLM output by sentence as they are generated. We also cannot send the user’s query to the LLM before they have stopped talking, therefore we cannot start generating the LLM response before the user has come to a natural pause.

Parallelism

The caller and callee can talk at the same time and all pieces of the system should be kept busy as data becomes available from their upstream service. This requires the system to be implemented in a fully parallel architecture. While the original Node-based implementation of this project heavily leverages Node’s native Event-driven programming, I had to implement this pattern using Python’s asyncio library – which involved getting a good amount of help from my LLM programmer [friends](see Acknowledgement) 🙂

Interruptions

This project does not take advantage of OpenAI’s GPT-4o’s Audio-to-Audio feature because it was not released at the time of its creation. Interruptions are handled by reactively breaking the flow of audio generation if speech is detected when a Twilio audio stream is in progress and resetting the underlying services. This process does work relatively well but could result in speech disruptions mid-word which could sound different from how humans deal with interruptions.

Open challenges and opportunities

While the first version of this project does demonstrate a rather impressive starting point and provided a fun learning opportunity, I did uncover a few open challenges and opportunities through the course of building this service including:

Challenges

Phone audio is very lossy. Phone land lines (and Twilio) are encoded with 8000 samples per second and 8-bit quantization using the G.711 codec (A-law or μ-law). The potential environmental noise, microphone distance to the speaker’s mouth and accents also add additional complexities to this audio loss. While advanced speech to text models do exist that can overcome these challenges, a real-time speech processing engine does have to prioritize speed over quality. This also loss sometimes results in awkward situations in calls when the system misunderstands the users.
The initial delay to get to the first sentence for LLMs and first byte for TTS are simply impossible to overcome in this design
1. I wrote a basic script to measure the latency distribution for OpenAI (GPT-4o) and Anthropic (Claude 3.5 Sonnet) in generating one small sentence over 10 trials. Based on my measurement, Claude Sonnet 3.5 took Avg: 763.72 ms, Std: 294.35 ms, Min: 512.37 ms, Max: 1467.52 ms and GPT-4o took Avg: 459.85 ms, Std: 123.68 ms, Min: 290.15 ms, Max: 635.97 ms. This means on average 0.5-1 second of response latency is due to LLM generation
2. On top of the LLM, the speech understanding and generation also adds some latency (another 1-2 seconds depending on what service is used with Eleven Labs taking significantly longer).
3. Network time for round-trip requests between different services and the web-server does add up to another 1-2 seconds.
User’s tone of voice is lost during speech to text conversion. This can be really challenging to overcome especially when the user is angry or frustrated on the calls (which happens to be common)
TTS speech speed is not controllable. Imagine the user asks the system to repeat a number slowly. The current design simply is not capable of this.
While the support for two LLMs (GPT-4o and Claude Sonnet 3.5) and two TTS (Eleven Labs and Deepgram) is implemented, there is a wide range of differences between the services of the same category. For example, Claude requires a much more verbose and specific system prompt to stick to a brief and conversational tone whereas GPT-4o is a bit too eager to give information about the task even when the user has not yet asked for it. The two models are also different in their tendency to run (and even the expected format) for function calls. Deepgram’s TTS is much faster compared to Eleven Labs but it unfortunately comes with the cost of strange mispronunciations (e.g. when a phrase has both words and numbers).
Enabling robot phone calls is a double-edged sword. In a world that misinformation and robocalls are rampant, creating yet another tool for these activities should be done with extra care and responsibility. My assumption is that this responsibility is enforced via Twilio’s own Acceptable Use Policy and Report Abuse system. I however do believe that projects such as this could help lower the barrier for irresponsible usage even though this is far from my intentions.

Opportunities

One straightforward opportunity could be to try the future version of GPT-4o and remove the Speech-to-Text and Text-to-Speech modules. I am however not certain that this version of GPT-4o would be as “controlled” as the text version as the user could really bias the model’s output via significant control over the range of emotions and tone of speech. This “openness” might in fact be a liability, especially in an enterprise setting.
The current implementation does not chunk audio streaming. This is a straightforward addition that could be added.
The user interface is currently very bare and could be expanded to support addition of function calls via UI, saving prompts and stateful memory (via using a database for storing call logs).

Acknowledgement

This project would have not happened without this great TypeScript example from Twilio Labs. Claude Sonnet 3.5, GPT-4o, and Aider also provided ample help in writing parts of this code base. Additional thanks to my friend Mona for trying the source code and proofreading this post before publication.

Hello World

Wed, 20 Dec 2023 19:54:42 -0800

I have been writing for most of my life. I recently realized that most of my professional writings are owned by and hidden behind the corporations where I have worked at through my career. And as for my personal writings, they have become buried in numerous social media accounts and mostly inaccessible given the sheer volume of noise in these systems.

While this is not my first attempt at blogging – I used to write blogs since the early 2000s – it is my most conscious attempt to date.

Having lived the age of social media from its beginning to today, I feel like a more distributed and self-published way to share information is the proper way, at least for me, to share my thoughts with the world.

I would be also remiss if I didn’t mentioned that this Podcast episode and it’s detailed covering of Publish (on your) Own Site, Syndicate Elsewhere did not catalyze the creation of this website.

Anyways, thank you for visiting and I look forward to sharing my learnings and thoughts with you.

I will be sharing links to the posts on this blog on my various social media, but if you are old school, please feel free to either subscribe to my blog’s RSS Feed or sign up for my newsletter.