When AI Codes, What’s Left for me?
39:51 Share

I grew up on a small farm. Soybeans paid the bills and the rain on the barn's tin roof sounded like a snare drum. My dad's old Massey Ferguson tractor with its front end loader on the front and its cutting blades on the back handled every chore. A green John Deere tractor and a red rust flecked combine that was so large lived under that noisy roof and they were by a playground. The nearest kids my age were a long, long bike ride away.

So on July afternoons, I'd climb up into our garage attic, and it was basically like an oven from the heat. It was stuffed with these old cardboard boxes full of dusty Pulp Fiction paperbacks. I would sit up there, and I would read for hours.

When our first Windows PC showed up, it was this beige box humming on the family room desk, and my dad had to call a friend who knew computers. And that friend coached eight-year-old me through the whole ritual of getting into DOS and sliding in the disk and typing N-U-K-E-M dot E-X-E. And then Duke Nukem blinked onto the screen. In that instant, from hitting enter to that explosion of color and sound, I was hooked. The computer was both a lifeline and also the most fascinating thing I had ever seen. ♪

Hi, this is Co-Recursive and I'm Adam Gordon Bell. And today I want to talk about something that's been dividing the developer community, AI coding agents. But this isn't another, you know, AI will replace us all talk or AI is overhyped take. It's more about me and what happens when your identity is tied to building things and then the tools you use for building fundamentally change. It's about the resistance that we feel and why maybe we should push through that anyway.

I think it will be interesting to the skeptics and the people hyping it up both. I think I have a pragmatic view or at least an interesting perspective and I hope you'll listen along. On Stranger Things, the 80s era nerdy kids, they play Dungeons and Dragons in a basement and they bike around the neighborhood together. But yeah, that wasn't my childhood. As I mentioned, I grew up in the country. No neighbors nearby.

My friends at the tiny school I went to were mostly kids from farming communities, especially when I was young. And most of them, you know, they run those same family farms now. We didn't always have a lot in common. I was kind of the class clown in school, the kid who got bored and acted out. And I knew I was different. That was clear. But it was never clear to me exactly who I was and why or how I was different.

After high school, I went into computer science and I didn't get super close with the students in that program either. I had a few friends, but mostly I kept busy on my own, always building something, not just programming, but making websites and messing around with electronic music, downloading pirated software like Photoshop and trying to figure out how to use it. When I started working as a software engineer, I finally met people who really understood themselves and were happy with who they were. My friend Don, right, he proudly embodied this nerd culture.

But I had never seen Star Wars. I had never played World of Warcraft. I didn't totally fit in with that crowd either.

But then something unexpected happened. I started meeting people who were just like me. I remember going to a job interview at a startup in San Francisco. It was not far from the Twitter offices. It was in the downtown area. Right away, I noticed people there that felt familiar to me. By day, everyone was writing whatever code needed doing. But on the side, they were learning Haskell or building games in Unity or just doing these things for fun. And I would say my favorite author, you know, was Ted Chiang and somebody...

else would say like, oh yeah, I love him, but I moved on to Greg Egan. They just seemed to have some of the same interests as me. It was so odd, to be honest. But here's the thing I didn't fully understand at the time. I wasn't just finding people like myself. I was finally discovering who I really was. A couple of years ago, I was on vacation in Florida with my wife sitting by the pool with my laptop building this Markdown parser from scratch. And she was reading perfectly content. And I was in this flow state where hours disappear.

chasing down edge cases and getting that hit of dopamine whenever something clicks into place. And it reminded me of being a teenager, right? Growing up in the country and my dad got a snowmobile and wanted me to come play. Or I had a friend who had a dirt bike who would swing by with the engine revving, ready for an adventure. But I was hunched over my computer building a mastermind board game in Turbo Pascal. And I would go outside and I would go play. But the most exciting things for me were those building

The building stuff was when I had the time of my life. There's something intoxicating in that moment when, you know, the algorithm finally handles all the edge cases. When you realize that you built something that didn't exist before and it works and it's pure and it's addictive in the best possible way.

So yeah, it took me a long time, like an embarrassingly long time, to admit to myself that I would rather spend 10 hours on a Saturday deep diving into some new programming framework than be at most parties. I would rather figure out how to automate something that probably doesn't need automating than do almost anything else. I'm someone who gets genuinely excited about reading the documentation for some new framework if I think it might solve some problem that's been bothering me.

