Over the last few months, I have gradually built a fairly stable AI-assisted development workflow for my side projects.
The workflow looks roughly like this.
Architecture and design are handled by Claude Sonnet / Opus. I maintain a set of engineering skills and design templates for feature planning. Once the design document is finalized, DeepSeek V4 is responsible for implementation. After coding is complete, I run an independent review workflow inside OpenCode to perform security review, architecture validation, data integrity checks, performance inspection, and test coverage analysis.
The process is structured enough that I have become fairly confident in it.
Recently, I decided to redesign the data storage architecture of one of my iOS projects.
The first version of the application was relatively simple. Data lived entirely in local SQLite storage. Users could manually export and import backup files, but data was stored unencrypted and there was no cloud synchronization.
During an AI-assisted security review, one issue was raised immediately.
Sensitive financial data was stored locally without encryption.
The feedback was correct.
This triggered a second architecture redesign.
The new design introduced AES-GCM encryption for all persisted data, and automatic backup to iCloud Drive. The goal was simple: keep user data private, avoid maintaining backend storage infrastructure, and allow users to restore data across devices without trusting a third-party server.
From a technical perspective, the stack became more complicated.
Flutter handled the application layer. SQLite remained the local storage engine. Flutter MethodChannel bridged into Swift native code. Swift then interacted with iCloud Documents API for cloud persistence.
Implementation was generated almost entirely through my AI workflow.
Everything looked fine.
Then I ran real-device testing.
The logs were clean.
JSON backup generation succeeded.
Encryption succeeded.
Flutter successfully invoked native Swift code.
Swift returned successful file write.
The application printed the following path:
/private/var/mobile/Library/Mobile Documents/...
Everything suggested success.
Then I opened Files.app on the iPhone.
Nothing.
No folder.
No backup file.
At first, I assumed iCloud synchronization was delayed.
I waited ten minutes.
Still nothing.
At this point debugging began.
I started checking the usual suspects.
Entitlements configuration.
iCloud container identifier.
Sandbox permissions.
Capability configuration.
Provisioning profile.
Everything looked correct.
I went back to AI-assisted debugging.
I used OpenCode with Claude Opus to review the native Swift implementation.
No issue found.
I switched models and repeated the review with DeepSeek.
No issue found.
I spent roughly two hours going through logs and rechecking assumptions.
Eventually I found the problem.
The Swift implementation used direct file writing.
content.write(to: url, atomically: true, encoding: .utf8)
This works perfectly in a normal filesystem.
But iCloud Documents API is not a normal filesystem.
Direct write does not properly trigger iCloud synchronization.
The correct implementation requires NSFileCoordinator
.
There was a second issue.
When restoring backup on a new device, the code directly attempted file reading.
However, files stored in iCloud may not be downloaded locally yet.
The restore logic needed to call:
startDownUbiquitousItem()
before attempting to read.
After fixing both issues, synchronization finally worked.
At that point I started thinking less about the bug itself, and more about the development process that produced it.
What I realized is this.
Throughout the entire development pipeline, every participant was validating code correctness.
Claude validated architecture.
DeepSeek generated implementation.
AI review agents inspected security and code quality.
I manually checked logs and exception handling.
But nobody validated system behavior.
This distinction feels increasingly important.
Code correctness and system correctness are not the same thing.
Historically, software development looked roughly like this.
Engineers write code.
Engineers review code.
Engineers understand code.
When bugs happen, engineers debug systems they understand.
But modern AI-assisted development increasingly looks different.
LLM writes code.
Another LLM reviews code.
Code volume expands rapidly.
Engineers understand less of the implementation details.
When bugs happen, debugging cost rises dramatically.
The interesting part is that none of the code involved in this bug was obviously incorrect.
The code compiled.
The APIs returned success.
The logs were clean.
Review passed.
And yet the system behavior was wrong.
I suspect this problem will become increasingly common.
LLMs are very good at generating syntactically correct code.
They are very good at code review.
But they remain weak at understanding complex runtime environments.
Especially when code interacts with operating system boundaries.
iOS sandbox behavior.
iCloud synchronization semantics.
Browser event loops.
Native runtime state.
Database isolation.
OS-level permission systems.
These are not code generation problems.
These are system behavior problems.
The industry currently spends a lot of time discussing how AI improves developer productivity.
I think we are missing the other half of the equation.
AI is clearly lowering coding cost.
But it may also be quietly increasing debugging complexity.
And as LLM-generated code becomes more common, I increasingly suspect one skill will become more valuable than coding itself.
Understanding what actually happens after the code runs.
Because in the AI era:
Code correctness does not guarantee system correctness.
A small iCloud synchronization bug reminded me of something I probably should have already known.
The faster AI helps us write software, the more important system-level verification becomes.
AI can write code.
But engineers still need to understand systems.
And when production breaks, understanding systems matters far more than generating code.