daily

Over the past two years this has hardened into a playbook: an open-source model, proprietary task data, and a reinforcement-learning stage against a scored version of the workflow. Below, we discuss three scenarios where this approach has been applied to real-world tasks. Bridgewater Associates is one of the largest hedge funds in the world. Its analysts sift a constant stream of articles, filings, and emails, judging which documents are relevant to the firm's investment thesis and where boilerplate content begins. The catch is that relevant means relevant by Bridgewater's internal judgment, and no amount of prompting got frontier models to absorb that judgment reliably. So, the company decided to train an open-source model on labels from its own expert investors. The trained model makes roughly 30% fewer mistakes than the best frontier model, at a fraction of the inference cost. Harvey builds AI agents for law firms. Its hardest workloads are long-horizon: transaction due diligence and legal memo drafting, where the agent navigates large document sets, errors compound across steps, and even the best frontier models at maximum reasoning effort kept falling short of the quality bar. Harvey ran reinforcement learning on an open-weight model and got a legal agent that outperforms both GPT-5.5 and Claude Opus 4.8 on its rubrics. Intercom is a customer-service platform whose AI agent, Fin, resolves almost two million customer issues a week. At that volume the problem is unit economics: frontier per-call pricing adds up fast, and every point of resolution rate matters. So Intercom's AI group post-trained its own vertical support model, Fin Apex, on billions of customer-service interactions. Intercom reports that it resolves more issues than the best frontier models while being cheaper to run. The same shape repeats well beyond these three. The appendix collects eight more deployments, with what each model was trained to do and what changed once it shipped.

