Two years ago, I started an experiment. I wanted to know whether I could build production-grade software products without writing most of the code myself. Not because I was lazy. Because I had thirty years of product ideas and not nearly enough development hours to explore them.
What followed was 15 months of iteration, failure, discovery, and refinement — through Cline, Claude Code, Claude Desktop with MCP stacks, Augment Code, and finally Augment Code’s Intent. I documented each phase. I shared the honest results, including the costs, the frustrations, and the breakthroughs. That is what the From Lab to Life series is about.
In my last article, I described what it felt like to work inside Intent — Augment Code’s multi-agent orchestration environment — watching 177 tasks get assigned, tracked, and executed while I focused on architecture rather than implementation. The feedback was immediate and consistent: people wanted to know more about the process behind the process.
So today, I am opening my books.
This is the exact methodology I use when I start a new digital product — refined over two years, documented in real-time, and actively in use right now on a client project I am building. It is the most valuable practical knowledge I can share about working with AI coding agents, because without this foundation, even the most powerful agent orchestration tools produce chaos.
There are three phases. Each one is essential. None of them can be skipped.
The difference between a professional using AI coding agents and a vibe coder is not the tools. It is everything that happens before the first agent runs.
Phase One: Context Engineering
The Foundation Everything Else Is Built On
I call this the context engineering phase, and it is by far the most important. It is also the phase most people skip, rush, or underestimate — and it is exactly why their agent-built projects collapse into debugging chaos three days in.
The principle is simple: coding agents are extraordinarily capable when they have rich, structured context. They are expensive, frustrating, and unreliable when they do not. Every hour you invest in Phase One saves you five hours in Phase Two.
Step 1: The Foundational Research Document
I begin every project the same way. I create a new Claude Project, and I throw everything I have into it — diagrams, investor decks, sketches from Excalidraw, notes app screenshots, PDFs, rough specs, anything that describes what I am trying to build. Then I engage Claude’s research mode with a single, clear mission: build me a foundational research document about this product space.
This document is a living brief about the problem, the market, and the technology. What similar products already exist? What frameworks have other developers used to build them? What would the ideal technology stack look like — front end (React vs Next.js, depending on the need), back end (Python, Node), infrastructure, databases? Which LLMs are suitable to power the specific AI capabilities this product needs? Are there existing APIs, platforms, or services I should be integrating rather than building from scratch?
On the current project I am building — an AI avatar assistant for a specific niche online platform — this research phase helped me identify that I needed to evaluate ElevenLabs and HeyGen for the video avatar streaming component rather than attempt to build this capability myself. The research document surfaced this immediately. It saved me weeks of misdirected development.
This document is also where I do the honest economics check. Is there a total addressable market? Does something similar already exist and, if so, what is the differentiation? If this is a SaaS product, what are the realistic unit economics at various user scales? I use the research agent to pull data, trends, market sizing reports. This is not busywork — it is the difference between building something that makes sense and building something beautifully that nobody needs.
I iterate on this document until it is right. Not perfect — right. It needs to clearly answer: what are we building, why does it make sense, and what are the building blocks we are using to build it?
Step 2: Technical Documentation — The Agent’s Knowledge Base
Once the research document is solid, I move into the second part of Phase One: creating the technical documentation that will serve as the foundational knowledge base for my coding agents. This is context engineering in its most literal form.
I typically create four documents:
• Architecture Document — The overall technical architecture: services, databases, integrations, data flow, and infrastructure decisions. If I am using Firebase, Supabase, or DigitalOcean, it is defined here. If there are external API dependencies, they are mapped here.
• Project Blueprint — The complete feature specification, broken into logical components. What does the front end consist of? What does the back end handle? What are the boundaries between them? This is the document my orchestrator agent will use to decompose work into tasks.
• UI/UX Document — Wireframe-level descriptions of the application: which screens exist, how users navigate between them, what each view displays, what interactions trigger what outcomes. I describe the login flow (Google Auth or otherwise), the dashboard structure, the key user journeys. I am not designing pixels here. I am describing functionality clearly enough that an agent can make sensible implementation decisions.
• Security and Compliance Notes — This is frequently skipped by people building with agents and it is always a mistake. Which regulations apply? GDPR? Specific industry requirements? What authentication mechanism is being used? What data must be encrypted at rest and in transit? What are the rate limiting requirements? Defining this here means my agent builds it in, rather than retrofitting it later.
I also address scalability in these documents. Is this an MVP that I am building to validate a hypothesis, or does it need to handle significant user load from day one? Agents will make architectural decisions that either support or constrain future scaling — and they will make those decisions based on what you tell them, or based on nothing.
Context failures propagate. A misunderstanding at the coordinator level cascades into every worker agent it instructs. The developer who thrives in this environment is the one who maintains the clearest shared context.
Phase Two: The Build Phase
Running Your Agent or Agent Army
Phase One is research and documentation. Phase Two is construction. And the construction phase has its own important sub-stages.
Setting Up the Environment
Before any agent runs a single line of code, three things need to be in place.
First, a dedicated project folder with a clear structure. Your coding agent needs to know exactly where it is working. This is not optional. Agents without clearly scoped workspaces create files in unexpected places, lose context between sessions, and produce the kind of ‘messy desk’ codebase that becomes impossible to debug.
Second, a GitHub repository — private or public, depending on your project. I connect my agents to this repository from the beginning. Every meaningful change gets pushed. Every session leaves a clean commit trail. Version control is not just good practice here; it is a recovery mechanism. When an agent makes a decision you disagree with, you need to be able to roll back cleanly. I have needed this more times than I would like to admit.
Third, API keys. If your application depends on external services — and most interesting AI applications do — gather all your keys before you start. This is also the moment to create your .env file: a plain-text configuration file that stores API keys, database credentials, and sensitive variables locally, outside your codebase. Your coding agents work with the .env file structure. They do not get the actual keys in the conversation. Sensitive credentials never live in your prompts or your commit history.
Choosing Your Agent Approach
There are three meaningful ways to run AI coding agents today, and the choice matters.
The simplest approach — multiple Claude Code sessions in separate terminal tabs — works, but each session is isolated. Each agent does not know what the others are doing. For experienced developers who can coordinate the sessions manually, this is a fast way to parallelize specific tasks. For anything more complex, it creates crossing processes and conflicting implementations.
Google’s Antigravity platform sits in the middle. Multiple agents working within the same project, with more awareness of a shared goal. More powerful than isolated terminal sessions, but still demanding in terms of manual coordination.
Augment Code’s Intent is, as I described in my previous article, something qualitatively different. You communicate with a lead orchestrator agent. You give it your project context, your blueprint, your architecture document. It writes a living spec, decomposes the work into discrete tasks, and delegates to worker agents — sometimes dozens of them simultaneously. The orchestrator manages the dependencies, the sequencing, and the synthesis. You manage the orchestrator.
The process I am describing in this article works with any of these approaches. The phases are the same. The quality of Phase One determines the quality of Phase Two regardless of which tool you use. But if you are building production-grade software and you want to move at the speed I described in my last piece, Intent or equivalent orchestration tools are where the real leverage lives.
The Debugging Sub-Phase — The Part Nobody Warns You About
I want to be direct about something that every practitioner learns the hard way: the debugging sub-phase of the build phase is currently the most exhausting and time-consuming part of the entire process.
Your agents will build features. Many of them will not work exactly as specified on the first attempt. Some will work in isolation but break when connected to other components. The front-end to back-end connection, in particular, is where things fall apart most reliably. An agent can run a thousand unit tests and confirm everything passes — and then the actual user interface will reveal a broken flow that no automated test caught.
I have spent significant effort over the past year trying to automate this phase through agentic browser testing. Tools like Claude in Chrome, and the integrated browsers in Antigravity and Intent, can navigate your application and report what they observe. But there are persistent challenges. Login walls — Google Auth, in particular — are difficult for agents to navigate repeatedly. Browser-based testing consumes tokens at a surprisingly high rate and is slow. And the information density an agent gets from a rendered browser is lower than you would expect.
What I have settled on as the most effective approach is a hybrid rhythm: I test manually in the application, describe what I observe to my coding agent in specific terms, the agent makes targeted fixes, I test again. This loop is faster than it sounds and significantly more efficient than full automated testing when you account for token cost and time.
If you are building an application with databases, live integrations, and real API dependencies, I also recommend this: build in production from the beginning, not just locally. Many applications behave differently in production than they do in local environments, particularly around database connections, authentication callbacks, environment variables, and API rate limits. The cost of debugging locally and then discovering production-specific issues is high. I debug once — in the environment where the application actually needs to work.
The most honest thing I can tell you about debugging with agents is this: it is still mostly manual. But it is manual work guided by the most capable tectechnical partner I have ever had.
Phase Three: Production and Deployment
Where Real Applications Are Born
The build phase produces working software. The production phase makes it real — publicly accessible, secure, version-controlled, and maintainable.
Connecting Agents to Production Infrastructure
My primary deployment infrastructure is Firebase, though the principles here apply equally to DigitalOcean, Vercel, Supabase, or whatever platform suits your project.
The key configuration step: give your agent scoped, project-specific access to your production environment — not master access. I connect my agent to a specific Firebase project by generating a project-scoped service account token in Google Cloud’s IAM settings. This is a step your LLM can guide you through in detail if you ask. The outcome is that your agent can deploy updates to exactly the project it should touch and nothing else.
I learned this lesson from experience. Early in my agent-assisted development journey, I had a worker agent deploy a new version of one application to an entirely different Firebase project because the default project in my CLI configuration was wrong. The application was overwritten. Everything was recoverable from GitHub — which is precisely why the GitHub discipline in Phase Two is non-negotiable. But it was a good reminder that agents are eager and exact: they do exactly what they are configured to do, including the mistakes.
GitHub as the Backbone
Throughout Phase Three, GitHub is not just version control. It is your deployment trigger, your backup system, and your rollback mechanism.
Some production platforms deploy directly from GitHub — DigitalOcean’s App Platform, for example, rebuilds and deploys automatically when you push to a specified branch. In this model, a push to GitHub is a push to production. Other platforms like Firebase require an explicit deployment command. I tell my agents to do both: push to GitHub and deploy to production in the same workflow. Two-step confirmation and a permanent record.
This also solves a problem that agent-based development creates: context continuity across sessions. Agents do not remember previous conversations. But GitHub commits do. A well-structured commit history tells any new agent session — or any human engineer — exactly what was built, when, and why.
Security Audits — Three Models, Three Perspectives
Before I consider any production application complete, I run security audits. And I run them with three different AI models.
Currently, my standard audit stack is Claude Opus 4.6, GPT-4.5, and Gemini 3.1 Pro. Each model has different training, different emphases, different blind spots. Running all three means I get the broadest possible coverage. I ask each one to audit the codebase for security vulnerabilities, specifically looking at authentication implementation, data validation, API key exposure risks, injection vulnerabilities, and any unprotected endpoints.
The findings are rarely identical. Each model surfaces different concerns. I compile the results, prioritise by severity, and then run an iteration cycle with my coding agent to address everything material before the application goes live.
This process has caught real issues every single time I have run it. It has never been wasted effort.
The three-audit approach is not perfectionism. It is professional practice. Each model sees things the others miss.
The Bigger Picture
I want to step back from the mechanics for a moment and say something about what this process actually represents.
When I started building with coding agents two years ago, I was a junior developer who used AI to assist with tasks. Today, I am a product architect who directs AI teams to build what I design. The shift is not subtle — it is a complete reorientation of how I approach product development.
Phase One used to be something I did informally, in my head, over weeks of half-formed thinking. Now it is a structured deliverable — a set of markdown documents that serve as the single source of truth for everything that follows. This discipline has made me a better architect because it forces clarity before commitment.
Phase Two used to mean writing code, testing it, writing more code. Now it means communicating precisely, reviewing agent output with architectural judgment, and maintaining the shared context that keeps the entire agent fleet aligned. The skill that matters is not coding speed. It is orchestration discipline.
Phase Three used to be the moment I handed off to a DevOps engineer or fought with deployment configurations alone. Now it is a structured security review and a systematic production handoff — still my responsibility, but supported by agents who can audit code more comprehensively than any single human reviewer.
The process I have described here has no hard ceiling. With this foundation, there are no limitations on what I can build. The complexity of the application does not change the phases — it scales them.
That is the point. Not to build faster, though that happens. Not to code less, though that happens too. The point is to expand what a single founder with architectural judgment and a well-directed agent team can actually bring into the world.
Two years in. Thousands of hours. These are the phases.
Start with context. Build with agents. Deploy with discipline.
Sources & Further Reading
Režun, T. (2026). From Writing Code to Directing Intelligence: Five Days Inside Augment Code’s Intent. Medium. https://medium.com/@talirezun/from-writing-code-to-directing-intelligence-five-days-inside-augment-codes-intent-7b04863808bf
Augment Code: Intent Documentation. docs.augmentcode.com/intent/overview
Karpathy, A. (2025). Software Is Changing (Again). karpathy.github.io
Osmani, A. (2025). The Future of Agentic Coding: From Conductors to Orchestrators. addyosmani.com
Anthropic (2024). Building Effective Agents. anthropic.com/research/building-effective-agents
Google Developers (2025). Build With Google Antigravity. developers.googleblog.com
Mason, M. (2026). AI Coding Agents in 2026: Coherence Through Orchestration. mikemason.ca
About the Author
Dr. Tali Režun is a Serial Entrepreneur, Business Developer, and Academic at the forefront of frontier technologies. As Vice Dean of Frontier Technologies at COTRUGLI Business School, he leads AI innovation initiatives and shapes MBA curricula for the next generation of technology leaders. With over 30 years of entrepreneurial experience — founding and scaling ventures including Lumina AI, Moj AI, Block Labs, CR Systems, 4thTech, Immu3, PollinationX, and Online Guerrilla — he bridges cutting-edge research in AI and Web3 with practical business transformation.
Tali’s Links
— https://talirezun.com/
— https://x.com/talirezun
— https://www.linkedin.com/in/talirezun
— https://www.researchgate.net/profile/Tali-Rezun
— https://luminawidget.xyz/
Disclaimer
Research and Educational Purpose
This article is published for research and educational purposes only. The content represents our personal experiences, observations, and analysis based on extensive hands-on experimentation with AI agent technologies over the past eighteen months.
No Commercial Relationships
We have not been compensated, sponsored, or otherwise financially supported by any of the companies, platforms, or tools mentioned in this article, including Augment Code, OpenAI, Google, or any other technology provider referenced herein. All opinions, assessments, and recommendations are my own and based solely on independent research and practical experience.
Individual Research Required
Readers are strongly encouraged to:
Conduct their own independent research before adopting any AI agent technology
Evaluate tools and platforms based on their specific use cases, requirements, and risk tolerance
Test systems thoroughly in controlled environments before production deployment
Consult with relevant technical, legal, and security professionals when implementing AI agents in business-critical or sensitive applications
Stay informed about evolving best practices, security considerations, and regulatory requirements
No Guarantees or Warranties
While I have made every effort to ensure accuracy based on my research and experience, I make no guarantees regarding the performance, reliability, security, or suitability of any AI agent technology for any particular purpose. Technology capabilities and limitations may vary significantly based on implementation details, use cases, and environmental factors.
Evolving Landscape
The AI agent ecosystem is developing rapidly. Tools, platforms, protocols, and best practices referenced in this article may be superseded, deprecated, or fundamentally changed by the time you read this. Always verify current capabilities and recommendations with primary sources and official documentation.
Your Responsibility
You are solely responsible for evaluating whether and how to implement AI technologies in your specific context. Consider your risk tolerance, regulatory requirements, security needs, and organizational capabilities before implementation.