AI and the Collision of Tech and Non-Tech Minded People

Welcome back to another episode of the Not Brothers podcast. Today we're going to talk about something we've experienced a lot and I'm sure other people have and we're referring to it as the great collide of business units and specifically the technical folks versus the non-technical folks in today's world. And a big part of that, as no surprise, is spurred by AI and the fact that we have a lot of people who...

have historically not been able to, you know, you're less technically savvy folks who haven't been able to build things or express their ideas in the ways that they can today, now that they have AI at their fingertips and they're bringing those things. But the interesting thing about that from a technical perspective is it brings with it a ton of things, not the least of which are security concerns, a bunch of fucking messes to clean up.

and other things. So we've experienced this. have a lot of, I'll say, wisdom to share, maybe a fun story or two, but wanted to talk about that. So where do we want to start, Mark? You know I have opinions.

Hmm. I know you have lots and lots of opinions. I think from my perspective, coming from the other end, Ryan's the hyper technical person. I'm the technical person that usually plays bridge between clients or other non-technical people of what Ryan's actually saying and, and, and what the business side is actually trying to get out of a situation. And so from my, from my lens, it's actually an interesting moment because

You can look at these non-technical people and you said it well, of not having the ability to express their ideas in a way that a technical person was willing, capable, or able to really pick up and move without a lot of extra work. And now we can get to a place where you can create some sort of version, call it an artifact, call it a version 0.1, call it something of like, hey, this is what I'm thinking about doing. In a lot of ways, it's incredibly powerful.

It's incredibly powerful, especially when we're talking about green pastures, areas where you don't already have something committed. You don't have a lot of code debt or idea debt that you have or are building on or around. It's incredibly powerful there. Where it gets tricky, and I think where you have very strong opinions, is in areas where you already have some sort of infrastructure or some sort of product development or some sort of

Code base to maintain and when someone produces something really new and cool. You're like, this is awesome Now I have to figure out how this puzzle piece that didn't exist before fits into a puzzle that was already complete and What other puzzle puzzle pieces do I need to rejigger? To make it work and that's where the collision really happens because on the business end you have people that are saying things like or feeling things like Well, I just put all this work and thought into this thing. Why isn't this progressing into the actual product release?

Because it's really, really important that it gets done. And on the other end, you have opinions.

I think there's also this challenge of what done is.

starting with something that's even smaller where.

all of what you just said is true, right? The AI gives you these sort of superpowers, or least the illusion of superpowers to some degree. And you have people who can take an idea of something that's in your head. You can create something that you can interact with. And to a larger degree, for the most part, like 70 % of it, I think, is fantastic. I think that's...

that has changed how we can interact with people on our team, right? Rather than them trying to articulate what they're talking about, they can go effectively build the experience that they're talking about and show it to me. And then we can do something with that. So it's changed even from a development perspective, right? As we're building products and websites and landing pages and things for our clients.

Rather than going through this arduous wireframing designing process, we've kind of just merged all of that together now and sort of have a prototyping step where the design and the architecting of all that is all kind of just one, which has been a positive for everybody because it gets us to the interactive state faster. And it also allows us to make decisions on things that would have just been skipped or not thought about or

Um, you just run out of time. Um, so that's been

We run out of time and if you do those steps in isolation, what you end up doing is forgetting about things over time, right? So you did this in wire framing and you made decisions and then you did this in prototyping or in design, you made decisions and you did this in prototyping and made decisions. And so you compress all those things into a shorter decision-making window. And now the end product is better. The decisions are tighter. They're remembered.

And that prototype then makes it over to the final product in a more cohesive way than it used to. that's, you're right, that's one of the fantastic benefits of this. And most of that can be done by a very non-technical person, a designer, a user experience expert. Someone like that can get to the place where those things that used to take a month can now take a week, maybe two.

Yep. And I think the I was trying to look up and see if I could find who it was from. Terry talks about it all the time, right? This is introduced and exacerbated another problem that has already existed and is well researched, which is that people in general equate the progress of a project.

with the UI. It's the progress of the UI and what they can interact with. It's why on some projects, we could have UI, and I'll hold that shit back. Because I know if I show you the UI, you think it's done. And there's nothing underneath of it. We just built the easy pretty part, the shell. There's nothing supporting this. But people are clamoring because they're like, well, you showed me the thing like s-

a week ago, why isn't this done now and shipped? Like, why do I have to wait on it? And I'm like, well, because we've got to build all the other fucking pieces. So we'll just hold off on that. But that's the part that AI is good at. So it allows someone like you to build something, to build a whole UI that you can interact with, and you can move things around and enter data and do stuff and feel like there's a full application there.

