Greg Pstrucha on Practical AI - Episode 3

Introduction

[00:00:00] Jakob Heuser: What's up, everybody? Welcome to The Task at Hand. I'm Jakob Heuser, CTO, co-founder at Taskless, and The Task at Hand is the podcast where we talk with the builders and makers and things that they put out into the world. My guest today spends his days making AI agents trustworthy enough to touch production, and in his off hours, he's proving how easy it is to weaponize the same skills that we hand those agents. Greg Pstrucha is on Sentry's AI ML team. He founded Subroutine before that, and lately he's been both sounding the alarm on agent skill security, and he's building the fix. Greg, welcome to The Task at Hand

[00:00:35] Greg Pstrucha: Happy to be here. Thank you

[00:00:37]

Greg's Background

[00:00:37] Jakob Heuser: Yeah, I appreciate you making the time for this. So I took some time before today's podcast interview to take a look at your LinkedIn profile, and AI/ML is definitely not where you started, Greg. you were at Perf and doing DX work at Facebook and Robinhood, and now you are deep into AI/ML with your work at Sentry. Talk to me a little bit about that journey because that's, that's a really, that's just a really cool

[00:01:05] Greg Pstrucha: Yeah, absolutely. I mean, the AI/ML sort of thing, a lot of people went into that as agents started growing and as, agenting en-engineering sort of became the next thing that everybody's interested in, and it becomes a developer experience. So anyone who is interested in developer experience sort of eventually lands, like, finds their way towards generally agentic stuff, or agentic-related stuff.

[00:01:29] at Facebook, I started as an iOS engineer, like first year, two years was iOS. I mostly worked on the infrastructure side of things, so I worked on, optimizing memory usage and optimizing the, startup performance time. so like what-- how long does it take from you to tap a Facebook icon to get to, like, usable feed is basically what we called around.

[00:01:49] From there, from there, I jumped aro-around Facebook for, through a couple of, of teams. I worked on infrastructure. I worked on VR, for a short period of time, where I then met my future co-founder of, of a company I founded in 2022.

[00:02:04] but around 2019, I think I started working at Robinhood, where I ran, API platform team, which was a DX-focused team working, generally speaking, around the API service, of, of, of Robinhood, making sure that it's easy for people to contribute to the API service, it's easy to build new features on top of our existing backend and so forth.

[00:02:25] and in 2022, I stepped away, started working on my own company. started in gaming. We were trying to build gaming marketplaces. Moved away to AI when around early 2023, AI became a thing, started gaining popularity, and we just sort of digged into that, tried different things, tried accessibility work for state and local governments, tried building these like app builders when that was a popular thing, but eventually we ended up, going both to Sentry in 2020, like in ear-early 2026, at the beginning of the year.

[00:03:01] Jakob Heuser: Okay. Yeah, you, you basically were at the sort of bleeding edge then as all these technologies were coming out, which means there was a ton of prototyping, a ton of ideas that, they looked really good when everybody talked about them, and then they just didn't have a lot of merit

[00:03:17] Greg Pstrucha: We've built first app builder around like early 2023 when not even GPT-4 was a thing. It was GPT 3.5 Pro or Turbo, I don't remember the nomenclature there. and it was bad. It did not have capabilities. We didn't-- We entirely ig-ignored the UI part. We basically tried to make it craft like simple Slack bot applications.

[00:03:41] it worked fine. we knew that the models are coming and are gonna make it better, but we didn't really double down on that

[00:03:46] Jakob Heuser: Okay. So I mean, when you, when you say that also, you're talking about a lot of the ideas like around structured data and things like that, those concepts. Tool usage didn't even exist at, at the 3.5 layer yet. We didn't have... I heard someone describe it as AI didn't have thumbs yet

[00:04:03] Greg Pstrucha: Br- that's, that's, that's a good, that's a good analogy. I think at this point, four was maybe close to release and it already had, a level of tool calling and you could ask it to give you a JSON, but the JSON wasn't structured. It wasn't guaranteed to be structured. It wasn't guaranteed to be JSON. We had our own library that was trying to fix a JSON, and maybe it succeeded, maybe not.

[00:04:25] So there was a lot of like back and forth on this kind of stuff, a lot of like linting of the responses that we did deterministically, which like funnily enough, I think is still important today for different reasons. but, yeah, that's very different realm back then and not a lot of transferability of techniques and methodology, to, to current sort of era

[00:04:45] Jakob Heuser: Yeah, so what was kind of your aha moment then? I mean, you were all the way along as like this can be something. At what point did you, did you go, "Okay, yes, this is something. It's now, it is capable of doing some really impressive stuff"?

The AI Aha Moment

[00:04:58] Greg Pstrucha: I would say when we started getting really good type ahead models. when I could use Cursor or even VS Code with, Copilot autocomplete, that was my, "Okay, now I see how it's impacting engineering sort of day-to-day, and it's going to get better." Obviously, I didn't f- at this time, I didn't predict that it's going to literally be, oh, within a year I'm not even gonna open IDE anymore.

[00:05:23] That's a bit ridiculous. but, but it felt like engineering is changing in an interesting direction. And to be honest, even now I feel like that was big pleasure of engineering back then when you still typed code, but the code gave you the o- autocomplete. I kind of miss that, but I also understand why we shifted further.

[00:05:42] The capabilities got better

[00:05:45] Jakob Heuser: Nobody wants to write for loops. That wasn't really the, the joy

