Dennis Pilarinos

I'm Dennis Pilarinos. I'm the founder and CEO of Unblocked. If you want to stand up and gather around here, if that's painful for your neck, or if you want to switch around in your chair, what have you. The reason is that we're actually going to be doing a lot of demos. I'm going to say a little bit of context first, and then we're going to go into it. We're going to see this thing actually working day to day.

A little bit of background. Actually, Mel, I'll start with a little bit of context first. The intent behind the talk is really trying to cut through all the noise that exists in AI dev tools. There's a lot of noise around the hype, around what these things can do, and so on and so forth. I'm going to show you Unblocked and our theory and thesis around context engineering, how that's important. But I thought I'd start off by providing a little bit of framing for this conversation.

This is a bit of an embarrassing slide, I will admit, because I suspect a lot of you are software professionals, engineers. How many folks here work in software engineering in some capacity? Yeah, an overwhelming majority. This is going to be super obvious to you, but it's a great way to frame the conversation. It's really acknowledging that software is developed, at the very highest level, in three stages.

The first is gathering context: how does this work? Why do we do it this way? Who should I talk to? All the things that you need before you can actually get into that second stage, which is actually writing the code. This is where you're going to see tools like Cursor and Claude, any of your favorite AI generation, code generation tools. And once you've implemented that feature or fixed that bug, the next thing you do is operate the service: build, deploy, iterate.

As embarrassing as the slide is, because I'm sure it resonates with you obviously, further, it's not a left-to-right process. This is something that happens in iteration, continues to happen over and over and over. But it's a great way to think about the problem end to end. This is where Unblocked predominantly spends a lot of its time: helping you gather the context that you need before you can embark in this SDLC.

A little bit of background on myself. I've been building and running engineering teams for the better part of 20 years. I worked at Microsoft and AWS. I had a company called buddybuild, which is a CI platform for mobile app developers that was acquired by Apple, where I ran a good chunk of their developer tools developer product offering there as well.

All that to say, one of the things that, from my personal and the lived experience of our team, we've realized across all of these organizations is that as an engineer, getting the information you need is insanely inefficient. It's very, very time consuming and it's quite painful as well.

The way that people do that is one of two ways these days. The first is they interrupt their coworkers. It's tapping them on the shoulder if you're physically co-located or sending them a Slack message and looking to get information from those folks. The second, if you're very keen, is to dig through a whole bunch of the different data sources that are used as you build your software: your bug trackers, your messaging platforms, your documentation systems. People are digging through all that information, trying to get all the information that they need to understand how their system works, what are some of the assumptions that they made through the process of building these systems.

I love this small anecdote. This is from a VP of engineering of an organization that's well known for hiring top-tier engineers. He said that one of his top engineers took five days to write 12 lines of code. In today's world, if it takes you more than a few minutes to write 12 lines of code, something is obviously not right. I think most of us can probably write 12 lines of code very, very quickly. But that's if you know what code to write. That's what we're seeing here.

Now, that's all anecdotal. That's things that you probably have an instinct for; you can relate to. Let's get into some numbers. If you look at Stack Overflow's most recent developer survey, they had over 65,000 respondents. 53% of them said that they're actually slowed down waiting on answers. 63% of those folks said that they actually spent between 30 minutes to two hours a day searching for these answers. And 49% of them said they spent the same amount of time actually responding to these answers. So it's not just, oh, I think it works this way, or I think this is a problem. It's actually a problem that lots of people face.

The problem is only getting worse. AI is helping us write more code faster every single day. I actually heard this funny, insightful quote or reference, which is like, big banks have accrued more technical debt in the last six months than they have in their entire history, which I thought was interesting. Why is that? Because we have people and we have AI that's actually going and writing a bunch of code for you.

If you take a look at that process, if a person or an agent is limited to just the source code, what you get are sometimes questionable results. I'm sure we've all experienced this. However, if you extend it so it's the source code and all of the context related to that organization, you end up actually getting mind-blowing results. That is the motivation behind Unblocked.

What Unblocked does is it takes the source code as the source of truth, augments it with the data and discussions from the messages that you would have in Slack, the bugs that you would have in Jira, the documents you might have in Confluence, puts it all together, and makes it available for people and their tools to ask questions and get answers. With that, I'm going to give you a demo, which is why I'm standing in the back of the room today. Let's jump into it.

What I'm going to do is actually... oh, you won't be able to see that. Of course, one AV issue after another. Let's see if we can. Add windows, add all application windows. Yeah, now you can see it. What I'm going to do is walk you through the Unblocked product on the Unblocked source code and our system. This is a real live demo. We use the product to build the product. We're going to jump into Slack, we're going to look at the code, but it is real and working.

The first thing I'm going to do is show you our web experience. What I'm doing is asking a question that's very specific to our system. The SourceSmart engine maps questions to answers, and a general-purpose large language model would have literally no idea what it is because it knows nothing about it. It lives in our infrastructure. What Unblocked does is it provides a bang-on technical response. It actually tells you how it works, what the algorithm is. It even goes as far to actually render a diagram. This is generative. There is no document that describes, or no single document that has, this image. It's something that Unblocked is able to generate because it believes it can help us. We generate all of that full answer by taking the references that are surfaced here to generate the response.