And in reality, it's just a house of cards. It hasn't built any of the underlying infrastructure. It's storing things just in local storage. It's using a lot of smoke and mirrors to give the illusion of an application. then we've had some of those where someone's like, hey, can you just deploy this? Fuck, no, I can't deploy that. A, I don't trust whatever that is. And B, it lacks infrastructure. As soon as you do deploy it,

what it does on your computer, it's not going to do in the cloud world because it's doing all of that locally. So we've had to figure out how do you bridge that gap in a way that doesn't make everybody feel disparaged, I guess is maybe the word, where it's like, man, I just put all this work into this. Was that just wasted? it's like, no, it solved a lot of problems and it answered a lot of questions.

But we can't not do the other part too, if we want this thing to turn into something real. We can't not audit the thousands of lines of code that it created or in my case, pretty much rip it out of React, right? the AI is always gonna build some React supported fucking garbage and like, cool, that's neat. First thing we're gonna do if we're gonna actually keep it is move it out of React because I don't wanna support that shit.

I feel targeted.

You should. But you know, the so the collision factor, right? There's that one. That's the first sort of like baby collision is like, why are you telling me it's not done or it's not good enough or it doesn't work? And there's no magic answer to that. In some cases, it's like, well, there's no underlying architecture to it. So, you know, there's nothing backing this. In other cases.

Well, well, well, well,

maybe there is something, right? You were banging around with one of our agents one time and I was like, why does this server keep restarting? And I dug and it was like, hey, it looks like Mark's trying to set up a Python server. I was like, what the fuck are you doing? I don't know. I just told it I needed multiple people to be able to interact and that's what it decided to do. was stop doing that.

But like the end of it was now we've got this like sort of pseudo application using some sort of Python backed thing using a SQL lite data, but like it was atrocious. We can't, we can't do that because it, especially when we're talking about things that you want to do, like if you just want to spend something up to generate an artifact and play with something or, or use it for a very small utility and then it goes away and you never use it again.

Fine, do whatever the hell you want, I don't care. But some of these graduate. And that's the interesting thing that we've seen is like with some tools that have been built by non-technical people, we've kind of looked at and been like, that's interesting. If we actually polish that, that is something that can graduate to either an internal tool that we can use and derive benefit from on an ongoing basis or even to tools that we use to interact with.

clients or even tools that we might put in the marketplace and sell. But again, those all require kind of a heavy amount of due diligence. And I think the challenge that needs solving for is, and really the solve for it is just like communication and trust, right? From a communication perspective, we need to find a good language to communicate the challenges. And from a trust factor, we just kind of have to trust that everybody has the best interest at heart.

because it's not necessarily the case that I just want to throw away your work and redo it myself. Not a big fan of redoing work if I don't have to. But I am responsible for making sure that like anything that we create, anything that we maintain, anything that could provide an entry point into our walls has to be maintainable, has to be secure, has to follow.

standards that we follow. And that's just something that we're not, it's not possible to enforce currently with ROKIN.

Talk about some of the things that we've experienced over time and some safeguards that we've put in place, not just for the technical people to use workflows and for certain best practices and whatnot, but also for others like me, like others on the team that are semi-technical that can do some pieces and parts, but need bumpers in the bowling alley, right? So talk about some of those things that we've learned over time that others would probably benefit from.

Yeah. So I think that, you know, there's probably a lot, right? We've, we've, I think what we figured out is.

you're definitely not going to hold back the wave of progress, right? As much as you might want to, in some cases, speaking to some of the people who are probably in IT, who would probably just love to be able to take these fucking tools away from people. Life finds a way, right? So you could ban them from the company and people will still use them. So.

better to figure out how to allow people to use them responsibly and.

provide some safeguards, and that's what we've chosen to do. Our team has embraced AI for a lot of things. We have some things that we don't use it for. And we have the ways that we have taught our team to use AI and all that sort of stuff. But we've also found that when creating things like artifacts, it'll just go fucking wild, and it'll create who knows what. So we've started to craft our own sets of rules for agents.md files and other.

documentation that we can give for different types of projects so that we can sort of corral the agents into the way that we like to do things. For basic boilerplate websites, we will use Astro so we have a whole boilerplate project with that that comes pre-baked with your agents.md and a bunch of documents and kind of dos and don'ts for how we

