Professional Development & Career

What's Changing:

• AI can generate code from descriptions
• Boilerplate code is automated
• Syntax lookup is instant
• Simple bugs are caught automatically
• Documentation is AI-assisted
• Basic testing can be generated

What Remains Essential:

• Understanding system architecture
• Making design decisions
• Debugging complex issues
• Understanding business context
• Ensuring security and reliability
• Validating correctness

AI can:

• Generate CRUD endpoints
• Create entity classes
• Write basic validation
• Generate repository code
• Create simple tests

You must:

• Design the overall architecture
• Decide on data model and relationships
• Implement business rules
• Ensure security (who can delete whose tasks?)
• Handle error cases properly
• Make it production-ready

How to use AI for learning

• Ask for explanations
  "Explain how Spring's @Transactional annotation works"
• Request examples
  "Show me an example of using MockK to mock a repository"
• Explore alternatives
  "What are the trade-offs between JDBC and JPA?"
• Debug your understanding
  "Why doesn't this code work?" (paste error)

Critical rules

1. Always verify - AI can be confidently wrong
2. Test the code - Don't assume it works
3. Read the docs - AI summarizes, docs are authoritative
4. Understand before using - If you can't explain it, don't use it

Effective uses for productivity

• Generate boilerplate
  Data classes, DTOs, entity mapping functions
• Write repetitive code
  Similar endpoints, CRUD operations, basic validation
• Create test templates
  Setup code, common test patterns, mock structures
• Documentation
  KDoc comments, README sections, API documentation
• Refactoring assistance
  Renaming, restructuring, extracting methods

The productivity pattern

1. You design the solution
2. AI generates initial implementation
3. You review and refine
4. You write tests to verify
5. You integrate into the larger system

Generally reliable

• Standard patterns you recognize
• Well-documented APIs
• Simple transformations
• Common use cases
• Syntax you can verify quickly

Quick review → Test → Accept

Needs careful verification

• Security-sensitive code
• Complex business logic
• Performance-critical sections
• Unfamiliar libraries or patterns
• Anything you don't understand

Thorough review → Understand → Test extensively → Verify → Accept

Red flags - Don't trust AI when

• You don't understand the generated code
• It uses libraries or patterns unfamiliar to you
• The explanation doesn't make sense
• It contradicts official documentation
• Multiple AI sessions give different answers

The pair programming mindset

In traditional pair programming, one person writes code while the other reviews. With AI, you can switch roles dynamically:

• AI generates, you review
  "Create a repository method for finding tasks by status"
  You verify correctness, check for edge cases, ensure it fits your architecture
• You write the code, AI reviews
  "Here's my implementation of the service layer. Suggest improvements..."
  AI suggests optimizations, points out potential bugs, recommends best practices
• You design, AI implements
  "I need a service that validates task permissions. Here's the interface..."
  You define structure, AI fills in implementation details
• Collaborative debugging
  "This test is failing. Here's the code and error..."
  AI suggests possibilities, you investigate and verify

Best practices

• Give AI context (show related code, explain the system)
• Be specific in your requests
• Ask AI to explain its suggestions
• Challenge AI's assumptions
• Use AI to explore alternatives before deciding

1. Does it do what you asked?
   Test the happy path first
2. Does it handle edge cases?
   Null values, empty lists, invalid input, boundary conditions
3. Is it secure?
   SQL injection, XSS, authentication, authorization
4. Does it follow your architecture?
   Correct layer, proper dependencies, consistent patterns
5. Is it testable?
   Can you write tests for it? Are dependencies injectable?
6. Is it maintainable?
   Clear naming, reasonable complexity, proper error handling
7. Does it perform well?
   N+1 queries, unnecessary loops, memory usage

Watch out for

• Hallucinated APIs
  AI invents methods or parameters that don't exist
  → Always check documentation
• Missing error handling
  Assumes happy path, ignores exceptions
  → Add try-catch, validation, null checks
• Incorrect assumptions
  Assumes data structure, state, or behavior
  → Verify assumptions match your system
• Outdated patterns
  Uses deprecated APIs or old approaches
  → Check if code is current
• Over-complicated solutions
  Uses complex patterns when simple would work
  → Simplify if possible
• Missing security checks
  Forgets authentication, authorization, validation
  → Add security layers

Why test AI code more thoroughly?

• You didn't write it, so you might miss edge cases in review
• AI doesn't understand your business rules
• AI might make subtle logical errors
• AI doesn't consider integration with your existing code

Testing strategy

1. Start with the tests AI suggests
   They often cover basic cases
2. Add edge case tests
   Null, empty, boundary values, invalid input
3. Test error scenarios
   What happens when things go wrong?
4. Integration tests
   Does it work with your actual database, services, etc?
5. Manual testing
   Use the API/UI yourself - does it feel right?

Architecture matters more than ever

• AI generates components, not systems
  It can create individual classes but struggles with overall system design
• Trade-offs require context
  Should this be synchronous or async? Monolith or microservices? AI doesn't know your constraints
• Evolution matters
  Systems must grow and change. Architecture determines how painful that will be
• Integration complexity
  How services communicate, where boundaries are, what depends on what

This course gives you architectural thinking