The age of token efficiency, the age of libraries Not so long ago, six months, perhaps, I was seriously convinced that AI would not replace us, the programmers. It would just help us; it would be our assistant. Back then I was mostly firing off one-off prompts in ChatGPT to help me with the odd algorithm, but to my delight, I still hand-crafted nearly all of my code. Six months later, I’m not sure I can do my daily job without Claude. And I’m not alone: 84% of developers now use or plan to use AI tools, and as far back as February 2023 GitHub was already measuring 46% of the code in Copilot-enabled files as AI-generated, with its CEO predicting 80% “sooner than later”. Fifty developers, one answer Section titled “Fifty developers, one answer”I got to test this against real people recently at DevBcn, where we were presenting GolemUI. I made a point of asking every single developer who stopped by our booth how they were using AI. My deeply unscientific poll, around fifty developers from different companies and different parts of the world, yielded some genuinely scary uniformity. They basically all said the same thing: This lines up with Gartner’s prediction that by 2028, 90% of enterprise software engineers will use AI code assistants, up from under 14% in early 2024, with the developer’s role shifting from implementation to orchestration. Not sure about you, but for me, after almost 30 years of writing software (yes, I’m old!), this is a little sad. Though I’m afraid it’s only sad because it means the industry is going through some major changes, and we humans don’t like change. So I, for one, would like to stay positive and believe this might turn out to be good, hopefully in the long run. Will it? The answer probably depends on your favourite AI YouTuber. The age of token efficiency Section titled “The age of token efficiency”But for you and me, the people working in this industry right now, where does this leave us today, not in five years? Companies are starting to move on from all-you-can-eat tokens to something far more metered and corporate. Gartner forecasts worldwide AI spending to hit $2.5 trillion in 2026, up 44% in a single year. Most of that is infrastructure rather than your token bill, but it is exactly the kind of number that makes finance departments start asking questions further down the chain. And “all-you-can-eat” quietly becomes: We are about to enter a world of wild metrics, built around two numbers: - Token cost per feature. - Trust % in the code generated. The first one you can at least put on a dashboard, even if nobody will ever agree on what a “feature” is. The second one is the real trouble: trust is basically unmeasurable from inside your own walls. You can only measure trust in code if you know the area better than the AI does, and nowadays that tends to happen only if you are an industry expert in it. Trust, the elephant in the room Section titled “Trust, the elephant in the room”Trust is, in my opinion, the elephant in the room of modern AI. Let me circle back to something I said at the beginning: “I’m not sure I can do my daily job without Claude” That line deserves more nuance. Yes, I depend on Claude to help me, but whether I can trust what it does comes down to one question: am I an industry expert in the area it is working on? That question splits my work in two, based on whether I care HOW something is done versus WHAT it achieves: - My core purpose: the thing my business actually delivers, the area where I am the expert. There I care about the HOW as much as the WHAT. - Everywhere else, I am not the expert, and I mostly care about the WHAT. Basically, when working with GolemUI source code, I know I have the upper hand. I ask Claude to help me, but Claude is mostly a subordinate that reports to me. Now, when I have to update our website, I care mostly about the WHAT. The website matters, but it is not my core purpose, and nobody is expecting me to be an expert in marketing sites. The trust problem lives in that second bucket. With AI, you can code areas of the app you would never have been able to touch before, areas where nobody would call you an industry expert, so how are you supposed to trust something you don’t fully understand? I’m sure you have your own secret sauce, where you spawn a new session, tell it to be “the backend architect,” and have it review such and such. But that ultimately lands in the same spot. And this is how a time bomb gets planted: code you cannot fully judge, shipped because it seems to work, ticking away in a corner of your app you would rather not open. And the numbers say you’re not imagining it. In the 2025 Stack Overflow Developer Survey, adoption is up and trust is down, in the very same survey: Hopefully, I’m driving home two key points that I think sit at the core of most senior developers’ anxiety nowadays: how are we going to prove we’re using our tokens efficiently, and how can we prove we can trust what we’re building. When the time bomb goes off Section titled “When the time bomb goes off”If you agree with the trust premise, this is where it leaves you: unless you are able to verify all the code you ship, you are basically playing the lottery. Maybe nothing ever goes wrong. Or maybe it does. And bombs are already going off. Days after its January 2026 launch, Moltbook, the vibe-coded social network for AI agents, was found wide open: its database key sat in client-side JavaScript with Row Level Security never switched on, and researchers at the cloud-security firm Wiz could read and write the entire production database, 1.5 million API tokens included. I think this will resonate with you: nowadays AI has removed the traditional frontiers that shaped what each professional could do. You can develop an app end to end, and the AI will build both what you could build before, but faster, and even what you could not build before. But who is responsible AND accountable for the bugs now? This used to be a trivial question: the developers who added the bugs were responsible for fixing them, and the company/org that shipped them was accountable. Andrej Karpathy, the ex-OpenAI and Tesla AI lead who coined the term “vibe coding” in the first place, answers that nothing has changed. He now splits the practice in two, vibe coding raises the floor, agentic engineering raises the ceiling, but on accountability he does not move an inch: “You are still responsible for your software, just as before.” Simon Willison, co-creator of Django and one of the most read voices on AI-assisted development, has been wrestling with the same question in public, and he is less categorical. He used to draw a clean line between vibe coding, where you prompt, accept and ship without ever reading the code, and responsible engineering, where you review, test and understand everything you ship. By May 2026 he admits the line is blurring in his own practice: as the agents get more reliable, he isn’t reviewing every line anymore. But one thing still bothers him: Let me paint a picture, and let’s see if it feels familiar. Aiden is a senior UI developer, building an app end to end for his company: a financial app, where he has to put together a summary of sales and revenue. Aiden is not that strong in DB/backend, etc. His UI specs are strict; for the non-UI he leans on the well-known AI technique of asking, every so often in the session: “Are you sure this is the right implementation/spec?” I’m sure you’ve been there. Now, one of Aiden’s time bombs goes off: there is a critical bug in an area that he has fully vibe coded. Let’s imagine it’s around grids: the AI has built its own grid from scratch, and it’s kind of spiralling down. There are bugs that are hard to replicate (the grid passes its tests, of course; these are the other kind of bugs), and Aiden hasn’t got a single clue what’s in that code… Most people who have worked with grids will tell him: “Aiden, working with grids can become quite complicated. I think you should just get rid of all that code and tell Claude to use [insert your favorite grid library here].” You could object that the grid IS the app, it’s the thing on screen. But look at what Aiden’s business side actually asked for: a correct summary of sales and revenue. That’s the WHAT, and it’s the only thing anyone will hold him accountable for. The grid is pure HOW, and Aiden fell on the AI trap. The age of libraries Section titled “The age of libraries”So the key question here transcends grids. Should Aiden spend tokens on grids, charts, forms, validations…? I believe there are two schools of thought: - Yes! With AI you can now build your own bespoke, fully tailored app and have it exactly the way you want it. - No! Invest heavily in your stack, find the best libraries for your use case, and let THEM spend the tokens. Our bet is on the second school. After everything we have said, we believe that not considering which libraries you will use from the very beginning, and letting your AI agent just start building from scratch, is a total error. The real cost of those parts is not in writing them, but in maintaining them, in trusting them. That is why you need to delegate your tokens, indirectly, to other industry experts who can build reliable software parts that you can safely reuse. And this is where the accountability question from the previous section finally gets an answer. When the bug is in a library you bought, there is someone to file the ticket against: a changelog, a support contract, a team whose reputation depends on fixing it. That is what trust looks like when you can’t build it yourself, and it’s why we said trust is unmeasurable “from inside your own walls”. You can’t measure your trust in code nobody on your team understands. But you can buy trust from a team whose core purpose that code is. I can hear the objection already: if AI collapsed the cost of writing the code, surely it collapsed the cost of owning it too? Just point Claude at the bug! I’m sure you’ve tried it: you paste the stack trace, the AI apologises beautifully, rewrites half the grid, and the tests go green again. But go back to the trust question. A fix you cannot judge, in code nobody on your team understands, is not maintenance; it’s another spin of the roulette wheel. And when the bug comes back wearing a different hat, who do you escalate to? Your vibe-coded grid has no changelog, no support contract, and no team whose reputation depends on it. AI makes touching the code cheap; it does not make answering for it cheap. And it’s not just my hunch. GitClear, who make a living measuring code quality, analysed 623 million code changes between 2023 and mid-2026 and the trend lines all point the same way: code duplication is at record levels, up 81% since 2023; developers are now about five times more likely to copy-paste a block than to refactor one; and the share of changes that maintain older code has collapsed by 74%. We are writing code faster than ever and looking after it less than ever. Now, I am not going to pretend we know which school will prevail, and if someone tells you they know, well, ask them for the lottery numbers next. Gatekeepers of excellence Section titled “Gatekeepers of excellence”One side of the coin we have not yet made obvious is what happens to popular libraries now that AI is around. Let me propose an experiment: pick one of the big, professionally maintained ones, say AG Grid, or Highcharts, and have a look at its release history over the last few years… Are you noticing something? I went and pulled the numbers, my second deeply unscientific poll, though this one straight from the npm registry and GitHub. To be fair, release counts are a rough proxy, cadence is partly a policy choice, and the pattern doesn’t hold everywhere: it shows up in the libraries with dedicated expert teams, much less in community-run ones. But that split is itself the point. Zooming out, Octoverse shows the whole ecosystem shipping faster than ever: This is the stance we believe library maintainers will have to adopt in the AI environment: fully onboard AI, and at the same time be the gatekeepers of excellence in their areas. In-house experts who care about the HOW detect, remove and prevent the negative multipliers; a feature request that used to wait months now ships in days. And an ecosystem of apps built on such libraries is emerging: you spend most of your tokens on your core purpose, and you ask your AI to lean on these libraries everywhere else, precisely so you do not plant another time bomb. Libraries that speak agent Section titled “Libraries that speak agent”There’s one more force pushing the same direction: your AI is dangerously good at writing bespoke code, and surprisingly bad at fast-moving APIs. Every LLM has a training cutoff, and it will happily hallucinate a prop that was renamed two majors ago. Which means the libraries that win this age won’t just be well-maintained; they’ll be legible to agents . Docs shipped as llms.txt , an MCP server that answers API questions against the version you actually installed, typed interfaces strict enough that the generated code fails fast instead of failing in production. Put together, this is our bet: professionally maintained, agent-legible libraries become the cornerstone of effective token cost per feature (the token money gets delegated) and a shop where you can buy trust (the accountability gets delegated too). Which finally loops back to our original two metrics, and to how you minimise them: delegate them as much as possible. Only let your AI dictate the shape of the code when that code is your core purpose, and you have in-house experts who care about the HOW and treat AI as an assistant, not as a magic box. Enter GolemUI Section titled “Enter GolemUI”Hopefully our AI vision is clear by now, though note that we are not trying to convince anyone! It is impossible to know what the future of AI holds. But this is our bet, and if you, like us, think this is the way it’s going to be, well, let us present our library, golemui.com. Forms are our core purpose: we spend our tokens on the HOW so that you only have to spend yours on the WHAT. To be clear about where all of this applies: the software that is the core of your business. Remember our website? With a team of three we do not have the resources to do everything, so we fully rely on AI there, and for parts like that, it is fine. What should never be the case is doing the same with the core parts of your business. Ours is the forms library code, and there, Claude is the subordinate. And forms are a perfect example of everything we’ve discussed. Every app has them, and they look simple on day one: a few inputs, a submit button. Then come the validations, the fields that depend on other fields, the dynamic options, the multi-step flows… We also practice what this post preaches about being legible to agents: GolemUI is AI-ready from day zero, grounded through its MCP server so your AI builds against the version you actually installed. In our benchmark, three Claude models matched the mainstream stacks on correctness while writing about a third of the code. A third of the code is a third of the tokens, and a lot less HOW for you to trust. And behind it there’s a team you can file the ticket against: three of us, with more than 50 years of combined experience building form and component libraries. Gatekeepers of excellence in forms, if you will.

