In today's fast-paced world of technology, enterprises are constantly navigating new challenges in software development. The accelerated pace of innovation, the rise of generative AI, and increasingly complex workflows have driven a paradigm shift, requiring adaptive enterprise AI solutions to remain relevant.

Tsavo Knott, CEO of Pieces for Developers, recently delved into the complexities on a podcast with Matthew DeMello at Emerj, the largest B2B AI podcast with 1MM+ annual listeners. They shed light on the emerging trends and challenges that organizations face when trying to become an AI-powered enterprise.

AI in Enterprise: Understanding the Current Landscape

Enterprises are struggling to keep up with rapidly evolving technology, increasing development cycles, and the meaningful implementation of emerging AI technologies. "Technology is moving faster than ever, the amount of documentation is ballooning in size and volume," says Knott.

Add to this the dispersion of teams across various departments, and it's easy to see how complexities can quickly multiply. "The number one challenge is that everything is moving faster," Knott emphasizes in regards to adopting AI for the enterprise.

The High Turnover Dilemma

Among the most alarming trends is a high turnover rate among enterprise developers, with an average tenure of just 13 months. "Developers are particularly difficult to replace and turnover is intense," Knott notes.

Organizations are faced with the task of rapidly replacing and training new talent, leading to an overall lack of software developers. "They used to keep developers for about 30 months, and now that looks like 13 months. That means you need to onboard developers faster and get them up to speed quicker," Knott adds.

Certain enterprise AI applications like Pieces can help position enterprise development teams for better business outcomes, by accelerating onboarding processes via AI integration technologies available through Pieces Copilot.

The Workflow Challenge

As the saying goes, "time is money," and this resonates profoundly in modern enterprise settings. Workflows are becoming increasingly fast and intricate, pushing developers to adapt to broader trends. Adopting AI in the enterprise through Large Language Models (LLMs) and AI code generation tools offer some relief by speeding up the process.

However, Knott points out, "The volume of code that is being written has probably increased by a step function of two-to-three with these generative solutions." These tools also pose their own set of challenges, lacking the context for specific projects.

Balancing Individual and Enterprise Needs

Interestingly, what works for individual developers often translates into success at the enterprise level, offering organizations a unique opportunity. "The number of touchpoints for individual developers, whether with their team or with others, is going up exponentially," Knott observes. By integrating freelance workflows, enterprise AI software can streamline processes and foster a more cohesive environment.

Introducing 'Next-Generation' Tools

Understanding that these are novel problems, the solutions also need to be innovative. That’s where Pieces for Developers comes in. It offers AI enterprise software with capabilities to document materials and processes, capturing the ‘who’, ‘what’, ‘when’, ‘why’, and ‘how’ behind development. "The goal is not to replace a workflow, but more so capture, and keep up with the volume of materials that developers are interacting with," Knott says.

Additionally, Pieces has a Copilot where users can choose from a wide range of LLMs, both in the cloud, and local instances they can download and run on device. Knott discussed the capabilities of the copilot stating, “Pieces Copilot features allow users to ask questions about their code, and questions about the project, people, and code in their organization. This unlocks new levels of productivity and provides individuals and teams the ability to solve problems faster and catch up to the increased pace set by generative AI startups."

The Convergence of Design and Development

Design and development are increasingly intertwined. Tools that were traditionally for designers, like Adobe and Figma, are now also part of the developer’s arsenal. "There is so much crossover between development and design, and those iteration cycles are becoming tighter," Knott remarks. Pieces for Developers plays a pivotal role in bridging this gap, helping to transition designers into front-end developers.

Final Thoughts

In summary, development timelines are accelerating, AI-generated materials are growing exponentially, retention rates are low, and tribal knowledge is dwindling. Knott sums it up as, "I would describe it as nothing short of chaos." But with future AI tools like Pieces for Developers, there's a way to navigate through these challenges and evolve.

