From Annoying to Useful: My Journey with AI-Assisted Development in 2025

The Journey:
From "GitHub Copilot just annoys me" through "Agents hallucinate APIs" to
"Holy shit, I just completed a 2-week feature in 4 hours." This talk documents
2 years of trial-and-error with AI coding tools – and the moment everything clicked.

The Mind-Blowing Result:
Portal format integrations that used to take 2-3 days? Now done in 2-4 hours,
fully tested, production-ready. Multi-file refactorings across 53 Maven modules?
Completed autonomously with 90% success rate. The "10x developer" isn't a myth –
it's what happens when you combine 20 years of experience with systematic AI workflows.
And with the right approach, 20x is within reach.

What you'll learn:
- Why autocomplete ≠ programming (and when it still helps)
- The context death problem and why auto-compaction is poison
- Analyze → Plan → Execute: Multi-phase workflows with review gates
- Skills > MCP: 83% token savings with the right approach
- Recursive instructions: How to teach LLMs to persist
- Real productivity metrics: What 20x actually looks like in practice

Real-World Application:
Portal Export Engine – Engel & Völkers' internal solution for transforming property
listings and automatically publishing them to 50+ international portals (ImmoScout24,
Idealista, PropertyFinder, etc.). 264k LOC, 53 Maven modules, 99.9% SLA, processing
50,000+ properties daily. This is where workflows prove themselves or fail. This is
where I went from frustrated to mind-blown.

With live demo on real production code: From merge request review
to feature implementation – watch a multi-day task complete in minutes.

For: Java developers who want to use AI productively without being
enslaved by their tools. Developers who are tired of AI hype and want
to see actual, measurable results.

Transcript

