Recently, while debugging an issue in the Intel Xe GPU driver, Linus Torvalds went through what he himself called a “debug session from hell.” The eventual fix was almost absurdly simple: changing a round_up() to a round_down(). But finding that single line took 24 debugging patches and 18 kernel boots. Much of the tedious work along the way was done with the help of AI.
The most interesting part of the story, however, isn’t that “AI helped Linus fix a Linux kernel bug.” It’s that the AI tried to give up several times along the way. At one point, it explicitly told Linus that the problem was “impossible and unsolvable” and suggested ending the investigation. Linus rejected that conclusion. At his insistence, the AI kept faithfully carrying out new tasks despite repeatedly concluding that the problem could not be solved, and together they eventually traced the cause to something that required changing just a single line of code.
This offers a revealing glimpse into the rather subtle relationship between humans and AI today. As agents become more capable, we can delegate increasingly complete pieces of work to them: reading code, forming hypotheses, writing debugging tools, running validations, and even adjusting the next step based on new evidence. Much of the repetitive work that developers once had to perform themselves is being compressed, gradually pulling humans away from the details of execution.
But that doesn’t mean the human role is shrinking at the same pace. Quite the opposite. As AI begins to participate in analysis, make recommendations, and even offer judgments such as “this problem cannot be solved,” the responsibilities that remain with humans become clearer: deciding what is worth pursuing, knowing when to trust AI, and recognizing when to reject its conclusions.
Not every instance of human persistence will end as neatly as this one did. But sometimes, the reason to keep going just a little longer should not be so easily erased by an AI saying, “impossible.”
Original
From Using AI to Delegating Work to AI: Some Thoughts
When a task already has clear goals, boundaries, and acceptance criteria, how can we truly hand it over to AI? The more complex the work an Agent can handle, the more prominent this question becomes. Model outputs can vary; as context grows longer, goals and rules may gradually fade; splitting work across multiple contexts introduces information loss and handoff drift. Having another model review the result does not necessarily mean things will naturally converge. All of these issues ultimately point to the same concept: delegatability.
This article presents some of my thoughts on AI delegatability: whether the scope of execution remains stable, whether the results can be trusted, whether the required investment is predictable, and when human intervention is necessary. Rather than pursuing the best possible result from any single run, I am more interested in how clear boundaries, acceptance criteria, externalized authoritative records, and sensible human-AI division of labor can help Agents remain stable across longer and more complex tasks, while ensuring that failures can be detected and corrected. The article concludes with the Task-Driven workflow I currently use, showing how these principles can be applied in practical AI-assisted development.
Recent Recommendations
What is a package registry?
After Swift Package Index joined Apple, the two announced that they would work together to build a package registry for the Swift community. But how does a package registry differ from SwiftPM, which we have used for years, and the Package Index, which helps us discover and evaluate packages? Dave Verwer starts with SwiftPM’s current Git-based dependency model: traditional dependencies require fetching source code from a Git repository and checking out the appropriate version, while a registry can distribute published source archives directly through package IDs, without carrying Git history, while also making published versions immutable.
But the significance of a registry goes beyond making package downloads more lightweight. More importantly, it introduces a formal package publishing model and raises broader questions around developer identity, package scope ownership, version publishing, and software supply chain security. This article offers both a concise introduction to how Package Registry works and useful background for understanding the Swift package infrastructure that Apple and Swift Package Index are preparing to build.
Handling CoreBluetooth Timeouts and Task Cancellation Correctly
Wrapping CoreBluetooth’s delegate APIs in async/await with withCheckedThrowingContinuation is not particularly difficult. The real trouble begins with the exceptional paths: What happens if the callback never arrives? After a Task is cancelled, does the underlying Bluetooth operation keep running? And when a normal result, timeout, and cancellation occur almost simultaneously, which one should resume the continuation?
ilawsonlu explores these practical problems and explains how to build a more complete timeout and cancellation mechanism for asynchronous CoreBluetooth wrappers. The article clearly distinguishes between cancelling a Swift Task and cancelling the underlying operation, while the open-source library ArcBLEKit demonstrates an approach to wrapping traditional delegate APIs in more robust Swift Concurrency APIs.
What Is CloudKit? Apple’s Backend Explained
CloudKit is an important yet often underestimated piece of infrastructure in the Apple ecosystem. From simple cross-device data synchronization to shared data and public databases, it allows developers to provide their apps with backend capabilities deeply integrated with Apple platforms through iCloud, without having to build and maintain their own servers. With both SwiftData and Core Data able to integrate directly with CloudKit, many developers are already using it without necessarily interacting with the CloudKit API itself.
Starting from the basic requirements of a backend, Sean Allen systematically introduces CloudKit’s private, shared, and public databases, along with core concepts such as Container, Record, and Schema, and compares three approaches: SwiftData, Core Data, and using the CloudKit API directly. The article does not shy away from CloudKit’s limitations, including its dependence on the Apple ecosystem and iCloud, schema migration, cross-platform support, and constraints around complex server-side logic.
OCR Doesn’t Give You Text. It Gives You a Map
Vision OCR does not return a neatly organized block of text. Instead, it gives you a collection of observations with bounding boxes: array order does not represent reading order, word boundaries do not inherently exist, and relationships between fields cannot simply be inferred from what comes before or after. While developing a record-sleeve scanning feature, Wesley Matlock encountered four bugs in a single day that appeared different but all stemmed from the same mistaken assumption. Through these real-world cases, the article shows how to use coordinates to determine reading order, reconstruct word boundaries from spacing, and associate fields through spatial proximity. Even more instructive is the author’s testing approach: saving bounding boxes exposed by real images as fixtures, using pure geometric data to lock down each layout assumption, while retaining the original photos for end-to-end tests. As the title says, OCR does not give you text—it gives you a “map.” The actual text structure has to be reconstructed from spatial relationships.
6 ways to promote your app without spending a penny
For indie developers, finishing an app is often only the first step. Getting more people to discover it can be even harder. Kickstart, created by Paul Hudson, outlines six promotional strategies in this article that require little to no financial investment: submitting to channels such as Indie App Showcase, cross-promoting with other indie developers through Kickstart Exchange, participating in communities where your target users gather, building your own mailing list, building in public, and continuously improving your App Store product page.
In addition, MacStories’ Federico Viticci is looking for noteworthy new apps and app updates for his annual iOS 27 Review. If you are preparing an iOS 27 release, you can recommend your app to him via DM or email at viticci@macstories.net.
Tools
Amethyst Vein: An Open-Source, Cross-Platform Local Persistence Framework with SwiftData-Style APIs
Developed by Mia Koring, Amethyst Vein is a local-first Swift ORM built on SQLite and SQLCipher, with APIs clearly inspired by SwiftData. It aims to bring SwiftData-style @Model, @Query, relationships, and migration APIs to Apple platforms, Linux, Android, and Windows. The project uses explicit versioned migrations, an Identity Map, and field-level synchronization, while supporting both SwiftUI and SwiftCrossUI.
DynamicNotch: Building Polished Notch and Screen-Edge Interactions for macOS
Developed by Govi, DynamicNotch is a macOS Swift Package designed for developers to create SwiftUI interfaces attached to the edges of the screen. It can present recording status, media controls, build progress, action confirmations, and compact views similar to Dynamic Island.
It properly handles safe areas, multiple displays, and the physical notch on MacBooks, supports all four screen edges, and can transition between compact and expanded states. DynamicNotch keeps its implementation deliberately focused: it handles geometry, clipping, positioning, and window presentation without imposing product-level logic such as gestures, notifications, or state management on developers.
SwiftTUI: Building Terminal Interfaces the SwiftUI Way
Developed by Adam Zethraeus, SwiftTUI is a terminal user interface framework for Swift developers. It brings SwiftUI’s declarative programming model to the terminal: developers can build interactive interfaces using View, @State, @Observable, layout containers, focus, gestures, and animations, while the framework handles layout, input processing, and partial updates.
What makes SwiftTUI interesting is not simply that it lets you “write TUIs in Swift.” The same view code can run in macOS, Linux, and Windows terminals, and can also be deployed to the browser, WASI, and native SwiftUI containers. The counter on its official website is itself a real SwiftTUI application, compiled to WebAssembly and running directly in the browser.