If you are a software developer in 2026, there is a good chance your daily workflow looks something like this:

• Pull up a ticket/task/story
• Read it, think about how to fulfill the requirements
• Feed Claude Code the ticket, manually or via MCP
• Add additional prompting for how you’d like the ticket completed
• Hit the go button
• Scroll your phone while Claude does its thing
• Review the output, either in IDE or in a PR
• Prompt again until the output is to your liking, maybe even manually tweak it
• Send PR off to coworkers for review
• Onwards to the next ticket!

Maybe you skip the second step. Maybe you don’t really review the generated code. Maybe you’re reading this and thinking, how quaint because you have 50 agents doing it all for you entirely, and you’re mostly doing the sixth step.

The point is: an LLM-based workflow is now how you produce the majority of the code that gets merged under your name. This is how much of my own work is now accomplished.

Let’s compare this to the halcyon days of 2021, when there was no Claude Code, but there was ZIRP and a lot more junior React developer jobs. My day back then as an IC looked more like this:

• Pull up a ticket/task/story
• Read it, think about how to fulfill the requirements
• Open IDE and either create a new file or find the appropriate file to start working
• Write code
• Write code
• Write code
• Keep writing code until I feel the ticket is satisfied
• Send PR off to coworkers for review
• Clock out because that took you all day

Increasingly, I’ve noticed an attitude among developers that the third through seventh steps of this old workflow are that of ancient history. Manually writing code is dead. Only luddites are still writing code by hand. And this: that the job of a software developer is shifting not from someone who writes code, but to someone who “architects” and “designs systems.” Each of us has become Imhotep while we direct a workforce of agents to build our pyramids (testing and otherwise).

Have you ever worked on a team that had a dedicated architect? Someone whose job it was not to muck around in the code trenches, but to sit above and do important things like draw little boxes of different shapes connected to other boxes by lines, some solid and some dashed?

If this person did their job well, their impact was likely largely invisible. If they did it poorly, that would probably really, really obvious, because the product and maybe company blew up. And if they didn’t do anything - that counts as doing it poorly. There is one commonality I’ve noticed in my career amongst architects who did the job well: they had a good understanding of the codebases that were created to carry out their vision. Conversely, architects who were entirely hands-off and did not day-to-day work of the developers seem to uniformly fail.

The excellent read Architect Manifesto by Oskar Dudycz has this as a key point: Architecture team should also work on the business features. This does not mean the architect should be ripping through tickets at the same pace as an IC; it doesn’t necessarily mean they should be involved with the more complex code the project requires. It just means that they need to be close to the code. They need to 1) get their hands dirty and occasionally write code, and 2) have a reasonable understanding of how the different modules used in the codebase(s) work together.

In the new world, where our team of ICs all have the name Claude, this is more important than ever. If you want to be an architect guiding a team of Claudes, you need to know a significant amount about the code they are generating. You should even get in there and do some of the work - write some of the code - yourself.

But why?

Let us start with an analogy: visual art. If you know how to draw, your medium a pencil and paper, you will not become better at drawing by using Nano Banana to make your work. If you don’t draw anything for a year, you will probably end up worse at drawing. Drawing is a skill: skills that are not used atrophy.

Code is the medium of software development. Writing code is like drawing with a pencil. It is a skill that must be practiced and cultivated, lest it wither away.

And wither away it will.

Recently, I was working on a side project that involved a local first architecture, with RxDB and Dexie.js. I embraced mass code generation for this project. My goal was not to make high-quality production software, it was to get a cool MVP working quickly, for a useful tool that I’ve been wanting.

By the time I felt satisfied with the MVP product, I had probably written about 20% of the code myself, and much of that was reorganizing and refactoring. The rest - including the core local first parts - were from Claude. And it worked! It works great. The product does what I want it to.

I started thinking about sharing this with other people. I even started thinking about hmm hey what if people might pay for this? could I…monetize??

Right about then I discovered that all the data for the account I’d been logged in under had disappeared. This was a sev 0, game-breaking bug that meant every user’s data would be wiped out every time they logged out and in.

I could have Claude try to fix this. Actually, I did, and it totally failed to, which is normal and fine, it often takes several iterations to fix big bugs with LLMs. Then I got the message that my tokens were up, I’d have to wait until 4pm for more. Blast!

No problem - I’m a software developer, I know TypeScript, I can go fix it myself. I opened up the likely culprit, where the sync between local and remote data happened, and realized: I have absolutely no idea what I am looking at. I have no idea how this library really works, or what this code is really doing.

Skill issue? Maybe. But it got worse: I realized that I didn’t really even know where or how to start debugging this properly. My skill to work with local first had, effectively, atrophied away, in just the few short weeks between me starting to learn about it and then offloading all of that to Claude.

I was a bit too embarrassed then to show my project to anyone, and I definitely was not ready to even think about asking people to pay money for it.

I architected the project; I made all the key technical decisions about what libraries to use, how features should work, what level of test coverage we should care about. I knew at a high-level how its sync loop should function. And yet I was still entirely useless when it came to actually making the damn thing work.

There is another way this project could have gone. I could have adopted a much slower pace, and worked with Claude to build the app piece-by-piece, taking the time to understand the code every step of the way. Had I done that I am confident I would have been easily able to debug the issue.

Here then is the argument I am making: writing code makes you a better software developer. This remains true even though we now have tools that can offload the majority of code we need to write. Actually it’s now more true than ever.

Every software developer out there who uses LLMs in their workflow should ask themselves: if these tools all disappeared tomorrow, would I be ok? Could I still create software?

If the answer is no, or if the thought of that scares you, then I would strongly encourage you to try writing some code without an LLM. It’s not that bad, I promise.

(Frankly, I know the answer to that question is a resounding no for many people, because I’ve seen it in interviews - developers who generated all of their code and couldn’t explain it beyond the surface level, or talk about why they made certain decisions.)

I would never want to work under a software architect whom I would not be confident could, if required, jump into the code under their supervision and fix problems with it, and add new features to it. Would you?

Don’t make your Claudes work under someone like that.

Humans must practice the skills we wish to master. We must practice them a lot, day in and day out. The core skill of creating software is coding. Programming. Writing code.

There is a place where this may not really matter. Personal software, stuff that just has to kinda work and has no stakes? Sure, you don’t need to know how the code works there. But for software systems that do matter, it’s critical that the humans working on them understand the code.

There is a whole lot more that can be said on this topic, especially in the more abstract realm of how being able to write good code correlates pretty directly with one’s ability to problem solve, which is the true responsibility of software developers. There is a lot to be said about how moving up levels of abstraction adds more nuance to this than I’ve included - but that’s another post entirely.

The software developers who will come out the strongest from the changes AI tooling has brought us are not going to be those who have entirely traded the medium of their craft for prompts. Nor are they those who refuse to engage with LLMs at all. They are those who know how to move fast with AI, while refusing to willingly give away their mastery of code.

I’m going to fix that critical bug in my app. But first I’m going to have to understand the code. And that means writing some code.