architect sites, and the same is true of Rails app. So, you if we build an application, it's always gonna be in Ruby on Rails. And we have similar skills baked and agents, MDs, and those sorts of things that we're just making available to not just the technical people on the team, but making available to everybody within the team. And then from an agent perspective, we have, you know, our central agent, Sheldon, we...

allow people to interact with. And Sheldon is pre-baked with the same sort of instructions. He has like, if you interact with something or if you build something, it's always a consistent way. It's always published a consistent way. It always goes to an internal server. And that has really helped to kind of cut down on the amount of craziness that's being produced. And that's a, I mean, we're talking, we produced like 150 years.

200 artifacts in like 30 days. So, and most of them were like pretty good, right? Like they look consistent, they feel consistent, they follow at least relatively good standards that I could probably convert into something that I would be okay maintaining longer term if the idea is same.

So let's talk about the collision pieces. So we've experienced this really in the last even 30 days of some of these things where, yeah, so we have existing applications. So you have underlying infrastructure, underlying code base, underlying puzzle pieces that already exist. And then you have other people, technical people and not technical people that are working on app improvements or working on new feature sets or working on

I experienced it in the last week.

ways to optimize user experience or anything else as part of that, to talk about the flows that we've taken those things through and some of the challenges that we've encountered along the way and what we're actively doing to try to solve those because there's not really a one-size-fits-all solution.

Yeah, I think the.

to

I think in this area, you start to see multiple collisions happen. So we have a few products we're working on that are currently internal facing. They'll be external in the not so distant future, some of them in the very not so distant future.

As people have interacted with those, they will find things that either a feature they want to change or a bug or something, and they'll submit that to their fizzy board. And we have that hooked up to where agents can pull from that. But also we have some folks that they know how to use Cloud Code. They have experience with that. They know how to run the Rails app locally because it's made super easy to do that.

So they'll play around with stuff and play with ideas and I encourage that. You start to run into a few challenges though. One is.

When you're building a solution into a system, especially a system that you intend to potentially make commercially available, the product design aspect of it can sometimes get missed and get skipped. And the vision for where the product is going and what should be in or out can be missed because someone's like, well, I need this feature. You're like, you've created a solution that's too narrow.

So now we have this instance of one that's not useful to anybody but you. And there probably was a solution that allowed you to get what you need, but also potentially make it useful for other people. A big one that I'm thinking of was in Cortex when we built the custom fields. We had a couple of clients that we needed to be able to capture some custom data on their work items specifically.

And they're like, hey, can we just add these fields? That's what we did in our old system. And we're like, no. That doesn't make any sense. Which was a bit of a confrontation, right? And it wasn't no, because I don't want to solve your problem. It was no, because that doesn't make any fucking sense. What really made sense is we added a feature to be able to create custom field sets and apply those to any projects in the system.

Now you can solve your problem, but also other people can solve their problems that are completely different. And it now fits every other type of client that we may have in the future. So we have a client that we're on-boarding right now that has the idea of markets. And we could have that as a field associated with the work that we're working on with them. And that's something that's completely different than a university that doesn't have.

you know this idea of markets and they don't really care about classifying things that way. So you have like the whole product design aspect. That's your like first collision is like should this feature exist in the first place even though you want it and does it fit with the product vision and where it's going.

When in from a business lens and from a user lens, what gets missed sometimes, especially as you have that collision is the ability for you to map out what you think is the right solution while skipping that product.

requirements documentation step in the first place, right? So because I have the ability to just go bang around in Claude code with a code base and that's on a branch and I can just kind of play around and see what happens and how it works and it's working. I got this to work. It's actually doing what it needs to do. You can skip that first step and we were actively experiencing this with different things where

Yes, you're right, that works, but is it the best solution possible to accomplish the business objective that was not well documented in the first place? So it's like skipping that requirements documentation step that can get us in trouble on the non-technical resource side in particular, because now you're handing this thing over to a technical user and you're saying, hey, please implement this thing, works,

And that technical person is looking at the entire puzzle board and saying, yeah, you're right. It works, but you added 12 puzzle pieces for something that might've only taken one. If we had gone about this slightly differently.

know, I mean, I've articulated this a few ways, but my favorite one, thus far has been, you know, the realization that like AI, AI is stupid. And it will do what you tell it to do. And that can be to its detriment, right? AI will, will bore a fucking hole through a concrete wall with a spoon. If you ask it to.

And it won't say, hey man, why don't we run a fucking drill? It'd be so much faster and so much easier. And that's that planning process, right? Sometimes, like, we can just go bang around into it and probably wind up at the destination, leaving, you know, a whole trail of dust and decay behind us.

and lot of broken spoons.