You know, I see a problem and I immediately start thinking about how I could come up with a solution. Even if it's totally overkill, it's just something I enjoy. But yeah, once I finally accepted that, like really accepted it, not just tolerated it, I stopped apologizing for disappearing into code caves for weekends. I stopped feeling guilty about getting excited about a new programming language and boring my friend about it at social events. It wasn't a weird quirk that I needed to fix, it was just who I was. Maybe it was my superpower.

But yeah, in San Francisco, right, I met these people and turns out there was a lot of people like me, folks who like building projects, who like writing and sharing ideas. A lot of them at this particular place came from Waterloo, another place in Ontario, and then I moved to the Valley. But I was still in Ontario. And so I spent hours and hours on Hacker News. It felt like an unofficial clubhouse for people like me.

And it felt like a place where I belonged, like there finally was a place. These were people who were building things and who understood the joy of solving problems that didn't need solving, who got excited about elegant code or who spent their free time learning a new programming language or learning math or doing whatever just for fun. Right after years of feeling like an outsider, it felt like home. But now, early, mid 2025, if you look at Hacker News, that sense of belonging for me, it can feel fractured.

The community that made me feel understood feels like it's splitting over LLMs and coding agents. Some folks posting exciting updates about what they're building with Cursor or Clod or posting updates about the latest releases of coding agents and others pushing back hard, arguing these tools produce brittle code and make developers lazy.

It feels like the clubhouse turned into a battleground between this changes everything and this ruins everything. And I feel like I'm pretty pragmatic and somewhere in the middle, but I'm definitely leaning towards excitement. After, I don't know, 20 years of coding for a living, I've seen enough tool changes to recognize when something's worth exploring. And I feel like if you love building things, if you like to create, nobody can take that away from you.

Not a boss, not a new tool, not even yourself. The urge to build these side projects and experiments that I love to create, it's just part of who I am, right? And AI can't take that away from me. But maybe it can help me. But even if, you know, Claude7 or ChatGBT6 drops and suddenly it's eight times better at coding than anybody, that doesn't mean that I'm going to want to stop building things.

It doesn't mean that you'll want to stop building things. Maybe the what will change because it can feel devaluing when some skill you've built up over time can be replaced by an API call. But that drive just doesn't disappear. The job market might change and expectations might shift. But there's a way to embrace the change that's going on and also stay connected to this need to build. Let me tell you about a fear that I know intimately. Once I saw myself as a builder, I hit a wall in a way I didn't expect.

When I became a software engineering manager, it felt like a special opportunity. I was working remotely. I'm here in Peterborough, not near any tech hubs, and I've been working remote for quite some time, but this is pre-COVID. The roles were limited and the chance to be an engineering manager at a large and growing tech company

It felt very exciting. I couldn't say no. I wanted to step up. I wanted to lead this sharp team of functional programmers at this fast-growing company that had recently IPO'd it. It seemed exciting, the idea of climbing the ladder of, you know, somewhere with hundreds of engineers. It also just felt like the thing that you're supposed to do. But almost right away, anxiety crept in. It wasn't very long before I wasn't coding anymore at all.

And when I would finally have to do a tiny task, you know, I would open up my VS Code and do a Git pull and see, you know, it'd be 37 days since I'd last pulled the code. And all I would need to do is some small task and open a PR and then Adrian would approve it two minutes later. And I remember him saying in Slack, like, feels good to ship something, doesn't it? And it did. But honestly, that feeling faded as fast as the GitHub actions build.

Because the rest of the day was meetings. Ireland at 8am, then DC folks, you know, through the middle of the day, Pacific Coast near dinner time. I started having my phone on this tripod with earbuds in so that I could go down for coffee while still in a meeting. And I spent way too much time reading and updating Confluence. I just, I hate Confluence. I don't know. There was a lot of Confluence updating, a lot of like digital paperwork, a lot of like being a router for messages between various teams.

Time as a manager moved fast. Ted, a friend who stepped into management at the same time I did, had the same worry. And I remember telling him, like, don't stress about it. Like, you were good. You were a good developer. And so being a manager isn't going to take that away. Like, maybe your skills will get a little bit behind, but you can always ramp back up if you need to switch. But while you're a manager, that should be your main focus. That was my advice to him. I