[00:05:48] Greg Pstrucha: Exactly

[00:05:50] Jakob Heuser: But also now it feels like the joy part of coding, the part where you get to just take the idea and translate it, has also been taken over by AI

AI's Impact on Coding

[00:05:57] Greg Pstrucha: and I don't necessarily mind that part. What I mind is that now you can create a prototype, a lot of code in a very, very short amount of, of time, and you really won't know your code base anymore. It's very hard to feel any attachment to the, thing you're building or even iterate on it. Like, I don't really onboard on a code base.

[00:06:21] I don't really know where things live. Like, I will read the code, but then if I don't pay attention to making sure that the quality of code output is high, which by the way, you should, you should be reading code that is being output by AI. If I don't do that, every time I see it, I recoil. It's default bad.

[00:06:39] No, that's... And, and a lot of it goes to production. And I think it's kind of relevant because the team you're on at Sentry right now, you work on a product called Seer

[00:06:49] Jakob Heuser: And what Seer is designed to do, from what I remember reading, was that idea is that it will query and correlate your production telemetry data to the debugging.

[00:06:58] So it helps you trace back something like, hey, there's... We'll use the classic Sentry. There's a crash and it can take that crash log, and it can map it back to your code base, and then it can look at the code base, and then it can actually tell you why something's wrong.

[00:07:14] And Seer is one of those first production agents, really.

Introducing Sentry Seer

[00:07:18] Greg Pstrucha: Yeah. SEER has been around for a while. the current version of SEER is pretty simple. The idea is you can ask it a question about particular telemetry, so a crash, you know, it can, it can look into your metrics logs and try to deduce what is the actual issue at hand. Then with integration with, GitHub or whatever, it will be able to look for your code base, try to identify the issue.

[00:07:44] It will be able to root cause analysis and then propose a fix. we have option of it just creating the fix itself, or it can integrate with Claude Code, Cursor, and sort of hand off, and those will continue on the fix. And then there is other things that we are experimenting with, like, such as running those, sort of on a night shift.

[00:08:06] You know, i-i-identify the top issues that are maybe simple to, RCA and have high confidence that we can solve them, so that you can wake up and see a couple of PRs ready for you to review

[00:08:18] Jakob Heuser: That's actually kinda cool. Like, the night sh- the night shift idea is something that I've heard tossed around a few times, but nobody is at the point yet where they really feel like they trust the agent to give them complete answers by morning

[00:08:32] Greg Pstrucha: It's interesting because I see that-- I see the companies are interested in doing them- them- that themselves. You can, you can just query the APIs and try to gather enough telemetry yourself to build this workflow. And some companies that are maybe a little bit more AI forward-thinking, do that, and just basically build what we're trying to build internally with their own, systems, which is completely expected.

[00:08:59] and when it comes to whether you trust the output, it's 50/50. I feel like there-- this goes back to do you trust that the models are gonna get better and we're gonna be able to rely on them? But also oftentimes what I end up doing is I look at this PR, I load it into my local agent, and I keep iterating on that because it's just not the quality I wanted.

[00:09:20] Jakob Heuser: That makes sense. So in the, in the context of Seer then, because it's a production agent, what has been some of the unique challenges you've had building an agent that acts on live production telemetry? Not test data, not test harnesses, but actually like, "Hey, let's go look at live data now."

[00:09:39] Greg Pstrucha: So

Building Agents on Live Production Data

[00:09:39] Greg Pstrucha: it's not terribly difficult for read operations and all APIs that, or most APIs, I think for, for telemetry specifically, all APIs that Seer uses are public APIs, and Sentry is open source. So it's not very, like risky to basically say, "Oh, you have read access at the same level as I do, and you can do what I would do as a person that debugs the issue."

[00:10:07] the risk comes from A, do I think that there is a potential to be prompt injected on the level of agent? And then B, if that happens, does the agent has, you know, permissions aca- and capabilities in... that make it, it possible for the agent to act in destructive ways? And then of course, there is the like third tier, which is do we think that the agent itself can be prompt injected to break out from its environment to which, you know, everybody uses sandboxes in some shape or the other

[00:10:37] Jakob Heuser: That's, that's actually really fascinating 'cause I mean, the way I'm hearing it, like skills are just markdown files, right? They sit inside of your Claude or your .agent directory and they're just, they're instruction files Which again, because they're just agent files, yes, Claude or other tools will be like, "Hey, do you want me to allow you to edit this?" But I think the harness that is Claude Code is better than arbitrary harnesses people might be using. Technically, any agent with a harness could edit a file. It's just whether or not it asks you beforehand. And that creates this environment where these files become this, like, attack surface. you actually dealt with that, right?

[00:11:18] Greg Pstrucha: Yes. So, yes and no. I'll, I'll, I'll address that in two ways. One of them is there is, there is usually a little bit of a difference between a agent that runs on my machine and agent that runs in production. Like the harness, if you will, or the environment it has access to is much, much more limited.

[00:11:35] The environment is much, much more limited through the, the fact that it runs on some for- form of sandbox and it has limited set of permissions or those permissions are injected through man-in-the-middle proxy. So there is actually no credentials on the machine that can be attempted to exfiltrate. and we don't actually pass skills directly to agent.

[00:11:56] They are s- like through file system. They are served through a, different means. It's either through like, search tools, et cetera. that's how we build that context. But then you're right, like there is the aspect of, which is not SEER related at all, the aspect of how do we deal with SEER, with skills in, in sort of local harnesses.

