Luke Stahl's Blog

End of coding, age of building

Sat, 07 Mar 2026 00:00:00 GMT

The constraint moved. For decades, the thing that determined whether software got built was whether someone could write the code. You needed syntax, framework knowledge, years of pattern recognition. That's not the constraint anymore. The constraint is whether you can describe what you want built, evaluate what comes back, and make good decisions about what to do next.

This didn't happen gradually. A set of tools crossed a threshold within about six months, and the gap between "I have an idea" and "I have a working prototype" collapsed from weeks to hours.

What happened in late 2025

The shift wasn't one tool getting better. It was five or six things converging at once.

Cursor shipped background agents in late 2025, letting multiple AI processes work across a codebase simultaneously. One agent refactors your auth layer while another writes tests for the module you just finished. Parallel execution against a shared codebase, with conflict resolution built in. That's a different editing model than autocomplete.

Anthropic released Opus 4.5 and a generation of RLVR-trained models that crossed a reasoning threshold. Earlier models could write functions. These models could hold architectural context across a 50-file project, understand why a particular abstraction existed, and make changes that respected the existing design. The gap between "generates code" and "understands the codebase" closed.

Claude Code started running as a local CLI, reading your file system, running your tests, iterating on failures without round-tripping through a browser. It turned a chat interface into something closer to a junior developer sitting next to you, except it could work through an entire debugging session in minutes.

And the browser-based builders matured. Bolt, Lovable, and v0 went from generating impressive demos to generating deployable applications. Not always clean applications. Not always production-grade. But working software that a non-developer could ship to real users, connected to real databases, with real authentication flows.

Each of these alone was incremental. Together, they moved the floor.

The coding era versus the building era

The coding era rewarded a specific set of skills. You needed to know that JavaScript handles async differently than most languages, that React re-renders on state change, that SQL joins have performance implications at scale. Years of practice built an intuition for debugging, architecture, and language-specific idioms. The work was writing code, and the quality of the code depended on your accumulated experience writing it.

The building era rewards a different set. Articulation matters more than syntax. Can you describe the data model clearly enough that an AI generates the right schema? Do you know that this feature needs async processing instead of a synchronous call, even if you've never wired it up yourself? And when the AI generates three approaches, can you tell which one breaks at scale? The skills shifted from implementation to specification and evaluation.

The difference shows up in specific scenarios. A marketing ops manager needed an internal tool to sync campaign data between HubSpot and their reporting dashboard. In the coding era, that's a ticket in Jira, a sprint planning conversation, two weeks of developer time. In the building era, she described the sync logic to Claude Code, iterated on the output for an afternoon, and had a working tool by end of day. Because the constraint moved from implementation to specification.

A designer prototyping a dashboard in Figma used to hand off static mockups to a frontend team. Now the prototype becomes the product. v0 takes the design, generates the React components, and the designer iterates on the actual code output. The handoff didn't get faster. The handoff disappeared.

Who builds now

The audience expanded, but not in the way the "everyone is a developer" crowd claims. A product manager shipping an internal tool isn't a developer. A designer generating React components from a prototype isn't a frontend engineer. They're building software, but they're doing it through a different interface than a code editor and a terminal.

The people making product decisions can now execute on them directly. That's the actual shift. A domain expert who understands the problem space deeply can build the first version of a solution without translating their knowledge through a development team. The translation layer got thinner.

Developers didn't become less important. They became faster. A senior engineer using Cursor with background agents can move through a codebase at a pace that wasn't possible two years ago. The tedious parts shrink. The judgment parts stay. A staff engineer reviewing AI-generated code still needs to spot the subtle concurrency bug, the missing index, the abstraction that will break when requirements change. That work didn't go anywhere.

What this means for developer content

If you're writing tutorials that start with "First, install the SDK and initialize a client," you're writing for a shrinking audience. Not shrinking to zero, but narrowing. A growing segment of builders thinks in prompts, not imports. They describe what they want, evaluate the output, and iterate. The SDK installation happens inside that loop, handled by the AI, often without the builder knowing which package manager ran.

This doesn't mean content gets dumber. It means the frame shifts. Instead of "How to implement authentication with NextAuth," the useful article becomes "How to think about authentication for a SaaS app." What are the tradeoffs between session-based and token-based auth? When does OAuth make sense versus magic links? What are the actual security implications of each choice?

