I haven't written a line of code in over 5 months now.
At the start of the new paradigm I was reading a lot more code, and I think it was making me better at the craft of coding. I'd see best practices used in languages I was unfamiliar with to solve a problem that I had articulated. I was reading code where I understood the intent and I was working backwards to understand the implementation. A few months in I started to trust the generated code more. The sense that I was sharpening the craft of writing code gave way to the sense that I was losing it.
Now, for many personal and professional projects, I hold a mental model of how all the pieces fit together, but it's not grounded in having read the actual code. It's grounded in the conversations I've had about how the system works. Sometimes that understanding has diverged from reality, either because I misunderstood something or because a question I asked got answered incorrectly.
It feels like I've stepped up the management chain: less time writing code, more time articulating what I want clearly enough, more time in conversations about what got built. But I don't think the core of the work has changed that much.
Designing Things
If I'm honest I was never a great software engineer, it was always a means to an end. I began my career in R&D where I was mostly following my curiosity and testing if an idea worked, and code was the tool I used to do that. Through working with some brilliant mentors and being humbled in numerous code reviews I eventually learned a little more of the craft of coding. I now sometimes get handed research code that needs to be moved to production and feel a pang of nostalgia as I'm trying to figure out where to add the error handling.
Most of the architecture work I've done has been around answering questions. In most companies those questions start with money:
"How much will it cost to run this new model?"
and then break down into smaller sub-questions:
"What compression do we need to get X many video frames from Y cameras to be decoded on a server with Z CPUs?"
"How many GPUs do we need to process X many video frames?"
"What is the optimal batch size and model instance count for this model architecture on this model of GPU?"
Answering them gives you the raw data you need to make decisions about how to build a system. Running experiments to answer these questions is probably how I spend >80% of my time when doing architecture work. There is of course other work involved, but these experiments have some of the largest impact on the final architecture of a system. Most of the code written to answer these experiments is thrown away, but the knowledge gained from writing them is retained. I've worked on greenfield projects where we spent a few months running these types of experiments and then only spent a week or two to build the system. When done well the systems that resulted from this process were minimal & beautiful.
Prove why a design decision is correct, don't speculate.
As far as I can tell this hasn't changed under the new paradigm, the work is still figuring out what questions we need to ask and running the experiments to get the answers. Code is now cheaper to write and throw away, we can run more experiments quicker and hopefully iterate to something better.
The other side of the coin with code being cheaper to write is I rarely see code being removed. Problems are solved with speculative additions. End-to-end tests & performance metrics are often harder to write (especially any that involve humans in the loop), but with wide-ranging additions being so cheap to make, it's more important than ever to have them. Otherwise your systems will balloon in size and complexity and become harder to reason about.
I don't know how to review PRs anymore. You open the diff and see ten thousand green lines added to an already complicated system. New functionality, new abstractions, new dependencies. The code might work, but the harder question is whether it should exist at all, and how do you prove that?
In a pipeline with a subjective quality measure, a media processing chain, an AI model, anything where the output is "does this feel right," measuring the impact of a change is hard. Even objective metrics get hard when the end-to-end tests aren't in place, or when running them needs a human in the loop, or physical hardware, or both. The change in front of you might be a real improvement, might be neutral, might be a regression that no one notices for three weeks.
What's the end-to-end impact of this change? What metrics are you using to measure that? What's your sample size? Is the test you're pointing me at actually exercising the thing you changed, or just the thing you added? You need to be both a data scientist and a research engineer now, designing the experiment that proves the change earns its place, and rigorously measuring the result.
Prove why additions are needed, don't speculate.
When I was first told "every line of code you write is a piece of technical debt that you're adding to the system" it crystallized a lot of the frustrations I'd had with my own work and pushed me to build simpler systems. Systems that solved the immediate problems and didn't speculate about future problems. The new paradigm is challenging this for me in strange ways. I'm still trying to build for the problem in front of me, but code feels so cheap.
I recently trained a MIDI generating LLM as a side project. I'd written it in Python, then spent a few hours porting it to run in the browser with WebAssembly, and then to C++ so I could run it on an STM32 microcontroller with a neural accelerator. Each port unlocked a different way of interacting with the thing I'd made. The browser version let anyone with a web browser play with it without costing me any compute. The embedded version opened the possibility of a dedicated hardware synthesizer. Two wildly different product directions, both trivial to explore.
Probably one of them, maybe both, I'll never touch again. In the old framing that's three weekends spent on dead-end ports, code I've taken on the maintenance burden of. In the new paradigm it's cheap exploration, code that exists and doesn't matter.
The ability to try an idea, fail quickly, and pivot is faster than ever, and I think what's actually changed is where the discipline lives. It's not in writing less code. It's in deleting more of it. Pruning your git tree so that your context window doesn't fill up with dead ends and experiments. Proving that each addition is valuable and measurably improves your system.
Debugging Things
I started my career in the broadcast industry where once or twice a year I'd work on some kind of live production. Snakes of cables would wind their way from a stage to a cramped port-a-cabin around the back of the venue. It would be filled with the fan noise of some experimental broadcast system whirring away in a server rack. There would be a huddle of engineers standing around broadcast monitors and computer screens frantically debugging things as the clock counted down. We'd have to be ready to capture what was happening on stage when it started happening. No ifs, buts, or maybes.
It left me with a taste for a good SEV. You have to bring calm, focused, methodical problem solving into a stressful situation. You have to act as an information filter, sorting facts from assumptions, organizing information as it comes in and using that to form hypotheses about how a system might be broken. Testing those hypotheses and integrating your findings back into the pool of facts you're using to synthesize new ones. I love a good Agatha Christie mystery and this tickles the same part of my brain that loves an unraveling mystery, the amassing of proof that lets you reach a conclusion.
The new paradigm is both a blessing and a curse to debugging.
The curse is that Claude presents facts and assumptions with the same confidence. You read a line of reasoning, it sounds right, and you don't always notice the assumption the chain rests on is a guess about how the code behaves. The chain builds on it, you build on the chain, and before you know it you're going in circles with no sense of where the wrong turn was. The way I find out is usually by interrogating the model about why it tried something, and watching the justification dissolve.
The defence I've landed on is not very subtle. Give it everything. All the logs, all the error messages, screenshots of metrics graphs, anything concrete about how the system is behaving. It eats context fast and triggers compaction more often than I'd like, but it makes it harder for an assumption to slip into the chain and pass itself off as a fact. When you ask why a decision was made you can ask Claude to point to the data the decision rests on. I find myself building quick tools to make this easier, throwaway Python scripts that produce spectrograms of audio data, anything that turns the system's behavior into something inspectable.
Over the 2025 holidays when it felt like the new paradigm began to take hold I was debugging the firmware for a synth engine I'd been working on, one of my last hand-written pieces of code. I was seeing glitches in the audio output on my oscilloscope, and I couldn't figure out why. It was one of those problems that was pulling the joy from the work. Out of a mix of frustration and curiosity I hooked a debug probe onto the RP2040, plugged my oscilloscope into my LAN so I could pull screenshots from it over the network, and pointed Claude Code at it.
I watched as my code got rewritten, the lights on my debug probe flashed as the code was loaded onto the circuit board, and the oscilloscope made a clicking noise as it captured a screenshot of the waveform. This cycle repeated a few times as I sat watching it. Unceremoniously the problem was solved. The synth engine worked. What might've taken me hours of frustration at best, or joined the pile of abandoned projects at worst, was solved. My focus was back on the parts that felt fun.
I think this worked because I'd built a loop that could be iterated on. I'd articulated the end state, remove the glitch that periodically drops the output to zero. I'd given the model the tools to make changes, the code and the debug probe. And I'd given it a way to measure success, the oscilloscope screenshots. It was harder for Claude to make assumptions about what does and doesn't work when after each change it could see the impact.
Concluding Things
I'm in the process of changing jobs, and there's something wonderful about calling old colleagues to ask them to be references. I get to check in with some of the smartest people I know and catch up about how their personal and professional lives are going. There's electricity in the air. Everyone is figuring out how to do the work in this new paradigm. There's less cynicism than I expected, and more excitement. People have been telling me about experimental projects that used to need management approval getting finished in a lazy afternoon and already shipping. About the personal project they had shelved being picked back up and revisited through this new lens.
I'll be moving back to a startup from the relative comfort of a large organization. It seems like a mad time to be doing it. The tech sector is up in the air, and I have a job that should weather the storm for at least a few more years. But the pull of getting to play in this new paradigm in an environment where my work can have such a direct impact on the success or failure of a company is incredibly alluring. That live production energy, the feeling of being cramped in a port-a-cabin with smart people solving problems to a deadline.
The craft of my work has been changed forever. The work itself hasn't changed. Gather data, hypothesize, prove it, build, ship.
