I hate that this is true

I think we've established that AI is really powerful for great and even okay engineers like myself. It's really good at doing what you tell it to, but you have to tell it the right thing. What about the rest of the engineers, though? The lackluster ones that are shipping React into things that it shouldn't be in, or are desperate to squeeze JavaScript into stuff that makes no sense, or just writing terrible Python code that powers things it absolutely shouldn't, causing outages at companies that just make you want to die. Here's where my hot take comes in. I think those engineers are actually better off as a result of AI. On one hand, they're able to do way more and as a result of that, they can cause more damage theoretically speaking, but I find that AI tends to steer people in a better direction. I think this is awesome and that we don't appreciate it enough. And I want to go into what I mean by this and why I think it's a good trend and how exciting this could potentially be for the future of software. I think we're all too focused on the slop side and not about the floor being raised. And I want to dig into that a bit with y'all. One of the many things benefiting here is that AI tends to make better decisions about what to bring into your projects than bad developers would by themselves. They might stick some mediocre technologies where they don't belong. Things like Flutter or JavaScript in places that they absolutely shouldn't be. Now, thanks to AI, they're making better technical decisions. Even I'm starting to use stuff like Rust more. It's important to build on top of good things like today's sponsor. I have a question for you. Is your app agent ready? I don't just mean, does it have an LLM's text or some crappy markdown file that describes how to use it? What I mean is, can it be signed up for with an agent? If I'm trying to use your service or something like it, and I ask my Codeex instance to go sign up for me, can it do it? And if it can, does it have to use a bunch of weird browser stuff? If so, you're clearly not using today's sponsor, Work OS. They already have Oth for enterprise figured out. But as enterprises are moving more and more towards agents, they realize there needs to be a better way to do that, which is why they introduced OMD. The point of OMD is to make it easy to set up Oth on services for agents. So if you're building an app that agents should be able to register your users with, OMD makes it trivial to do. It's already been adopted by Cloudflare, Firecrawl, Resend, Monday, and more. And it makes sense why. It's an open protocol that allows for your agents to register for web services. Forms are just not the right solution for agents. I was experiencing this earlier today when I was trying to fix things in a Google dashboard and I tried having codeex use the website and it couldn't even find the field to put the email address because they used the wrong treatment and it was a little too faded out for the agent to notice and I had to stop it, hop in and type it myself. That's just one of the hundreds of issues you can encounter from captas to dashboards to ooth consent screens and none of that makes sense for agents. A lot of these flows worked great when humans were the ones navigating the web, but reality is different. And if you don't have an agentready system, you're falling behind. And I'm going to be real. If any other company made this, I'd be really skeptical. But it wasn't any company. It was work OS. The guys behind O for OpenAI, Anthropic, Cursor, Perplexity, Versell, and you could read the screen. You know, everyone uses Work OS, even T3 chat. Build O that's reliable for you and your agents at soyb.link/works. Sorry about the fake start there. You got to do your job, you know. sneak in a Flutter junk, drop an ad quick, and then dig into an article that I'm sure won't piss anyone off. Should be a fun one. Sean God wrote this article, and as soon as I saw it, I knew it would have to be a video. AI makes weak engineers less harmful. I have personally seen this, and I am sure I'll have a lot of thoughts. Like other kinds of puzzle solving, software engineering ability is strongly heavy- tailed. The strongest engineers produce way more useful output than the average, and the weakest engineers often are actively net negative. Instead of moving projects along, they create problems that their colleagues have to spend time solving. I'll drop an even hotter take here. This isn't so much that like weak engineers cause problems as engineering gaps cause problems. If you have an exceptional engineer, like a top 1enter, and then a pretty good engineer, that exceptional engineer is going to get really frustrated that the pretty good engineer is like changing things they might not want to or getting in their way. You can ask any of the engineers on my team. I do this to them all of the time. I'm good at moving fast. I'm good at understanding systems. My actual code can vary in quality depending on how much effort I'm putting in. And I can absolutely be a detriment to my team. To the point where a lot of our culture now is that I show what I'm thinking of via a poll request with no intention of it ever being merged and then the team looks at it, tries what I had in mind, and then goes and builds it correctly. Figuring out how to keep engineering quality gaps from getting your best engineers pissed is essential. This is really big for retention in particular. Great engineers hate working around engineers that are meaningfully worse. So, you got to figure out how to balance things so those engineers don't get in their way or just don't last very long. But because these weak engineers get in the way, many tech companies will try and build small, ludicrously well-paid teams instead of large teams of more average engineers. And why so far this seems to be a winning strategy. Yeah, absolutely agree. This definitely is the winning strat. The bigger the team, the higher the chance people get in each other's way. I recently learned that new engineers aren't being taught about the mythical man month anymore. And that makes me sad because I remember learning about this in college and how hard it clicked for me. Actually, I think this came up in my like high school CS classes where I was just like doing very basic like Java programming and VB stuff when I was young. Yes, they were still teaching Visual Basic when I was a kid cuz I am that old. The Mythical Man month by Fred Brooks is a classic book on software project management famous for the central argument that adding manpower to a late software project makes it later. This is very unintuitive for people. Adding more people to a project does not make it faster. I know people aren't being taught this because I have to experience it every day. When I explain that like the T3 chat mobile app is delayed and will hopefully come out soon, that all of these features people want in T3 code are delayed and Julius is working on one thing at a time. The immediate response is, oh, why not bring on more people? You have this awesome community of people who will be more than happy to contribute. In some ways, yes. But at the same time, the work to orchestrate all of them, to onboard all of them does as much to slow down as it does to speed up. At best, they counteract. At worst, they slow you down. And I cannot tell you how many times I've experienced this personally with my own company and with other businesses I've worked at where expanding the team makes things slower. This is part of why I was useful at companies like Twitch. Not because I could debug us out of really hard situations, but if a road map was not going to be hit and a deadline was going to be missed, I could come in and trim correctly to get us where we need to be faster. I was almost like the counterpoint to this problem where I'm the one person you can add that will speed things up. They might end up slightly buggier. They might end up with less features, but they'll get [ __ ] done and they'll get done in time without too big of compromises. But this is a very rare thing and most engineers when added to a team will slow it down even if that engineer is exceptional. The additional overhead of managing a bigger team and getting them onboarded will slow down the people who are working enough that things get slowed down overall. Very important concept. There's a reason there's a book about it that has been cited for the last 40 years. It's because it's a real thing. Back to the article. Being effective in a large tech company is often about managing this phenomenon. trying to arrange things so the most competent people land on projects that you want to have succeed and the least competent ones are shunted out of the way. For instance, if you're a technical lead on a project, you more or less have to ensure that the most critical pieces are in the hands of people who won't screw them up. Whether by directly assigning the work or by making sure someone else can sit on the shoulder of the engineer that you're worried about. This is not like a single spectrum. You can't draw a left to right where on one side engineers are bad and the other they're incredible. There is multiple dimensions to this spectrum here. One of them is your experience. How long have you been here for? I would take a four out of 10 engineer that's been coding for a year over a seven out of 10 engineer that's been coding for 20 years because that four out of 10 has so much growth potential and a little bit of time put into them might slow us down right now, but that could be paid off later massively if I can level them up to get to that like 8, nine, even 10 range. The time you invest in a person to get them sped up is an important factor to consider as well. And I find that most of the people who aren't considerate of this either just aren't leaders, they're more IC's, they're focused on their deliverables and their tickets, or to be a little crude, they work at a company with really shitty retention and they're not used to investing in people because if somebody gets good, they just leave and get paid better somewhere else. So things to consider here. All of that said, Claude Code changed this. Frontier LLMs don't have the taste or the system familiarity of a strong engineer, but they've absolutely raised the floor for weak engineers. Yep, now we're cooking. Instead of getting a poll request that could never possibly work or would cause immediate problems, the worst you'll now see is a standard LLM pull request. Wrong in some ways, baffling in others, but at least functional on the line by line level and not so obviously incorrect that someone with no knowledge of the codebase could point it out. That's a huge improvement. Absolutely. Yes. I have seen some of the stupidest PRs imaginable. Both when I worked at a company where there was a lot of different technologies being on the only elixir codebase at the company when everybody else is doing JavaScript, Ruby and Go resulted in getting some PRs that were uh questionable that just fundamentally didn't understand anything about what was going on. That's kind of over now. The types of people who would throw those shitty PRs around are the types of people who lean heavily on tools like Claude Code. And as such, those people have meaningfully improved the quality of what they're shipping. You can try this out yourself. Attempt to deliberately make mistakes while working with a coding agent. You'll find that the agent pushes back hard against many obvious errors like caching user data without a user specific key, writing infinite loops that might never terminate, or leaking open files. Of course, the agent will still miss subtle errors, particularly ones that require understanding of other parts of the codebase. Yep, working with the least effective engineers is now sometimes like working with a claude opus or codeex instance directly that you're communicating with over Slack. I've said this for a bit, but like part of why I'm good at working with agents is because I had to work with engineers and run teams for the better part of 10 years now. And the quality of engineers varies wildly. And how much effort you have to put into prompting them, so to speak, varies wildly, too. Some engineers can take a vague ticket and build something incredible. Some engineers can have 30 perfectly detailed tickets for really simple things and still [ __ ] it up before they even get to the PR. Occasionally, it's literally that. Your colleague is just taking your message, pasting it into clawed code, and then pasting back the response. It's annoying, but it's still a much better experience than working with that kind of engineer directly. Yep. Let me give an example. This is going to be a funny one. The team I worked with on ModView was genuinely some of the best people I've ever worked with in my life. If I had any need for engineers, I would hire any of them in a heartbeat. They're awesome. I loved working with them. The fact that we got this project built as fast as we did with crazy deadlines is something I'm still proud of, and I'm more proud of the team than anything. They really stepped up and made [ __ ] happen. There were multiple times where like fundamental theories I had proposed on how to build this weren't panning out and I was ready to just give up and throw it all away and one of them would step up and be like, "No, I think that there's an angle here that will work and then just show up the next day with the thing I was convinced was entirely broken working." Incredible experience, incredible engineers. I would endorse the [ __ ] out of any of them anytime. I even gave up a promotion in order to get one of them promoted more aggressively because we only had so much room for that. It is what it is. Loved working on ModView. Really proud of the product. It's still in my opinion the most polished and reliable product which has shipped in a very long time. So why am I talking about this in a video about bad engineers? Because I'm not showing you Mod View. I'm showing you the blog post where Mod View was announced. This blog post cost me more sanity than anything I've ever built in my life. Because this blog was maintained by one engineer whose full-time job was posting things on the blog. See this broken purple thing here? That's supposed to be a demo. This is supposed to be a video that my designer meticulously crafted and made. She like learned After Effects to make the best possible video to demonstrate the product and it's now a purple screen. And not only that, she made a bunch of these and they're all now just purple screens. So what happened? I lost a month of time and quite possibly a promotion for how hard I crashed out over this. We wrote this blog post in Google Docs. We embedded links to the files for each of these videos that were simple MP4 files that we had on Google Drive and we sent that to the engineer who runs the blog because we there was no CRM. There was no way for us to write it. We just sent them the content in hopes that they would make the post and they did. but he wanted to have the videos embedded and he didn't know how to do that. So he converted all of these 4K resolution 20 plus second long MP4 files into 80 to 200 megabyte GIFs and embedded those 200 megabyte GIFs directly in the blog post. The page took almost a gig to load. My chat is reacting correctly to this information. I said, "What the actual hell are you doing? We gave you video files. please embed the video files. So he responded by uploading all of the videos to Twitch's at the time still almost functioning but not quite VOD platform where you could upload a video and then use their not really functioning iframe embeds to embed the videos. So each of these simple autoplaying demos of the product became a really shitty Twitch player that you had to hit play on, wait a few seconds, and then it would start to play part of that 20 second video that was supposed to be a loop. I said, "What the actual [ __ ] again?" So I went and converted all of these properly myself to webm files that I knew would be embeddible in the browser. I sent those to him. He said, "I don't see how this will be different, but sure." Then he uploaded the web m to Twitch the same way and switched over the URLs. I said, "What the [ __ ] Do you just not understand anything that's going on here?" And then wrote the HTML he's supposed to be putting in and tested it myself by inspecting element, but he didn't know where the video files would be. So I spun up an S3 bucket public. Had to get security permission to do it to host these files myself so I could give him the HTML to put in the page to finally have these simple web ms that I did all of the work for embedded so they would play automatically correctly. And then he used a shitty CRM to paste them in. And the result, I [ __ ] you not, was the plain text of the video element I sent him. This was two weeks of back and forth. Ultimately, I gave up and told them to go back to the version that had the video embeds from Twitch that is now broken and in this state. I need you all to be so real with me. First off, is it acceptable that I crashed out so hard I almost got fired over this because I think it's totally acceptable. I stayed a year and a half, but I crashed out [ __ ] hard over this one. Valid crash. Cool. Thank you guys. I got in trouble for this one. This came up during one of my promotion discussions. Like it it is legitimately possible I have lost tens of thousands of dollars because of this crash out because I didn't get a promotion because of it. This is also one of the many things that motivated me to say [ __ ] this and quit and do my own thing. So it worked out in the end. Why did I go to my superiors? You think I didn't go to my [ __ ] superiors? His title on LinkedIn is principal engineer. Insane. He's on a team alone. I think the reason this could happen is because he was so isolated nobody else noticed how shitty he was. But now I have question two. I need y'all to be real. Do you think Claude Code would have been better or worse than that engineer? Thank you chat. I rest my case. Does he for a chance work at Anthropic? Now thank you. Back to the article. The Slack interface is not ideal. Unlike using cloud code directly, you sometimes have to wait hours or even days for a response. How about two weeks? And you don't get visibility into the agents thought process, but it's still helpful on the margin. More compute being thrown at your problem is better than less. Of course, this isn't a great state of affairs for the engineers in question, who is almost certainly learning less than if they were making their own bad decisions. It's also a bad state of affairs for the company, who is paying a human salary and getting a co-pilot sub, which they're also likely paying for. After the current push to figure out what value AI is adding to engineers, I suspect there will be a push to figure out what value engineers are adding to AI and the engineers who aren't adding much may find themselves out of a job. Absolutely. As I said before, there's many dimensions to this problem, but I'm going to try and just do two axes. We have the dumb and god axis where one side the engineers embed webm via plain text and on the other side they invent the webm. But then we're going to have the experience axis. Generally speaking, there will be a trend here where the newer you are, the dumber you are. And the more experienced you are, the better you are. This is absolutely the trend that we would expect and hope for. But there will always be outliers. You'll have people like Nexel or Julius who somehow are brand new, but also really experienced. The quadrants are going to be weird for this because of the nature of it, but you get the idea. People who are like Julius that had very little real world experience but just understood [ __ ] great are going to end up there. But then there's people like the guy I was working with who was like 8 plus years in and just did not know what he was doing at all. And the way these people should be treated should be meaningfully different. Each of these quadrants deserves a different attitude and a different attention. I'm going to call this top right quadrant the normal goods quadrant. These are people who worked, they know what they're doing, they get paid accordingly. They work to get here. They are here now. If they use AI, right, they will be slightly more efficient. Not much to say about the people up here. Then we have the quadrant down here. What do I want to call this? I'm going to call this one the prodigy corner. This is people who despite their experience, things just click faster. They might not know how to navigate your codebase just yet, but they know how to solve problems with code. Well, I'm going to give a really silly example here. One of the services that I built, the one that got me into Y Combinator is Ping. It's a tool for doing live stream collaboration. So, if you want to bring a guest onto a show like mine, this had a lot of complex web application development problems, a lot of complex WebRTC problems for doing the video pipelines. This product was not easy to build. It was also not easy to contribute to because of all of the different layers that are necessary to build a service like this that is a web app that is a Zoom clone that has complex requirements around the WebRTC layer and the quality expectations that then embeds into OBS, a product that I'm using to film this video right now. All of these layers are complex and the first engineer I hired to help me with this, her name was Mel. She had almost no experience in traditional application development. She came from the game dev world and it was actually funny enough building a game engine in Zig. When she applied for the role, there wasn't even a role. I was a nobody, but I posted on Twitter that I was building this. She found my email on GitHub and wrote me what is still to this day the best cold email I think I've ever gotten when I had like 400 followers on Twitter. Not this Mel, by the way. Not Project Melody. Mel was an engineer who saw my post, was really hyped, found my email and sent me a very thoughtful, cold email of like, "Hey, I know this is a long shot. No idea if you're hiring. No idea if I'm even useful to you, but I really like what you're building. I'm a big fan of the like anime VTuber world stuff, which I didn't know anything about, by the way. I just had a friend who was that told me that this is a good direction to go in and worked out okay." She was more from that space and was really excited about this. So the combination of her getting what we're talking about and like who our customers were even better than I did, but also like being motivated enough to try and figure out the end slide was exciting to me. And I looked at her GitHub and was impressed with the things she had built. None of them were relevant to what we were doing here, but they were complex projects, especially for somebody who didn't have dev experience before. I think she had a job at like Starbucks or something if I recall. I can't remember for sure. So I expressed some concern just about the difference between the things she was building and what we were building. This is also the early days of the T3 stack. So, I told her a bit about my stack and how we build this and that I would come up with a programming problem for her to try to show her skills in the future. Within a day, she emailed me back saying, "Oh, this stack's actually really cool. I just went and rebuilt my personal portfolio with it and started building this other app with it and then linked me to two GitHub profiles of the things that she was building using this, just two new repos that she had spun up using the T3 stack way before anyone knew what the T3 stack was." I was like, "Oh [ __ ] you you get this. you're in. So I hired her, brought her on as my first and pretty much all the product stuff that was clearly speced that Mark and I were too busy to build. She would be the one to do. She helped a lot with the admin panel. She built all of our video and coding stuff that was used to like store the recordings of the calls and then send them to S3 so you could download them. All that type of stuff was her. Also was the one who patched a ton of random things to. She was super helpful. Loved working with Mel. One of the best engineers I've ever gotten to watch grow like that. About a year in after she built all of this useful [ __ ] we started working on the recording storage system and I had to sit down with her and Mark and one other ends at the time and spec out what this would look like. We pulled up Excaladraw. We drew out what all these pieces would be, how everything would work, how it would come together. This was Mel's problem, but we all specked it together. She was still junior. At the end, I was like, "Any questions?" This is also around the time that I had implemented my stupid questions rule where I required all new hires to ask at least one dumb question a day just to get them over the friction of being scared to ask things and look dumb. Mel internalized this so incredibly well that she asked a question that I'm still thinking about now 5 years later. This makes sense and I think I can do it. One of the best engineers I've ever worked with didn't know what an endpoint was because it hadn't been relevant to her yet. It wasn't relevant when she was building a game engine. It wasn't relevant in the T3 stack because we used TRPC for everything. So, it was all just calling functions. She just hadn't needed to know what an endpoint was yet. Incredible. But this is why I wanted to highlight things here because if you take a if I told you, I have this engineer with a year of experience and they just ask you what an endpoint is. Should I fire them? Most people would respond. But if I then framed it as this engineer who came from an entirely different field who's only been working on tech for a year, built all this awesome [ __ ] without even knowing what an endpoint was yet. There's a huge difference. Somebody in this top left quadrant could ask what's an endpoint and they should be fired. And somebody in this bottom right quadrant could ask the same question and it means something entirely differently. It's impressive that they got this far without knowing those things. And also that she had the balls to ask. The point I'm trying to make is that someone like Mel is disproportionately positively impacted by these things. The hottake I drew this for is to say people in this bottom section benefit massively from AI, but people on the left section look less dumb because of AI. So left of this line, dumb people look less dumb. Below this line, less experienced people can build experience faster. Imagine somebody like Mel that was less bold, more nervous. She was already pretty nervous, but was comfortable working with us in a way where she could ask these questions. Imagine someone like her that was too nervous to ask the question. Maybe they don't have that first job yet. Maybe they don't have the community around them to ask these questions and build this understanding with. Who the [ __ ] do they ask? And how useful is that answer? Imagine someone like Mel that's a little more nervous screenshots that diagram that she sees in a video of mine or in a meeting she watched or was in and then ask Claude code about that. Then she can ask follow-up questions and then better herself and learn faster. She was so motivated to learn all of these things and be able to build solutions to the problems her and her friends had. This was a time before AI she kind of had to use me like the AI where she would ask me the questions. And this is the framing I want to flip here is if you're treating the employees like the agent and you're prompting them and they're going off and doing the thing like cool fine whatever. I'm used to them treating me that way asking me the questions figuring out this stuff for me sometimes just to get permission. Like how many times have we all wrote the prompt would it be dumb too and then something that's like kind of dumb but could work. I love getting those questions especially when I had newer more junior engineers that would ask the dumb question and we would all get to learn as a result. that type of person can 10x themselves so efficiently now not because the AI prevents them from learning but because the AI accelerates their learning and that's the difference I want to draw here people who are in this section that are experienced but not very good AI makes them look smarter because they don't have to put as much effort in to do things but people who are prepared to put in the effort who are excited to better themselves in this bottom section here they are the ones who are going to win the hardest I just realized why this diagram sucks. Let me swap things around a little bit. There. Fixed. Now up is good, down is bad, left is new, right is experienced. This is the normal trend line. People who are above the trend line are awesome. We want more of them. Anyone in this area, anywhere on it really is good. People who are below this line are not. And if you find one of those rare engineers in this top left section here, the ones whose experience goes far beyond their knowledge, people like Mel who can build incredible systems before they know what endpoints are. People like Yash, our intern for T3 Chat, that figure out how to reverse engineer a Webpack bundles and insert additional packages into them via user scripts, which I've still to this day never seen anybody else do. I have looked online. There's no resources about that. Yos just figured that out himself. I thought Yos was in his 30s when I hit him up to hire him. Turns out he was in high school. Those people are the ones that are going to take these tools and go way further with them. And a mistake I want to make sure people don't make and will do my best to jump in front of is to make sure y'all understand newer engineers using AI does not mean they're going to make themselves dumber. This is a question of their motivation and their capability. And this is something you can't really change in a person. They kind of have it or they don't. Engineers who are above this line, generally speaking, are going to use the AI to better themselves and grow faster. An engineer whose trend line might have looked like this before, where they can get to that good end point a little faster. It might look like this now. They might just curve straight up and hit this god tier before they even hit four years into their career. And I see this happening to people. I know people who just realize that AI is the infinite learning machine. they can learn and understand anything through it and have grown way quicker as a result. So I switched the trend line to white to make that easier to understand because I want to draw the opposite which is an engineer that relies on these tools to never have to learn and their curve looks like this where the AI has prevented them from bothering to learn because they don't want to have to do it. I think this actually perfectly encapsulates what I'm imagining here and like what AI does. It takes people who were on this line, maybe slightly below, slightly above, and lets them curve in each direction. And there's even some engineers who are like this, that were doing okay, but then AI made it too easy to not learn and just immediately flatlined. I want to just make sure we're not measuring by how good somebody is at coding, but how good they are relative to how long they've been doing it for. Because there could be two engineers that are starting at the same point in this bottom corner. Maybe they both start from zero and they both look like they're relying on AI and they both can be more productive because of AI. Some of them are improving themselves, others are hampering their growth. So to this specific sentence in the article where the bad engineers, the weak engineers are learning less than if they made their own bad decisions. I don't necessarily agree. I think that engineers who aren't motivated to learn, this will absolutely be the case. But the fact that an engineer who wants to learn can try out all their different theories and learn more effectively what does and doesn't work is awesome. Worth noting that if the company doesn't have a lot of those engineers is just traditional weak engineers. This is going to be very bad for the company who's paying a human salary and getting a co-pilot subscription and then they're not doing much. You can't talk to Claude over Slack like you talk to normal Claude. This is actually a very good point. Isn't one of the things I love about LLMs? You can call them [ __ ] stupid and it's kind of okay. Someone made an awesome package, Dev Rage, that you can run with NPX Dev Rage, that measures how often you swear to different agents. Apparently, my claudis got wiped again somehow, cuz I had a lot more messages in here last time I ran it not long ago, but uh yeah, I swear in less than 2% of Codeex chats, but I swear in over 3% of Cloud ones. There was also a study that shows swearing at agents can sometimes actually make them perform better, which I find funny, but you get the point. It's okay to be curt to your agents. And more importantly here, this is my hottest take. It's more okay to throw the code away. Something I've experienced that sucks is when someone puts a lot of work into a thing and then you have to throw it away. This actually happened one of the implementations of the recording stuff that Mel was working on where we decided that that feature was no longer what we wanted. She had put a ton of work in and we had to throw it out because it wasn't the direction we wanted to go in anymore. And I felt awful. When an earlier career dev has only built like three things and they put the most work into the newest one and then you say, "Sorry, we can't use this. We aren't going to merge that." It feels so much worse. And I don't know if y'all have experienced this. I have guilt merged before. I knew it wasn't the right thing, but I merged it anyways cuz I felt bad about it sitting there and them not getting the hard work put into the product. I don't feel that with LLMs. I don't mind telling the LM code to like [ __ ] off. That was actually one of my favorite things with Elements. I no longer felt that guilt. And I've told my whole team, by the way, my PR should never be treated as things we have to merge. If you're not feeling it, just close it. I'm not offended. But unlike talking to LLM, if you're in Slack, a human's going to read your message, even if you're really just interacting with an LLM. So now all you have between you and the Claude sub is a person whose feelings will get hurt when you tell them their [ __ ] sucks. Skipping them and going straight to the agent is better. Not all net negative engineers use AI tools like this. Many are strongly convinced in their own wrong opinions about how to build good software or they mistrust AI in general or they believe that relying heavily on LLM is not a good way to improve. Oof. This is very true. I've seen this myself. There's a specific archetype of engineer that is very rarely good. There's like a handful that are, but I can list them on one hand. I'm going to call these people the anti-react devs. I'm going to put devs in quotes because I don't actually think any of these people build anything. The people who immediately will say you react whenever they learn anything used it. Some of them can actually be pretty talented and knowledgeable. Alex Russell is one of the few that I can think of here. Alex aka slightly late has some of the best web research and performance analysis stuff of any developer ever. I regularly cite his performance inequality gap content where he measures the performance of different phone CPUs at different price tiers every year. Those are my favorite charts. Fun fact, over the last four years, the $100 Android phone, like even though there's a new $100 Android phone every year, the performance has not improved at all in that time. In the 4-year window from the Moto E30 to the Moto E15, CPU performance has not improved at all. the year-over-year improvements for any given iPhone are bigger than the total performance for a $100 Android phone. This isn't like, oh, they are growing, but at different rates. No, the bottom doesn't grow at all. And this is a thing I didn't understand until I started reading Alex Russell's stuff. I did a threehour long debate with Alex Russell that's recorded and on YouTube somewhere because I think when he talks about React, he goes from one of the best developers and insightful introspective people in the webdev world to just genuinely kind of [ __ ] dumb. And it's crazy to see that dichotomy in somebody where they're both really really smart and in the weeds and know their [ __ ] but they have such a grudge against the thing that they cannot have an intelligent conversation about it. Imagine me with Flutter, but if Flutter was actually good. That's the difference here. And after he got removed from the Chrome team, they had to hire different people to come in and clean up the mess because he had built so much bad blood between framework authors like the React team and the Chrome team. This is also the person who's responsible for web components. By the way, the point I'm trying to make is that this is a smart person who has a dumb take. And as a result, there are a lot of much dumber people that have the same dumb take who will cite him as proof that they are right and everyone else is wrong and ignore the fact that the majority of the web is now React. Not the majority of websites, but the majority of hours spent on the web are spent on sites using React. That is just a fact. It is what it is. That's why hiring reflects the same. As a result, usually when somebody comes out really strongly against React, they're kind of dumb. Generally speaking, the person who I'm not saying I don't think this applies to them is Primogen. Primagen doesn't like React, but he's not anti-react. He just doesn't like it and thinks it's used wrong sometimes. That's a totally reasonable take. He's not the type of person who's going to reply to every post on Twitter saying, "Ew, why' you use React?" He just used it for some things, didn't like it in a handful of them, and tries to not use it going forward as a result. That makes all the sense in the world. Totally fine with that. But if you give somebody who has these deep-seated beliefs that are wrong an agent, and the agent wants to go down that react path, they'll tell it, "No, don't do that. React is evil and terrible. Do this other thing." And the agent will be like, "Yeah, sure. You're absolutely right." And do it. So, this will reinforce their bad beliefs and make them feel more productive despite having these bad takes. And that is a very real thing. And I agree that like that type of person isn't going to be very productive with LLMs because they're too busy enforcing their [ __ ] beliefs into the agents. I do love the call out here that no strong engineers are using AI tools like this. Even when they're being lazy or sloppy, a capable engineer will have enough baseline taste to catch obvious AI generated errors. So the phenomenon of engineers becoming thin wrappers around cloud code is limited to the kind of engineers for whom this is an improvement in their work product. Yep. If an engineer couldn't build because their taste was [ __ ] they might not notice the LM doing shitty things, but they'll still actually build something. That's the other thing about these anti-react people. I've never used any software any of them make cuz none of them make software. They just make rants on Twitter. The thing this post isn't saying that I think is worth noting, it's hinting at it here with the Claude over Slack stuff, is that when you break down these two types of weaker engineers where you have the ones who are weak cuz they're new, but they're learning and they're growing and using these tools to go faster, then you have the weak ones cuz they're lazy and got into code cuz they wanted to make money and don't care about it at all and they're using the AI to not learn it and just keep doing their thing. One of those types of engineers is going to do quite well as the industry changes and the other is going to get really really [ __ ] Imagine putting a filter in front of clawed code that just takes all of your technical advice and makes it bad. Imagine a sub agent that goes between you and your prompts that just takes the thing you're asking it to do and says, "Can you make this slightly dumber and use worse technologies and then passes that to the agent to go build it?" That's effectively what a lot of these people are and they have no place in the industry as it changes. there's the only thing they can be is an owner of the thing when it fails. They're not actually providing value directly. And these systems are going to cause that to collapse where in a previous world the gap between a good engineer and a bad engineer wasn't that big. Like if we were to have the bars like a bad engineer is a three out of 10 and a great engineer is an eight or whatever. The thing that has changed here in the short term is that the bad engineers can get a little bit better and the good engineers can get a lot better. But as the systems get better, the models get smarter, the tools get stronger, the good engineers are going to get better and better, deliver more and at higher quality. And the ones who are lazy, not paying attention, just phoning it in, they're going to get worse and worse. the gap's going to widen massively and everyone's going to be really confused when it happens that they thought they could just Google search results their whole career and now they're letting the AI do it, never actually understanding things. The engineers who don't know what an endpoint is and don't care to learn it, not the ones who don't know what it is and are nervous to learn about it. That's the difference. And that gap growing is going to crush these people. And to put this bluntly, for those who don't get it, which are this type of person, they don't get things generally. Life is about to get very rough for the bottom 30% of engineers. It just is. Engineers were so necessary for so long that you could get a job even if you sucked. That is no longer the case. So get good or get a new job because the future is going to be very different from how it is now. And the changes have already started. I'm just trying to be realistic here. I'm not saying that if you're a new engine, you're screwed. I'm saying if you're an unmotivated engineer, you're screwed. And those who tend to watch videos like this to learn about these things in their spare time that are however many minutes into this video, you're already probably better than average. You're going to be fine. Just ask your AI more questions about things. Try to learn. Write a journal every day about the thing you learned in a given day. And if you go to bed at the end of the day, you update your journal and have nothing to add, fix that before you go to bed. As long as you keep learning and growing and challenging yourself and pushing yourself into places you don't fully understand yet in hopes of growing and learning, you're going to do great. But if your goal is to see how much you can get away with, not how much you can grow, it's time to leave the field. I think I've said all I have to here. You all have a great opportunity right now. I hope you take advantage of it. And while weak engineers might look a little stronger than they did before, they're not going to last very long. But if you're weak cuz you're new and you're motivated to grow, you're going to do great. Just make sure you never give up on the learning side, as tempting as it may be. I got nothing else to say on this.