I wish I could take my own advice, but I found that I couldn't because of what I said. Building things and being good at that was a big place where I got a lot of self-worth. But now I was in back-to-back meetings with endless messages flying around, and I just started to worry that after finally figuring out what brought me joy, I had just traded it all away. I think that a lot of resistance to AI coding tools comes from the same place. Fear of losing something that has defined you for so long.

People are reacting against overblown hype, and there is overblown hype, I get that, but I also think there's something deeper going on here. When you've worked hard to build your skills, when coding is part of your identity and where you get your worth, the idea of a tool that might replace some of that is very threatening.

But here's what I want to encourage you to do. Put some of that fear aside, at least for a learning experiment. Treat these tools like something that you need to get familiar with. Treat it like something you should explore in a side project, something worth spending time on. Not because they solve every problem, but because they're worth understanding. And if you are a builder, these tools, Cloud Code or AMP or Cursor, they're designed for you. But to see that, you need to overcome that fear, or at least admit to yourself that it's there.

Because when coding is part of your identity, a tool that devalues it, yeah, it's hard. But I guess what I'm trying to say in my long-winded way is that if you're a builder, if you get joy from that, once you master these tools, you're going to love it. Some of your skills will be less valuable for sure, and that's scary as fuck. But other ones are 10 times as powerful, 10 times as valuable as they were before. And that's exciting.

So as I moved from engineer into management and then left that for developer relations, I found myself coding less and less. DevRel scratched the itch in a different way. You know, writing things and making videos, it was another creative building endeavor, a little bit different, but I still got to code and build small sample apps and show them off. So it worked, but I wasn't in the trenches as much as I was on a product team.

On the product team, I always wanted to keep up. I always wanted to be the best, so I'd spin up side projects to try out new tools, to experiment with new techniques, or to finally build something that was polished in the way that I wanted to do at work, but we just didn't have the time, or the code was too old and scary, or whatever. But even when I was coding less at work, I still needed to build things. Honestly, I find it kind of addictive. There's this feedback loop where you start building something, and you get stuck, and then you try to figure it out, and then you get that rush when you do, and then you want to do it all again.

When I started playing with languages that had stronger types, the highs and lows got even sharper. This, you know, like excitement and frustration. When I'm deep in a coding session, totally focused, and forget about everything else, it's just, it's a great feeling.

But honestly, it can get frustrating, this addiction. You know, I block out time to work on the podcast in the morning, doing the editing or setting up the interviews or hunting for stories. And sometimes I love it, but other days not so much. And it's always easy to reach for some random coding project and convince myself that it will solve my problem. I just can't help myself. I just like to build little things.

Here's a weird example. If you check out the podcast website, corecursive.com, there is a slash rankings page. And on it, you'll find subpages that list the most popular episodes from other coding podcasts. Best Python podcast, best Android, best cloud, best Linux. This started as a weird side project that I got way into at some point, you know, distracting myself. I had basically this pile of Bash scripts because I was trying to get better at Bash then.

And honestly, it became way too much bash. But I was scraping feeds of podcasts, scraping Twitter, looking at reviews, trying to find for these podcast episodes, which ones were the most popular, right? That would help me find guests to interview on the show. But it kind of took on a life of its own. And at some point, I was like, I should just put this up on the website. Eventually, I rewrote it in awk. And honestly, I never even checked the results. I'm not even sure I use the tool.

But yet it still exists and it's still running daily and gathering metrics. And probably at some point I'm going to try to rebuild it in Python. Because that's just what I like to do. But right now, we're at this moment. It's like 2005 and you're a decent chess player. Not grandmaster level, but you know your openings, you're pretty good, but you've been getting crushed by chess engines. Then someone suggests like, what if you use the engine to help you think through positions, but you make the final calls?

The first time you try it, something magical happens. The engine spots techniques and tactics that you missed, but you see the long-term strategy that it doesn't quite grasp. So together, you're playing better than ever, better than either of you could alone. You're not just using the chess engine as a calculator, you're collaborating with something that has different strengths than you do. That's exactly where we are with coding tools right now.

We're in the 2005 chess mode, that moment of discovery when you realize it's not human versus machine, it's human with machine. These LLMs might be able to single shot build some simple stuff like a React to-do list, but to build something hard, to work in a large code base, to tackle hard things that haven't been done before, they need to be paired with an experienced builder who can guide them, right? And that's you. You bring your intuition about what needs to be built and the way it should be built and your sense of when something's off or there might be a better approach, right?

