AI & Productivity

Using AI Coding Assistants Without Losing Your Fundamentals

AI coding assistants can make you faster or make you fragile. Here is how I use them day to day, and the habits that keep your own skills sharp while you do.

Benjamin Amoako (ProfJero) · 5 min read

I use AI coding assistants every week. They help me scaffold components, write tests, explain unfamiliar code and think through bugs. Pretending they don't exist, or telling my students not to touch them, would be bad advice.

But I have also watched something worrying happen. A learner builds an impressive-looking app in a weekend with heavy AI help. Then something breaks — a small thing, like a missing await or a wrong field name — and they are completely stuck. They cannot read the code, because they never really wrote it.

AI can make you faster or it can make you fragile. The difference is not the tool. It is how you use it.

The core principle: you are still the engineer

An AI assistant is like a very fast junior colleague who has read a lot of code but does not know your project, your users or your constraints. It is often right. It is sometimes confidently wrong. It can invent functions that don't exist, use outdated APIs, or quietly introduce a security hole.

So the rule I follow, and the rule I teach, is simple:

Never ship code you cannot explain line by line.

If you can't explain it, you don't own it. And if you don't own it, you can't maintain it, debug it, or defend it in an interview.

Where AI genuinely helps

Here is where I find assistants most valuable:

  • Boilerplate and repetition: form handlers, config files, repetitive CRUD functions, data transformations
  • Explaining code: "Walk me through what this regex does" or "Why does this function return undefined?"
  • First drafts of tests: generating test cases, including edge cases I might forget
  • Rubber-duck debugging: describing a bug in words often reveals the answer, and the assistant can suggest places to look
  • Learning a new library: asking for a minimal example, then checking it against the official documentation
  • Refactoring suggestions: "How could this function be simpler?"
  • Writing documentation: README sections, comments, commit message drafts

Where you need to be careful

  • Security-sensitive code: authentication, authorization, database rules, payment logic, anything handling personal data. Review this with extra care, and check it against trusted sources.
  • Library versions and APIs: assistants may suggest methods from older versions. Check the docs.
  • Architecture decisions: AI can list options, but it does not know your budget, team, users or internet conditions. You do.
  • Anything you are learning for the first time: if the goal is to learn, letting AI do it for you defeats the purpose.

A practical workflow that keeps you sharp

This is the workflow I use and recommend.

1. Think before you prompt

Before asking the assistant anything, spend two minutes writing down what you want: inputs, outputs, edge cases. This keeps you doing the design thinking. It also produces a much better prompt.

2. Ask for small pieces, not whole apps

"Build me a complete inventory system" gives you a large blob of code you don't understand. "Write a function that takes a list of products and returns those with stock below their reorder level" gives you something you can read, test and integrate.

3. Read, run, and question

When the assistant gives you code:

  1. Read every line. If anything is unclear, ask it to explain.
  2. Run it with normal input, then with strange input (empty lists, missing fields, very large numbers).
  3. Ask: "What could go wrong with this code?" or "What are the security risks here?"

4. Rewrite in your own style

Rename variables so they match your project. Remove what you don't need. Simplify. When you reshape code, you understand it.

5. Verify against real sources

Check unfamiliar functions in the official documentation. If the assistant says "this method does X," confirm it. This takes a minute and has saved me hours.

An example: reviewing AI output

Suppose you ask for a function to search products by name, and you get this:

js
function searchProducts(products, term) {
  return products.filter(p => p.name.includes(term));
}

It looks fine. But ask yourself a few questions:

  • What happens if term has different capitalisation? "panadol" will not match "Panadol".
  • What if a product has no name? This will throw an error.
  • What about extra spaces in the search box?

A more robust version:

js
function searchProducts(products, term) {
  const query = term.trim().toLowerCase();
  if (!query) return products;
  return products.filter(p =>
    (p.name ?? "").toLowerCase().includes(query)
  );
}

The AI wasn't "wrong" — it just didn't know your real users. Those questions come from experience with real data, and that is exactly the skill you must keep building.

Deliberate practice: protect your fundamentals

To make sure AI is not quietly eroding your skills, build some "no-AI" time into your week:

  • Write some code from scratch. Small exercises: array manipulation, DOM updates, a simple API route.
  • Debug first, ask later. Give yourself fifteen or twenty minutes with the browser dev tools, console.log and the error message before asking for help.
  • Explain your code to someone else. If you train or mentor others, as I do, you will quickly discover what you don't actually understand.
  • Read documentation directly. It builds the mental map that helps you judge AI answers.
  • Rebuild something you generated. Take a component an assistant wrote and rewrite it yourself without looking.

For beginners specifically

If you are in your first year of learning, my advice is to use AI mainly as a tutor, not as a ghostwriter. Good prompts for learning look like this:

  • "Explain this error message in simple terms and suggest where I should look — don't fix it for me."
  • "Give me a hint, not the answer."
  • "Review my function and tell me what could be improved, and why."
  • "Quiz me on JavaScript promises with five questions."

Used this way, AI can be one of the best learning tools we have ever had — especially for learners who don't have a mentor nearby.

A quick self-check

  • Can I explain every line of the code I shipped this week?
  • Did I verify unfamiliar APIs against the official docs?
  • Did I test edge cases, not just the happy path?
  • Did I review security-sensitive code with extra care?
  • Did I write at least some code without assistance this week?

If you can answer "yes" to most of these, you are using AI well.

Conclusion

AI assistants are not going away, and they shouldn't. They can remove a lot of tedious work and help you learn faster. But your value as a developer is your judgement: knowing what to build, spotting what's wrong, and understanding why. Protect that, and AI becomes a multiplier rather than a crutch.

How are you using AI in your coding right now — tutor, assistant, or ghostwriter? Share your workflow in the comments; I'd love to learn from yours too.

0 comments 0 views
Benjamin Amoako

Written by Benjamin Amoako (ProfJero)

Full-stack developer and IT trainer from Cape Coast, Ghana. Co-Founder of Digital Bridge Initiative and Founder of ProfJero Hub. I write about building real software and growing in tech.

0 Comments

0/2000