Matthew Blode on shipping 90% AI-written code at 60 million users

From handwritten code to 90 percent written by AI

Matthew: Engineers are building for engineers, and there is a lot of innovation in this space because the models are so good at writing code. There is stuff that comes out that we get excited about putting into the product. For the most part, it is less bottom up from customers wanting more AI tools. A lot of it has been internally coming up with ideas, more exposure to the features and the competitor landscape, and thinking of alternative ways to solve a problem. You can get the AI to evaluate the AI output, but at a certain point, who is watching the watchman? You need humans in the loop. So then, how do you scale that?

Matt: Hello everybody. You are listening to Agents After Dark, powered by Prefactor. I am Matt Doughty, your host, CEO and co-founder of Prefactor. Prefactor is building the agentic control plane that lets regulated enterprises track, manage, and control their agentic stack, build a single source of truth for the organization, drive return on investment, and get the board off your back.

Today on Agents After Dark we are talking with Matthew Blode of Linktree. Matthew has built and sold two startups over the past few years and is now building Linktree’s Link Apps from within. He is also an OpenAI Codex ambassador, so he is deep in the AI coding and Codex community. Matthew, thank you very much for joining us today.

Matthew: Thank you for having me.

Matt: Not at all. To kick off: you have built two companies from scratch and gone on to exit. What changed about going from zero to one once AI became part of that stack?

Matthew: Starting in 2020, when I built VenueSafe, ChatGPT had not launched, so 100 percent of that was manually handwritten code, like the good old days. In 2023, when I co-founded Fingertip, that is the transition where things started to move, and the workflows have been evolving week by week ever since. The percentage of the code written by AI keeps climbing. Today I am probably writing less code than I ever have, but outputting more.

Managing the risk of AI code at 60 million users

Matt: The big question is that you are now working for a massive Australian success story, a billion-dollar company. How do you manage the risk of AI code getting it wrong?

Matthew: With my own startup, at a smaller scale and especially at the MVP stage, it is a priority to ship fast and iterate quickly, and your risk tolerance changes greatly. With Linktree’s 60 plus million users there is a different standard of quality. Even so, you can get an even greater benefit by leaning into AI programming, because as a code base evolves and gathers more dependencies, the AI tooling helps you review, think through, plan, and create technical specs. It is supplemental. It does not replace your ability, but it is a kind of safety net for your coding standards. Since I only joined Linktree in September, it is a new code base I am learning, so I lean on these tools to get context and find the best existing patterns. If I had gone in without AI, I do not think I could make nearly the same impact in the code base.

Matt: If you were to estimate how much code you build in Codex, or the solution of choice, versus coding the manual way, what would the split be?

Matthew: I would say more than 90 percent. Within that there are a lot of workflows for code review, for simplifying, for auditing, multiple coding agents, multiple layers of human code review, and my own review. It is not just one type of prompt. In production there are lots of layers to make sure you have velocity but are also doing things safely.

Working in discrete layers, not one big feature

Matt: That makes sense. I recently discovered Claude Code, perhaps later than most, and I went in thinking I could type a couple of prompts and it would just work. Then you realize it takes a lot of work to uncover the things that have gone wrong and to keep good engineering practice in place. None of that has gone away. When you built Fingertip as an AI-powered website builder, what was the moment you realized this was production grade rather than just a cool demo?

Matthew: Through the initial version my use of AI evolved. When I was building the MVP, Claude Code did not exist yet. I was working on the database schema and the web app inside Claude, doing conversational planning about how to build the back end, how to implement a feature, and doing research. It was a bit more removed from the codebase. Today, with Claude Code and the Codex CLI, a lot of that happens in the codebase. It has the context of your files, your AGENTS.md file, access to your GitHub, access to Linear. There is much richer context. With the models getting smarter, the workflow changed: now I input as much context as I possibly can, use plan mode, and make sure there are phases and to-dos. A lot goes in up front, and once the plan is in place the output is exceptional. It has been a gradual transition over the last few years to leaning harder and harder on AI as it can do more.

Matt: Was there a moment during that build when you shifted from conversational use of Claude into coding, and it was an aha moment of, this is going to change everything?

Matthew: I was pretty early to Claude Code, and that was the aha moment. Going from Claude in the chat, I was never really on board with Cursor. I did not find the autocompletion so useful a couple of years ago. But Claude Code being in the code base, able to read the files, figure out the context, and search, replace, and write all the code for you with this agent harness, that was the turning point. The models have gotten better and better, to the point where you can be a bit more vague and the AI still figures it out. I would not recommend lowering your standards on your prompts, but it is incredible what it works out from fairly vague instructions that, if you gave them to a human, they would say, I have no idea what you are talking about.