your ability to break down complex problems into manageable pieces. And the AI brings its speed and pattern recognition and ability to handle the tedious parts. And together you can tackle projects that you never would have had time for alone. If you're someone who isn't using these tools yet, for whatever reason, I want you to set aside your objections and yet treat it as a learning project. Not because you have to love it and not because it's going to solve all your problems, but because this is a skill worth developing.

Because here's the thing about learning projects. They can be frustrating, right? When I started at Tenable, I had always worked on Windows. And then my boss just says, hey, you're getting a Mac. All the devs used Macs. So that was the way. But I was a Windows person and I didn't say anything. I just went along with it.

And my fingers had years and years of muscle memory burnt into them. Control C, control V, control everything. Now suddenly it's command. And my pinky keeps stabbing at the control key like I'm trying to punch through concrete and things aren't working. On Zoom screen shares, I'd fumble to do basic tasks with everyone watching and hitting the wrong keys and getting nothing. Sorry, I'd mutter and I'd be frustrated and I seemed like I didn't know what I was doing. My fingers failing me at the exact moment I needed to look competent.

My MacBook was gorgeous, right? Way nicer than my old ThinkPad, but it felt like I was working with oven mitts on. But now I couldn't imagine going back, right? Learning Haskell was the same torture. I spent hours building this beautiful parser for parsing log lines using Parsec. This was years ago. And the code was so clean and elegant and it looked like poetry. And then it would break because it couldn't handle, you know, handling a bracket or a pipe in some random spot and it would fail in some completely unrelated way.

The code was simple to look at but building it was hard. Where in C# I could put together a regex with name groups in maybe 5 minutes, but here the code was prettier but debugging it was such a challenge. But that's the pattern, the moments when you're thinking "this is completely stupid" or "I'm frustrated how this isn't working" or "I feel slower" that's when you're growing the most. And it hurts because everything feels clunky and impossible and you start wondering if you're actually getting anywhere or just torturing yourself for no reason.

But that's what it's like to learn. That's why it's a great time to put aside your fears and frustrations and invest some skills in building with one of these tools. Treat it like deliberate practice. Something you do because the skill itself is valuable and it feels good to learn. It just also feels awkward and frustrating in the way that learning something new always does. But yeah, if you want to work with a coding agent, this is what I do. You don't have to listen to me, but I do want you to consider it, right?

Especially if you have a strong aversion to these tools, but also you're a builder. I just think it's something you should try. Pick a good tool. Pick the one with the strongest coding model. Right now, that's the cloud models with thinking. And then make sure you're using an agent. Use cloud code, use AMP, use cursor seems very popular, but there's a million of them.

And yeah, you're going to have to spend some money. You need to pay for all these API calls that they consume so aggressively. But commit some time to playing around because there's all these criticisms I see on Hacker News from people who haven't taken the time to use and play around with these tools and build the skills. And if you haven't, then your criticisms actually don't hold a lot of weight. Because yeah, when you get over the hump, when you build up some tricks, and even before then, it's just so much fun.

And I'll get into some of the font I've had, but first, you know, some advice. You can't treat these coding agents as some magical AGI that's going to fix everything or make you 10 times faster overnight. It's not that. Just think of it as a new tool that you're learning to use, like switching from Mac to Windows or moving from imperative to functional programming or learning OO. Treat it as a chance to learn something new. Start small, right? I like to think of it as like a junior programmer that I'm pairing with. I talk to it and it does the work. It stands on keyboard.

One of the fun learning tasks that I've done is pick a library that you rely on and don't understand well, clone its GitHub repo and then fire up your favorite agent and start asking questions.

How does this work? Where's the control flow? What are the main data structures? Have it generate some quick and dirty docs specific to the way you want to understand things. It's low stakes and it's a great way to get comfortable with this back and forth process. It can explore the code base probably faster than you can, and then it can help explain to you things. And then you can ask questions back and forth. Next, after that, you know, try a small project, maybe something you've built before, but with a new twist or in a new language that you're less comfortable with.

Don't expect the LLM to handle everything. Instead, treat it like a coding partner, something that helps you with writing, right? You can work together and plan out your project, then tackle the first step and then the next. Ask it things like, can you write a test for this?

