The most useful thing AI has done for my development process this year is not making me faster at every stage. In some places it has made me deliberately slower, which sounds like a strange benefit until you are working through a problem that needs better thinking rather than more output.
It is very easy to use AI as a code vending machine. Ask for a function, paste the result, move on. I understand why that is tempting, especially when deadlines are tight and the task feels familiar. The problem is that development work rarely fails because a single function was difficult to write. It fails because the surrounding assumptions were wrong, the edge cases were not understood or nobody stopped to ask whether the feature should behave that way in the first place.
That is where I have found AI more useful. Not as a replacement for understanding, but as something that helps me test my understanding before I commit to a direction.
Using AI Before Writing The Code
The best place to use AI is often before the code exists. If I am planning a feature, I can describe the behaviour and ask what cases I might be missing. Sometimes the answer is obvious. Sometimes it surfaces something I had not considered, such as what happens when the user refreshes halfway through a process, when an API request fails or when the same component appears twice on a page.
That kind of conversation is useful because it changes the quality of the implementation. I am not asking AI to produce finished code. I am using it to create friction around the assumptions. That friction is valuable because it forces me to explain the feature more clearly.
I have also found it helpful when naming things. If I cannot describe a module clearly enough for an AI tool to understand what it should do, that usually tells me the module has not been thought through properly. The unclear prompt is often a symptom of unclear thinking.
Using AI To Review Decisions
Another useful habit is asking AI to argue against a technical decision. If I am considering adding a dependency, restructuring a component or changing a data model, I can ask for the reasons that decision might create problems later. I do not treat the answer as truth, but it gives me a useful checklist to think through.
This is particularly helpful on smaller projects where there may not be another developer immediately available to review the thinking. AI does not replace a proper code review, but it can help create a first pass of scrutiny before the work reaches someone else. That makes the later human review more focused.
The important part is that I still make the decision. AI can suggest risks, but it does not understand the business context unless I provide it. It does not know the client, the future maintenance plan or the constraints around the project. Those details matter more than a generic technical answer.
Where I Avoid Using It
I try not to use AI to skip learning something I will need to maintain. That is the dangerous part. If the generated code works but I cannot explain why it works, I have only moved the problem into the future. At some point, the code will need changing, and then the lack of understanding becomes expensive.
This matters with infrastructure, security, payments and anything that affects user data. I might use AI to help explore documentation or compare approaches, but I do not want to copy an answer into those areas without understanding it properly. The risk is not that AI is always wrong. The risk is that it can sound confident in places where I should be cautious.
I am also careful with code style. AI can produce code that is technically fine but inconsistent with the project. A codebase has its own habits, naming, structure and level of abstraction. Matching that matters because the next developer has to live with the result.
The Most Practical Use Case
The most practical use case for me has been turning messy thinking into something I can inspect. I can paste notes, describe a bug or outline a feature and ask for a structured view of the problem. That gives me a starting point, not a final answer. I can then challenge it, remove the parts that do not fit and keep the parts that help.
This has been useful in WordPress work, front-end behaviour, documentation and operational planning. In each case, the value is not that AI knows the perfect answer. The value is that it helps me see the problem from another angle quickly enough to improve my own thinking.
I think that distinction matters because it keeps the responsibility in the right place. AI can contribute to the process, but it should not own the judgement.
Retrospective Thoughts
The teams that use AI well are probably not going to be the ones that ask it to produce the most code. They will be the ones that use it to ask better questions, review assumptions and reduce avoidable mistakes before work becomes harder to change.
That is how I am trying to use it. Not as a shortcut around the work, but as a way to slow down at the points where rushing usually creates problems. Requirements, edge cases, naming, testing and documentation all benefit from a little more thought.
The strange part is that slowing down in those places often makes the project faster overall. Fewer wrong turns, fewer hidden assumptions and fewer bits of code that nobody fully understands. That feels like a better use of AI than simply producing more output.