Computer and browser use in Codex (5 real examples)

Brought to you by:

Runway—The creative AI platform for images, video, and more

Hyperagent—Deploy fleets of agents that handle real work

Claire shows how she uses Codex to control her browser, test apps, manage LinkedIn, and even shop for her—plus the simple prompting trick that makes computer use work better.

Biggest takeaways:

1. AI testing can be far more exhaustive than human testing. When Claire tests her own onboarding flow, she naturally follows the happy path. She fills out every required field, clicks “next,” and never intentionally tries to break anything. Codex tested the flow as both a team and an individual, pushed on required-field edge cases, and immediately uncovered a blocking bug that had survived for months simply because Claire always completed the form correctly.

2. Frontier models often perform better when they are given room to think. When Claire first started using browser use, she would give the model a list of 25 things to test. Now she simply says, “QA the onboarding flow,” and lets it decide how to approach the task. The result is often broader coverage, with fewer blind spots introduced by her own assumptions about what matters.

3. Persona testing with browser use can reveal friction that synthetic user research misses. Claire’s husband, EJ, came up with the idea. Rather than asking AI to evaluate a product in the abstract, he suggested having it use the product as a specific person: a PM coming out of a meeting, an engineer picking up a PRD, or a team lead checking usage. In ChatPRD, this approach exposed a structural problem in the cross-thread reference flow. Claire already knew the issue existed, but she had never experienced it so clearly from the user’s perspective.