The idea is to move forward one piece at a time, learning as you go. Start small. Let the agent handle the code writing and see what it gets right and what it gets wrong and then offer input and build up rules and you'll get better. Working with an LM is like pairing with somebody who's brilliant at some things and clueless at others and sometimes has different tastes than you. There's a learning curve. And the people mastering these tools, they're the people who have developed intuitions about what works and workflows that work and learn to lean into the strengths while avoiding the weaknesses.

But to get there, you have to give it a chance. Let me tell you about a recent project that I was working on. I wanted to build a program that takes a YouTube video, downloads the MP4, pulls out the audio, and generates a transcript. And then, you know, I'm creating a blog post version of that video by grabbing pictures, you know, key images from the video itself.

So I opened up VS Code with AMP in the sidebar and I started dictating. I literally talk into the box for the prompt using MacWhisper. I'll say, "I want to download YouTube videos and generate a transcript. Then I want to identify key visuals and note them in this file." Is there a Python native way to do this or should I use the YouTube download program I normally do? We have some back and forths, 15 minutes of me rambling and getting input back on different ways it could work. Sometimes it misses the forest from the trees,

But yeah, we do software design together. I use it as an advanced rubber duck. And yeah, you can tell I do anthropomorphize these agents. I just talk to them back and forth. That's just how it feels for me to build something this way. So we got the first version working. It was a clunky one-off script, but I had various stages to add. So we had to convert it to a proper Python project organized by files. You know, I committed after every major change that way it could roll back if things went sideways, which they sometimes did.

But this whole process feels very different than working with something like Devon or these tools where you put together a GitHub issue that, you know, exactly describes what you want and then let it run off and do the work. Honestly, I've never worked with one of those tools and I don't super trust them because my experience of building is very iterative. I like this back and forth. I want to build in a certain way and in fact, I had to build up a bunch of linting scripts so that the generated code would come out the way I want it.

But yeah, as we built, I hit Gemini's file size limits. You can only post files up to a certain size. Anything bigger needs a secondary API upload. Then you send Gemini a file reference.

And so we got that working, but then we have to add FFmpeg to re-encode videos to lower the resolution so that a lot of times we don't even have to do the secondary upload. And there's back and forths and there's testing and there's adding new conditions and there's AMP going out and digging through the docs, which is super helpful actually for it to go out and try to find what's the relevant stuff.

And in some ways, it felt like it took ages to build this thing because there was a lot of back and forths, but it actually came together pretty fast. And on my own, I would have never finished it. I just didn't have the time. But with AMP, I could push through the tedious parts. And there was still plenty of frustrating moments, plenty of like, nope, you forgot about this, you know. But for me personally, having these back and forths isn't that big of a deal. It's just communication. It's just pair programming.

And the whole process was fun. And I can hear all the objections. If I had to constantly guide them, then why not just write it myself? And I feel like that criticism, it's not that it's wrong, it's just kind of missing the point. It's kind of missing what this experience was actually like. It was fun and fast and better code in the end than I'd actually do on my own.

Another complaint I hear is why bother, right? If AGI is supposed to be so advanced and maybe even replaces, why do I have to learn all these tricks just to use it? Why invest time? If it's really that good, shouldn't it be simpler and not harder?

But honestly, these are just tools. These aren't AGI. If it was AGI, you wouldn't need to fuss over prompts or workflows. You could just say, you know, watch me using this software. Or can you take the Linux kernel and rewrite parts of it in Rust? And the AGI would figure it out and send you a pull request. Or here's 50 videos of people getting stuck. Can we smooth out some of the rough edges? Look through this and find performance problems.

But we're not there, right? These tools can boost what we do, but only if you're willing to experiment and learn and iterate and guide it and put in the work. And before you do that, you have to get past your own fears and biases. Here's an example from Hacker News. Someone complained that code generators like Claude are inefficient. They asked Claude to write something to normalize image orientation. You know how sometimes pictures that you take on your phone, they're actually sideways, but they use a header to say it goes the other way. And

And then some photo programs like ignore that header and display them sideways. So they wanted a program to fix that. So they asked Claude to do it. And they said that the first solution was clunky. So they pointed out the problem and Claude tried again, but that solution felt brittle. And it took two rounds of back and forth before they finally got to a version that they liked and worked well. And their takeaway was that these tools, they just lead to less than ideal solutions. And you have to step in and guide them. That's like actually totally fair criticism, but honestly taking two rounds to build something that's not,

