When AI Became Another Pair Of Hands

The first time I used AI properly during development, I did not treat it like a replacement for writing code.

I treated it more like another pair of hands sitting next to me. Useful, fast, occasionally impressive and still very capable of misunderstanding the job. That distinction mattered because it changed what I trusted it with. I was comfortable asking it to explore options, explain an unfamiliar API or draft a first version of something repetitive. I was not comfortable letting it make final decisions without checking the result myself.

In 2023 that feels like the sensible place to start. AI tools have become difficult to ignore, especially for developers, but the useful question is not whether they can write code. The useful question is where they genuinely help the work and where they introduce another kind of risk.

Using It At The Messy Beginning

The place I found AI most helpful was the early messy part of a task. Sometimes I knew roughly what I wanted but had not yet shaped the solution. Asking the tool to sketch a few approaches could help me see the problem from different angles. Not because the first answer was always right, but because it gave me something to react to.

That is very different from copying a finished answer into a project. When I use AI at the beginning, I am still making the decisions. I am asking better questions, removing the poor suggestions and keeping the parts that fit the project. The value is speed of exploration rather than authority.

I also found it useful for documentation-style work. If I had a function, a build step or a small internal tool, AI could help draft an explanation that I could then rewrite in my own words. That saved time, but only when I already understood the thing being documented. If I did not understand it, the generated explanation could sound confident while still being wrong.

The Code Still Needed To Be Owned

The most important rule I set for myself was that any code I used still belonged to me once it entered the project. I could not blame the tool later if something broke. That meant reading the output carefully, testing it properly and adjusting it to match the conventions of the codebase.

This was especially important in WordPress and JavaScript work, where there are often several ways to solve the same problem. AI might produce code that works in isolation but does not fit the theme structure, security requirements or long-term maintenance of the project. A working snippet is not the same thing as a good implementation.

// A generated idea is only a starting point.
// The project still needs its own checks, naming, escaping, testing and context.

function handleToggle(button) {
  const targetId = button.getAttribute('aria-controls');
  const target = document.getElementById(targetId);

  if (!target) {
    return;
  }

  const isExpanded = button.getAttribute('aria-expanded') === 'true';

  button.setAttribute('aria-expanded', String(!isExpanded));
  target.hidden = isExpanded;
}

That kind of code still needs the same questions I would ask if I had written it from scratch. Does it handle missing elements? Does it preserve accessibility attributes? Does it match the browser support for the project? Will someone else understand it later?

Where I Found It Less Useful

AI was less useful when the problem depended heavily on the exact state of a project. It could not see the full build unless I gave it the relevant context, and even then it did not have the same understanding I had from living with the codebase. It might suggest a clean answer that ignored a constraint I knew existed because of a plugin, a client requirement or an older part of the system.

I also became careful with anything involving security, payments, personal data or production infrastructure. In those areas, a plausible answer is not enough. The work needs documentation, review and proper testing. AI can still help ask questions or produce a checklist, but it should not become the source of truth.

The danger is not that the tool is useless. The danger is that it can sound useful even when it is wrong. That means the developer using it needs enough experience to challenge it.

How It Changed My Workflow

The main change was that I started using AI for momentum. It helped me get past blank-page moments, turn rough thoughts into a first draft and compare different ways of approaching a technical problem. It also helped with small translation tasks between languages and libraries, particularly when I knew the concept but wanted a reminder of the syntax.

I still needed to slow down at the point of implementation. The generated answer might speed up the start, but the final code still had to pass through the same judgement as everything else. That balance made the tool feel genuinely useful without letting it lower the standard of the work.

Retrospective Thoughts

I think AI has become part of the development environment in 2023, but I do not think it removes the need for experienced decision-making. If anything, it makes that judgement more important. The easier it becomes to generate code, the more important it becomes to understand whether the code should exist.

That is the way I am trying to use it. Another pair of hands, not another brain to outsource responsibility to. Helpful when directed well, risky when trusted blindly and most valuable when the person using it still owns the outcome.