The content that holds value is the content that helps someone make decisions, not the content that walks them through keystrokes. Implementation guides aren't dead, but they're commoditized. The AI can generate a NextAuth setup. What it can't do is tell you whether NextAuth is the right choice for your specific situation.

What didn't change

Architecture decisions still require someone who understands distributed systems and scaling characteristics. AI can generate a microservices setup, but it doesn't know whether your team of four should be running microservices or a monolith. It doesn't know your deployment constraints, your on-call rotation, or the operational complexity your team can absorb.

Judgment still matters. AI generates plausible code quickly. It also generates plausible bugs quickly. Someone needs to review the output, understand the failure modes, and catch the cases where the AI optimized for the wrong thing. A function that passes all tests but handles errors by swallowing them silently is worse than a function that doesn't compile, because at least the compiler error is honest.

Senior developers aren't less valuable. They're more leveraged. The gap between a senior engineer with AI tools and a junior engineer with AI tools is wider than the gap was without AI. The senior knows what to ask for and knows when the output is wrong. The ceiling didn't move. The skills that make senior engineers valuable are the same ones AI can't replicate.

The career path question

Here's the part nobody has a good answer for: what does a junior developer career path look like when the entry-level work is automated?

Junior roles traditionally existed as training grounds. You wrote CRUD endpoints, fixed CSS bugs, added form validation. Those tasks built intuition for how systems work, how code breaks, and how to debug when something doesn't behave. That intuition feeds the judgment that makes senior engineers valuable. The entry-level work wasn't just work. It was education.

If AI handles the CRUD endpoints and the form validation and the CSS bugs, the question isn't whether juniors are needed. It's how they develop the judgment that AI can't replace. The obvious answer is "they'll learn by reviewing AI output instead of writing code from scratch." Maybe. But reviewing code you don't fully understand is a different skill than writing it, and it's not clear it builds the same depth of understanding.

This is an open question, and I don't think anyone has an honest answer yet. The tools moved faster than the career structures adapted. Companies are still hiring for roles defined by the coding era while the work increasingly belongs to the building era. That mismatch will resolve, but how it resolves will shape the next generation of engineers.

What is developer marketing and why it exists

Mon, 02 Feb 2026 00:00:00 GMT

Developer marketing sits at the intersection of product marketing and growth marketing. You’re responsible for launches, messaging, and positioning, but also for how those decisions show up in campaigns, GTM, and adoption. The role owns the developer persona end to end and is accountable for both product-led and sales-led growth, not just shipping something.

The role runs in parallel with most marketing functions, from content and lifecycle to web, demand gen, and RevOps. The scope doesn’t stop at signups. You’re responsible for the full funnel, which means accounting for revenue, not just activation. If people sign up but deals don’t close, that’s still a problem to solve.

You’re also more technical than the average marketer. You’re closer to the product, the workflows, and the constraints, and you put developer trust first. Once that trust is lost, it’s hard to recover.

That combination is what makes developer marketing both exciting and difficult. The role comes with overlap, ambiguity, and frequent justification, especially in developer-first companies where everyone speaks developer and ownership is rarely clean.

Why this role exists at all

Most marketing is optimized to explain value at a high level. That breaks down when claims have to hold up under actual usage. Developers evaluate through workflows and constraints, and they notice quickly when something doesn’t.

Developer marketing exists because this kind of evaluation requires technical judgment before messaging ships. Someone has to pressure-test positioning against how the product actually behaves. Someone has to surface mismatches early, before they turn into sales friction, support tickets, or churn that no one planned for.

When that responsibility is missing, the gaps don’t disappear. They just move downstream, where they’re harder and more expensive to fix.

Why developer-first companies make the role harder to see

In companies built primarily for developers, developer context is everywhere. Marketing teams tend to be more technical and already speak to developers without translation. There’s a shared baseline for how developers think.

In those environments, developer marketing doesn’t always show up as a clearly defined function. The work spreads across teams. Parts of it live in product. Parts live in content, growth, or demand gen.

That’s where confusion starts. Not because the role isn’t needed, but because responsibility is diffused. Everyone contributes. No one is clearly accountable for how the product is framed and evaluated by developers end to end. The role doesn’t disappear in developer-first companies. Accountability just becomes harder to pin down.

Why technical chops matter more than familiarity with developers

There’s a difference between being adjacent to developers and having technical judgment. The first gives exposure and the second lets you evaluate whether something will hold up once it’s actually used.

