Article · Blog
How I work with AI: I don't ask for code, I configure the environment the AI works in
I believe the real gain with AI didn't come from better prompts, it came from changing the question. Instead of asking for code, I engineer the environment, the harness, where the agent works within my standards.
When people ask how I use AI in my day-to-day mobile development, the short answer is that I stopped treating it like a smarter autocomplete. I believe the real gain didn't come from writing better prompts, it came from changing the question. Instead of "what can this AI do for me today", I started asking "what environment do I need to build so it works within my standards, every single time". I call that the harness.
What the harness is
A harness is the structure around the agent. It is not a prompt, it is a configuration. It is the rules it loads before it starts, the memory it consults, the checks it has to pass and the guardrails that stop it from doing something reckless. The difference is subtle but it changes everything. Without a harness, every session depends on the luck of the prompt and on my patience to repeat context. With a harness, the agent opens already knowing the project architecture, what was left pending last time and what it is not allowed to do.
The pillars
Auto-loaded contract. Every session starts by reading the project's architecture and quality rules, without me asking. The agent already knows the dependency direction between layers, the boundaries between modules and what is non-negotiable. That prevents code that works but is born outside the standard.
Working memory. I keep a living record of the project state. Each session continues where the previous one stopped, without relying on the chat history. I believe this is one of the most underrated points, because what kills productivity with AI is not the AI being wrong, it is me having to rebuild context every time.
Automated sensors. The agent does not consider a task done just because the code compiles. It has to pass checks for architecture, types, lint, tests and documentation consistency. If something breaks, it sees it and fixes it before handing it to me.
Confirmation gates. Reading runs freely, but any action that changes or destroys something stops and waits for my confirmation. Nothing irreversible happens on its own. That lets me run the agent with more autonomy precisely because I know it will not surprise me where it matters.
Disciplined flow. Before writing code, we talk through the idea, write a plan, execute it in parts and review. It looks bureaucratic, but it is what turns a good intention into a predictable delivery.
MCP connectors: the agent acts on the source of truth
This is where one of the biggest gains lives. I connected the agent, through MCP, to GitHub and to Atlassian. That changes the nature of the work in two ways.
The first is error margin. Instead of me copying and pasting context and hoping it understands, the agent reads the source of truth directly: the real issue, the PR, the code, the ticket. Less guessing, less hallucination, less rework. It works with what exists, not with what it imagines exists.
The second is reporting and self-assessment. Because it can see what the ticket asked for and what was actually delivered, I can generate honest status reports and, more importantly, a self-assessment of the delivery itself. It cross-checks what was agreed against what was done and points out the gaps. I believe this is rare to see, it is where AI stops being just execution and becomes quality control too.
Specialized skills
On top of the harness, I activate specific skills depending on the task: for the harness and work discipline itself, for planning and writing specs, for tests, for code review (including adversarial review), for UX, for Swift and SwiftUI and for architecture decisions.
I also use a product skill, PM style, and that may be the one that changed the way I think about delivery the most. It helps me look beyond the code and ask what usually gets left out: does this move a metric, does it solve a real pain, is it worth the effort it will cost? I believe a lot of developers stop at "it's done and it works", and I wanted to be able to answer, before that, whether it was the right thing to build. Bringing the product lens into the AI flow lets me prioritize better, justify what I deliver and see the work from the point of view of whoever is going to use it, not just whoever writes the code.
In day-to-day mobile
In the Claude ecosystem, I use Claude Code for new features, debugging, refactoring and tests, and the Claude API when the app itself needs embedded intelligence. But what makes the difference is not the tool, it is the harness around it. The same feature I used to ask for loosely is now born inside the contract, passes through the sensors and arrives reviewed.
Quality and speed, together
Intuition says discipline is a brake. In practice it was the opposite. I believe I got faster precisely because I stopped wasting time with rework, lost context and code that had to be undone. Quality went up because the standards stopped depending on my memory and started being guaranteed by the structure. It is not magic, and it does not always come out perfect... I have had stumbles, decisions I had to reverse, things the agent misunderstood. The difference is that the harness turns those stumbles into something cheap to fix, instead of expensive.
To close
I believe the future of development is not about who types faster, it is about who builds the best environment for AI to work safely and consistently. That is what changed my deliveries.
If any of these topics interest you, I can go deeper into any of them:
- how the confirmation gates work in practice
- how I keep memory between sessions
- how I use subagents to execute plans in parts
- how I ensure truthfulness and stop the AI from inventing facts
- how MCP connectors turn into reporting and self-assessment of delivery
- how I combine specialized skills, from Swift and architecture to product, depending on the task