I have been writing PHP for over a decade, and I resisted AI coding tools for the first year they were everywhere. Not because I thought they were useless, but because every demo I saw was someone generating a to-do app from scratch — which is nothing like the work I actually do. Two years in, AI tools have genuinely changed how I work, but almost none of the gains came from where I expected.
Where AI actually saves me time
The wins are boring, repetitive, and low-risk. That is the pattern. Here is where I get consistent value:
- Reading unfamiliar code. When I inherit a legacy WordPress plugin with a 900-line functions file and no comments, pasting a chunk in and asking "what does this actually do, and what breaks if I remove it?" saves me 30-40 minutes of tracing. I still verify, but I start from a map instead of a blank page.
- Boilerplate with a known shape. Custom post type registrations, REST route scaffolding, WP-CLI commands, migration scripts, PHPUnit test skeletons. These have a correct form I can recognise instantly, so reviewing the output is fast.
- Regex and SQL I would otherwise get wrong twice. A complex
preg_matchor a three-table join with a subquery used to cost me 20 minutes and two failed attempts. Now it costs three minutes plus a test run. - Translating between formats. A CSV column mapping, a JSON schema into a PHP array, an old jQuery snippet into vanilla JS. Mechanical work with a verifiable output.
- Writing the thing around the code. Commit messages, PR descriptions, changelog entries, docblocks, the client-facing summary of what changed. As an Associate Director I write more of this than actual code now, and it is where I save the most hours per week.
Notice what these have in common: I can tell within seconds whether the output is right. That is the real filter — not how complex the task is, but how fast I can verify the answer.
Where it costs me more time than it saves
I have lost entire afternoons to AI-generated code, so this list matters more than the first one.
Anything involving your specific business logic. The model does not know that your order_status field has a legacy value of 2 that means "refunded but shipped anyway" because of a bug in 2019. It will write clean, confident, wrong code. I now assume any generated function touching domain rules is a first draft that needs full review.
Debugging something you have not understood yet. If I do not know why a bug happens, asking AI to fix it usually produces a plausible patch that suppresses the symptom. I once accepted a suggested try/catch that silently swallowed a database write failure. It took two weeks and a client complaint to find. Now the rule is: understand first, then use AI to write the fix.
Framework and API specifics that move fast. Generated code for newer WordPress APIs, block editor internals, or any library that changed its interface recently is frequently a confident mix of two versions. Check the docs for anything that touches a versioned API.
Security-sensitive code. Nonce checks, capability checks, sanitisation, escaping, file upload handling. AI output here is often almost right — it will sanitise input but forget current_user_can(), or escape on output but miss one branch. I read every line of this myself, every time. An esc_html() that is missing on one of four echo statements is exactly the kind of thing that passes review when you are skimming.
The workflow that actually stuck
I went through three phases: ignoring the tools, over-trusting them, and finally landing on something sustainable. The version that stuck looks like this:
- Write the function signature and the docblock myself first. Naming the inputs, outputs and edge cases forces me to think through the problem. Then I let AI fill the body. This single habit improved output quality more than any prompt trick.
- Give it the surrounding context, not just the task. Paste the related class, the database schema, the coding standard you follow. Generic prompts get generic code that does not match your codebase.
- Ask for the approach before the code on anything non-trivial. "What are three ways to handle this queue processing, with tradeoffs?" is far more useful than "write a queue processor." I often use the reasoning and write the code myself.
- Never accept code you could not have written. If you cannot explain what a line does in review, you cannot maintain it at 2am when it breaks. This is the rule I enforce hardest with my team.
- Run it before you believe it. Obvious, but the fluency of the output creates a real psychological pull toward skipping the test.
Measure it, or you are just guessing
Everyone claims AI made them faster. Very few have checked. I tracked my own work for six weeks with a crude method: a note in my time log marking whether a task was AI-assisted, and how long it took versus my estimate.
The result was not the 10x anyone promises. Boilerplate and documentation tasks came in around 50-60% faster. Debugging and integration work was roughly flat — sometimes slower, because I would chase a wrong suggestion before backing out. Net across all my work, maybe 15-20% time saved, concentrated almost entirely in one category.
That number is worth having, because it changes how you deploy the tool. Fifteen percent overall is good. Believing it is 300% is how teams end up shipping code nobody understands and estimating projects they cannot deliver.
What changes when the whole team uses it
The individual productivity question is the easy one. The harder one, once you manage people, is what AI does to code review and to junior developers.
Two things I have seen consistently. First, review load goes up, not down. More code arrives, it looks polished, and reviewers skim it because it reads well. We addressed this by requiring the author to state in the PR description what they verified manually — it forces the check to happen before review, not during.
Second, juniors who lean on AI for problems they have not yet learned to solve plateau fast. They ship working features and cannot debug them. The guidance I give is simple: use it freely for things you have done before and find tedious, avoid it for things you are learning. That distinction protects the skill-building phase without banning a useful tool.
The takeaway
AI coding tools are a real productivity gain in a narrower band than the marketing suggests. They are excellent at the work where you can verify the answer instantly — boilerplate, translation, documentation, exploring unfamiliar code. They are actively risky where correctness depends on context they do not have, especially security and business logic.
Pick two or three tasks you do every week that are tedious and easy to check, use AI for those consistently for a month, and track the time. That is a far better use of your attention than another tool comparison thread. The developers getting real value are not the ones with the best prompts — they are the ones who know exactly which of their tasks to hand over.