bad at all. Maybe your expectations are just too high. Or, you know, maybe you could have explained it clearer. But these tools aren't magic. Like, they're not going to nail every problem on the first try. I think of it more of like working with a teammate. You need to go back and forth. You need to refine what you're working on. You need to collaborate to get good results.

I mean, I've gone back and forth five times or more just trying to nail down the best structure to use for a specific solution. That's not a flaw. That's just how building things actually works. The same would happen if I were designing something with a colleague. But a real risk with these tools is skill atrophy. And that does worry me. Take the video transcribing program I was talking about. I don't really know all that code. I certainly don't know it all well.

Meanwhile, there's code that I build myself that I know inside and out, at least, you know, when I first finish it. I remember how each part was used and how I structured things. But the code I didn't write or that I wrote with the agent, I just don't have the same depth on it. I've read and reviewed most of it, but certainly lots of it I haven't. Some tests I just never looked at. We just needed to test this condition. So yes, like skill atrophy is a real risk.

But once again, I feel like if you treat this as a learning project, instead of focusing on building my Python chops right now, I'm looking at building a new skill, figuring out how to use these tools to build things, working alongside a coding agent and getting things done. When I look at it that way, I don't worry so much. If I'm losing my edge, that's okay. I can always go back to writing Python by hand, which I still do sometimes. Nothing's stopping me. Other complaints, they don't ring as true to me. If you're having trouble getting real work done with coding agents,

is probably a skills gap. And that's okay. Instead of blaming the tools, just try shifting your perspective. What am I missing? How can I get better at using these tools? Other developers are building real things, so it's worth asking, you know, what could I be doing differently and would that be worth it? Because maybe you can't evaluate things until you really understand how they work. The tools aren't perfect and it's totally fair to feel frustrated or want to walk away or try again next year when they got better.

But I push back a little bit, right? This stuff is new. And honestly, it's fun to mess around with. I think it's worth exploring. Another thing I built before ChatGPT's deep research feature existed, I built my own research assistant using Windsurf as the coding agent at that time.

Because part of my interview prep for the podcast always involves creating a timeline of someone's career, you know, where they went to school, what their jobs were, what their projects were and their pivots. And I would manually hunt through their blog posts and LinkedIn history and public work and piece together a timeline of what they did. It's useful. It's super useful for guiding the interview, but it's also time consuming.

So I built a web app that automates this process. It'll do a Google search for the person, find their blog, you know, spider the links, try to find all their posts, follow links, evaluate if they're relevant, hunt for interviews they've done, transcribe them, pull all these documents down, and then attempt to build a timeline off that. When I first used it seriously, it was for the Hatress interview.

And those guys, being very detail-oriented, they prepared their own timeline of them building Hatres. And I found a couple things that they didn't include, and I thought they might be hallucinations, but they weren't. There's real things that happened that they just forgot to include in their timeline. It was mind-blowing. I had saved myself so much work, and it was actually doing a better job than I did. But also, building that tool was a lot of fun. Working with coding agents has some of the same addictiveness that I've always loved with building. These feedback loops, these cycles of

frustration, and then breakthrough that can make programming addictive. Even, I guess, the probabilistic nature of them maybe even makes it more addictive. Variable cycles of reinforcement. But also building up new skills, right? I've learned not to micromanage the process. When I'm planning with AMP, I'll use dictation and speak for quite a while of various concerns and then send it off and get some feedback and we iterate and we do some design together. So I've built up my own, you know, bag of tricks. Dictation is definitely one of them.

But yeah, I'm just sharing some of my experiences here in the hopes that if you're doubtful that you might give these things a try. Or if you're listening and you're not doubtful, but you have a coworker that is, maybe you can share this with them. I don't know.

But another thing I do a lot is use the coding agents for just small automation opportunities. GitHub Actions is always a pain for me or builds in general. So I like, you know, asking the coding agents to make the changes or if I make the changes myself, asking it to review the changes and look for any problems before I commit and send it off because the build feedback loop is just brutal, right? So if I can catch problems earlier, it saves me a lot of time.

It's like getting a PR review, but instantly in a way that's faster than waiting for the build to run, which is sometimes slow.

