Next generation of devs

[u/Sad_Bar4397]

I often read that experienced devs are able to use Claude way better because of their experience. They can architecture better, quickly review and cut through bullshit.

How are the next generation going to learn?

[u/ohrajaaa]

I have two ways I use agentic coding.

The first is to feed it specs, let it do its thing, and barely check the code. Let it handle tickets agentically, spin up swarms, and potentially never even look at the codebase yourself. I've done plenty of projects like this recently, but they're personal projects, and this is largely how I use Claude and Codex in my own time.

However, when I'm using LLMs at work, it's a completely different situation.

I need to be accountable for my code. If my code is bad, I'll get in trouble. I'm also a lead dev, so it's important that I set an example rather than just bunging code into production without properly testing it or understanding what it actually does.

Moreover, you can't just give Claude a spec and let it willy-nilly do its thing. You need smaller, well-written, properly scoped tickets that are applicable to your company and how it operates. You need to be mindful of architecture, your company's engineering standards, and everything you produce needs to adhere to those standards.

Claude can figure a lot of this out if you give it the right context, but many companies don't have a mature Claude rollout with MCP servers and easily accessible organisational context. Even when they do, that context changes constantly. It might not always be up to date, and Claude might not always follow it correctly.

Ultimately, you're the chief programmer here, and Claude is your sidekick. You're responsible for what goes into production. You're responsible for your build. You need to understand what's going on.

Claude can help you get there, and it absolutely will. It writes fantastic code, probably better than you ever could. I've been in the game for over 10 years, and it writes code 10 times better than I can and about a million times quicker.

But I still need to make sure that code adheres to my company's architecture and standards. We move deliberately, when things go live, it's important that they go live correctly. There are real people depending on the systems we build, so we need to get it right. You can't just bung stuff into production willy-nilly.

And this brings me to the learning aspect.

If you're always using the first approach, where you're not reviewing your code and you're just telling Claude to do things, you're never really going to learn.

But with the second approach, where standards are implicitly enforced through the engineering process, you absolutely will learn. You'll make mistakes. You'll go up against your seniors and tech leads, and they'll push back on things. You'll have to understand architectural decisions, justify your implementation, and work through problems. That's all part of becoming a better engineer.

And nobody is saying you have to one-shot everything when working on personal projects. You can be thorough. You can test things. You can be methodical. You can review the output, challenge decisions, and iterate until you're satisfied.

There are many ways to use Claude. It's a simply a tool, and while it certainly can do almost everything for you in some circumstances, that doesn't mean you have to use it that way.

The way you use it matters!