The invoicing bug that reached production

Matt: That was definitely my experience last week. Going to the side effects of using AI to build a startup, how did you handle bugs, hallucinations, or cases where it led to customer churn? Have you had those experiences, and how did you handle them?

Matthew: That is a good point. Maintaining feature velocity and good standards at the same time is very hard. The workflow I landed on was to work in discrete layers, instead of getting the AI to yolo the whole feature at once and hallucinate, say, API endpoints that do not exist. Being deliberate about it: we are going to work on the database schema and the migration files, find the edges of the API and how other products do it, and make sure the foundations are there. Then work on the schema for the back end and make sure the interfaces are smart and intuitive. Then layer by layer into the front end, and make sure the front end is type safe. Ultimately you can trust that the thread from top to bottom is going to be more or less functional. There is still unit testing, integration testing, manual QA, but being diligent and deliberate is still necessary.

Matt: Do you recall any examples where you lost customers as a result of an error?

Matthew: Our problem was maybe introducing features and being a bit bullish and aggressive about how quickly we wanted to ship to main and to production. There were some rough edges as we iterated towards what our customers actually wanted. Specifically, we introduced an invoicing feature, and there was a bug when we upgraded one of the dependencies. Users were trying to create an invoice and the input field did not work, because the AI hallucinated about the version upgrade. Unless you manually QA those changes, you would not necessarily catch it through the whole CI/CD pipeline.

Matt: Did that invoicing error make its way into production?

Matthew: Yeah, it did, which is unfortunate. They were not able to create the invoice. If we had been smarter about having more manual QA or more automated testing, we could have caught that issue. But there is a trade-off with feature velocity and how quickly you want to iterate, because if you have infinite unit tests, making a change becomes very hard. As a startup, your equation for testing is drastically different from a bigger company’s.

Where to draw the line on risk

Matt: That is a really good example of how something slips through. When you were thinking about where to implement AI, or where to add more testing, invoicing feels like one of those higher-risk areas where you might not introduce AI because of the risk. How do you set the line in the sand between where you are happy for AI to run with it and where you are not?

Matthew: That is fair. My risk tolerance is relatively high with my own startup. At Linktree I want to be very mindful, especially given the size of the user base. Those two scales are interesting. Regardless of invoicing or, say, writing a blog, there are scales within the feature: if you are handling currencies and tax, there are different trade-offs. Company size, user base volume, and risk tolerance are all factors. For invoicing, we still made sure we had unit tests for all the utility functions, all the tax calculations, all the handling with Stripe, the rounding, making sure the decimals worked, and a double-entry ledger for the accounting so there were no discrepancies. We had a lot of infrastructure to ensure the math was correct. On the product side, because the web is tricky, sometimes those bugs still slip through.

Scaling review from a startup to Linktree

Matt: I appreciate the candidness. Shifting into your current role: you have millions of users, very discerning users who use Linktree as a window to the world for their businesses, whether they are an influencer, a small business, or a big business. When you introduce features now, AI or otherwise, how do you decide what runs autonomously versus what needs review, given Linktree is so much bigger than a startup?

Matthew: There are a lot more processes involved in putting something in front of 100 percent of users, especially on the profile side. At a startup you might just want a five-minute deployment: push to main, get in front of users, bypass everything, because the blast radius is so small you can be aggressive. At Linktree you want feature flags, internal dogfooding, manual QA, unit tests, integration tests, end-to-end tests, human review, a few AI code reviewers in GitHub, and all of your changes validated with Claude Code, Codex, or Cursor. There is a spectrum from push to main and ship it, to make sure it is correct, and there are a lot of additional processes you can put in place.

Matt: Have those processes ever failed? Have you seen things slip through despite all of that?

Matthew: So far, so good. There are always bugs, no matter how much you test. Linktree is impressive in how it handles deployments, with the Buildkite pipelines and a lot of infrastructure and tooling. If you could solve all edge cases, that would be a miracle, but there are a lot of unknown unknowns that only pop up once you meet reality, or an issue only shows up at that scale. I am not sure you can avoid it entirely.

Matt: Do you feel there are more bugs now than before, or about the same?

Matthew: The code quality is improving. There used to be a trade-off between velocity and using AI to just ship. The coding agents are so sophisticated and so impressive that the work is better than it was. With the right context it is borderline incredible in terms of the quality of the output.

Whether AI means fewer engineers