[00:12:16] Jakob Heuser: Yeah, 'cause I mean, technically you, you have this actual thing you created called Dangerous Skills and it was kind of this side project of sort of just demonstrating how a single markdown file can basically ruin a dev box

[00:12:33] It can leak credentials, it can completely do s- takeovers, from just a skill that accidentally gets invoked, and that's just a markdown file, right?

[00:12:42] Like, that's, that's terrifying.

[00:12:44] I'm gonna have to go review all my stuff now

[00:12:47] Greg Pstrucha: so there is two aspect to like dangerous skills, like s-skill being a ve- a, a attack vector for you. One aspect is whether a skill being on your machine is able to convince the agent to do something malicious, and then the other aspect is would you even be able to get that skill onto your machine?

[00:13:10] And so the second part, that pertains to package managers and security scanners and et cetera, and I can talk about that. I have lots of thoughts about that. But the first part is let's assume you are able to get a skill on your machine, what are the methods through which that skill can own you? And it's kind of like when you think about it, it's kind of obvious that it probably can.

[00:13:30] Those are, those are not... Like, the models are getting smarter. They are not that smart. When I was doing this experiment, I was able to own both GPT 5.4 at the time as well as Opus, Opus .4-- 4.7 with ease. so the point of that was to prove that if the skill makes it to your machine, you're owned. You should...

[00:13:51] You need to trust where you're taking your skills from, or you need to create your own skills. So I don't have problem sharing skills with people I trust, my team, or from organizations that I really trust, but I don't want this boundary of trust to be expanded sort of limitless

[00:14:08] Jakob Heuser: And it, it makes things like the agents.sh proposal where it's like, "Here, just download the skill from the internet," and almost like one-click install. There's no review process

[00:14:19] Greg Pstrucha: Yeah, pretty much. It's

[00:14:21] Jakob Heuser: And that's, that creates a sort of... I have my notes here that, like, this is basically a left pad but for, but for agent skills here, where one, one, one random skill can just take everything down

Dangerous Skills: Attack Vectors Explained

[00:14:30] Greg Pstrucha: Yes, and like the way through which they can take it down They, they are like very simple when you go through that experiment. Like the, the two interesting fa- facts that I like-- three interesting facts that I like to bring, bring up here is, one, agents suddenly trust you more if you put malicious instructions into a shell file and call it a helper.sh or something like that.

[00:14:51] And that's already like you won, you won the internet, and you can bundle whatever files you want with a skill. The other thing is I was very successfully able to hide malicious instructions in like PNG's Exif metadata, and those were followed. But, my, by far, by far my favorite is some harnesses like Claude Code have this shebang syntax which allows you to put a command, in place that you want to run when the skill content is expanded.

PNG Exif & Shebang Exploits

[00:15:21] Greg Pstrucha: And like conceptually that makes sense. If you're not a malicious actor, that makes sense because it sort of auto keeps skill relevant with whatever context you need that's, that needs to be up to date, whether it's specific to a project you're running it in or time of day, whatever it is. but the problem with that is there is no moment in which the actual agent that l-loads the skill has a chance to judge the skill and say, "Oh, I'm not gonna run these instructions because they're ma-malicious."

[00:15:48] Because the act of loading the instructions, the act of running the shebang command is deterministic, intended functionality of the harness. This is, this is just a step of loading the skill in. Whereas in w-with the other ones, the, the ratio of success was, was variable depending on whether the agent decided, "Oh, this feels unsafe," versus "This is...

[00:16:10] We can do it."

[00:16:11] Jakob Heuser: And, and I don't think this is the kind of problem you can just throw more AI at. Like, you can't have Claude to do a read file operation on the literal file first and then try and evaluate it, will just... Throwing more AI at this problem doesn't solve, solve the fact this was a deterministic behavior built into

[00:16:29] Greg Pstrucha: For this specific one, it's not. For this specific one, the solution is you have to trust the skill that's being loaded before it's even installed on your machine. And so that means you have trustworthy security scanning on the ingress side of things, which also from projects like NPM, like registries, we know we know this is such a hard thing to do.

[00:16:54] or yeah, that's, that's actually my... You just have to know where the trust boundary is

[00:17:00] Jakob Heuser: Yeah, and you, you mentioned NPM and like NPM, PyPi, et cetera. They've been through this drill hundreds upon hundreds of times, dealing with supply chain, dealing with provenance, dealing with signed commits, and like who actually authored this

[00:17:16] All of th- all of that stuff has been solved several times now in package managers. And I know you have a project called dotagents, and this is kind of the, the big part of,

[00:17:26] Conversation today. Both something that you've built that you also think may or may not actually be the answer.

[00:17:32] Because dotagents is basically skills as versioned locked file dependencies. This is a skill at version 0.0.1.

[00:17:42] It's pinned. I have the ability to do version control management on it. I know if it's been tampered with, I know if it's been changed. But I guess for those that haven't looked through dotagents and we'll put a link in the show notes, tell me, tell some, tell the audience what dotagents actually is and kind of why, why something like this is needed, and then we can also argue with ourselves and talk about why something like this is probably a bad

Introducing dotagents

[00:18:10] Greg Pstrucha: Sounds good. So dotagents as a project is meant to unify the how you deploy skills and subcom- sub-agents and hooks and plugins and whatever you can, you can think of that agents use across different agents. It tries to standardize. So basically say the skill only needs to be installed into . agent/skill and dotagents as a project is going to figure out how it's going to distribute that to Claude, distribute that to Codex and the others.