Developer marketers need to be able to read content and recognize when something is glossed-over. They need to look at a demo and tell whether it actually holds up. They need to understand why a limitation matters before customers encounter it and turn it into a problem.

This isn’t about writing production code every day. It’s about understanding systems well enough to evaluate claims honestly. Familiarity with developer culture helps, but technical fluency is what makes the role effective.

What developer marketing is responsible for

Developer marketing is responsible for maintaining clarity and credibility with a technical audience, even when ownership across teams is messy.

In practice, that responsibility tends to show up in a few places:

Shaping positioning and framing so it reflects how developers actually evaluate tools
Validating that messaging aligns with development workflows, not idealized ones
Surfacing mismatches early, before they ship and become someone else’s problem
Representing developer reality consistently across product, sales, and marketing

This isn’t a checklist of tactics. When no one owns it, the gaps show up fast. Demos that fall apart under usage. Content that explains features but avoids constraints. Messaging that sounds right until someone tries to build with the product.

How developer marketing runs alongside other marketing functions

Developer marketing doesn’t replace product or growth marketing. In smaller companies, it often is product and growth marketing because one person owns the work end to end. As teams grow, the functions split out, but the responsibility doesn’t disappear.

In larger orgs, developer marketing becomes a coordinating role. Product marketing, growth, content, lifecycle, and RevOps have clear owners, but someone still has to keep the work aligned. Positioning has to match how the product actually works. Campaigns can’t get ahead of reality. Growth tactics can’t create downstream cleanup. That’s also why developer marketing experience scales into leadership. You’ve already had to own the whole system.

Developer marketing vs Developer Relations

Developer marketing and DevRel are often confused because they work with the same audience. They solve different problems. DevRel focuses on relationships, education, and feedback loops. Developer marketing focuses on clarity, positioning, adoption and revenue. There’s overlap in execution, but not in responsibility. They work best together. Things break when one is asked to replace the other.

Developer marketing in the AI era

The core responsibility hasn't changed. You still own trust, positioning, and credibility with a technical audience. But who that audience is and how they evaluate shifted. AI coding agents moved the constraint from writing code to describing what you want built. The people evaluating your product now include PMs, designers, and domain experts who build through prompts, not syntax. Developer content has two audiences now, humans and the AI agents helping them build. If your docs can't be parsed by an agent in Cursor or Claude Code, developers won't see your product at all.

I wrote more about this shift in End of coding, age of building.

How I think about being a better developer marketer

First, you should use the product. You should build with the thing you’re marketing. You should hit the same rough edges users hit and understand why they exist. It’s hard to explain limitations honestly if you’ve never run into them yourself.

Second, use AI aggressively, but deliberately. Automate repetitive work and invest in reusable tools, like a writing style guide or a Claude skill, so you’re not starting from scratch every time.

If you’re vibe coding, write instructions that explain what the generated code is doing. You should understand the structure of a codebase well enough to know where files live and how to update them manually if something breaks. Even if you work primarily in visual tools or AI editors, that baseline matters.

Build a sandbox. Have a place where you can play around with different dev tools and see how they actually behave. My site became my personal playground.

Learn from people who are close to the work and opinionated about it. I read an interesting question posed to potential hiring candidates, who do you think is doing marketing well? It made me run through the exercise and I think it’s important to follow folks who show their thinking, not just outcomes. Here are a couple folks that keep my wheels spinning, it a good way of course.

Hank Taylor - Developer Marketing Advisor, CodetoMarket
Morgane Palomares - VP of Marketing, Braintrust
Randall Degges - VP of AI Eng & DevRel, Snyk
Steve Sewell - CEO, Builder.io
James Hawkins - Co-CEO, PostHog

I keep most of this thinking written down so I don’t have to relearn the same lessons every time. I collect articles, threads, talks, and tools as gems. Over time, that gets distilled into my developer marketing handbook, which is where I capture how I approach personas, messaging, enablement, and GTM strategies when developers are part of the equation.

A note on how I actually apply this

I keep running into the same questions when I’m doing developer marketing work. What actually matters here? What’s noise? Where am I about to overcomplicate something or gloss over a constraint that will come back later?

One example is a Developer Marketing Claude skill I built that turns my developer marketing handbook into an interactive reference. I plan to use it to get oriented quickly and sanity-check decisions when I’m moving fast. It’s not meant to replace judgment or thinking. It’s there to reduce the cost of starting from scratch every time.

