AI Workflows at Work · Advanced

Lesson 8: AI for Developers — Where It Helps and Where It Hurts

Using models for real engineering work: scaffolding, debugging, review and tests, with a clear line around what to never trust.

By the AIVraj Editorial Team 8 min readLast updated July 24, 2026
What you will learn
  • Choose the right AI task for each part of your workflow
  • Prompt effectively with code context
  • Recognise the failure modes that cost the most time
In this lesson
  1. Where it clearly helps
  2. Where it clearly hurts
  3. Prompting with code
  4. Review and tests
  5. A working discipline

Where it clearly helps

Boilerplate and scaffolding. Translating between languages and framework versions. Explaining unfamiliar code and cryptic stack traces. Writing the tests and docstrings you were going to skip. Regexes and SQL you would otherwise reach for a reference to write. In each case verification is cheap: you run it, or you read it, and you know immediately.

Where it clearly hurts

Anything where verification is expensive. Concurrency, security-sensitive logic, migrations against production data, subtle floating-point or timezone behaviour, and any API released after the model's cutoff. The characteristic failure is not a syntax error — it is confident, plausible, idiomatic code that calls a method which has never existed.

Prompting with code

Give the model what a new colleague would need: the relevant file, the error text in full, the runtime and versions, and what you have already tried. Then state the constraint that matters — "no new dependencies", "keep it in the existing repository pattern", "must run on the edge runtime". Ask for the reasoning before the patch on anything non-trivial; it materially reduces plausible-but-wrong answers. Tools like AI Code Generator, Code Explainer and Bug Fixer ship with these instructions already in place.

Review and tests

The highest-value use is as a second reviewer, not a first author. Paste a diff and ask for edge cases, missing error handling and security concerns — framed as questions, not verdicts. Test generation is similarly strong, with one caveat: a model writing tests from your implementation will happily encode the bug as expected behaviour. Describe the intended behaviour instead of pasting the function.

A working discipline

  1. Never paste secrets, keys or customer data.
  2. Read every line before committing; generated code you have not read is technical debt with a delay fuse.
  3. Run it. Lint it. Type-check it.
  4. For anything security-relevant, assume the output is wrong until proven otherwise.
  5. Prefer small, reviewable generations over whole-file rewrites.

Practise with these tools

AI Code Generator

Generate code from spec

Code Explainer

Understand any code

AI Bug Fixer

Fix broken code

Regex Generator

Build regex from a description

Frequently asked questions

Should junior developers use AI?

Yes, with the rule that they must be able to explain every line they commit. Used as an explainer it accelerates learning; used as an autocomplete for code they cannot read, it stalls it.

Why does AI suggest methods that do not exist?

It generates plausible API shapes from patterns it has seen. Anything released after the training cutoff, or rarely used, is prime territory for invented methods — check the docs.

Next lesson
Lesson 9: Research and Analysis Without Hallucination
Continue
More reading: Learning Center · AI Glossary