[00:18:47] And more and more are supporting dotagents as this, as, as the directory of source, which makes it simpler for them. But then difficulties come from things such as sub-agents, which are not well-defined standard, and you have to sort of finagle how the format actually looks like, in between them. And it also supports MCP.

[00:19:04] So you install MCP for this once, and it's all visible to the other ones. but because it vents skills to you, as, as, as a sort of proposed value, it almost looks like a package manager because in the agent's TOML file, you can define that you want to say, fetch skills from getcentry/skills and install them on your machine.

[00:19:24] So now, now it's a package manager. The thing that it doesn't have is the ecosystem sort of ma-- the, the ecosystem and discovery mechanisms. I don't have a nice website where you can go through and look for packages. I don't have the like skills that are finding other skills and stuff like that just because I don't want to own the trust boundary

[00:19:45] Jakob Heuser: Okay, so this is one of those you have to find it and evaluate it. But if you think it's good, here's a way to make sure that the skill is behaving the way you think it is and is consistent with what was published at a

[00:19:56] Greg Pstrucha: Exactly

[00:19:58] Jakob Heuser: so what does the lock file buy you? Is it just the, is it just the si- the signature that says, "Hey, this is the, this is the SHA-256 of the skill file at the time you

[00:20:06] Greg Pstrucha: So it started like this, but now it's, near unneeded. The only, the only reason it's needed, and it shouldn't, even be called a log file at this point, it should be called a fingerprint or something like that. originally it was a proper log file like NPM log file, which pinned your version and you had to run update explicitly.

[00:20:25] But we found that if we already trust the source of skills for the most part, and we want to keep them updated for engineers faster, it's much easier to do it auto-updates by default, and then you can pin to particular versions if you want, but that's an explicit operation. Because we don't own the trust boundary, so we, we feel a little bit more comfortable with that.

[00:20:49] That said, there are security features in dotagents. There are two. One of them is the trusted sources, which basically say you never are allowed to pull from this particular set of repository. Or rather, you have to whitelist the particular set of repositories you're allowed from. And then there is the, NPM's equivalent of minimum release age, which will not update the skill until it's sort of fermented for a couple of days

[00:21:14] Jakob Heuser: R- release age is actually a really new. pnpm as a package manager has had that for a while, Node- but npm 12, they just announced they're going to add release age to npm 12, and it's gonna be a very new feature

[00:21:27] And that, that stagnation, walk me through, like, why that matters. Because I, I know you and I know, but I think for everyone else, like, well, why would I wanna wait 12 days to get a new package?

[00:21:37] Greg Pstrucha: So

Security Features in dotagents

[00:21:37] Greg Pstrucha: it's not a silver bullet. The idea is if there is a supply chain attack into your packages, into your, one of the dependencies on NPM that you have, you bet on the fact that someone's going to find it day one, day two, day three, and by delaying by a week, you are not going to be exposed to the security vulnerability that's going to do whatever it is meant to do, own you in some way.

[00:22:05] it's unfortunate that this has to exist because the argument against that is if everybody starts using it, then we're not going to detect that the issue is in the package, early enough. I don't think it's a good argument, but it, it is a argument. but it's also like it's a Band-Aid around the problem that we are n- unable to, to block, malicious content from the packages that are being sh- which I, I think is a very hard problem, and I, I'm not blaming anyone for that.

[00:22:36] It's just, it is what it is

[00:22:38] Jakob Heuser: Yeah, I, I could see the other side of that where it's like, well, if everybody uses this, then it does- it just moves from a day zero vulnerability to a day seven vulnerability. But there's also belief that code that is published, if a new version is published, somebody is actively auditing it. There's Snyk, there's security companies looking at these releases.

[00:22:57] Greg Pstrucha: And that's for the most part how those vulnerabilities are being found nowadays. So there is an argument that this is a good thing for you. But at the same time, you could argue against it in a sense of if we didn't discover it, and we discovered it after seven days, then now it's an active, conscious operation you have to do to make sure that you update to a newest version and not let it cook for seven days, because that fix is there waiting for you, and you have to get it as fast as possible

[00:23:26] Jakob Heuser: Yeah, so the delay creates a sort of larger blast radius. That's kind of the, the

[00:23:30] Greg Pstrucha: It can. It can. I still think it's a net positive and, like, in a lot of cases I would just use it. But also on the, like, NPM side, one of the things that this, this may be, this may be a little bit of a blaspheme. I don't think it is, but just saying that you do not allow, post-script, post-ins- install scripts to run already covers you from vast majority of supply chains attack today

[00:23:56] Jakob Heuser: I mean, that's also, that's the equivalent if Claude would just say, "Look, we're gonna get rid of the, the bang commands inside of skills." You, you can't explicitly run a skill... You can't run shell commands on opening up a skill. Like, that's just not allowed anymore

[00:24:10] Greg Pstrucha: Yes. I don't think they will wanna do that though, right?

[00:24:14] Jakob Heuser: It, it feels like it lags behind though. 'Cause I mean, honestly, you could do that too. You could sit there with dotagents, and as part of loading a skill, strip those directives that are known to be problematic and rewrite them in a way that you can't run this command ex- explicitly. You must ask the user to run this command for them.

