• LinkedIn
• Twitter
• Instagram
• YouTube
• RSS Feed

Apple •Spotify• Pocket Casts •Youtube •Overcast •RSS

What’s up everyone, today we have the pleasure of sitting down with Alexey Komissarouk, who leads growth engineering and martech at Anthropic.

Summary: Alexey builds martech infrastructure at the company with the most reason to trust AI to build it for them. He unpacks how Anthropic uses Terraform pull requests, a data warehouse doing more work than any vendor, and a security review process that’s genuinely harder than the code itself. He explains why Anthropic still keeps Linear around, why the company builds its own CDP instead of renting one, and why an old thesis about IKEA shelves needed a serious rewrite. He also admits he doesn’t actually know who owns half the internal tools people have built inside Anthropic, and he’s not super worried about that… yet. If you’ve ever wondered what build versus buy looks like once building costs almost nothing, this is the episode that answers it.

In this Episode…

• How Engineers Actually End Up Specializing in Martech
• Why Anthropic Still Buys Some Vendors
• Why Anthropic Builds Its Own CDP Instead of Buying One
• How the Vibe-Code Era Is Rewriting Build Versus Buy Math
• Who Owns a Vibe-Coded App After Its Builder Leaves
• Why the Data Warehouse Beats Every Other Part of Your Martech Stack
• Which Martech Tools Survive Even Though You Could Replace Them
• How to Avoid Drowning in Shadow Martech Tools
• What Happens to Marketers When Claude Can Just Do the Work

About Alexey

Alexey is a key member of the technical staff at Anthropic where he wears the hat of the dedicated growth engineer who works on martech. He’s spent the past year and a half rethinking which tools the company builds versus buys as AI changes the economics of both. He previously led Growth Engineering at MasterClass from 2020 to 2023 and spent 4 years at Opendoor as an early engineer and later a Growth Engineering manager.

Before that, he ran a product engineering consulting practice for companies including Dropbox, Pebble, and Binti, and in 2014 he left San Francisco to co-found Hacker Paradise, a work-and-travel company that has since run trips to more than a dozen locations for over 800 alumni. He graduated from the University of Pennsylvania with a computer science degree, where he started the PennApps hackathon.

Just a quick disclaimer that Alexey is joining the podcast as Alexey the technologist and human, not the employee at Anthropic. The views and opinions he expresses in this episode are his own and do not necessarily represent Anthropic.

How Engineers Actually End Up Specializing in Martech

Ask most engineers what they want to work on, and martech rarely makes the list. It carries a reputation problem, unglamorous and marketing-adjacent, the kind of work that gets assigned rather than chosen. Alexey built an entire career on being the exception, and the path there had nothing to do with a plan.

He grew up in Israel reading Joel Spolsky, came to the US for college, and started a company right out of school that ended in a messy founder breakup. A stretch of consulting followed, along with a bootstrapped travel company, Hacker Paradise. Then came the moment every founder-adjacent engineer eventually hits: watching former classmates land at Google and Facebook while he was, in his own words, futzing around for half a decade. He needed something that paid well and still felt like solving a real problem. That search led him to growth.

“I call growth the retirement program for technical co-founders.”

Martech specifically was never the plan. No engineer, Alexey says, wakes up excited to work on it. It sounds boring until you’ve felt the pain yourself, and he had. At his own startups, he was the one setting up email automations, and he remembers exactly what it felt like to get pulled off real work because a marketer needed a template changed in code. That irritation is what turned into a career. Opendoor hired him to rebuild their long-term email sequence, a problem he already understood cold from years of iterating on Hacker Paradise’s own systems.

He ran that function at Opendoor, took it over again at Masterclass, and now runs it a third time at Anthropic. He describes himself as the engineer who never minded doing the work everyone else avoided, and that pattern has built the same career 3 times over.

The engineers who end up owning martech well are rarely the ones who set out to specialize in it. They’re the ones who got annoyed enough by a blocked marketer that fixing the problem became more interesting than avoiding it.

Key takeaway: Identify the recurring request that annoys your engineering team most, whether it’s an email template edit or a landing page tweak, and treat it as a real problem worth solving instead of an interruption to survive. Build the tool that makes that specific annoyance disappear for good. The engineers who end up running martech well are usually the ones who fixed their own irritation first.

Back to the top ⬆️

Security Approval Is the Real Bottleneck at Anthropic

