When Machines Code Better
It’s 6:07 AM. My only company is a warm mug of strong and sweet coffee, Starbucks dark roast and hazelnut creamer poured. And I’m looking at a messy code base, several thousand lines of Python scattered across, you know, a dozen files, and describing it. Today’s goal is simple. I want to take this brittle, hand-wired collection of data transformation pipelines, and I want to turn it into this clean, modular DAG. I can actually describe the changes fairly specifically, but it’s brutal to pull everything off because every file needs to change.
Every transition, every step needs its own file. The logic of the stages, you know, from transcribing to video formatting, will stay the same, but they need to be extracted cleanly into their own files, into their own functions. And the existing tests, as far as I can tell, except for a couple of end-to-end ones, are probably a write-off because I’m totally changing the structure of how everything calls everything else. So I type claude --dangerously-skip-permissions into my terminal, and I start dictating. I start describing the refactor, what the end state is gonna look like, right? How everything should be organized.
Then, I copy over a type signature and some key files I want it to look at, and I hit enter, and I’m off to scrolling Twitter, learning about some controversy about some genes ad that I don’t really understand. But 19 minutes later, every test is green. I mean, there are very few of them left, but the end-to-end ones are working, and the folder structure is completely transformed. Claude ran the linter; it cleaned up the code. Everything is working. I mean, it didn’t update the README.md; it left behind outdated instructions, and it left a bit of dead code because I had this section that called Whisper locally that I was no longer using.
And so it missed it. But otherwise, the change was flawless. I had been worried about this refactoring. I knew I had to do it, but it felt so big, with so many changes that I just didn’t want to get into it. But here it was done. I was in the new state, and I thought to myself, did I just automate myself out of a job? Are we all automating ourselves out of jobs? That’s what I was thinking. And so, right then, I was excited but scared, and I made a snap decision about how I work. I’ll get to that in a bit, but what I did is I opened Roam, my note-taking app, and I jotted down a single line, a very important thought that has been guiding a lot of my work ever since.
Hello, this is CoRecursive, and I’m Adam Gordon Bell. Last episode, I shared how excited I was about coding agents, and I’m still excited. I really am, but I’d be lying if I didn’t mention how, you know, I do have some fear as well. And there’s this Scott Alexander story that I read years ago, and it kind of nails exactly what I’m worried about. Here’s how I remember it.
The Whispering Earring
There’s this magical topaz earring, and it’s locked away in a museum vault to keep everyone safe from it.
If you put this earring in your ear, it whispers to you, “You’d be better off taking me out.” But if you ignore that advice, that’s when things get interesting, because whenever you wear the earring and you have a choice to make, it whispers in your ear, telling you exactly what to do, and it’s always the best decision every time.
If you’re stuck choosing between two jobs, the earring just tells you which one to take, and it’s never wrong. Over time, people found that the earring was always right, and so it makes the wearer’s life better in every possible way. And the more you wear it, the more you get used to it.
And the earring doesn’t just stop at big choices. It chimes in about breakfast, what to say to your friends, and how to give a speech. And even, you know, when and how to move your arm. It’s always there, working to give you exactly the advice that you need. Except then, when you die after an abnormally happy and successful life, you, the earring wearer, are found to have no prefrontal cortex left. You have long since let your brain atrophy away as the earring makes every decision for you. You have long since become its puppet. You got everything you wanted, and you made the decisions that gave you the most happiness.
But were you still you?
That’s why the earring stays locked up and out of reach to keep us all safe.
Lines in the Sand
Sound familiar? The earring is what life looks like if you relinquish everything to AI. It’s a life without integrity standards. Integrity standards are those lines I jotted down in Roam, and I’ll get to later. But I mean, it’s crazy that this story was written in 2012 because it could not be more relevant today.
That’s what we’re digging into today because after the last episode about my excitement about coding agents, I got a lot of questions and comments from people like, “How do I keep learning if an agent does all the work? What skills are actually worth building now in this new world?” Right? Have the value of skills changed?
And honestly, like, will I even have a job in the future if all my job is now is hitting “Accept All” on some generated code like I was doing with Claude that morning?
These are great and honestly kind of scary questions, and we’ll dig into all of them. I’ll share how my experience working with Claude Code pushed me to set some rules and to change the way that I work. But first, let’s talk about why just moving faster, letting coding agents do the heavy lifting, and going as fast as you can can actually be a trap because it can be like running on a treadmill.
Everyone’s sprinting, but no one’s actually getting anywhere. That treadmill has a name. It’s called the Red Queen Race. And the clearest example I’ve heard of it starts with a two-income family who thought they found a way to improve their lives.
Racing to Stay Still
So, back in 1999, the Parkers could support their whole family on just the husband Mark’s income. There was some breathing room–his wife Joan stayed home, so no daycare bills. Their mortgage was manageable, not some wild stretch. If Mark lost his job, or they needed some more cash, Joan could pick up shifts; she had work experience, so they had a safety net. That kind of setup was already getting rare in their neighborhood, but it still worked for them.
But in 2007, they followed the advice everyone gave. Joan went back to work, and suddenly their income doubled. Back in 1999 their $1,000 mortgage felt breezy; by 2007 they were wiring nearly $4,000 to the bank every month just to stay in the “good-school” ZIP code. But they could now swing more vacations and pay for daycare for their second kid.
A few years go by. Suddenly, their finances are tight, tighter than before. Even though they’re earning more now than 1999–they need both incomes just to keep up with what they used to afford on one. Their paychecks had doubled, but their extra cash on hand actually shrank. Everything feels more expensive. And it’s not just them. The world changed.
And then if one of the Parkers gets laid off, or has health issues, things go bad. The Visa balance hit $23,000 at 19.9% APR, the bills pile up and bankruptcy becomes possible.
This example comes from Elizabeth Warren’s book, “The Two Income Trap: Why Middle Class Mothers and Fathers Are Going Broke.” It’s not a book about politics. It’s a book about how chasing efficiency and status can make the whole system shakier for everyone.
More Money, Same Place
But it’s a real thing that played out, it went like this. Families went from one income to two, and suddenly there was more money coming in. So you think life would get easier, but when everyone’s income rises, certain things like housing just get more expensive to soak up that extra cash.
Back in the seventies, most households had a single income. Now most have two, especially if there’s kids. But that extra money didn’t mean even bigger savings or even more comfort. It mostly went to paying for a place to live. If you wanted to stay in a good neighborhood, there were only so many houses, and so prices just rose to match what people could pay.
Housing is what economists call a positional good. There’s only so much of it, so the price goes up as people compete. Elizabeth Warren also points out that higher education is another positional good; parents want their kids in good schools, but there are only so many spots.
So when families have more income, schools raise tuition, and families are able to pay. So all that extra money eventually from having two income earners got eaten up by housing and by educational costs.
So after 30 years of this, you end up needing two incomes just to cover the basics that used to be able to be covered by one. Housing and school for your kids ate it all up, and you’re just right back where you started, except now there’s less slack; you both need to work just to get by.
That’s not to say that life hasn’t improved. We have better tech, we have iPhones, we have air conditioning, but those upgrades are a different story. They’re unrelated to the switch from two incomes and the subsequent ballooning of the positional good costs.
Why This Matters Now
I am bringing this up of course, because of coding agents. We’re in this moment where writing simple code is easier than ever. Maybe not in every tech stack now, but it’s coming. And suddenly we’re in a spot like the families who went from one income to two; we can produce more. Writing code isn’t the bottleneck it used to be.
Code is cheaper to produce, and that gives us extra capacity, just like the Parkers had when they both started working and they had extra cash, extra slack. So what do you do with that extra capacity, if you just use it to crank out features as fast as you can, to pile up code?
You end up in a Red Queen’s race, everybody running faster just to stay where they are. People will love you for a while, but I think there’s a trap here.
And so it’s worth thinking twice before you fall into this trap.
The Speed Trap
If you’ve ever worked in enterprise software, you might know what I’m gonna talk about. Sales often hinges on RFPs, and to win, you need to check off a long list of features. Every new feature becomes ammo for the sales team to close another deal. So there’s always this push for more features, and the people buying the software aren’t necessarily the ones that have to use it every day.
There’s a couple layers of indirection there, so you end up with these weird incentives. There’s always pressure to add new features, but making them fit together or building something that people can actually use, things that people actually need, that doesn’t always matter as much as getting the new features in.
So you get a spreadsheet of checkboxes, and someone has to crank out a button to do an “export to XML,” and they need to get it done in 48 hours so that we can get the deal. And the button barely works, and the customer doesn’t even use XML exports, but the competitor has that feature, and they aren’t gonna choose you if you’re not at feature parity, even though your product’s better.
So you need to add it. You need to win the RFPs, and your competitors need to win it as well. So you compete on who can add the most features, who can add the most checkboxes for the least amount of money.
Automation Meets Assembly Line
The derogatory term for this, right, is a feature factory. You’re just cranking out features. Most engineers are just picking up tickets and moving quickly through them, one after another. That’s the core job. Just keep the queue moving, just keep adding features. We need to keep up. We need to catch up.
So say you bring coding agents into the mix. If they really do help you work faster, any extra breathing room they give will quickly disappear because the pace will just pick up.
You might be thinking for a while, “Wow, I’m getting so much done and barely breaking a sweat,” but turning out features faster will just become the new baseline. The pace that everybody will expect from you has just increased because your company is now racing against every other feature factory out there, and they’ve got the coding agents too.
So suddenly just keeping up means shipping features way faster than you did before, right? That’s the Red Queen’s race. You can now run faster, but so can everybody else. So now you need to run faster just to stay in the same place and win those contracts.
If you’re a software developer and your job is mainly just cranking through tickets as fast as you can, that’s a problem. I think if anything about the feature factory story sounds familiar, I think it’s a dangerous time. You need to be vigilant if you spend most of your time working on tasks in a big codebase that don’t really make a lot of sense to you, or you’re not super clear on how the product works and how it’s improving people’s lives. It’s a bad spot to be in if you’re just going to focus on speed instead of asking, “How can I blast through these tickets as fast as possible with a dozen coding terminals open?” But yeah, it ties back to what I jotted down in my Roam notebook, which centers around this idea of just careful thought.
When Thinking Becomes Optional
Brian Kernighan once said that the best debugging tool is still careful thought and a few well-placed print statements.
This is a controversial quote, often used to criticize the use of debuggers, but I have found it to be true. Back when I was working in C# I used debuggers all the time. If something broke, my first move was to set a breakpoint and step through the code.
You know, F10, F10, F10. Until I got to the state where the bug happened and it worked, but it could get kind of mindless sometimes. The debugger was the only way to solve a problem, right?
But many times I could have solved it without the debugger. If I had spent some time thinking, debuggers are powerful. No question, right? But when a tool does all the heavy lifting, it’s easy to stop thinking deeply about what’s going on in your code. I would just jump to the breakpoint and look at the state who wants to do the hard work of thinking through the code execution.
That’s why Brian’s point, I think, is less about the print statements and more about taking the time to really think through what’s happening in your code. He’s saying you should pause and consider what’s going on, exercise that mental muscle by working out the problems in your head. That’s why you sometimes see really skilled programmers who completely avoid debuggers. Debuggers are super helpful at helping you solve problems faster.
But if you force yourself to reason through issues without them, it can build a long-term skill. Similarly, I’ve found myself at the command line before, like mindlessly hammering the up key, trying to find an old command, sometimes 20 presses up just to get to git commit –amend.
I could have typed that out myself, but I wanted to be efficient and I was being lazy. But that’s when skills start to slip
and I see it happening to myself with coding agents too. I type in the description for a quick code change, change this to that, and let it edit it, even though it would’ve been just as easy for me to do it myself.
The easier it gets to automate things, to look things up, the less I have to think. And it’s always tempting to not think, but this act of retrieval, this act of thinking, it’s where real learning happens. It’s harder, but if we skip it too often we risk going on autopilot. Whenever something you’re doing is becoming mindless. I feel like there’s danger there.
I have a strong sense of this danger because of my current job working in developer relations.
Playing Developer on TV
Developer relations is not always easy. I work at Pulumi right now, and if you haven’t heard Pulumi, it’s a tool that lets you spin up cloud servers using Python or whatever, programming language. But I don’t work on the Pulumi product itself. I show people how to use it.
There’s this criticism about developer relations, whether it’s called, you know, DevRel or dev evangelist, or builder in residence, or community engineer, which is my current title.
The criticism is that the people in this job are just shills and, and honestly, that’s not wrong. My job right now is to get people to use Pulumi, and I’m okay with that. I like the product and yeah, I am a shill, I guess. Right? I think it’s a fair trade.
I don’t think that’s the real issue. The real issue is this. Being in developer relations feels like playing a developer on TV, I can make a video where I walk through building something with Pulumi, but my day to day isn’t the same as someone who’s actually coding up infrastructure all day.
Making those videos takes a ton of time, but a lot of the time it’s like making a thumbnail and doing descriptions and picking the right feature to show off. And then I’m in some marketing meeting and they’re going over partnership enablement with AWS and I realize, I don’t even know what partnership enablement means.
The event is 5,000, but are they paying us or are we paying them? And, and what is the event even for? I’m so confused.
That’s why I say it feels a little bit like acting, right? Like George Clooney isn’t a real doctor and sometimes I’m really not the kind of engineer I’m presenting myself as
In my last job at Earthly, we were a tiny team and like I knew I wasn’t shipping big features. Uh, I wasn’t really shipping any features at all, but I talked to the folks who were every day and so I still felt connected to the work, right?
But now I’m at a bigger company and the company’s great, but I’m in marketing and there are just two of us engineers in marketing and sometimes it feels like we’re really on the edge of things. Right. We’re really in this no man’s land between people building the software and the people using the software.
So just like mindlessly vibe coding, you can lose your way pretending to do something without actually doing it and it can take you to a bad place. And so I had to establish some ground rules for myself. I had to find ways to stay grounded to the work. Last month I skipped a marketing and sales bowling event and I went to this infrastructure as code teams, uh, food crawl at an offsite. Sure. Uh, part of it, maybe the main part was ‘cause I wanted to try this Chicago beef sandwich from the bear, but more than that, you know, I wanted to talk to the real engineers, the people building things, and I sometimes feel a little bit cut off from them.
Right. So I got to hear some of the real challenges of adding more languages to our policy as code feature. I got to hear it unvarnished from the people working on it, and conversations like that give me a lot more depth.
they make me feel a lot more confident in the content I’m putting out in the tutorials or examples or whatever I’m doing are more grounded in, in real world experience.
I’m excited about making videos. Like honestly, I’m pretty excited about figuring out how to effectively make videos, but I know that if I’m not actually building things, if I’m not coding, if I’m not using the products, I, I lose touch with what matters, right? So I’m trying to make myself, go deeper.
I’m trying to answer, questions in the community in Slack. I’m trying to use Pulumi for my own side projects, not just for demos.
I haven’t always been great at doing this, right? It’s a work in progress, but. I have to force myself to stay grounded. I have to force myself to not just mindlessly do the marketing things and let my distance away from the actual engineering, eat my brain.
I mean, that sounds pretty derogatory. I, the people in marketing are great, but the distance can be a challenge. And I feel the same way with the coding agents. That’s why I’m trying to set up these rules for myself. My integrity standards.
My Writing Integrity Rules
The first set of rules that I set up like this were around writing. My podcast, whether you’ve noticed or not, is built on writing, writing up my thoughts, shaping them, sharing them. Blogging has worked a lot for me too in the past. Don’t do it as much now, but I write things down. I polish them. I try to communicate something real. When LLMs came out, right? LLMs have a place in this process.
They help me edit; they help me tighten up my drafts. But it’s important to me that I always start with my own words, with my own first draft before I get any AI help involved. When I use an LLM, I treat it as a tool to improve my writing, not to do the writing for me. I go through my drafts and I cut out clutter, and I simplify my wording, and I tighten up sentences, and LLMs help with that, helping me with tips on cleaning up my writing.
Things like, you don’t need to say really, or vary these; these aren’t adding to your writing. Let’s make it tighter. I often ask for their feedback on a whole piece of writing. It’s like having an editor on call. I find it super helpful, but to me, the AI’s helping me polish, and I’m doing the writing.
Other people I’ve seen use LLMs to generate tutorials by, you know, feeding it a set of writing rules and a prompt, you know, something like, “Write a guide on how to use C# and connect to Postgres,” and they describe what they want, and the model spits out the content, and maybe they iterate on it a bit, and they publish it under their own name, you know, 20 minutes later.
That’s not something I’m comfortable with. That is outside of my integrity standard. I’m not saying it’s not useful; maybe some great useful content is made that way, but to me, that’s not something I’m gonna put my name on. That was one of the first lines I drew in the sand.
But that’s why it was natural for me to write down a standard for coding agents. That’s why the integrity standard I wrote down in my notebook that morning was, “I design; the agent assists.” It is just eight words, but since then they’ve guided every coding session. And I’ll show you how those words affect how I do things, how I code, how I delegate, how I review.
I Design, Agents Assist
But this is an answer to one of the big questions I got after last episode. How do I keep learning and getting better when the agents are doing the coding?
For me, it comes down to this integrity standard and to me, focusing on system design because that’s what I want to get better at. That’s my approach. Yours will be different, right?
If learning is your goal, you have to be explicit about what you want to learn and carve out a time and a structure for that.
If you want to get better at the actual syntax and the muscle of typing out solutions, you won’t get there by letting an agent do all the work. I mean, maybe that shouldn’t be your goal anyways, but we’ll get to that. But you need to be clear about the mode you’re in. If you’re in shipping mode, go ahead, fire up cursor, or whatever you’re using, power through those backlog tickets. If you’re aiming to master hands-on coding, you need to protect these sessions where the agent stays off.
Fighting Machines to Learn
If you wanna get better at writing tests or at code comprehension, one way an LLM can help you get better is by acting as a sparring partner. Say you’re grinding out lead code problems in Zig. You know, try to write out your solution and then ask ChatGPT for its take and compare. Who’s better? These models can actually be really good at understanding a language’s idioms, and I feel like that back and forth can help sharpen your own approach.
But the key is to be intentional, right? You want to use the tool, don’t let it set the standard for you. But be explicit about your standards for accepting code. Your boundaries are probably different than mine, but one I’ve also set is I have to understand every change before I merge it. I have strong opinions about where things should go and the data structures that should be used, and I’m not handing that off.
Take that big refactoring I mentioned earlier. I let Claude handle it. Yes, and it nailed it better than I could do. But I’m fine with that trade off. I’m going to lose a little bit of Python typing at the keyboard, muscle memory over time if I outsource that.
But I’m not giving up the habits of reading and evaluating and deciding how the code would be structured.
Because I actually dictated all that structure. I’m still working on the best way to not get lazy, like things like handing off little chores to the agents when it would be faster to just do it myself. It’s that same problem as leaning on the debugger.
But yeah, I’m trying to keep my code reading skills sharp because I feel like that’s getting even more valuable. But yeah, you’ll probably have to set and reset these boundaries for yourself. Sometimes you’ll slip and then you’ll remember why that you drew that line in that certain place.
But as long as you’re thinking and challenging yourself, that real growth happens and you’re not just coasting.
The standards would probably change. The lines I drew in the sand for writing changed over time, and my coding ones probably will as well. That’s the shift that I’m kind of working through now, trying to talk out right here with you, and I want to explain my approach to design skills, but mastery matters as well. But it’s not just pure mastery.
What Skills Still Matter
What matters for a successful career is mastering rare and valuable skills. That’s the foundation. Right, and we’re living in a time where actually some skills that were rare are now priced in pennies via an API call.
And I feel like that’s why one of the hardest questions I have to answer is, what skills are even valuable to learn in this new world? Because I think it’s changing. Some things are tough, but that doesn’t make them valuable.
Chess, Code, and Choices
When I was a kid, my dad loved chess. He liked to have his friends over and beat them at chess. And he had this specific chess set/table that he had built for himself with these little drawers, with all the chess pieces in that were like marble.
And he always said, like, chess would teach me how to think. But a year or two after I had left university, I did pick up chess for a while. I downloaded Chessmaster and I raised my rating in Chessmaster up to 1400. And when I would go visit my parents at home, my dad and I would have a chess game. Occasionally, he would let me win.
But it was hard, right? The effort felt heroic just to get to 1400. And then I realized like 1400 in that game is probably something like 1100 in the real world, and it’s barely mediocre at chess. But all that learning was hard, I mean, fun but hard, and far less marketable than the couple of evenings I had spent after university learning C that very quickly landed me a dev job.
So the real question isn’t, like, what hard skill can I master? But what is rare and valuable enough that people will pay you money, and it’s an interesting skill. Lately, because I’m doing videos, right. I’ve been working on my video skills. I’ve been editing and making thumbnails and the whole package.
And thumbnails especially feel like a pretty commoditized thing to do for my job. I need to get better at them, but I can’t help but notice that it would be very tough for me to make a good living as a video editor or generic content creator compared to the community engineer job that I do right now.
Right. So I need to stay grounded to my engineering skills.
Skills That Don’t Matter
My point is, if we’re talking about a successful career, you have to be careful not to pour your energy into skills that are hard to master, but are quickly losing value. Some things that used to be the core parts of a developer’s learning plan just aren’t as valuable anymore, I think.
I don’t know for sure, but like, take CSS. I spent years thinking like I should really learn how CSS works inside and out because every time I touch it, it feels confusing and messy, and I hate it, I guess. But for a long time I thought I should just master this. It’s not going anywhere, but it feels like these days I can just let the AI handle it for me and it’s not something I’m excited to learn and maybe I don’t have to.
And that’s great. But you know, I’ve written deep dive tutorials on how to learn Awk and how to learn JQ, and I thought they were really good. I worked hard on them.
And I thought these skills were must-haves, tools that are not going anywhere, and they’re worth learning. You can kind of amortize that learning over the course of your career, that makes you more powerful, more successful.
Regex and various CLI tools, I feel like they all fit in that groove, but maybe they aren’t as valuable and essential. Now it’s easy to outsource just command line tools to an LLM.
So it’s up to you to decide what’s worth learning and what isn’t. But I can tell you that while I’m sad that, you know, my JQ skills might be lost, I’m not sad to relinquish my bash scripting skills that I had built over time. Some things that I’ve spent a hard time learning have absolutely been devalued.
And you can already see the shift happening in how companies are hiring developers.
Interviews with Machine Helpers
Meta lets candidates use AI tools in interviews; other companies want to actually see how you use a coding agent. So, if you’ve been grinding LeetCode problems to land your next job, I think that path is starting to close.
The focus is changing. Soon, you might be asked to debug code written by an AI or how to manage several AI agents in parallel to ship features fast. I’m not really sure, but I do think system design questions are going to become more important. These are skills that are going to matter more if you’re aiming for a traditional software engineering job at a big tech company.
I mean, if that’s your goal though, that’s not my goal, but I do think we all need to think a little bit differently about learning goals. I don’t actually have an explicit answer to the question, what skills will be valuable in this new world, but I have a couple hunches, and one for sure relates to design.
That’s why what I wrote down was I design; the agent assists.
Humans Design, Machines Build
because the night before my 6:07 AM refactoring, I was doing a lot of design work, Not visual design, conceptual design.
You see, I’ve been learning to make videos and especially edit and script them. And my process is a bit unconventional and involves this messy Python program, And this program, one thing it does is it pulls apart existing videos that I like, that I want to imitate, and it breaks them down scene by scene.
And then I use that scene by scene breakdown just for learning. It’s been an interesting little side project for me. But there’s a bunch of steps. Download the video, extract the audio, run Whisper and get a transcript. Use Gemini to scan the video for onscreen details and, and key visualizations and you know, changes.
Yeah, sometimes I just want a transcript. Other times I want a shot by shot breakdown with like animated gifs of each key visual so that I can pass that information on to my editor. I’ve been learning there’s different types of visuals you can use. Supplemental reinforcing, entertaining,
and then this pipeline has a whole bunch of other steps that I won’t get into here, but this is where the main idea clicked. If I could find a cleaner design for this messy imperative vibe, code script, then the agent could do some of the restructuring.
’ cause really all that happens is you start with an input type, whether that’s a video URL or an MP three or a text document. And then depending upon the task, you do some sort of transforms. And as I added new transforms, right? The LLM was happy to build each step as a one-off, but it just was slowly becoming a mess.
’ cause it had no problem with just churning out a new step exactly as it was and not seeing any overall structure. Right? But I kept coming back to this idea, like there is a real structure underneath it. I have a handful of document types. You know, a transcript, a scene by scene breakdown, an MP4, animated gifs, YouTube URL, um, visualization types, a Twitter thread, et cetera.
And there’s clear transitions between them sometimes with forks and multiple paths. You know, if you’re taking an MP three and you’re turning it into an audio transcript, that is just a transition, right? In a graph from MP three to transcript. And one that takes a transcript and a video file and runs them through Gemini and splits out a scene by scene breakdown.
You know, that’s a transition that has two inputs of the transcript and the MP four and then to a specific markdown file. The coding agent couldn’t see the structure, but I could, so
I had this design idea and I ended up talking it through with ChatGPT with the O3 model, how this pipeline might work, right? I went back and forth.
There’s the straight imperative approach. But you know what, if we do it this way, what if we have some sort of path finding algorithm, you know, classic lead code type solution where you have a queue and you use breadth-first search to find a way to navigate through various transitions to your end state.
So the idea that, I came up with was sort of to have a method for each transition and to annotate each with input and output types and then register that as a transition. And then the search algorithm could just path find. And it gives you a totally new way to structure the program.
Instead of explicitly outlining, pipelines, you pass in an input type and ask for an output type and it finds the path through.
It just seemed like a very big change, but conceptually it made sense. So the next morning. Coffee in hand, hazelnut creamer, which is delicious. I fire up Claude code and I start describing the change that I’d like. I give it the type signature for my annotation for registering a transition and how I think this might work. And I send it off and it rewrote the whole project to fit this new model. And I actually didn’t expect it to be this easy.
I thought it was gonna be a mess, and that’s why I put it off to the morning. But really it was easy to describe this end state goal. And then there was just a ton of details to get it right and it could run the program and figure out and use the types and it just worked. And that’s where things got interesting because the newly structured code was so much easier to work with.
Suddenly I could imagine easier ways to add more things to add caching, to get logging in a centralized place, et cetera, because it was all now more organized. ‘cause I’d offloaded this grunt work, but I had come up with a good design,
so it wasn’t really just a click accept all moments, right? Claude had done all these repetitive parts, but the real value was in this planning and designing process.
If I’d stayed in this pure vibe coding place, I could have continued adding features, but it was slowly becoming more and more of a mess, harder to add things to the LLM would’ve done it, but everything would’ve been rote and repetitive and I would’ve had my brain turned off. So I think this kind of thoughtful problem solving.
Planning system design, refactoring ongoing maintenance. I think these are valuable skills. So this is one of my working answers to what skills matter most in the future.
Because in the morning when the refactor ran without errors, the real win wasn’t about the speed, right? It was about the choice to rethink the whole structure and to hand off the grunt work to get that structure in place. The people who will struggle the most with the changes that are happening now are, yeah, those who are deeply suspicious of AI and won’t bring it into the workflows, but also the people who will just turn off their brains and try to crank out things as quickly as they can.
I feel like both of those people will risk being left behind as the work evolves.
So, yeah, let’s not settle for just moving faster. Let’s take on problems that actually make us think, let’s tackle the tricky stuff. Let’s use these new tools to level up and not just automate. That’s how we keep our skills sharp. That’s how we make sure what we do feels valuable, even as the landscape keeps shifting.
Where Paths Lead
I got into computers because I love playing video games as a kid, and then that led me to programming. And then first it was to make my own games, but pretty soon I realized like programming for its own sake and kind of the instant feedback when something works. And yeah, then I moved into enterprise software with the difficulties I mentioned and then security.
And then somewhere along, you know, talking to people became part of my job. And Shane Hoovers sent me this article about this idea of unfolding where instead of planning one thing leads to the next. Ways that you can never predict, but if you guide them the right way, you end up in a great place and everything makes sense.
What Comes After Code
Looking back, we don’t really know how software development or the world is changing right now. Maybe things will stay mostly the same; maybe everything will get turned upside down. You can dig in your heels and refuse to adapt, but I don’t think that’s a good plan. Or, you know, you could panic and assume the worst: everything’s changing; we’re doomed.
I need a new career. Or then there’s also the risk of just going through the motions. You know, doing the Red Queen’s race thing, using the new tools to get an edge and not really noticing that you’re handing over all your thinking to the machine.
But yeah, these aren’t the only options. The bigger and simpler option is just to notice what’s happening and adapt.
I can’t tell you exactly where we will end up, but I can say this: if you pay attention to what you’re doing, to what you’re enjoying, to where the challenges are, you don’t need to map everything out. I never did. You just have some preferences and let that guide you.
Sometimes the world is very foggy, and all you can see is a step or two ahead, but that’s enough, right? You just use what little vision you have to guide you, and you keep adapting, and you let yourself be surprised by what you end up loving and lean into that.
The Next iPhone Moment
It’s an interesting time, right? In 2007, Steve Jobs announced the first iPhone on stage, and 12 months later he opened the app store, and overnight there was this fertile ground for tens of thousands of tiny businesses and eventually Uber and Lyft, and so much more, arrive.
It’s the concept of the adjacent possible, right? It’s this idea that when something new appears, like that iPhone, it unlocks a new set of opportunities. Things that weren’t possible before, but now, suddenly, are. It’s just not everybody has found them yet, but they’re now adjacently possible to what we have.
That’s why you see things popping up in parallel, like both Uber and Lyft coming out. In similar times, large language models are like that 2008 App Store moment. Suddenly, all sorts of new projects and ideas are within reach. I don’t know where things are going, right?
Getting Ambitious, Not Scared
If you’re curious and willing to explore, this is the perfect moment because everybody is like me just figuring things out.
I’ve noticed some engineers moving more towards product design. They’re moving away from the feature factory mindset and becoming more interested in building products and how things actually fit people’s needs.
So that’s one path, right? People letting go of a little bit of technical depth to focus on product and how things fit with the users. Syntax and language quirks may start to matter less to these people. What matters is understanding what they’re building and why it matters. This is kind of the product engineer path where you blend your engineering knowledge with product thinking.
It feels like an exciting direction that some people are going in. If you want to have a bigger impact, if you want to embrace the changes that are happening.
But that’s just one direction, right? You can follow the threads that interest you, see what grabs your attention, and keep moving forward. Don’t hand over your curiosity to the machine. Use it to push your ambitions further. Maybe you can dive into something totally new, like contributing to projects that felt out of reach. I have no idea how you add a new data type to postcards, but I could use an LLM as a teaching tool maybe to help me understand the code base to get up to speed faster.
If there was something I really wanted to get in there, it might help me get through it, where previously I would get stuck.
Lots of options, right? These tools are here to stay, but you don’t have to become obsessed with coding agents or chasing every newest trend. I think you should just use the moment to be more ambitious in what you can build. Treat these tools as just tools, but tools that are now allowing people to push the boundaries.
And from there, you just follow what interests you. Maybe it’s hand coding a ray trace. Maybe it’s diving into lean and advanced mathematics, but where careers are concerned and getting well-paid, I would focus on learning skills that are rare and valuable, but also interest matters the most, right? So pay attention to what actually excites you, what feels exciting and what feels like real growth, and lean into that. Can you master a large code base that you actually care about? Can you get better at making real structural changes to that code? Can you push yourself to design systems that are cleaner, more reliable, and easier to understand than you ever could before?
When you start to burn out or lose energy in one area, I always feel like you have to pay attention to what grabs you, because sometimes there’s a new area that will spark something interesting and take you somewhere completely new. And for me, those instincts have always been worth following.
Choosing Your Own Path
So where does all this leave us? Right? When I started this episode, it was 6:07 AM and I had that coffee in hand, which I really would like right now. I was wondering if I’d automated myself out of a job. But now I see the real risk wasn’t the agent; it was turning off my brain. It was losing that part of me that wants to build and to understand and to keep pushing. That’s why the real move is to get ambitious, not scared to chase what excites you and see how far you can go past your old limits.
The tools will keep changing, right? The pace is picking up. But if you keep asking what’s possible, what’s worth building, what excites me? If I keep designing, instead of just hitting accept all, then I’m not falling behind, right? I’m choosing my own path. So as you look at your messy code or that empty file waiting for your next idea, just ask yourself, am I letting the tools call the shots? Or am I using the tool to build the type of person that I actually wanna be?
Until Next Time
That’s the show. Thanks to Michael Lynch. Thanks to Shane Hoversten. Thanks to Chris Lewis for the questions and many more shout outs to, uh, Alex and Kevin. And Jason and Chris and Cedrick and everyone in the, uh, LLMS channel for pushing this conversation further. Um, and thank you for all the supporters.
Special thanks also to Malcolm Clark who told me, you know, he’s too busy to worry about all this AI agent stuff. He’s got a lot of work to do, but he listened to me on our weekend runs drone, on and on about my excitement about them.
And kind of helped underline to me the fact that, to me it feels like everything’s changing. but for some devs, whatever, they got work to do and they’re not too concerned.
But yeah, whether this episode hit home for you or left you unconvinced, uh, I’d love to hear more. Send me an email, join the slack. Uh, and until next time, thank you so much for listening.
Sticher
Overcast