Developer or AI Manager?

I've noticed something changing in the way I write code.

I still code, obviously. But more often now, part of the job looks like this:

1. Explain what I want.

2. Give an AI tool enough context.

3. Let it generate something.

4. Read the code carefully.

5. Figure out what it misunderstood.

6. Ask it to fix part of it.

7. Run the tests.

8. Then sometimes rewrite the important bits myself.

And that made me wonder:

Are developers slowly becoming managers of AI agents rather than people who primarily write code?

I don't mean that coding is disappearing.

If anything, understanding code feels more important when you didn't write every line yourself.

You still need to recognize a bad abstraction, question an architecture decision, catch a security problem, understand why a test is failing, and decide whether the generated solution actually belongs in the codebase.

The difference is that typing code may become a smaller part of the overall job.

A developer could spend more time describing problems, providing context, reviewing changes, coordinating multiple agents, and deciding what gets merged.

That sounds less like traditional programming and a little more like technical leadership.

There's also an uncomfortable question here.

If AI writes more of the implementation, how do junior developers build the instincts needed to review that implementation later?

A senior engineer can look at generated code and say, This technically works, but this design is going to hurt us six months from now.

That judgment usually comes from years of writing code, breaking things, debugging production issues, and maintaining systems.

So I'm curious how other developers are experiencing this shift.

• Are you actually writing less code because of AI?
• Has reviewing AI-generated code become a meaningful part of your workflow?
• Do you think prompting and managing agents will become normal software engineering skills?
• And if developers write less code themselves, how should newer developers build strong engineering judgment?

I don't think the interesting question anymore is whether AI can code.

It clearly can.

The more interesting question is what our job looks like when it can?

Comments

[Jason Lu]

One useful shift is to treat generated code as a draft that must earn its way into the system: ask the agent to state its assumptions, then verify them with tests and a small manual review. For juniors, the missing foundation can be built by owning small features end-to-end—including debugging failures—rather than avoiding AI entirely. The judgment comes from comparing intent, implementation, and behavior, not just from typing every line.

[Sushyam Nagallapati]

@jason_lu_0178cf6b579997fb That point about junior developers owning small features end-to-end resonates strongly. Treating AI outputs strictly as proposed drafts forces real critical thinking, which is where true engineering intuition gets built.

If juniors rely on AI to generate most of the implementation details early on, what specific signs or milestones do you look for to ensure they are actually developing that core judgment rather than just steering the tool?