I lot of broken spoons. But if we just make a plan and we're like, you know what, we actually have to go through this concrete wall, we're going to need a drill and a drill bit. And just go through and then think about what's in that wall. Are we about to drill through a fiber optic cable? I always see the videos of people when they accidentally dig up

or

fiber optic bundles and you're like, well that just ruined someone's life. This is thousands of fucking cables that are the size of a human hair. But you know,

Hahaha

That's a challenge, right? think that the more that people can follow that, the other thing becomes a handoff, right? When you're on the other end of that, I've experienced this multiple times when you crack open a pull request from somebody and you're like, there's 20,000 lines of code here.

how the fuck am I supposed to review this? I can't review 20,000 lines of code. Like not actually, not in any amount of time that makes logical sense. But there also becomes another challenge of like, what are we trying to do? So there are, you know, the lack of understanding of what the intent was becomes this whole other challenge because it's like, I do see things that exist here and I...

do not think they should exist, but maybe they absolutely should. And I just don't understand the context or the intention or the need that was behind them because we skipped sort of the planning step and just started building and building and building and building.

It's defining that success criteria on the upfront in the same way that we would for our clients, right? It's easy to skip that step for internal project work because you can just go bang around. And sometimes that's important and meaningful. Is this even possible? Should I even put any of the effort into some of this requirements gathering? Let's go bang around for a little bit and see if I can do it. But then if it becomes possible, you almost have to stop, like stop yourself, take two steps backwards and say, all right.

Sure.

Now we need to go through this requirements step. you and our other technical folks internally have done a good job of helping build frameworks and skills for our Sheldon, our master AI, to be able to help prompt through things like product requirement documentation. If you tell Sheldon, hey, it's time for us to go through PRDs, and here's the artifact we're going to go through PRDs for, they'll step you through this really in-depth process to come up with

you know, six to eight markdown files in the end that kind of define what it is we're trying to do and why that's meaningful. And, and that becomes a success criteria that you on the other technical end can deploy your agents on to look at that 20,000 lines of code to say, is this accomplishing the technical objectives in a meaningful way as part of this documentation loop? And that's a, it's an easy way to pass the sniff test that yes, we should now at a human level engage further.

versus to your point, having the human look at 20,000 lines of code with minimal success criteria to gauge whether this is good or bad and say like, how do I untangle this without making my life in a month from now a nightmare? Because we deployed feature sets that are duplicative as an example.

I think it's also important to think about the thing that we've talked about with an RTM that's been really successful is breaking things down into bite-sized chunks. It feels good to create this massive pull request, but it becomes... And look, you have people out here touting that you should be creating 35,000 lines of code a day and all this stuff. No, you shouldn't. Nobody.

Nobody who's actually creating things and cares about being responsible for it long term is saying that. It's usually a bunch of fucking hustle porn bros that don't actually produce anything. Yeah.

Nothing sustainable anyway.

especially because lines of code is a terrible fucking measure of anything. just that it gives a relative size to a thing. But I think breaking that down into smaller chunks, like bite-sized chunks, also helps because it's a lot easier to review the functionality of something when it's five pieces that are this big that it is when it's this one conglomerate. And it's so intertwined that you can't.

You can't unravel it, which sometimes means like shipping a little bit slower, shipping incrementally, doing some experimentation and shipping just kind of experiment and like, hey, I played with this. What do you think about this? Where it's like, well, we're not going to merge this because it's only partially done. But conceptually, we're on the right track and we can sort of like comb through review, put a pin in that and kind of say like this stuff is good. We feel good about this. We're happy with it and we can keep building on top of it.

And I think that's how you do get to a point where you have something that's big. think there's also sort of probably a last step that often gets skipped when building anything, which is like this compression phase. I think about like, we're in this phase right now. I mean, we do it with all the things we do, but like we're in this phase heavily right now with the MRT4 rewrite that I'm working on heavily with DHH.

know, where Amartya 4 basically re-engineers the entirety of Amartya. It gets rid of a ton of dependencies. By and large, it looks the same, right? Like when you go from 3.8 to 4, the screen blinks, and that's pretty much all you notice. But there's a whole lot of shit that's gone into that screen blinking. And...

The, there was a, as we've implemented all of that, you see just kind of this growth and this addition of a bunch of stuff. And now we're in kind of this compression phase where it's like you're looking at this giant block of stuff that we've done, it's all relatively good, and figuring out how much of this can we compress? And what can we get rid of? And what is extra? And what is crept in here or lingered in here or could be consolidated in that,

