Paradigm Shift Slides Lesson 01 // Engineering & AI
The Paradigm Shift
From Syntax-Heavy Construction to Intent-Based Design
LLM Semantics Syntax Abstraction
The "Vibe" Challenge
01 // INTRODUCTION
"Can you write a complex multi-threaded sorting algorithm in Python without typing a single bracket, keyword, or colon—using only English?"
This is the essence of Vibe Coding.
Legacy Method
Syntax-first approach
Manual state management
Debugging at the character level
Vibe Coding
Intent-first approach
LLM handles implementation details
Architecture-level debugging
Defining the Meta-Layer
02 // DEFINITIONS
What is Vibe Coding?
The practice of building software where Natural Language Intent is the primary interface for generation, iteration, and deployment.
New Abstraction Level
If Python abstracted C++, then LLM natural language prompts abstract Python. We are moving one layer higher in the hierarchy.
Semantic Drift
The gap between what you meant and what the model produced . Success in vibe coding depends on minimizing this drift.
Hierarchy of Complexity
01 // Machine Code
02 // Low-Level (C)
03 // High-Level (Python)
04 // Natural Language (Vibe)
The Mechanical Constraints
03 // ANALYSIS
Probabilistic Nature
LLMs predict the next token, not the next logic gate. This leads to code that looks correct but fails in edge cases or complex state transitions.
Training Data Bias
Models are biased toward common patterns (LeetCode, Boilerplate). Novel or highly custom architectures often cause "hallucination" of APIs.
Context Window
The "short-term memory" of the model. Managing context (what the AI knows about the codebase) is the single biggest technical challenge.
The Architect Mindset
04 // SYNTHESIS
From: Implementer
Typing individual for-loops and if-statements.
Manually importing libraries.
Hand-writing unit tests.
To: Orchestrator
Defining interfaces and system boundaries.
Guiding LLM through iterative refactoring.
Reviewing AI output for logical consistency.
Next: Comparative Code Analysis Activity
Comparative Code Analysis Worksheet Comparative Analysis
Syntax vs. Semantics in Algorithm Design
ID: NLP-L1-WS-01
Natural Language Programming
Student Name
Date
Laboratory Objective
In this session, you will compare the cognitive load and output precision of manual implementation against LLM-driven generation. You will implement a Weighted Directed Graph Traversal using Dijkstra's algorithm.
Part 1: The Syntax Grind
Estimated: 15 Minutes
Briefly outline the logic for a Python-based Dijkstra implementation. Focus on the data structures required (priority queue, distance map).
Pseudo-Code / Architecture Logic
Cognitive Reflection
What specific syntax hurdle (e.g., heap manipulation, tie-breaking logic) took the most mental energy to recall?
Part 2: The Semantic Vibe
Estimated: 5 Minutes
Prompt an LLM to generate the same algorithm. Do not use the word "Dijkstra". Describe the requirements purely through system behavior and goals.
The "Intent" Prompt Used
Output Analysis
Identify one "hallucination" or inefficiency in the AI code.
Semantic Alignment
Did the model interpret your 'intent' correctly on try #1?
The Drift Matrix
Metric Manual (Syntax) AI (Semantic) Time to Executable Cognitive Load (1-10) Robustness/Edge Cases Auditable/Readable
Synthesis Question
If "Vibe Coding" allows you to skip syntax, does it also allow you to skip understanding the underlying algorithm? Support your answer based on the "Drift Matrix" above.
Paradigm Shift Discussion Guide Discussion Facilitator
L1 // The Paradigm Shift
Core Objective
Guide graduate students to move beyond seeing LLMs as "code generators" and start seeing them as "architectural compilers." The focus is on articulating intent rather than specifying steps.
Facilitation Prompts
The Hook
"What happens to the developer's role when the keyboard is replaced by the voice?"
Does the 'developer' become a 'reviewer'?
How does the nature of technical debt change when code is generated in seconds?
Critical Analysis
"The Semantic Drift"
Ask students to define the exact point where their prompt failed to capture a nuance. Was it a linguistic failure or a logical one?
Future State
"Abstraction Fatigue"
If we stop learning syntax, can we still fix the compiler when it breaks? This usually leads to a heated debate on the value of CS fundamentals.
Pacing Guide
Lecture / Hook 15m
Lab: Dijkstra 30m
Group Synthesis 20m
Debrief 10m
Teacher Tips
Watch for students who just use "Write Dijkstra's algorithm". Force them to describe the *problem* instead.
Encourage students to use "vibes" like "make it performant" or "use a clean modular style" to see how adjectives affect code style.
Look Ahead
Lesson 2 will focus on multi-file logic and Chain-of-Thought prompting. Today is just about the "Mindset Shift".
The "Vibe" Taxonomy
Intent
The high-level goal (The "What").
Semantics
The meaning of instructions.
Implementation
The specific code generated.
Drift
The error between Intent & Output.
Logic Mechanics Slides Lesson 02 // Engineering & AI
Logic Mechanics
Chain-of-Thought & Few-Shot Engineering for Complex Systems
Decomposition Context Injection
The One-Shot Fallacy
01 // THE CHALLENGE
Simple scripts work in one shot.
Symptoms of Failure:
• Circular reasoning in generated logic
• Hallucinated edge cases
• Lost context in multi-file systems
The Solution?
We must stop asking for the answer and start demanding the process.
Chain-of-Thought
Few-Shot
Chain-of-Thought (CoT)
02 // TECHNIQUES
The Theory
Forcing the model to output its reasoning before the code increases accuracy by using the context window as a "scratchpad" for logical verification.
"Think step-by-step..."
1
Requirement Analysis
The model lists every constraint it understands from the prompt.
2
System Architecture
The model defines the modules, interfaces, and data flow.
3
Implementation Execution
Finally, the code is emitted, guided by the verified reasoning above.
Managing Multi-File Context
03 // SCALING
The Context Skeleton
Feeding the model a high-level file tree before requesting specific file implementations.
Interface Protocols
Defining .h or types.ts files first to lock down how modules communicate.
Iterative Injection
Updating the prompt with the latest version of related files as you progress.
Workshop Challenge
"Build a distributed cache system with TTL expiry and a LRU eviction policy using a single, structured Chain-of-Thought prompt structure."
1 Shot Only Must explain logic first Go.
Prompt Decomposition Lab Worksheet Lesson 02 Lab
Prompt Decomposition
System Architecture via Semantic Chain-of-Thought
Complexity
Advanced
Mission Parameters
Your goal is to prompt an LLM to build a Distributed Rate Limiter (Token Bucket Algorithm) that synchronizes state across multiple worker nodes using Redis. You must use a Chain-of-Thought structure to ensure 100% logical accuracy in one shot.
Required Components
- Redis Connection Pool
- Atomic Lua Scripting
- Multi-Node Sync Logic
- High-Resolution Timers
Phase 1: Component Decomposition
Break the system down into three discrete logical units. Describe their behavior, not their code.
Unit A: State Persistence
Unit B: Consumption Logic
Unit C: Synchronization
Phase 2: Few-Shot Injection
Design a minimalist example of the logic you want to see. This "hints" the model toward your preferred architecture (e.g., using functional patterns vs. OOP).
Injectable Reference Snippet (Markdown format)
// Write your skeletal example here...
Phase 3: The Unified Prompt
The Vibe Architecture
Construct the final prompt. It should start with "Think through the architecture step-by-step..." and incorporate the logic units and examples from the previous page.
Self-Correction Check
Did the resulting AI code handle atomic race conditions? If not, what semantic instruction did you miss?
LLM Evaluation
Rate the model's logical consistency on a scale of 1-10. Explain any "drift" in the implementation of the Redis Lua script.
// Context Managed by System Architect // NLP-L2-WS-02
Advanced Prompting Teacher Guide Teacher Guide: Advanced Prompting
L2 // Engineering Logic
Instructional Strategy
This lesson moves students from "asking" to "directing." The key pedagogical shift is forcing students to articulate the state machine of their code before the model writes a single line.
Scenario: The Race Condition
Common Pitfall
Students often ask for "a synchronized cache" and the LLM provides simple Python code that is NOT thread-safe for a distributed environment.
Teaching Point: Instruct students to include the phrase: "First, analyze the potential for atomic race conditions in a Redis environment and suggest a locking strategy."
Scenario: Context Overload
Management Strategy
When building multi-file systems, the LLM often "forgets" the schema of File A while writing File B.
Teaching Point: Show students how to use "Context Skeletons"—a text block containing only the function signatures of all existing files to be pasted at the top of every new prompt.
Master Prompt Patterns (The "Keys")
Pattern Name The "Magic" String Desired Outcome System Architect CoT "Identify all constraints and dependencies before emitting code." Avoids "forgetting" requirements midway through generation. Structural Few-Shot "Here is an example of my preferred error handling pattern: [Pattern]" Forces consistency in boilerplate and stylistic choices. Boundary Locking "Strictly adhere to the following interface protocol: [Types]" Prevents the model from changing API signatures on the fly.
Post-Lab Reflection Questions
"Did the Chain-of-Thought reasoning ever disagree with the resulting code? (Hallucination of logic vs implementation)"
"How much 'wasted' context did your prompts contain? Could you have achieved the same result with 50% fewer words?"
"Which was more effective: describing the logic in English or providing a few-shot code example?"
Refactoring Strategy Slides Lesson 04 // Engineering & AI
Refactoring Strategy
Modernizing Legacy Systems via Natural Language Directives
Legacy Modernization Language Translation
The Ingestion Challenge
01 // CONTEXT
"A Monolith is a Context Problem."
Refactoring 10,000 lines of legacy Java into Rust isn't a coding task—it's a knowledge management task.
The Past
Manual line-by-line rewrite. High risk. High cost.
The Vibe Way
Semantic mapping. Interface-driven porting.
LLMs are better at "translating intent" between languages than they are at writing novel logic from scratch. Why? Because the logic is already defined in the source.
Architectural Directives
02 // TECHNIQUES
Structural Mapping
Directive: "Identify the core domain entities in this 2012 Java Monolith and map them to a modern TypeScript interface schema."
Functional Decoupling
Directive: "Extract the authentication logic from this global utility class and encapsulate it into a standalone Go microservice."
Protocol Translation
Directive: "Convert these REST endpoints into a GraphQL schema while maintaining the same underlying data models."
Semantic Verification
03 // QUALITY
How to know if the translation is accurate?
Automated Testing
Use the AI to generate unit tests for the legacy code first, then run them against the new code.
Interface Comparison
Ask the AI to generate a detailed summary of side-effects for both versions and compare the delta.
Modernization Sprint
"Transform this 10-year-old spaghetti Java code into a modern, containerized Rust module with an explicit async runtime.
[01] MAP ENTITIES >> [02] DEFINE TRAITS >> [03] PORT LOGIC
Monolith Refactoring Case Study Lesson 04 Case Study
Monolith to Microservice
Semantic Refactoring of a Legacy Java Enterprise App
Source
JAVA EE 2014
The Legacy State
The application is a massive Inventory Management System. All logic—ordering, shipping, and billing—is contained within a single 15,000-line ServiceManager class. The database interactions are handled via raw SQL strings hardcoded into the Java methods.
Refactoring Goal
Extract the "Billing Engine" into a standalone Rust microservice using the Strangler Pattern.
Refactoring Protocol
1. Schema Ingestion
2. Domain Mapping
3. Logic Porting
4. Validation Synthesis
Phase 1: Semantic Mapping
Prompt the AI to identify the 'Billing' domain entities within the massive Monolith file. List them here.
Legacy Entities (Java)
Modern Equivalents (Rust/TS)
Phase 2: Logic Porting Directive
Construct the specific natural language instruction to port the billing logic. You must specify: Error handling, Type safety, and Async requirements.
// Enter your Refactoring Directive here...
The Strangler Validation
Automated "Vibe" Testing
How do you prompt the AI to prove that the new Rust code behaves exactly like the old Java code? Describe your strategy for generating cross-language unit tests.
Context Limitation Analysis
What was the biggest challenge in fitting the legacy codebase into the context window?
Refactoring ROI
Estimate the time saved using Vibe Coding vs. manual refactoring for this case.
Architectural Synthesis
In a world of Vibe Coding, Technical Debt is no longer a code-level problem—it's a documentation-level problem. If the AI can refactor a monolith in seconds, why do we still have technical debt?
Refactoring Analysis Teacher Guide Teacher Guide: Refactoring Strategy
L4 // Legacy Modernization
Pedagogical Approach
Refactoring is the ultimate test of "Vibe Coding." It requires the LLM to understand existing context and transform it into a new paradigm. Instructors should emphasize Interface-First migration.
The Strangler Pattern Prompt
Technique #01
Instead of porting the whole app, students should "strangle" a single service out of it.
"Analyze [LegacyFile] and identify all methods that touch the [Billing] database table. Create a new Go interface that mirrors these methods' signatures exactly."
Semantic Translation
Technique #02
Encourage students to use the "Translate Intent" prompt rather than "Rewrite in Rust."
"Given this Java logic, what is the most idiomatic way to achieve the same data safety and performance in Rust using the Actix framework?"
Case Study Solutions (Key)
Entity Mapping Solution:
Legacy Java UserRecord -> Rust UserAccount Struct with Option<T> for nullable fields. Billing logic should move from a global static method to a specific Invoice trait.
Validation Solution:
The most robust strategy is "Differential Testing": Inputting the same JSON payload into both the Legacy and New modules and comparing the output hash. AI should be prompted to generate the payload generator.
Common Pitfalls to Monitor
API Drift: AI changing function names (e.g., get_user vs getUser). Remind students to lock the interface first.Implicit Logic: Java's automatic GC vs Rust's Borrow Checker. AI might generate Rust code that doesn't compile due to ownership issues.Database Logic: Remind students that raw SQL strings in legacy code need to be converted to modern ORM calls (or safe SQL) in the new system. Documentation Control Slides Lesson 05 // Engineering & AI
Documentation as Control
The README as the Ultimate Compiler Input
Specs as Source System Synthesis
Documentation-Driven Development (DDD)
01 // THE PARADIGM
"In the AI era, the README is the code."
If your technical specification is precise enough, an LLM can generate the entire functioning repository.
Success is measured by how little manual coding is required after the "Architectural Prompt" is delivered.
AI
The Compiler
DOC
The Source Code
HEX
The Binary
The "Source of Truth" Spec
02 // COMPONENTS
Phase 1
Core Ontology
Define every noun in the system. What is a "User"? What is a "Transaction"? Lock the definitions before the logic.
Phase 2
Interface Contracts
Specify input/output schemas for every module. This creates the "boundary" that the AI cannot cross.
Phase 3
Behavioral Flows
Describe the step-by-step logic of complex interactions using natural language "vibe" directives.
System Synthesis
03 // EXECUTION
The Synthesis Prompt
"Using the attached technical specification, generate a file structure for a [Full-Stack App]. Implement the [Auth] module first, ensuring it adheres to the [Schema] defined in section 2."
Scalable
Consistent
Self-Documenting
The README Architect
"Your final exam: Write a README file so detailed and logically sound that an AI can generate a fully functioning, bug-free SaaS platform from it alone."
Zero Manual Lines of Code allowed.
README Architect Project Worksheet Lesson 05 Project
The README Architect
Documentation-Driven Development Mastery Project
Phase
FINAL MASTERY
Final Mission
You must design a Real-Time Collaborative Markdown Editor. However, you will not write any code. You will write a Comprehensive Specification Document (README.md) that serves as the blueprint for an AI to generate the entire repository in one session.
Architecture
Node/WebSockets
Frontend
React/Tailwind
Storage
Redis/Postgres
Constraint
0 Manual Code
Phase 1: Defining the Ontology
Define the "Nouns" of your system. Be hyper-specific. What does a "Session" contain? What is the schema of a "UserCursor"?
System Data Models (YAML/Markdown syntax)
Phase 2: Core Behavioral Logic
Describe the Conflict Resolution Strategy (Operational Transformation or CRDT) using only natural language. How should the system handle two users typing at the same index simultaneously?
// Enter your Behavioral Directives here...
The Generation Feedback Loop
AI Compilation Log
When you fed your README to the AI, what was the first thing it failed to implement correctly? How did you adjust your README to fix it?
Interface Integrity
Did the AI respect your schema boundaries, or did it "hallucinate" new fields into your objects?
Vibe Success Rate
Percentage of the final repo that was generated purely from the first draft of the README.
%
The Future of the Engineer
If "Documentation is the Control Code," what new skill becomes most valuable for a Graduate Engineer? Is it writing English? Logic? Philosophy? System Design?
README Architect Rubric Guide Project Rubric: README Architect
L5 // Final Mastery Assessment
Grading Rubric
This project evaluates the student's ability to translate complex system requirements into a deterministic natural language specification.
Criteria Exceptional (90-100) Proficient (70-89) Weight Ontological Precision Nouns and data models are defined with zero ambiguity (e.g., specific bit-depths, nullable flags). Entities are clearly named but may lack specific type constraints. 25% Architectural Flow Behavioral logic for edge cases (e.g., race conditions) is described using precise English. Happy-path logic is clear, but edge cases are left to AI "imagination." 30% One-Shot Viability The README results in a compiling, functioning core system with < 3 follow-up prompts. Requires significant conversational debugging to reach a working state. 35% Constraint Adherence Zero manual lines of code were edited; all fixes were applied to the README and re-generated. Minor manual fixes were applied to code during frustration points. 10%
Teacher's Note
The goal of this rubric is to penalize "Vague Vibe Prompting." If a student's spec says "Make it look modern," they should lose points. If it says "Use a 12-column grid system with 24px gutters and Cyan-500 accents," they gain points.
Exit Interview Questions
"Which section of your README was the most difficult for the AI to parse?"
"If you had to hand this README to a human junior dev, would they understand it as well as the AI did?"
"What is the 'syntax' of English that makes it a good programming language?"