Every fast-moving company claims to move fast, right up until security gets involved. At Anthropic, that friction shows up in a specific place: the moment a marketer’s vibe-coded app is ready to connect to something real.

The upside is a real departure from a typical martech org. Marketers at Anthropic don’t file a ticket and wait. They build the tool themselves, and martech’s job shifts from building it to making sure it holds up and plays well with everything else. Alexey says that’s been the pleasant surprise: instead of a request landing on his desk, a finished app does.

“It’s very nice when marketing doesn’t come to you with a request. They come to you with, hey, this app works, is this okay?”

Security is the part that moves slower. Anthropic builds technology that’s explicitly dual use, and that changes the math on every internal tool. Add an MCP connector to a martech app, and that app becomes a genuine attack surface. If it gets compromised, someone could use it to reach Anthropic itself. Approvals that would have taken a day at a previous job, the kind of thing nobody would have thought twice about, now run through a real review process.

Why Anthropic Still Buys Some Vendors

Part of that scrutiny comes from who Anthropic sells to. It has enterprise customers in health tech and fintech, which means it inherits a lot of the same compliance obligations as a vendor to them. That context shapes how the team decides what to build versus buy.

Security reviews get treated as an afterthought in a lot of engineering cultures, something to route around rather than respect. Anthropic’s own product makes that posture harder to justify. When the thing you build is the reason attackers would want in, slowing down to check becomes part of the job rather than an obstacle to it.

Key takeaway: Map every internal martech tool that connects to an external service through an API or an MCP connector, and treat each connection as a potential attack vector instead of a convenience. Route anything handling customer or model data through a real security review before it ships, even when building it only took an afternoon. The friction is real, but skipping the review is worse.

Back to the top ⬆️

Why Anthropic Builds Its Own CDP Instead of Buying One

Look at almost any martech category right now and you’ll see the same thing happening. Vendors that started out solving one problem keep bolting on adjacent features until they all start to look like the same product wearing a different logo. Alexey has a name for it.

“I’ve described this as the martech Mexican standoff, a bunch of products that all cost a lot of money, all trying to become one another before the CFO says, let’s just use this one.”

He speaks well of the category too. He’s used Census and Hightouch at past jobs and as a consultant, and says he’d reach for one of those tools again at a growth-stage startup. Anthropic ended up building instead, mostly because so much of what the company needs is custom enough, and it has the headcount and engineering capacity to do it well.

The Tool They Replaced: the CDP

Asked what Anthropic replaced despite having a perfectly good vendor solution, Alexey doesn’t hesitate.

“I will say we largely are doing the CDP ourselves.”

Anthropic ran on an uncontroversial off-the-shelf CDP for a while before making that shift, one Alexey still recommends as a default choice to most companies. The shift happened once traffic and internal logging tooling grew large enough that engineering could piggyback off infrastructure that already existed. At that scale, the question stops being whether a vendor is useful and starts being how hard it would be to build the same thing on top of the data warehouse using tools the rest of engineering already runs.

That decision connects to a broader belief Alexey holds about architecture. He’s a strong believer in the composable CDP: everything lives in the data warehouse first, and then you build as many apps on top of it as you need, some giving marketers cleaner views of the data, others pushing it out to wherever it needs to go. Once that foundation exists, the CDP stops being a single vendor’s product and becomes a layer anyone can build on.

His actual filter for these decisions comes down to 3 questions: how good is the internal version of the thing, how much effort would it take to build and maintain, and what does it actually cost. At Amazon-level scale, he says, you don’t get the luxury of a few big-check vendors you never question. A growth-stage startup might reasonably keep one. Anthropic treats almost none of them as untouchable.

The real test for build versus buy is whether the company’s scale has already removed the specific reason the vendor category existed in the first place.

Key takeaway: Run the same 3-question filter before renewing any martech vendor contract: how good is a realistic internal version of this tool, how much ongoing effort would it take to build and maintain, and what is this actually costing you at your current scale. Put the data warehouse first, ahead of any single vendor’s roadmap, so nothing you build later gets locked to one platform. Revisit tools you inherited at a smaller scale specifically, since the math that justified them may no longer hold.

Back to the top ⬆️

Speaking of replacing tools… are you still operating like it’s 2013 and you haven’t updated your chatbot? We recently started collaborating with the Docket team and what they are building with their Inbound Demand Agent is super cool. Check it out.