One of the things I love to do is give you some of the insights that we've learned as we've built this product. I'll start with this one. These are the references that you can see. We've connected through a consequence of all these different data sources, so Asana, Confluence, any number of them. What I've seen in the three years that we've been building this and the tens of thousands of developers who use it every day is that the first question every engineer asks is a question they already know the answer to, 100% of the time. I would leverage my entire net worth to take that bet. I'm so certain of it. I think the reason is because they don't trust the system. They want to get a sense for: is this thing actually good? Does it actually know the answers?

What we find is that people will ask that question and click on these references as a means to dig in and figure out if it's actually doing a good job. Over time, as that person becomes acclimated with the product, they stop clicking on these references. They've built this trust relationship with the system. They believe it to be an expert now and just get the answer that they want and move on. It's an interesting human behavior to see unfold as you build products like this.

The next thing that you'll obviously want to do is suggest follow-up questions. These are actually LLM-generated follow-up questions that we've seen help people as they're trying to understand a problem. You don't necessarily know what question to ask. Almost every human interaction, if I ask you a question, you're likely going to say, you should also look at, or did you know, or heads up on. These questions help accommodate that similar human workflow, but on a one-on-one scenario.

So a little bit of how that web experience works. You'll see one of the things that it will actually ask to do here, if you read the response, is actually go and optimize a file called the SourceSmart calculator, which again, you can't see. One second, I'm going to have to keep sharing. Add windows, add all application windows. If you read that in a little bit more detail, it would say that there are some optimizations to be made in the SourceSmart calculator. As a developer, I've asked a question, I've got some response, I need to go make this change.

This is Cursor. How many folks here use Cursor or Claude Code out of curiosity? Okay, maybe a third, half-ish. What you're seeing here... I don't know if I can zoom this in for you. Yeah, you can see that a little bit better, hopefully. What I'm going to do is actually... that zoom has maybe broken things here. I'm going to launch the agent, and I'm going to ask the agent to actually optimize the source calculator, the thing that is next on my task list.

What these tools largely do is they take a look at the source code and maybe some limited context that they might have access to, and try to go and solve that problem. But at the end of the day, what they're doing is they're fancy grep machines. They look through the source code and they're looking for examples of things that resemble the problem that they're trying to solve. When they find that, they basically apply it or adapt it to solve that problem.

In the interest of time, again, I think folks probably want to get to lunch, I'm going to interrupt this. But what it actually ends up doing, the implementation that Cursor provides or Claude Code, actually regresses the performance of the SourceSmart calculator. We've actually run the experiment and seen it. It's because, again, it's only limited to the context that it has available to it.

Instead, what I'm going to do is turn on this Unblocked MCP server. Now I'm going to ask that same question. Instead of just being limited to the source code, it's now getting actually complete end-to-end visibility of every part of the SourceSmart engine: every conversation, every bug, every pull request, every document that it needs in order to make an educated guess.

Let's take a step all the way back. Imagine you hired a new engineer to the organization and said, hey, go and implement this feature, or go and fix this bug. You can't talk to anyone. You're not allowed to use Slack or look at any of the documents. Just look at the source code and go and fix it. That's pretty limiting. You're probably setting that person up for failure. If you think of that mental model, you have to give them all that context in order for them to do a good job. That's what we're doing both for people and for the tools that they use.

In this specific example, you can see that it's able now to go reference a bunch of relevant pull requests. It's able to reference documents that help it know how to go and solve that problem correctly. Makes sense so far? Yeah. Okay, great.

Let's go to another tool, which again, you won't be able to see. I will do the thing again. It's interesting having worked for Apple and knowing a lot of the people who build a lot of these features when they don't work, I know the exact faces of the people that I want to strangle. Anyway, in this case, what I'm going to do is jump into our engineering channel. I'm going to pretend that I know nothing about Unblocked. This version of Dennis has this very standard workflow.

Most organizations have a Slack channel that's ask-qa, ask-DevOps, internal-support-related channels. What do people do? They jump into that Slack channel and they just ask a question. One of the keys to building successful developer products is meeting people where they are and extending the habit loop that they've already built. In this case, Dennis, who knows nothing about Unblocked, goes and executes his standard day-to-day workflow, asks the question in the channel. What Unblocked does is recognize that it's a technical question and that it can provide a high-quality answer. When those two semantic checks are recognized or realized, Unblocked will chime in directly in the thread.

This version of Dennis gets a response typically in less than a minute. If you're geographically distributed or time-zone shifted, you're getting very, very quick responses no matter where you are. If you are part of the team that's required to support this channel, your workload gets lightened because you're getting these expert-level answers and you don't have to do anything about it. It's just chiming in and helping.

Of course, if I wanted to, as I get familiar with the product, this version of Dennis can ask that same question directly targeting the Unblocked bot, and it'll give me an answer without doing those semantic checks. What we're seeing is the progression of someone whose standard workflow doesn't have to get adjusted or changed in order to get the things that they needed, which you saw in the previous talk, in terms of how people need to be able to extend their existing workflows.

