Is Learning to Build Software Still Worth It with AI? (My Honest Take)

0:00 reverse engineer anything. This is the latest viral GitHub repository and it is genuinely fascinating. It's a really good example of what we're able to accomplish with agents when we have

0:10 proper harness engineering. But I'm seeing this all over the place right now. People are completely blowing this out of proportion, saying if agents are able to do something this difficult, it

0:20 means that coding and engineering is entirely solved and we don't even have to apply our minds to it anymore. Or at least that's coming very soon. But there is a very specific reason why agents are

0:29 so good at this task in particular. And so we'll talk about this today and how that kind of plays into the larger conversation I want to have here, which is what is even worth learning as AI

0:40 starts to take over more and more complicated tasks like this. And I get it. With all the hype around AI and the doom and gloom in the engineering space, like this tweet that went viral last

0:49 month, it might genuinely feel like to you that it's less important for us to invest in the skills of building as AI gets more capable and we're just simply becoming meat proxies where agents are

1:01 getting good enough where we're just going to delegate all of the critical thinking to them. But this is not the way to go. I firmly believe that there are some skills that actually become

1:10 more important for us to invest time into as agents get more capable because not everything is reverse engineering. There are certain tasks that agents completely knock out of the park, but

1:19 that doesn't mean we can just extrapolated to it solving everything. So, keep this repository in mind cuz we'll come back to it in a second. But first, I want to hit the nail on the

1:28 head here. The big question that I've been teeing up is, is anything still worth learning with AI? And spoiler, yes, very much. There are skills that we want to be investing in. And the biggest

1:38 reason is large language models can't read your mind. No matter how powerful they are, you still have to have the larger harness around the agent to properly communicate your intent. That

1:49 is the shift that we're seeing in the engineering space. So agents do genuinely write all the code. I haven't written a single line of code myself in over a year. So I delegate the coding,

1:59 but I'm very much a part of the planning up front and the validation at the end. Even if I have a very elaborate harness with a super good large language model and I trust it to write very clean code,

2:10 I still need to make sure that I'm getting what I actually want. So if the agent makes a mistake, it's actually more my fault that I didn't properly communicate my intent. And so I need to

2:20 have the harness up front where it's grilling me with questions, getting on the same page, validating my intent at the end as well. This is never going to go away. And the skill of communicating

2:31 our intent and building the harness around the agent to allow us to do so is only ever going to get more important as we task our agents with accomplishing harder things. But the problem is

2:41 exactly because agents are so good at the middle part. Everyone is tempted to become a meat proxy. I mean, I've dealt with this temptation myself. Wherever I might receive a request like a Jira

2:51 ticket or something from a teammate, I'm just going to dump that right into my coding agent without any planning, any critical thinking of my own. And then whatever I get back out from the agent,

3:00 I just spew that back into Slack or as a pull request, whatever that might be. And so in this situation, the person giving the original request may as well have just gone to the coding agent

3:08 themselves because you've added no value in going through this process. But the code is still on you, right? Like as an engineer, you still have to take responsibility for the output even if

3:18 you didn't apply any of your own critical thinking. So you better make sure that you've communicated your intent properly because if you really are just a meat proxy, I can guarantee

3:27 for most tasks, the agent is not going to do it as you actually need because it doesn't understand the nuances of how you want to fix the bug or the feature you want to build, whatever that might

3:37 be. The point is, you absolutely do not want to be that person where if you get asked a question in Slack, you just dump it to your coding agent and then you reply, "Claude said," and then here's a

3:46 giant AI response. You make the other person review. This is the ultimate form of being a meat proxy. Okay, cool. I get it. But if it's so important for us to communicate our intent properly and

3:57 build that larger harness to make that possible, like I'll talk about more in a little bit, how can we have examples like this? I mean, with reverse engineer anything, if you take a look at the

4:05 readme here with their quick start, it is a very simple request to reverse engineer any kind of application. And with this MCP, I mean, the reason this GitHub repo blew up is because it is so

4:16 incredibly easy to build anything, to reverse engineer anything with it. But like I said at the start of the video, there is a very specific reason why this works. Think about it. The reason this

4:27 works so incredibly well is because the application that you are reverse engineering literally is the intent. You need nothing else to communicate properly what the final product should

4:37 be because the final product is already there. And so the agent is constantly able to validate its own work 100% reliably because it's able to see what it's building right now. Does that align

4:47 with the features or the behavior of the application that it's reverse engineering? That is why this process works so incredibly well. And of course also added in is the fact that there's a

4:57 very well-designed harness here. So of course that is important as well. But even with a harness generally you have to do a lot more of that intent engineering. But here you don't need to

5:06 because you already have it. That's why I think people are so wrong when they say that this repository proves that soon agents will be able to build literally anything. It's not a fair

5:15 example because it has such a good reference. Now, a lot of the things that we build, there are good references we can give the agent and you do want to do that as much as you possibly can. But