How the Vibe-Code Era Is Rewriting Build Versus Buy Math

Every engineering org has at least one person who eyes each SaaS line item and wonders out loud why the company is still paying for it. At Anthropic, that person is Alexey, and he’s aware of how that sounds.

The Pressure to Build Everything Yourself

He describes going to leadership with the same pitch on repeat: what should we do about this tool? Leadership tells him not to worry about it. He pushes back anyway.

“I think I’m just cheap, man.”

That instinct has a real filter behind it, though. Alexey hasn’t seen anyone get annoyed about using an external tool unless the tool is genuinely bad. The bar for keeping a vendor around, in his view, is that people have to actually love using it, not just tolerate it. Linear is his go-to example inside Anthropic: engineering teams keep asking why they haven’t built their own task management, and the answer is that Linear already has good taste baked in, and tools with that quality tend to survive longer no matter how tempting it is to replace them.

Why the Old Math No Longer Applies

Alexey pushes back on the idea that vibe coding has made parts of the build versus buy debate irrelevant. He says the underlying gates, the dollar thresholds and valuation stages that used to trigger a build decision, have simply moved. The dollar figure at which it becomes cheaper for engineering to build something in-house used to sit around a million dollars. Now it might be closer to $100,000. The valuation at which a company decides to bring most things in-house has moved too, from something like a $10 billion company down toward a $1 billion one. These are rough estimates, not precise thresholds, but the underlying shape holds: it’s the same math, run on inputs that have all gotten smaller.

What’s actually changed is who does the building. In the old model, a marketer’s request traveled a fixed path: marketing asks, martech ops evaluates vendors and still has to loop in engineering for integration, engineering eventually ships something. Now the marketer often just vibe codes the tool directly. Alexey has entire internal apps his own martech ops team built and maintains that he finds out about 6 months after they shipped, with nobody ever escalating it to him.

That shift only works because of what sits underneath it. If the data lives in a clean data warehouse and the underlying pipelines are trustworthy, most requests collapse into something much simpler: a nicer front end on data that’s already correct. Anyone can build that without ever pulling in an engineer. What actually still requires engineering is narrower than it used to be: decisions with real consequences, like ad or email changes that need checks and review, or situations where the data quality itself hasn’t been proven out yet. Once you can trust a Claude-generated number the way you’d trust a query written by your own data team, most of what used to require an engineering ticket doesn’t anymore.

The build versus buy decision used to run through a procurement conversation. Increasingly, it runs through a data quality conversation instead, and whoever controls the warehouse controls how much of the org can skip engineering entirely.

Key takeaway: Audit your data warehouse for trustworthiness before you audit your vendor contracts. Fix the pipelines and clean up the schema so a Claude-generated answer can be trusted the way a hand-written query would be, since that trust is what lets marketers safely vibe code their own tools without pulling in engineering. Reserve actual engineering review for decisions with real consequences, like anything affecting ad spend, email sends, or customer data.

Back to the top ⬆️

Who Owns a Vibe-Coded App After Its Builder Leaves

Every org that lets marketers vibe code their own tools eventually runs into the same uncomfortable question: what happens to that tool when the person who built it quits? Ownership of internal software used to have an obvious answer, whoever’s name was on the commit history. That answer gets murkier once the person who wrote most of the actual logic wasn’t a person at all.

“It’s me by default, but it’s actually Claude. Claude will escalate it to me if we run into issues, but it probably has a better context of the code.”

That’s Alexey’s honest answer, and the honesty is the point. Nobody has fully solved this yet, and pretending otherwise would be worse than admitting it’s still TBD. Phil half-joked that they won’t sign a 3-year contract with that arrangement, they’ll keep it at monthly. Alexey’s response was to dare anyone to go ask a vendor for a 6-month renewal and watch how fast the tone changes.

What It Takes to Pass the Vibe Check

The harder question sits one level up: what turns a marketer’s useful tool into infrastructure the company can actually depend on? Alexey’s default answer is surprisingly low-key.

“By default, what you need from me is nothing, actually.”

A lot of tools clear that bar without him ever getting involved. The example he keeps coming back to is email rendering, a properly miserable technical problem where getting a single template to look right across Outlook and a dozen other clients used to eat real engineering time. Martech ops built a vibe-coded tool that takes the team’s default templates and checks them against a testing tool like Litmus, and they did it almost entirely without him. He came in for a day or 2 to help tighten a loop where the tool renders a batch of variations and has Claude visually flag the bad ones, but he estimates martech ops did 99 percent of the actual work.

