B (3:09)

So you kind of work more like a product owner than a programmer.

C (3:13)

Yes, yes. But then I'd say that for me it's something in the middle.

B (3:21)

So.

C (3:23)

I do look at the code. But still the AI for me is producing most of the code. For me it is that I am specifying the features by prompting using different agent tools. The agent is producing the code. I will check how it works and then also kind of a glance on a code. But I'm a really, really technical product owner. I think that's the difference. So that like if it's a pure white thing, it was that you don't have to understand anything. But for me, I think I get most of the benefits while I understand the technology. For example, if the AI first, I don't, for example, mention the technology, how to do this. But then if AI does incorrect solution, I think this is not good. I can suggest, hey, you could use this pattern and that kind of stuff. Or like, hey, let's fix this using this and this technology. And this is like a stupid implementation. And then the nice AI says yeah, brilliant idea, and then goes on. So for me it is like that. I am really using AI a lot, but I'm still kind of trying to understand the internals, what it is doing, but I'm not reading it line by line kind of thing, but more like looking at big picture that are you going in the right direction both in the feature wise and technology wise.

B (5:06)

That's a great insight because we've had a couple of guests here on this series that talk about pipe coding. Exactly. In this, don't even look at the code perspective. One was more like, we're just giving it guidance and we have a few tricks to know when it starts hallucinating. Like, for example, have a system prompt or a context file that tells it to always start the answer with a specific emoji. And then when the emoji disappears, you need to reset the context because this is very important as context is important for the AI to perform. Another one was more talking about AI coding. So vibe coding feeling a little bit more like pachinko coding, right? Like you go to the slot machine, you pull the lever and then sometimes it works, sometimes it doesn't. And now we're hearing you saying that actually it is deliberate coding, right? Like you look at the code, you look at the architectural patterns and design patterns and you'll guide it in that level. So we see that there are multiple levels of, let's call it detailed understanding. Of the output that we apply. In this context of AI assisted coding, how do you feel about these levels? Am I missing certain types of levels here or do you feel that these three kind of more or less describe vibe coding in practice?

C (6:31)

I think I agree with you. I'm reading. I know a lot of people who don't have that much even technical background and they work with the AI just doing the prototypes from small web apps and websites. And then you're right. But also I'm also sometimes jumping from a style to another in a way that when I'm working in startup I have to do back end, sometimes infrastructure work, sometimes front end, sometimes even like CSSN style stuff, which is, I know what it is, but I'm not very professional on that. So in those cases I'm like, just for example, I've shown AI some UI pictures and like, hey, can you do this as this picture shows? And then I don't understand if the CSS styles are good or anything, but like, if it looks good, I'm like, okay, I'm fine. That so, so sometimes I'm working like that, but then in the certain backend stuff, I like look more thoroughly because I understand and I think usually there are certain core architecture places where it matter, the quality matters more. More so there I like try to understand more. So I relax sometimes also more and do more.

B (8:01)

So what you're saying is that you move between different levels as you go through different tasks.

C (8:08)

Definitely, definitely. Because that's actually beauty of this stuff that especially in startup, like there's a possibility to do a lot of things or sometimes responsibility also. And we can't have special, special people for every task in a way. So then you're like, you have to do things that you don't know that well and then you have to trust AI more and I'm willing to do it and taking the risk in a way.

B (8:39)

And that's a very good point.

C (8:40)

Right.

B (8:40)

Like we need to be aware where we are taking risks even if you don't use AI. That's good advice anyway. Right? Like always be aware of where the risks are because you, you're probably going to need to pay attention to that sooner or later or establish some fallback or workarounds or whatever. When you think about your experience with AI assisted coding, Marcus, when was that first moment that you realized that, oh, this is changing. This really changes how we work with code today?

C (9:12)