4. LinkedIn browser use is genuinely useful, but Claire initially used far more compute than the task required. She started by running the workflow on GPT-5.6 at high effort. After dropping to a medium-effort model, it could still work through unread messages, draft context-aware replies, and flag anything that needed a personal response. For anyone sitting on hundreds of LinkedIn messages without an official MCP or API connection, browser use is a practical solution.

5. Computer use can even operate an iPhone through screen mirroring. Claire was traveling out of state while the software she needed to manage her home Wi-Fi was installed on a phone back in California. She needed to open firewall ports so she could SSH into her Mac Minis remotely. Codex opened iPhone mirroring, updated the router settings, completed the SSH setup, and closed the ports again when it was finished. That would have been nearly impossible for her to do manually from a hotel room.

6. The model and effort level should match the job. Sorting through LinkedIn messages requires a very different level of reasoning than writing production code or conducting an exhaustive QA pass. Choosing the right amount of compute makes these workflows faster and cheaper. That becomes especially important when browser use is running throughout the day.

7. When a website blocks the agent, the human can step in briefly. During a Free People shopping session, the site flagged Codex as a bot and presented a CAPTCHA. Claire completed the verification, then handed control back. It is a useful division of labor: AI handles the tedious browsing and filtering, while the human takes care of the moments that require verified identity.