Matt: The natural question people ask is that if you implement agentic platforms, coding or otherwise, you can do more with less. Have you seen the need for fewer engineers as a result of Claude Code, Cursor, or these agentic solutions?

Matthew: Even with a high percentage of code written by AI, it is just leverage. You are able to extend your capacity and your skills, but I do not think there is an upper limit to how much humans want to create or what they need. We just want higher quality, more taste, more craft, more care, more features, more customization. There is still a huge roadmap of things we want to build, and I do not foresee that reducing. It probably changes the landscape for SaaS companies, and there is more abundance of software, but the demand feels almost boundless.

Delivering AI features users actually adopt

Matt: Fair enough. Shifting from building with AI to delivering AI features: what has your experience been of giving AI features to customers, and how have you taken them on that journey?

Matthew: The first version of Fingertip threw you in the deep end: here is a blank page, create. That is very confronting. When we watched users, they would struggle for 30 minutes and then drop off, and what they created was interesting and unique but not to the standard they wanted. Over time we evolved to pre-built templates. When you onboarded, you would say, I am a handyman, and we would look in our database of templates and find the equivalent starter. Then we used AI to rewrite the content and enrich it based on your location, your name, your logo. Doing all of that up front meant that once they got into the website builder they were at an 80 to 90 percent quality website. It was much easier to work from that starting point, where they could look and say, this is wrong, I am going to change it, instead of coming from a blank sheet of paper. There is a lot of paradigm shifting in using AI to reduce the cognitive load and help people meet their needs more easily. Even for content on a Fingertip website, we had a write-with-AI feature sprinkled through the whole application. Any description, any title, they could use ChatGPT to edit their text. That helps people so much, because otherwise the spelling might be wrong, or it would not be verbose enough, or not specific enough. Everyone needs some assistance.

Matt: That is a really interesting example of guiding people through the journey. What I am hearing is that the change management is as important as the technology itself, and the speed at which people move from old tools to new ones is very fast. I have worked in post-sales software for a long time, and the toughest job in software is not selling it, it is adopting it after the fact. Any change is hard, particularly when it is changing every day. You said 80 to 90 percent of the websites were of a quality people felt was in line with their expectations. How do you manage the quality of the outputs, whether now or previously? A lot of people are concerned about quality. We have talked about coding quality, but for AI features I have yet to see a strong methodology that can be rolled out consistently, short of the standard LLM approaches. How do you manage quality and track it at an organization like Linktree or Fingertip?

Measuring quality: evals and the watchman

Matthew: It is a hard problem. There are evals you can do: you can get the AI to evaluate the AI output. But at a certain point, who is watching the watchman? You need humans in the loop, and then the question is how you scale that. Linktree uses a platform called Braintrust for evals, which gives you analytics and dashboards so you get observability on what the AI is coming up with. Another thing is setting the right guardrails. If you leave something too open-ended, or you lean on ChatGPT to make all the decisions when it could have been an if-else statement and very discrete logic, you are opening room for things to go wrong needlessly. In the Fingertip example, we could probably generate the whole page from scratch today without templates, but that opens a can of worms: is it making all the content up, did it fail? Being smart about how you use the technology is always necessary.

Who is asking for AI, engineers or customers

Matt: We are talking about this from the perspective of engineers building with Claude Code and being at the forefront of AI. Sonnet 4.6 came out yesterday, Opus came out the other day, and these frontier models are pushing the boundaries of what you can achieve at a considerably low cost for the output. Customers speak with sales all the time and relay back feedback and product requests. Do you feel it is customers pushing you to develop more AI, or engineers going, I can do this, so I want to introduce it? There is inevitably a tension there. How does that work at Linktree?

Matthew: If I think of a new technology, say agent skills. This has come out and I am using it personally for all of my workflows now. I have skills for auditing the UI, updating the typography, reviewing my pull requests. I have these markdown files with the rules and my standards. That is a technology that came out in the last couple of months, and maybe 1 percent of the world has ever touched it or even heard of it. Things come out that are not evenly distributed. Especially for engineers, we are so close to using AI in our workflows. Engineers are building for engineers, and there is a lot of innovation in this space because the models are so good at writing code. There is stuff that comes out that we as engineers get excited about putting into the product. For the most part it is less bottom up from customers wanting more AI tools. A lot of it is internal ideas, more exposure to the features and the competitor landscape, and thinking of alternative ways to solve a problem. On the flip side, some users say, I do not want AI anywhere in this product, please make sure I can disable it, which is also a valid concern. There is a whole other perspective you need to cater for.

The users who want no AI at all