I think for me there wasn't just one moment. There has been like three phases. Like about a year ago, I started using Copilot, GitHub Copilot which was a pioneer in these kind of tools back then the tool was able to predict autocomplete. For example, if I was writing a function and writing a function name and the parameters it could implement the internals of function. If it was just few lines of code, it wasn't a big thing but it was still something that I started using. And then I noticed that when I wasn't using it I was like I really missed this because back then I was using different editors for different tasks and I only had Copilot in one editor. So that was like small boost. But I still. It was something that like if it wasn't in the editor I was missing it. But it's it I think the boost wasn't that big. And then the next next step was that then I started using AI like chatbots like ChatGPT or Cloud Node Cloud nowadays which I use mostly that when I didn't know something very well like learning new things. Then I started using the tool like hey could you. I don't understand this API. And started talking with and then probably even got some snippet of code and then I pushed into the editor and started working on that. So that was another boost to my development. And again that was one thing that I couldn't live without anymore because like oh, should I just google things out? It's too slow. But then then the third step, which I think is now the biggest one was was then like it started before summer when the. This agentic coding tool started appear like the cursor and Claude code for example. Those are the. That I. I've been using most then and beginning it was pretty like I was not sure if I want to because that. That's. That's totally different paradigm that I'm not even coding myself. I actually start by prompting and then ask the agent to do all of the coding for me. In the beginning I think a few months ago they were not working that well but then it didn't took that long and then I learned to use them and then it was like totally changing the way and that's why I've been posting in this LinkedIn that what's happening here because like nowadays like I still code a bit but like I say 90% of my code is produced by these tools. And that's like if I think all of my like I've been coding since I was kid this is a huge change and the reason why I'm doing this is like I now think Always like, okay, should I code this like by hand? But then it's like, it's, I'm working in the startup and the biggest risk is that we can't produce new stuff as quick as possible. And I'm like, it's just that I can't beat AI anymore. I mean it's just like, be faster.

B (12:44)

Yeah, yeah, yeah, yeah.

C (12:45)

So it's perfect. And that's crazy, James. Like for example, I sometimes code in cafeterias and then it's actually just yesterday there was my phone, I used hotspot that wasn't working and I couldn't connect to AI service. I'm always like, what should I do? What should I do? Should I start coding by hand or coding by hand?

B (13:12)

That is an interesting statement. So I remember many years ago I read a book by a listener and a friend of the podcast, I'll put the link in the show notes, which kind of gave us the history of the change between low level coding and high level languages. So for example, going from I think it was even punch cards, punch cards to assembly to then C. I mean and for Anyone listening in 2025, C is a low level language today, but it used to be the highest level language at some point. So this is kind of an evolution. And what I was thinking when I was reading, thinking about reading that book was exactly the same type of experience that you just now described was talked about back then and about. And back then in the 60s, there was a lot of fights within the software community about what was better. Right. Like the same arguments came up. We'll all become stupid, we will not know how the computers work, all of that stuff. And what you're describing, that cafeteria moment when the hotspot doesn't work and you go like, ah, what should I do? Should I code by hand? Now that's exactly the same kind of evolution that happened to us, meaning the industry, software industry way back in the 60s when we went from low level languages to higher, not high level, higher level languages. And we're doing the same, right? Like, because even languages like Python which are super high level, are now low level compared to prompting an LLM.

C (14:47)

Yeah, yeah, you're right. There are a lot of similarities with this. And I've also seen this pattern, I've also done with very low level languages. And then I moved to object oriented functional programming and I think it all improved. I think the big challenge here is that there is a difference. Like when you're moving from low level language to higher level language, they are still deterministic I mean, it's like more for engineer brains, you can understand it, but now the LLMs, it's not deterministic anymore, and it actually changes how you have to think about. And that's actually, I know some of my friends, it's very hard to switch to this new way of doing because even though now I'm like, yeah, AI is doing the coding for me, but it fails very often and you have to move to this new paradigm where you can't predict that if you put the same prompt, it might work or it might not work, and you have to think differently. So there are similarities, but this determinism is very different.

B (16:06)

Actually, that brings me to the next question, which is really that different paradigm of thinking. Right. Like, when we talk about AI assisted coding, as you said, it's no longer a deterministic way of developing software. So what have you learned about what actually makes AI assisted coding work? Taking into account that fact that it's no longer a deterministic programming language. Right. Like English or Finnish. I don't know if you program in English or in Finnish.

C (16:37)

Yeah.

B (16:37)

So English in this case is not a fully specified and mathematizable language. Right. Like, it's very fuzzy. There's a lot of implicits and things that are not defined. So what makes AI assisted coding with language work for you?

C (16:58)

