Making software with AI is easier. Continuing the work is another matter.
Describing an idea to AI and turning it into a program has become much easier than it used to be. You do not have to write every line from scratch, and you can read error messages together with an AI assistant to decide quickly what to try next.
But making a program once and being able to continue developing it anywhere are different things. If the development environment exists only on one laptop, you are unsure which folder contains the files, and there is no record of previous changes, continuing the work somewhere else becomes difficult.
The faster AI can write code, the more important the basics of source control and development environments seem to become. A tool that creates code and a process that lets you find, run, and maintain that code are not the same thing.
A conversation with someone who was vibe coding
Not long ago, I spoke with someone without an IT background who had already created several programs using AI. They explained that, without the laptop they normally used, they could not easily continue developing somewhere else.
I started by explaining how to keep source code on GitHub. You can clone a repository into another development environment and inspect its change history. That matters more than simply copying files between computers, because you can choose which recorded state to continue from.
They had not known about version control. That conversation reminded me that being good at prompting an AI tool is not enough. A sustainable process also requires managing source code, recreating an environment, and verifying the published result.
Why I use Git and GitHub
Git does more than preserve the latest version of a file. It records differences, allows inspection of earlier states, and helps carry work into another environment. GitHub provides remote storage and access to the repository.
However, cloning code from GitHub does not automatically recreate the development environment. After cloning, you still need to check the Node.js version, dependencies, environment variables, run commands, and deployment connections. Moving code and reconstructing the environment are different steps.
Knowing that changes the question from "Can I develop without that laptop?" to "Where will I clone the repository, and what will I need to prepare again?"
When a working feature suddenly stops: tracing changes with Git
There is another reason I value version control in vibe coding. Sometimes I ask AI to add a feature or change existing code, only for something that worked before to stop working. Carefully documenting principles and work instructions in Markdown can reduce mistakes but cannot eliminate them.
If Git history has been kept, I can locate a previously working commit and compare it with the current code. Examining which files and lines changed helps narrow down the cause and, when necessary, restore earlier code.
Instead of repeatedly telling AI to "fix the bug," I can investigate what changed since the known-good state.
Version control is therefore not only a method of saving code. It is also a way to manage trial and error and recover from mistakes when building with AI. The important condition is that a working state must actually have been committed if I want to compare or restore it accurately.
The ONSEMO development environment I set up
The overall workflow for ONSEMO can be shown in one diagram.
Windows → WSL2 Ubuntu → Codex → GitHub → Cloudflare → ONSEMO services
Windows is my everyday operating system, while the development work takes place inside WSL2 Ubuntu. I use Codex, Node.js, and Git there, then push the changes to GitHub. Cloudflare picks up the Git changes and updates the public website through its connected build and deployment process.
When moving to another environment, I clone the GitHub repository, prepare the required tools and dependencies, and rerun the local build and tests. That can take longer than simply copying files, but it makes the source and current state easier to verify.
After I established this system, my WSL2 development environment was interrupted by an out-of-memory event. That eventually led me to set up a separate Codex Cloud development environment. It highlighted the difference between remotely controlling an existing PC and being able to develop without that PC at all.
Why I chose WSL2 Ubuntu instead of working directly in Windows
I did not want to give an AI coding tool broad access to every file on my Windows PC. I wanted a clearer division between development files and personal files.
That led me to organize development around WSL2 Ubuntu. Keeping project files inside WSL2 makes it easier to define the working area, inspect permissions, and intentionally limit which directories are needed.
On one occasion I placed a development file in my Windows Downloads directory and asked Codex to retrieve it. Access was blocked in that particular environment.
But it would be a mistake to treat WSL2 as complete security isolation. Windows and Linux filesystems can be connected, and the accessible paths depend on mounts, settings, and permissions. WSL2 helps organize a development boundary; it is not a security product that automatically removes every risk.
Developing remotely with Codex Remote
In OpenAI's description, Codex Remote uses a phone more like a control surface for development work. You can initiate work, adjust its direction, and inspect changes running on a connected development host. OpenAI's introduction to Codex Remote.
That is not the same function as GitHub. GitHub keeps source code in a repository that other environments can clone. Codex Remote lets you direct work on a connected host. It does not automatically move source code to another computer; the host, its permissions, power, and network connection remain prerequisites.
So I think about the two tools separately. I use Remote when I want to continue guiding an existing Windows/WSL2 session away from my desk, and GitHub cloning when I want to work independently in a different environment.
In actual Remote use, repetitive approval prompts sometimes interrupted development. Auto-review reduced those interruptions, although Android tests still needed attention. I documented the approval policy change and the later improvement to the Android verification process in separate Knowledge articles.
Related readingWhen Codex Keeps Stopping for ApprovalHow Codex Auto-review reduced repeated approval interruptions in remote development, and why approval policies are different from sandbox permissions.
Related readingAutomating Codex Android Checks Without Always ApproveA real Android Gradle troubleshooting case: move caches inside the workspace, scope tests to Debug, and use a project verification script instead of broad approval rules.
Automatically deploying websites with GitHub and Cloudflare
After finishing work, I build locally first. I check that existing routes still work, content and links are correct, and optional features such as APIs do not prevent the main page from being displayed.
Pushing verified changes to GitHub triggers a build through Cloudflare's Git integration and updates the public site. Rather than issuing a manual deployment command, I use Git both for change history and as the deployment trigger.
Once deployment finishes, the final check takes place on the public URL.
This completes the loop beyond "AI wrote some code": review the change, validate it, publish it, and confirm what visitors actually receive.
What an annual cost of $10.46 really means
At the time described here, the direct annual cost of my personal domain was $10.46. That number represented the domain registration cost alone, not the total cost of development or operating the services.
Some costs, such as a custom domain, may be unavoidable when publishing a small service. But a price only helps other people evaluate an approach when the inclusions and exclusions are clear.
Why basic IT knowledge still matters in the AI era
AI can help enormously with writing and explaining code. But a human still has to decide which files may be accessed, where code is stored, what another environment needs installed, and how to verify a public deployment.
When AI-generated work becomes an actual service, boundaries matter more than one successful command: separating personal files from project files, reviewing Git changes, watching for information that must not be published, and preserving a path back to a working state.
To me, basic IT literacy in the AI era is not just the ability to write lots of code personally. It includes understanding how files, permissions, operating systems, Git, deployments, public URLs, and verification fit together.
If I want to keep making small programs, I first need an environment in which that work can continue. Keep source code in Git, document how to recreate the development setup, and publish through a process whose results can be verified. That is the most practical conclusion I have drawn from this experience.