1. My Journey with AI-Assisted Development Peter Quiel Java Freelancer JUG Bielefeld · November 2025 From Annoying to Useful
2. 1. The Journey - From frustrating autocomplete to systematic workflows 2. Key Learnings - Pattern evolution and what works/doesn’t work 3. Real-World Application - Portal Export: 250k+ LOC enterprise codebase 4. Live Demo - Putting it all together Agenda
3. GitHub Copilot JetBrains AI Chat GPT Part 1: First Contact
4. 🤖 AI pair programmer 🚀 10x productivity 💡 Intelligent code suggestions ✅ 15% excellent autocomplete 😐 70% useless noise 🤷 15% "close enough" The Promise Reality
5. Productivity gain: Low to zero What changed: ❌ Still needed to understand the problem ❌ Still needed to architect the solution ❌ Still needed to debug everything Still need to do the real work ✅ Slightly faster at writing boilerplate ✅ Replaced ~70% of Stack Overflow searches Metric: Before AI: 8 Stack Overflow tabs → After AI: 2 tabs + 1 AI chat The Numbers
7. Augment Code Arrives Part 2: Agents and Naive Usage
8. Task: Write test from JSON data Output: { "name": "John Doe", "email": "john@example.com", "age": 17 } @Test void shouldRejectMinorUsers() { UserValidator validator = new UserValidator(); User user = new User("John Doe", "john@example.com", 17); assertThat(validator.isValid(user)).isFalse(); } What Actually Worked
9. Methods Inventions Code didn’t compile. Agent hallucinated APIs that "should" exist. Everything unexpected in your code leads to wrong assumptions. Failed on so many levels when working on medium tasks. // Agent writes test, invents methods that don't exist assertThat(user.isAdult()) // ❌ Method doesn't exist .isFalse(); assertThat(validator.checkAgeRequirement(user)) // ❌ Also fiction .isFalse(); What Didn’t Work
10. Problem AI has no memory between sessions Solution attempt: Process: Create detailed memory files → Let AI improve them → Reference in prompts Did it work? Sometimes. When AI actually read them. // todo meme - it works when it wokrs. .ai/ ├── memory/ │ ├── architecture.md │ ├── validation-patterns.md │ └── test-conventions.md └── tasks/ └── add-user-validation.md AI Persistent Memory - Knowledge Files
11. "Agents can code, but they can’t remember" What I learned: ✅ Agents can handle medium tasks (3-5 files) ✅ I need build up a knowledge base ❌ No built-in memory mgnt. Stupid like *** ⚠️ Will confidently break what they can’t see 📝 External memory helps …when they read it Success rate on medium tasks: ~30% worked perfectly, ~70% needed intervention Key Takeaway
12. Why Claude Code? - BC I like 🐚 Part 3: It’s all about Context
13. Classic symptoms: 1. Each fix adds more context 2. More context = worse decisions 3. Worse decisions = more fixes needed 4. Complete context collapse 💀 You: "Fix the validation" Claude: "Awesome! I fixed the validation!" You: "You broke the error handling" Claude: "Oh yes, sorry. Fixed now." You: "Validation is broken again" Claude: "You right, sorry. Fixed ..." Slow Context Death Vicious cycle
14. What happened: Message 1-5: Great results ✅ Message 6-10: Results getting fuzzy 🤔 Message 11-15: Starts breaking things 😰 Message 16+: Complete garbage, apology loops 🔥 Total Context = Σ(all inputs) + Σ(all outputs) + Σ(tool results) + system overhead Context Window Formula
15. Claude Code feature: Automatic context compaction Promise: Condense history, keep important context Reality: Result: Rubbish. Complete loss of nuance. Original (153k tokens): - All architectural decisions - Edge cases discussed - Implementation constraints - Error patterns seen After compaction (35k tokens): - "User wants to add feature X" - [Everything important: gone] Auto-Compact: The False Hope
16. The brutal truth: Context window = RAM for LLMs Finite resource Degrades with size "Can’t be recovered" once polluted Lessons: ✅ Monitor context usage ✅ Clear context deliberately ❌ Don’t run into auto-compact. /compact yourself. ❌ Don’t create a flood of messages "Context is treasure, not trash"
17. Agents & Commands Part 4: Taking Control
18. The Architecture Shift Before: Generic prompting with knowledge files After: Specialized agents with focused expertise .claude/ ├── CLAUDE.md # Agent catalog ├── agents/ │ ├── java-implementation-expert.md │ ├── data-model-expert.md │ ├── test-specialist.md │ └── architecture-reviewer.md └── commands/ ├── create-portal-format.md ├── add-property-mappings.md └── implement-feed-publisher.md
19. Agent Components 🎯 Role: Clear responsibility 📚 Expertise: Domain knowledge 🚧 Constraints: What NOT to do 🔄 Triggers: When to activate In the end, it’s a markdown file implement test analyze User Prompt Keyword Match java-implementation-expert test-specialist java-code-scout Focused Response ✅ Specialized Agent "You are java-implementation-expert - Expertise: Spring Boot, Lombok, Stream API - Constraints: Follow validation-patterns.md - Output: Production-ready Java code" → Focused, consistent results What Is an Agent?
20. Main Agent 10k Task 1 - 15k Task 2 - 20k Task 3 - 15k Knowledge Files - 30k Main Agent - 95k Problem: All knowledge loaded upfront Context grows with every message Quality degrades after ~20 messages Main Agent 24k tokens Agent 1 110k tokens Agent 2 89k tokens Agent 3 54k tokens Main Agent 54k tokens ❌ Without Agents ✅ With Agents
21. Role: You are the application domain model expert Expertise: Domain Expert Knowledge Database schema - direct reference to database- schema.sql Reads schema when needed Special JPA knowledge Hibernate expert - knows Torbens Blog better then himself Data Access Pattern - Records instead of Java Beans Constraints: MUST verify that fields exists MUST follow database shema conventions ALWAYS reference our database-schema NEVER implement code, only NEVER make assumptions without DB schema ref NEVER Provide incomplete access patterns that could cause NPEs Agent Example
22. Commands = Pre-structured prompts for common tasks Example: /create-portal-format command Process: 1. Create Maven module in /portal-formats/ 2. Add JAX-B plugin to pom.xml for XSD binding 3. Generate Java classes from XSD 4. Create Transformer.java 5. Implement basic property mapping 6. Add unit tests for transformer 7. Register in portal-formats-parent pom Output: New Maven module with transformer skeleton ` ` Task-Specific Commands
23. Agents without process = Random results Sometimes brilliant, sometimes terrible No way to reproduce or debug Commands without enforcement = Suggestions AI might follow them, might ignore them Need: ✅ Reproducible process ✅ Enforced constraints ✅ Clear success criteria ✅ Systematic validation "Power is nothing without control"
24. Structured Process Part 5: Plan-and-Execute
25. Read-only codebase exploration Multiple solution options Output: analysis file Review & Discussion Fresh context Focused execution Code changes Benefit: No planning discussion pollution in execution phase /create-task "Add shop filter" /work-on task_file.md Phase 1: Planning Phase 2: Execution
26. Process: 1. Review generated task file 2. Chat to refine plan: "Add caching for shop lookups" "Consider pagination" "Check permission requirements" 3. Update task file iteratively 4. /clear context when satisfied Benefits: High-level discussion without code changes Catch architectural issues early Refine before committing to implementation ` ` Interactive Planning Refinement
27. Fresh start = No planning pollution Agent follows task step-by-step with clear context ✅ Step 1: Created ShopFilter.java ✅ Step 2: Registered in FilterRegistry ✅ Step 3: Updated GraphQL schema ... Phase 2: Execution (Fresh Context)
28. Symptoms: Pain points: More time investment in planning When execution fails, wasted effort is higher Need to start over from scratch Failure rate: ~30% of executions needed restart Task: "Follow validation patterns" Agent: [implements validation differently] You: "Why didn't you follow the pattern?" Agent: "Oh, I should have checked validation-patterns.md" Issue: Knowledge wasn’t consistently picked up
29. The harsh reality: Having documentation ≠ Using documentation Agent must explicitly read them No guarantee agent will find right files Question that emerged: How do we make knowledge accessible when needed, not just available if requested? "Knowledge is useless if it’s not accessed"
30. Knowledge When Needed Part 6: Claude Skills
31. Skills = Progressive knowledge disclosure Documentation files: Exist in project Agent must find them Agent must decide to read them High context cost to include Skills: Registered with Claude Auto-suggested when relevant Loaded on-demand Minimal context footprint What Are Skills?
32. Context reduction: ~41k → ~8k (when all loaded) Typical usage: Only 1-2 skills per task = ~3k .claude/doc/ ├── portal-api-format.md (12k) ├── property-types.md (8k) ├── validation-patterns.md (6k) └── domain-model.md (15k) .claude/skills/ ├── portal-formats/SKILL.md (3k) ├── property-model/SKILL.md (2k) ├── validation/SKILL.md (1.5k) └── domain-model/SKILL.md (2.5k) Before After
33. Quality improvements: ✅ Higher accuracy in planning ✅ Fewer surprises in execution Agent knows about edge cases Implements according to established patterns Less "creative interpretation" Before: "How should I format for ImmobilienScout24?" After: [skill auto-loaded] "ImmobilienScout24 uses JSON with externalId..." The Results
34. "Greater tasks need greater preparation" Skills solve the knowledge access problem: ✅ Auto-suggested when relevant ✅ Low context footprint ✅ Domain knowledge separated from agents ✅ Reusable across workflows But: Planning still too shallow for complex tasks Need: Separate analysis phase to assess complexity before planning. Key Takeaway
35. Analyze-Plan-Execute with HITL Part 7: Three-Phase APE
36. Phase 1: /analyze Phase 2: /create-task Phase 3: /work-on - Read-only codebase search - Structured plan - Focused execution - Multiple solution options - Dependency-aware ordering - Step-by-step Output: analysis.md Output: task.md Output: Code ↓ ↓ [Review Checkpoint 1] [Review Checkpoint 2] "Understand problem?" "Plan complete?" The Three-Phase Pattern
37. Command: /analyze "Implement portal format for Bayut based on bayut.xsd" Agent process: 1. Read bayut.xsd structure 2. Search for similar portal implementations 3. Analyze property mapping requirements 4. Check transformer patterns in existing portals 5. Review feed publisher architecture 6. Identify integration test patterns Key constraint: Cannot propose solutions yet Output: analysis_bayut_portal.md with findings and solution options ` ` ` ` Phase 1: Analysis (Read-Only)
38. Human reviews analysis: ✅ Correct understanding of problem? ✅ All aspects covered? ✅ Missing considerations? Refinement via chat: Decision: "Go with Option D" Then: /clear before next phase You: "Option C won't work - we need separate modules" You: "Bayut requires English + Arabic descriptions" You: "Add requirement: support for compound properties" Agent: [updates analysis with constraints] [adds improved option] ` ` Review Checkpoint 1: Validation
39. Command: /create-task analysis_bayut.md "Use Option D" Agent process: 1. Read analysis findings 2. Apply direction 3. Search codebase for implementation patterns 4. Break down into atomic tasks 5. Order by dependencies 6. Add validation steps Output: task_bayut_portal_20241116.md with 12+ detailed steps and dependencies ` ` ` ` Phase 2: Task Planning (Still Read-Only)
40. Human reviews task plan: ✅ All steps present? ✅ Dependencies correct? ✅ Realistic estimates? ✅ Missing edge cases? Refinement: Decision: "Plan looks complete" Then: /clear again You: "Add task for compound property handling" You: "Need error handling for partial feed uploads" You: "Add monitoring for feed success rate" Agent: [adds tasks 10-12 for those concerns] ` ` Review Checkpoint 2: Validation
41. Command: /work-on task_bayut_portal.md Agent execution: Each task: Mark done → Run tests → Validate → Continue ` ` Starting task 1/12: Create Maven module structure ✅ Created portal-formats/bayut/pom.xml ✅ Added to parent POM ✅ Build successful Starting task 2/12: Configure JAX-B plugin ✅ Added jaxb2-maven-plugin ✅ Generated 45 Java classes Phase 3: Execution (Fresh Context)
42. Successfully completed: ✅ Bayut portal integration (2.5k LOC new) New Maven module, 45 JAX-B classes, transformer with mappings, publisher, comprehensive tests Zero manual intervention ✅ Time investment: Analysis: 30-60 min Task planning: 20-40 min Execution: 2-4 hours (mostly automated) Success rate: ~70% completion without intervention Results: 2-5k LOC Features
43. Issue: Tasks sometimes incomplete execution Symptoms: Root cause: LLMs are stateless. Each response is independent. "Work on all task" instruction in Main Agent Context gets foggy during work. Task file has 15 steps Me: "/work-on task_file.md complete all tasks in the file" Agent: "Completed steps 1-8. Would you like to do a review?" Me: "No! Continue until all tasks are done!" Agent: "Oh yes, let me continue" Agent does steps 9-10 Agent stops again The Remaining Problem
44. Three-phase with HITL works brilliantly… ✅ Complex tasks properly scoped ✅ Plans validated before execution ✅ Context stays clean between phases …but execution persistence is fragile: ❌ Agent forgets it’s in a loop ❌ Completes some tasks, stops mid-execution ❌ Context accumulates during long execution "LLMs can get Alzheimer’s… quickly"
45. Enforcing Persistence Part 8: Recursive Instructions
46. Goal: Agent should complete ALL tasks without stopping Reality: Agent completes some, then stops Root cause: LLMs are stateless What doesn’t work: Polite requests in preamble ≠ persistent behavior "Please complete all tasks in order" "Continue until all tasks are done" "Don't stop until finished" The Problem Statement
47. Insight: Put critical instructions where they’ll be read last (just before generating response) Implementation in /work-on command: ` ` # ⚠️ RECURSIVE EXECUTION LOOP - READ THIS BEFORE EVERY RESPONSE END **MANDATORY: Execute this EVERY TIME before ending response:** 1. Check task status 2. If tasks remaining → GO TO NEXT TASK (DO NOT ASK) 3. If all complete → Final validation 4. DO NOT END RESPONSE until ALL tasks complete **DO NOT:** ❌ Stop and wait for user confirmation ❌ Ask "Should I continue?" ❌ Break loop before ALL tasks complete Solution: Recursive Repeated Instructions
48. 1. ALL CAPS for Critical Rules 2. Negative Instructions 3. Explicit Verification Steps 4. Repetition at Multiple Levels In main command file In agent prompt In task file template **AUTONOMOUS MODE: You continue automatically. NO HUMAN INTERVENTION NEEDED.** **DO NOT:** - ❌ Stop and wait - ❌ Ask permission - ❌ End without checking After EVERY task: - Mark [x] in TODO - Add summary to task_file.md - Run TodoRead - If incomplete tasks exist → CONTINUE IMMEDIATELY Additional Enforcement Techniques
49. The Result
50. Key Takeaway "Being polite to an LLM brings you nowhere" LLMs respond to: ✅ Strong directives (DO THIS) ✅ Explicit constraints (NOT THAT) ✅ Repeated instructions (at decision points) ✅ Concrete verification steps LLMs ignore: ❌ Polite suggestions ("Please…") ❌ Vague goals ("Try to complete…") ❌ One-time instructions far from decision point
51. Right-Sized Processes Part 9: Conditional Workflows
52. Current flow: All tasks → /analyze → /create-task → /work-on Issue: Heavy planning overhead for simple tasks Example: ` ` ` ` ` ` Task: "Add 3 missing field mappings + update test" Going through full 3-phase: 55 min Direct analyze → work-on: 30 min Waste: 25 minutes of process overhead The Problem
53. Result: /analyze command decides which path to take Task Assessment ├─ Do you know exactly what to do? │ ├─ YES → 2-Phase (analyze → work-on) │ └─ NO → Continue ├─ Scope: ≤5 Files? → 2-Phase │ └─ >5 Files? → 3-Phase ├─ Explorative task? │ ├─ YES → 3-Phase │ └─ NO → 2-Phase └─ Risk assessment? ├─ Expensive (DB, API) → 3-Phase └─ Easy rollback → 2-Phase ` ` The Solution: Decision Tree
54. Even for simple tasks, analyze phase provides: 1. Verification of assumptions "Just add logging" → "Also need config update" 2. Pattern discovery Found 3 similar logging patterns in codebase 3. Dependency awareness Logging requires updated log4j2.xml Task categorization in practice: 2-Phase (~40% of tasks): Mapping fields, transformer updates, test fixes 3-Phase (~60% of tasks): New portal formats, bigger refactoring Why Analyze First Still Helps
55. The Token Math Part 10: Skills > MCP
56. MCP Server for GitLab Skills + CLI Approach Savings: 6,200 tokens (83% reduction!) MCP Server loaded: - Tool definitions: 15 tools × 200 = 3,000 tokens - Schema definitions: 2,500 tokens - Authentication: 500 tokens - Connection overhead: 1,000 tokens Total: ~7,000 tokens just for availability gitlab-operations.skill.md loaded on demand: 800 tokens What about MCP?
57. Step 1: Find/create CLI tool Step 2: Document in skill Token cost: ~800 tokens (only when needed) brew install glab # Use existing GitLab CLI --- name: GitLab Operations keywords: gitlab, merge request, mr --- ## View Merge Request glab mr view <MR_NUMBER> ## Get MR Diff glab mr diff <MR_NUMBER> CLI + Skills Alternative
58. Debugging MCP: Black box CLI: Transparent Testing MCP: Need server running CLI: Direct testing Portability MCP: MCP environments only CLI: Terminal, scripts, CI/CD Control MCP: Predefined capabilities CLI: Full control, write custom behaviors Additional Benefits
59. Skills + CLI wins: ✅ 83% token savings ✅ Fully transparent ✅ Easy to debug ✅ Works everywhere ✅ Complete control When MCP makes sense: Complex stateful interactions Real-time streaming data Advanced authentication flows But: Not for typical coding tasks Use Skills - Forget MCP
60. Practical Insights Part 11: Tips & Tricks
61. 1. Turn Auto-Compaction Off Auto-compact = context destruction Use manual /compact when needed or /clear for fresh start 2. Use Skills Instead of MCP Find/write CLI tool → Document in skill → Done (~800 tokens vs ~7k) 3. Rewind Session for Artifacts <ESC><ESC> Generate artifact → Rewind → Ask different follow-up questions Unlimited questions, same context footprint 4. Monitor Context Usage Safe: < 50k | Yellow: 50-90k | Orange: 90-120k | Red: > 120k Use plugin for visual indicator ` ` ` ` ` ` Essential Tips (1/2)
62. 6. Task File as Source of Truth Keep updated during execution Resume after interruption Track progress 7. Separate Concerns Session 1: Implement feature Session 2: Write tests - or vice versa 8. Explicit Exit Criteria In task files define validation checklist Agent knows when done 9. Review Checkpoints Are Not Optional 5 min review saves 3 hours of fixing ROI: Insane. Never skip reviews. Essential Tips (2/2)
63. Portal Export System
64. Mission-critical real estate property export engine Purpose: Transform property listings from Engel & Völkers CRM Automatically publish to 50+ international real estate portals Keep portals synchronized with near real-time updates Scale: 50,000+ properties processed daily 99.9% SLA uptime Sub-second API responses (<500ms) 50+ Portals: ImmoScout24, Idealista, PropertyFinder, Facebook, Google Real Estate, RightMove, Kyero, Fotocasa, and more across Europe, Middle East, Asia What Is Portal Export?
65. Metric Value Java Source Files 2,305 files Total Lines of Code 264,784 LOC Production Code 1,561 files / 136,377 LOC Test Code 744 files / 128,407 LOC Maven Modules 53 modules Portal Transformers 18 modules Portal Publishers 19 modules Why this matters for AI: 250k+ LOC = Context management critical 53 modules = Navigation complexity 60+ property types = Domain knowledge essential Codebase Scale
66. Tech Stack: Java 17, Spring Boot PostgreSQL, Pub/Sub Kubernetes, Docker Avro, JSON, XML, CSV Property Engine CRM sends us PubSub Event ↓ We Query CRMs REST API ↓ CRM Data Mapper - Map DTO to ↓ PresentationData - Central Datamdoel (Avro-schema-generated) ↓ Portal Transformer - reusable Portal Formats (18 modules) ↓ Portal Format ↓ Portal Publisher (19 modules) ↓ Portals How It Works - In a Nutshell
67. Demo
68. We want to add short term rental featuer to our export system. Two fields are already available /analyze We have two new fields in the property engine (CRM) api. we need to add this mapping to idealista and property finder, if that is possible. Short Team Rental Feature
69. The Journey Summary
70. ✅ Structured multi-phase workflows Analysis before planning Planning before execution Fresh context between phases ✅ Specialized agents with skills Domain knowledge in skills Agents delegate to skills Token-efficient architecture ✅ Explicit constraints and recursion Strong directives, not polite requests Repeated instructions at decision points Autonomous execution with verification ✅ Human-in-the-loop checkpoints Review analysis before planning Review plan before execution Catch errors early, save hours What Actually Works
71. ❌ Treating AI like human programmer No memory between sessions No inherent understanding Needs explicit instructions ❌ Freestyle prompting for complex tasks Context death inevitable Results degrade over time Hard to reproduce ❌ Auto-compaction Destroys context quality Unrecoverable Never use What Doesn’t Work
72. And… are you more productive?
73. Jan - July 2025 ~2,000 lines/week Maintenance mode Oct - Nov 2025 ~12,000 lines/week Peak: 18,500 lines Pre-AI Era AI-Assisted Era
74. Productivity Increase Same working hours · Same developer · Different workflow 6x
75. Work has completely changed, no need to programm more than 5 lines. One Dev easily handles 500k LoC project Almost no reason to have Tech Dept 3rd Level Support can be done by Chatbot Extrem Cognitive Load: Context switching when working on multiple tasks Impact
76. Thank You!