The application is a carbohydrate-counting app with a modern Swift codebase, written using current Apple frameworks and Composable Architecture. There was no significant technical debt to “clean up”, I already migrated the app to Swift 6 with strict concurrency some time ago. Instead, the goal was to explore how far agentic workflows could go in a realistic but well-structured project—specifically by modularizing the app into multiple local Swift Packages and evolving the architecture without sacrificing stability or velocity.

After connecting my ChatGPT account and downloading Codex, in less than six hours I was able to carry out a deep architectural reorganization, add two user-facing features, and significantly expand test coverage—all without manually writing any production or test code (for real).

Agentic Engineering as a workflow, not a feature

Agentic Engineering in Xcode is best understood not as an enhancement to code completion, but as a fundamentally different workflow. Instead of assisting at the level of individual lines or symbols, Xcode becomes an execution environment for an autonomous agent that can reason about the entire project.

By providing high-level instructions in natural language, I was able to ask Codex to analyze the codebase, propose a modular structure, migrate existing functionality into local Swift Packages, update dependencies, and ensure everything continued to build and run correctly. It even translated new localization keys automatically to supported languages. The interaction felt much closer to delegating work to a senior engineer than to using a traditional developer tool.

Modularizing into local Swift Packages

The core refactor consisted of splitting the application into a set of local Swift Packages, each with a clearly defined responsibility. This included isolating domain logic, data access, and shared utilities into separate modules, while keeping the app target itself focused on composition and UI concerns.

What stood out was that the agent did not simply move files around. It adjusted access control, reworked dependencies between modules, updated imports, and adapted existing tests to the new structure. My role throughout the process was to review the proposed architecture, validate the boundaries between packages, and request refinements where the separation did not fully align with my intent.

The entire modularization was completed without manual edits, except for adding the new local packages manually to xcodeproj, yet the resulting structure was coherent and idiomatic Swift.

Adding image suggestions using Apple Intelligence

Once the modular architecture was in place, I moved on to feature work. The first addition was automatic image suggestions for food items, generated using Apple Intelligence. When a user adds new food data with carbs info, the app now proposes suggested images, improving both usability and visual appeal.

From an implementation perspective, Codex handled the integration end-to-end: introducing the necessary abstractions in the domain layer, wiring them through the new modules, updating the UI, and ensuring the feature fit naturally within the existing architecture. The fact that this was built on top of a freshly modularized codebase made the change easier to reason about, not harder. There were few iterations needed to refine the feature the way I liked but I didn’t write any code at all.

Organizing food items by category

The second feature introduced categorical organization for food items. While conceptually simple, this change touched several layers of the app: the data model, domain logic, and presentation. In a traditionally structured project, this would have required careful coordination across targets and tests.

Using the agentic workflow, the change was expressed in terms of behavior and user experience. Codex propagated the necessary changes across modules, updated existing code paths, and extended the test suite accordingly. The end result was a feature that felt native to the app rather than bolted on.

Testing at scale

After the architectural changes and new features were complete, I asked Codex to focus on test coverage. The result was an increase of roughly 200%, with tests that exercised domain logic and validated key behaviors across modules.

What matters here is not the raw number, but the quality. The generated tests were meaningful, readable, and closely aligned with how the app is expected to behave. They provided real confidence that the refactor and new features had not introduced regressions, especially important after a large-scale modularization.

A shift in the developer’s role

The most significant aspect of this experience was not raw speed or novelty, but a fundamental shift in what it means to “write software” when friction is removed. The primary constraint was no longer implementation effort, but the precision with which intent could be expressed. Clear instructions and well-defined architectural boundaries consistently led to better outcomes. The engineer’s role naturally shifts toward defining module boundaries, reviewing decisions, and validating results. Deep expertise in Swift, iOS architecture, and the problem domain remains essential, but a large portion of repetitive and mechanical work fades into the background.

While agent-based development is not new—Codex itself was not announced recently—the integration Apple delivered in Xcode 26.3 is exceptionally well executed. The experience feels native: you interact directly with Xcode, without complex setup, configuration, or ongoing troubleshooting. After signing in, you can start working within minutes, and the tooling simply stays out of the way.