Want to dig deeper into these topics? Tune into the full podcast episode for more expert insights from Tsavo Knott on the changing landscape of software development, and how to become an AI-powered enterprise.

Full Transcript

Matthew 00:00

Tsavo, thank you so much for being with us on the program today.

Tsavo 00:04

Hey, what's going on? Thanks for having me, looking forward to chatting about some of this stuff.

Matthew 00:08

Absolutely. Now, in terms of developers, they're a very interesting profession, at least across industries. And there's also this aspect of what happens for individual developers that really tells us a lot about what's going on in an AI-powered enterprise in the best way for those workflows to manage themselves. Just from what you're seeing on the developer side, what do you see as the biggest challenges currently facing enterprise developers in their leadership?

Tsavo 00:41

Yeah, it's a pretty interesting question. Because I think, you know, for developers at large, it's an interesting time to be in that field, you've got a ton of stuff going on regarding generative AI, and I will talk a little bit about, you know, the blending roles between development and design. And also, we've been working in this world where you have a lot of developers working asynchronously across the globe.

And so I think that the challenges are various in nature, but the number one challenge is just that everything is moving faster, technology is moving faster than ever, even down to the amount of documentation that's getting written, it is just ballooning in size and volume.

And with the advent of AI in enterprise organizations, for developers in an enterprise or an individual setting, they're trying to cover so much more surface area these days, right. And so I think the challenge is, for every new framework update, or for every new platform that you have to ship for iOS, Android, web, you know, macOS, Linux, etc, just the ground that they have to cover is becoming extensive, if you will. And also the difficulty of the technology is going up.

So you know, things are moving faster, there's more ground to cover, there's deeper tech that has to get deployed, and the bar continues to be raised when it comes to the experiences that consumers expect.

And then on top of that, you have larger teams and teams are becoming more integrated than ever. So I would sum it up as nothing short of chaos. And I think the end result is how do developers navigate this chaos? Right? How do they kind of keep up?

Matthew 02:16

Absolutely, absolutely. And just in terms of what you were saying there, in terms of technology, layering up the entire process, adding more to the overall volume that needs to be covered, we see AI playing a big role in that not only in AI, being part of the solution, but also being part of the problem in terms of layering up that code, correct?

Tsavo 02:38

Yeah, that's right, so the volume of code that's getting written is now, you know, probably increasing by a step function of two to three with these generative solutions. And so your codebase is ballooning, as I mentioned.

I think that creates productivity in one regard, but it also creates kind of a side effect of chaos in another regard. So because it's accelerating so fast. How do you make sure that developers are keeping up with this rate, double checking things, the quality of the product stays intact, and then also going back and forth with your design team, to make sure hey, look, we're not having scope creep, or we're still on target or things like that.

So speed, being introduced into this whole process can actually be a dangerous thing. I think, yeah, you'll have gains on productivity. But if things move too fast, then that's also a little needle you have to thread.

Matthew 03:31

Absolutely. Also, in terms of AI for enterprise. I know developers, and this just comes from my background and my last job working as an AI vendor developer, are particularly difficult to replace, in terms of their skill sets, and what workflows they were working on.

And we also know that turnover is very, very intensive. I'm also wondering just about the kind of day to day labor turn over challenges in this space as well.

Tsavo 03:59

Yeah, I think that you're spot on there with your question. We've talked to a lot of VPs of Eng, and CTOs and so on, and they said their number one problem that they're experiencing regarding turnover is they used to keep developers for call it a couple of years, 30 months, now, it's really starting to look like they're keeping developers for 13. Right? A much smaller window.

So that means that you need to onboard developers faster, get them up to speed quicker and have them to that level of contribution and productivity, that doesn't really kind of slow down the ball. And so it's another interesting and nuanced problem there. Because your volume of code is going way up, that whole existing process is already moving incredibly fast. So how do you get a new developer in and up to that velocity as fast as you can?

Matthew 04:44