I’ve also published a developer marketing cheat sheet that pulls together roles and responsibilities, along with distribution channels and metrics. It’s intentionally lightweight and doesn’t require an email to download. If it’s useful, take it. If it’s not, ignore it.

What the job actually demands now

Doing this work well today requires more than knowing channels or tactics. It requires technical literacy, comfort operating between teams with unclear responsibility, and a willingness to be specific even when that means accepting tradeoffs. Most of all, it requires accountability for trust and revenue, not just reach.

What gets lost during leadership transitions

Fri, 09 Jan 2026 00:00:00 GMT

Over the past few years, I’ve seen the same pattern repeat across different companies, teams, and stages. It stopped feeling situational and started feeling structural. Leadership changes. Direction shifts. Teams reset. Then the same sequence plays out again.

I don’t think this usually comes from bad intent. Leadership choices shape the outcome in systems that reward visible change over durability. Over time, I started thinking about it as a flywheel. Not a formal model, just a way to explain why the same behaviors reinforce each other and keep repeating.

A pattern I keep seeing

It usually starts the same way. A new leader joins with a mandate to fix things. Expectations are high, time is limited, and the organization wants to see movement quickly. There’s pressure to create clarity and confidence, both internally and externally.

That pressure shapes the first decisions. Change becomes the most visible signal of ownership. Direction gets reset, priorities get reshuffled, and the org starts moving before there’s full context on why things look the way they do.

What follows is consistent enough that it’s hard to ignore:

A rebrand or reset of priorities
A restructure to match the new direction
People exit, sometimes by choice, sometimes not
New roles open that look a lot like the ones that were removed

Within a year to eighteen months, leadership changes again. The next person inherits a partially reset system, and the cycle starts over.

The leadership flywheel, as I see it

I think of this as a leadership flywheel because each step reinforces the next. New leadership enters under pressure to show progress. Visible change signals momentum. Structural and team changes follow. Outcomes take time. Leadership tenure runs out before those outcomes fully materialize.

The flywheel keeps moving not because anyone wants disruption, but because motion is easier to measure than durability. The system rewards visible change more than sustained execution.

Why leadership transitions often start with change

From the outside, change reads as action. From the inside, it often reads as necessity. New leaders inherit teams they didn’t build and strategies they didn’t choose. There’s limited trust in inherited context and little patience for slow understanding.

Resetting direction, structure, or messaging establishes ownership and creates distance from what came before. The issue isn’t that change happens. It’s that change becomes the starting point instead of the result of learning.

What gets lost first

The earliest losses are quiet. Context disappears. The reasoning behind past decisions fades. Work that was in motion loses sponsorship and stalls, not because it failed, but because no one is left to carry it forward.

Each transition removes another layer of institutional memory. Over time, teams stop assuming their work will compound. They expect it to be revisited.

What gets lost over time

As these transitions stack, the cost becomes harder to ignore. Strategy turns into something that’s constantly reworked instead of built toward. Teams get cautious about long-term bets. Confidence in direction erodes, even when the direction itself is sound.

People adapt by narrowing scope and shortening time horizons. Not because they lack ambition, but because they’ve learned what survives resets and what doesn’t.

The professional impact no one plans for

Leadership transitions don’t just reset strategy. They reset careers. Performance gets evaluated by managers who weren’t there for the work. Progress has to be re-explained. Advocacy disappears when leaders leave, often through no fault of the people they supported.

Growth becomes uneven. Not tied to output or impact, but to timing. This is one of the harder realities to talk about without sounding bitter, but it shapes how people experience their careers more than most organizations acknowledge.

I’ve experienced this firsthand, including situations where positive reviews, bonuses, and pay adjustments existed right up until a leadership change reset the narrative. In those moments, the work didn’t suddenly stop delivering. What changed was how success was defined and which outcomes mattered.

A leadership assumption worth challenging

Teams often get labeled as underperforming when the real issue is instability. Work doesn’t fail because the people were wrong for the role. It fails because the system never gave it time to land.

Strategy gets blamed when continuity was the missing ingredient. Changing players is easier than stabilizing the field, but it rarely addresses the underlying problem.

Entering a team without restarting the cycle

There’s another way to enter an organization, though it’s slower and less visible. Spend time with the team before reshaping it. Separate inherited issues from structural ones. Learn what’s already been tried and why it stalled.

Most teams don’t need to be replaced. They need space to operate without being reset every year. This doesn’t mean avoiding change. It means earning it.

