A working function answers a small question: can this be done? Building useful software means answering a much bigger one: should it work this way?
Think about adding a search box to a product. The visible work is an input, a query, and a list of results. The less visible work is deciding what “relevant” means, what a user is allowed to see, how quickly the results need to arrive, and what happens when the service is unavailable.
An AI tool can help with all of that. But someone still has to supply the context, make the tradeoffs, and decide whether the result is good enough to ship. Generating an answer does not settle those decisions.
The specification is part of the work
Before you ask a tool to build something, write down the problem in plain language. Who has it? What do they do today? What would a better outcome look like? Which constraints are real, and which are habits?
That exercise often changes what you build. Sometimes it makes the implementation smaller. Sometimes it reveals that the proposed feature is solving the wrong problem.
The useful question is not only “Can I make this?” It is “What would make this worth making?”
Review the decision, then the code
Code review should include more than style and syntax. Check the assumptions. Look for missing authorization checks, ambiguous failure behavior, and inputs the happy path never touches. Ask what the change will cost to operate and maintain.
If you cannot explain why an implementation is appropriate, running it successfully once is weak evidence. Trace it. Test a boundary. Compare it with a simpler alternative.
A small exercise for your next project
Write a short decision note before building: the problem, two possible approaches, the reason for your choice, and one condition that would make you reconsider. After the implementation, revisit that note.
Use AI to speed up exploration and challenge your assumptions. Keep practicing the judgment that connects an implementation to a real need. That judgment has always been part of software engineering.