daBongo LMS AI Training Courses

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.