Living inside leadership transitions

For people inside the system, there’s no clean answer. Some leave early. Some stay and adapt. Some get reshaped into roles they didn’t come in to do. Occasionally, a leader arrives who builds with what’s there instead of tearing it down, but you can’t plan on that.

What you can plan for is the reset.

You shouldn’t assume your previous performance reviews will be read. You shouldn’t assume context will carry forward. You shouldn’t assume the work you did speaks for itself once the people who sponsored it are gone. That’s frustrating, and it’s draining, but it’s also the reality of how often leadership changes.

Writing things down helps more than people want to admit. Not as self-promotion, but as continuity. Capture what you worked on, why it mattered, what changed because of it, and what didn’t get finished. Keep a record of decisions, outcomes, and tradeoffs while the context is still fresh.

This isn’t about selling yourself constantly. It’s about not starting from zero every time the org resets.

Over time, these notes become your own internal handoff doc. They make transitions survivable. They give you a way to ground conversations when direction shifts again. They help you advocate for your work without relying on memory or missing context.

You can’t stop the leadership flywheel alone, but you can make sure it doesn’t erase your contribution every time it turns.

Can a modern website run on Markdown + AI alone?

Mon, 15 Dec 2025 00:00:00 GMT

A debate surfaced over the weekend about whether teams still need a CMS at all. The idea is simple. If AI can draft content, migrate files, clean up structure, and commit everything to your repo, maybe you don’t need a content system. Everything becomes Markdown. Everything lives in Git. AI handles the busywork.

It’s a compelling argument for code-first teams.

But the real question is bigger.

Can an entire production website be built and maintained this way, or are there parts of a CMS that AI and Markdown still can’t replace?

And once you widen the scope to the whole website, a third option starts to matter too: visual development.

Here’s how these models actually compare.

The argument for Markdown and AI

Markdown has always been appealing to developers. It’s simple, local, versioned, and transparent. With AI acting on files the same way developers already do, a lot of friction disappears. You can:

draft content in your editor
use agents to clean up structure
generate frontmatter
fix formatting
reorganize folders
handle bulk changes
commit and deploy without leaving your flow

For a fully technical team, this model feels clean. There are no CMS dashboards to maintain, no API layers to wire up, and no separate content environments to manage. Everything lives in one place, and automation handles the repetitive work. It’s a real advantage for teams that operate entirely in code. But it also assumes something important: every contributor works like a developer. And most websites aren’t run that way.

Where Markdown starts to fall short

Markdown works well when content is simple and the team is small. That’s why some engineering-led teams can run it without friction. But once a website becomes a system instead of a collection of documents, Markdown introduces gaps that aren’t obvious until you hit them.

Some websites genuinely don’t need structured content, workflows, localization, or a cross-functional editing model. If your site is simple and your team is entirely technical, Markdown can work fine. But if your website relies on these capabilities, getting them in a Markdown workflow means building and maintaining them yourself.

Here are the big ones.

1. No structured content model

Some sites don’t need schema-level modeling. Many do. Production sites often rely on:

fields
types
relationships
reusable fragments
shared data across many surfaces

Markdown doesn’t enforce any of this. One missing field can break pages. One inconsistent value can break queries.

You can bolt on schema validation, but at that point you’re recreating parts of a CMS.

2. No safe editing environment

Markdown works for engineers. It doesn’t work for non-technical contributors. Even if AI generates the files, someone still ends up reviewing diffs or dealing with frontmatter.

Supporting broader teams means building:

internal UIs
guardrails around edits
validation layers

Otherwise, you're asking non-technical contributors to operate in Git.

3. No preview tied to actual components

Some engineering teams already maintain strong preview systems. Most don’t.

Without one, a Markdown file can’t show:

how a component renders
how content interacts with layout
how changes ripple across a page

You only see the real outcome after a build or preview deployment.

4. No built-in workflows

Websites need:

approvals
version history
scheduling
role-based access
localization
multi-surface consistency

Markdown doesn’t support this. Reproducing it means building bots, branch rules, and CI automation to simulate editorial workflows.

5. No shared space for collaboration

Markdown keeps contributors split across tools:

developers in Git
designers in Figma
marketers in docs
reviewers in comments elsewhere

There is no shared environment for the website itself. Markdown is simple until the website isn’t.

Can AI agents solve this gap?

AI agents can automate a lot inside a Markdown workflow. They can generate files, rewrite content, reorganize structure, migrate documents, clean up frontmatter, and handle several repetitive tasks developers used to own.

