Talk Overview:
This recording captures what might be the biggest shift in software engineering we’ve seen in decades: the move from hand-typing code ourselves to building it alongside machines.
Matt Squire traces the thread from 1960s MIT – where Seymour Papert believed everyone should be able to create with computers – through to 2025, where “vibe coding” is becoming genuinely viable.
But this isn’t just a “look what Claude can do” showcase. Matt digs into three crucial skills that matter more than ever: problem decomposition and system design, fluency in reading and debugging AI-generated code, and cultivating domain knowledge with proper user empathy. There’s a compelling argument here that we’re not facing the death of programming, but rather returning to something closer to its original vision – where building things matters more than memorising syntax.
The talk balances optimism with honest questions about what this means for junior engineers learning their craft, and whether curiosity alone is enough to navigate this transition. Whether you’re already knee-deep in AI-assisted development or still sceptical about the whole thing, there’s genuine substance here beyond the usual hype cycle nonsense.
Fair warning: contains strong opinions about Emacs, nostalgia for the Amiga 500, and at least one quantum computing joke.
Full Transcript
Matt Squire: [00:00:00] Thank you very much, Amul. So, yeah, I’m following a talk on quantum computing and that’s quite a big thing to follow. My talk’s not gonna be nearly as clever, but, did you hear about the guy who was having trouble with his quantum computer?
Phoned up tech support and they said, have you tried turning it off and on at the same time? There we go. So I’m here to talk about whether we are the last programmers and I guess the premise of the title here is that we are all programmers. I’m kind of curious though, can I get a show of hands?
Who here would regard themselves? As being a programmer. Okay. And of those who put your hands up, who uses AI coding tools as part of your work right now? Lots of [00:01:00] people. Now the other question, of course, the logical question because this, the other premise of the talk is well, of loads of you who aren’t programmers or don’t consider yourself to be programmers.
How many of you have been vibe coding lately? Okay. A few. Yeah, so that’s really interesting and that’s kind of why I wanted to do this talk and why I wanted to, to bring this topic to the room today. So we are in possibly the most interesting transition in the history of programming of software engineering as, as a profession, as an activity, as a cultural phenomenon.
We are in a position where for the first time, professional programmers don’t need to handcraft code a lot of the time, the truth is that we are entering this era where, we don’t need to handcraft code.
We maybe don’t need to write code at all. And there’s a question of not is that true, but of how much code do we actually need to write now, if [00:02:00] any, and what does this mean? As professional programmers, what does this mean for us? And what does it mean for us more broadly, socially? So I wanna answer that question, but I want to tell you a little bit about myself first to set the scene here.
I’m Matt. I’m a programmer. I’m a computer scientist, more or less. I put a maths enthusiast because I like mathematics, but I don’t quite have the rigor to call myself a mathematician. Smarter people, like people who talk about quantum computing probably can do that, but perhaps I can’t.
Most importantly, I’m a nerd and I’ve been programming for pretty much as long as I can remember. I’ve also been an Emacs user since 2009. How many people use Emacs? Wow, that makes me sad. Well come to Fuzzy Labs stand and you can talk to me about Emacs and I’ll tell you why you should be programming using Emacs in 2025.
I’m also, the CTO at Fuzzy Labs and we are a company that we’re basically an AI consultancy. We help people productionise AI. If you like we are kind of part of the problem. So [00:03:00] that’s also kind of context for this talk. That photo is me at an event called Oggcamp. Oggcamp is a open source conference.
This is the first one they ran 2009. Coincidentally, the year I started using Emacs. And here I am standing on the stairs queuing to get into a talk about Linux kernels or something crazy and inseparable from my laptop where I don’t know what I was doing, but I’m sure I was programming something. So that’s kind of setting the scene here.
I’ve been doing this for a very long time. I’m passionate about it. I’ve learned a lot along the way, and I’m kind of, I say that to kind of put myself in the shoes of what I think at least is a section of programmers in our industry right now who are genuinely worried, worried that AI tooling is gonna take their jobs or change their jobs in some fundamental way.
I want to at least empathize with that position. I wanna tell you a little bit about my history as well in, in terms of programming. So this was my first computer. How many people have ever seen or touched one of these? [00:04:00] Excellent. Good. So this is a Sinclair ZX Spectrum. The 128K there refers to the memory.
That’s 128 kilobytes of memory. So this presentation for context could not nearly fit on that machine. For the younger people in the audience, you may not know what this thing on the left here is that that’s called a tape drive. And, some of you know about tapes because you’ve used them.
Like me, I was probably the last generations who actually used tape. You have programs on that tape, and that’s how you would load software into this machine. Okay, so that’s pretty cool.
And it looks kind of like this. You turn the thing on. This is the menu you get, you get a basic interpreter. You get a calculator and you get a loader where you can load programs from the tape or to the tape.
So far so good. Now, when I got this, it was already out of date, so I was probably 12, 11, 12, that kind of age. I just turned 40 this year, so you can do the maths on that. But this was out of date when I got it. It was a [00:05:00] family hand down from someone else. And it came with a manual. And the manual is a beautiful thing.
I still have it. It’s a little bit battered, I’m afraid. I used to carry this round with me on family holidays genuinely. And it tells you how to program it. It contains all of the information you need to program in basic and any of these other things. It tells you how the machine works internally. It may even have some schematics, I don’t quite remember.
But the idea is that if you want to write a program and you don’t know how to do that, well, you can type it in. You can literally type line by line. Your reward in this case is this, so this is a program called Breakout. It’s a game and you have to knock the little bricks off using your little boat.
Fair enough. That’s pretty cool, right? Well, it’s cool enough for a machine that was built in 1987 . Well, I soon, soon enough, I managed to get an upgrade on this. So this is my favorite computer ever. Even in 2025. This is the Amiga 500. How many people know the Amiga 500 . So [00:06:00] this was an enormous upgrade. Interestingly, this machine was built roughly the same time period as the ZX Spectrum. It was well ahead of its time. And again, we got it second hand. It was a hand down in my family.
But this became my entire life, to be honest. It was a revelation. It had a floppy disc drive. Isn’t that exciting. No more tapes. So yeah, I mean this, as I say, it was well ahead of its time, right? So this is what the desktop looks like. You’ve got multitasking. You’ve got preemptive multitasking, which was very new at the time.
You have the ability to load different software from floppy discs. It was really popular with graphics and video editing, believe it or not. And it came with a version of Emacs, which is kind of fun. You could program it and basic it once again, but a little bit more sophisticated, you can do a lot more with it, more power, more options, more tooling.
And again, it came with a manual. So again, I studied this manual. I got the magazines by the way, the magazines, for people who this is completely alien to, they were magazines and in them you had source code and it was basically like GitHub. But instead you had to go to the news agent and buy the [00:07:00] magazine.
And, and if you wanna do a pull request, it doesn’t work anyway. So yeah, that’s how that works. But again, I was, like I said, completely obsessed with learning how to program this thing and learning how all this stuff works. I showed you a screenshot of breakout earlier. There was a much better version of breakout called Arkanoid, which you got on the Amiga.
You’ve got on the Atari, a few other platforms at the time, this was an amazing game. I spent ages playing this, but I spent even longer trying to program my own version and say, why would you do that because it already exists, but that’s not the point right? The point is to learn how this stuff works and it’s just following your curiosity.
I spent a very long time writing my own basic version of this. And, learning along the way. The code was not good by any stretch of the imagination.
I don’t have it anymore, and thank goodness for that. I wouldn’t put it on my GitHub. I certainly wouldn’t propose anyone uses it for like, you know, GitHub if they’re applying for job applications, things like that. But that was that. [00:08:00] And I kind of, you know, asked myself recently, well, if I spent all that time trying to build my own version of this, what would that look like in 2025?
So I went to my friend Claude. And I said, can you make me an Arkanoid game in Python? And believe it or not, two minutes later we have it. So that’s kind of sobering. You could say, okay, well do you know what? It’s actually a really basic game. It’s pretty easy to write. The code for this is probably in the training set for Claude anyway, so it’s not that impressive.
And it doesn’t tell us anything about the future of programming, right, because it doesn’t do anything that anybody actually needs, unless what you need is this game. And if you do well, it already exists. So you could make that argument and say, this doesn’t really tell us very much.
So let me show you another example of something that has been vibe coded, completely vibe coded. So in Fuzzy Labs we have, a problem. Good problems to have, but one of the problems is that we have a bunch of different marketing [00:09:00] channels and we have different people who follow us on those marketing channels.
And we want to be able to unify them. We wanna understand if someone’s following us on LinkedIn, is it the same person who’s coming to our MLOps meetups? Is it the same person who’s subscribed to our newsletter? So we couldn’t find anything that solved this problem in exactly the way we needed to solve it.
And what happened was our CEO Tom stood at the back in, the yellow and pink, by the way. So I just give you a little bit of context. Tom is technical. He can definitely program. He’s very capable, but he didn’t want to. He is a very busy man, lots of things to do. So Tom built this entirely using vibe coding.
Not a single line of code was written, so that’s interesting, right? This is a real application that solves a real business problem that we have. We have the domain expert who knows the problem inside out. Who was able to build an application that he needed, that we needed as a business without writing any code.[00:10:00]
And this is in production. This is live. We use this every day, every week. And something else, a little bit more lighthearted, hook-a-ducks. So actually, if you come to our stand a little bit later, you can play this game. This was vibe coded by Rhiannon, our marketing manager.
And okay, we could have got something off the shelf, but we wouldn’t have been able to customise it and make it look Fuzzy ish and these kinds of things. So again, relatively straightforward game, but someone is able to just build that by prompting a LLM without really needing to write any code.
And this is what I mean, right? This is the key question, right? And I framed this in a negative way deliberately. And the reason for that is that I wanna reflect what I see as a bit of a negative mindset in the industry at the moment.
At least if I go by what people post on LinkedIn, which maybe I shouldn’t, but you know, it’s that kind of, well, if anyone can build software, it’s not special anymore, is it? So why do it? [00:11:00] Why bother is programming dead at this point? That’s the question I feel a lot of people are asking, and I don’t feel like it’s the right question.
I feel like it’s unnecessarily negative, but nevertheless, that is a bit of the sentiment. What I’d like to argue over the next 20 ish minutes is that actually we are in possibly the most exciting period of time in software engineering that there’s been, but also that this idea that anybody can build software is not a new idea in the history of computer science.
And it is not something that we should be fearful of or negative about. If anything, it’s a good thing that we should celebrate and embrace. So with that in mind, I would like to take you on a history lesson. In fact, most of this talk is a history lesson you’ve probably noticed. So I’m gonna quiz people on their knowledge of computer science history.
I dunno how well this is gonna go, but we’ll give it a try. Does anybody by any chance know who the man on the left is? No. Okay. [00:12:00] Seymour Papert was a South African born mathematician. He had not one, but two PhDs in mathematics. Considerably smarter. I would venture than all of us in this room.
But thankfully we get to benefit from his mind and his brain. He became co-director of the MIT AI lab in 1967 when not only was computing relatively new, but AI was definitely new. Incidentally, the history of AI goes all the way back to the early 1950s with the work of people like Alan Turing.
It’s not as new as we think, but anyway what Seymour Papert was really passionate about was education. And particularly he was interested in understanding how this, for him new thing of programming could be used to transform education in the classroom. How could it be used to change how we teach children?
So he had a theory called constructionist learning. Actually, it wasn’t entirely his theory, it’s based on the work of the psychologist Piaget. [00:13:00] But fundamentally, he’s asking the question, how do children use technology to learn? And he had a few principles here. So he’s observed that learning happens best when children are able to make things and share them with their colleagues.
Programming for Papert is the thing that allows those children to very easily build things. So that’s kind of interesting. It’s empowering. Programming is enabling people to create things. It’s not seen as an obscure skill that you need to spend years and years of your life building up and then hoarding.
It’s actually something for everybody, and that’s gonna be a common theme here, debugging he sees as a way of teaching. But basically intellectual rigor. It’s about teaching children how to think about thinking, frankly, teaches anyone how to think about thinking. Certainly not just children. The overall concept here is that people learn best when they can build things that they personally care about.
Well, that kind of resonates with me if I think back to my early [00:14:00] history with programming of I just wanted to build Arkenoid. I wanted to build my own version ‘cause I just cared about it and I can’t say why. I just wanted to do it. So it’s that kind of idea, that kind of thinking. This book, if you really want to delve into the history here, there’s a book which, uh, Papert wrote called Mindstorms.
By the way, the Lego thing is named after that. So this is, some of you have probably played with something like this at some point during school. It’s a bit inconsistent in terms of how this is delivered in the curriculum, but this is called Turtle. It’s a robot that can draw patterns. So the idea is it can move back and forth.
It can turn around, it has a pen that can go down and up and you can program it to draw pictures and patterns and things like that. This is a very early version, but even nowadays in British schools, at least sometimes variations of this are being used to teach programming at a very early age. And I’d be interested afterwards actually, if anyone has any anecdotes about that.
I’m interested about the, the experiences there. So On the left we have Cynthia Solomon, actually just, just LA left there and Seymour Papert again on the right with his robot and his little fish that he’s clearly very [00:15:00] proud of. So Cynthia Solomon and Seymour Papert worked together. They collaborated heavily on a programming language called logo.
Logo is the language that you use to program. The robot logo is designed to teach children how to program. It could be used to teach anyone how to program. It fundamentally exists to teach the basic concepts of programming, the basic reasoning and logic to anybody who, who really wants to learn. And here we have an example, so very, very old picture, very grainy, but we have um, the little robot being used and the little teddy bear there.
How does it work? Well, I don’t really have time to go into the deep details of Logo in terms of the specifics, but the idea is it’s very, very simple. So We have very simple commands, very simple verbs that tell you how to tell the robot what to do.
For instance, if we wanna draw a square, how you read this is you say, in order to draw a square, you repeat four times, you move forward a hundred steps, rotate 90 degrees, and then you finish. Right? Fair enough. Seems straightforward enough. I’m not suggesting by the way, that we should all [00:16:00] switch to programming logo.
I’m using this as an illustration for. A way of thinking about programming that exists in the very early history of computer science that I think we’ve since lost. We’ve lost touch with this idea that everybody should be able to, not necessarily program, but should be able to create things using computers, and if programming is the means of doing that or if something else is, the means of doing that doesn’t particularly matter.
The point is that we can use computers to create things and learn while we do so. And I love this quote from Papert. So he says, a programming language is like a natural human language in that it favors certain metaphors, images, and ways of thinking. So that’s how he’s thinking about programming at that time in the 1960s.
So he sees programming as being for everybody. The language should support human creativity. And he even criticised languages like Basic and Fortran and things like that at the time because he didn’t feel that they had that same idea of being able [00:17:00] to uh, give everybody that creative capacity that he felt that there should be.
Now, uh, the other person here is Alan Kay. I should have made that a quiz, but there’ll be a few more quiz coming. Don’t worry. Um, Alan Kay, just really briefly, um, kind of built on a lot of the ideas of Papert, but he invented a language called Smalltalk. How many people have ever programmed or seen Smalltalk?
I’ve never had the pleasure of programming Smalltalk myself. It’s one of the first object oriented programming languages. Not the first, but one of the first. And it developed a lot of the early concepts. Alan Kay shared the same philosophy that really programming should be a way for people to express thought and express their creativity and build things.
And that was the philosophy he built into Smalltalk. Again, I’m not suggesting we should all go and program Smalltalk, but it’s just interesting. To think about the history of this and how the ideas developed, but then how we’ve kind of moved away from these ideas. And I think if you look at some software ecosystems now, particularly I look at, I dunno, the, the JavaScript ecosystem, even the Python ecosystem that I spend a lot of time in, the [00:18:00] complexity now is huge.
The amount of stuff you need to know to build software successfully is enormous. Whereas this, this idea of, well, anyone should just be able to create things that, that seems to be a little bit lost. And you can see the, the kind of joined up thinking between Alan and, and Seymour here. So he said, I, he visited Seymour Papert and he observed children doing real programming with especially designed language and environment, and that encounter hit him with what the destiny of personal computing was really going to be.
It seemed for a long time like that, destiny had not been realised. I would argue that we are about to realise that destiny with the advent of AI assisted programming. And so I’ve got roughly 12 minutes. I’d like to answer the question of how we adapt, or at least I’d like to begin to answer that question.
I’d like to try to give something about how we should adapt to this new reality, because this conversation is going to continue. This is definitely not the end. It is really [00:19:00] just the beginning of that conversation, but I’ve got three thoughts here. The first is to focus on. Problem decomposition and system design.
The facts of the matter is that building software, like actually building software in production at scale, making it secure, making it satisfy all of the edge cases and different user requirements that come up is a lot more than just programming, is a lot more than just writing code. So if the typing code bit can be automated, there’s a lot more space for us to focus on what’s really, really hard, which is;
how do I take a complex problem and break it down into simple parts? How do I do that? A lot of software development is that really. How do I interpret requirements? We are never gonna get away from that. And actually, if anything, what we’re gonna find is that the, there’s kind of almost a, there’s a bit of a joke I guess in the software development community
typical stereotypical project manager who isn’t able to express requirements and the programmer who’s [00:20:00] stereotypically pedantic about the requirements. What we’re gonna find, I think, is we’re gonna end up meeting in the middle because we’re actually still gonna need to be specific about our requirements.
And anyone who’s tried vibe coding themselves will have realised this when they’re prompting that if you are not really, really specific about what you want, then Claude is gonna do something and it may or may not be what you originally intended, but it’s gonna be something. So it’s almost speeding up that feedback loop.
Now in the picture here, anyone wants to venture a guess? The lady in the middle.
Grace Hopper? Yes indeed. Grace Hopper was um, fantastic at abstraction. So Grace Hopper, among other things, invented the COBOL programming language. COBOL was designed to be a kind of natural language way of programming. It was designed to allow business specialists to write software without knowing things about, I don’t know, pointers and memory allocation and that sort of thing.
She invented one of the first compilers in order to make COBOL work. So she’s really good at thinking about abstraction, thinking about taking a complex [00:21:00] problem and breaking it down into sub-problems and layers of abstraction where complexity, different levels of complexity exist at different levels.
That’s really important. That allows us to turn what is at the time, writing assembly code or Fortran into being able to write as what almost looks like English and have it execute. Also she’s famous for talking about lengths of wire. If anyone’s not seen it, just search YouTube later.
For um, Grace Hopper, lengths of wire, just trust me on this. So she explains how, um, the latencies of information transmission work with a very intuitive example, again, demonstrating how good she was at abstraction. Okay, well the next thought is building fluency in reading, debugging, and evaluating code.
Because if a lot of the code we used is going to be written by an AI, you know, either we are, we’re going for vibe coding and we’re just telling it to by a prompt to generate us some code or we are maybe not quite going that [00:22:00] extreme, but we are, um, using an assistant to help us write the code as we go.
Either way, we need to be reading a lot of code that’s generated, not just by our colleagues, but by AI. We need to be able to interpret it. We need to be able to debug it, we need to be able to evaluate it. Now, debugging is particularly interesting. Um, I think it was, um, I’m gonna say Brian Ingham might have got that wrong, but.
I think it’s Brian Kernighan and one of the inventors of C said that debugging code is always twice as difficult as writing it. So you should never write the cleverest code. You can possibly write because you’re not clever enough to debug it. That logic applies here, right? We, we kind of, we need to be good at debugging stuff.
We need to be good at interpreting what the AI generates. If we don’t understand what the AI generates, we’ve got no hope that, let’s be honest. Um, this picture is Edsger Dijkstra. Edsger famously didn’t like computers. He was a computer scientist who didn’t really like to use computers. He said that computer science has as much to do with computers as microscopes have to do with biology, or telescopes have to do with astronomy, but you know, he also, felt that debugging was particularly [00:23:00] important skill to develop. And the last one is about cultivating domain knowledge and building user empathy. And this is a mixture of technical skills, but also business knowledge, expertise in a particular domain and our ability to just understand other people, and particularly the people who are going to use the software that we build.
So again, there’s a lot more room for this if we are no longer concerned with typing code into a machine. There’s a lot more room to think about this. There’s a lot more room for using AI to ideate about these things too. But the idea here is really understanding the problem that you’re trying to solve through the software that you are building.
Really understanding those requirements, really understanding how the users are going to interact with and experience the software that we’re building. That’s crucial. And you know, The picture here happens to be. The [00:24:00] very first spreadsheet, believe it or not which was VisiCalc. So, you know, it is interesting to think about how something as simple as the invention of the spreadsheet transformed how people used computers to solve certain problems.
You can’t imagine using computers without the existence of spreadsheets right now. Right? As soon as you see a spreadsheet shaped problem, you immediately recognise it and jump into one. But that had to be invented. Someone had to think about this was a particular user experience that needed to exist and they had to build it.
And VisiCalc is long dead, but the concept is still there. It remains, it survives. So that’s three thoughts on things we can think about to change how we, what we emphasize and what we focus on as software engineers, as professionals in this new world. So I think as I said at the beginning, right now is the best time to be a programmer.
And there’s a few reasons for this. Firstly, that we are entering an [00:25:00] age where in principle, anybody can build software. Anybody can create software. And sure, granted, it may not be the case that the non-technical person can create and productionise something, at least not yet, and probably not for a while.
But someone can express an idea through software in a way that they could never hope to do before, and that’s really exciting. If anything, it probably means more work for us software engineers because we have lots of people who have ideas that they can now prototype that will gain funding and need to go to production.
That’s good news, but also because the feedback loop is so much faster, the tools we have allow us to build things rapidly, iterate on them and gather feedback, gather um, like a real, real world experience of what that software’s gonna do, of what a particular thing is gonna look like in a way that we just couldn’t before.
So it’s that kind of [00:26:00] the speed of experimentation, I suppose, is what I’m getting to, right? It’s the speed of experimentation that we are gaining now that we never had before, and the ability to collaborate with a wider set of stakeholders. You know, if, I can build something and give someone the ability to sketch out a variation on what I’ve built, even if they’re not particularly technical, and then I can take that and build on that and we can go back and forth.
That’s exciting. But the final point is to that point about education, because that’s one of the concerns that when I’ve spoken to people, has been expressed the most strongly, particularly when I’ve spoken to engineers early in their career, they’ve said, what will the impact of AI assisted coding be on my ability as a junior engineer to learn and hone and improve my craft?
That’s a hard question to answer because it almost looks like, really cynically. Maybe you can’t. Right, and there’s, there’s almost these cynical takes you see on LinkedIn of we’re [00:27:00] only gonna have senior engineers, and at some point that’s gonna be a problem because none of the junior engineers will have gone through the learning journey they needed to go through to be a senior.
I don’t think it’s necessarily that gloomy though. The reason is that I think back to myself again, learning to program I think that if I were that again, 11, 12-year-old boy stood in front of probably not an Amiga 500 in 2025, but stood in front of something else.
And I had access to these tools, would I still try to build Arkanoid? Well, I think I would, and I don’t think it would be a question any more than it was ever a question of, well, Arkenoid already exists. I have it on floppy disc. Why would I write my own? There’s never, never a question. And the reason is curiosity.
So the most successful engineers that I’ve ever seen in my career have something in common. It’s curiosity. It’s a need to learn. It’s a need to know, I couldn’t have [00:28:00] not built my own Arkenoid and it doesn’t matter that it was bad code ‘cause I was 12, for goodness sake. It doesn’t matter. It’s about the learning, it’s about the curiosity, it’s about following that curiosity.
I would definitely, I think, use the tools to help me learn more quickly. I could go to ChatGPT and say, here’s my basic interpretation of Arkenoid what do you think? And maybe ChatGPT could have given me some helpful hints, and maybe I would’ve been an even better programmer at the start of my career as a result, because I’ve learned from this massive wealth of knowledge that’s available to me.
And so just to conclude, one little ironic twist of history. Um, I mentioned that Seymour Papert was in the, uh, MIT AI lab, 1967. The other co-founder was a man named, marvin, the name has dropped outta my head. Mar , freeze when you’re on stage.
Um, Marvin Minsky, right. So Marvin Minsky, one of the things Marvin Minsky’s famous for is, um, his work on the perceptron, um, which was one of the very early manifestations [00:29:00] of neural networks, or rather neurons, artificial neurons. Uh, he wrote a book called Perceptrons, in which he demonstrated a number of fundamental limitations of the neural networks at the time.
And that book led to a massive drop off in funding for AI research. It started what was called the first AI winter. So, you know, the kind of, um, you start out along this story arc, you get to a collaboration that paused at least AI research for a good few years before it picked up again. In any case, I, um, would like to say thank you for listening.
Um, I think we’ve got a little bit of time for questions as well, but also you can come and meet me and the Fuzzy Labs team back in the vendor area there. We’ve got a table. You can play Vibe Coded Hook-a-Duck. See if you can break it. That might be fun. But also you can win prizes, so maybe just do that.
You can learn more about us at our website. We also have a newsletter. And I can’t not say we are hiring because we do believe that there is still a [00:30:00] need for programmers in 2025. So if you wanna talk to me about that as well, let me know.
Thank you.