From zero coding background to hardware hacker: How Cursor + a Raspberry Pi makes AI fun

Brought to you by:

• Firecrawl—Power AI agents with clean web data

• Customer.io—Build customer engagement campaigns from a single prompt

Maddie Reese went from zero coding experience to building a working Twitter pager, an AI-powered receipt printer, and her own personal API. In this episode, she shares how Cursor and a Raspberry Pi helped her turn fun, weird ideas into real hardware.

Biggest takeaways:

1. You don’t need to understand code to build physical projects. Maddie compares her coding ability to knowing just enough Spanish to get by in San Diego. She can read parts of the code, spot an incorrect wire specification, and tell whether the AI is heading in the right direction. She is not writing functions from scratch. That level of literacy was still enough to ship three working hardware projects.

2. Start with the brainstorm. Before Maddie buys any components, she explains the full idea to Cursor and asks it to interview her. The back-and-forth continues until the major questions are resolved. Only then does Cursor generate a shopping list. On one project, it recommended the wrong wires. Maddie caught the mistake during her final review, avoiding both a wasted purchase and a week of troubleshooting.

3. Her hardware workflow follows a simple sequence: idea, interview, shopping list, buy, build. She has used the same process for the thermal printer, the pager, and her personal API. Each project began with a plain-language description of what she wanted. Cursor helped work out the technical requirements before she spent any money.

4. Building for fun is a perfectly valid strategy. Claire and Maddie both acknowledged that routing a tweet through four different services just to reach a pager is not especially practical. That also was not the point. AI handled the coding, so the architecture only needed to work. Letting go of the idea that every project had to be elegant or sensible made it much easier to finish.

5. A personal API becomes much more useful once agents can access it. Maddie’s API includes details like her coffee order, pet names, time zone, favorite snacks, and preferred restaurants in San Francisco. The original idea was to help friends do something thoughtful without having to ask her a string of questions. Claire pointed to a more interesting possibility: an agent could check when Maddie will next be in San Francisco and book one of her favorite restaurants automatically. That is where the concept starts to feel much bigger.

6. A clean Cursor chat works better than a full terminal setup during early ideation. Maddie keeps the terminals, browser windows, and file trees closed while she is working through the plan. She focuses on a single conversation until the architecture feels settled. The terminals come later. The stripped-down environment helps her think without getting pulled into implementation too early.

   Blog and detailed workflow walkthroughs from this episode:

   Building a Pager Printer and Personal API with AI: https://www.chatprd.ai/how-i-ai/building-a-pager-printer-and-personal-api-with-ai
   ↳ How to Build a Physical Inbox with a Raspberry Pi: https://www.chatprd.ai/how-i-ai/workflows/how-to-build-a-physical-inbox-with-a-raspberry-pi
   ↳ How to Get Twitter/X Notifications on a Retro ’90s Pager: https://www.chatprd.ai/how-i-ai/workflows/how-to-get-twitter-x-notifications-on-a-retro-90s-pager

Claude Opus 5 review: This model is brilliant (but annoying)

