AI Can Write The Code -- What Part Do You Keep?

Dev Leader Weekly 154

Aug 24, 2026

TL; DR:

AI changes the work, not your interests
Keep the parts that energize you
Offload friction without surrendering judgment
Join me for the live stream (or watch the recording) on Monday, August 24 at 7:00 PM Pacific!

AI Can Write The Code -- What Part Do You Keep?

There is a version of the AI conversation that is mostly about fear: Are software engineers getting replaced? The question that caught my attention from the ExperiencedDevs subreddit was different.

This developer was not primarily worried about losing their job. They were worried about losing the part of software development that made them care in the first place.

They can hand increasingly complex work to an LLM and get something useful back. That’s impressive, but it also leaves them wondering where they fit into the process. The building, the problem-solving, and the feeling of making something are starting to feel different.

I’ve talked before about how AI career fears are evolving, but this is not just another replacement-anxiety discussion. This is about engagement. If AI can perform more of the work, what part of the work do you actually want to keep?

You can check out my full thoughts on this in the video below:

I Would Start With Questions, Not A Prescription

If I were talking directly to this person, I would not jump straight to, “Here’s the best AI stack,” or, “Here’s the correct way to stay motivated.”

I would ask questions.

What part of software development used to pull you in?
Was it exploring a hard problem before the solution was obvious?
Was it designing the system?
Was it writing the implementation yourself?
Was it learning an unfamiliar technology?
Was it simply seeing an idea come to life?

Those answers matter because two developers can do the same job and love completely different parts of it.

I’ve had people tell me they genuinely enjoy working in legacy codebases. They like the constraints. They like figuring out how to move one piece without breaking five others. Someone else might look at the same situation, read about dealing with legacy code, and think, “Please let the AI handle all of this.”

Neither person is wrong. They are motivated by different challenges.

The Industry Is Optimizing For Throughput

My own experience with AI coding tools has changed quickly. Not that long ago, I could hand over a non-trivial feature and the result was somewhere between, “Cool, that worked,” and, “I just created more work for myself.”

There were tasks I would not even bother delegating because I expected the back-and-forth to cost more than doing the work myself.

That line keeps moving.

The models are more capable. The tools around them are better. Skills, instruction files, custom agents, and stronger development harnesses let us provide useful context without manually writing a 400-page specification for every task.

I do not think “one-shot everything” is a useful goal by itself. I also do not think the future of software development is engineers spending all day writing absurdly detailed specs. But the direction seems clear: AI is taking on more ambiguous work with less explicit supervision.

That means organizations will keep looking at throughput. If one person can move several workstreams forward with AI while another person insists on manually completing every step, there may be pressure on the second person to change.

That is not a moral judgment. It is a constraint worth acknowledging.

I’ve shared some of my real GitHub Copilot CLI workflows on a C# codebase, and the benefit is not that I can avoid thinking. The benefit is that I can spend more of my thinking time where it has the most value.

Find The Zoom Level You Actually Enjoy

I think about software development at different “zoom” levels. It’s actually something I apply when thinking about codebases, system architecture, workflows... and even careers!

At one level, you care about the exact loop, condition, and method. Zoom out, and you care about how the classes collaborate. Zoom out again, and you care about service boundaries, data movement, and the shape of the system.

Some people love the implementation details. Some love the architecture. Some love experimenting in the problem space before any architecture exists.

For the developer who raised this question on the original Reddit post, it sounded like the early problem-solving pass might be the part they want to preserve. They want to explore the difficult problem themselves and bring in AI afterward.

That can be a completely reasonable operating model. The important part is understanding the tradeoff. If that early pass becomes the bottleneck while everything around you is optimized for throughput, you may need to adjust how much of it you keep, how long you spend there, or what you hand off afterward.

Actionable Tip: For one week, keep two short lists:

Work that gave you energy
Work that drained your energy

Do not write broad labels like “coding” or “meetings.” Be specific. Was it shaping an API? Untangling a production issue? Writing repetitive mapping code? Reviewing a design? Learning a new domain?

Patterns will show up. That kind of reflection matters well beyond AI, and it is part of building a career that fits how you are wired.

Let AI Take The Friction

Once you know what you want to keep, look at the rest of the work.

Maybe you hate writing boilerplate. Maybe tests, observability, or security reviews are the tasks you procrastinate on. Maybe you love designing a feature but lose all momentum when the implementation becomes repetitive.