that compression phase, like it's going to take a while for us to do that, but it's the responsible thing to do because in the end it gives us something that's much more maintainable. It's much smaller. It's much more thoughtful, right? So like one of the one of the pieces I spent a couple hours the other night doing was just taking every color in the entire system. And it all comes from one file now. And it's you know that gets littered through.

dozens of widgets and pieces and parts and whatever. But what that means is you can change one variable and say, I want all the borders to be blue and be confident that every border in that whole fucking thing will be blue. And you don't have to go chase it down in a hundred different places. So it provides a layer of consistency for that, you know, because we are extracting those things and removing potential for brittleness in the future. I think that's important. I think it's important for...

any sort of application in that case, that becomes like the operating system that we're using day to day. So I for damn sure want that to be stable. But any other application that we're also using needs to have that level of stability, need to get rid of that, that brittleness and taking the time to sort of like compress your own pull request before passing it off is important. And I think that like when coming from a

you know, a non-technical, like in this case, right, if you have a non-technical person for creating sort of a pull request that's going to be reviewed by a technical team, I think they're probably like the three things that have to happen, right? One, you have to have a plan going into it. You need to be able to articulate your plan, right? This is the old show your work sort of thing, which is annoying as it was as a kid, and it's important sometimes. you know, be willing to show your work and have a plan going into it.

keep your work as tight as possible. So don't just go creating a bunch of stuff. Don't add on a bunch of stuff. Like keep your work tight. And then when you are passing that stuff off, know, do your team a favor and, you know, give them that plan. Give them videos and information about like how does this thing work? How should it work? Because those are all things that will help expedite sort of that.

that pull request review process.

You're giving an example as we were talking, I think yesterday even about how on the Amarchi project, you have hundreds of contributors to the Amarchi project. And one of the requirements with any sort of, of pull requests is that you have video and or screenshot and or descriptive things associated with it so that whoever's reviewing it, even from the upfront, like three minutes looking at it, I can understand what it's trying to do without having to read.

and try to dissect a code base or download the code base and then deploy it and figure out what's changed and all those different things. That's a very small, what seems like a subtle detail. But I think even in our own processes, I think that's something that's probably missing in some of our internal team members, especially the non-technical team members that are contributing to some of these things. Like, how do I make this as easy as possible for the person catching the ball on the other end to understand what the intent is?

so that I can get what I want is really sort of the lesson here and here.

This is a fun one. I gotta go answer the door because otherwise I'm gonna have to stab somebody.

Can we hit stop? No, we'll just come back.

30.

Ahem.

Alright, well, let me just clip that part out.

Yup, 31 minutes.

had delivery that they just kept knocking on the door. I'm like, fucking leave it at the front door.

What were we talking about?

talking about, oh, I was talking about the Amarchi project and how in the Amarchi project you were talking about ways to get what you want. The easiest way to get your pull requests understood is by having great documentation, preferably video of how the thing's supposed to function so you don't actually have to download it on the technical end to actually figure out what changed and what the functionality is supposed to look like. Just give a quick video, photos.

Descriptions be as descriptive as possible and if you do those things you'll likely have a better chance of getting what you want If you don't do those things, you can chase it down

Yeah, I mean, those are those are those are always my favorite, right? We've had that with I mean that project, but also with internal products that we have where somebody pushes up a pull request, I pull it down and what it does for me is not what it was intended to do either because of some incompatibility or a migration problem or or just me misunderstanding, you know, based on the title, what it's supposed to be.

So I pull it down, I go test something, I'm like, this isn't working at all. And they're like, well, it's because it's over here. Oh, I didn't know that. See, my favorite things are when they come with like, here's the problem I was trying to solve. Here's a quick demo of me solving that problem and how it should work. And then here's the code, and it's a nice neat little.

Yeah.

small thing not touching anything it shouldn't be touching. Those are the ones that sometimes I can just look at and be like, yeah, looks good merge.

And then you have other ones that look like spaghetti.

120 files, 17,000 lines of code. Yeah, those are.

Little harder to dissect what that's about with, especially without video, without descriptors, without real documentation that supports success criteria. Like this is a real example that we are actively dealing with and, and not for, for lack of intent or lack of effort or lack of trying it's, it's seeking to solve a real problem within one of our applications. It's adding a full blown feature set that we've been using an artifact to solve some of the problems and.

You know, it's a not it's a it's a technical technically inclined person doing the work, but skipping a couple of steps that we're talking about here in the process, potentially of of the requirements documentation phases and how the hand off loop needs to happen and.