Matt: Why do they not want AI in the tool? Is it a data concern? I cannot imagine why you would not want AI in it.

Matthew: If I steel-man that position, I could think: I do not want my data leaving your servers and going to a San Francisco company, where I do not know if they are reading it or what they are doing with it. Or maybe I am just happy to write my own content, and with AI it has slurped up the whole internet and generates new text. I can see why you would have issues with that. On the other side, it is a very capable tool, and I have more leverage and more capacity because of it. I have made that conscious trade-off, knowing the downsides.

Matt: I have two points, given that your platform is a front door to the world from people’s social media presence. Not wanting their data to flow to US-based companies is a slight irony from those customers’ perspective. From a production product perspective, it is a big overhead to prevent people from getting access to new functionality that is becoming standard in modern technology. Is there a point where you just give it to everyone and it is their choice whether they use it or not?

Matthew: Having a way to opt out is probably valuable and necessary. On the previous point, you might think the AI is just taking all your data, but there are deliberate privacy policies and restrictions in place, so I want to preface that the data is handled safely. If a user wants to use a product without AI, that is valid, and it is worthwhile supporting them in that choice rather than forcing them in. I think of a piece of software like the Zed code editor. It has a lot of AI functionality, but it respects it if you want to disable all of it. That is a good balance, letting the user opt out if they want.

Matt: I feel like this becomes a question of data sovereignty. If I am thinking of HTML or something basic in your platform, AI is going to become part of that. In the not too distant future you will have a place where you do not have a choice, because it is like building a website: if you accept that it is built on Claude Code or Cursor, you are going to have AI tools within it. Does it not then become a question of data sovereignty rather than whether it uses AI or not?

Matthew: That is probably valid. Apple has clearly been late to the party with AI, but where they are going is building local LLM models that run on your machine. Then you can be confident the data is not going to Cupertino, it is staying local and no one is processing it. Maybe that is the end state: the local models get good enough that you do not necessarily need OpenAI or Gemini.

Matt: I do not think we are at that point yet. That also feels like something an engineer has dreamed up, because I think about my parents and their use of AI. I sent them a video and song from Suno that my CTO had generated for Prefactor. I had not played with Suno before, and it was amazing, and they would have no idea. So the idea of having an LLM on their computer, unless it was embedded into the OS, is a curious concept.

Matthew: Yeah, that will be interesting. Chrome has an LLM, a lightweight version of Gemini, which I have downloaded locally. It is maybe a gigabyte you download, and then it runs locally. I do not think anything actually goes to Google when I ask it. So we are almost there. We will see what Apple comes out with.

Advice for founders building AI-native products

Matt: That will be really interesting. I have a couple of final questions. If I am a founder today building an AI-native product, what is the one mistake you see people making that you would advise them to avoid at all costs?

Matthew: The rate of change right now is spectacular. I am pretty young, but I have never seen any technology shift at this rate. From my perspective, the mistake is putting blockers in front of yourself that slow you down in any way. You need to optimize your workflows and make sure you can iterate quickly, ship quickly, and provide value for your users quickly, because things are changing every day. If you are building a startup, you want clear ownership, you can ship fast, and you can lean into these AI tools. If you are not, you will get left behind.

From proof of concept to production: the Pixar method

Matt: A final question. A lot of people are struggling to move from proof of concept to production, from a nice demo a vendor exposes them to, into real life. The challenge is not watching the demo or buying it, it is going from that demo into production. Do you have tips for organizations thinking about that, and if they have invested in a lot of POCs, anything you would insist on to avoid wasting money on them?

Matthew: I think of the Pixar method. When they make a movie, they spend as much time as they can in the storyboarding phase before they get their thousand animators and sound designers to produce the final thing. I would lean into prototyping and proof of concepts, and throw away things you can iterate on quickly. To make sure that translates into real end-user value, what I have found to work is to isolate the core value in the proof of concept and extract it into a library or a utility that can be used in a production environment. If you build something and it works in a very happy, narrow way, you still want to make sure there is value you can extract and actually put into production. So there is the proof of concept, get it working from top to bottom, and then a second step of pulling out the value into the bare bones. Your prototype can be very green field and innovative and push the needle, but when it goes into production, things slow down and there are more trade-offs. You want that 80/20 principle of what the core value is. Reach out to me on LinkedIn, search Matthew Blode, b-l-o-d-e, and send me a message. I am always available to chat or jump on a call and connect. Thank you so much, Matt. Great questions, you really got me thinking.

Matt: Thank you, Matthew. That was a great conversation. We have been Agents After Dark. Thanks very much, and speak again soon.