Soybeans and Silicon
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 my 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. That friend coached 8-year-old me through the whole ritual of getting into DOS, sliding in the disk, and typing “NUKEM.EXE,” 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 CoRecursive, and I’m Adam Gordon Bell, and today I want to talk about something that’s been dividing the developer community, AI coding agents. This isn’t another, you know, AI rule replaces 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.
Born an Outsider
On Stranger Things that the eighties era and 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, 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, 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 it was different. That was clear, but it was never clear to me exactly who I was and, and why or how I was different.
After high school, I went to 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.
Finding My Tribe
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, building games in Unity, or just doing these things for fun. I would say my favorite author, you know, was Ted Chang, and somebody else would say, “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.
Addicted to Making
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 for, you know, where hours disappear, chasing down edge cases and getting that hit of dopamine whenever something clicks into place.
It reminded me of being a teenager, right? Growing up in the country, 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 you know, I would go outside and I would go play. But the most exciting things for me were those building moments. 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. 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, I see a problem and 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.
My Digital Clubhouse
In San Francisco, I met these people, and it turns out there were a lot of people like me—folks who liked building projects, who liked writing and sharing ideas. A lot of them at this particular place came from Waterloo, another place in Ontario, and then had moved to the Valley. But I was still in Ontario, 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, learning math, or doing whatever just for fun, right?
After years of feeling like an outsider, it felt like home.
The Great Coding Rift
But now, early to mid 2025. If you look at Hacker News, that sense of belonging for me 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 Claude, 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.
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. 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 Claude seven or ChatGPT six drops and suddenly it’s eight times better at coding than anybody, that doesn’t mean that I’m gonna wanna stop building things. It doesn’t mean that you’ll wanna 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.
Trading Code for Meetings
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 remotely 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 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 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, do a git pull, and see, you know, it’d be 37 days since I’d last pulled the code. All I would need to do is some small task, open a PR, and then Adrian would approve it two minutes later.
And I remember him saying in Slack, “Feels good to ship something, doesn’t it?” It did. But honestly, that feeling faded as fast as the GitHub Actions build because the rest of the day was meetings: Ireland at 8:00 AM, then DC folks, you know, through the middle of the day, Pacific Coast, near dinnertime. I started having my phone on this tripod with earbuds in so that I could go down for coffee while still in a meeting. I spent way too much time reading and updating Confluence. I just hate Confluence. There was a lot of Confluence updating, a lot of digital paperwork, and a lot of 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, “Don’t stress about it. 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 wish I could take my own advice, but I found that I couldn’t because, as 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, you know, 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, Claude Code, 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 is hard. I guess what I’m trying to say in my long-winded way is that if you’re a builder and 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.
Reinventing Myself, Again
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 that 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 wanna 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 you forget about everything else. It’s just, it’s a great feeling.
Yeah, 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.
Side Projects That Spiral
Here’s a weird example. If you check out the podcast website CoRecursive.com, there is a /rankings page, and on it, you’ll find sub pages 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 a, and honestly, I never even checked the results. I’m not even sure I used the tool, but yet it still exists, and it’s still running daily, gathering metrics, and probably at some point, I’m gonna try to rebuild it in Python. Because that’s just what I like to do.
The Chess Engine Moment
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 todo list, but to build something hard, to work in a large codebase, 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 offered. There might be a better approach, 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’ve 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, yeah, treat it as a learning project, not because you have to love it and not because it’s gonna 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, you know, years and years of muscle memory burnt into them. You know, 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. You know, on Zoom screen shares, I’d fumble to do basic tasks with everyone watching and hitting the wrong keys and getting nothing. You know, “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 five 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 at 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.
Treat This as a Learning Project
But yeah, if you wanna 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, you know, 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 claude code. Use amp, use cursor. Seems very popular, but there’s a million of them. And yeah, you’re gonna 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 fun I’ve had, but first, you know, some advice. You can’t treat these coding agents as some magical AGI that’s gonna fix everything or make you 10 times faster overnight. It’s not that. 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 OOP.
Start Small, Start Smart
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’s hands 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. You know, 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 wanna 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 and 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 LLM 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.
Building With AI
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 MP four, 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 open up vs code with amp in the sidebar, and I started dictating I literally talk into the box. For the prompt using Mac Whisper, I’ll say, I wanna download YouTube videos and generate a transcript. Then I wanna identify key visuals and note them in this file. You know, 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. Yeah, we do software design together. I use it as an advanced rubber doc. 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 I 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, and I don’t super trust them because my experience of building is, is very iterative. I like this back and forth. I wanna 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 wanted.
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 forth and there’s testing and there’s adding new conditions and there’s amp going out and digging through the docks, 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. ‘cause there was a lot of back and forths, but it actually came together pretty fast. And on my own, I would’ve 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.
Beyond ‘Not Perfect’
Now 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 an AI is supposed to be so advanced and maybe even replace this, 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 an AI. If it was an AI, 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 a AI 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, and 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. Before you do that, you have to get past your own fears and biases.
What HN Gets Wrong
Here’s an example from Hacker News. Someone complained that code generators like Claude are inefficient. They ask 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 then some photo programs like to ignore that header and display them sideways. 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 gonna 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. Right? The same would happen if I were designing something with a colleague.
Will I Get Worse?
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 built 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. 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.
So, 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. You know, 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, right? 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. Right? If you’re having trouble getting real work done with coding agents, it’s 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 is totally fair to feel frustrated or want to walk away or try again next year when they got better. But I pushed back a little bit, right? This stuff is new and honestly, it’s fun to mess around with, and I think it’s worth exploring.
Automating Curiosity
Another thing I built before Chat GPT’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 what their pivots were. Right? 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 from that. When I first used it seriously, it was for the Hatetris’s interview, and those guys being very detail-oriented. They prepared their own timeline of them building Hatetris, and I found a couple of things that they didn’t include, and I thought they might be hallucinations, but they weren’t. It was 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. 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 various concerns and then send it off and get some feedback, and we iterate and we do some design together.
So I 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, uh, 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, uh, in a way that’s faster than waiting for the build to run, which is sometimes slow.
New Tricks, Old Habits
I wasn’t always programming in Python. Uh, that’s a relatively recent thing, but I’ve been using Python a lot because agents work with it so well. 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. 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. Once we’ve done the first one, I can say, “Okay, now do the rest.”
This exists in a whole bunch of files. Then the call sites need to be updated, or, you know, there are eight more instances of this, and 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: 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 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, you know, two-thirds of the codebase 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.
Thinking Like an Architect
Okay. Another vacation story. Over this last Christmas, Kourtney and I were in Mexico. We were on the Yucatan Peninsula at an all-inclusive resort. 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 while I was trying to reverse engineer Descript’s file format so that I could programmatically edit my podcast. Three hours in, I had tracked down where Descript stores its project files; it’s a zip file that contains a whole bunch of documents.
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. I realized I was attempting something that I never would’ve tried before, not just because it was technically ambitious, but because half of it was in a language that I didn’t really use and analyzing code that had deliberately been made unreadable.
A breakthrough came when I figured out that I could use this backup and restore workflow in Descript, make changes to the zip file, and then restore the project from backup. Then boom, my edits were in place, but I wasn’t getting bogged down in the grunt work of parsing all these JavaScript files and getting things edited in the right spot or deciphering crazy functions. I was working at a level higher and telling the LLM specific things, like we only want to depend on the parts of this JavaScript file that we need. Because if they make a change in their format, 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 LLM was doing all the detail-oriented grunt work, and I was describing 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 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 Kourtney read in her book, I realized something had changed. I was thinking at a different level. I was exploring an interesting problem 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.
Awkward Means Growing
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. 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 SCC habits over, you know, pattern matching and immutable data structures and whatever. And some of it translated well, but some of it was just fighting against the language. But working with an LLM, 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’ve 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 some known data structures that you pass around, but it’s helpful to have a native speaker when you get into a new area. They can teach you, you know, the rhythm of the language. And because the LLMs 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.
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 until they’ll just slow you down. Maybe you just wanna focus on other skills right now. That’s completely fine. Not everybody needs to be on the bleeding edge of everything all the time.
Anti-Anti-AI
That’s cool. My friend, and previous podcast guest, Chris Krycho, 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 out code 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. So 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. 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. 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.
Choosing to Build
Am I worried that an AI breakthrough will come around and replace all analytical thought that 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 that works, 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 wanna 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’ve hoped for.
Still a Builder
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, you know, 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 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 or maybe they have a more nuanced take, but please share it with them. Until next time, thank you so much for listening.
