PhpStorm got us into AI without giving up the review

We have written and maintained PHP sites in PhpStorm for a long time. The IDE is where the code lives: the files, the debugger, the terminal, the git tool window. When we talk about "working on the site", we mean opening the project in PhpStorm and staying there. Chat windows came later. They never replaced that place.

This is a plain account of how we added AI without moving the review after the push. There are no growth charts. We have a rule against quoting numbers we haven't measured, and it applies here too.

AI arrived inside the editor

The first AI that stuck for us was the kind that proposes a change where the developer already works. GitHub Copilot, Junie and JetBrains AI sit in the same window as the file. You see a suggestion, you accept or reject it, and the diff stays on the machine. Nothing has left yet. That matters more than which brand of assistant is talking.

For a team that already lives in PhpStorm, that was a natural step. We did not have to invent a new place to write code. We added help inside the place we trusted.

The guardrail

The rule we were willing to keep is simple: nothing leaves the machine until a person has seen the change. A suggestion can fill in a method, rename a symbol or draft a test. A person still reads the diff before the commit, and again before the push. That is the AI-era transition we accepted.

It is slower than letting a bot open a remote branch and push while we look later. It is also why developers on the team will use the tools. They keep ownership of what goes into the repository.

Why not cloud-agent-first for day-to-day code

Cloud agents are useful for some jobs, and our developers have a clear line on which ones. Building a big or complex feature, or laying the base of a new one, stays in the IDE with the AI assistant, because it needs a developer's full attention. Once that base exists, extending it is a different job. Our country settings are a good example: we build the base code and the process for one country by hand, and adding another country on top of it can then be handed entirely to a cloud agent, because the pattern is already in the codebase.

So the split is not "cloud agents never". It is: the developer builds the foundation in the IDE, and a cloud agent can repeat a pattern that already exists. What we do not do is make "implement remotely and push a branch" the default for new or complex PHP work.

The difference is when the review happens. A cloud agent that implements on a remote machine and pushes a branch means the human review comes after the push. In PhpStorm with in-editor AI, the human review comes before anything leaves. For the developers who maintain our PHP sites every day, review-before-push is the habit they already had. Asking them to give that up so an agent can go first was a non-starter.

This is not a claim that one product is better than another. It is a claim about when a person looks at the diff.

Two tool families, two jobs

We run more than one kind of AI work, and we match the tool to the job.

I use Grok Bot every day for the business and admin fleet: drafts, checks, routines, the Monday report that only surfaces what needs a person. Grok Bot runs on Cursor. That is how we keep several long-running sites maintained without turning every morning into a pile of manual tasks. I wrote more about that setup at https://netprojects.com/insights/how-we-run-netprojects-with-ai-agents.

Most of our developers are on PhpStorm. For them, PhpStorm plus in-editor AI (GitHub Copilot, Junie and JetBrains AI) is how code ships on the PHP sites. The assistant proposes; the developer reviews; the commit and push stay human. Project instructions keep the assistants on our stack and conventions, but they do not replace the person on the diff.

We also experiment with new tools as they appear, including from OpenAI, Anthropic and Cloudflare. The mix changes. What stays fixed is the habit: business agents for business work, the IDE for day-to-day code, and a person on the diff before anything is pushed.

What we write down

Assistants drift unless you tell them how the project works. So we write project instructions: the stack, naming, how we structure PHP, what not to invent. That keeps suggestions closer to the code we already have.

Writing it down does not mean we stop reading. A good instruction file reduces noise. It does not sign off a commit. A person still opens the diff, checks assumptions, and decides what goes in.

The same habit shows up in the business fleet: drafts by default, people decide. On the code side it looks like: suggest in the editor, review on the machine, then push.

What we'd tell another team

If your team already trusts an IDE, stay there. Add AI where the developer already works. Keep a human on the diff before anything leaves the machine.

Do not force a cloud push-first workflow on developers who will not accept review-after-push as the default. Build complex features and the base of new ones in the IDE, with the developer's attention on them. Once that base is in place, hand repeatable extensions of it to a cloud agent. Use in-editor AI for the daily work. Keep business agents on business work, and coding tools on code.

Write the project conventions down once so assistants stay on the stack. Then still review. The gate is the person, not the model.

That is how we got into AI without giving up the review: PhpStorm for the PHP work we already knew, assistants in the same window, and nothing pushed until someone has looked.

Alex Michalas is the founder and director of Internet Projects Ltd, which trades as NetProjects. You can read more about how we use AI at https://netprojects.com/standards/ai, and how we run the business fleet at https://netprojects.com/insights/how-we-run-netprojects-with-ai-agents.