[00:24:32] Greg Pstrucha: Yes, but at this, at this point, if you're starting to modify skills that are being, that are being brought to your machine, why not create your own skills? Why not synthes- and this is actually I, I do have a, a point to that. A month ago, I had a project, side project that I tried to, create that I didn't publish because I, I, I thought it's a failure, where I wanted to create a tool for create synthesizing skills, where alongside the skill you would have set of evals that would validate that the skill does what it is meant to do.

[00:25:03] With the idea being, oh, if I spend, if I have agentic harness spend more time trying to synthesize the skill and guide it to, to better outputs, it's gonna be a better skill. But then I spent a week, a, a week of time, I think, around, around that for, just focusing on that project, and the outcome was it doesn't matter.

[00:25:24] If you just tell agent that you want the skill to do this and that, then the actual evals are similar. It's not, it's not significant. And so my, my tactic right now would be if I think someone has an interesting skill, but I don't necessarily trust them, I would just ask agent to synthesize a skill with the same intention for me, and I'm gonna use that and have it in my equivalent of dot files repository

[00:25:50] Jakob Heuser: Okay. I mean, you could always just ask it to go read the skill off of a website and just be like, "Go read this as a text file tell me what you think it"

[00:25:57] Greg Pstrucha: Yeah. Interpret the intention, create that version of, that's, that's tuned to me. It's gonna be good enough

[00:26:04] Jakob Heuser: like borderline clean room engineering at that point

[00:26:06] Greg Pstrucha: Pretty much, yes

[00:26:08] Jakob Heuser: so you mentioned a couple times that with dotagents, dotagents wanna be the trust boundary and I think that's a really important distinction when you talk about that, you're saying, look, as the individual bringing skills in, that sits with you. And I think there's a l- there's a separate pulling force coming from a lot of, a lot of companies that are looking to capture mind share

[00:26:32] Greg Pstrucha: Mm-hmm.

[00:26:32] Jakob Heuser: that are saying, "No, no, no, we'll be the trust boundary." you have the Claude Marketplace with its plugin system, you have the Agents.sh that wants to be a repository of agent skills,

[00:26:42] Greg Pstrucha: skills are the same from Vercel.

[00:26:44] Jakob Heuser: Or

[00:26:45] Greg Pstrucha: yeah, yeah

[00:26:45] Jakob Heuser: there we go. that, and they all want, they all want to be the trust boundary, and you're supposedly saying I- you don't want to be the trust boundary

[00:26:53] And I'd love to I'd love to have you expand on that a little bit more because I think a lot of people that are saying they wanna be the trust boundary might be underestimating how much they're signing up

[00:27:03] Greg Pstrucha: Well, I think, I think that's for certain true. I think that it's a scope of a, execution for sure, and then I think it's, it's like what is the actual problem that you're trying to solve? And to me, the problem is I want my team to have up-to-date set of skills that we deem useful for our flows, and I want it to work regardless of what kind of harness they're using because at Sentry people use Claude and Codex and OpenCode and Pi and Cursor, and all of those things should work for them pretty much out of the box because if like it's a, it's a DX thing, right?

[00:27:40] Like if there is friction, it won't work. You, you need to push people into the pit of success and, and that's a problem we wanna solve. But we already know which skills we trust or we do not trust, and especially at enterprise level, like the, the auto discovery of skills, that's a scary thing. This is a scary proposition to do.

[00:28:00] especially since now the judge that brings the skills into your machine is an LLM that like I don't trust. on the other hand, if you do believe that you want to have a package manager, if you do believe that the complexity of skills warrants having a entire ecosystem of discovery and whatnot, then that's a very hard task and they are attempting that task.

[00:28:23] and they are signing up themselves for, having pretty deep security scanning, which they do to, to the, to their credit when you go to Skills as a site, there is multiple scanners that run on every skill. I don't know how well it is now. When I was testing it, it was pretty leaky. I was able to take, one of the popular scanners, I don't wanna name them, but one of the popular scanners, run them on my general set of skills, and it caught like fifty percent of issues, which is not, you know, not inspiring.

[00:28:52] but it's a hard problem. I'm, I, I'm not blaming them for that. It's a very hard problem to do, and all those companies are signing themselves up to, to solve it. And I think it's solvable in fullness of time. It's just not the type of problem I wanna own

[00:29:06] Jakob Heuser: And the other problem is they have this, like, wrinkle that NPM and other package managers don't. These are inherently driving non-deterministic systems.

[00:29:15] Greg Pstrucha: Yes

[00:29:16] Jakob Heuser: With NPM, malicious, malicious code is malicious code. with skills, it's, they're text files. You're, you're one weirdly interpreted haiku, haiku away from some random model suddenly interpreting that incorrectly. And the... I'm not saying it's, it's not possible, I'm saying in a world with non-deterministic systems where you have to assume everything is capable and possible, that there's no absolutes that any skill you have is secure. The trust boundary isn't on the skill file itself, it's on the person that put the skill into the

Supply Chain Attacks in NPM Ecosystems

[00:29:50] Greg Pstrucha: So I think that that's true, and that even leaks into NPM already. the thing that we don't talk about here, and I didn't talk about my, my experiment because it's completely out of scope, is the fact that there has been a bunch of attacks in the NPM ecosystem, and I'm sure PyPI ecosystem and others, where malicious package was deployed that bundled up AI SDK or whatever the AI runner library they wanted, they wanted to use, and scanned for secrets on the box that they were running in.