Of course, one thing is that you have to go back and start learning tricks like setting. Like for most of the tools, they support this kind of. That you can set this kind of system prompt information that always do this and this, you can give it the information. So you basically teach your tool to do things like that. I want always to have this kind of patterns and that kind of stuff, but at the same time, when you'll do it, it's, you know that in most of the cases, it actually listens to you. So you have to understand that when you're working with the AI that like, you give it some instruction, do it like this. And then at least for me, I've tried to understand how the systems work. So, for example, there is this thing that, like, when you give. Give them more and more context, basically, if you, if you talk long to AI, the context is so long that it starts to make more mistakes. I think that's, that's like by design, or at least how this, this is how they work. So you have to be mindful about that. And then for me, it means that I usually stop at some point. So. So you kind of, as an example, like, I'm trying to do some feature and it's like, it's, it's making mistakes and couldn't find them good solution. It's still bugs and that kind of stuff. So at some point I just like delete the conversation and then like scrap all the code that it did and then go back to the, for example the ChatGPT and Start, Start talking with. Hey, let's, let's think about is there any like totally new way of doing this? And then it's kind of. And with the help of that tool I get a new idea how to approach the problem and then I go back to the agent tool and start the conversation again.

B (19:02)

So you're using two different AIs. You have one AI which is actually doing the coding like cloud code or cursor and then you have another AI with which you are discussing maybe design or architectural questions.

C (19:17)

Yes, yes, that's one thing. And especially I use it if it's like a harder problem and like, and they are totally separated. So that's kind of a. Two opinions on that code.

B (19:29)

And then you are kind of like in. Not literally, but you're almost like copy pasting ideas from one to the other. Of course you're either talking or typing. You're not necessarily copy pasting, but you're kind of bringing ideas from one AI like ChatGPT or Claude or whatever into the actual coding AI to execute on that. Right. But you also said that you scrap the code and that's something that one of our interviewees, Llewellyn Falco kind of mentioned as a critical tip is that you always version control everything.

C (20:00)

Yes, that's super useful and very important that they do it in small steps. And then whenever you have something working, you use local commits with git or something because there is a challenge that sometimes AI goes into this kind of loop that it tries to fix and whatever you do it just makes more and more mesh and trying to do. And if you don't have like this checkpoint, like the tools nowadays have some kind of checkpoints themselves. But I still trust the git more and it's. For me it's more natural to do.

B (20:40)

When you say code in small tabs, I think it's small steps. Pardon me? I think it's very important for you to describe explicitly what do you mean, how small should the small steps be?

C (20:53)

Of course that depends on the feature, but something that you can put as one commit. So like I never don't, I never do this, kind of create this whole feature by one go. It's more like that I already in my mind split them into smaller pieces. Like, do this like first, for example, don't do like, do the like minimum feature without error handling. And then I started start adding, for example, error handling. Like, hey, let's handle the error cases. This like one step.

B (21:35)

What do you think? So one of the things that we used to do, you know, before AI, when we did tdd, one thing that we usually did is that we did a local commit for every test that for every test run that passed, right? Like you write the test, it doesn't pass. You write the code, it passes. You run all the tests, you do a commit. That's not what you're saying though, right? Like you're talking a bit higher level.

C (21:57)

Yes, they are larger. Like one. Like let's. If you think about lines of code, one step can be 100 lines of code. So the steps are in a way, they are not that small that they used to be in the TDD era.

B (22:12)

Okay, So I was thinking, because I've been doing some experimentation myself, writing some scripts for myself, for stuff that I do regularly. And one of the things that I noticed is that it feels very easy to go without committing until something fails. But then when it fails, it's hard to backtrack because of course you've lost the version history. So how do you make that distinction? Because even if you have in your mind this idea, okay, let's do the feature, just the happy path, right? Like no error handling, but it might fail before you finish the happy path. So how do you keep yourself accountable and make sure that you're not doing too much before creating that checkpoint or commit?

C (22:58)

I have like, I think I don't have like three rules. This is something that I've been learning. But like I have some, my own rule of thumbs. For example, if I have been iterating like five times, roughly five times, then I at least stop and start thinking that should I continue this process? Because the challenge with AI is that it is very willing to continue forever. So it doesn't stop. It's always like, if you are saying that, hey, it doesn't work, it doesn't work, it doesn't work. It always comes up with new ideas and like, like endlessly. So it's very important that you have some own rules. For me, it's something around like five loops and then I at least stop, for example, then I go to the another tool and start thinking about if this approach is did I give the correct information to AI? Or even sometimes it's like A normal like or sometimes I noticed, okay, it seems that it's very hard to do the implementation and so I scrapped the code and then like asked it, hey, could you do this kind of a refactoring that could make this easier for, to make these kind of changes in future. And then I do just the refactoring, commit it and then go back to.

