Guy Podjarny is the co-founder of Tessl. Before that he founded Blaze, a web performance company acquired by Akamai in 2012, and Snyk, a developer-first security company.
In his conversation with Tristan, Guy shares his model for how agentic development works. Models are the new operating system. Tools let agents act in the world. Context, the thing developers actually write and maintain, is what Guy argues is the new code. All of it is wrapped in a harness that sets the UX, the constraints, and the container. His central argument is that most teams already treat skills, the canonical unit of context, the way software gets treated before anyone takes it seriously: copied files, cloned repos, no versioning, no way to know if a change made things better or worse. He calls the failure mode, “the inability to scale vibes.”
He also argues, and Tristan tests the idea against dbt Labs’ own experience building a purpose-built harness, that most companies will end up owning their harness rather than renting one from a frontier lab, as cost pressure and capable open-weight models like GLM 5.1 change that calculus.
Tristan joined the Super Data Science podcast to trace analytics engineering back to its 2016 origins, explain why the semantic layer matters more in the agentic era, and break down how 12-kilobyte skill files are turning year-long migrations into six-week ones.
dbt Summit 2026 is almost here. Connect with the world’s largest gathering of dbt users, September 15-18 at The Cosmopolitan in Las Vegas. Level up your data and AI work: Register now with a 25% discount using the code dbt26-podcast.
Listen now: Spotify · Apple Podcasts · YouTube · Amazon Music · RSS
Three ideas from the episode
1. Context breaks into three buckets, and each one is loaded with a different amount of force. Guy’s taxonomy: policies and practices are the decisions a team already made about how it works (API design, security policy, which framework to use); specs are documentation-style definitions of how a product or system behaves; and workflows are procedural sequences for tasks like incident response or a multi-step data job.
Layered on top is a separate question of forcefulness: rules get shoved into the context window on every single turn, skills are ready-made units that load on a hint, and passive docs just sit there for an agent to search if it needs them. A skill’s front matter, the YAML block at the top of a skill.md file, is the part that’s always loaded, which is also why a hundred skills competing for that same sliver of attention becomes its own problem.
2. Skills need the same lifecycle as code, or you’re just scaling vibes. A single developer iterating on their own prompts can get by on instinct: try a phrasing, see if the agent does better, move on. Guy’s point is that a skill only becomes valuable once it’s reused, shared, or handed to someone else to modify, and that’s where vibes stop working.
If a teammate proposes a change to a shared skill, there’s no way to know whether it made things better or worse without an eval. If cost suddenly matters, there’s no way to know whether the skill actually needs Opus or would run fine on GLM or DeepSeek. And skills carry real security exposure: malicious skills lifted wholesale from the open ecosystem, negligent skills that omit basic safety instructions, and vulnerable skills that guide an agent into pasting credentials somewhere they’ll end up in a log.
Treating a skill as a reusable unit of software, not a markdown file you hope stays relevant, is what pulls all of that under a lifecycle: versioning, quality review, dependency management, evals, security checks.
3. Most companies will end up owning a harness, not renting one. A team at dbt Labs wanted to build a dbt-specific harness, and his first instinct was that this was a bad idea, since general-purpose tools like Claude Code and Codex already work well. It turned out to be neither hard to build nor a wash, delivering meaningfully better accuracy and real gains in token efficiency.
Guy’s broader argument is that any organization running more than one kind of agent, coding, legal, DevOps, sales, will need to manage shared context and constraints across all of them, which no single frontier lab’s harness is built to do. The other force pushing the same direction is cost. Open-weight models like GLM 5.1 are now good enough that companies talk openly about swapping them in, something Guy says would have sounded like a confession a month earlier and now reads as forward-thinking.
Between focused agents that need shared context, real cost pressure, and the risk of over-relying on a harness built by a company that also sells the model underneath it, Guy expects building your own harness to become a core competency rather than a stopgap.
Key takeaways
Lightly edited for clarity.
You’ve started multiple companies, all in developer tooling. Walk through that path.
Guy Podjarny: I’m a developer by trade. I started as a developer at an early AppSec company that got acquired, and got acquired again by IBM. In that process I moved into product, then briefly into a C-level role. At IBM I felt it was time to pursue something I wanted to do, which was start a company. I left to found Blaze, which focused on making websites faster. I took knowledge from the world of AppSec around application analysis and built an inline compiler for web pages to make them faster, and that got acquired by Akamai. I became CTO of about half of Akamai for three and a half years.
After Blaze and Akamai I got the itch to do it again, so I started a company and called myself CEO. That was Snyk, a software security solution helping developers build security into their development process. Snyk went well after a couple of years of wandering the desert and some near-death experiences, and it kept growing. About two and a half years ago I’d passed the CEO reins at Snyk to focus on product strategy, and I started working on AI and caught the bug.
The last step was accepting I’m an addict and leaving to found Tessl. We believe there’s a new software development paradigm forming, one that revolves around intent and instructions instead of code and implementation. Two years ago we didn’t know what that would look like. We just had conviction it would form, and that it’s exciting to build tools for it.
What keeps you starting over?
Guy Podjarny: A glutton for punishment. I’ve thought about that a lot. I think fundamentally satisfaction comes out of struggle. You take on something hard that you believe matters, work hard on it, and if you succeed, you get that satisfaction. I was in a comfortable spot at one point, working part time, doing a lot of angel investing, learning a lot but not owning anything. Accepting that you can’t have it both ways, that you can’t have the comfortable life and still feel that drive, is a little bit of an addict’s behavior. You’re looking for that hit of satisfaction.
The other piece is that I’m driven by impact. When I think about how to achieve the most impact, there are a lot of ways to do it, including as an investor. But the way I best know how to do it is to take problems I can solve with technology and community, the two things I know how to do, and drive ahead.
Why base Tessl in London and go co-located, when Snyk was built remote-first from day one?
Guy Podjarny: With Snyk we had a London office and a Tel Aviv office from the start, so it was naturally remote-friendly. We made a rule that no team would be entirely co-located, almost the opposite of what most companies do, because I was afraid of an us-versus-them dynamic I’d seen in past companies. That built good async habits early. With Tessl we made a conscious decision to be local and co-located here in London, though a few people, especially in go-to-market, are elsewhere. A big part of that is the speed of alignment and collaboration.
There’s a general truism in AI, and in any fast-moving space, that the importance and the cost of alignment is growing in relative terms. Getting a group of people in a room to agree on something costs the same as it always did, but the time it takes to build the thing afterward is much smaller, so the relative cost of alignment goes up. I took the hit on access to talent, which is the real trade-off, for the sake of ease of alignment. We also invest a lot in community here, hosting two or three meetups a week in the office. We’re hybrid: people come in three to four days a week rather than every day.
What’s a skill? Start from the top.
Guy Podjarny: Let me zoom out to the emerging agentic stack. Being AI native means focusing on delegating work to agents, which is different from using an agent as an assistant. You have to think about the task you’re defining and how you verify the results, similar to management.
The stack today looks roughly like this: models are the new primitive everyone builds on, effectively the operating system. You have to think about whether your instructions compile for a given model. Tools sit on top of that and turn a model into an agent, letting it interact with the world and fetch information. Then you have context, and I’d argue skills are the canonical unit of context, the new code, in the sense that context is what actually gets executed. Both of those are wrapped in a harness: the UX you interact through, a constraints layer, a container, and mechanisms like hooks to introduce deterministic software where you don’t want to leave a decision to the model.
So context is sandwiched between two pieces of software, harness on top setting the stage and constraints, tools underneath as enablers, and skills sit in the middle as the thing you actually program.
That’s a more expansive definition of context than just documentation. Is that really how you think about it?
Guy Podjarny: It’s a bit like asking what is code. There’s infrastructure as code, data as code, a variety of types. When I look at context files, the things you maintain and evolve, they tend to hold one of three things.
Policies and practices are decisions you made in a room about how your API design works, your framework choices, your security policy. Specs are definitions of how a product or system works, closer to documentation, useful when something is error-prone or expensive for an agent to figure out on its own. Workflows are sequences you create to help an agent along, because it might not know how to do incident response or process a large volume of data, and sometimes you need consistency for compliance or because you want repeatable behavior across a thousand runs.
On top of that there are three levels of forcefulness: rules, the stuff in your CLAUDE.md or AGENTS.md that gets loaded every time; skills, which are more like ready-made commands the agent loads on a hint; and passive docs, which just sit there for the agent to find if it goes looking.
Is there a part of a skill that’s always in the context window, even before the rest of it loads?
Guy Podjarny: Yes. The skill has a hint, metadata in the YAML front matter, that gets loaded every time and helps the agent decide whether to pull in the rest. It gets tricky, because if you have a hundred skills, they start competing with each other for the agent’s attention. I might be getting technical about the definition. In the ecosystem, when people say skill, they often just mean context in general. Skills can come with reference material, docs, a whole package. Many skills today are distributed via agent plugins, an installable package on top of the agent, so they’re really just a reusable, portable unit of context.
Using Anthropic’s more specific definition, what does a skill literally consist of?
Guy Podjarny: It’s actually very lightly structured. There’s a primary skill.md file with defined front matter, a name, some definition of when to load it, and text that can include images or anything else you’d throw into the model. That genericness is part of its strength, since it makes a skill naturally portable across agents.
Second, it can ship with reference material in a defined folder structure, mostly just a packaging convenience since the skill.md typically links out to those files.
Third, most harnesses, Claude Code, Codex, Gemini, Amp, and increasingly vertical agents, have their own way to install skills, with some variation in where they get fetched from and how they load.
Beyond that, a skill is a very general, generic thing, and that’s why I think when people say skill, they usually just mean a reusable unit of context.
You’ve written that most teams treat skills as static artifacts that quickly go stale. What were you seeing that made that click?
Guy Podjarny: I’d call it the inability to scale vibes. These tools are powerful enough to be overwhelming, and people are impatient to see something work, so they lean into intelligence and run forward. The result is a lot of voodoo, a lot of “does it work,” and people get stuck once they hit that wall. The simplest version is prompting itself: you run it, you think a certain phrasing makes the agent succeed more, and because it’s a single-player experience, that’s manageable. It’s you talking to yourself.
But a skill is a reusable unit of software. You don’t create one unless you want to do something twice, or share it with someone else, and that’s exactly where it breaks down. If a colleague proposes a change to a shared skill, how do you know if it made things better or worse? If cost suddenly matters, how do you know whether a skill needs Opus, or GPT, or would run fine on something like GLM or DeepSeek, which are dramatically cheaper? You end up back in a world of vibes.
There’s also a security angle, probably from my AppSec roots: skills get executed by the agent, whether that’s reading an email, browsing, or loading a skill, and executing instructions creates real risk. We’ve seen a huge number of malicious skills in the open ecosystem. There are negligent skills that just lack safety instructions, like telling an agent to commit something into a repo without checking whether that repo is public. And there are vulnerable skills that guide an agent into something insecure, like pasting credentials into a prompt where they get captured in a log.
Once you start thinking of skills as code, you realize we already have solutions for a lot of this. You don’t need to reinvent the wheel, you just need the relevant stack for this new type of software.
When we first talked about Tessl a couple of years ago, you described spec-centric development. Was the shift to today a pivot?
Guy Podjarny: More an evolution, or an elevation. We started by saying software will move from revolving around code and implementation to revolving around intent and instructions. We focused on the spec: you say what you want to build, and the agent builds it, dealing with the fact that you never say everything you want, so there’s a shadow spec that gets created as the agent fills in gaps. I still think that’s needed, but as agents came onto the scene, it became clear that’s only part of what you want from a successful developer on your team.
You also need them to understand your financial constraints, your style guides, your data schemas, your aesthetic choices: do you want simplicity or flexibility, cost efficiency or fast iteration. We evolved from speccing the program to speccing the programmer, thinking about how you want a good developer on the team to actually work. That’s what pulled us into the broader world of context, which is where the word skills comes in as the term of the moment.
How do you now describe what Tessl is?
Guy Podjarny: We see ourselves as an agent enablement platform, and today even context is just one piece of that. You should think of us as a composable factory for agentic development. We offer a variety of software development tools: Tessl Review, which agentically reviews whether context is high quality; Tessl Verifiers, fast linters that check whether an agent adhered to the context it was given; an eval platform for creating dynamic tests, so you know whether a skill actually helped or regressed when you change it or swap models; a package manager for versioning and distributing skills to a registry; and observability tools that monitor agent logs so you can learn from them.
What we’ve recently released is the Tessl Agent, a harness that focuses on factory building. You launch it in your repo, it explores your history and past pull requests, and it can, for example, create a code review skill based on patterns it’s observed, set up an automation that aggregates logs from that activity daily, and extract eval scenarios from those cases so you don’t regress as you evolve it. It can also, on your instructions, try running that skill on a cheaper model so it runs more cheaply over time. Tessl becomes those two things: the agent that builds the factory, and the set of building blocks for factory building, with context as one piece of it.
What drove that expansion from a toolkit for advanced users into an agent that builds the factory for you?
Guy Podjarny: Building factories was just too hard. It’s scary. It feels insurmountable, like there’s a big thing you need to do to get started. As a result, only people advanced enough could take advantage of the tools we’d built. We saw that when we were running inside someone else’s harness, it was hard to improve the user experience or even know precisely what happened, so we needed to go down a level ourselves.
There are really two convergent paths to adoption. One is going from single-player to multiplayer: you have a skill, you want to share it, you see five similar skills and don’t know which to pick, you don’t know if they’re secure, or which ones you can safely delete. That’s the skills-sprawl problem, and it extends well past engineering into non-development parts of the organization. The other path is wanting to get to the cutting edge through continuous loops rather than forcing everyone to reach a high level of local expertise.
They converge: if you start from loops, eventually you want to reuse what you built somewhere else and need central tooling. If you start from central governance, eventually you want to make things better on a loop. Depending on your pain point right now, skills sprawl or wanting to drive forward, you land on one or the other, but they end up in the same place.
Tell me about evals. What is one, and where does it run?
Guy Podjarny: An eval is an agent test with a runtime component: you dynamically execute the agent through a scenario and see how well it did, as opposed to a review action, which is more like static analysis, faster and more scalable but less powerful. Just like tests, evals can be big or small, sometimes a waste of tokens, sometimes fundamentally valuable.
To create one, we help generate a scenario: how to set up the environment, maybe pulling code from certain commits, adding or removing a skill or context, then defining the task, which we can generate from the skill itself, from historical pull requests, or from live observation. Then you run it in a sandbox eval environment, typically with and without the skill you’re testing, to see if it’s actually helpful.
By default, if you’re evaluating a skill, we use a cheap model, currently what he refers to on the recording as “DeepSeek V4 Flash,” which isn’t as good as Sonnet but demonstrates skill uplift faster and cheaper, so it’s a good signal for whether you’ve progressed. If you’re assessing a new model instead, you can run across a wide variety of models.
The last piece is criteria: for each scenario, what does the setup look like, what’s the task, and how do you judge the output, including making sure you haven’t leaked criteria information into the task itself. Developers don’t like writing docs or tests, and it turns out they don’t like writing context or evals either, so the easiest path is to observe agent behavior and auto-capture it as an eval rather than asking anyone to write one by hand.
Can Tessl spin up the infrastructure an eval might need, like dbt plus test data?
Guy Podjarny: You can put a lot of that in the eval container, though we don’t do all of it in a cookie-cutter fashion yet, and there are probably gaps. If you’re just reading data it’s not a problem, but if you’re writing data you have to think about cleanup, not unlike tests. We’re probably strongest in auto mode for coding scenarios. When you get into something like a dbt-shaped scenario, the platform enables it, but you may need to work a bit harder to set it up, and we’d want to hear back on what that looks like in practice.
You’ve said companies will run many agents, coding, legal, sales, DevOps, that need shared context outside any single harness. Why won’t the labs that build the best models also build the best developer tooling?
Guy Podjarny: There’s a real advantage to controlling both the model and the harness. A lot of models are visibly tuned around their own agent, and it’s often hard to get them to sway off it. Sometimes that’s a genuine advantage. But organizations want flexibility, and they’ll use many agents. Even a team that’s all-in on one harness is probably also using an agent from their project tracker, or their observability tool, or their legal team’s tool, and those all need the same context, the same constraints, the same knowledge, which pushes people to manage that outside any one harness.
The second, more recent driver is cost and the open models. It’s funny: talking about cost a month ago made you sound like a skeptic, and now it makes you sound like a forerunner. Companies are now talking openly about swapping in something like GLM 5.1 that competes well with a frontier model, in a way they’d have done quietly before.
That raises a real question: how much do you trust that a frontier lab’s harness will make you successful with an open-weight model that competes with their own business? Between focused vertical agents, cost, and wanting to own your own destiny as the market shifts around you, I think people will want to own their harness. I don’t know that there’s a single one that wins, but building your harness, like building your factory, is a competency you should be developing.
You were skeptical about building a dbt-specific harness. What changed?
Tristan Handy: I had the wrong priors on this, whatever, four or five months ago. There was a team internally that wanted to start building a dbt harness, and I thought it was a bad idea, because everybody uses Codex or Claude Code and they seem to be pretty good. It turns out it’s not actually that hard to build a harness, and the ability it gives you to tune for your specific factory is pretty profound. You can achieve both better accuracy and something much more token efficient. So I’ve become a believer in the multi-harness world.
Could a harness like Tessl’s get used for non-coding work?
Guy Podjarny: It’s not our priority right now. This world is being led from the dev world outward. We talk about a software factory because the models are better at development, and loops are easier to build there, so the standards get set in that world first, but the pattern travels. A lot of the same knowledge applies.
At Tessl our own go-to-market team couldn’t keep up with how fast our product was changing, and people were spending all their time updating sales decks and demos that were always a step behind. So a lot of our current investment is in expanding into go-to-market: a messaging framework that updates from the repo automatically, auto-generating demos when the product changes, figuring out which customers to notify when a capability ships, and tapping into customer call data to see how people actually responded.
Eventually a salesperson still has to learn the thing, so there are necessarily people in the loop, but they need to be enabled rather than left to do the update work by hand. Anywhere you’re repeating an action, you should think about how to agentify it, and once you do, you put it in a loop: gather feedback, whether that’s a customer opening an email or a human’s comment correcting something, and set up an automated recurrence to make it better.
Chapters
00:09 Welcome
00:36 Guy’s path: AppSec, Blaze, Akamai, Snyk, Tessl
03:46 “A glutton for punishment”: what keeps him starting companies
05:32 Passions outside of work, and family
06:24 Jigsaw puzzles, and the moment AI ruined them
07:00 Why Tessl chose to be co-located in London
08:55 The rising cost of alignment in a fast-moving space
11:16 The emerging agentic stack: models, tools, context, harness
15:13 Why context is “the new code”
15:42 The three buckets of context: policies, specs, workflows
18:17 Rules, skills, and passive docs: three levels of force
18:59 What’s always loaded: the YAML front matter
20:32 Anthropic’s skill definition, and when it landed
21:19 What a skill.md file actually contains
23:59 The inability to scale vibes
26:42 Cost: do you need Opus, GLM 5.1, or DeepSeek?
27:23 Malicious, negligent, and vulnerable skills
28:56 From spec-centric development to speccing the programmer
31:49 Tessl as an agent enablement platform and composable factory
33:04 The new Tessl Agent: a factory-builder harness
35:05 Why building factories was too hard for most teams
36:37 Two paths to adoption: skills sprawl and continuous loops
38:48 Why the labs won’t own developer tooling too
42:09 GLM 5.1, and talking about cost without sounding like a Luddite
44:02 Tristan on rethinking the dbt-specific harness
44:34 Owning your harness as a core competency
45:22 Could this extend to sales?
45:33 Tessl’s own go-to-market automation problem
48:44 What an eval actually is
51:20 Eval anatomy: setup, task, criteria
52:53 Can Tessl spin up a dbt-plus-test-data sandbox?
54:03 Wrap-up
Please reach out at podcast@dbtlabs.com for questions, comments, and guest suggestions.
This newsletter is sponsored by dbt Labs. Discover why more than 80,000 data teams use dbt to accelerate their data development.