Absolutely. And we've covered a couple of the challenges for individual workflows. They bleed on up through macro economics within enterprise AI strategy. I think we've covered that especially in terms of turnover, and how we see a lot of tech adding layers of tech debt to the very job of development. But just concerning individual workflows, and what developers deal with day in and day out, what do you see as the biggest challenges there, regardless of industry for the individual developer?

Tsavo 05:20

Yeah, a couple of really simple examples are, you know, reading documentation. So more than ever things are getting documented, because you can also read technical documentation. Now, with generative AI that is absolutely ballooning, you have asynchronous work.

So you have code that you have to review, messages that you have to catch up on, and emails that you have to go through. And so the number of digital touch points that developers have to interact with is going up as a side effect of just these increasing workflow paces.

So for an individual, oftentimes you're left at the end of the day with 50, maybe 100, tabs open, got your IDE open, you're trying to keep up with the conversation going on in Slack. And so it's, again, nothing short of chaos. But what this represents is that work in progress journey, right?

So the atomic interactions that you're having with the sources that you're reading, the code that you're iterating on, the people that you're talking to, that's a big part of an individual developer’s hour by hour, day by day workflow. And there's a lot of volume to that.

So if you could imagine, you know, because tech is moving faster, the framework that you're using to build is updating sooner. So now you have to go, and you have to make sure you're keeping up with breaking changes, or you're keeping up with the latest tech stack, or the best practices or things like that, because everything is just moving faster now.

And I would add to that, you're getting PMs and product leaders and managers, they have an expectation that, you know, developers are moving faster, because the industry is saying, hey, look, we expect you to move faster. We introduced all this tech, we want to see our team at that velocity, or that individual hitting those benchmarks. And so developers are certainly pressed to keep up.

The last thing is jumping around, right. So open source has been a big contributor to everything that's going on, they've got their work stuff, they've got their open source stuff, maybe they're doing some side projects. So the context switching as well is pretty insane, to be honest.

Matthew 07:21

And just with what we were talking about before, with kind of the the two ends of these continental railroads coming together between design and development, that context switching, that jumping around, that you mentioned, is getting more intense than ever, because we don't really know where the ball is going to land necessarily, in terms of those workflows in design and development. But maybe we can illuminate some of our answers here.

I'm wondering, especially in that area for what we were talking about in terms of giving individual developers a greater sense, or at least having a tool that has a greater sense of what's happening outside the browser. And all the context that's important, from outside the individual program to accomplish the task, how are business leaders, especially supervisors in development teams, using data tools to solve some of these problems?

Tsavo 08:19

I think that what we're seeing is you're having a new wave of tools that are standalone that you can use as kind of a glue between things. But I think that you're also seeing a large wave of tools that are in between other tools, right, and so really trying to sit between what you're doing in the IDE, what you're doing in the browser, what you're doing in those collaborative environments to kind of be a cohesive connective layer, to get that developer’s back and capture some of that work in progress stuff.

So kind of speaking towards some of the stuff we're building. That's exactly our goal here at Pieces is to be a tool between tools, deeply utilize AI to understand hey, of all the pages that you have open in the browser, all the tabs, or all the code that you're visiting in your IDE, or all the people that you're talking to, what is relevant? What's important? What context do we need to capture, so that if you are onboarding a new teammate, you can share that context with them.

And they can pick up where you left off faster, or you can pick up where you left off faster, you know, so I might jump from one project beyond that for six months, and then jump to another project.

And a year later, I'm circling back to the original one. I'm like, where do I jump back in. And so I think the goal is not necessarily trying to replace or do any certain part of that workflow better, but more so just capture it and try and keep up with the volume of materials that people are interacting with, and just have that available for the developer.

Matthew 09:52

And just to put even a finer point on the process and what it looks like, it might help to even clarify what that receipt looks like when someone's handing off their workflow or a project. Let's say a developer leaves on their supervisor, what does that final product in terms of a record look like so that I can help train new developers to pick up right where they left off.