5:26 for most of what you build, it's simply going to start with an idea in your head or someone who's assigning you the task. And in that case, it is still up to you to communicate the intent with your

5:36 agent. if you just give it a vague idea, if you're just the meat proxy, you're going to produce good code because LLMs write good code, but it misses the point of what you actually want to build. And

5:46 so most of the time when you aren't, you know, reverse engineering an app and you don't have that clear example, you essentially have to make the reference, right? Like this is where as builders,

5:55 we still very much have to apply our own critical thinking because we have the agent gorillas with questions. We're answering these and actually putting a lot of thought into them as we should.

6:04 We're building up that reference with documentation like a PRDA, a plan document, whatever that might be. The point is we build the reference for the agent to go off of so it actually

6:13 understands what we want in the end. And so with all that being said, the most important skill to invest your time into right now as AI gets more and more capable is building the harnesses around

6:23 communicating your intent. So giving it references and allowing it to discover references when possible. Otherwise, going through the process of essentially building your own. A lot of people call

6:34 this intent engineering. Whatever it is, the point is you have to be able to recognize, apply your own critical thinking to know when you can give it examples and when you have to

6:42 essentially craft a replacement. Right? I've always said for years, examples are the most powerful thing for large language models. And it doesn't matter how powerful the LLM is, it still needs

6:53 that to really know what you actually want. The sponsor of today's video is Firecrawl. They call themselves the context API for AI agents. I covered their incredible search a few weeks ago,

7:04 but this time I want to show you Alexandria, which they just launched. It is a knowledge library, a massive catalog of over 100 data providers your agents can pull from directly for things

7:14 like benchmarks, company data, job boards, podcasts, and Firecrawl's own indexes for research papers and developer docs. And I'm able to access Alexandria directly in my coding agents

7:25 like Claude Code through the Firecrawl MCP server. So here I asked it to use Alexandria to answer the question which openweight model gives me the most intelligence per dollar for coding

7:35 agents right now which is a genuinely interesting question for me. And so first it calls into Alexandria to figure out the right data provider and then for free it can determine the cost of

7:45 searching through that data provider and then after that just a single call to pull the full leaderboard and get me the answer. And now that I found this model I want to hook it into my cloud code.

7:54 And so Firecrawl also offers their developer index which allows me to quickly search through a bunch of GitHub issues, pull requests, readmes, documentation. It finds the setup very

8:03 quickly here to incorporate this model with Cloud Code and even find some gotchas from the GitHub issue list for the Cloud Code GitHub repo. Firecrawl is free to get started with a,000 credits

8:13 per month and browsing everything in Alexandria doesn't cost anything. I'll have a link to them in the description. Now, not everything is reverse engineering where we have the perfect

8:23 reference. But for a lot of what you build, you can give a reference or even craft one for at least part of your intent. And so I want to give you an example of that from my own work. And

8:32 then I want to end the video by covering the test to help you identify as LLM get more capable. Is a skill still worth learning? Because yeah, there's a lot more than just intent. I don't want to

8:42 just leave you with that, even though that is the main example for this video. Cool. So now let me show you an example from my own work. So I've been spending a lot of time refining my AI software

8:52 factory recently and building a lot of different applications with it just to test it out. And so I've covered my software factory a lot on my channel already. I'll link to a video right

9:01 here. But the main idea is that you give it a PRD where you've done a lot of planning and of course communicating your intent. And then the factory is responsible for autonomously splitting

9:11 it into tasks and then knocking them out each one at a time to build out your full application. So very autonomous, but you're still very much a part of the process building that initial PRD. And

9:22 so I've been experimenting with this a lot throughout the year, and it's getting really, really good now. And so this is an example of a game that I built with it. And so I let the factory

9:30 go for maybe like a dozen laps to build out the initial proof of concept for this. And it's a it's a great game. And so genuinely, like this isn't like something I'd go and publish on Steam

9:39 right now, but it's a good starting point. I could definitely build on top of this. But the problem is the real game. I didn't actually want to be 2D like this. I really wanted a 3D game.

9:50 But the problem is I'm not a graphic designer or an artist in any way. I actually had trouble figuring out how I wanted to communicate that this needed to be 3D to the agent when I was first

10:01 building the PRD. Without a reference, it was really hard for me to get the agent to actually do a good job making something 3D. And so I ended up having to settle for this this 2D version of

10:12 the game. So, it works well, but it's not what I actually wanted because I failed to communicate my intent. And the reason I know it's not the agent's fault is because of what I'm about to show

10:22 you. And so, going along the same lines as reverse engineer Anything, I figured instead of trying to meticulously explain the 3D graphics and exactly how I wanted it to look, what if I gave it a

10:33 reference to work towards and set up the workflow in PRD to actually have it build towards that and then compare things side by side to validate. And that is exactly what I did with this