Another fun story. When we built the product, the very first year, I would say, we had this core assumption, which was: there's no such thing as a dumb question, that you can benefit from the questions that your coworkers ask. Every once in a while through our support channels, people would reach out to us and say, hey, I actually don't want my coworkers to see this question. We're like, yeah, that's no problem at all. The way you do that when you ask a question is you click this little eye icon. If you click it, it's a private question. People would be like, oh, that's exactly what I was looking for, that's amazing, and they would just go off on their merry way.

As time progressed, we realized that maybe this assumption that we had was incorrect. What we did actually was change the default behavior such that private questions were the default. When we rolled out that change, the number of questions skyrocketed. It's another interesting behavior where people want a place where they can ask questions without judgment, where they can get high-quality answers and they don't have this fear of imposter syndrome, as an example. It's been incredible to see when you can empower people who are new to the organization, or even fairly senior folks who might not necessarily remember some of the specifics for how something works. Giving them a quote-unquote safe space to ask these questions is incredibly empowering.

I'm going to show you how to do that. If you think about clients, we have a web app. We have IDE extensions. I'm going to show you how you actually do it in Slack. I'm going to ask a question here. I'm now going to conflate the two features for you. If I wanted a private way of asking questions in Slack, I can DM the Unblocked bot. What that's giving me is this place where it's not visible to everyone in a big channel.

I'm also doing something that probably is a question that would raise a lot of consternation, certainly for Pete. I'm asking a question like, what did he actually work on in March 2025? I'm doing that to demonstrate that Unblocked is able to do something remarkable: beyond just looking at the static data sources, what it's actually going to do here is hit GitHub, pull all of the pull requests, and surface a summarization of those pull requests by category. This is actually Unblocked hitting a runtime to get that information, so it's not doing document search in that capacity. Think of GitHub as that runtime.

We can take a look at any one of these things. Here's one of those pull requests, and you can see that it was back on March 3rd and what Pete went and did in that month. Here's an example of me getting some intel on Pete, and Pete not having to worry about it necessarily, all while demonstrating the scope and capabilities of what Unblocked can do.

Now I'm going to take that and extend it just a little bit. One of the things that we recognize is when you build this context layer, it's not just for being able to do things like Q&A. One of the things that I would observe, and the gentleman before us alluded to this, is I think there is unquestionably a hype cycle around the scope and impact that AI can have. But I would observe that on that spectrum there are kind of two ends to it. The first is that a lot of the workflows that we're seeing are actually human-led and AI-assisted. You have to poke the machine and get a response or get it to do something.

I think some of the most compelling scenarios are where it's AI-led and human-assisted, where the machine is recognizing when something has gone wrong and says, here's how you can actually go and fix it. We started thinking about these scenarios and how we can take this code contextualization platform and leverage that full end-to-end context to solve real problems for engineers.

If I surveyed most engineers, there are two problems that people hate doing on a day-to-day basis. One is writing tests, and I think there's a ton of tools that will do that for you right now. The second is actually debugging why your pull request actually failed. You're trying to get something landed into the code base, the build system says that it failed, and you're trying to understand why.

This is a list of all the pull requests that have recently been opened. I'll choose one. Here's one that actually failed. What you'll see is that Unblocked is actually now participating in this triage or in this process of trying to help this engineer figure out why something failed. When your CI system fails, Unblocked can notice that, actually do a root cause analysis, and provide a suggestion for how to actually go and fix it. For each one of these workflows, it's actually telling me how to go and fix this problem. This is a scenario where something bad has happened in the runtime, which happens to be our build system. Instead of me digging through endless log lines or files or what have you, I get the AI who gives me the full context of my organization to go and solve this problem.

That's just our toe in the water for things that AI can actually go and do. You can imagine integrations with things like AWS or GCP or Datadog, where you start getting visibility into some of the runtime aspects of your application. You're bringing to bear the context of your organization to say: hey, page load time has regressed, or this Kubernetes cluster has reached or exceeded its CPU utilization rate. Here are the code changes, here are the related Slack conversations, here's how you go and fix it, and it knows about you and your application.

That concludes a good chunk of the demo here. I will switch back to the slides, which thankfully you can still see. Here are many, many teams who are using Unblocked, and it's been fun to see this product grow over the years.

This is one of my favorite, actually it's an unsolicited LinkedIn post from a staff engineer. There was some interesting conversation this morning in the Slack channel around whether there is some reluctance for people to use these AI tools or adopt them within their organization. I think there's a commonly held belief that quote-unquote interns, or folks who are early-stage in their careers, find the most benefit. This is a counterexample to that. This is a staff engineer at a company that says this workflow fundamentally changed the way how I work. With Claude Code, his coding tool of choice, he found the holy grail of engineering productivity: context-aware coding. I thought that was fascinating. It feels like unlocking a whole new level of flow, which is the dream that we always aspire to, which is: I can just sit there and hammer through this stuff.

That is Unblocked and how we're bringing context to solve real problems for folks.