Writing

Every few years, a technology emerges that prompts breathless predictions about the end of software development as we know it. Visual Basic was going to let business users write their own software. No-code platforms were going to make developers obsolete. Now, large language models are supposedly going to write all our code for us.

I have spent the last two years integrating AI into development workflows—my own and those of teams I lead. The results are genuinely impressive. Code generation, automated testing, documentation, code review assistance: AI excels at all of these. But "excels at tasks" is very different from "replaces the person."

The value of a software engineer has never been typing speed. It has always been judgment—knowing what to build, what not to build, and how to tell the difference.

What AI actually does is compress the feedback loop. A developer who previously spent four hours writing boilerplate now spends twenty minutes reviewing AI-generated boilerplate. That is a genuine productivity gain. But the developer still needs to know whether the boilerplate is correct, whether it fits the architecture, whether it handles edge cases, and whether it introduces security vulnerabilities.

The developers who should be paying attention are those who have coasted on implementation skill alone. If your entire value proposition is "I can write React components quickly," then yes, AI is coming for your lunch. But if your value is understanding the business domain, making architectural trade-offs, mentoring junior engineers, and navigating organizational complexity—AI is your best new tool, not your replacement.

The industry needs more developers, not fewer. AI will help us meet that demand by making each developer more effective. That is the boring, correct answer. It does not make for good headlines, but it is what I see happening on the ground, every day, in production systems that matter.

If you have spent years in the .NET ecosystem and are now looking at Spring Boot, you are probably experiencing a mix of curiosity and dread. The Java world has its own idioms, its own opinions about project structure, and its own version of dependency injection that looks familiar but behaves differently in ways that will bite you.

This is not a comprehensive tutorial. It is a map of the territory—the conceptual bridges between what you know and what you need to learn. Think of it as the conversation I wish I had with someone before I started.

The biggest mistake .NET developers make with Spring Boot is assuming that similar syntax means similar behavior. It does not. Respect the differences.

Start with the build system. In .NET, you have MSBuild and NuGet. In Spring Boot, you have Maven or Gradle. Gradle is the modern choice, roughly analogous to the newer .csproj format—declarative, but with an escape hatch into imperative code when you need it. Maven is the older, XML-heavy approach. Most new projects use Gradle, but you will encounter Maven in existing codebases constantly.

Dependency injection in Spring is annotation-driven. If you know ASP.NET Core's DI container, the concepts transfer directly: constructor injection, scoped vs. singleton lifetimes, interface-based abstractions. The difference is that Spring uses annotations like @Autowired, @Component, and @Service where .NET uses explicit registration in Startup.cs. Spring's approach is more magical and less explicit. Whether that is better depends on your tolerance for convention over configuration.

The rest—middleware, routing, ORM, testing—all have direct analogs. The details differ, but the architectural patterns are nearly identical. Which makes sense: both ecosystems evolved to solve the same problems for the same kind of applications.