10:43 game. I've always really loved the graphics of this Legends of Zelda game. It's super unique cuz it's not fully 3D like, you know, Super Mario Galaxy or like of course a firstp person shooter,

10:53 but it's also not like fully top down like Pokemon cuz that honestly is more like just top down 2D. I don't know. I just I love these graphics. And so I figured what if I give this to the

11:02 agent? I plan with it up front like here's the game I want to emulate the graphics of maybe just a little less toyish and then I want you to constantly compare the output of the game to this

11:12 and just align on the graphics over time. And so this worked really really well. So here is a very initial proof of concept for the game that I built with the factory using the Legend of Zelda

11:23 game as the graphics reference. This is the first time I've actually attempted a 3D version of this game probably like five or six times already. This is the first time it actually looks close to

11:32 what I wanted because of this whole, you know, harness around validating against the graphics of the other game that I specifically chose. And there's a lot of planning and designing that went into

11:41 that. So, I definitely applied my mind. A lot of critical thinking went into getting here, even though I'm using a software factory with a very autonomous version of AI coding. But, I love this

11:52 and I just got started building this. Literally, I've had the factory only running for like a day or two on this application, but it's already starting to look really, really good. And just

12:00 for fun here, I'll show you what a battle looks like. Kind of like what we had with the 2D version of the game. Definitely a lot of things I have to tune up like this weird circle appearing

12:09 once in a while. U but yeah, like the combat is actually pretty smooth. Yeah, the game is just fantastic. And the important thing here is with every failed version of the 3D game, I'm using

12:18 the most powerful LLM, Opus 5.5, with a very elaborate harness, my software factory. yet I still need to spend a lot of time communicating my intent because without that your agent will write good

12:29 code that misses the point. That's why it is the most important skill to learn and it doesn't matter how much more powerful LLMs get. And so that segus really nicely into the test. We've

12:39 talked a lot about communicating our intent as the most important skill, but there's a lot of other important skills as well. The question to ask yourself is if the next model is twice as good. Does

12:50 this particular skill we're analyzing matter more or less? And I would say if it matters the same amount, it's, you know, obviously still worth putting your time into learning it. And there are a

13:00 lot of things that matter less. Now, as LLM get more capable, we have to deal with prompt engineering less. Like those little tricks that used to help you get better output just don't matter anymore.

13:10 We don't have to roll our own loops. LLMs do a lot of reasoning and walking themselves through a workflow automatically. And we have things built in harnesses like /goal. Giant rule

13:20 files. Even especially in the last few months, we've learned that really long rule files trying to communicate all of our constraints and conventions can sometimes just bloat the agent more than

13:28 help. LLM don't need to be taught general software engineering principles, for example, like they used to be maybe a couple of years ago. And it's crazy because even a year or two ago, these

13:39 things used to matter a lot. like prompt engineering and crafting good rule files, but it's just not where you should be investing your time. Where you want to invest your time is everything

13:47 at the bottleneck with the planning that you do before writing the code and the validation after, right? especially communicating your intent, but even just like the harness engineering as a whole,

13:57 building your skills and sub agents and hooks and bringing that together into the more comprehensive system for your agent. Like what I'm working on with the software factory, what the person

14:07 engineered for reverse engineer Anything, right? For every single powerful system, there's someone who's put a lot of critical thinking into this system to set the agent up for success.

14:17 Because as LLMs get more and more powerful, we're just going to give it harder and harder tasks. And so we still need our conventions and workflows built in. And so yes, we're not going to focus

14:27 as much on the rule file and dedicating hours and hours and hours to crafting out like we did before, but going up to the higher level. This system is still very critical. Like I always tell

14:37 software engineers, we are no longer engineers of the codebase. We have delegated that to the agent. Instead, we are engineers of the harness for the agent, setting it up for success and

14:47 using every mistake as an opportunity to make our agent better. And so, for some engineers, they don't like this. You might like coding, but you don't like building these harnesses. I get it. It

14:57 doesn't jive with everyone. If that's you, I am truly sorry. Like I understand that your role might not be as fulfilling, but at least for me, and I hope this is for you as well, building

15:06 these harnesses is very satisfying and fulfilling because you're getting the job done in the codebase just in a different way. And it's so cool to see your harness get better and better over

15:15 time. That data flywheel making it so you just operate more and more efficiently, assuming you're applying your critical thinking to build it out, and you're always making sure that you

15:24 communicate your intent and you're a part of that process. And so with that, that's everything I had to cover in this video. I hope the test was helpful, just helping you think about what are the

15:33 skills still worth investing your time into because there are definitely still a lot even with LM's getting so capable, especially with this biggest example here of we always need to communicate

15:42 our intent and have a part of the harness for that. And so I hope that you found this useful. And if you're looking forward to more things around agentic engineering and what I've covered here

15:51 with intent engineering, I would really appreciate a like and a subscribe. And with that, I will see you in the next