His real line in the sand shows up in a narrower place. Most of these tools are read apps: they pull real data and display it, and if anything gets written back, a human still copies the output into the actual email vendor by hand. The moment that changes, the moment someone wants to fully automate a change that modifies a thousand templates at once, is exactly when Alexey wants a seat at the table, because that’s precisely where a small mistake stops being small.

The infrastructure bar comes down to blast radius, how much damage a single mistake could do once it ships, not how polished a tool looks or how clever the build was. A tool that reads data and shows it back can fail in a small way and get fixed the next day. A tool that writes changes at scale can break a thousand things before anyone notices.

Key takeaway: Sort your team’s internal tools into 2 buckets: ones that only read and display data, and ones that write changes back at any real scale. Let the read-only tools ship and iterate freely without engineering sign-off. Require an engineering review specifically at the moment a tool moves from writing one record at a time to writing changes across many records at once, since that’s where a small bug turns into a large one.

Back to the top ⬆️

Why the Data Warehouse Beats Every Other Part of Your Martech Stack

If AI is going to make custom software radically cheaper to build, the obvious question follows fast: what part of a marketing stack still counts as a real advantage, and what’s just plumbing you happened to build yourself instead of renting? Is it the database, the workflow logic, the interface, or the institutional knowledge baked into how the system works? Alexey has a clear ranking.

Why the Database Comes First

The data warehouse sits at the top of his list, and early. His reasoning is simple: it’s the one piece everything else eventually plugs into, and there’s no guarantee your various vendor tools will play nicely with each other. There’s a near-certainty they can all read from a data warehouse you control.

“It’s not obvious that all your various vendor tools will work with each other, but it is obvious that they can all read from your data warehouse.”

Workflow logic ranks a close second, though Alexey is quick to point out it’s really the same category wearing a different name. Workflow logic is still just code, or still just a database. He’s comfortable letting a vendor tool run a piece of that logic. The line he draws is around orchestration: the moment you’re coordinating the entire workflow end to end, that coordination layer belongs internally, where it can call out to specific vendors only where they actually earn their keep, on the leaf nodes of the process rather than at the center of it.

Config as Code Turns Marketing Into an Engineering Problem

The mechanism Alexey keeps coming back to is Terraform, infrastructure as code applied to marketing settings instead of servers. If a tool’s configuration can live in a repository instead of a vendor’s admin panel, most established martech tools already support it through existing Terraform integrations.

“Claude is better at code than almost anything else. You just translate whatever problem you have into code, and all of a sudden Claude’s amazing at it.”

That reframing matters more than it sounds like it should. Ask an AI tool to change a vendor configuration through an API directly, and it has no memory of the exact current state of that configuration and no way to check without making a pile of API calls first. Put the same configuration in Terraform, and every change ships with version control, a review step, and every safety check a normal code deployment gets.

Alexey walks through a concrete example: connect a new advertising partner and you need 5 new events piped to it. In the old world, that meant clicking through a CDP’s interface by hand. With config as code, Claude can instrument the events, wire up the destination, and ship the whole change, while legal’s rules, like never sending unhashed emails or raw IP addresses, become an automated check that blocks the merge instead of a policy nobody actually enforces.

The sequence he describes moves in stages: first, everything lives inside a vendor tool the way it always has. Then the database itself moves into the data warehouse. After that, the vendor tool gets managed through Terraform, so marketers can propose changes directly with Claude and get the same review process engineering already trusts.

Vibe-Coded Front Ends Without the Risk

The final stage in that sequence is building a custom front end on top of a vendor’s own business logic, and Alexey’s email vendor example makes the payoff concrete. A vendor tool might handle all the orchestration logic behind when an email actually sends, but the template editor sitting on top of it can’t easily enforce a company’s copy or legal guidelines. Build a new front end that looks like the old editor, and every time someone hits save, it can run through those review checks first and only then write back into the vendor tool.

“The risk there is pretty low, because the back end is still your vendor tool. But your front end, now you get to add any sort of customization you want.”

Alexey used to build janky versions of this pattern with Chrome extensions and custom JavaScript hacked on top of a vendor’s site. Now the same outcome comes from asking Claude to build the front end directly and wire it into the vendor’s APIs, reverse-engineered where necessary. The data warehouse is yours, the interface is yours, and the vendor keeps only the riskiest, most business-critical logic in the middle, exactly the part worth paying someone else to maintain.

