#008: AI assisted or Plagarism?
AI-assisted development has quickly become one of the most common tools in modern software engineering. More and more, it has been seen that people use coding assistants to explain unfamiliar code, suggest implementations, write tests, and help track down bugs. Sometimes, it almost feels like all the skill has been taken out of programming.
But a warning is important here: an AI assistant is not a Rare Candy that instantly gives you all the experience you need. It can produce code quickly, but it does not automatically understand the real goal, the constraints of the project, or the consequences of a wrong decision.
Someone still has to provide the right context, review the result, ask useful questions, and take responsibility for what gets shipped. Without human oversight, AI can quite easily turn into a self iterating and widely spreading piece of junk code, all from just a single error.
Nonetheless, the landscape is changing, and this change is the most visible during the interview process. If a tool can generate a familiar algorithm in a few seconds, then memorizing syntax becomes less important than understanding the problem.
Recruiters have started to test candidates on how they use their tools, similar to how stenographers became the benchmark in 1880’s replacing manual handwritten shorthand as it evolved after the invention of the first practical shorthand typewriter.
Interviews increasingly ask whether someone can break down an unfamiliar task, explain trade-offs, and debug imperfect code rather than thinking up everything from scratch. In settings where AI assistance is allowed, candidates may also need to demonstrate how they use it rather than relying on it to write everything from scratch. As with everything, there are trade-offs with this approach, but I will not be going into detail about that here.
Instead, I would rather emphasize that this shift does not mean that the fundamentals are no longer useful. In fact, I believe that they matter even more! You cannot properly review code if you do not understand the language, the algorithms, or the system it is supposed to support.
An AI-generated code can look polished while still being inefficient, insecure, or completely incompatible with the rest of the project. At the same time, AI systems generate likely responses based on patterns in their training, which means they can sometimes produce familiar or previously seen material.
If care is not taken, generated output can resemble someone else’s work or include material that was not properly authorized for reuse. That is why it is important to understand the role AI plays in your work and to review what it produces.
I do not want an assistant that simply agrees with every idea I have and tries to implement all of them, spreading its effort thin like a shotgun blast at a distance. Instead, I want a tool that helps me explore possibilities while still leaving me responsible for the final decision.
The best workflow is not asking AI to play the whole game for me; it is using AI to train more effectively while I remain the one holding the controller.
The speed that AI offers is useful, but speed without judgment can create a much larger problem later. Without careful review, development can turn into a loop of accepting, testing, and correcting AI-generated output. Even worse, a small error can spread through the codebase before anyone notices it…
For me, the strongest engineer in this changing landscape will not be the person who refuses to use AI or the person who accepts every suggestion without question. It will be the person who can combine strong fundamentals with good tools, and the speed of a machine with the correctness afforded by human oversight.
The battle is changing. The goal is no longer just to prove that you can perform every move from memory. It is to show that you understand the matchups, know when to use your Terastallization, and can still win when the opponent runs a full Metronome team.