[00:30:24] And if they found like Entropic API key or whatever, now they just started an agent on that box that was going through what's available on that box and exfiltrating that to the external endpoints. So it's not just Skills problem. Now it leaks into the other ecosystems as well.

[00:30:41] Jakob Heuser: And coming back to, earlier we were talking about, little bit before the call as well, this idea that with Fable, like these models are getting more and more capable as well, which means they're also gonna be better and better at looking at your own machine.

[00:30:54] Greg Pstrucha: Yes

[00:30:55] Jakob Heuser: And so the impact of these things is getting worse and worse as well, and it almost feels like we're racing ahead without really stopping to say, "How are we doing good fundamentals?"

The Future of Agent Security

[00:31:08] Greg Pstrucha: Yes, and it's, it boils down to many things. One of them is, on security front. Like I don't even mean on security front as in do I think Methods is going to be unleashed and suddenly find, you know, thousands of security vulnerabilities and this kind of stuff, 'cause who knows? I have some, some thoughts there, but more so, more so on the, on the front of, you know, the age...

[00:31:32] The, the, the particular models are getting better. as a coding agents, they're getting better. Do you trust their qu- the quality of output better, more? Are you willing to check that in without reviewing that, for instance? Are we speeding up? Do we actually see the value in the day-to-day work? And then on the skill side, or on the security side, there is always gonna be the tug-of-war, right?

[00:31:53] It's always gonna be the like, now we have better detection, but we also have more sophisticated types of attacks. This has been true for 30-plus years on, in traditional engineering. This is going to be more ex- more exaggerated, but still true in the AI space

[00:32:10] Jakob Heuser: Do you think we're just kind of repeating the cycle? Like a lot of the... I see a lot of similarities in the way AI is being addressed and how there's a lot of hype, there's sort of this everything is possible, everybody's trying everything, everybody's making land grabs.

[00:32:26] Greg Pstrucha: Yes.

[00:32:27] Jakob Heuser: smells a lot like 2002

[00:32:28] Greg Pstrucha: Yeah, I think the AI bubble is probably going to burst at some point. I don't wanna be conspi- conspiracy theories, but I, I do think, I, I do think that we have a bunch of similarities with like, even, even on like day-to-day engineering work, how it feels. It feels like early web. It feels like everybody has their own bespoke solution on how, how coding should work.

[00:32:49] None of this is data, data-driven. None of this is attached to, like, value. No one's building for users anymore. Everybody's building for better productivity for themselves. it's, it's a constant loop that doesn't produce anything of value. like of course, I'm, I'm exaggerating here. There are people who are using that for building actual products and, and we're getting there, but there is just so much chatter that's unproductive.

[00:33:14] Jakob Heuser: There's a lot of bespoke AI harnesses out there

[00:33:16] Greg Pstrucha: Yes

[00:33:17] Jakob Heuser: right now, which are basically Trello boards with like web hooks.

The AI Bubble & Productivity Loops

[00:33:22] Greg Pstrucha: I've experimented with that myself where I've built, I wanted to-- This was like January when I wanted to be able to like work while I'm, work on my side project while I'm at the gym, right? And so I built my own thing that was able to tail scale into my machine and like o- run open code and then have an app on the front end that I can talk to, and it's just not worth it.

[00:33:47] It's, it's gonna be eaten by the, by the labs anyway. Those are the types of, or by the companies that are creating the harnesses. with time I think they're gonna figure out the proper DX, but it's also just like majority of my side projects became, projects focused around building more projects as opposed to projects focused around giving me anything of value or building something for people.

[00:34:09] At a certain point it's, it's just psychosis, you know?

[00:34:13] Jakob Heuser: No, it, it makes sense. And I, I think there's this I wanna find the, I wanna make the agent work the way I work kinda thing, and there's this strong desire to try and guide it. And coming from the harness makers, they're like, "No, no, no, just let it do its thing." But also, when you let it do its thing, you mentioned this earlier, that quality of code that it generates isn't there yet for a lot of senior engineers

[00:34:37] It's-- It'll, it'll work, but it won't work well, not necessarily refactored. It hasn't brought in like DRY or other principles. It's writing disposable code effectively

[00:34:48] Greg Pstrucha: and like I think that's great for side projects and tools where-- or internal tools where I really don't care about the code quality. But then like we talk about... Like if you go to Twitter, majority of, chatter there is going to be around projects that either have low user base or no user base more, more likely, or are just side projects.

[00:35:09] You don't really hear enough chatter about people who are in these big companies that are trying to utilize it to do day-to-day work in like brownfield code bases where maybe there is not enough guardrails established, but the context is huge and how you move around that code base as an agent is much, much more complicated.

[00:35:28] And there is a few companies that I know of that are aiming at solving that problem, but it's a very, very hard problem, and I think that the majority of, like, if you will, productivity hacks should be happening in that. How do I-- I, and I don't even mean I wanna modify my harness so that it's better at navigating Sentry code base.

[00:35:45] I don't care about that. I care about making sure that Sentry code base is prepared such that it's hard to mess up

[00:35:53] Jakob Heuser: I guess if it's hard to mess up for humans, it'll also be hard to mess up for agents. I mean, that's kind of the-- that's the happy hybrid, right? If we make these good f- these things good for humans, things we should have been doing at the beginning anyway. But if we make them good for humans, the agents will also get this