Competitive advantage in a marketing stack comes from owning the layer everything else depends on, and using code as the interface to change it safely, far more than it comes from which individual tools you chose.

Key takeaway: Move your data warehouse to the center of your stack before you change anything else, since every future decision depends on owning that layer. Check whether your existing martech vendors already support Terraform or another config-as-code integration, and start managing at least one high-friction configuration, like ad destination mappings, through code and version control instead of a vendor’s admin panel. Build a lightweight custom front end only where a vendor’s own interface is blocking a rule your legal or brand team actually needs enforced.

Back to the top ⬆️

Which Martech Tools Survive Even Though You Could Replace Them

Most B2B companies still treat the CRM as the source of truth for the whole go-to-market org, even though the data underneath it usually belongs in a data warehouse. Old habits are hard to break here. Salespeople live inside one tool, and whatever that tool reports becomes the number everyone trusts, whether or not the warehouse tells a cleaner story.

Alexey’s read is that this kind of change rarely comes from the data team. It comes from a sales leader deciding the current setup isn’t giving them what they need. If the tool works and the numbers get hit, nobody has a reason to push. When he ran his own startups, there was no CRM at all, just small internal tools built on Rails that did the job well enough. That’s a much easier call to make with a 5-person sales team than with an enterprise motion that’s already working.

That same logic, a tool staying in place long after you’re technically capable of replacing it, is the exact argument Alexey made a few years ago about a completely different category: landing page builders.

“It’s so funny because the thesis survives, and the particulars I was way wrong about.”

The original argument used the Kallax, the IKEA shelf everyone keeps buying and nobody bothers replacing, as the metaphor. Some tools stay worth paying for long after you’re capable of rebuilding them yourself, because attention, not capability, is the real constraint. His original example was landing page builders: keep using whichever one your team already has, because marketing wants to run a lot of custom pages and engineering has enough front-end work on its plate already. That argument doesn’t hold up the same way anymore.

What still holds is the underlying need. Marketers should be able to spin up a landing page in half an hour to test an idea. What’s changed is what it takes to get there. Instead of a dedicated no-code platform, you need a strong design system and a written skill that spells out the rules a page has to follow. Pair that with one front-end engineer who understands the platform and one designer who owns the system, and Claude can generate a page that’s on-brand, compliant, and fully custom in the time it used to take to configure a template.

“Lovable is becoming Webflow before Webflow becomes Lovable.”

Alexey is bearish on the landing page builder category, even as he expects individual products in it to evolve and find a smaller niche. His take on why this category goes first, ahead of other tools that seem just as replaceable, comes down to how easy the output is to judge. A landing page is visual. Anyone can look at one and tell in seconds whether it’s good. That makes it one of the easiest things for AI to prove itself on, and one of the first places a Kallax-style tool stops being a Kallax and starts being optional.

The tools that survive the vibe-code era will be the ones where nobody can agree on what a replacement is even supposed to look like, far more than the ones that are simply hardest to replace technically.

Key takeaway: List every martech tool your team keeps paying for out of habit, then sort them by how easily someone outside the team could judge whether a homegrown replacement is actually as good. Start replacing the tools at the easy-to-judge end of that list first, like landing pages and visual assets, where quality is obvious at a glance. Leave the tools where good and bad are hard to tell apart for last, since limited attention does the real protecting there, no matter how easy they’d be to rebuild.

Back to the top ⬆️

How to Avoid Drowning in Shadow Martech Tools

Give every marketer the ability to vibe code their own tools, and you get an obvious side effect: a pile of internal apps that nobody remembers approving, half of them useful, half of them left behind the moment their builder moved on. Alexey doesn’t dodge this. Asked whether teams at Anthropic keep rebuilding Linear on the side instead of just using it, his answer is instant.

“We built like 10, by the way.”

Every one of those attempts ends the same way: someone tries it, gives up, and goes back to Linear, because Linear is actually good. That small anecdote is really the whole shadow-tool problem in miniature. Building is cheap now, so people will keep trying, and most of what gets built will die on its own without anyone noticing. The real risk sits in losing track of what’s actually running production-critical work versus what’s a leftover side project nobody remembered to delete, far more than in the experimentation itself.

