daBongo LMS AI Training Courses

← Back to Course

AI Fluency for Builders – Problem to Shipped Solution

Lesson 4: AI in Development and Testing Workflows

Lesson Objectives

By the end of this lesson, students should be able to:

  • Apply the AI coding collaboration pattern to development work
  • Identify code categories that require heightened review
  • Use AI to produce tests that test behavior rather than implementation
  • Maintain code ownership by understanding AI-generated code before committing it

Lesson Content

AI coding as collaboration, not vending machine.

The biggest mistake builders make with AI coding tools is treating them as vending machines: describe the output you want, accept the code, move on. This produces code you do not understand, cannot debug, and cannot maintain. The right model is collaboration: you provide context and intent, AI generates a first implementation, you review and understand it thoroughly, then you refine.

The collaboration loop:

  1. Describe the behavior you want (not the implementation – the behavior)
  2. Review the generated code: do you understand every line?
  3. If no: ask Claude to explain the parts you do not understand before accepting them
  4. If yes: evaluate whether the implementation is appropriate for your context
  5. Test before committing

Code categories requiring heightened review.

Not all AI-generated code is equally risky. Heightened review for:

  • Security-sensitive code: Authentication, authorization, input validation, cryptography – common vulnerability patterns are well-represented in training data (on both sides of the security/insecure fence)
  • Performance-critical paths: AI generates working code, not necessarily optimal code for your specific scale and data characteristics
  • Code that integrates with external systems: Third-party API calls, database queries, file system operations – error handling and edge cases are where AI commonly under-generates
  • Business logic: Code that encodes rules or decisions about what your product does – correctness here is your responsibility, not AI's

Testing that tests behavior.

AI is good at generating unit tests – but the tests it generates by default often test implementation details rather than behavior. Tests that test implementation break when you refactor; tests that test behavior survive it.

When asking AI for tests, specify:

  • "Write tests that test the behavior (inputs and expected outputs) – not the implementation details"
  • "For each test, write the assertion in terms of what the function should do for the user, not how it works internally"
  • "Include edge cases: null inputs, empty collections, boundary values"

This produces tests that provide real protection rather than false confidence.

Maintaining code ownership.

A rule for every AI-generated code block before it is committed: can you explain what it does and why? If you cannot: understand it before committing. Ask Claude to explain. Trace through it manually. Sketch the logic on paper. Committing code you cannot explain means inheriting a maintenance responsibility you cannot discharge. Every AI-generated line you commit without understanding is technical debt with no corresponding asset.

Practical Example

A developer uses Claude to implement a rate-limiting middleware.

First version: she pastes the description, accepts the generated code, commits it.

Three weeks later, a subtle timing attack vulnerability surfaces in a security review – a pattern that AI generated because it is common in training data.

Second version (different project): she asks Claude to implement the rate limiter, reviews the code line by line, asks Claude to explain the session management approach, identifies that the same common pattern is present, asks "what are the security considerations in this implementation?", and Claude surfaces the vulnerability.

She fixes it before committing.

The difference: ten minutes of understanding review versus three weeks of production exposure.

Lesser-Known Tip

For debugging with AI, describe the behavior you are observing, not the code you suspect is wrong. "This function is returning null when I expect an object – here is the function and here is the input it receives" produces better debugging assistance than "I think line 47 is wrong." Behavior-first debugging prompts let AI reason about the full system rather than confirming the hypothesis you already have – which may be the wrong one.

Safety Notes

AI-generated code can introduce security vulnerabilities that pass code review because they look like standard patterns. For any code touching authentication, data storage, user input processing, or financial calculations, a security-specific review is warranted – either by a security-focused team member or an external review. "It was AI-generated" is not a defense and not an explanation if a vulnerability is found. You committed it; you are responsible for it.

Practice Task

On your next AI coding session, commit to the understanding rule: before committing any AI-generated code block, verify you can explain what it does and why. For any block you cannot explain, ask Claude to walk through it before accepting. Track how often this step catches something worth changing. After one week, assess: how often did the understanding check produce a better final implementation?

Completion Check

You should be able to describe the AI coding collaboration loop, identify which code categories require heightened review, write a test specification that asks AI to test behavior rather than implementation, and apply the understanding rule before committing AI-generated code.

Log in and enroll to access lesson quizzes.

← Back to Course

Scroll to Top