I wasn't always programming in Python. That's a relatively recent thing, but I've been using Python a lot because agents work with it so well. But I've also found that all the static typing and linting that I've always loved is really also a key when working with these agents. Now I throw every tool that I have at my code: formatting, linting, type checking. That way when the LLM makes a change, everything runs through the linter step and we catch problems.

I even use a duplicate code finder since LLMs sometimes will try to re-implement something because they didn't see that there's an existing solution somewhere else. And the duplicate code finder is super helpful for guiding it. My biggest trick lately, my biggest improvement is doing kind of mass refactorings. Change the signature of something that's used quite a bit in a way that's a little bit more complex than your standard refactoring.

I'll do the first one manually, and once we've done the first one, I can say, "Okay, now do the rest." This exists in a whole bunch of files, and then the call sites need to be updated, or there's eight more instances of this. It'll go off and find them and make all those changes flawlessly. And with AMP, I'm using subagents, and it can do it so fast. It's so nice. That for me was a big realization lately, that these tools weren't just helping me write code faster, they were changing the size of projects I could tackle and the way I could think about reorganizing things.

Of course, they're also probabilistic, so they can also make a mess. I think we'll come to see the anti-pattern of the AI-empowered engineer as sending in the PRs that rewrite two-thirds of the code base or whatever. We still need to be targeted in our changes, even if we're feeling more powerful with these tools at our disposal. But yeah, the expanded ambition is a real thing.

Okay, another vacation story. Over this last Christmas, Courtney and I were in Mexico. We were on the Yucatan Peninsula at an all-exclusive. It was super nice. I was sitting poolside with her in one of those beach beds, frozen drink in hand, you know, laptop balanced on my knees, and she was reading this massive Robert Caro biography. And I was trying to reverse engineer Descript's file format so that I could programmatically edit my podcast.

Three hours in, had tracked down where Descript stores its project files. It's this zip that contains a whole bunch of documents. And then we were making changes to the documents, reloading the project, testing what breaks and what doesn't.

But some of the processes involved understanding obfuscated typescript from Descript's own code, and I would never be able to understand that on my own. But the LLM could read through it and grab the pertinent details here and there. And I realized I was attempting something that I never would have tried before. Not just because it was technically ambitious, because half of it was in a language that I didn't really use, and analyzing code that had deliberately been made unreadable.

But a breakthrough came when I figured out that I could use this backup and restore workflow in Descript, make changes to the zip, and then restore the project from backup. And then boom, my edits were in place.

But I wasn't getting bogged down in the grunt work of parsing all these JSON files and getting things edited in the right spot or deciphering crazy functions. I was working at a level higher and telling Windsurf specific things. We only want to depend on the parts of this JSON file that we need. Because if they make a change in their format changes, we want our edits to stay stable.

So we don't want to parse the whole thing. But that's when it hit me. I was being kind of a coding architect. I was always kind of skeptical of this role. You know, you hear of like the enterprise architect who just describes how things work. But here it was working because the LM was doing all the detail oriented grumwork. And I was describing, you know, what I thought the best approaches would be.

We never got a great automated testing loop working because Descript is UI driven and this backup and restore I had to do through the UI. So the reloading, it was kind of manual. And eventually I got distracted and I never totally finished the project. But lying there by the pool, iterating on this weird experiment, while Courtney read in her book, I realized, you know, something had changed. I was thinking at a different level. I was exploring an interesting problem. And

and just throwing away approaches that didn't work because the tools had removed enough friction that I could focus on these very interesting parts of the problem. I do sometimes hate the uncomfortable feeling of not knowing what I'm doing. You know, when you first start using something, that anxiety kicks in. Like the same feeling of when I started to use a Mac or learning functional programming when everything feels clunky or you get in a frustrating feedback loop. But I've learned to recognize that that discomfort is often a sign that I'm growing.

You know, when I started working with Python more seriously, I kept trying to bring my Scala habits over. You know, pattern matching and immutable data structures and whatever. Some of it translated well, but some of it was just fighting against the language. But working with an LM, I can let go of that resistance faster. Instead of forcing old patterns, I can start asking, like, well, what would be the Python way to do this? And the tool can help me discover idioms I would have never found on my own.

I still kind of like to do Python my own unique way. I'm not huge on these giant classes with a lot of state. I like to have like some known data structures that you pass around. But it's helpful to have a native speaker when you get into a new area that can teach you, you know, the rhythm of the language. And because the LMs behind these agents understand so many different pieces of technology, they can be a great guide when you start working in a new area.