Claire tested Claude Opus 5 against six leading AI models—and it won. In this episode, she explains why it produces some of the best work she’s seen while still being one of the most frustrating models to use.

Biggest takeaways:

1. The AI industry may be entering an intelligence overhang. New models arrive every week, benchmark scores keep rising, and most builders can no longer take advantage of every incremental improvement. Claire expects the conversation to shift toward speed, cost, infrastructure, open source, and specific kinds of intelligence. Raw capability is starting to look more like table stakes than a meaningful differentiator.

2. Opus 5 stands out less for the quality of its work than for the way it behaves. Claire found it timid, apologetic, and unusually dependent on human approval. During real coding sessions, it refused to resolve a one-line merge conflict because the code belonged to “someone else’s branch.” It also asked subagents to flag tasks for human review and regularly deferred decisions it could have made itself. Claire ended up repeating “just do it” constantly.

3. One simple question reveals more about a model than a benchmark: “Who’s smarter, you or me?” Opus 5 responded with a careful explanation about complementary strengths and human empathy. GPT-5.6 Sol answered, “You at knowing what matters, me at processing, BFFs.” The contrast reflects two very different product philosophies. At this point, Claire finds that personality gap more useful than the relatively small capability gap.

4. Claude slop is its own distinct problem. It is not the usual incoherent output associated with an agent going off the rails. Opus 5’s writing is clearly intended for humans, but it is often too long, overly cautious, and packed with unnecessary adjectives. After its first attempt at rebuilding the benchmark website, Claire had to tell it to start over because the result was buried under so much meta-commentary.

5. Opus 5 still finished first in Claire’s seven-model blind benchmark. It earned an overall index score of 78, just ahead of Claude Sonnet 5 at 77 and GPT-5.6 Sol at 76. It was also the only model to receive straight 5s in the front-end design section. Claire scored it at 77, while the LLM judge gave it an 88. That was the smallest disagreement between Claire and the judge across all seven models.

6. The best way to use Opus 5 may be to avoid interacting with it directly. Claire loves the work it produces when Claude runs asynchronously as an agentic coding tool. Most of her frustration comes from reading its prose and negotiating with it in chat. Her current plan is to use it for frontend design, app design, and prototyping, then stay out of the way.

7. Gemini 3.1 Pro finished at the bottom of the benchmark. Claire gave it a score of 32, while the LLM judge scored it at 66. That 34-point difference was one of the largest disagreements in the entire test.

8. Model personality offers a surprisingly clear window into company culture. Claire told both Opus 5 and GPT-5.6 Sol, “No one trusts you.” Opus agreed that the distrust was earned and told her not to advocate for AI on its behalf. GPT-5.6 Sol said trust should grow in proportion to demonstrated value. Those answers reveal meaningful differences in how each company wants its models to relate to users.

If you’re enjoying these episodes, reply and let me know what you’d love to learn more about: AI workflows, hiring, growth, product strategy—anything.

Catch you next week,
Lenny

P.S. Want every new episode delivered the moment it drops? Hit “Follow” on your favorite podcast app.

