Printed on: February 16, 2026
Some time again, my app crashed mid-workout on the health club. I uploaded the crash report, gave my AI agent some context, and went again to my set. By the point I completed, there was a pull request ready for me. I reviewed it, merged it, and had a hard and fast TestFlight construct on my gadget shortly after — with out ever opening Xcode.
That form of turnaround is barely potential due to the supply pipeline I’ve constructed round agentic engineering. And that is what this publish is about. Know that this publish does not introduce something revolutionary by way of how I work. However it is a setup that works properly for me, and I believe at the present time, it is essential for folk to get some insights into what others are doing as an alternative of seeing one more “I SHIP TONS OF AI CODE” publish.
I am hoping to be slightly extra balanced than that…
Agentic engineering (aka vibe coding) is gaining popularity by the day. An increasing number of builders are letting AI brokers deal with giant elements of their iOS tasks, and actually, I get it. It is extremely productive. Nevertheless it comes with an actual threat: if you hand off the coding to an agent, high quality and structure can degrade quick if you do not have the precise guardrails in place.
On this publish, I wish to stroll you thru the pipeline I exploit to ensure that although I do agentic engineering, my product high quality stays stable (sure, it includes me studying the code and generally tweaking by hand).
We’ll cowl organising your native surroundings, why planning mode issues, automated PR evaluations with Cursor’s BugBot, operating CI builds and checks with Bitrise, and the magic of getting TestFlight builds land in your gadget nearly instantly after merging.
If you happen to’re taken with my broader ideas on balancing AI and high quality, you would possibly get pleasure from my earlier publish on the significance of human contact in AI-driven growth.
Organising your native surroundings for agentic engineering
The whole lot begins domestically. Earlier than you even take into consideration CI/CD or automated evaluations, that you must make sure that your AI agent is aware of how you can write code the best way you need it written. An important instrument for that is an brokers.md file (or your editor’s equal, like Cursor guidelines).
Consider brokers.md as a coding requirements doc to your agent. It tells the agent what language options to choose, how you can construction code, and what conventions to observe. This is an instance of what mine appears like for an iOS venture:
## Swift code conventions
- Use 2-space indentation
- Want SwiftUI over UIKit until explicitly concentrating on UIKit
- Goal iOS 26 and Swift 6.2
- Use async/await over completion handlers
- Want structured concurrency over unstructured duties
## Structure
- Use MVVM with Observable for view fashions
- Preserve views skinny; transfer logic into view fashions or devoted providers
- By no means put networking code immediately in a view
## Testing
- Write checks for all new logic utilizing Swift Testing
- Run checks earlier than making a pull request
- Want testing conduct over implementation particularsAdd this file to the foundation of your Xcode venture, and Xcode 26.3’s agent will choose up your guidelines too.
This file is simply a place to begin. The factor is, your brokers.md is a dwelling doc. Each time the agent does one thing you do not like, you add a rule. Each time you discover a sample that works properly, you codify it. I replace mine continuously.
For instance, I’d discover my agent creating new networking helper courses as an alternative of utilizing the APIClient I already had. So I can add a rule: “All the time use the prevailing APIClient for community requests. By no means create new networking helpers.”. From that second on, the agent ought to honor my preferences and use present code as an alternative of including new code.
Past guidelines, you too can equip your agent with abilities. A talent is a standalone Markdown file that teaches the agent a couple of particular matter in depth. The place brokers.md units broad guidelines and conventions, a talent normally comprises detailed patterns for how you can construction issues like SwiftUI navigation, deal with Swift Concurrency safely, or work with Core Information. Xcode 26.3 even has an MCP (you’ll be able to kind of consider that as a predecessor of abilities) that may assist brokers discover documentation, greatest practices, and extra.
Your native surroundings is the inspiration. The whole lot that comes after (PR evaluations, CI, TestFlight) will depend on the agent producing cheap code within the first place.
Planning earlier than constructing
That is the step that, in my view, carries a ton of worth however is simple to skip.
If you happen to use Cursor (or an identical instrument), you in all probability have entry to a planning mode. As an alternative of letting the agent bounce straight into writing code, you ask it to make a plan first. The agent outlines what it intends to do — which information it’s going to change, what strategy it’s going to take, what tradeoffs it is contemplating — and also you overview that plan earlier than giving the inexperienced gentle.
The distinction between “hearth off a immediate and hope for one of the best” and “overview a plan, then execute” is big. While you overview the plan, you catch dangerous architectural choices earlier than they turn into dangerous code. You possibly can steer the agent towards the precise strategy with out having to undo a bunch of labor.
Planning may even make it extra apparent if the agent misunderstood you. For instance, in case your immediate is not tremendous focused to sort out all ambiguity up-front, the agent would possibly confidently suppose you meant one factor when you meant one other. A humorous instance is “persist this knowledge on gadget” and the agent assumes “write to consumer default” if you meant “create Swift Information fashions”. You possibly can usually catch these items in planning mode and repair the agent’s trajectory.
In apply, my workflow appears like this: I describe what I need in planning mode, the agent proposes an strategy, I give suggestions or approve, and solely then does the agent change to implementation. Going by means of planning first can really feel sluggish however normally I discover that it makes the output so a lot better that it is 100% value it.
For instance, after I wished so as to add a streaks function to Maxine, the agent proposed creating a completely new knowledge mannequin and look at mannequin from scratch. Within the plan overview, I seen it was going to duplicate logic I already had in my exercise historical past queries. I steered it towards reusing that present knowledge layer, and the outcome was cleaner and extra maintainable. With out the planning step, I’d have ended up with redundant code that I would have to scrub up later.
Automated PR evaluations with BugBot
As soon as the agent has written code and I’ve completed a fast examine to overview adjustments, I run the code on my gadget to ensure issues appear and feel proper. As soon as I log off, the agent could make a PR on my repo. If the agent is operating within the cloud, I skip this step fully and the agent will make a PR instantly when it thinks it is completed.
That is the place BugBot is available in. BugBot is a part of Cursor’s ecosystem and it mechanically evaluations your pull requests. It appears for logic points, edge instances, and unintended adjustments that I’d miss throughout a fast scan. It might probably even push fixes on to the PR department.
BugBot has been invaluable in my course of as a result of although I do my very own PR overview, the entire level of agentic engineering is to let the agent deal with as a lot as potential. My objective is to kick off a immediate, rapidly eyeball the outcome, run it on my gadget, and transfer on. BugBot acts as an automatic security web that catches what I may not.
Let me offer you two examples from Maxine. The primary is about edge instances. Maxine recovers your exercise if the app crashes. BugBot flagged that there was a potential situation the place, if the consumer tapped “begin exercise” earlier than the restoration accomplished, the app would try to begin a Watch exercise twice. Actually, I thought of this situation almost unattainable in apply — however the code allowed it. As an alternative of counting on what I could not realistically take a look at, BugBot added safeguards to ensure this path was dealt with correctly. That is precisely the form of factor I would by no means catch throughout a fast eyeball overview.
The second is about unintended adjustments. I as soon as had a PR the place I had left behind a number of orphaned debugging properties. BugBot noticed them as “in all probability not a part of this transformation” — the PR description the agent had written did not point out them (as a result of I did the debugging myself), and no code truly referenced these properties. BugBot eliminated them. Small factor, but it surely’s the form of cleanup that retains your codebase tidy if you’re transferring quick and reviewing rapidly.
Operating builds and checks with Bitrise
Although the agent runs checks domestically earlier than I ever see the code, I desire a second layer of confidence. That is the place CI is available in. I exploit Bitrise for this, however the identical workflow ideas apply to Xcode Cloud, GitHub Actions, or any CI supplier that may run xcodebuild.
This step is much more essential for my cloud based mostly brokers as a result of these do not get entry to xcodebuild in any respect.
I’ve two Bitrise workflows arrange for my tasks, every triggered by totally different occasions.
The take a look at workflow (runs on each PR)
The primary workflow is a test-only pipeline that triggers each time a pull request is opened or up to date. The steps are minimal:
- Clone the repository
- Resolve Swift packages
- Run the take a look at suite with
xcodebuild take a look at
That is it. No archiving, no signing, no importing. The one job of this workflow is to reply one query: do the checks nonetheless go? If one thing the agent wrote (or one thing BugBot fastened) breaks a take a look at, I do know earlier than I merge. And I can inform an agent to go repair no matter Bitrise reported.
I set this up as a set off on pull requests concentrating on my primary department. Bitrise picks up the PR mechanically, runs the workflow, and stories the outcome again as a GitHub standing examine. If it is purple, I do not merge.
The discharge workflow (runs on merge to primary)
The second workflow triggers when one thing is pushed to primary — which in apply means when a PR is merged. This one does considerably extra:
- Clone the repository
- Resolve Swift packages
- Run the complete take a look at suite
- Archive the app with launch signing
- Add the construct to App Retailer Join
The take a look at step would possibly really feel redundant since we already examined on the PR, however I like having it right here as a remaining security web. Merges can often introduce points (particularly if a number of PRs land shut collectively), and I would fairly catch that earlier than importing a damaged construct.
The archive and add steps use Bitrise’s built-in steps for Xcode archiving and App Retailer Join deployment. You arrange your signing certificates and provisioning profiles as soon as in Bitrise’s code signing tab, and from that time on, each merge produces a signed construct that goes straight to TestFlight.
Why checks matter much more with AI
Having a stable take a look at suite might be essentially the most impactful factor you are able to do for agentic engineering. Your checks act as a contract. They inform the agent what appropriate conduct appears like, and so they catch regressions in CI even when the agent’s native run one way or the other missed one thing. Higher checks imply extra confidence, which suggests you’ll be able to let the agent deal with extra.
By the point I truly hit “merge” on a pull request, the code has been by means of: native checks by the agent, my very own fast overview, BugBot’s automated overview, and a inexperienced Bitrise construct. That is a number of confidence for little or no handbook effort.
The magic of quick TestFlight suggestions
That is the place every little thing I wrote about up to now comes collectively. As a result of the discharge workflow uploads each merge to App Retailer Join mechanically, each single merge to primary leads to a TestFlight construct — no handbook intervention required. You do not open Xcode, you do not archive domestically, nothing. You merge, and some minutes later there is a new construct in TestFlight. This closes the loop from “I had an concept” to “I’ve a construct on my gadget” with minimal friction.
While you’re testing your app within the subject and also you discover one thing you wish to tweak — a format that feels off, a label that is unclear, a circulate that is clunky — you’ll be able to usually simply inform your agent what to repair. If the change is easy sufficient and also you’re good at prompting and planning, you’ll be able to have a brand new construct in your gadget surprisingly rapidly. By your native planning, by means of the PR, by means of Bitrise, and onto your gadget by way of TestFlight.
Let’s return to the instance from the intro of the publish…
Throughout one in every of my exercises with Maxine the app crashed. Proper there within the health club, I pulled up Cursor, uploaded the crash report that TestFlight gave me, added some context about what I used to be doing within the app, and kicked off a immediate. Then I simply resumed my exercise.
By the point I used to be completed, there was a PR ready for me. The repair wasn’t good — I needed to nudge a number of issues — however the bulk of the work was completed. I merged it, Bitrise picked it up, and I had a brand new TestFlight construct shortly after. All whereas I used to be centered on my exercise, not on debugging.
That is what occurs when each piece of the pipeline is automated. The agent writes the repair, BugBot evaluations it, Bitrise checks and builds it, and TestFlight delivers it. Your job is to steer, to not crank.
Abstract
Agentic engineering doesn’t suggest giving up on high quality. It means constructing the precise guardrails so you’ll be able to transfer quick with out breaking issues.
The pipeline I exploit appears like this: a well-maintained brokers.md and AI abilities set the inspiration domestically. Planning mode ensures the agent’s strategy is sound earlier than it writes a line of code. BugBot catches points in pull requests that I’d miss. Bitrise runs checks on each PR and archives plus uploads on each merge to primary. And TestFlight delivers the outcome to my gadget mechanically.
Every bit reinforces the others. With out good native setup, the agent writes worse code. With out planning, it makes dangerous architectural choices. With out BugBot and Bitrise, bugs slip by means of. With out computerized TestFlight uploads, the suggestions loop is simply too sluggish to be helpful.
To be clear: this pipeline does not catch every little thing. An agent can nonetheless write code that passes all checks however is architecturally questionable, and BugBot will not at all times flag it. You continue to must overview and suppose critically. However the mixture of all these layers significantly cuts down the chance of transport one thing damaged — and that is the purpose. It is about lowering threat, not eliminating it.
If you happen to’re prototyping or simply exploring an concept, you in all probability do not want all of this instantly. However the second you may have actual customers relying in your app, this sort of pipeline pays for itself. Set it up as soon as, iterate in your brokers.md as you go, and you’ll transfer quick with out sacrificing the standard your customers anticipate.