Tsavo 10:20

I think one of the problems that we're certainly trying to address, is that the final result today is developers will go through all of these processes either on their own or in a small team, and they'll create an output that is a code base, and it's committed, and it's deployed to customers. However, that code base that's checked in at the end of the sprint, and that final production code often lacks the nitty gritty details of how you get to that end code base, right? What sites did you visit? What decisions did you make? Who did you talk to? Where did you iterate on the designs, and so that work in progress journey is, is quite often lost.

With Pieces, for example, we're really focused on making sure we're capturing the ‘how’ a developer got there. So that when you're bringing a new developer onto the team, you can share that ‘how’, in addition to the ‘what’. The ‘what’ is very well captured. Today, it's the end code base, but how that code base came to be, right, and everything that went into it, that's what we're focused on.

So as you use Pieces, and you research in the browser and problem solve, you write code, and you refactor code in the IDE, and you collaborate with your teammates, it's just picking up on all those relevant touch points and saving along the way in kind of like a hub or a drive. And in all that context, all the materials you're interacting with are saved.

So that new developer comes in, and already they can ask the copilot, hey, how do I do this? Or who do I talk to, to solve this problem? And they don't have to create that, you know, that hub themselves, they're just going to transfer that knowledge right to their drive, and now they're picking up fluidly, where you left off.

Matthew 11:58

So it's about having that drive repository, and also being able to run the analytics on it, predictive capacities, run the LLM on it, all the features of that copilot. So the copilot is feeding from what's in the drive.

And all of that context, not just the final result, but also how they got there to help train those new team members, I just want to get a sense of the amount of control, I guess, on the admin side for that among the supervisor. In what ways can they kind of shape that training, or be able to control that context in order to, you know, get across exactly what this person was working on before they left?

Tsavo 12:43

Yeah, one thing to note that's pretty important there is we are leveraging small language models and Llama to to have all of this stuff on-device and air-gapped and secure, I think that's super important to note.

But the second thing is that, you know, if I'm a Pieces user, I can open up my company workspace for my project workspace, and I just go along with my workflow. And so I'm saving things to Pieces, I'm interacting and sharing things from Pieces to others. And I'm talking to my copilot.

So this is really starting to build up a persisted knowledge base, if you will, that represents my workflow and how I get things done, and related links, related people, related sample code, etc.

And so basically, what happens is, say I leave and I go to another project. That user is going to come in, and they're going to start with my hub, right? My Drive, it'll be transferred to them. So they might ask that copilot, hey, how do I get into this database model? Or who do I talk to, to do some pair programming with this? And that hub is already still aware of the previous user.

So it has all that knowledge that it aggregated over time. And because this is an air-gapped large language model on-device, you don't have to worry about that getting lost, or not being persisted on an account basis. So I think it's really easy for us to transfer workspaces from me and to others, and then also to create shared workspaces that are continuously getting consolidated against everything that everyone is doing. So yeah, in essence, it's just knowledge transfer through these large language AI models as you use Pieces.

Matthew 14:21

And we're seeing this on the end of design software. I've been an Adobe Creative Suite subscriber for a very long time. Now, we just had the Figma dev mode, a recent release. And in these tools, you see a lot more functionality geared towards development work.

And I'm wondering how this looks at least from the development side, this is not only impacting developers and design workflows, but how are business leaders using enterprise AI software to drive developer workflows where they crossover from design?

Tsavo 14:56

For us, we just take a look at the digital supply chain that goes into building products. And there's so much crossover between Dev and design. The iteration cycles are becoming tighter. Figma, as you mentioned, they released that dev mode. And so developers are now able to interact with designers and ask designers, hey, for this component, do you have some boilerplate code, you have a sample snippet that figma generated.