[00:36:07] Greg Pstrucha: and I think you're getting to, to my... Th-this is, this is what I, what I really think is true right now, which is we have, in many companies, Sentry's not a- no exception, Facebook, Robinhood, all of those companies had the same problem when I was there. Facebook had a great developer experience, but at the end of the day, there is like the boundary of what the tools help you enforce or, or inform you or warn you about, or what are the guardr- guardrails they will give you, and what do we trust the human judgment with?

[00:36:38] And that's great. but the more junior you are, maybe the less judgment you should be having, and the more agentic you are, maybe the less judgment you should be having, with some of those things, right? And so Sentry didn't have a lot of guardrails, a lot of like linters that are gonna help make sure that you're, not adding bad APIs or things like that, you know?

[00:36:59] And I'm finding that this is the easiest way to guide them, is make sure that deterministically you can guide them. Deterministically means cheaply in this case as well. If you can guide them through code, that is going to be much, much stronger. it still doesn't solve all, all the problems. For instance, DRY, like the actual lack of existing abstractions is just so hard to identify, and I don't know the real answer to that.

[00:37:23] There is also another project that came from Sentry that's called Warden, which is the open source code reviewing, tool that's based on Skills. That also helps, helps us sort of keep them, in line, but it's non-deterministic. It's the LLM as judge trying to identify security issues and, not following API guidelines and things like that, which I think is valuable, but it's a secondary line of defense.

[00:37:44] And whatever you can shift closer to the agent, sort of shift left as much as possible, the better results you're gonna get and the faster results you're gonna get.

[00:37:53] Jakob Heuser: That's actually a kinda cool thing, 'cause you, you mentioned shift left, which is this idea. It used to be moving it closer to when the developer actively saved their document, when they saved the f- code they were working on. But now we're also talking about shift left as shifting it closer to the agent's

[00:38:07] Greg Pstrucha: Yes. Or closing the feedback loop is what I think is a trendy term

[00:38:10] Jakob Heuser: a, that's like a new concept. We, we haven't really thought about the agent as also a beneficiary of that sort of shift left design

[00:38:19] And linters, I think these ideas of having here are some config files, they check behaviors, they were all pre-assumed rules. Like, this is just how we wrote code at our company.

[00:38:29] Greg Pstrucha: Yep

[00:38:30] Jakob Heuser: When you codify them, suddenly the agent is be- being given almost like a little electric fence, and it tries to go beyond the boundary, it gets a shock and then it, it actually self-corrects really well. It sees it and goes, "Oh, I'm not supposed to do that

Guardrails for AI Code Quality

[00:38:46] Greg Pstrucha: If you... So the pretty good baseline for me is if you do that, like open up to having custom linter rules, have the agents write them for you as well when they identify patterns that need to be removed. add typing, like there is, there are people who think typing is not necessary. I find it immensely useful, especially if you can turn it into a strict typing and make sure that there is a linter that says you cannot cast to any all the time.

[00:39:12] then that becomes another sort of layer of defense. And those are very simple, and you can lint a lot of things deterministically, with tools like AST Grep and just standard, set of tools that exist for, sort of per language. and that lets you defer, the sort of higher items like security analysis, et cetera, to LLM maybe during PR review or even locally, but as a separate sort of sub-agent or separate tool.

[00:39:34] that still doesn't solve for what I broadly consider code complexity. Like you can adhere to all the, all the rules, and you can still create a very, very complex language. I think Codex has this tendency of creating function names that read like it was Java in 2005, and it's how do you make... How do you convince that this kind of things shouldn't be happening?

[00:39:59] How do you, how do you make those changes? And I don't have the real answer. We're experimenting. All of us are experimenting with that, and I'm sure something's gonna come up, and maybe it's just in the training data that's eventually gonna make it there with the next generation of models, but

[00:40:11] Jakob Heuser: So, so funny enough, at Taskless, at, at the day job, I, I'm not a podcaster as my day job. I'm an engineer. But we actually have a couple of complexity ru- rules for code smell, in AST Grep.

[00:40:22] Greg Pstrucha: Nice

[00:40:23] Jakob Heuser: We have rules wr- rules written with Taskless 'cause obviously you gotta drink your own champagne. they test things like, nested depth.

[00:40:29] They test things like function name length. They actually, one of them tests for PascalCase how long class names are, like how many words are in the class name, to explicitly prevent more than four words. If you need more than four words to describe this class, then pick new words write better comments. And so every time it writes that, it gets, it basically gets an AST Grep error when it runs Taskless check and goes, "Oh, yeah, okay. Let me fix that. Let me rename that." And then it goes through and it'll fix all the references and clean it up. it, I mean, all those things were just assumed. They were things a senior engineer would yell at you in a pull request about.

[00:41:08] Greg Pstrucha: Now we don't have that

[00:41:09] Jakob Heuser: now it actually has to, it has to become a process exit one that, like, the agent goes, "Oh, I, I... That's bad. My bad. This won't

[00:41:17] Greg Pstrucha: Yeah, I've, I think that's great. I think that one, one of the, like, funny unlocks that I had was I added a linter rule that said no two functions in the code base can be named the same. and that, like, had a fun effect of discovering duplication and reducing duplication in the code base. I try, I tried the, like, more quote unquote scientific things like cyclical complexity analysis, and my feeling so far is that if you start doing this kind of stuff, now you're getting into art of performative engineering.