Alexey says the next 12 to 24 months will be genuinely difficult on this front for most companies, martech included. He’s not feeling that pain acutely yet, which he treats as an early warning sign rather than reassurance. What’s kept martech at Anthropic ahead of the curve so far is a dedicated engineering team that actively curates what gets built, so people are shipping their own tools without throwing out process entirely.

“What do you do with a garden? You clip the hedges and make sure everything is mostly fine without getting too in the weeds of what people are using.”

His actual plan leans on the same AI that created the sprawl in the first place. Point it at the problem directly: find every stray app people are actually using, build a list, flag which ones should be consolidated and which are outright wrong, hand back a prioritized plan, and once that plan is approved, execute it. Keep a recurring task running that checks again every week, catching new ones and reporting back. He’s confident this already works well enough to run today. Most companies will eventually land on something like a single person whose whole job is maintaining that list, the head-of-internal-tools role as gardener rather than builder.

Claude as the Onboarding Ramp

That same context problem shows up for a completely different reason once you ask how a new hire finds their footing.

“All of Anthropic is basically a big context engine for Claude.”

Alexey tells a story from 15 years back, as a Facebook intern who figured out the guy sitting next to him knew everything and could just ask. A few rounds of that and the guy pushed back: have you tried looking it up yourself? He learned to calibrate how long to struggle before asking for help. That calibration mostly disappears with Claude in the loop, because asking costs nothing and the answer arrives immediately, as long as the company has actually done the work of feeding Claude good context to draw from.

Anthropic doesn’t have a formal catalog of every martech-related vibe-coded app. If someone asked him directly, his real answer would be to go ask Claude and see what comes back, not to pull up a spreadsheet. Phil connects that to something bigger: Claude works the same way as an onboarding ramp for anyone starting any new project, not just new Anthropic employees, and removing the perceived learning curve is often what actually changes things for people who assume building something themselves is out of reach.

Tool sprawl and onboarding friction look like separate problems until you notice they share the same root cause. Both come from context that exists somewhere but isn’t reachable fast enough to matter, and both get solved the same way, by making that context something anyone can just ask for.

Key takeaway: Set up a recurring weekly task that asks Claude to inventory every internal tool your team is actually using, flag which ones overlap or look inactive, and generate a prioritized consolidation list for a human to approve. Assign one person to own that list on an ongoing basis rather than treating tool sprawl as a one-time cleanup project. Point new hires at Claude as their first stop for context on internal tools and systems, before they interrupt a teammate.

Back to the top ⬆️

What Happens to Marketers When Claude Can Just Do the Work

Every marketer who’s spent an afternoon watching an AI tool do a version of their job has felt some flavor of this question, even if they haven’t said it out loud. Given the chance to ask himself anything he hadn’t already been asked, Alexey went straight there.

He admits he feels the anxiety too, the same one his friends bring up: the AI keeps getting better and better, so what actually happens long term, and how does anyone stay useful along the way. On the long-term half of that question, he doesn’t pretend to know more than anyone else. He calls it above his pay grade and moves on, which is itself a useful answer, since so much AI commentary claims certainty it doesn’t actually have.

The short-term half is where he has something concrete to offer.

“The watermark between what you need an engineer for and what a marketer can do with Claude just keeps rising and rising and rising.”

The old pattern was predictable: a marketer hits a wall, says this needs a custom tool, and escalates to an engineer who builds it. Alexey describes a new pattern replacing it, where the marketer shows up having already built the tool, and the conversation that follows is about specific blockers instead of a blank request. Maybe there’s an access permission issue. Maybe Claude pushed back on something and the marketer wants a second opinion. Either way, the engineer’s job shifts from building from scratch to unsticking something that’s already 90 percent there.

His advice for marketers is direct: get access to Claude if your company doesn’t already have it, and push it further than feels comfortable. See how far you actually get before you assume something is beyond you. When Alexey imagines what a job interview looks like a few years from now, he pictures self-sufficiency becoming a real, explicit part of the pitch, not a nice-to-have buried in a resume bullet.

“I’m that engineer who’s like, have you tried using Claude? Why are you bringing this to me. Just never get that response out of your engineers.”

The marketers who come out ahead of this shift will be the ones with the highest tolerance for trying something themselves before asking someone else to do it for them, far more than the ones with the deepest technical background.