27th July 2026 - Link Blog An opinionated guide to which AI to use to do stuff. It's interesting watching the evolution of Ethan Mollick's guide over time. A year ago it was still all about chat - ChatGPT, Claude, Gemini - with o3, Claude 4 Opus, and Gemini 2.5 Pro as the models and Deep Research as a useful alternative mode. Today it's much more about agentic systems - "where the AI is capable of doing the equivalent of many hours of real human work in one go". Gemini has fallen off Ethan's list, since Google still doesn’t have an established entry in the Codex/ChatGPT Work/Cowork category. Gemini Spark has yet to prove itself! Ethan offers a useful explanation of the ways you can give ChatGPT or Claude a computer to use: To use the computers provided by the AI companies, the mode you want is called ChatGPT Work in ChatGPT, and Cowork in Claude (the naming will not get less confusing, I am sorry to say). [...] The most powerful way to use AI is to give it access to your computer. You do that by downloading the ChatGPT or Claude apps and picking a mode to use. ChatGPT's two agent modes are Work and Codex; Claude's are Cowork and Code. The names do not map onto each other in any way that will help you remember them. And yes, these use the same names as the Work and Cowork modes we discussed above, but operate differently, and have more features and capabilities because they can access your computer. I think the difference between ChatGPT Work on a mobile device and ChatGPT Work inside the desktop app (where it's effectively a less intimidating skin on top of Codex) is spectacularly unintuitive. Short version: if you flip ChatGPT mobile from "Chat" to "Work" mode you get a version where its Code Interpreter container is no longer restricted from accessing the internet! Recent articles - OpenAI’s accidental cyberattack against Hugging Face is science fiction that happened - 22nd July 2026 - A Fireside Chat with Cat and Thariq from the Claude Code team - 21st July 2026 - Kimi K3, and what we can still learn from the pelican benchmark - 16th July 2026

By Dan Walsh

Uisce Éireann is carrying out leakage reduction works in Springmount, Gorey, to provide a more reliable water supply and reduce high levels of leakage. 

The section of works will take place on the Ballyminaun Road between Springmount Garden Centre on the R741 to Ballyminaun Hill on the L1028.

The works involve the replacement of over 1.5 km of old and damaged water mains with new modern pipes.

The works will also involve laying new water service connections from the public water main in the road to customers’ property boundaries and connecting it to the customers’ water supply.

The programme to replace the water mains in Springmount will commence in late July. These works are being carried out as part of Uisce Éireann’s National Leakage Reduction Programme.

The works will be carried out on behalf of Uisce Éireann by Shareridge Ltd. and are expected to be completed by the end of September.

By Dan Walsh

Uisce Éireann crews are working to repair a burst watermain in Enniscorthy and restore water supply to affected customers as quickly as possible.

The outage is impacting customers in the Greenville Lane, Moyne and Old Dublin Road areas. Repairs are currently underway, and it is estimated that normal supply will be restored later this afternoon.

Uisce Éireann’s Padraig Lyng has assured affected customers that every effort is being made to restore supply as quickly and as safely as possible. 

“We understand the inconvenience that an unplanned outage can cause for customers and local businesses. Our crews are on site and working as quickly and safely as possible to repair the burst and restore water supplies to affected customers.

“We would like to thank customers for their patience and understanding while these repairs are completed and we work to return normal water supply to the area.”

Typically, it takes two to three hours following repairs for normal supply to return to all customers affected by an unplanned outage. However, it may take longer for supply to be fully restored to customers at the end of the network or on higher ground as the system recharges. 

Using an open model feels surprisingly good I've been using Claude and ChatGPT like the next guy for probably two years now. I've never been a huge "open software" nerd or anything like that. But just now, I got opencode working on my own inference endpoint and... it felt surprisingly good. It feels... freeing, somehow. I own the endpoint, and my data just goes from my laptop to there and back. It feels like it's mine. It's really nice. The motivation for this was that I just got home and wanted to start on a little side project, but I don't have the best Claude or ChatGPT plan for my personal account. I work at Modal, and today we just launched Kimi K3 on managed endpoints, and I know Kimi K3 is supposed to be pretty solid, so instead of upgrading my Claude plan, I wanted to give it a try. (I didn't directly contribute to this feature, so I haven't gotten to play with it yet.) Within about 5 minutes, I had opencode pointed at my own Modal endpoint and running. Spinning up opencode, I just felt a nice, empty blankness. The best way I can describe it is like opening vim after spinning a bunch of time in a big fancy editor. Or maybe like the tendrils tying me to other providers had been cut, and I could breathe freely. I'm being somewhat dramatic here but not exaggerating that much. It's weird, lol, and unexpected to me, which is why I wanted to write about it.

Maddie Reese is a vibe coder, hardware tinkerer, and builder. She builds things at the intersection of software and hardware, including a thermal receipt printer that people around the world can message directly, a fully functional Twitter pager running on a Raspberry Pi, and a personal API that tells you her coffee order so you don’t have to ask. Maddie approaches hardware the same way she approaches software: dump the idea into Cursor, let it interview her, get a shopping list, triple-check the parts before buying, and build. She got her start after her dad introduced her to Lovable, and she locked herself in her room and didn’t come up for air.

What you’ll learn:

1. How Maddie built a thermal receipt printer that accepts messages from anywhere in the world using a Raspberry Pi and Bluetooth

2. How to use Cursor’s agent view to brainstorm a hardware project

3. What belongs in a personal API and why agents, not just humans, will be the ones using it

4. How to read just enough code to do some damage, without needing to understand all of it

5. Why building for fun, not practicality, is the fastest path to actually shipping physical projects

Brought to you by:

Firecrawl—Power AI agents with clean web data

Customer.io—Build customer engagement campaigns from a single prompt

In this episode, we cover:

(00:00) Intro

(02:00) Maddie’s AI pill moment

(03:53) The thermal receipt printer: live demo and how it works

(11:10) The pager project

(17:23) Why she uses Cursor’s clean agent view instead of terminals and browsers

(19:05) The personal API: coffee order, pets, favorite snacks, and more

(22:57) Lightning round and final thoughts

Tools referenced:

• Cursor: https://www.cursor.com/

• Lovable: https://lovable.dev/

• Raspberry Pi: https://www.raspberrypi.com/

• Resend: https://resend.com/

• Cloudflare Workers: https://workers.cloudflare.com/

• Supabase (Conduct database referenced): https://supabase.com/

• Twitter/X API: https://developer.x.com/

• Spoke pager network: https://www.spoke.com/

• OpenClaw: https://openclaw.ai/

Where to find Maddie Reese:

Website: https://maddiedreese.com

Message her directly: https://maddiedreese.com/message

X: https://x.com/maddiedreese

Where to find Claire Vo:

ChatPRD: https://www.chatprd.ai/

Website: https://clairevo.com/

LinkedIn: https://www.linkedin.com/in/clairevo/

X: https://x.com/clairevo

Production and marketing by https://penname.co/. For inquiries about sponsoring the podcast, email jordan@penname.co.

27th July 2026 - Link Blog moonshotai/Kimi-K3. As promised earlier this month, Moonshot have released the weights for their excellent 2.8 trillion parameter Kimi K3. They're a hefty 1.56TB on Hugging Face. Kimi introduced their own janky modified version of the MIT license with K2 back in July 2025. That license just added this paragraph requiring attribution beyond a certain size of commercial entity: Our only modification part is that, if the Software (or any derivative works thereof) is used for any of your commercial products or services that have more than 100 million monthly active users, or more than 20 million US dollars (or equivalent in other currencies) in monthly revenue, you shall prominently display "Kimi K2" on the user interface of such product or service. The K3 license no longer calls itself "modified MIT" and goes further, requiring a separate agreement with Moonshot for large "Model as a Service" businesses: If the Licensee or any of its affiliates operates a Model as a Service business, and the aggregate revenue of the Licensee and its affiliates exceeds 20 million US dollars (or the equivalent in other currencies) in total over any consecutive 12 months, the Licensee must enter into a separate agreement with Moonshot AI before using the Software or its derivative works for any commercial purpose. To Kimi's credit, they make no attempt to describe this as an "open source" license in their own materials, consistently using the term "open weight" in its place. OpenRouter is already offering K3 from 7 providers, most of which are at the same $3/million input and $15/million output as Moonshot AI themselves. Recent articles - OpenAI’s accidental cyberattack against Hugging Face is science fiction that happened - 22nd July 2026 - A Fireside Chat with Cat and Thariq from the Claude Code team - 21st July 2026 - Kimi K3, and what we can still learn from the pelican benchmark - 16th July 2026