while the feature works the way that it's intended, now we're in a place where it's like, well, I'm not necessarily willing, and I'm speaking on behalf of Ryan here, I'm not willing to say yes to this because I'm not sure, without doing three days of work, exactly how this is gonna impact everything else. And so I now have to decide, do I kick this back and potentially piss off this person?

Yeah.

and feel like their time is wasted or is there a different way that we can approach this? do I make sure that this is not something that happens in the future while also rewarding progress and making sure that the work is recognized as valuable?

Yep. It's, I mean, it's a challenge, right? And it's, it's a challenge that open source has seen as well, the, the ghosty project and kind of what they have dealt with is one that I've also followed along with. it kind of sort of articulates a similar problem where, you know, ghosty is a big open source project, but it's a small team that manages that. Mitchell has been pretty transparent about some of the challenges they faced and not the least of which is the

the AIification of everything has presented a situation where like, Ghosty, think mostly is written in like Zig and know, languages that I don't fucking deal with. It deals with things like OpenGL and again, stuff that I just don't, I don't have any expertise in that. But if I have a problem with it, like some bug, I can just tell Claude like, Hey, I got this bug.

And it'll come up with some reason that that bug's happening and be like, do you want me to file a pull request? And there's so many people doing that. And what you get on the other end is you get this like really well thought out detailed looking thing that tells you exactly what the problem is, exactly where the problem is, exactly what the solution is, what the code, the only problem is the solutions most of the time.

are completely fucking irrelevant, in some case, make it worse. I've had some that I've seen again on a Marchie where they're like solving some Nvidia problem. And their solution for the Nvidia problem was to explicitly set variables to the default values. You literally did nothing. You took values and set them to the same values they already were and then claimed success.

The real thing that you did is you restarted your goddamn computer. That was the solution. The solution was reboot. But there again, we're faced with a pull request that we have to review and you want to give time to people and there becomes this challenge of how much time did you actually put into this? If all you did, like in that case scenario, if all you did was say you spent some tokens.

You didn't spend your own time diagnosing and digging into this and trying to understand it. Whatever. I don't fuck close it. Like no harm, no foul. And this has been the same thing that like, you know, Mitchell has talked about. It's like I.

If you're trying to do something and you're just not hitting the ball, I will work with you forever to help you get that ball across the, like to help you hit the ball and figure out whatever the miss is and whatever challenges are there or whatever.

But if you're not trying and you're just swinging at it with AI.

Well, I'm not gonna spend any time. I'll just have my AI agent review it and decline it. So he's taken a harder line than I have thus far, or even considered, which is like only taking code from trusted sources at this point. they won't, the ghosty project doesn't take pull requests from, I can't remember if it doesn't take pull requests or if you can basically get blackballed or both.

But they're basically kind of like a vouching system. Like you kind of have to be vouched for in order to have a pull request considered because they were just getting inundated with absolute garbage. Just pull request after pull request after pull request after pull request. And this is the same, I use that as an example, right? Like how did we get from like companies and working with people to an open source project, right? It's the same thing.

It's the same thing happening with a different set of people because the reactions are the same, right? The gut reaction is almost like, you know what? We just need to tell them to stop doing this. Right? We need to tell people to stop, to stop trying to do this. And like, I don't think that's the answer. I don't, I would like to think that there's a better way to solve the problem and a little bit of education and responsibility on both parties. It's hard to control that and you know,

an open source project where like you're trying to get the world to comply. But within our company, I think we can get our world to comply. And what that affords us is like there's an interaction that I saw a couple of weeks ago where one of the project managers on our team submitted a bug and Sheldon popped in and said, hey, I got some questions about that bug. And she answered the questions. And he was like, do you want me to see if I can fix it?

She said sure.

And he fucking did. He submitted a pull request. Somebody on our technical team, Jake, reviewed it and merged it. And with zero interaction with a development person at all, other than just the review at the end, a bug, I don't remember, it wasn't a substantial crazy bug, but it was a bug nonetheless. A bug was solved entirely using interactions in a fizzy card.

by somebody who's never written a line of code in their life and just was experiencing a problem. So they were able to sort of self-solve that problem that maybe would have just sat in the backlog for a while and not gotten solved. So I don't want to lose that. I don't want to lose the ability to just progress things along, because also the questions were important. The original bug report.

wouldn't have been solvable. Because what happened is the agent kind of deployed it, looked into it, asked some more questions, and through that back and forth, got to the root of the real bug. And there's always that back and forth that has to happen. But it was able to do it over the course of a much tighter course versus having to go back and forth between humans, checking their notifications, and having a conversation, and spending it up, and doing all that sort of stuff.