On a more personal note, finding time for indie projects has always been a challenge. After spending the workweek programming, it is not always appealing to dedicate entire weekends to writing more code. This workflow changes that dynamic. It allows me to focus on the product decisions and the value I want to deliver, while Xcode handles much of the implementation under my supervision. At a broader, organizational level, the same shift applies: teams can refocus on delivering meaningful user value and ensuring they are building the right things, rather than expending disproportionate energy on process and mechanical execution.

Closing thoughts

Using Agentic Engineering with Xcode 26.3 and Codex on a real, modern production app demonstrated that this approach is already viable for professional iOS development without spending hours in setting it up. It enables large-scale architectural changes and feature work at a pace that would previously have been unrealistic, even in a well-maintained codebase. With proper Skills, that goes even further. I’ll write another article about that soon.

This is not about replacing developers. It is about raising the level of abstraction at which we operate. Once you experience that shift firsthand, it becomes clear that this is not a preview of the future—it is already part of the present.

Apple has set a high bar with this release.

Why would someone use an app to count carbohydrates?

My wife has been managing her diabetes since childhood. To keep track of the carbohydrates in her meals, including those cooked at home and ordered at restaurants, she used the Notes app from Apple.

She experimented with various applications that provided databases of nutritional information for common products, but her experience with them was not satisfactory. While some calculations were reasonably accurate, she found that her diabetes management was not effectively controlled due to the inaccuracies in the carbohydrate counting.

This prompted her to create her own list of carbohydrates, which would allow her to count them quickly and accurately. I wanted to assist her in this endeavor by developing an app specifically designed for this purpose.

What is carb counting, and why is it necessary?

You’ve probably seen a nutrition facts table on all the food you buy from the supermarket.

Carbohydrate counting involves determining the number of carbohydrates in a portion of food you intend to consume. For instance, if you consume the recommended portion (110g), it contains 23g of carbohydrates.

This calculation is crucial for individuals with type-1 diabetes because the amount of insulin they require for injection depends on two factors:

– The quantity of carbohydrates they plan to consume.

– The insulin dosage needed for 1g of carbohydrates.

Based on these two factors, type 1 diabetic patients can calculate the appropriate insulin dosage to administer before each meal. For example, if they consume 23g of carbohydrates and the recommended ratio is 2 IU per 10g, they would inject 2.3 IU of insulin.

While this calculation is straightforward and can be mentally performed by even children, it becomes more complex when considering varying ratios based on the time of day, menstrual cycles, and numerous other life factors such as stress or anxiety, as well as active insulin in the body.

In such cases, it is advisable for patients to use a Bolus Calculator to effectively manage their diabetes. This tool tracks different ratios and the active insulin levels in the body from previous meals. Ultimately, the most critical aspect is accurate carbohydrate counting.

Look and feel

I wanted to keep it as simple as possible, so I divided it into two tabs.

• List of meals: Where you count the carbohydrates before eating.
• List of food: Where you keep track of the nutritional facts for each food based on your regular consumption.

Users can simply add their food items in advance, and the counting process becomes straightforward. They can add items from their list, and the calculation will be displayed instantly.

Since my wife uses the Bolus Calculator from the mySugr app and importing data from Apple Health is a supported feature, I’ve also implemented data export.

Behind the scenes

I wanted to take this opportunity to create a new application from scratch and experiment with the new Observation tools introduced in version 1.7.0 of The Composable Architecture (TCA).

Implementing the app was incredibly straightforward. I only needed to create SwiftUI views and reducers for meals, food lists, meal counting, and item details. The integration of the Observation framework into the TCA library made the data bindings between the views and reducers seem like magic.

The most challenging part was persisting the data. I opted to store it in a simple file within the app’s sandbox.

One of the significant advantages of using TCA was that all data modeling was implemented using structs. This allowed me to provide users with the flexibility to modify the carbohydrate content of a food item without affecting the calculations for previous meals, including the same food item. For instance, if a user decides to purchase it from a different supermarket and the nutrition facts are slightly different, they can adjust the carbohydrate content without impacting the meal calculations.

The Composable Architecture is an exceptional implementation of the unidirectional data flow paradigm, elevating SwiftUI apps to new heights. It took me just four days to develop and publish my app, including creating a promotional website and professional AppStore screenshots, which I’ll delve into in a separate article.