And so I think that the interaction rate between developers and designers is going to go way up. Also the code getting exchanged is going to become more fluid. Now keeping track of, hey, look, I'm I'm an independent developer, and I've already got all this stuff going on, and it's already moving very fast, you add a designer to that who's now generating snippets and sharing technical resources with you, etc., it kind of just adds to that chaos.

So Pieces for us is going to be really important to cater towards what designers need to save. And as they iterate with developers, and for developers, we're going to be really focused on bridging the gap between how designers work and developers work, and making sure those materials that transfer between those exchanges don't get lost.

I would just say, now you're throwing together two massive parts of the digital supply chain, and it's just going to create even more chaos, but also faster paced iteration. So I think the need to capture that iteration is becoming more and more prevalent, right?

Matthew 16:27

And what do you think of the ways that these tools can help designers maybe see the world a little bit more through the lens of developers, or how these tools may be used to move designers, to front end developers, in terms of their workflow?

Tsavo 16:44

I think that with the Figma dev mode, and other features and functionalities that are similar and coming down the pipeline, I don't think that it's reasonable to think you're going to throw a designer into it large code base, or that you're going to take a developer and throw them into a design environment like Figma. I think you'll see a little bit of that, but I think that designers are going to interact with small functional bits of code, you know, snippets, and they're going to stay in Figma, they're going to generate that stuff, save it, send it to someone else.

And I think that they're going to help that front end developer get a jump on the implementation. For the developer, I think that it's really a matter of referencing. By having both a visual representation of what that end implementation should look like, and a code snippet, to say, this is really where it should be along these lines, I think they're going to be saving a lot more from the designer. It’s both the visual and the technical implementation that they're expecting.

So I actually think that it will affect developers less, but it will be really interesting, because designers are going to be inherently interested in pushing developers to get that head start saying, Hey, here's a bunch of snippets, here's an existing implementation or whatnot. Developers previously would have had to ask for those things. And I think designers are going to start proactively giving those things along with the design.

Matthew 18:11

It sounds like as more of their workflows become integrated, I think there's going to be an influx of templates that are going to be built around certain design needs, that get translated into development needs, and vice versa. I think you're going to see a lot more of that in recent years.

And it's going to help to have tools that are equally built, not just for the AI-powered enterprise, but also your individual use. And freelance, actually, I think this could help us out right now. I have this tool that went all the way back to my freelance period to say this worked. When I did this crazy contract job for somebody else, maybe it'll work here. So to have that kind of agnosticism from your specific work environment, I think will be a really big advantage.

Tsavo 18:56

Yeah. And you know, just to add to that, like we mentioned earlier, developers are jumping around a lot, especially with the advent of open source. And I think you're totally right, I could be working on an open source project and have seen an implementation or a UI or some type of visual aesthetic that I really liked.

And I know when I was working on that, I saved a bunch of things to Pieces, pPieces now has that captured, it's aware, it understands the sites that I visited, how I kind of went about that process.

And then six months later, I find myself in a deja vu situation. And now I'm just looking into Pieces, and I'm saying, hey, let me quickly reference that resource versus trying to find that one website that you visited six months ago.

Pieces is just capturing the right stuff. Developer and designer processes are super cyclic. So I think saving things in anticipation that you're going to need it later, and having Pieces be aware of the context around those things that you're saving, be it as a designer or as a developer, is just super helpful to pick up where you left off.

Matthew 20:00

Absolutely. And in speaking of picking up where we left off, I always love these conversations about something we know is going to happen, these kinds of two ends of the continental railroad we've been talking about, because when that future arrives, where developers, maybe the dust settles from, from this collision between the two workflows, we're gonna have those templates already be in place that we were talking about before.

It's going to make an even more interesting conversation about how tools like this get used and where we're seeing that dust settle.

Tsavo, thank you so much for being with us on the program this week. It's been a pleasure.

Tsavo 20:36

Absolutely, hopefully people enjoy this, and it was great to riff on some of these things. It's going to be a wild world out there for sure.