Even that feedback loop has been a tremendous change for how we've managed some of these work requests or bug requests or any of those things, right? Where you've taught Sheldon or other agents to ask questions, to essentially play human version 1.0 of Q &A of, right, cool, here are some basic questions about the thing you're trying to solve. And sometimes he's a little bit...

Aggressive and he'll keep asking questions and you've taught him to like, man, like tone it down. You don't need every question under the sun answered, but you do need some basic items. Yeah. But that.

Or sometimes you just tell him to shut the fuck up. He'll pop into a conversation and be like, hey, just inserting my two cents here. I'm like, you fuck off and stop talking.

Yeah, you go away. You're just listening. But he'll he's done a really, really good job of making sure that things that would otherwise have sat in a backlog forever, at least have more context into what you're trying to solve. And in this case, it was able to self progress and self progress into a to a point where it was it was could become part of a release super fast, probably within a day. In other cases.

You have things that go back and forth and it's like, okay, well, this is actually a really big feature request. And so we can move it along and now we need to go through a formal PRD process and it identifies those things along the way. And so it's like, how do you, you started the conversation by saying, avoiding the collisions between technical and non-technical people in an AI driven world is probably not possible. What is possible is improving the communication loops and, and we've, we've actively sought to improve those communication loops without

penalizing the people that can feel like they're being slapped on the wrist for doing something quote unquote wrong as part of participating in this new AI world when really it's kind of a, it's a communication structure dynamic that needs to evolve, not necessarily the person's abilities that need to evolve. And so how do we continue to put those parameters in place so that

in our version of interacting with fizzy cards and our Sheldon asked the right questions on the upfront, where how do you encourage people to go through a PRD process as part of an artifact creation? So you've gotten to the end of this artifact creation, you're like, awesome, I think I've banged around and it does what I want it to do. Now I need to take it back through a PRD process so that we can get real clarification of what's actually important so that when you get to a place where, to your point, you have some real architecture behind it,

and some real structure behind it that it all actually makes sense, whether it's a greenfield project or whether it's an existing project that you're adding feature sets to.

I think the last thing that, because we keep talking about this forever, but I think the last thing that's probably worth talking about is the challenge in avoiding, in my opinion, it should be avoided.

the temptation to clean up other people's messes and also the temptation to just sort of expect that somebody is going to clean up your messes, right? We've had some of these clashes internally as well where somebody, they create something and what comes back is a whole bunch of feedback. And you're like, well, why didn't you just fix it? I didn't build this thing. You're responsible and should be responsible for your work and that

means the continuation of that work. It is very tempting on occasion to just be like, well, I see what they were doing. I'll just fix all this stuff up. And when you do that, what you find is you wind up doing everybody else's work and not yours. So now you've just created more work for yourself. But also it takes you're basically taking like all of the fun and interesting parts away.

This is a challenge, I think, in the development world right now, where there's a lot of pieces being extracted from that, a lot of the thought process and the architecture and the design and those sorts of things. And in some cases, in some organizations, they're just basically like, all right, and you guys just review it and make sure we're not going to get, we're not creating any problems here. Well, that takes all of the fun parts away and leaves me with just like, I'm just reviewing all of this.

this slop that all of you have slopped together and I'm responsible for somehow making this work. And I think that is also like that can present a challenge like just from a personnel perspective. I think that, you know, if if that's what we're in a future world expecting people to do like you will just burn people out so quickly and you'll lose all good talent.

basically, because nobody wants to sit around and just review every like clean up everybody's messes and on the other thing, and I think it has to be like, you have to know, like, if you're going into this, it's your job to carry it across the finish line, you don't get to carry it up to the finish line and be like, there's a bunch of other stuff here that needs to be done. And I don't really feel like doing it, because it's tedious and going to take time. Not my fucking brow.

I think there's a difference between kicking something back because you're expecting somebody to carry it across the finish line and that person not knowing what to do to carry it across the finish line, which is a different collision that... Yeah.

Yeah, those are different. When we're about figuring out how to take the forecast feature that you architected and be like, make that in this application. I don't really have a language to use to explain to you how to do that. And you don't really have the understanding to be able to do that. So that becomes something that is

You have given a representation of how does this function and sort of what's the idea. That's good enough for us to kind of take that and build that piece. It would sort of be like the opposite if you were like, here's this thing. I'm like, well, it's missing these pieces. Like, what do we do? We need to figure out like how to handle multi-layered clients or how does invoicing fit into this and how does all these other pieces.

