What AI is useful for

As a developer, I think there’s no better time to get into AI than now.

It’s not a fad. People already use it every day at work. And you’re not late either. Most developers are still figuring this out. You’re early.

Writing code with AI, or with AI helping you, is how programming works now. Many people say AI gets in the way. Usually that’s because they hit the first roadblock and gave up. This course is here to help you get past that roadblock.

What you can do with it

Here are some of the ways I use AI as a developer:

• start a project from scratch
• work on an existing project
• add tests and documentation
• fix bugs
• refactor code
• bump dependencies on an old project I haven’t touched in years

That’s a short list. The real one is much longer.

AI works best when the task has many possible answers and you can check the result. Renaming a function is low risk. You read the diff, you run the tests, done. Asking it whether a strange medical symptom is harmless is a different story. A wrong answer costs a lot more.

Three questions I ask first

Before I hand something to AI, I ask myself:

• Can I describe the result I want?
• Can I give it the information it needs?
• Can I check whether the result is correct?

If all three are yes, AI is a good fit. If I can’t verify the output, it can still help me explore. But it should not make the final call.

Four kinds of work

Transformation changes something you already have. A summary, a translation, a refactor, a different data format. You have the original to compare against.

Generation creates a first draft. Code, docs, test cases, emails, plans. Treat it as raw material, not finished work.

Exploration shows you options. Ask for three database designs, or the likely causes of an error, or questions you haven’t considered. The value is in seeing more of the map.

Review looks for problems. A model can read a diff, challenge an assumption, or suggest edge cases. It’s a useful extra reviewer. It can’t prove nothing is wrong.

Where it’s a poor fit

Be careful when the task needs a guaranteed fact, private data you can’t share, a final decision with serious consequences, or an action that’s hard to undo. A fluent answer can still be invented, outdated, or built on a misunderstood requirement.

And sometimes doing the work yourself is faster than explaining it and checking it. A two-line edit doesn’t need a conversation.

Take one task from your current project. Which of the four kinds is it? Then write down how you’d check the result. If you can’t name a check, make the task smaller until you can.