But agents don’t replace the systems that keep a full website consistent and safe.

To match what a CMS provides, AI agents would need to handle:

schema enforcement
field validation
relationship modeling
reference checks
localization parity
role-based permissions
publishing controls
approvals and sequencing
preview environments
multi-surface consistency

AI can help with pieces of this, but it can’t be the system.

To get all of these capabilities in a Markdown world, you’d need to build:

your own schema engine
your own validation pipeline
your own preview pipeline
your own workflow and approval model
your own contributor UI
your own localization framework
your own content governance rules
your own automation to prevent destructive edits

At that point, you’re not “avoiding a CMS.” You’ve built one. AI assists the work. It does not replace the infrastructure that coordinates it. This is the distinction most people miss.

The argument for a CMS

A CMS solves the problems Markdown can’t. It gives you structure, validation, workflows, and a safer way for non-technical contributors to manage content without touching code.

People don’t write inside the CMS. They publish inside the CMS.

That’s the important distinction.

Even if AI drafts and rewrites content, the CMS provides:

a consistent schema
a place to enforce rules
a predictable workflow
a safe environment to update live content
a shared model for content relationships
clear separation between editing and code

That’s why CMSs exist.

Not because writing is hard, but because maintaining content across teams requires structure that Markdown doesn’t provide on its own.

But CMSs are not perfect either. They can feel disconnected from the real site. They often separate content from layout. Editors can break things. API layers add overhead. Preview systems vary in quality.

So even though a CMS solves real coordination problems, it introduces friction in other areas.

This is why a third model matters.

The case for visual development

Visual development sits between Markdown and a CMS. It treats the website as a full system, not just content or code. It gives teams a shared environment with structure built in.

In a visual development model:

developers define components, logic, and structure
designers work directly in the real layout
editors update content inside the same system
schema and relationships stay consistent
content and layout stay aligned
AI operates with awareness of the actual components and fields

It removes the separation between:

content and layout
authors and developers
code and preview
structure and design

Markdown doesn’t provide this.

Headless CMSs rarely provide this.

And the role of AI changes completely in a visual development system. AI isn’t generating files in a vacuum. It works inside the actual structure of the site. That means:

AI site builders generate real pages using real components
AI visual editing adjusts layout, spacing, and structure with context
AI app scaffolding uses actual data models and extension points

AI doesn’t sit on the side. It participates in the system.

Visual development builds the website as one environment instead of splitting it across tools.

This is the gap Webflow fills.

ℹ️ Some platforms even combine visual development with Git-based workflows, like Builder.io's Fusion approach, which shows there’s real demand for visual editing that still fits into an engineering-centric versioning model.

So what does a team lose moving from a CMS to Markdown?

You lose:

schema enforcement
relationship modeling
predictable workflows
safe editing environments
shared context across teams
reliable previews (unless you maintain your own preview system)
localization pipelines
role-based permissions
structured publishing
cross-page consistency

You can rebuild some of this, but now you’re maintaining a custom system that grows in complexity as your website grows.

What a team gains by going Markdown-first

You gain:

full developer control
simpler architecture
fewer systems
automation through agents
transparency through Git
lower overhead

It’s a strong option for small, fully technical teams with simple content needs and tight ownership over the site.

It’s not designed for companies with cross-functional contributors or evolving structure.

What visual development offers instead

Visual development isn’t trying to be Markdown. It isn’t trying to be a CMS either.

It offers:

structure like a CMS
flexibility like a codebase
real layout context like a design tool
shared collaboration across roles
AI that works inside the true structure
developer extension points when needed

It’s the only model where the website stays a single source of truth for everyone.

Developers keep control. Designers keep fidelity. Marketers keep clarity. AI doesn’t act blindly. That’s why visual development matters in this debate.

The simple way to think about it

Markdown + AI

Great when the team is fully technical and the site structure is simple.

CMS

Great when content structure, governance, and shared responsibility matter.

Visual development

Great when a website is treated as a unified system where design, content, development, and AI all work together with real context.

Inside my developer marketing stack

Mon, 24 Nov 2025 00:00:00 GMT

Every builder has a rhythm to how they build. For me, that rhythm lives somewhere between code and content, the overlap where developer marketing happens. These tools help me stay organized, move faster, and keep projects on track without overcomplicating the work.

IDE