B (24:19)

The thinking about this, I can't help but thinking about a rule of thumb. We always have rule of thumb, right? Like it's not exactly applied like that, but you, you tend to stick to it. And the rule of thumb I'm thinking about is that you should have a rollback commit at least every half an hour. What do you think about that? I'm not.

C (24:43)

Yeah, like yeah, yeah, you're right. Of course it depends on if you are more prototyping it. Sometimes it doesn't matter that if you work, work longer. But that's roughly, roughly something that you're in a, in a right ballpark that you should have like regular commits, like half an hour, hour, like if it's more than hour, then it's like with this kind of a coding, like, well.

B (25:06)

At least before coffee break and before lunch. Like, at least that, like don't go to lunch without the commit. And this is important because when you think about commit, and in this case we're talking literally about code commit, but when you think about commit, you also think about these checkpoints, the ability to roll back. But you also think about how to split the work, how to not try to do everything at the same time. Because and here's perhaps the thing that I think we need to talk about is this idea that actually AI assisted coding, it's still software engineering, right? There's a tool to help us do that, but it's software engineering. And when you think about software engineering, it's not just one developer, it's a whole team. And I know you've been thinking about this. So how do you think this AI assisted coding for one developer specifically will affect other aspects of teamwork, like planning, task splitting, testing, code reviews. How do you think vibe coding affects our work as agile teams?

C (26:10)

I think one, the speed changes a lot of things because with the AI, if everything goes well, you can actually produce like so much more stuff. So then if you want to get full benefits of that, then you have to have freedom for doing within a day, for example, to do more. So at least for me, it means that you have to get bigger tasks. If you had before this, you were splitting within a team that you do this small thing and then let's discuss tomorrow daily or something like that. That doesn't work anymore. You have to give more freedom to individual developers. Like, hey, there's this huge feature and this is your job to do. I mean, I'm now working in a gaming. It is more natural because this has practiced here for a long time. But I know in some other areas it's very common that for example, if you think about user story or feature, it's common that it's split that into tasks and there are multiple developers working with the small things and then you coordinate quite often. And I think that's very challenging in here because like if, and this is not deterministic, but if in the best case you can do the same feature that took like four whole team to do a week, you can do it in a one day. So you have to. It would be nice that you have a freedom to also do that. So that. Okay, let's move on.

B (28:05)

And so you're saying that maybe we split a story into tasks before and maybe these days you wouldn't do that anymore. Give a story to a person and the person does that story, whatever that is. And perhaps even implicit in what you said is that the stories can now actually be larger than what they used to be.

C (28:26)

Yes, yes, yes. And then you don't have to spend time together splitting those tasks anymore that much, because I think that's for me, it's about part of the wipe part that then when you are doing the stuff, then you learn also how to split the last pieces better by yourself with the tool.

B (28:50)

Exactly. And perhaps one metaphor is that now the AI assistant is just like pair programming, except of course, it's much faster at typing. Right. Like it's pair programming with somebody that.

A (29:05)

Types at light speed.

B (29:07)

Quite literally.

C (29:08)

Yeah, that's a good analogy.

B (29:10)

And one of the things that is really curious is that the people adopting. I know it's not your case because you did pair programming and you have some XP in your background, but a lot of people out there are now pair programming. While before AI assisted coding, they would vehemently oppose the idea of pair programming. So this idea of teaming has now completely changed because now we're not just teaming with other human beings, we're also teaming with the machine. But we accept certain teaming practices like pair programming with the machine much better than we accept teaming with other human beings as a population. Right. I know you're a pair programming enthusiast, but is that how you see it? Do you see it the Same like we're slowly accepting pair programming much more than we did before.

C (30:03)

