VibeTDD Experiment 4.1: Project Setup and the Automation Reality Check
After the convention generation experiment taught me that AI can't easily build the flexible system I dreamed of, I shifted to a more pragmatic approach: focused project templates.
For Phase 4.1, I wanted to test whether AI could handle the initial task of project setup. The goal was simple: take a proven template and adapt it for a specific project.
The results revealed something I should have expected: Maybe we don't need using AI for mechanical tasks that bash scripts excel at.. But they also revealed something more interesting in where AI actually provides value.
The Setup: From Template to Working Project
The Template Architecture
I created a project template based on everything I'd learned from previous VibeTDD experiments:
Stack: Kotlin + Spring Boot + Maven + Modular Monolith
Architecture: Hexagonal (clear separation for AI understanding)
Structure:
api-template-modular-basic/
├── app/ # Application module
├── commons/ # Shared code
├── docs/
│ ├── conventions/ # All VibeTDD conventions
│ └── tasks/ # Development task guides (it's just for experiments, I don't think it should be in real projects)
├── main-api/ # Main API module
├── module-template/ # Template for new domains
└── pom.xml # Multi-module Maven setup
2
3
4
5
6
7
8
9
Why Hexagonal Architecture: Clear boundaries between business logic and external layers should make it easier for AI to understand what and where to test with proper conventions.
The Task: Template to Real Project
I chose the same payouts domain from previous experiments, but this time with complete API and database layers for a more realistic test. I'm going to use it for all phase 4.X phases and postpone more complex task I planned before.
The Goal For this Phase: Take the generic template and adapt it for the specific payouts project.
Testing Claude Code for Project Setup
First Attempt: The Simple Prompt
I decided to try Claude Code for this experiment - the terminal-based version that can actually execute commands and scan the entire codebase.
My initial prompt was simple:
"Adapt this template for a payouts project. Rename module-template to payouts and replace all ModuleTemplate references with Payout."
Result: It worked reasonably well on the first try.
Second Attempt: Consistency Check
I wanted to test consistency, so I tried the same simple prompt again on a fresh copy.
Result: Partially failed - missed several references and had inconsistent naming patterns. The project didn't compile.
Third Attempt: The Strict Prompt
Time for surgical precision based on previous VibeTDD lessons:
Your task is to prepare the template to real project. Follow the steps:
- execute `git init`
- execute `git add --all`
- copy module-template to payouts
- in the copied module rename all occurrences ModuleTemplate to Payout
- change the project name to payouts-api and update the reference in all modules
- rename the base package com.company to dev.vibetdd
- don't touch anything else, don't assume it would be helpful
- test that code is compilable: `mvn clean test`. If not then fix issues
- execute `git add --all`
2
3
4
5
6
7
8
9
10
11
Result: Worked correctly with the detailed instructions.
An Interesting Discovery
Here's where things got interesting. I had placed all my VibeTDD conventions in docs/conventions/
and decided to put task guides in docs/tasks/
. I created docs/tasks/1-setup-project.md
with the setup instructions.
The Surprise: When I just typed claude
in the terminal, it automatically started executing the first task ))).
Claude Code had scanned the project, found the tasks directory, and assumed I wanted to execute the first available task. It was simultaneously impressive and unsettling.
The Verdict: AI vs. Bash Scripts for Project Setup
After testing this approach multiple times, I could conclude:
❌ Maybe we don't need to use AI for mechanical tasks
Problems with AI setup:
- Inconsistent execution: Misses references even with specific instructions
- Context confusion: Sometimes overthinks simple rename operations
- Compilation fixes: Adds unnecessary complexity when fixing broken builds
- Time overhead: Much slower than script execution
✅ Bash scripts excel at this
A simple bash script would:
- Execute faster: No reasoning overhead
- Be more reliable: Same result every time
- Handle edge cases: Properly escape special characters
- Be maintainable: Easy to update and version
The Reality: It makes no sense using AI for project setup when a bash script could do it in seconds with perfect accuracy.
Where AI Actually Adds Value
While AI failed at mechanical setup, it provides value for:
- Adding new modules during development (understands existing patterns)
- Dependency decisions (suggests libraries, explains trade-offs)
- Architecture guidance (explains structure, suggests improvements)
The Project Template Success
Despite the setup automation disappointment, the project template approach itself worked great:
Clear Structure
The modular monolith with hexagonal architecture provided:
- Clean separation of concerns
- Obvious places for new features
- Testable business logic
- Clear API boundaries
Convention Integration
Having conventions directly in the project meant:
- No separate documentation to maintain
- Context-aware guidance for developers
- Easy onboarding for new team members
- Consistent patterns across modules
Ready-to-Develop Foundation
The template included:
- Pre-configured Maven modules
- Basic hexagonal architecture setup
- Testing infrastructure including test for common logic
- API layer foundations
- Database integration points
The Next Experiment Preview
Phase 4.1 proved that AI shouldn't handle mechanical project setup, but it validated the project template approach. Now I'm moving to something more interesting: requirements to implementation workflow.
Phase 4.2: Spec to Stories to Tasks to Tests
The Goal: Test whether AI can help break down requirements into actionable development work.
The Workflow:
- Get requirements (business specification)
- Split into stories (user-focused features)
- Create dev tasks (implementation work)
- Generate tests (verification criteria)
The Hypothesis: AI should excel at this kind of analytical work that requires understanding context and breaking down complexity.
Each task will contain:
- What to do (implementation requirement)
- Test criteria (verification in plain English)
- Acceptance criteria (when it's complete)
Why This Matters: If AI can help translate business requirements into structured development work, it could significantly improve the planning phase of software development.
Lessons for VibeTDD Framework
- Consider to avoid AI for mechanical tasks - bash scripts are faster and more reliable
- Use AI for contextual understanding - pattern recognition, architectural decisions
- Project templates work - expert-curated patterns beat flexible generation
The Meta-Learning
Phase 4.1 reinforced a key VibeTDD principle: AI should augment human expertise, not replace proven tools.
Bash scripts are perfect for mechanical tasks. AI is valuable for understanding, analysis, and pattern application. The key is using each tool for what it does best.
The real value isn't in getting AI to do everything, but in creating workflows where AI enhances the parts of development that benefit from intelligence and reasoning.
Next up: Testing whether AI can help break down complex requirements into actionable development tasks. If successful, this could transform how we move from business needs to working code.