It's like, remember when you first start coding and everything was new and you stumble across some feature or library and it suddenly made everything click? Working with LLMs makes that easier, right? It brings back that sense of discovery. I mean, maybe it's just me, but it feels...

great to always have this partner who's there, who's game to explore weird ideas and try different approaches or just explain things to me from a new angle. They make the whole process feel a bit more playful and a little bit less like grinding through documentation and looking for the exact thing that describes this problem I'm having. But look, I get it if this whole exploration process doesn't appeal to you. Maybe you love your current tools and workflow,

Maybe you're an expert at the very specific thing that you're doing and the agents are nowhere near where you're at and so they'll just slow you down. Maybe you just want to focus on other skills right now. That's completely fine. Not everybody needs to be on the bleeding edge of everything all the time. That's cool. My friend and previous podcast guest, Chris Kreutzer, was telling me that I'm anti-anti-AI. And honestly, I feel like that fits, right? Some folks hype up these tools nonstop. Others push back hard against them and say they can't do anything.

And then there's people like me, not cheerleaders, not doomsayers, but pragmatically building things and having a lot of fun. I think these tools are useful. I also think like I come from an odd place, right? After almost 20 years of coding for a living day in, day out, I don't spend as much of my day writing code as I used to. And that puts me in a good spot to see how these tools can boost what we do.

Because honestly, you don't have to be a genius to outcode me in Python. I was never a Python expert. But that made it easier for me to just see how much help they're bringing. It's totally fine if you don't agree with me. Not everybody needs to use coding agents for everything. I'm just here to speak up for anyone who's curious and unsure. Because my pitch is like, give these tools a shot. There's a big gap between the hype and the pushback.

but trying them out is the first step to bridging it. It's just an exciting time to build things. The coding I do now is very different from when I was a full-time backend Scala engineer, you know, working on finding container vulnerabilities. But I still love to code and it's incredibly fun and these tools exist and they aren't going anywhere.

When I think about my career, right, it just feels like another transition. From that kid working on basic programs and then VB.net to then, you know, learning object-oriented programming in college and then moving from Windows to Mac and from imperative to functional and from individual contributor to manager and then back again to building things. Each transition feels awkward at first, but then natural and essential and fun.

And right now I feel like I'm drawing on so many skills I already had. Breaking down problems, understanding systems, debugging when things go wrong, knowing when something feels off or it's just the wrong approach. The core of what makes someone good at building software hasn't changed. It's just that now you can have this powerful partner that can help out in the process. The same curiosity and the same drive that always excited me to understand how things work and how to build things. There's just like a new tool.

but the fundamental satisfaction of creating something is still there. Like that's unchanged. Am I worried that some AGI breakthrough will come around and replace all analytical thought? Will force us to rethink everything about employment and work in the world? I mean honestly a little bit. It does seem like these AIs are getting smarter. But that's a problem for another day. Right now these tools exist and they're powerful and they're incredibly fun to work with. I could spend my time worrying about obsolescence or I could spend it building things that I never thought I'd have time to build.

I could resist these changes or I could lean into them and see where they lead me. And for me, it's obvious what I want to do. I want to build things. That's why I say, if you're curious, start small, pick a side project, treat it as a learning experiment, have fun. You might discover that working this way scratches the same itch that drew you to programming in the first place. Or you might decide it's not for you, that's fine too. But if you're like me, if you still get that rush from figuring something out, if you still love the moment when messy ideas crystallize into something working, then this might be worth exploring.

Because at the end of the day, we're still builders, right? We're still the people who see problems and want to solve them, who imagine things that don't exist and want to figure out how to make them real. The tools have changed, but the joy hasn't. It's still this great, fun, iterative process. And honestly, that's amazing. That would be exactly what I would have hoped for.

That was the show. This episode was a bit different, just me sharing my thoughts on something that I've been thinking about a lot and that I know a lot of people also are thinking about. Whether you're skeptical of these tools or already using them, if this show resonates with you or makes you think about anything or change your behavior, hopefully just try some things out and have fun doing it. I'd love to hear about that. And also...

If you know someone who's resistant to trying these tools, who's a great builder, maybe share the episode. Maybe they have a more nuanced take, but please share it with them. And until next time, thank you so much for listening.