Yeah. Yes and no. I think that now we are going into this direction that we talk about is like, like one thing that yeah I did. I've done like a lot of pair programming in the past and I think one of the reasons like where why people didn't like that you didn't want to like sit with other people. Like some people. It's psychology. And I have to say that the AI is a very different like yeah, there's similarity, it's a pair programming but it's still computer. And it's both more natural like because the for AI is more like hey, good idea, your ideas are good. And it's always like it never complains which is nice. But on the other hand like you don't have the human connection with them. So there's like, you know, like this is a pretty, we had topic in, in a way that like I, I know you have the similarity but it's still, you know, you're talking with the, or you're working with the computer which is like basically programmed to say nice things to you. And then it's like it's not just a light speed coding but it's also encouraging you all the time. And, and I know when I've been pair programming it's it's sometimes it's like not, not the case.

B (31:23)

It's like fighting sometimes. Right.

C (31:26)

But then again there's actually, it's a good point. There's one similarity that even though these tools are coding in lightspeed, it still means that when you are prompting something bigger that you have to wait like sometimes five minutes or so. And while it's doing that you have to think like do you start doom scrolling in Facebook or something or, or do you like think about the next step which is similar in pair programming. This is something that I now try to kind of. I'm like watching it doing its job, but it's happening so fast that it's hard. You can't read the code but you can read the kind of summaries. It's saying okay, I'm doing this and this. And then while it's doing you can try to start thinking what to do next kind of after that talking about.

B (32:20)

What to do next. There's two activities in software engineering that become quite different once we start coding with AI. One is quite obvious, right? Like there's no point in doing the code review because it's probably following all the, all the right practices and has the Right. Syntax and whatever because it's coded in. But the testing sounds to me it becomes a completely different activity. Right. So as developers, we are not testing our software. Obviously we're testing enough to know it's working, but we're not really testing the software. So how do you look at these two activities, code reviews and testing. When you are coding with AI, but then the overall team also needs to give their input in testing and code reviews.

C (33:05)

Yeah, let's start with the code reviews. That's also like now when we are doing this lightspeed coding, then the review can easily be. If, if every, like, if every team member like, if have like very strict code reviews for example, then, then, then if you, if you end up having like a 100 pull requests per day, so you're, you're in big trouble again. So, so in that, in there, I'd say that we have to use more AI for reviewing code, which is of course it's counterintuitive but like in a way you can have then the different AI doing the review and so on because like I think this is one of those things that this doesn't work if you do the reviews like you used to do before because then you have a bottleneck there and it's, and it's. I've noticed it's also for humans, it's very boring. So if, if you're just reviewing, reviewing, review and reviewing like it's. It doesn't work. So you have to loosen up that process. That's one thing. And then, then about testing with this new style of working, I spend more time on actual product because actually the, the I test manual like this exploratory thing a lot because most the AI is doing the coding and I actually often during that time might look at it. But I can also think about seeing the product testing our game for example, while unlike. And so I do manual testing a lot more so I learn the product better. And then for unit testing and that kind of stuff, the AI is doing that too, which is like it's actually pretty good at that. But there you should review what it's doing because it can. It's the same thing that like I remember sometimes when there's like this test coverage rules where like the test coverage has to be something like that. And then some coders just did stupid test to make true. Yes. And I have to say that unfortunately AI is very good at that too.

B (35:28)

So it tricks us as well as itself.

C (35:32)

Yeah. So for me, reviewing the test code is actually often more important than actual that you're actually testing the real test.

B (35:41)

That's a very good point. So one thing that I've learned is that I use CLAUDE code, so I have it in the project file, have the process, and the process always says, write the test first, make sure it fails, then write the implementation and then check that it passes. And this step, although it sounds like wasteful, why would you do that? And a lot of TDD detractors have said that in the past, so it wouldn't be a new thing. But if you do that, you know that the test is trying something that fails before the code is implemented. And of course you still need to look at it and so on. But most of the times it will still work out that the test actually tries to do something. It's not just quote unquote asserting true, right? Like, still pay attention to that. And then another rule of thumb that I figured out is you can always ask it at any random point. You can always ask it, hey, pick one test and change something in the output so that it fails. I'll fix that and check that it still passes, right? Like you can kind of build these checks and balances and you can even do that in your process. Like in CLAUDE code is the CLAUDE MD file. You can say, hey, every third iteration, pick a random test, change the output, check that it fails, fix it again, check that it passes, right? Like you can build this process in. And this leads us to the next question, which is we're always discovering new things. And this is just, I mean, it's September 2025 as we record this vibe. Coding is a six month old term that is, you know, spreading like wildfire, but it's still very young. Our practice with AI software engineering, that's what I will start calling it now, AI assisted Software engineering, because it's not just coding. You're right, we're kind of discovering the future here, right? Like we're pioneers where we're bumping into the walls and discovering stuff. So when you think about your experiences as you look forward and project that experience forward, what do you think are the key trends we will see in the next, say six 12 months? Maybe even that's too far. But anyway, six months, what do you think the future holds when it comes to AI assisted software engineering?

