Gregory Bastianelli | Software Engineer

Learning with AI

ls

Set clear project rules

For learning with AI, use these rules:

1. I write the first test.
2. I make the first implementation attempt.
3. I read official documentation before asking AI.
4. AI gives hints before solutions.
5. AI reviews completed diffs rather than generating entire features.
6. I manually type code I choose to adopt.
7. I document what I learned.
8. I must be able to explain every committed line.

Use AI heavily for review, lightly for creation

AI is especially useful after you have completed a feature.

Ask it to:

  • Find missing test cases
  • Challenge your assumptions
  • Review accessibility
  • Identify security concerns
  • Point out unnecessary coupling
  • Explain unfamiliar TypeScript errors
  • Compare your solution with framework conventions
  • Quiz you about the code
  • Suggest refactoring opportunities

Keep a learning log

Add a file such as:

LEARNING.md

After each session, record:

## 2026-07-18

### Built
Parsed Markdown files and validated frontmatter.

### Learned
- How Node reads directories
- Why parsing and file access should be separate
- How discriminated unions improve error handling

### Needed AI help
Understanding why an async filesystem function changed the return type.

### Could I reproduce it?
Mostly. I should rebuild the parser without referencing the current code.

Type the code yourself

Even when AI provides a useful example, avoid copying it wholesale. Recreate it manually and rename or restructure it based on your project.

Typing it yourself gives you time to notice:

  • Types
  • Imports
  • Function boundaries
  • Error handling
  • Naming
  • Assumptions
  • Framework conventions

Put a time limit on being stuck

Use a fixed progression:

  • First 20–30 minutes: work independently
  • Next 15 minutes: consult official documentation
  • Then ask AI for one hint
  • Escalate only when the hint is insufficient

Use AI in progressively stronger levels

Do not jump directly from “I am stuck” to “write the code.”

Level 1: Rubber duck

Explain the issue without asking for a solution:

I am trying to parse Markdown frontmatter and return a typed BlogPost.
Here is what I believe should happen and where my reasoning breaks down.
Ask me questions that help me find the problem. Do not provide code.

Level 2: Conceptual hint

Give me one conceptual hint about why this test is failing.
Do not show the implementation.

Level 3: Documentation guidance

Tell me which Next.js or Node.js concepts and documentation sections I
should study to solve this. Do not write the solution.

Level 4: Review your attempt

Review this implementation for correctness, edge cases, and design issues.
Do not rewrite it. Point out problems and let me fix them.

Level 5: Minimal example

Use this only when the earlier levels are insufficient:

Show the smallest unrelated example that demonstrates this concept.
Do not adapt it to my portfolio project.