AI can help with those parts, but “give it to AI” is not the same as “stop being responsible for it.”

If I want an LLM to handle work that I do not enjoy, I still need to set it up to succeed:

Explain the outcome, not just the task label.
Provide the constraints and relevant context.
Define how the result will be checked.
Review high-risk decisions instead of trusting plausible output.

Otherwise, I have not removed the frustrating work. I have replaced it with babysitting an agent that keeps producing the wrong thing.

The goal is not to surrender judgment. The goal is to reduce the mechanical effort around the judgment.

What I Actually Love About Building Software

This thought exercise made me look at my own patterns.

Historically, I have loved building frameworks and reusable systems. Many many moons ago, I built UI framework experiments in XNA and Unity. I have spent time creating ridiculously overcomplicated libraries that almost nobody would use, sometimes including me.

Why? Because exploring the shape of those systems was fun.

The same pattern shows up in things like BrandGhost and Needlr. BrandGhost started because I needed a tool as a content creator and wanted to build it. Needlr grew out of the way I liked structuring C# applications. Both gave me a chance to take an idea, shape it, and watch it become real.

That is the key for me: I like seeing ideas come to life.

I care about technical direction. I care about architecture. I care about patterns that will create headaches if they spread across a codebase. I do not feel emotionally attached to writing every if statement or choosing between a for loop and a while loop.

For a long time, writing all of that code was simply the price of admission.

There was also an almost inevitable point in some side projects where the design ballooned, I realized I needed to undo earlier decisions, and the recovery work felt bigger than the fun part. Historically, that could be where I abandoned the project.

AI changes that balance. It can help me refactor, recover, and fill in the mechanical pieces while I stay involved in the direction. That’s a big reason I still build side projects. I can explore more ideas without every idea demanding the same amount of manual implementation.

AI Can Expand Your Range

There is another benefit here: AI can help you move into areas where you do not have deep experience.

I had an agent put together front-end work for a private dashboard. I could inspect whether the behavior made sense. I could check whether the tests exercised real code instead of a fake system under test. But I did not have years of front-end experience that let me confidently debate every pattern in the implementation.

Without AI, I might have needed to learn an entire stack just to build a dashboard I needed. Blazor has often been useful to me for a similar reason: I can bring my C# experience into web UI work. AI gives me another way to cross that gap.

That does not instantly make me a front-end expert. It lets me produce something useful while being honest about where my judgment is strong and where I need more help.

The same applies to learning. I love the feeling of having learned something, but I am often uncomfortable at the beginning of a new challenge. AI can launch research in parallel, summarize a domain, and give me enough footing to start asking better questions.

It lowers the barrier. I still have to engage with the result.

Build A Personal Operating Model

There is no universal percentage of software development that you should keep for yourself.

Instead, build an operating model that reflects your interests, your role, and the risk of the work:

Keep the work that gives you energy and develops judgment you want to retain.
Co-pilot the work you enjoy but can accelerate with feedback or parallel exploration.
Delegate mechanical work where you can define a clear outcome and verify it.
Review decisions involving architecture, security, data, and other expensive failure modes.

Then revisit the model. AI capabilities will change. Your role will change. The parts you enjoy may change too.

Actionable Tip: Pick one task you routinely dislike and improve the handoff to AI. Add the context, examples, constraints, and checks it was missing. Do not expand this to everything at once. Prove that the handoff actually saves time before you depend on it.

Humans Are Still In The Picture

I am not convinced the destination is, “People disappear and AI builds everything.”

My expectation is that people become much more amplified by AI and whatever tooling grows around it. I do not have a crystal ball, and I am not going to pretend that I know exactly how every software role changes.

But even in my own projects, the valuable part is not just code appearing faster. It is being able to explore more directions, recover from mistakes that previously killed momentum, and focus my attention on the parts where I have something meaningful to contribute.

That still requires a person deciding what should exist, what good looks like, and which tradeoffs are acceptable.

Wrapping Up

If AI could take over one part of your software development work tomorrow, what would you be relieved to lose?

Now flip it around: what part would you genuinely miss?

That second answer is the important one. It tells you where your interest lives. Keep enough of that work to stay engaged, get better at it because you care, and use AI to reduce the friction around it.

You do not need to reject AI to preserve what you love about software development. You need to be deliberate about where you fit into the process.

Dev Leader Weekly

Discussion about this post

Ready for more?