Key takeaway: Get a Claude subscription this week if you don’t already have one through your company, and pick one recurring request you’d normally send to engineering. Try to build it yourself before you file the ticket, and only escalate once you hit a specific, nameable blocker rather than a vague sense that it’s too hard. Track how often you resolve the request without ever looping in an engineer, since that number is a real signal of how self-sufficient you’re becoming.

Back to the top ⬆️

How Alexey Decides What Deserves His Energy

Every guest on this show gets asked some version of the same question eventually: how do you decide what actually deserves your time. Alexey’s answer starts with an honest disclaimer.

He calls himself bad at this, then describes a system that sounds pretty deliberate anyway. 2 young kids take a fixed chunk of time, and he treats that as non-negotiable, on the logic that there’s no other reason to have had them in the first place. Exercise and sleep take another chunk. Everything left over goes toward work that’s actually interesting to him and that he believes works.

“This is it. This is the job I am happy to have for the rest of my career.”

That realization landed about 5 years ago, once he became head of growth engineering at Masterclass. He’s held other titles since, including VP of engineering, and talks openly about the parts that didn’t fit him. He respects the people who do those jobs well and knows he couldn’t do their version of the role as well as they can, the same way they couldn’t run his. That mutual respect, paired with getting to teach the next generation of growth engineers and help define what the frontier of the role even looks like, is what actually locked in his decision: advise, invest, and operate inside this one specific space for the rest of his career, and let everything else go.

Alexey traces this instinct back to his own father, a tech entrepreneur who worked relentlessly. Having kids of his own made the trade-off obvious to him in a way it apparently wasn’t for his father: if you’re going to have children, you spend the time with them.

Career satisfaction comes from finding the specific, narrow lane where your weaknesses stop mattering because someone else on the team covers them, and staying there on purpose, far more than from finding the single best job available.

Key takeaway: Write down the parts of your current role you don’t enjoy and are only mediocre at, then find the specific person on your team who’s genuinely strong in those exact areas. Hand that work to them deliberately instead of continuing to grind through it yourself, and double down on the narrow slice of the job where you’re actually the best person for it. Block off a fixed, non-negotiable chunk of your calendar for the people or habits that matter most to you, the same way you’d block off time for a critical deadline.

Back to the top ⬆️

Episode Recap

Alexey Komissarouk makes one central argument across this conversation: AI hasn’t eliminated the build versus buy decision, it has moved every threshold that used to define it. The dollar figure where building beats buying used to sit near a million dollars and now sits closer to $100,000. The company size where it made sense to bring most things in-house used to require billions in valuation and now applies much earlier. The underlying math stayed the same. Only the inputs moved.

The tactical thread running through every chapter is the same: put the data warehouse first, treat vendor configuration as code wherever possible, and reserve real engineering review for the moment a tool starts writing changes at scale instead of just reading data back. That’s the pattern behind Anthropic building its own CDP, running vendor tools through Terraform, and drawing a hard line around anything that could break a thousand records at once without anyone noticing. It’s also the pattern behind Alexey’s take on the Kallax argument: some tools survive because nobody can agree on what a good replacement would even look like, more than because they’re inherently hard to replace, and landing page builders just lost that protection.

For practitioners, the implication is uncomfortable but real. The gap between what requires an engineer and what a marketer can do directly with Claude keeps widening, and the marketers who benefit most are the ones willing to build first and ask questions only when they actually hit a wall. Martech ops teams that used to be a request queue are turning into something closer to a curation layer for tools other people already built.

None of this comes wrapped in false confidence. Alexey is upfront that ownership of a vibe-coded app after its builder leaves is genuinely unresolved, that shadow tool sprawl is a real problem still ahead of most companies rather than already solved, and that he has no idea what the long-term future of marketing roles looks like once AI keeps improving. That honesty is arguably the most useful part of the episode. Nobody has this fully figured out yet, including the people building the infrastructure for it.

Find Alexey Komissarouk’s writing at alexeymk.com.

Full episode ⬇️ or Back to the top ⬆️

✌️

—
Intro music by Wowa via Unminus
Cover art created with Midjourney (check out how)

Apple •Spotify• Pocket Casts •Youtube •Overcast •RSS

Related tags

See all episodes

Future-proofing the humans behind the tech

Apple •Pocket Casts•Google •Overcast •Spotify •Breaker •Castro •RSS

• LinkedIn
• Twitter
• Instagram
• YouTube
• RSS Feed