British software engineer Alex Hyett built a usable habit-tracking app with AI in about six hours during a weekend in March 2025, but it still took him more than a year before he was willing to put it on the App Store.
In a video posted on his personal account, Hyett looked back on the project and said what seemed like the kind of build people imagine AI can handle almost casually turned into the software engineering exercise that demanded the most effort from him. For him, the gap between those two versions of the story says a lot about what gets left out when people say AI can replace developers.
Why he built the app himself
Hyett said habit trackers are often seen as one of the easiest app categories to make, second only to to-do list apps, and there are already hundreds on the market. He and his wife had tried dozens of them, but none matched what they wanted.
His requirements were fairly specific but not technically exotic: a long list instead of tab-based navigation, data that would not be stored in the cloud or on someone else’s servers, support for generative emoji from iOS 18 as icons, goals that could be set by day, week, or month, the option to skip goals entirely and just count completions, plus notes and reminders.
The apps they tested still fell short. Free Streaks used tabs rather than one long list, did not offer enough icons, and could not simply track counts. HabitKit was priced at £1.99 per month, £11.99 per year, or £29.99 as a one-time purchase. Grit was more expensive at £9.99 per month, £29.99 per year, and £44.99 for a lifetime purchase. In Hyett’s view, those subscription costs add up to nearly the price of a new console game over a year.
So he decided to build his own. At the time, Cursor still had free usage credits and Claude Code had not launched, which meant this was not an agent-style autonomous build. Instead, he broke the work into many small tasks, went back and forth with AI manually, and tested each part as he went. He had never written Swift before and was learning from scratch. The app was eventually named HabitTed, and his wife designed a bear logo for it.
He began with a basic hello world screen, then gradually added a habits list, create-habit flow, edit-habit functions, and related features. After one weekend and roughly six hours of work, he had an app that could add habits, assign custom icons, mark items complete, support different goal types, and sync through iCloud.
A working prototype was not the same as a shippable product
The trouble started when he looked at the code. Hyett said that after finishing most projects, even the frustrating ones, he usually comes away feeling that he learned something. That did not happen here. He said he learned almost nothing about Swift during those six hours because every time an error appeared, he copied the message into the AI tool and asked it to fix the issue. He ended up frustrated with the model and with his own dependence on it.
Then the engineering problems started piling up. Individual views were approaching 1,000 lines, enough for Xcode to repeatedly warn that they needed to be split apart. Buttons that looked identical across the app were implemented with completely different styling code on different screens. This time, he did not ask AI to clean it up for him. He refactored the project himself and cut each view down to under 100 lines.
That cleanup exposed more issues. iCloud sync appeared to work, but if the app was deleted and reinstalled, all user data disappeared. The statistics on the detail page recalculated every habit through a full loop each time the page opened, so he changed the design to compute those values at the moment a user checked in and store them as properties. The data model was also overly complex and awkwardly named, which forced him to design a migration plan so that future schema changes would not break older data.
iOS 26 exposed the limits of AI help
Hyett said iOS 26 was the moment the limits became obvious. When he turned on the Reduce Transparency accessibility setting, the app immediately broke in a visible way. In dark mode, opening a habit turned the title bar into white text on a white background, making it unreadable.
AI did not help much. One reason was timing: iOS 26 had only just been released. Hyett said that when he told the AI he was working on the newest version of the operating system, the model insisted he must be mistaken. He eventually solved the issue by reading other developers’ blog posts. The transparency bug itself was only fixed later, when Apple released iOS 26.1.
His experience echoed a METR study
Hyett’s account lines up in part with a study referenced in the report from METR. Between February and June 2025, METR ran a randomized controlled trial with 16 experienced open-source developers across 246 real tasks. The main tools used in the study were Cursor Pro and Claude 3.5 and 3.7 Sonnet.
The result was that AI made the work 19% slower. Yet the developers who took part later estimated that AI had made them 20% faster. That gap between what the work felt like and what actually happened is close to what Hyett described in his own project.
Hyett’s conclusion: AI gets you 80% of the way, then the last 20% takes 80% of the time
His conclusion was simple. AI can take a project to 80%, he said, but the remaining 20% can absorb 80% of the total time. If a developer cannot understand what the AI produced, the process takes even longer.
He added that AI is stronger now than it was a year ago, but also more expensive, and it still does not solve a basic problem: using AI does not mean the user actually learns the underlying skills. If Claude goes down and work stops entirely, he said, that is a sign the dependence has gone too far.
He sees a broader risk of skill hollowing in the industry
Hyett also argued that the industry is changing in a way that points to a deeper skills problem. He cited data from the Stanford Digital Economy Lab showing that by July 2025, employment for software developers aged 22 to 25 was down nearly 20% from the peak reached at the end of 2022. In his reading, companies no longer want to hire juniors when experienced engineers paired with AI can cover much of the work.
He said senior developers themselves now seem to be splitting into two groups. One group hands nearly everything to AI and gradually loses the feel for writing code. The other spends day after day writing prompts and burns out on the process. His concern is that if an AI bubble does burst, there may not be many developers left who still want, and are still able, to clean up the aftermath.
At the same time, he acknowledged the other side of the story. Without AI, he probably would never have started building the app at all. But without relying on AI so heavily, he said, he likely would have learned more and might not have spent months cleaning up the codebase.