⚡ I Got Tired of Writing the Same Spring Boot Code… So I Built a Generator Inside IntelliJ
Every Spring Boot project starts the same way.
You create an entity…
and then spend the next hour writing:
- Repository
- Service
- Controller
- DTOs
- Mappers
- Exception handling
- Pagination
Nothing difficult.
Just repetitive.
And repetition is where productivity dies.
🤯 The Real Problem Nobody Talks About
It’s not about writing code.
It’s about rewriting the same code again and again:
- Same patterns
- Same structure
- Same logic
And yet…
We still do it manually.
🧠 The Idea
I asked myself a simple question:
What if selecting a class could generate an entire backend layer?
Not boilerplate.
Not templates.
But production-ready code.
⚙️ Under the Hood (The Interesting Part)
Building this inside IntelliJ was way more complex than expected.
🔹 1. Reading Code Like IntelliJ Does (PSI)
You don’t parse Java files manually.
You work with IntelliJ’s PSI (Program Structure Interface):
- Detect fields
- Identify annotations like
@Entity - Extract metadata
Without PSI → nothing works.
🔹 2. Generating Code That Doesn’t Look Generated
Most generators fail here.
They produce:
- Ugly code
- Poor structure
- Hard to maintain
I wanted the opposite:
Code that feels like a senior developer wrote it.
That meant:
- Clean layering (Controller → Service → Repository)
- DTO separation
- Proper naming conventions
🔹 3. Dependency Injection Without Breaking Projects
This turned out to be one of the hardest parts.
You need to:
- Detect if dependency already exists
- Support both Maven & Gradle
- Avoid duplicates
- Insert safely inside correct block
A naive approach breaks builds instantly.
So I built logic to:
- Scan existing dependencies
- Inject only when missing
- Keep it idempotent
🔹 4. Optional Security (JWT)
Security isn’t just “add dependency”.
It involves:
- Filters
- Authentication flow
- User + roles
- Token handling
And it had to be:
Optional. Clean. Non-breaking.
🔹 5. Supporting Multiple Databases
Different teams → different databases.
So I added dynamic support for:
- MySQL
- PostgreSQL
- MongoDB
- H2
Challenge:
- JPA vs Mongo are fundamentally different
- Configurations vary
- Drivers must be injected conditionally
⚡ The Biggest Lesson
Generating code is easy.
Generating safe, usable, production-ready code is hard.
🧩 What This Changed for Me
I stopped thinking like a developer writing code.
And started thinking like:
A developer building tools for developers.
🚀 Why This Matters
This isn’t just about saving time.
It’s about:
- Reducing friction
- Standardizing architecture
- Eliminating repetitive mental load
Because energy should go into solving real problems…
not rewriting CRUD for the 50th time.
💬 Final Thought
The best tools don’t just automate tasks.
They remove unnecessary thinking.
If you’ve ever tried building developer tools,
or struggled with safe code generation…
I’d love to hear your approach 👇
Top comments (8)
This is solid. The PSI + safe dependency injection part is where most generators usually break.
One thing I’ve seen though, generating CRUD layers solves maybe 60–70% of the repetition.
The bigger friction starts right after:
That part still ends up being rebuilt manually in every project.
Curious if you’ve thought about extending this beyond CRUD into those layers, or if you want to keep it focused on code generation only?
I’d go with a hybrid.
Opinionated core for things that should never be reinvented (auth, roles, tenancy basics, structure)
Then modular for everything else.
Most devs don’t want flexibility at the start. They want something that just works.
Flexibility matters later.
That’s actually the gap I’m focusing on with BuildBaseKit. Going beyond CRUD into the layers that are painful to rebuild every time.
Yeah this actually makes a lot of sense.
The hybrid approach feels right—having a solid opinionated base for things like auth and structure, and then keeping everything else modular.
Totally agree on the “just works” part too. Most of the time you don’t want to think about setup, you just want to start building.
I’m trying to move in a similar direction with this—starting with a strong base and then expanding gradually.
Interesting that you’re focusing on that gap with BuildBaseKit—that’s definitely where most of the real pain is.
I checked it out, this is solid work.
One thing you might notice as you go deeper, generation helps early, but teams still struggle once real business logic + multi-tenant flows kick in.
That’s exactly why I’m building BuildBaseKit, to handle those layers out of the box instead of generating them.
If you’re open, I’d love to get your take on that approach since you’re already solving the earlier part of the problem.
I am trying the generator out now, code looks nice. But for some reason the applications shuts down after starting without a clear error message. I do see a warning that I do not yet understand:
I am working with the intellij plugin of your generator right now. Maybe you have an idea what could be wrong ?
After I added this to the pom the server did start and kept running:
<dependency><groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
If you're curious, I turned this into an IntelliJ plugin you can try here:
plugins.jetbrains.com/plugin/29476...
Would love your feedback 🙌