There is a significant difference between using AI to help you code and using AI that actually understands your codebase.
A familiar way to code with AI is to paste snippets into browser chat, ask for a change, copy the output back into an editor, and repeat when something does not fit.
I used to work that way too.
When I first started coding with AI, I would literally copy code into chat, ask for a fix, paste it back into my project, then go back and forth again when the result did not fully fit. It worked, but it was slow, disconnected, and frustrating.
What changed the experience for me was letting the agent work with the project itself.
I use Codex for the majority of my coding projects. Having it work with the local project files means I can keep iterating without pasting the same file structure and code back into a conversation. An editor such as VS Code can be part of that environment; the key is access to the actual project.
Once you work this way, it feels like your project suddenly has a face. You are not just prompting a chatbot. You are interacting with the code itself through an intelligent layer that can read, reason, and make changes with you.
That shift changes everything.
Why Browser Chat Falls Short
Browser chat is fine for quick questions, rough ideas, or isolated code snippets.
But serious development work usually depends on context:
- How files connect to each other
- What patterns already exist in the project
- Which dependencies are involved
- How configuration affects behavior
- What tests or adjacent components might break
Without that context, the agent has more room to make assumptions that do not fit the project.
That is why browser-chat coding often produces code that looks right at first glance but creates extra cleanup work later.
The Better Workflow
Here is the workflow I recommend and use.
First: Get the Access and Data Ready
Before asking the agent to build, I connect GitHub authentication, configure the service credentials the project needs, and identify the relevant data sources. If a feature depends on an API, the environment needs a working connection to that API.
That setup is square one for me. Give the agent a clear project folder, explain which systems it can use, and make sure it has the permissions required for the task. Keep secret values in the environment or a secret store rather than in prompts or committed files.
An API key provides access to a service; it does not explain the data. The agent also needs context about what the data represents and how the project should use it.
Phase 1: Start Where Your Skill Level Makes Sense
If you are newer to coding, tools like Lovable or Replit can still be helpful. They lower setup friction and can help you get an app off the ground before pushing it to GitHub.
That said, this is where the landscape has changed fast.
If you already understand code and can work comfortably in a real project, you can often skip that layer entirely. With tools like Codex or Claude, you can start from the ground up directly from prompt, generate the initial structure, and begin building in a real development environment right away.
The best starting environment is the one you can understand, inspect, and test. You can move between a hosted prototype and a local project as your needs develop.
Phase 2: Push to GitHub
Once the prototype is viable, push it to a GitHub repository. This does two things:
- Creates a permanent, versioned history of your work
- Makes it cloneable to any local environment
git init -b main
# Review .gitignore and stage only the intended project files.
git add README.md src package.json package-lock.json
git commit -m "Initial prototype"
git remote add origin https://github.com/yourname/your-project.git
git push -u origin main
Phase 3: Clone or Open the Project Locally
If the project is on GitHub, clone the repository to your machine, then open that project folder in VS Code. In VS Code, you can use Git: Clone from the Command Palette, supply the repository URL, choose a local location, and open the resulting folder. The VS Code repository documentation walks through that process.
Cloning copies the project and its Git history to your machine. VS Code is the editor you can use to work with that copy.
If you prefer the terminal, the same starting point looks like this. The code . command requires VS Code's command-line launcher to be installed:
git clone https://github.com/yourname/your-project.git
cd your-project
code .
If the project is already on your machine, open its existing folder. If you are starting something new, create a project folder and begin there. GitHub is useful for version history and review, but you do not need to clone a repository before you can start a local project.
Phase 4: Connect a Real Coding Agent
This is the step that changes the experience completely.
There are two practical ways to start:
- Work inside VS Code. Open the project folder and use a coding-agent extension, such as Codex or Claude Code, within that workspace. The agent can work with the relevant project files while you inspect the code and changes in your editor.
- Work directly in Codex or Claude Code. Select the local project folder in the application's coding environment, or start its command-line agent from that folder. VS Code can still be your editor, but it is not required for this route. Claude Code's desktop documentation describes choosing a local folder; the official OpenAI documentation explains local project access and how the Codex CLI and IDE use the project directory.
For me, the essential step is connecting the folder I am actually developing. Once the agent has access to that project, I explain the goal and start iterating against the files. A useful opening request is: "Read the README and relevant project instructions, explain how this app is organized, and identify the files involved in the feature I want to build."
The difference from browser-based AI is profound. The model is no longer limited to the code you pasted into a chat window. It can work with the actual project.
When you ask it to "fix the authentication bug in the middleware," it can read:
- The middleware file
- The files that import it
- The configuration that affects it
- Related tests
With Codex in particular, you can add project folders directly from your local machine, let it inspect the codebase, and have it make changes inside the actual files. That makes the interaction feel much more natural. You are no longer copying fragments back and forth. You are working with an agent that can see what you are seeing.
That is a big reason I like Codex so much. It feels practical. It feels close to the work. The main benefit for me is continuity: I can keep working through a feature with the agent against the same project.
Phase 5: Develop With Full Context
Once the model is connected to your codebase, development becomes a much more efficient conversation. You can ask:
- "What's the best place to add rate limiting to this API?"
- "Refactor this component to use the pattern established in UserCard.tsx"
- "Write tests for this function following the existing test conventions"
- "Find the bug, make the fix, and explain what changed"
These questions depend on project context. Access to the files lets the agent inspect what matters, although I still need to explain the goal and correct misunderstandings.
Phase 6: Test Locally and Review in GitHub
Whatever I am developing, I keep it open locally and test the features myself. I interact with the product rather than relying only on the agent's report that the change is finished.
Once it looks right, I push the changes to that project's repository and review them there. Relevant automated checks add another layer of evidence, but they do not replace using the feature. That combination—iteration with the agent, local testing, and repository review—is my actual workflow.
Why This Matters
For me, the benefit grows as I keep working in the same project: less time reconstructing context and more time improving the result.
A coding agent that knows your file structure, naming conventions, architecture, and existing patterns gives you output that actually fits the project.
Project access gives the agent a way to ground its suggestions in the files and conventions already there. I still review the result, because context improves the starting point without guaranteeing correctness.
And beyond speed, it changes the way coding feels. Instead of manually dragging code in and out of a chat window, you are interacting with the project directly through an intelligent interface. That makes development more efficient, more fluid, and far more practical for real work. For me personally, Codex stands out because it lets you work directly against local project folders in a way that feels especially natural once you get used to it.
The workflow starts with access and data, continues through iteration against real files, and ends with local testing and review in the repository.
Once you do that, it is very hard to go back.