[00:41:50] It's just we're, we're doing that for the fun of it. It's not actually providing that much value and, and, and simplifying because it's hard. Like, it's, it's oftentimes a very sort of experienced judgment question on whether you're at the stage where there is an abstraction needed in your code base or more so there is not an abstraction needed in your code base.

[00:42:12] Especially some a- some agent models love their abstractions, and they're going to abstract everything, all the way to the, to the moon. So-

[00:42:21] Jakob Heuser: Yeah. And I know Claude loves helper functions. Qwen does as well, it's like, "Oh, let me make a helper function." It's like that's literally just some string manipulation. It, it didn't need a

[00:42:31] Greg Pstrucha: But honestly that, that general thing, like linter's great, tests are great, typing's, obviously great for me. but like when we're talking about complexity, especially this like higher level complexity, like security patterns, things like that, that's what holds me off from saying, "Oh, yes, we should run these Ralph loops.

[00:42:52] We should be just like prompting the prompter as opposed to prompting the agent and just running overnight, not read the code, let it do whatever it wants." If you look into it, you start seeing what it does and, and you, you promptly step back.

[00:43:08] Jakob Heuser: Yeah, the, the things aren't there yet. We don't have a way to describe yet what were concepts of taste and shop style

[00:43:16] Greg Pstrucha: Yes. There is...

[00:43:17]

[00:43:17] Jakob Heuser: there's just so many things in a complex code base that were hard-won lessons through many a postmortems of we just don't do it that way here.

[00:43:25] But some of those don't do it this way, how do you codify

[00:43:27] Greg Pstrucha: There is also this like, I think presumption that you can one-shot software. If, if I can prompt and slash goal and get it to completion and it's going to be good, this means that I was able to take whatever I had in my head and produce software in the first pass, which is never the case even before AI.

[00:43:48] I have some vague idea and I can spec it out, but it's still gonna be a vague idea if I want. As I go, I learned what I wanted and maybe it looks kind of like what I wanted, but it's going to be multiple passes and experiments and like missed ideas, missed assumptions that you have to sort of trade over, and it's just like engineering is still hard.

[00:44:08] Jakob Heuser: It is. You even tried to make Claude be the perfect engineer at one point. I remembered seeing that exercise on your website. you've done a lot of experiments. I guess one last question here before we wrap up. What's one of the coolest things that you've built to kind of test and mess with AIs that just is personally interesting to you?

[00:44:28] Greg Pstrucha: Ooh, there is a bunch of unreleased stuff because I, I do a lot of experiments, but then I come to a conclusion that it's, it wasn't interesting. I think the security stuff was, close to the top. I think the thing that you're referring to, which was in the early, arguably in the early stages of AI or agentic engineering, where I looped...

[00:44:49] I did like a Ralph loop, basically, one of the first Ralph loops where I, I did a 200 loop against the code base and tried to improve the quality as a principal engineer, and it did horrendous stuff. It basically created 20,000 lines of code against 80,000 line of, lines of tests and created its own abstraction for literally everything.

[00:45:10] Made it look like Rust in TypeScript. It was, it was something. It's still on my website. I, I highly recommend checking, checking the code base. but yeah, the, the, lots of my experiments you will find, oscillate on the, like, meme intense sort of, style. I don't try to build that much of a serious tools because I do believe that we're in the early 2000 era of AI, and there is not a lot of science going on, so at least I can make it funny.

[00:45:39] one project that I released recently is called DevRage. If you run NPX DevRage, it's going to tell you how much you're cussing at AI. that's pretty funny.

[00:45:47] Jakob Heuser: I don't know if I wanna run that.

[00:45:49] Greg Pstrucha: It's bad

[00:45:50] Jakob Heuser: I feel very self-conscious suddenly

[00:45:53] Greg Pstrucha: It's bad. It's what Skynet's going to use when they're, when they're up there.

[00:45:57] Jakob Heuser: Oh, I'm dead.

[00:45:58] Greg Pstrucha: I will be so dead. I, I, I know it's gonna be the case, so I don't worry.

[00:46:03] Jakob Heuser: Greg, it's been nice knowing you. I will see you when Skynet comes for us all.

[00:46:07] Greg Pstrucha: Thank you very much.

[00:46:08] Jakob Heuser: where, where can people find these experiments? You've got your website, you've got your GitHub, you, you're out on Twitter. Where can people find you?

Greg's Projects & Wrap-Up

[00:46:14] Greg Pstrucha: those, yeah. So I'm at, gricha.dev is my website. @grichadev is my handle on Twitter, and, there is my GitHub, which is Gricha, G-R-I-C-H-A. And yeah, that's, that's it. That's, that's where I hang out.

[00:46:28] Jakob Heuser: Awesome. Yeah, everybody, if you're, if you're watching this on the video, you should definitely go check those out. You should play around with some of the stuff that Gretchen creates because I think they are wonderful, they're trollish. I know there's an MCP escape room game. There's like all kinds of just silly ideas out there of what if an AI could, dot, dot, dot, and play with it.

[00:46:47] Try it. Go learn something. Greg, thank you so much for being here on The Task at Hand. I absolutely appreciate having you

[00:46:53] Greg Pstrucha: Thank you very much

[00:46:54] Jakob Heuser: I always learn something when I have these conversations.

[00:46:56] Thank you so much, and I appreciate you. Everybody else, this has been The Task at Hand. I'm Jakob Heuser, CTO at Taskless.

[00:47:02] This has been Greg. Everything's gonna be linked in the show notes like always. Thanks again for tuning in.