Cursor is now my main workspace after years in VS Code. They share the same foundation and extensions, but Cursor feels like where things are moving.

Same integrations and ecosystem as VS Code
Familiar setup that just works
AI that’s advancing faster than VS Code, which is surprising since GitHub built Copilot first
I pair it with Claude Code in the terminal for context, explanations, and large-scale debugging when I need deeper insight

It’s less about what’s new and more about pace. Cursor feels like it’s evolving while VS Code feels like it’s coasting.

AI chat tools

ChatGPT is my go-to for projects, building custom GPTs, and setting up connectors or integrations. I also use it for content curation when I’m gathering examples or early research.

Gemini handles search and visual creation. Its new Nano Banana feature makes generating visual references surprisingly quick.

Right now, both tools serve different purposes, but my guess is Gemini eventually edges out OpenAI. We’ll see.

Design and visual thinking

Figma is where I build and prototype designs. I don’t use its AI features, they’re still behind the curve. What makes it useful is how quickly I can move from layout ideas to something ready for production. Components, variables, and shared libraries keep everything consistent without extra effort.

Excalidraw is where I whiteboard. I sketch flows, map systems, and rough out diagrams before anything formal. A cheat code I use is generating Mermaid diagrams in ChatGPT to get a starting point, then rebuilding them in Excalidraw to make them clearer and more visual.

Analytics stack

A big part of developer marketing is understanding how people use what you build. These tools help turn product usage into insight.

PostHog for web analytics, event tracking, and session replay
FullStory for journey mapping and deeper behavioral insights
Sigma for the full view, from lead tracking to closed-won pipeline reporting
Looker for clean visualization and quick summaries

There isn’t one analytics platform that does everything well. A mix is usually the reality, and this is the combination that works for me.

Marketing and SEO stack

This is the set of tools I rely on to manage search, automation, and content performance. Each one plays a different role, from tracking technical SEO to finding new opportunities and testing campaigns.

Ahrefs is my go-to for monitoring technical SEO, tracking backlinks, and doing competitive keyword research or content gap analysis
SurferSEO helps grade keyword-focused content and tighten on-page structure before publishing
Google Keyword Planner is great for generating new ideas based on topics or URLs and gives solid monthly search volume data
Google Ads still earns its place, paid search still works, especially in developer marketing where people search everything (even Bing)
AirOps is a newer tool I’ve been using for automation workflows, from competitive intel to content research, all built through AI
Buffer is my social tool of choice, mainly because its free tier goes further than most and supports multiple platforms without friction
Common Room helps track and understand community activity across social, forums, and other developer channels.

This stack helps me connect research, creation, and distribution. It’s about staying close to what works and improving a little with each iteration.

Sales and enablement stack

This is where product knowledge turns into enablement.

Gong for reviewing customer calls and spotting themes that shape positioning and messaging
WorkRamp for internal education and onboarding content, keeping sales and marketing aligned on what’s new
Figma Slides for building presentations with real design flexibility. It feels like designing, not fighting templates.
Arcade for creating interactive product demos that help explain features in context without heavy editing or production time

They keep information flowing and teams aligned on what actually matters, the customers using the product.

Collaboration stack

Collaboration works best when it’s async, not noisy.

Notion is where I write everything, content drafts, specs, notes, and ideas. It’s underrated for collaboration and perfect for pulling in code snippets or assets. People think they need Google Docs, but they’re wrong.
Airtable is a dream for anyone who loves spreadsheets. It’s flexible, visual, and great for tracking content and projects. I’ve been a fan since day one, even if not everyone adopts it.
Slack is the only real choice for team communication. I live and die by the save-for-later feature, and the new canvas tools are great for organizing thoughts. Don’t at me with Microsoft Teams.
Loom is the best way to explain anything on video. It’s perfect for walkthroughs, feedback, or education. The editing tools are ok, not Descript-level, but work well enough. The AI still has some catching up to do.

This stack makes it easy to share work, document ideas, and keep everyone aligned without the constant back-and-forth.

Developer and Data Stack

This is where projects take shape.

GitHub for version control and collaboration
Supabase for quick databases and APIs
Vercel or Netlify for deployments
Warp for a cleaner, more visual terminal

It’s a reliable setup that scales smoothly and keeps development fast without adding unnecessary infrastructure.

Closing Thoughts

These tools have stuck because they make the work smoother. They cover everything I need to build, write, and collaborate without slowing things down.

The stack will keep changing, but the goal won’t.