those are all experiential, those are all things that maybe just like were forgotten about in the consideration. Those would be things that I would push back and I would say like, all right, you go figure that out and then bring it back.

And that's a new paradigm too, right? mean, for non-technical people, the paradigm used to be, in a short six months ago, that you had an idea and maybe you were smart enough to write down how that idea works and maybe you were smart enough to maybe do some loose wire frames of how that thing might work. And then it was up to a technical person to take it and progress it in its entirety into something that was interactive and functional and whatever.

And then the new paradigm is almost the opposite. It empowers technical people to say, hey, actually, you have the ability to take this 50 % further than you used to. And so I'm not being mean and kicking this back. I'm empowering you to take it further so that you can actually get more of what you want, and we don't miss. I mean, you can.

You know, that is interesting. I, I, I've felt this and I hadn't, hadn't really thought about it until just now, but I mean, you're right. think the equation has kind of flipped on its head to an extent because historically, you know, you would sketch something on a piece of paper. We would hand that to a technical team to build. They would build it. Give it back to you. You would tell them things you want to change. They would go make those changes and you would kind of like, that's the cycle that you would go through.

And what we're talking about here is kind of the opposite. Or I'm like, I don't want your sketch. Go build a prototype. And then you build a prototype. And then I look at the prototype as a technical person and say, we're missing this. We haven't considered this. What does this do? How does this feature work? And I'm giving you feedback to go fix your fucking prototype. And it's like it's going the exact opposite direction now. And there are times that I've felt

internally, that the like, it's like people don't know what to do with that, where they submit something and then they're getting like a bunch of critique and feedback and request for revisions from the other end that they're so like, usually, there was a one way street the opposite direction. And then it'll just kind of like stall for like, there's a hitch in the step there, where they're like,

100%.

Okay, did you guys make those revisions? like, we made it, we make those revisions. I told you to make those revisions. It's not your job.

It's very different feedback loop. I mean, I will say there are definitely people internally that have struggled with that. I think we're getting through it, but it's been a, you know, five, six ish months of just interesting paradigm shifts. And so you have non-technical people that are used to just being the idea people and they can be the idea people. that's, they were used to getting a team of people to be able to help them progress their idea from start to finish.

Mm-hmm.

And now we're asking people to say, like, hey, you're the idea person. That's awesome. Take this to an 80 % complete thing. You don't have to take it all the way to the end and you're going to need feedback along the way. And that's completely fine. But get it to a point where you would feel good about it and then involve other people and then get that feedback. And by the way, after you get to the 80%, we're also going to ask you to take it to the 90%. And so that additional 10 % is something you were never, ever involved with before.

And now it's your job. And we've heard conflicting feedback on that. Some people feel very empowered by the ability to do that. I feel very empowered by the ability to do that. And there are others who felt like they're sort of siloed or put into a silo and expected to just do things on their own that they may not know how to do. And so this, it's like this self exploration of, what am I capable of and what am I not? And am I comfortable in this ambiguity or?

or is this making me really uncomfortable and this doesn't feel like my job? And there's this interesting dynamic that's been happening across things.

There's there's there's definitely like a personality type that jives really well with where everything is aligned now. I the other one is like I said my last thing was going to last one, but it's not the, you know, writing. Right. If you're if you're good at articulating ideas through writing, you know, whether you write it all yourself or not, like is I think becomes important. You know, we.

There are different types of people that exist and who like to communicate ideas differently. And one of the funnier interactions that we've had lately is someone who's like, hey, I have an idea for something. And we're like, cool. Submit a feature request for it or whatever. We're asking you to write it down. And they're like, well, can we just meet and I'll just show it to you? And I'm like,

Listen, man, the person who's going to take the first swing at this is going to be an agent. So either you write down what's in your head and articulate it in your words, or you show me and I write that down. At end of the day, somebody's writing this shit down because we have to, we're going to feed that in so that the agent has the context that we're, the agent that we're using to help produce the future is has the context of what we're trying to do.

And that has become like a little bit of a comical and like foreign concept to some folks. But I think that like, if you're somebody who is good at like having ideas, articulating your ideas well in a written format, if you're diligent enough to do that, and then, know, submitting that across the line, I think you'll be more successful than folks who are kind of used to.

sort of having ideas, being very like meeting driven, meeting heavy, not really as documented, not really as...

as good at just articulating in written words what they're trying to convey, I think you'll be a lot more successful.

Yeah, 100%.

Alright, that was a pretty good parting words of wisdom.

Yeah, write shit down.

Right, so.

Till next time.

next time.