There’s no shortage of takes on AI and software engineering right now, and most of them come pre-sorted into one of two bins: it changes everything, or it changes nothing. Gustavo Medori doesn’t fit neatly into either. He uses coding agents constantly. He also has firm, specific rules about what he’ll never hand off, and he can tell you exactly why, with receipts, including one very expensive outage at Apple.
Gustavo has been a software engineer for about a decade, the last five years of that on Apple platforms. Before that, he did “a little bit of everything before doing Apple platform development — backend, frontend, web, just the whole nine yards.” That range shows up in how he talks about AI. He’s not defending a stack or a job title. He’s talking about judgment.
What follows is part of a longer conversation about AI. You can catch the full interview inside the Treehouse AI Bootcamp.
Treehouse: Where does AI show up in your day-to-day, and where doesn’t it?
Gustavo: The way that you leverage AI such that it has a meaningfully positive impact on your work is to get it to take care of the stuff that you don’t enjoy doing, so that you get more time to do the stuff you do enjoy.
I use AI a lot for the stuff on the periphery so that I can spend more time actually thinking about the engineering problems that I want to think about.
For Gustavo, “the periphery” means PR descriptions and stakeholder updates — an agent pointed at his repo, GitHub, Figma, and Slack drafts those for him.
Treehouse: What are you actually running?
Gustavo: I think Claude Code had this big boom in popularity in 2025 because it packaged the agentic loop really nicely for everybody and didn’t require people to spin up their own setups too much. I like Claude Code a lot for the simplicity; you just download it, and from there, Claude can help you build out things to help it work better for you.
More than anything, I find that it’s most practical to use AI to reinforce your own learning, because as engineers, we’re constantly learning every day, all the time. Any way that you can find in your workflows to have it challenge your ideas and assumptions, allowing you to understand those challenges and either pivot or reassert your stance, is the pathway to not just better quality code, but to you becoming a better engineer.
Treehouse: How do you decide when to let AI write something versus writing it yourself?
Gustavo: The first metric that I use is: if my coding agent writes this code for me, will I understand sufficiently what it has written?
One of the things that gets lost in the AI hype—and it’s probably one of my biggest qualms with the software engineering industry as a whole right now—is all this hyperbole going around with people saying that so much of your code should be written by AI now. What seems to get lost in that conversation is, well, what happens when something breaks?
When something breaks, if you throw up your hands and say, “Hey, the AI wrote it, I don’t know,” it’s not going to fly. The thing is broken.
When I was working at Apple, I remember we had an outage for one of our payment systems, and we were literally losing millions of dollars per second when that happened. You can imagine that if that’s what’s happening, your engineering director is going to come over and ask what happened. If you just shrug, you’re going to be in trouble.
Treehouse: People talk about “vibe coding” versus “agentic engineering.” Where do you draw the line?
Gustavo: When you’re vibe coding, I like to think that you want to keep the blast radius small—only vibe code things where, if it goes wrong, the only person that gets hurt is you.
Whereas if you’re doing real engineering for other people, you have to read the code.
As time goes on, especially if it’s a field that you’re an expert in, the distinction between you writing the code and you not writing the code isn’t really what’s going to make the difference. It’s going to be whether or not you can read the code, understand it, and know what you’re committing to the repo if someone asks you, “Hey, what did you write last week?”
Treehouse: What does your review process look like before you merge AI-generated code?
Gustavo: That’s one of the reasons I like Claude Code—I feel more like I’m in the driver’s seat. Something like Codex and other coding agents may take an approach of, “Let me go build the whole thing, and I’ll come back and show you when I’m done.” For me to enhance my own personal understanding of the code that’s being written, I like to see the bricks being laid one at a time.
Obviously, any code that you commit to a repo should undergo a human review process, unless you are literally a one-person team. Even then, you should probably review your own code.
For unfamiliar code, Gustavo points a second AI at his own pull request — but with named targets, never a vague “does this look good?”
“Hey, what do you think of the code that was written here? Can you spot and specifically call out any typical anti-patterns? Can you spot anything that breaks encapsulation or anything that could be a security concern?” Specifically call out things that you want it to look for based on the domain that you’re working in.
Treehouse: What part of the job has AI genuinely made better?
Gustavo: Well-written unit tests are so important to ensuring a high-quality codebase, but the biggest barrier to a well-tested codebase has always been the motivation to test.
It turns out AI is really good at tedious, mundane stuff.
AI has given me a really high degree of confidence that the quality of my code is going up.
Treehouse: And what’s been lost?
Gustavo: I think the ways in which LLMs maybe have worsened or changed software engineering as a discipline is that, inevitably, you do feel more distant from the code.
There is something that can’t be understated about how meditative it is to write out code by hand. There really is something to the fact that your brain, in this sort of focus flow state, draws connections and has insights that maybe you wouldn’t otherwise have unless you’re in that state. When you’re using AI, you’re in that state less.
One of my personal goals is to use AI to find more of that time to be in a flow state, to have that focus time, and not just constantly be cranking out features. That’s where the really satisfying parts of the job are.
Treehouse: What would you tell a developer who’s new to the industry and hasn’t started with these tools?
Gustavo: I would say probably just pull down Claude Code and go dig through the documentation. The documentation for Claude Code and Codex—which are the two biggest ones—is excellent out of the box. That’s why I recommend people start there.
Seriously, read the documentation, get your feet wet, and always have a project when you’re learning a new type of programming. Have an end goal in sight and focus on getting there, because it forces you to arrive at edge cases that you might not otherwise hit just noodling around and making toy projects. Build something real that you might actually use.
Treehouse: And the holdouts — people staying away on purpose?
Gustavo: Those reasons may be moral: concerns about the environmental impact of AI, the ethical impact of how they’re being used, or how they’re impacting mental health. These are all 1 million percent valid reasons to be a holdout. If AI makes you uncomfortable, I get it.
Probably the thing that resonated with me the most is how we use these tools responsibly. . .That’s an idea and a “thought technology” that I got from Simon Willison, and it really unlocked my openness to adopting the technologies myself as someone who cares deeply about the craft.
For the curious ones, his recommendation is Simon Willison’s blog — the source of the “blast radius” idea that structures his whole approach.
Our thanks to Gustavo for the time. You can hear the full interview inside the Treehouse AI Bootcamp.
Ready to Build That Foundation?
Everything Gustavo said comes back to one thing: the tools are only as good as the judgment steering them. You have to be able to read the code. You have to know what to ask for. You have to recognize when something smells fishy.
That’s the philosophy behind the Treehouse AI Bootcamp: four weeks of structured, project-based learning that gives you the working knowledge to use AI coding tools with confidence, not just the ability to paste prompts and hope. And in keeping with Gustavo’s advice, you build something real.
It’s self-paced, built for people without a technical background. And it includes Gustavo’s full interview.
Any plan gets you into the AI Bootcamp →
Try it free for 7 days, then $25 a month.
Frequently Asked Questions
Gustavo’s test is a single question: if the coding agent writes this, will I understand sufficiently what it has written? In a domain you know well, AI can draft while you read every change. Outside your expertise — he uses spinning up an Android app as his example — use AI to learn the problem space instead of generating code you can’t evaluate.
Vibe coding is generating code without really reading it. Agentic engineering is staying in the loop and reviewing every change. Gustavo’s rule for the first: keep the blast radius small, and only vibe code things where the only person who gets hurt if it breaks is you. Anything other people depend on gets read.
Scale the review to your confidence in the domain. On familiar ground, watch changes as they’re made and interrupt when something breaks encapsulation. On unfamiliar ground, require human review — even solo, open a pull request to yourself and come back with fresh eyes — and point a second AI at the PR with specific targets: anti-patterns, broken encapsulation, security concerns.
Unit tests. Writing them is mostly pattern matching — find the mutable state, drive the code into that state, assert it got there — and AI handles that tedium well. Reviewing test code is far easier than writing it, so the engineering discipline still applies. Gustavo’s other big win is the periphery: PR descriptions and stakeholder updates.
Read the Claude Code or Codex documentation before anything else, ask the agent what it can do, then build a real project rather than toy exercises.