C (37:56)

At least I hope that these LLMs will get faster so that the process is like, as I said, like it would be better that if you, if you wouldn't get detracted. Like for example, if just five minutes. It's not, it's not natural, sometimes like and then you lost the flow. If you think about the coding flow that you used to have, that's. That's one of the things I miss sometimes that now and I like, like there's like a lot of waiting. So this like I really hope that the elements don't just get better, I mean in quality, but they also improve the inference speed which hopefully happens. That's not sure because it has actually the speed of that improvement is not that good anymore lately but let's see. And then I'm expecting at least that these agent tools will get more and more advanced in a way that they do more and more like trying to understand the solution and trying to test things automatically for you. So there are already some, I know some agency tools for example that they code something and then they ask you to play like test the product and they look the logs and they automatically find that oh okay. The thing that I implemented, I noticed that it's not actually working. So there will be more and more these smart features added to these tools that automate and that's definitely like a short term trend.

B (39:36)

Which tool do you think is kind of pushing the boundary lately?

C (39:43)

I mean at least I checked the latest replit which they are really trying out these new concepts at least so replit.

B (39:53)

All right, we'll put the link in the show notes for people to go and check it out. And I know it's still too early, I mean it's only six months since this whole vibe coding thing came in the scene. But is there a resource, a book, a video, a blog post, a series of blog posts that you think every AI assisted software engineer should be reading or watching?

C (40:15)

I don't really have any book or especially books. There are no books because things start changing so fast. But I really recommend people to try some Claude code or cursor to do something even small with yourself and in a way that you don't code yourself at all so that you get the experiments. I think this is something that at least even thinking about my experience for me when I first hand started to understand what it means, it was totally different than just reading like others experiences. So I really recommend you to try one of these tools.

B (41:00)

We'll put the link to some of those in the show notes we talked about cloud code, cursor and also replit. And also check out the other episodes of this series. There's a lot of experiences being shared that will hopefully help you get started or get further if you already started. Markus, we're close to the end. But before we go, where can people find out more about you, the work that you're doing doing, and also your latest startup, Bitmagic.

C (41:26)

I say like for me, the LinkedIn is the best way you can follow me there. So in another social media, I'm not that active. And then of course Bitmagic, you can go to Bitmagic AI and check it out. It's live, so you can absolutely check.

B (41:42)

It out, see what they're doing with AI assisted gaming. More on that at Bitmagic. AI Marco, it's been a pleasure. Thank you very much for your generosity with your time and your knowledge.

C (41:54)

Thanks. It was a pleasure.

A (41:59)

All right, I hope you liked this episode, but before you hit next episode, here's the deal. This podcast is powered by people like you. The members who wanted more than just inspiration. They wanted real tools and real connection to people who who are practicing Agile. Every day we're talking access to over 700 hours of agile gold, CTO level strategy talks, summit keynotes, live workshops, E courses, Deep Dive interviews, books, and if you're into no estimates, we got the pioneers of no estimates in those Deep Dive interviews as well. Agile Business Intelligence, creating product visions, coaching your product owner courses, you name it. You'll get invites to monthly live Q&As with agile pioneers and practitioners, plus a private Slack community which is free of all of that AI slop you see everywhere. And of course, without the flame wars, it's a community of practitioners that want to learn and thrive together. It's the best place to connect with community and learn together. So if this podcast has helped you before, imagine what you will get from this podcast membership. So head on over to scrummastertoolbox.org membership and join the community that's shaping the future of Agile. We have so much for you, so check out all the details@scrummastertoolbox.org membership because listening is great, it's important. But doing it together, that's next level. I'll see you in the community.

B (43:49)

Slack we really hope you liked our show. And if you did, why not rate this podcast on Stitcher or itunes, Share this podcast and let other Scrum masters know about this valuable resource for their work. Remember that sharing is caring.