Lately, even tasks that I consider relatively simple often take AI several minutes—or sometimes even tens of minutes—to complete. It gave me the impression that as models become more capable, they somehow have to become slower.
In reality, the main reason lies with me. Although today’s AI agents let us choose different models and reasoning levels, it’s much easier—and often more reliable—to simply hand even straightforward tasks to the most capable models. At the same time, modern agents no longer limit themselves to the small change you explicitly requested. They proactively expand their search, analyze whether the modification could affect other parts of the project, and try to identify potential issues before they happen. The models may be more powerful than ever, but they’re also taking on substantially more work for every task.
There’s another factor as well. As my trust in these models has grown, so has the scope of the tasks I assign to them. What used to be “refactor a function” or “improve a screen” has gradually become “implement a feature,” “build a module,” or even “create an entire product.” Without realizing it, I’ve started treating AI agents as genuine collaborators. The pace at which model performance improves simply hasn’t kept up with the way we now use them.
In other words, developers are no longer pursuing only “writing code faster.” Increasingly, we’re using AI to write better code, even if it takes longer.
The shift from question-answering to task delivery has happened in just a single year. As we grow accustomed to waking up and reviewing completed work, the real bottleneck is quietly moving elsewhere. We used to ask whether a model was capable of completing a task. Today, the more important questions are how to define a clear, verifiable objective, and how to reduce the cost of achieving it. AI is becoming more like a teammate, and the ability to organize and decompose work effectively is becoming the next competitive advantage.
Recent Recommendations
Bluetooth without the delegate dance
Delegates remain a challenge many developers continue to face years after the introduction of Swift Concurrency. Not only do they often lead to cumbersome code organization, but under Swift 6’s strict concurrency checking they also become increasingly difficult to integrate naturally with modern concurrent code. Kyle Browning leverages Swift 6.2’s Custom Executor to bind CoreBluetooth’s callback queue directly to an Actor’s execution context, allowing delegate callbacks to run naturally within Actor isolation without additional locks, thread hopping, or synchronization logic.
Custom Executor allows an Actor’s tasks to run on a designated executor, making it a powerful tool for bridging traditional callback-based APIs with Swift Concurrency. If you’re facing similar migration or abstraction challenges, this implementation is well worth studying. I also explored this topic in depth using Core Data as an example in this article, explaining how to bind traditional serial queues to Actor executors for seamless integration with Swift Concurrency.
Working with Xcode on CI
As more developers adopt self-hosted macOS runners or cloud-based CI, reliably managing Xcode, Simulator Runtimes, and code-signing environments has become an essential part of engineering infrastructure. Dmitry Rodionov shares a collection of practical techniques for using the Xcode CLI in CI, including managing multiple Xcode installations with DEVELOPER_DIR instead of xcode-select, automating the installation and cleanup of Simulator Runtimes and Metal Toolchains, and reducing unnecessary recompilation during branch switching with Compilation Caching.
Squeeze every last bit of value out of GitHub Actions
Optimizing GitHub Actions doesn’t necessarily mean more aggressive caching, more complex workflows, or additional conditional logic. Instead, this article advocates a more valuable principle: every CI run should match the actual risk introduced by a change. Starting from the investigation of an apparently ordinary flaky test, Snow discusses how deterministic tests eliminate unnecessary reruns, how portable checks can be moved to Linux while leaving Xcode-dependent validation to macOS, and how Build, Test, or Build for Testing can be selected dynamically based on change risk to avoid wasting expensive runner time.
I particularly agree with one of the article’s core ideas: the goal of CI is not to “run more,” but to “answer the right questions.” Every expensive macOS build should validate a risk that a cheaper runner cannot, and every failure should provide actionable information that helps move the project forward.
Building adaptive non-modal panels in SwiftUI
Starting with WWDC26, iPhone-only apps running through iPhone Mirroring on a Mac or on an iPad enter a resizable environment. This means relying solely on horizontalSizeClass for layout decisions is becoming increasingly unreliable. Matthaus Woolard demonstrates how to build an adaptive non-modal panel by recording scene size and safe-area insets at the root using onGeometryChange, then choosing between bottom and side presentations based on the actual available width. One particularly useful technique is preserving the resolved layout cache during dragging, preventing adaptive content from changing size due to repeated measurements.
If your app is iPhone-only but still has users running it on iPad or macOS, layout adaptation deserves much more attention going forward. As discussed in From Size Class to Available Space, the era of resizable canvases no longer guarantees developers absolute control over interface layouts, instead giving users much greater control over how apps are presented.
SwiftUI @ContentBuilder - Faster Type Checking in Xcode 27
Xcode 27 introduces the new @ContentBuilder. Although it is currently just a type alias for ViewBuilder, Apple has begun recommending this new name in its latest SwiftUI APIs. Sagar Unagar explains the change and notes that, for most applications, there is no need to immediately replace every @ViewBuilder with @ContentBuilder, as existing code already benefits from the compiler improvements introduced in Xcode 27.
I haven’t written much SwiftUI code recently, so I haven’t yet experienced firsthand whether this change significantly improves compilation performance. That said, in previous projects I often noticed Xcode struggling with type inference and code completion whenever different builder content was mixed inside a
ViewBuilder, especially with APIs like Table and Charts. If Xcode 27 truly improves these scenarios, then this change represents much more than just a new builder name.
Tool
tswift: A Lightweight Swift Runtime Built with Rust
Without relying on the Swift toolchain, LLVM, code generation, or any C dependencies, tswift can parse, semantically analyze, and execute Swift source code. Developed by Francis Chong, tswift implements the Swift frontend entirely in Rust, handling lexical, syntactic, and semantic analysis before interpreting Swift language semantics and standard library behavior through a tree-walking runtime.
Beyond the language runtime itself, the project is also exploring framework support. SwiftUI already has a basic rendering pipeline, while Charts currently implements 58 of 60 range-related members, can render Web SVG output, and can bridge to Apple’s native Charts framework on iOS.
Whether it’s the C-based miniSwift, the recent signs of the Swift compiler’s self-hosting progress, or the Rust-based tswift runtime, they all demonstrate that the Swift ecosystem is evolving toward a more open and diverse implementation landscape. As more implementation paths emerge, Swift’s cross-platform potential continues to grow beyond what many expected.