docs: add Alan Tour Eiffel paradigm evaluation (5/5 CRITICAL)
Integration of Alan Engineering team's paradigm shift framework: - Tour Eiffel Principle (transformation vs acceleration) - Ralph Wiggum Programming (agentic loops) - Verification Paradox (automated guardrails over human review) Files added: - docs/resource-evaluations/alan-tour-eiffel-paradigm.md (291 lines) Files modified: - guide/production-safety.md: New Rule 7 "Verification Paradox" - guide/ai-ecosystem.md: Added practitioner insight (line 2133) - machine-readable/reference.yaml: Added Alan + verification paradox entries - README.md: Fixed evaluation counters (37/35/38 → 41) Source: https://www.linkedin.com/pulse/le-principe-de-la-tour-eiffel-et-ralph-wiggum-maxime-le-bras-psmxe/ Authors: Charles Gorintin (CTO Alan), Maxime Le Bras (Talent Lead) Published: 2026-02-02 Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
This commit is contained in:
Florian BRUNIAUX
parent
1ceba8b3fc
commit
5b69db64a9
6 changed files with 497 additions and 5 deletions
|
|
@ -2129,6 +2129,41 @@ External resources from experienced practitioners that validate and extend the p
|
|||
|
||||
**Note**: Article aggregates existing research. For primary data, see DORA Report 2025, Stack Overflow 2025, and Matteo Collina insights documented above.
|
||||
|
||||
### Alan Engineering (Charles Gorintin, Maxime Le Bras)
|
||||
|
||||
**URL**: [Le principe de la Tour Eiffel (et Ralph Wiggum)](https://www.linkedin.com/pulse/le-principe-de-la-tour-eiffel-et-ralph-wiggum-maxime-le-bras-psmxe/)
|
||||
|
||||
**Author credentials**:
|
||||
- Charles Gorintin: Co-founder & CTO at Alan (15K+ companies, 300K+ members, €500M raised), ex-Facebook/Instagram/Twitter data science, Mistral AI board member
|
||||
- Maxime Le Bras: Talent Lead at Alan, pioneer in AI-assisted recruitment in France
|
||||
- Published: February 2, 2026 (Newsletter "Intelligence Humaine", 3,897 followers)
|
||||
|
||||
**Content summary**: Paradigm shift framework for AI-assisted engineering through two core concepts:
|
||||
1. **Eiffel Tower Principle**: AI tools fundamentally transform what's architecturally possible (like elevators enabled Eiffel Tower's shape), not just acceleration of old tasks
|
||||
2. **Ralph Wiggum Programming Model**: Agentic loops where engineers become architects/editors rather than sole creators (reference to Simpsons character "helping" assemble furniture)
|
||||
3. **Verification Paradox**: When AI succeeds 99% of the time, human vigilance becomes unreliable for catching the 1% errors — solution: automated guardrails over manual review
|
||||
4. **Precision as Currency**: Clear specification (WHAT/WHERE/HOW) becomes engineer's new superpower, replacing implementation speed
|
||||
5. **Ambition Scaling**: Pursue previously impossible ambitions enabled by new tools, not just faster execution of old tasks
|
||||
|
||||
**Key quote**:
|
||||
> "L'intelligence est la faculté de fabriquer des objets artificiels, en particulier des outils à faire des outils." — Henri Bergson, L'évolution créatrice (1907)
|
||||
|
||||
**Alignment with this guide**:
|
||||
|
||||
| Alan Concept | This Guide Reference |
|
||||
|--------------|---------------------|
|
||||
| Verification Paradox | Production Safety Rule 7 (production-safety.md:639) |
|
||||
| Precision requirements | Prompting WHAT/WHERE/HOW/VERIFY (ultimate-guide.md:1512) |
|
||||
| Ralph Wiggum loops | Iterative Refinement workflows (workflows/iterative-refinement.md:107) |
|
||||
| Engineer → Architect shift | Mental Model: orchestrator pattern (ultimate-guide.md:1189) |
|
||||
| Eiffel Tower Principle | Transformation vs acceleration (implicit in paradigm shift) |
|
||||
|
||||
**Value**: Production-scale validation from major French tech company operating in heavily regulated industry (health insurance, GDPR, health data compliance). First clear articulation of "Verification Paradox" as distinct concept. Demonstrates that paradigm shift concepts apply beyond Silicon Valley startups to established European companies.
|
||||
|
||||
**Context**: Article includes interview with Stanislas Polu (Dust co-founder, ex-OpenAI) mentioning Mirakl achievement (75% of employees became agent builders using Dust platform). Validates that "engineer → orchestrator" transformation is happening across industry, not just early adopters.
|
||||
|
||||
**Language note**: Original article in French; concepts and quotes translated for this guide.
|
||||
|
||||
---
|
||||
|
||||
## 11.3 Skills Distribution Platforms
|
||||
|
|
|
|||
|
|
@ -636,6 +636,159 @@ fi
|
|||
|
||||
---
|
||||
|
||||
## Rule 7: The Verification Paradox
|
||||
|
||||
### The Problem
|
||||
|
||||
When AI succeeds 99% of the time, traditional human verification becomes fragile:
|
||||
|
||||
**The paradox**: As AI reliability increases, human review quality decreases.
|
||||
|
||||
- **Vigilance fatigue**: Rare errors (1%) slip through when humans unconsciously trust patterns that usually work
|
||||
- **Pattern-trusting behavior**: Manual review degrades as reviewers stop expecting errors
|
||||
- **False confidence**: "It worked last 50 times" creates blind spots for the 51st failure
|
||||
- **Cognitive load**: Humans aren't optimized to catch 1-in-100 errors consistently
|
||||
|
||||
**Real incidents**:
|
||||
- Payment validation bypassed after 200 successful transactions → fraud on transaction #201
|
||||
- Security check skipped because "AI always gets auth right" → credentials leaked
|
||||
- Test suite passing 99% → production bug from the 1% case that wasn't tested
|
||||
|
||||
**Source**: [Alan Engineering Team (Charles Gorintin, Maxime Le Bras), Feb 2026](https://www.linkedin.com/pulse/le-principe-de-la-tour-eiffel-et-ralph-wiggum-maxime-le-bras-psmxe/)
|
||||
|
||||
### The Rule
|
||||
|
||||
**Build automated safety systems instead of relying on human vigilance.**
|
||||
|
||||
When AI reliability crosses ~95%, shift from manual review to automated guardrails.
|
||||
|
||||
### Anti-Patterns vs Better Approaches
|
||||
|
||||
| Anti-Pattern | Better Approach |
|
||||
|--------------|-----------------|
|
||||
| Manual review for every AI output | Automated test suites + selective review |
|
||||
| Trust because "it worked last time" | Verification contracts (tests, types, lints) |
|
||||
| Human as sole error detector | Guardrails that fail fast (CI/CD gates) |
|
||||
| "Spot-check" strategy for high-frequency AI ops | Comprehensive automated validation |
|
||||
| Reviewer fatigue = lower standards over time | Consistent automated quality bars |
|
||||
|
||||
### Implementation
|
||||
|
||||
**Option A: Automated Guardrail Stack**
|
||||
|
||||
```yaml
|
||||
# .github/workflows/ai-safety.yml
|
||||
name: AI Output Validation
|
||||
|
||||
on: [pull_request]
|
||||
|
||||
jobs:
|
||||
validate:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: Type safety
|
||||
run: npm run typecheck # Catch type errors AI missed
|
||||
|
||||
- name: Lint rules
|
||||
run: npm run lint # Enforce code standards
|
||||
|
||||
- name: Unit tests
|
||||
run: npm run test # Verify behavior contracts
|
||||
|
||||
- name: E2E tests
|
||||
run: npm run test:e2e # Catch integration failures
|
||||
|
||||
- name: Security audit
|
||||
run: npm audit # Detect vulnerable dependencies
|
||||
|
||||
- name: Bundle analysis
|
||||
run: npm run analyze # Catch bloat/regressions
|
||||
|
||||
# Human review ONLY after all automation passes
|
||||
```
|
||||
|
||||
**Option B: Verification Contracts in CLAUDE.md**
|
||||
|
||||
```markdown
|
||||
## Verification Protocol
|
||||
|
||||
### NEVER rely on human review alone
|
||||
|
||||
**Automated verification required**:
|
||||
1. **Type safety**: `npm run typecheck` must pass (zero errors)
|
||||
2. **Tests**: `npm run test` coverage ≥ 80% for new code
|
||||
3. **Lint**: `npm run lint` must pass (zero warnings)
|
||||
4. **Security**: `npm audit` must show zero high/critical vulnerabilities
|
||||
5. **Performance**: Lighthouse score ≥ 90 for affected pages
|
||||
|
||||
**Human review is for**:
|
||||
- Architecture decisions
|
||||
- UX/design choices
|
||||
- Business logic validation
|
||||
- Edge cases automation can't catch
|
||||
|
||||
**Human review is NOT for**:
|
||||
- Syntax errors (use linters)
|
||||
- Type errors (use TypeScript)
|
||||
- Performance regressions (use benchmarks)
|
||||
- Security issues (use automated scanners)
|
||||
```
|
||||
|
||||
**Option C: Pre-merge checklist (automated)**
|
||||
|
||||
```bash
|
||||
# .claude/hooks/PreCommit.sh
|
||||
#!/bin/bash
|
||||
|
||||
echo "🔍 Running automated verification (Verification Paradox defense)..."
|
||||
|
||||
# 1. Type safety
|
||||
npm run typecheck || { echo "❌ Type errors detected"; exit 1; }
|
||||
|
||||
# 2. Lint
|
||||
npm run lint || { echo "❌ Lint errors detected"; exit 1; }
|
||||
|
||||
# 3. Tests
|
||||
npm run test || { echo "❌ Tests failing"; exit 1; }
|
||||
|
||||
# 4. Security
|
||||
npm audit --audit-level=high || { echo "❌ Security vulnerabilities detected"; exit 1; }
|
||||
|
||||
echo "✅ All automated checks passed"
|
||||
echo "💡 Human review can now focus on architecture/UX/business logic"
|
||||
```
|
||||
|
||||
### Edge Cases
|
||||
|
||||
| Scenario | Behavior |
|
||||
|----------|----------|
|
||||
| AI writes perfect code 99.9% | STILL run automation (paradox applies even at 99.9%) |
|
||||
| Time pressure, "just ship it" | Automation is non-negotiable (fast ≠ skip safety) |
|
||||
| Trivial changes (typo fix) | Run automation (typos can break prod) |
|
||||
| Emergency hotfix | Automation REQUIRED (stress = higher error rate) |
|
||||
|
||||
### Why This Matters
|
||||
|
||||
**Old model (pre-AI)**:
|
||||
- Code quality = human expertise + careful review
|
||||
- Errors caught by experienced developers
|
||||
- Review quality stays consistent
|
||||
|
||||
**New model (AI-assisted)**:
|
||||
- AI produces high-quality code 95%+ of the time
|
||||
- Humans become complacent ("AI usually gets it right")
|
||||
- 5% error rate slips through fatigued review
|
||||
|
||||
**Solution**: Automate the boring verification (syntax, types, tests), reserve human attention for creative/strategic review.
|
||||
|
||||
### Integration with Other Rules
|
||||
|
||||
- **Rule 3 (Feature Completeness)**: Automated tests verify features are actually complete
|
||||
- **Rule 2 (Database Safety)**: Migration tests catch destructive operations
|
||||
- **Rule 6 (Pattern Following)**: Linters enforce project conventions automatically
|
||||
|
||||
---
|
||||
|
||||
## Integration with Existing Workflows
|
||||
|
||||
### With Plan Mode
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue