Opus 5.5 is proof that we do need smarter models Transcript, AI Summary & Key Points

00:00 I'm going to be real with y'all. AI's gotten pretty damn smart. It's a hell of a lot smarter than I ever thought it would be. Just 2 years ago, a blonde guy with a mustache that somehow had access to this YouTube channel did a video called AI isn't going to keep improving, where he relatively confidently asserted that we were going to hit a plateau with how intelligent AI could get that would make the improvements more and more marginal as we tried using these new tools.

00:23 I made that video before Opus 4.5 was even in training. And the amount things have changed since then is truly hard to comprehend. We went from AI that could autocomplete when we were typing occasionally to being able to ask real questions about our codebase, tell it which files to edit, and now we're at the point where we just hand it a screenshot of a bug and trust it to figure it out and test it and get it merged.

00:46 It's crazy. But with all that, my take changed a bit. I went from thinking that it wouldn't keep getting smarter to something a bit more bold. I started to think we might not need them to be smarter. And I felt this many times when new models drop. It's like, "Oh, this is so much better. I can barely figure out how to take advantage of this level of intelligence.

01:04 I have no idea why we would want anything smarter." I felt this with Fable 5. And Opus 5.5 has changed my mind. Not just because it is better at doing the things I do every day or it's faster, it's cheaper, but because it's smarter. And I don't just think this is better for coders. I think it's better for a lot more people than I ever would have guessed.

01:26 I used to think that these model improvements were only going to really benefit a select set of people who were always on this bleeding edge, pushing the limits of what they're capable of. I was wrong. And the reason my mind changed on this is sillier than you probably think. Yes, it's Halo and Call of Duty. While I'll gladly admit I'm a sucker for skateboarding stuff, I do think this represents a huge shift where models getting more capable is going to benefit a hell of a lot more people than just software devs.

01:59 Let me explain why everyone will benefit from this after a quick word for today's sponsor. I know this is supposed to be an ad, but I want to give a real quick history lesson. Back when AI first started getting attention, it was to answer basic questions using the knowledge that it had. It progressed very quickly to the point where we were using it to edit files on our computers using tools like Claude Code.

02:17 I think we're about to enter a third era. An era where the agents aren't just working within the little box of the website they're on or the computer that we're running our systems in. They're going to start doing real work for us. But in order to do that, they need to be able to get out and do things on the web, which means they need a platform that supports this.

02:35 Today's sponsor is Browserbase. And man, I wish all the personal assistants I used were using them. There's a lot of layers to why I think browserbased is the best way for your agents to do things on the internet, but I'll start with one that has been really frustrating as I've leaned more into Grockbot authentication. When I want to let my Grockbot access a service that isn't already a plug-in, I have to let it spin up a computer in the cloud, open it up myself, go to the web page, and sign in.

02:56 But if they were using BrowserBase, I could link my one password account, and it's handled for me. Not only can Browserbase handle the signin, they can also handle the management of your sessions and persisting them so that your agent doesn't have to sign in again every single time it makes a request. I know this sounds trivial, but you have no idea how much everyone else is getting this wrong, even the major labs into their personal assistant tools.

03:16 That's all great for the signedin experience, but a lot of what your agents do is finding things on the web and accessing them. That's why the search API is so useful to get a bunch of results that your agent might need, as well as the fetch API, which will turn those results and pages into HTML, JSON or markdown. This is way more reliable than a curl will ever be.

03:33 Considering that 85% of APIs on the web cannot be accessed via curl, this all comes together with a really, really powerful experience. Unblock your agents and see what they can do at soyb.link/browserbase. While I could sit here all day and watch all of my favorite childhood games get reverse engineered, decompiled, and mashed together in these crazy ways, this is just like the tip of the iceberg in a lot of ways.

03:55 And I'm realizing this stuff goes a lot further than I would ever have guessed, especially for people who might not be engineers. It's genuinely kind of silly that it took all of these game mashups to make me realize that everyone can benefit from smarter models, but it it really made it click for me. And there's a couple different angles to this. The most obvious one is the one that we've all been living with for a while now.

04:20 Smarter models means devs can make better software faster. This has been the case honestly since like Sonnet 4. That AI could allow developers to take their road map, their plans, the things they were going to build and get through those faster and deliver software their users want more effectively than they could have before. And as models have continued to get more capable at dev stuff, the amount that a dev can do has gone up exponentially.

04:48 I'm shipping more code in a week than I shipped in all of last year at this point. It's crazy. And I know it's all slop or whatever. You guys are just wrong at this point. Half the code that my AI is writing for me is better than all the code you've written in your life if you actually think that way. Like it's insane how far these things have gotten and how capable they are at making good decisions and doing real work.

05:06 That is all good and dandy, but we're still presuming that the person has experience because that is kind of necessary to get the most most out of these tools. So devs can do all of these things and when they do these things and make better software, people benefit because they can use the programs that might not have been worth building before. For a silly example of this, I built a service called Lawn.

05:28 I was using Frame.io and I was getting more and more frustrated with how slow it was, with how expensive it was, with how Adobe it was starting to feel, and how annoying it was to just send a quick link to one of the brands that we're working with for a review and stuff like that. So, I threw together an open source alternative myself in a few days, and it works great.

05:49 This is how we do all of our video for my team. Now, for reference, Frame.io was acquired by Adobe for $1.3 billion in October of 2021, and I would legitimately say we have about 70% of their functionality that they had at that acquisition point, as well as a ton of extra things that they still don't have today. That was considered a $ 1.3 billion product not that long ago.

06:12 And now at the beginning of the year, I was able to recreate it and open source it because why not all trivially. It's crazy how viable these types of things are when before they just absolutely weren't. And that was with like Gemini 3 Pro and Opus 46. Do you know how much it's improved since then? It's crazy. And I didn't even need to reverse engineer anything for this because the way the core product works made a lot of sense.

06:40 It was just all the integrations and like edges you have to hit to make it work that made it hard. But that's a program I built that a lot of others have benefited from. It's not like a huge product, but there's a few hundred people that use lawn to power their video pipelines for a lot of YouTube channels that you and I both watch, which is super super cool.

06:55 And people have even been forking it and building their own things on top. And that was where the next layer started for me. So I already have professional devs are able to make better software with smarter models. But the next piece I've been seeing, I'll call technical people. There's no good term for this. I don't want to be like offensive. It's the types of people who like maybe they played with code a bit and just decided it wasn't for them.

07:18 They're very smart. They're very capable. They just didn't go the route of being software developers for a living. I I would argue somebody like a a Linus Tech Tips would fit this archetype to an extent. not script kitties, but like people who know their way around a computer and have a good intuition for what software can and can't do, but very little intuition on what is or isn't realistic for them to make.

07:41 And what's cool with these people is the power they get as models get smarter because they don't understand the limitations of code as well. They understand limitations of the thing the code does. They don't necessarily understand limitations of like different frameworks and tools and ecosystems. And if their app's getting really slow and they built it in Rails, they don't know what is making it slow.

08:02 They might hear that planet scale is really fast and railways really fast and end up spinning up both in different regions and then their app is really slow and they just don't get it. As models get smarter, those gaps start to get plugged too and they can ask questions like why is the app so slow now? And it can do the types of analysis to get these answers.

08:22 A highly motivated technical person that just never quite got good at coding can do so much more now. They can fork software they rely on. They can now also debug systems far beyond their understanding. They can whip up scripts or fork some program and when it doesn't work how they expect it to, they can change and adjust. The same way that like you could open up your computer and swap a part.

08:47 These same technical people can now open up their software and swap things out too. Previously, they could like make their own small little apps with AI. Now, they can ask the AI to fork some tool they use and make changes to adjust it to their liking. They can reverse engineer apps they're using every day, like Codeex and Chat, GPT or Discord, and insert JavaScript to change the experience in the product.

09:08 All of that was super cool, but it was very personal. didn't like scale out the same way because models just weren't great at like packaging the work they had done and making it so others can adopt those things. You might be able to make a cool plugin for your local Discord, but setting that up in a way others can use it was still complex and dangerous and hard to get right.

09:29 But while devs could make things others could use, technical people could use the AI tools to customize what they were already using, but not necessarily to productize it and give it out to others. And that might be my initial framing here. Tier one is it helps the things I'm good at. This is like I'm already editing code and I ask the AI to customize a function or maybe I let autocomplete drive some of the lines as I'm changing them.

09:51 Then it can make edits to the things I use often. This could be using AI to customize a tool that you use every day to fork a library and make some slight adjustments to it to do your job more effectively, but it's still like very personal. Like the AI and the thing I build with it isn't really leaving my little bubble. Tier one, I am telling the AI like what its constraints are and building everything around it.

10:13 Tier two is I'm letting it do a bit more and it's exploring places I'm not as familiar, but it's still limited to me and my little circle of like the software I use. This is using AI to build a personal Chrome extension or to make a Discord script to change how Discord works for you or even like the personal AI assistance and things. All I would put here.

10:30 Then it gets to the point where they can build things you don't fully understand where I have a bunch of projects I've been working on in Rust. And I don't actually write Rust. I barely understand the language. I played with it a bit. I find it tedious and annoying. But I'm writing a lot of projects in Rust now even if I'm not writing the code. And I'm also able to distribute those projects and I will be shipping many of them to real users in the very near future.

10:51 And then all the way at the bottom, there is the crazy new unlock tier of, oh [ __ ] we can use these tools to decompile, reverse engineer, and rebuild the things that already exist in the world at like their very core. Things that like are basically impossible to understand. Like no one fully understands the decompiled codebase for Super Mario 64. That's just not viable.

11:14 And it's magical truly unbelievably so that these tools can build a good enough comprehension of something like that to operate within it. The reason I'm tearing this is when model level ups happen there are different categories of people that are affected differently. So if we have devs for example, when AI coding first started to be a thing with like OG co-pilot, it would help devs with things they're good at and technical people were not helped at all in this framing.

11:43 Like they could ask it questions and get answers, sure, but they're not building things with it yet. But then the models got better. And then they got to the point where they could like actually use a tool and edit some code. And then this happened. Technical people could use these tools to like customize their homepages or like work on their Wix site and stuff like that.

12:05 Devs could suddenly use it to actually customize the tools they use to edit some packages that they're relying on to make real changes to their codebase that are multiple files that are being touched. And then the models got better again. Opus 4.5 dropped and all of a sudden everything shifted again. Technical people were suddenly able to build full apps that kind of worked.

12:26 There were people who had never coded months before, building benchmarks that they couldn't read for things they didn't understand. And devs suddenly could go even deeper. This is when a lot of us started like building games as side projects or trying to port libraries to different things or use these tools to automate some of these decompilation processes and then the models got better again.

12:46 And I would argue with Fable 5 and eventually with Astra, the jump for devs was immediately huge, but the jump for technical people was not quite as big. And I thought this might be the end to an extent that the gap from technical people who don't code to devs who will know life like all their understandings. I thought this gap was going to just keep getting bigger and bigger and bigger.

13:07 And then Opus 5.5 happened. And the thing that made Opus 5.5 so interesting to me is while it didn't really move what I was doing with AI much, like I do a lot more, but it didn't necessarily unlock a lot of new capability for me that I couldn't piece together with other things. The fact that there was one model that could do all of this stuff that was well priced and accessible on subscription tiers bumped technical people deep, deep, deep into this idea of being able to build things they don't understand.

13:36 There are now people who have never coded before. They've never opened Blender. They never done any of those things. That are using their claw subscription. They're paying 200 bucks a month for to port maps from their old favorite games into new games that they reverse engineered. That's crazy. But there's another tier of people, non-technical people.

13:52 I don't think they have been moved anywhere near as much, but that's an opportunity for the people in these other areas. If you are the person who fixed their mom's computer for a long time, you might be able to find more and more problems that your mom has with other things that AI could solve, either by showing her how to use an AI tool or building her something useful with your AI tools.

14:15 You also can start modding games in ways that you fundamentally couldn't understand in this position. And then you can share those mods with your friends. And I am sure there's a bunch of people playing the Call of Duty Halo mashup that don't understand anything about how it works. They were just sent an EXE from a friend who got it all figured out.

14:36 And these technical people can now share so many more cool things with their friends. And here is where my spiciest take comes in. So, we need to talk more about these people, the devs, cuz I have uh a harsh reality I need a lot more of y'all to wake up to. We're not very creative. And the more creative you think you are as a dev, the more likely you are to have really bad ideas.

14:59 Generally, devs are not very good at most things that aren't delivering code. That's just reality. The reason that my channel is so popular isn't cuz I'm super smart or really good at branding clickbait thumbnails. It's cuz I'm like six out of 10 at communication in a space where the average is a three. So, I'm able to talk about these things and be a lot easier to listen to than your average dev who would otherwise talk about these things.

15:27 This is why so many dev teams have a non-technical designer and product manager that don't know [ __ ] about code that are being paid 100k plus a year. It's cuz we need them because we don't have the taste or the creativity to do anything other than like link two libraries up in a novel way. We're not good at this. And here is where the spice comes in.

15:48 Technical people who can't code aren't necessarily decent at this. These are the people who got really into Zapier back in the day because they didn't know how APIs or web hooks worked. So, they would use those tools to force things to work together in ways that made no sense. I've seen some OBS setups that hurt my brain because it's just so far outside of how the program was built to work.

16:12 Like I know somebody who has over 40,000 scenes in her OBS because she uses them all as dynamic layers that link to and stack on top of each other for crazy dynamic scenes in like situations that she'll create in OBS. Like I've seen some crazy [ __ ] and that's all weird creative [ __ ] thinking and suddenly those types of people have had their like shackles taken off to an extent.

16:39 And that's what's so exciting here is what happens when those people who don't understand how this all works, who don't understand that a game made in IW4 should not work inside of the same engine as a game made in UE3 versus a game made in whatever the [ __ ] EA was cooking at the time. People who don't have that strong like fundamental belief that like these things are different, therefore they can't be combined or these things work this way because they've worked this way for 20 years.

17:10 All of this stuff is just it it's hard for us to comprehend. And I know this for a reason that is really really silly. I know devs aren't good at this because of my most popular short. Why can't we commit our environment files? It sounds stupid when I put on a slide like this, but I want you to really think about this for a second. When I have a team of engineers that are working on a project, why do I have to build another system to share this specific file, but all the other files can go and get just fine?

17:36 We have to take the step back and think, is this how we do things because it's right or is this how we do things because it's just how we've always done it? Why can't we commit our environment files? I played this short because I have learned this take is an unintentional I don't want to say IQ test. It's a like creative thinking exercise for engineers who are not good at creativity and they're often not good at thinking.

17:57 The reason I brought this up in my AI worldfare talk was because I want us as engineers to start unraveling these deep set beliefs that we have. It's time for us to take a step back and look at what we are doing and why we are doing it. And one of the best ways to do this is to have outsiders come in and be like that makes no sense. And they do things differently cuz they don't know any better.

18:21 This happens a lot in music where some random kid from some foreign country will like something they hear in another place and make their version of it. And by the time it's notable enough to be heard by people from the original culture, it's also refined enough that they can't really poke holes in the things that it does differently. We're about to hit this era with software where people who have no idea what they're doing can come in with ideas that do not make sense to us because we've been engineering for 20 plus

18:46 years and these kids don't know the difference between Java and JavaScript and they're going to make things that are really cool and surprisingly powerful because they don't know to not ask for it. And I know we're not going to be very good at this as engineers because of the comment section in all of these videos. Why can't I post a picture of my credit card to Twitter?

19:08 What kind of tech brain rot is this? The saga of the sinking Theo continues. Homies still learning soops exist. I can give you a couple reasons. Decoupling, source, and keys. Sometimes in the company, you want to see code of one another, but don't have the ability to launch it. Yet, you're you're assuming everything still works the way it works today.

19:27 The point I'm trying to make is that GitHub giving everyone access to every file into Git as an origin system sharing every file with everybody with access might not be the right way to manage our source code. Love this comment from Shiv. Oh, you want me to think? Nah, too much. I'm a software engineer, man. Yeah, I'm not paying you to think. I'm paying you to write code.

19:48 Boil the ocean, but we can't even find the ocean. Actually, Gamergirl, the reason I'm talking about this is I think devs like you are going to be very well off. There's a lot of devs who are creative weirdos that do strange [ __ ] with code that have struggled to find a job for various reasons, usually dumb. That is shifted a ton. highly motivated people with a bit of creativity and a willingness to think outside of the box and dive onto things they don't understand fully, they're going to be rewarded absurdly heavily

20:17 in this era where the the less tied you are to the way things have to work right now, the more likely you are to break out of that box a bit and come up with more unique and creative things. And when things don't work, you can ask questions and figure out why. simple way of putting this that I actually really like from chat. Yeah, here it is from chorus here.

20:39 Try first to understand why not because there's a lot of questions and things we do in software dev that are effectively just cuz the tools have worked this way forever and it would be too expensive to try and change it. Things like the compilers we use written in one language like porting it to another is just too much effort and time and risk and keeping it synced is not necessarily worth it.

20:59 or apps that were built in one language that aren't worth porting to another because it's expensive to do. Or if you have an audio device that's bugging you, like I often do, technically speaking, if I was to spend a few months to a few years, I could absolutely reverse engineer my road cer and write custom firmware for it. It would just take me a very, very, very long time.

21:18 Now, these things are much more accessible. the amount of effort and historical experience you need to try out these crazy yolo runs is so much lower. And I've done these things before AI could help me with it, where I try some crazy bold idea like building my own tech stack or trying to build my own game engine, which obviously didn't go as well as the other things I did, or trying to build my own protocol for WebRTC stun servers to make the quality of the connections better without causing any latency issues.

21:49 Like I have been trying these types of crazy yolo missions for the better part of my career. And now those explorations are much less expensive and much more accessible which means you have to be willing to go down them. But you also have to be willing to try things and have them fail. And I find a lot of devs are worse at that since devs are used to working in the things in the systems they understand even if they don't understand them fully.

22:14 They are used to failures but it's like they change five lines of code and it doesn't do what they expect. So, they go change them a few more times. It is so rare that a dev files a PR that doesn't eventually get merged that we almost feel bad. Like, who here has merged a poll request because they felt bad closing it because they know the person who made it worked really hard on it.

22:36 I know I have. Let's see some yeses and ones in chat. If you've ever guilt merged a PR, see all those? this happened because it feels bad throwing away somebody's work, but we're also just so used to the point of a PR going up being that that PR will merge. And that is just a deep culturally set thing that we have to start walking back. And let's be real here.

23:02 Let's say a professional dev who's written code for years spends 2 hours on some slop thing that is a 2,000 line of code PR and then separately a technical person who isn't a dev spends 5 hours on the same thing and makes a nearly identical PR. Who's going to feel worse when you close the PR because you don't want that in your product? The engineer who spent 2 hours on it or the technical person who spent five plus?

23:28 I think we all know the answer to this. Obviously the developer, they value their time more highly. They have expectations when they are building these things. They are used to PRs they file being merged. And if they can do a week of work in 2 hours, they're still putting up a PR that feels like that week of work. And when you don't merge it, they still feel bad the way they used to.

23:47 The technical people who haven't coded before don't have this experience, but they also just don't have the expectation either because they're not going in expecting this to work or expecting this to land. They're going in expecting this to be a fun experience really. And that difference in expectation going in has allowed these people to do crazy [ __ ] recently.

24:08 So what I'm trying to say here is we need to get over ourselves a bit as developers. We need to be a little more willing to take a step back and question things. We need to feel less bad when the thing we do doesn't work and should be thrown out. We need to ask more questions both to our agents and to ourselves about what we're building, why we're building it, and what we could potentially do differently.

24:26 We need to be a little bit more willing to boil the ocean and do these crazy things that don't really make sense. I remember just a few months ago, my YOLO project rewriting the entirety of the TypeScript compiler in Rust felt like the unoptanium of AI. Like maybe someday AI will be able to make a little bit of headway in this project. Not only was it working in under 20 hours, it is now two to three times faster than TSGO.

24:55 And most importantly for my actual reason I want it, it works in WASAM. I didn't think this project would ever be able to like realistically happen. If I was lucky, it might pass a compilation here and there. Now it works on all the real projects I care about with 99.99% accuracy against the other versions of TypeScript. And not to keep calling out chat, but raging here said that when I first started the project that they made fun of me for it so hard because they never thought it would work.

25:23 That's why I started it. I started this project as like my attempt to think of a thing AI would never be able to do. And now this feels too easy. Like yeah, of course the AI could rewrite a known target like a compiled app in a different language, but just a couple weeks ago this didn't seem possible. It's crazy how much things have changed. And I'm not even thinking bold enough.

25:47 And it's my job to think too bold so I can make videos out of it. I like this way of framing a game mechanic. I'm a software engineer as well as a systems engineer. And my hut take is that most devs are pretty happy writing the same damn linked list written by every other dev over and over again. They don't really like differentiated workloads. As a systems engineer, I'm basically annoyed writing code that's already been written before.

26:08 I think the people who can work at higher levels of abstraction and not care about the low low-level implementation are going to be the winners. I pretty much entirely agree with this. The only thing I would change is the people who are willing to be flexible with how low or high level they go, they are going to be the ones who benefit the most. The people who are willing to throw away their preferences in order to make something better for their goals are going to benefit a lot.

26:33 Like do you have any idea how many technical decisions I have had to make in projects that are not the decision I would prefer at all because they are the thing that gets me my goal the fastest. Like I really do genuinely want to switch us over to the Swift UI rewrite for the mobile app. But the speed the agents can operate at with the React Native app combined with the OTAA updates and all the pushing that Julius and Jay have done to make the performance not just comparable, but I would say in many ways faster.

27:01 I'm not going to probably ship the version that I prefer, especially on the technical level cuz I know it's more capable because the agents, the tokens, and the timer are going into a different thing. Or for a sillier example, my fleet. You might notice some of these boxes have a new OS on it. You would imagine if I was making T3os that it would be full of all my opinions.

27:23 Well, if I do end up shipping T3os, it's not going to look like what you think because it has none of my opinions in it. I didn't make this new DRO of Ubuntu because I want to have a DRO that does everything I want. I'm building this DRO because I want a DRO that has none of the things I want. It's designed to have the things the agents need instead.

27:45 T3os doesn't have a guey when you boot it. It is headless, but it will spin up gueies that are a fork of XFCE for my agents to use through the driver level with KUA control. So, they can do computer use for each individual thread. It's also using Bash instead of Zish or fish because as much as I prefer Zshell, I very much prefer Zshell. I recently audited all of the errors that my agents have and over 30% of the errors that Claude runs into across my machines are because the Zshell machines format new lines slightly

28:17 different and Claude mal formats the rip grip commands. I've also learned my agents aren't quite as good at dealing with Arch and Cachios for a dev box. And as much as I would prefer to run Cache on all my [ __ ] I've accepted it's not the best choice for a lot of work and for a lot of my boxes. So now I'm making a not really a fork of Ubuntu. It's more like a super customized Ubuntu image that is customized for the agents, not me.

28:39 And this is weird because on one hand I'm going deeper, customizing the OS, but on the other hand, I'm going shallower because I'm not making the decisions for myself and my willingness to be flexible up and down the spectrum of depth for this stuff because I'm not building the product for me is how I'd put it. Or like I'm not building T3os for me. I'm building T3os for my agents so they can build things for me.

29:03 And if we're not more willing to think about things this way as devs, not only are we going to stop benefiting from the models getting smarter, these technical folks who don't have the same boundaries in their brains are going to accelerate far past us. That person you used to get annoyed by in high school because their solution to everything was install Ubuntu even though they've never programmed before, that person's going to run laps around you if you're not careful.

29:28 And I say all of this because I was wrong. I had the silly belief that models would be putting out things that were so complex that technical people couldn't understand it and the devs would be the only ones who could. And that same knowledge that made us more capable of wielding Opus 4.5 and eventually even Fable is starting to hold us back. So what happens when this all hits the non-technical folks?

29:51 I have no idea. I'm just paid to talk about code, guys. Seriously though, like I've been thinking too much about this and I just wanted to get the ideas out of my head because these things are changing faster than I expected. We're still accelerating. And it turns out a model that can write its own compiler is useful to people who want to rewrite their old favorite games.

30:10 And I never thought a model that capable would be useful to my friends in high school. But I didn't think people would be rewriting their favorite Xbox 360 games from decompiled ports in Rust plus Bevy and then mashing them up together either. We're at the very very tip of this crazy ass iceberg and I hope that you guys are prepared for the future as it is coming cuz godamn.

30:33 It's not going to get any slower. What I'm trying to say is that I was wrong and I've been reflecting on it a lot. And I know a lot of y'all probably are thinking the same way I was just weeks ago. I hope this video convinces you to start rethinking where these models are going and who will be able to use them because I know I have been blown away with what we can do.

30:53 Every time I get a DM from an old friend from high school or somebody I used to work on random audio engineering stuff with showing me the crazy things they're building with Opus, I realize that we are very, very early still and where we are going is going to be pretty damn cool. said all I have to here. Let me know what y'all think.