• Layered architecture (Controller → Service → Repository)
• Separation of concerns (DTOs vs Entities)
• Dependency management (Dependency Injection)
• Data access patterns (JDBC vs JPA vs JOOQ)
• Transaction boundaries and consistency

Why testing matters with AI

• Verification of correctness
  How do you know AI-generated code actually works? Tests.
• Edge case discovery
  AI often misses edge cases. Good tests catch them.
• Documentation of intent
  Tests show what code should do, not just what it does
• Refactoring safety
  Tests let you safely improve AI-generated code
• Integration validation
  Does this component work with the rest of your system?

Testing skills you've learned

• Unit testing with JUnit and Kotest
• Mocking with MockK
• Controller testing with MockMvc
• Service and repository testing patterns
• Test organization and best practices

AI can help with

• Suggesting possible causes
• Explaining error messages
• Proposing solutions to try
• Finding similar issues

You must handle

• Understanding your system state
• Reproducing the issue
• Verifying the actual cause
• Testing the fix works
• Ensuring no side effects

Complex debugging scenarios AI struggles with

• Race conditions and concurrency issues
• Production-only bugs with partial information
• Performance degradation in specific scenarios
• Integration issues across multiple services
• Security vulnerabilities and their implications

Surface Knowledge:

• "AI says to do it this way"
• Can't explain why code works
• Struggles when AI suggestions fail
• Unable to evaluate trade-offs
• Copies without understanding
• Can't debug unexpected issues

This person adds little value beyond what AI provides.

Deep Understanding:

• "Here's why this approach works"
• Explains trade-offs and implications
• Debugs when things go wrong
• Makes informed architectural decisions
• Reviews and improves AI suggestions
• Adapts solutions to context

This person multiplies AI's value.

Without a Workflow

• Merge conflicts everywhere
• Unclear what's in production
• Hard to revert bad changes
• No coordination between developers
• Difficult to manage releases
• Testing becomes a nightmare

With a Workflow

• Clear branching strategy
• Predictable release process
• Easy rollbacks when needed
• Parallel development possible
• Quality gates (code review, testing)
• Traceable history

• + Simple and easy to learn
• + Fast iteration and deployment
• + Works perfectly with CI/CD
• + Single source of truth (main)

• - Less control over releases
• - Not ideal for scheduled releases
• - Can be chaotic for large teams

• + Clear structure for large teams
• + Great for scheduled releases
• + Parallel development streams
• + Hotfix workflow built-in

• - More complex to manage
• - Slower feedback loops
• - Can accumulate merge conflicts
• - Overkill for small teams

• + Fastest integration
• + Minimizes merge conflicts
• + True continuous integration
• + Simplest workflow

• - Requires strong test coverage
• - Needs feature flags for incomplete work
• - High discipline required
• - Less time for thorough code review
• - Can feel risky to teams
• - Requires mature CI/CD

Technical Aspects:

• Correctness
  Does the code do what it's supposed to do?
• Tests
  Are there appropriate tests? Do they cover edge cases?
• Error handling
  Are errors handled appropriately?
• Performance
  Are there obvious performance issues?
• Security
  Are there security vulnerabilities?
• Edge cases
  What happens with null, empty, or extreme values?

Design & Maintainability:

• Readability
  Is the code easy to understand?
• Architecture
  Does it fit the overall design?
• SOLID principles
  Is the code well-designed and maintainable?
• DRY
  Is there unnecessary duplication?
• Naming
  Are names clear and descriptive?
• Documentation
  Is complex logic explained?

Do

• Be specific
  "This function could be split into smaller functions" vs "This is messy"
• Ask questions
  "Could we use a map here instead of filtering twice?"
• Explain why
  "This could cause a race condition because..."
• Acknowledge good code
  "Nice handling of this edge case!"
• Suggest alternatives
  "What about trying X approach?"
• Distinguish required vs optional
  "nit:" for style, "BLOCKER:" for must-fix

Don't

• Be vague
  "This doesn't look right"
• Make it personal
  "Why did you write it this way?"
• Nitpick everything
  Focus on important issues
• Assume incompetence
  Maybe they know something you don't
• Rewrite in your style
  Accept different valid approaches
• Only criticize
  Point out good things too

Good responses

• "Good catch! I'll fix that"
• "Could you explain more about why?"
• "I hadn't considered that case. Thanks!"
• "I chose X because Y, but I'm open to alternatives"
• "You're right, but I will do it in separate branch."

Avoid

• "That's just your opinion"
• "It works, doesn't it?"
• "I didn't have time to do it properly"
• Silence or ignoring feedback

Increasing in value:

• Architects
  Design systems, make technical decisions
• Senior engineers
  Review code, mentor, solve complex problems
• Technical leads
  Bridge business and technology
• Platform engineers
  Build tools and infrastructure
• Security engineers
  Identify and prevent vulnerabilities
• Performance engineers
  Optimize systems at scale

Declining in value:

• Pure code writers
  Converting specs to code without judgment
• Boilerplate generators
  Creating repetitive CRUD code
• Syntax experts
  Knowing language syntax but not architecture
• Copy-paste developers
  Using code without understanding

These tasks can increasingly be automated