1. Overview
In this first lesson, we’ll frame what this foundational course is about and, just as importantly, what it’s not about. It isn’t a tool walkthrough, and it isn’t a pitch on how AI will change everything.
It’s a recalibration for working developers whose instincts were formed in a world where writing code was the hard part.
Let’s look at how mature AI-assisted development actually behaves in practice, what has shifted underneath our day-to-day work, why I start on a greenfield implementation, and what we’ll build across six rebuilds of the same project.
It’s the start of the journey.
2. A Glimpse of Mature AI-Assisted Development
In January 2026, the Cursor team pointed a swarm of AI agents at building a web browser from scratch. The swarm was structured, not a single open-ended prompt: planners decomposed the work, workers wrote the code, and evaluators evaluated the output. One week later, the agents had produced over a million lines of code across a thousand files, including a Rust rendering engine and a custom JavaScript VM.
Let’s be honest about what this was. The browser was a capability demonstration, not a shipped product; it was buggy, and it was incomplete. The significance isn’t in the artifact, it’s in the shape of the work. A system of that size was produced in a week by specialized agent roles, not by a developer typing line by line, and not by one unconstrained prompt either.
A month later, Anthropic published its own version of the same pattern: a 100,000-line C compiler built mostly by sixteen Claude agents running in parallel for about two weeks, capable of compiling Linux, QEMU, Postgres, and Redis.
Several other high-profile stories such as these exist. More importantly, many less flashy, less marketed, more routine examples sit behind them. The pattern is quietly becoming where a mature team is headed. These are mature efforts: structured prompts, role specialization, evaluation loops, careful verification. Not vibe-coded demos.
The rest of this lesson is about the shift that made this kind of work possible, and where the real skill premium now lives.
3. The Shift: Code Is Cheap, Systems Thinking Is Scarce
Code generation has been commoditized. On any of the current frontier models, producing a working implementation of a reasonable feature is fast, cheap, and most of the time roughly correct. Writing code is no longer the bottleneck, and it’s no longer the differentiator.
So where has the bottleneck gone? Not to any single place. It has moved to a cluster of activities that used to sit in the background of our work:
- deep system design
- a deep understanding of how agentic systems actually operate
- the harness we build around the AI
- the clarity we’re capable of bringing to our planning, and critically,
- the ways we verify what comes back.
Deep understanding of these is the new bottleneck.
We’ll call the umbrella skill Systems Thinking. It’s the capacity to look at a piece of work and see more than the code: the boundaries between components, the decisions that are easy to change and the ones that aren’t, the places where failures will show up, the seams that carry the most risk. Judgment is a close synonym, and so we’ll use both.
Now, a fair question at this point: recent studies don’t all obviously support this story. An InfoQ report early in 2026 covered Agoda’s finding that AI coding assistants didn’t meaningfully speed up delivery. A widely cited METR study found experienced open-source developers were around 19% slower with AI, while feeling 20% faster. These findings are real, and they deserve acknowledgement and weight.
The reframe is this: they reflect the average experience today, which is heavily weighted toward immature adoption. Teams bolting AI onto their existing workflow without the surrounding systems thinking and got exactly what that setup produces. The teams behind the stories in Section 2 aren’t rare outliers; they’re early arrivals at what mature adoption looks like.
The gap between those outcomes and the averages is the gap I’ll focus on here, with the AI-focused courses in the library.
This course is a first step into that work.
4. Who This Course Is For
The material is for the working or aspiring Java developer. I assume a basic understanding of Java, comfort with unit tests and Git, and a working local development setup. Familiarity with Spring Boot is helpful because the Jira Lite project I’ll use later is built on it, but it isn’t a hard prerequisite. And, of course, the course library will help you brush up on these foundations.
No prior experience with AI coding tools is expected; we’ll install and configure everything together here.
If that sounds like the standard Baeldung reader, that’s because it is. What’s different is the framing. The premise is simpler: our instincts were calibrated for a world where typing the code was where the work was. That world has shifted. Re-anchoring those instincts to where the work now actually lives is critical.
5. Where AI Helps, Where It Doesn’t, and Why We Start with Greenfield
Let’s draw the map first. AI-assisted development helps across a wide range of scenarios: greenfield work, larger and existing codebases, debugging, writing tests, producing documentation and boilerplate, and learning unfamiliar languages or frameworks. That’s a sketch, not a roadmap, and each of those areas has its own texture. I’ll also use the term vibe coding occasionally for unguided AI output; it’s now common enough that it doesn’t need a definition.
It’s just as useful to name where AI structurally needs guidance. These are the places where the developer still owns the decision:
- What to build, and what could fail. AI writes the code we ask for. It doesn’t know which requirements matter most in our specific context, which failures are expensive, or which assumptions are dangerous for our users.
- Architectural commitments. Decisions such as access control, audit trails, and tenant boundaries are made on day one and can’t be prompted in after the fact. AI implements; it doesn’t decide.
- Irreversibility awareness. Some decisions are one-way doors. AI will happily help us pick a database or an event model, but it won’t flag that the choice is hard to undo later without rewriting half the system.
- Domain and operational judgment. What “good enough” looks like for this team, this user base, this risk profile. That’s our call, not the model’s.
Those four areas are where our work has moved, and sharpening how we direct the AI around them is what the rest of the course is about.
Greenfield is one of several core approaches, and it’s where I’ll focus this course. I pick it deliberately. Greenfield isolates the AI-direction skill from the unrelated skill of reading and navigating an unfamiliar codebase. When both skills are in play, it’s hard to tell which one is failing. Working with larger and existing systems is a real concern and will be covered in future material.
6. The 6 Rebuilds
The backing project for this course is Jira Lite, a ticket-tracking system with enough structure to be interesting: states, workflows, permissions, and relationships between entities. I picked a domain with real complexity on purpose. Simple CRUD is too easy for AI, and it hides the decisions that actually matter.
We’ll rebuild Jira Lite six times, and that’s the core of the course. Each rebuild starts from scratch, and each one adds exactly one layer of structure on top of the previous one. The project stays fixed; the variable is the surrounding structure. What we’re watching for, each time, is how that single added layer changes the output, the experience, and the result.
Here are the six rebuilds, in order:
- Vibe Coding: rebuilding Jira Lite with minimal direction, to set the baseline.
- Structuring the Prompt: rebuilding with a deliberately structured prompt as the only added layer.
- Adding Integration Tests: rebuilding with an integration test feedback loop around the AI.
- Adding Code Analysis: rebuilding with static analysis added into the loop.
- Adding Structured Specs: rebuilding with a written specification driving the work.
- Adding Dev Guidelines: rebuilding with explicit development guidelines layered on top of the spec.
Each rebuild answers a narrow question. What does a structured prompt change that an unstructured one can’t? What does a test loop give us that a prompt alone doesn’t? What does explicit analysis catch that we’d otherwise miss? And so on up the stack.
At the end, we’ll place the six rebuilds side by side. That final synthesis is where the layers stop being abstract and start being a comparison. We’ll see, concretely, what each one contributed, what it cost, and where the return on structure flattens.
7. One Last Thought
This course is going to ask a lot of our judgment. Not of our typing speed, not of our ability to produce code, but of the questions we ask the AI, the constraints we hand it, and the signals we use to decide whether what came back is any good. That’s where our value shows up now, and that’s the skill the AI-grounded course library on Baeldung is here to build, one course at a time.
AI makes thinking more important, not less.
8. Conclusion
The shift underneath our work isn’t that code got easier; it’s that the scarce resource changed. Writing code used to be the hard part, so that’s where our instincts got sharp. Now the hard part is upstream of the code, in the decisions, constraints, and verification surrounding it, and our instincts need to catch up. That’s the recalibration this course is about, and the six rebuilds are how we’ll do it, by holding the project fixed and watching what each layer of structure actually changes.
Next, we’ll get the tool we’ll be working with installed, authenticated, and verified. From there, we’re into the work.