Open Reader

I Vibecoded This Feature Using Codex

completed 12:50 Jul 17, 2026 Watch on YouTube

Current Status

completed

Video ID

u_3q5rMkAds

RAG / Chat

Enabled
I Vibecoded This Feature Using Codex
Description

Senior editor Jack Cheng wanted paid Every subscribers to be able to share full articles with anyone. The feature wasn’t high enough on the roadmap to ask an engineer to build it, so he researched the idea, pointed Codex at Every’s codebase, and shipped it himself. Jack joins Austin Tedesco and Kate Lee to walk through the research, internal buy-in, guardrails, implementation, and analytics behind gift links. They also explain how AI coding tools let editorial and growth teams test more ideas without pulling engineers away from larger projects. Every is the most AI-native startup on the internet. Through ideas, software and education, subscribers get the tools to work at the frontier of AI. Start your free trial today: https://every.to/subscribe?utm_source=youtube Follow Every: https://x.com/every Timestamps: 00:00 How knowledge work is changing 01:43 What Jack built 02:03 From idea to experiment 10:22 Let the data decide

Summary

Generated by gpt-5.6-terra

At-a-Glance

  • Verdict: Watch fully
  • Core thesis: AI coding agents let non-engineering teams ship previously deprioritized product experiments without consuming scarce engineering capacity, provided leadership sets business and technical guardrails and measures the result.
  • Why it matters: The video offers a concrete operating model for turning agent-assisted coding from an individual productivity tool into a controlled, cross-functional experimentation capability.
  • Best use: Use it to inform a lightweight self-serve shipping model: let domain experts propose, build, validate, instrument, and iterate on bounded experiments while engineering retains responsibility for core systems and risk boundaries.

Executive Summary

Every's editorial team shipped a paid-subscriber “Giftlinks” feature—links that allow non-subscribers to read an otherwise paywalled article—after an editorial employee identified the need from personal use and media-consumption habits. Historically, the idea would have required a growth prioritization decision and engineering roadmap capacity, and likely would have been deferred as a low-priority feature.

Instead, the employee used an AI agent pointed at the existing codebase to investigate whether related functionality existed, used ChatGPT deep research to prepare a case for the experiment, and used Codex to implement the feature. The proposal included how Giftlinks work elsewhere, what implementation would require in Every's environment, and what success metrics should be tracked.

The central organizational shift is not that every idea becomes strategically important. Rather, leaders can permit low-cost exploration if the work is bounded by clear constraints: it must not break the site, unintentionally expose paid content, or undermine the primary business objective of MRR growth. The head of growth remained skeptical that Giftlinks would increase revenue, but supported shipping because the downside could be monitored and the cost of testing had fallen sharply.

The speakers argue that this model frees the primary engineer for high-leverage work while giving editorial staff greater agency over the CMS and workflows they use daily. They emphasize instrumentation through PostHog and letting actual user journeys determine whether to scale, adjust, or disable the experiment. Their practical advice is for non-engineers to build confidence on personal projects before attempting production pull requests.

Key Takeaways

  • Claim: Agent-assisted development changes prioritization from “is this worth engineering roadmap capacity?” to “can a motivated owner safely ship and measure this within guardrails?” | Evidence: Giftlinks was described as a P3/P4-style nice-to-have relative to other growth work and would ordinarily have required coordination with Andre, the engineer who manages a full site roadmap. With Codex available, the team allowed the editorial owner to build it instead of waiting for formal prioritization. | Implication: Ken can create a separate lane for bounded, reversible agent-built experiments so useful local improvements do not compete directly with core-platform or strategic engineering work. | Caveat: This does not remove the need for priorities; leadership explicitly retained guardrails around MRR growth, site stability, and paywall integrity.
  • Claim: Domain experts closest to users can generate worthwhile product and growth experiments that centralized roadmaps systematically underweight. | Evidence: The feature originated from an editorial employee wanting to share Every articles with readers of a personal newsletter, plus observing Giftlinks used by publishers such as the New York Times, Wall Street Journal, and blogs like Jason Kotke's. | Implication: Empower teams that live in customer-facing systems to identify and prototype friction points, while requiring a measurable hypothesis rather than treating every request as a committed product investment. | Caveat: Closeness to the workflow creates ideas, not proof of business value; the head of growth explicitly doubted Giftlinks would generate incremental revenue.
  • Claim: A credible AI-enabled experiment still begins with a structured case, not merely prompting an agent to code. | Evidence: Before implementation, the owner asked ChatGPT to research Giftlink effectiveness, assess what Every would need to implement it given the site and codebase, and specify what should be tracked; the resulting report was shared with growth and editorial leadership. | Implication: Require experiment owners to produce a compact agent-assisted brief covering external precedent, implementation scope, risks, ownership, and success/failure metrics before they receive permission to ship. | Caveat: The transcript does not provide the research findings or quantify expected conversion lift, so the report supported decision-making rather than validating the economic case.
  • Claim: AI agents can be used as a first-pass control layer for implementation risk, allowing leaders to focus on the business constraints they actually own. | Evidence: The head of growth gave Codex the implementation plan and asked whether it would break anything or accidentally give away content for free; Codex's answer was used to backstop the concerns about website safety and paywall leakage. | Implication: Use agents to generate risk analyses, test plans, and change reviews, but establish escalation thresholds for sensitive surfaces rather than relying on an agent's “no” as final approval. | Caveat: An agent’s assurance is not equivalent to formal security review, testing, or human code review—especially for authentication, authorization, billing, or broad data-exposure paths.
  • Claim: The economic value of cheap shipping is that organizations can replace internal debate with instrumented market learning. | Evidence: Rather than resolving whether Giftlinks would improve MRR in a meeting, the team plans to track Giftlink redemptions, free-subscriber acquisition, and conversion from free to paid using PostHog dashboards; they would scale it if it drives paid conversion or turn it off if it harms paywall conversion. | Implication: Design every self-serve feature release with predeclared stop/scale criteria, event instrumentation, and a reversible rollout path; otherwise cheaper building can simply create more unmeasured complexity. | Caveat: The transcript offers no actual post-launch data, so Giftlinks remains an unvalidated experiment rather than evidence that the strategy works.
  • Claim: Personal agent-coding projects are a practical training ground for non-engineers to gain the confidence needed to contribute safely in production. | Evidence: The speakers recommend building a personal CMS or other private projects, trying different models and tooling, and repeatedly shipping pull requests before doing so at work; one speaker says personal-project successes reduced anxiety about an engineer judging production PRs. | Implication: Create low-stakes sandboxes and internal practice repos so operators can learn agent workflows before receiving production access or responsibility. | Caveat: Personal-project learning does not teach all production concerns, including organizational review requirements, security controls, operational ownership, and rollback discipline.

Detailed Brief

Giftlinks as a controlled paywall-growth experiment

  • Claims: Giftlinks intentionally trade some access to paid content for possible top-of-funnel reach, social proof, free-user acquisition, and eventual paid conversion.; The editorial team considers the feature a consumer-standard capability for subscription media, not merely an internal workflow convenience.; The team frames the launch as an iterative experiment rather than a one-time feature specification.
  • Evidence: On article pages, paid subscribers see a “share full article” control, can see their available number of Giftlinks, and can copy a link for a non-subscriber.; The team specifically plans to observe whether articles with Giftlink redemptions convert readers and whether the feature drives free subscribers who later become paid.; The stated operational loop is: release, inspect early data, refine or tweak, collect more data, and decide from observed user journeys.
  • Caveats: Allowing subscribers to share paywalled material can cannibalize direct paywall conversions; the transcript does not specify rate limits, fraud controls, expiry rules, or attribution design.; The speakers distinguish between freeing engineers from smaller workflow improvements and eliminating engineering involvement altogether; the latter is not claimed.
  • Implications: Subscription businesses can test access-flexibility mechanisms without precommitting to a broad paywall strategy, but must make the permission model and reversal mechanism explicit.; The critical operating asset is not just agent access; it is an experiment platform that makes usage, conversion, and downside visible quickly.

Management model: constrained autonomy rather than centralized permissioning

  • Claims: The head of growth describes a personal shift away from protecting engineering resources through centralized gatekeeping and toward enabling trusted teammates to run bounded experiments.; Editorial teams can become partial owners of the systems they use most, rather than remaining fully dependent on an engineer for every local improvement.; AI tools make organizational trust and comfort with delegated work a more important bottleneck than raw implementation capacity.
  • Evidence: The head of growth says the best organizational investment is infrastructure that lets anyone with editorial or product experiment ideas ship quickly.; The editorial speaker says that, historically, even daily CMS pain points often could not justify a request because the impact appeared limited to one person.; The group repeatedly characterizes the cultural adjustment as becoming less of a control freak and turning work over to agents and teammates.
  • Caveats: The approach assumes employees can access the relevant codebase and have sufficient context to use agents responsibly; the transcript does not address access control, branch protection, or review policy.; A proliferation of individually shipped features can create UX and maintenance debt if teams do not establish ownership and retirement rules.
  • Implications: Ken should treat agent enablement as an operating-model redesign: clarify who may ship, what they may alter, which checks are automated, and who owns an experiment after launch.; Core engineers can be redeployed toward high-leverage architecture and reliability work only if the self-serve lane has explicit quality, observability, and lifecycle controls.

Notable Concepts & Terms

  • Giftlinks: Subscriber-issued links that let non-subscribers access paywalled articles; used here as a potentially viral acquisition and conversion experiment.
  • Codex: The coding agent used to inspect the codebase, implement the feature, and provide a first-pass assessment of whether the planned change could break the site or expose content.
  • Opus: Named alongside Codex as part of the broader AI-tool availability that makes non-engineers capable of attempting previously impractical builds.
  • PostHog: The analytics product the team intends to use for dashboards and tracking of redemption, subscriber, and conversion behavior.
  • MRR: Monthly recurring revenue; the head of growth’s primary business guardrail and reason for skepticism about the experiment.
  • P0/P1 vs. P3/P4 prioritization: The contrast between urgent, roadmap-worthy work and lower-priority enhancements; agent tooling makes lower-priority work more feasible without displacing critical work.
  • Bounded experiment: A reversible release permitted because its technical and business downside is constrained, observable, and tied to explicit measurement.

Operator Notes / Why Ken Should Care

  • Define a self-serve experiment policy with allowed surfaces, prohibited surfaces, required reviewer roles, rollback expectations, and an ownership/retirement rule for shipped features.
  • Create an agent-generated experiment-brief template requiring: user problem, external precedent, implementation plan, risk analysis, instrumentation events, expected upside, and stop/scale criteria.
  • For any experiment touching entitlement or payment boundaries, require deterministic authorization tests and human review in addition to agent-based codebase analysis.
  • Provision a sandbox or practice repository for non-engineering operators to learn prompt-to-PR workflows, testing, and rollback before granting access to production-adjacent code.
  • Audit whether the current analytics stack can attribute a shared-link event through redemption, signup, activation, and paid conversion before approving similar growth experiments.

Source/Metadata

  • Title: I Vibecoded This Feature Using Codex
  • Transcript words: 2733
  • Duration seconds: 770
  • Timestamp note: No timestamps or chapter markers were present in the supplied transcript.

Transcript

2466 words en Processed in 256.1s

I wouldn't have even attempted to build something like this. But because we have Codex, because we have Opus, Austin, you were, this is not something that is a priority for the growth team, but if you wanted to just go ahead and do it, point Codex at it, just have it do it, go ahead. It was a really pivotal moment in us being able to actually do Giflinks. How we work is changing, right? This is a great example of the way in which work is possible, especially for knowledge workers like us, is dramatically different now. You have the tools to do almost anything you want at your disposal now. And it gives you the ability to do your main job better and very well. And it also gives you the ability to play and explore. And I think, looking at how this previously would have gone, you would have been, Oh, I see this problem. I would love for us to have Giflinks. You would probably come into me and be, I think this should be a growth experiment or the engineering team should build this. I would have said, good idea. It's not a priority on our roadmap. Let's do this later. And instead, you were just, I can just have an agent go, go do this. You no longer have to think about as much, is everything that someone's excited about a priority on the roadmap, and more, or do we have the systems in place for people to ship something they're excited about? And if they are, this is what it looks like to just be, go run at it. So what we have done is the editorial team have shipped Giflinks on the site for paid subscribers. When you go to an article page, you can actually see this new button called share full article. You can click it, and it'll let you know how many Giflinks you have and let you copy a Giflink to share with folks who are not paid Every subscribers. So how this started was I was scratching my own itch. I have a personal newsletter, and I often want to share things with my readers that aren't paywalled. There were a couple of pieces that I wrote on the Every site that I wanted to share with them without the paywall. The other thing I noticed was that a lot of my favorite blogs, Jason Kotke's blog, they'll only share paywalled content that uses Giflink to share it. Part of me was wondering, if we're trying to grow our subscriber base, are we limiting ourselves and limiting the ability of our articles to go viral? I started interacting with my AI agent. I pointed it at our code base, and I was, tell me what we have already on Giflinks. Do we have anything like that? Next step from there was who did I need to get buy-in from across the company in order to do this? I knew that it was tied to Austin in terms that it would be a growth experiment. I knew that Kate had to be a big part of this because she's the editor in chief. And then I also knew that I had to come to you guys with a convincing argument that this is something we should even try. So what I did was I had ChatGPT do deep research about Giflinks and about their effectiveness and pull together a comprehensive report about all of that. But then also about, if we were to implement it, knowing the site and the code base for the site, what would we have to set up to implement it? What would we want to track to make sure that we're measuring success? And so I put together that report, and I sent it to both of you. And I think this is where what we did with Giflinks maybe diverges from the way that this would have worked in the past. Austin, you looked at the report and you were, this is great. At the same time, we have all these other growth experiments that are a higher priority level. Before coding tools, AI agents, it might have just there, right? Jack, when you mentioned it to me, of course, it was a feature I'm intimately familiar with and use all the time myself. I'm frequently sending Giflinks with reporting from the New York Times or the Wall Street Journal. It always felt like something that would be a really nice to have. But knowing from my own perspective, sitting on the editorial team, typically the way that it has worked is that we have an engineer, a fantastic engineer, Andre, who manages our site. And he has a really full roadmap and he has a lot of priorities. And getting on that roadmap requires a lot of coordination and a lot of resource and planning on his part. Knowing how burning some of the issues are that we do need to be attending to on a day-to-day basis, it was a little hard to imagine how we would make this the case for this. More of a P0 or P1 priority as compared to a P3 or P4. Yet again, these are things we wanted to have. We are a media organization in addition to a producer of software. We want to be up to snuff with other organizations. And that is a habit that consumers know. And Jack very cogently made the case in a really complete document of what it is, how other sites do it, what the potential lift in growth could be, and what it would require to actually implement it. So my perspective on this is that I'm an enormous control freak. And I've also worked in paid subscription media my whole career. And I feel like a thing that I am quite used to is the people making the contents having a strong, strong desire to give it away for free so that more people can consume it. But the other thing that I experienced a lot at Every is that people get really excited about stuff and want to try stuff and want to experiment with different things. And a thing that can happen a lot here is that we get distracted and we can get off of what is the actual main thing we're trying to do that's going to help us achieve our goals? It's both a really good thing at Every because the only way this place works is people like to play and experiment and try new stuff. But it's been a transition for me coming here because I am someone who's, I see a goal. I frankly just want to focus on it and make it happen. And so you can actually see here that Jack, you messaged me this of, I think I want to do this. And what I'm basically telling you is don't waste my time with this. That's really my response, me being, interesting, right? A gift link is really thinking about how do we work with the trade-off of giving away a piece of content for free in order to potentially drive top-of-funnel and then mid-funnel journeys for net new users and social proof and sharing to potentially drive new free subscribers and eventually new paid subscribers. And I was, of the many things we can do that will increase our MRR, this is very low on the list of things that I think will work or are worth our time. And so you can actually see here that Jack, you messaged me this of, I think I want to do this. And what I'm telling you is don't waste my time with this. That's really my response, me being like, interesting, right? A gift link is really thinking about how do we work with the trade-off of giving away a piece of content for free in order to potentially drive top-of-funnel and then mid-funnel journeys for net new users and social proof and sharing to potentially drive new free subscribers and eventually new paid subscribers. And I was like, of the many things we can do that will increase our MRR, this is very low on the list of things that I think will work or are worth our time. The cool thing that's possible now is that you took that and you were able to then be like, hey, I have a plan. And you brought the plan and you shared it in Slack. I shared your plan with Codex, and all I asked it was, is this going to break anything, or is this going to give away a bunch of content for free that I don't want to? I am backstopping it against the things that I really care about. And Codex said no. It's a change in how I think companies with smart, creative, ambitious people can operate, where I can say, okay, these guardrails are in place for the thing that I'm responsible for, which is MRR growth. And also the guardrails are in place that you can test this and try this without breaking the website. It's actually an important growth moment for me in how I work, to say, okay, as long as I trust the people I work with, understanding we have all these tools at our disposal now to do anything. It's actually much better to let people run at the thing they're excited about and try it, as long as the systems are in place to do this work really well. And it's been a good insight for me and the rest of the growth team to be like, actually, the best thing we can do is build the infrastructure for anyone on the team who has these cool ideas around editorial experiments and initiatives, product experiment initiatives, to just quickly ship stuff they're excited about because they're close to it. You two are avid consumers of media and paywall media. [SPEAKER_03] You're going to naturally get really good ideas that might be great for the business. And rather than how I've worked before at previous companies, where you're really protective of your resources, you're really protective of your engineering time here. [SPEAKER_03] I think the best thing we can do is be like, great, not just ship it, but you know how to ship it, right? And we know how to see if it's harming something important. And it's actually going to make us go a lot faster and work a lot better. [SPEAKER_01] So proud of you for this growth moment, head of growth, Austin. [SPEAKER_03] A lot of AI stuff has been like, all you have to do is be less of a control freak, and everything— Out of your comfort zone. [SPEAKER_03] Will be better. [SPEAKER_03] Yeah, yeah. [SPEAKER_03] Turn over work to your agents and your teammates. I think what's interesting too from that perspective of control and where the work gets done is, from an editorial perspective, we are the ones who are most heavily in the CMS, making sure pieces are produced to the highest level of our standards every day. And yet historically, we have the least facility with using it or with changing it or building it. I've thought of myself, at least, as being at the mercy of an engineer who, the features that they're going to build likely are going to be the ones that could have the greatest impact on the greatest [SPEAKER_01] number of users. [SPEAKER_01] And so if it's something that is a small pain point for me, even if it's something I experience every day, it may not be a priority because it's just not going to impact anyone other than me. [SPEAKER_01] I should clarify, GIFT links is not that category of feature, but that is typically how the relationship between an editorial team and an engineer who maintains a website has gone. [SPEAKER_01] It's been really refreshing to see that is something that we can have a little bit more of a hand in and a little bit more control over. [SPEAKER_01] And, by the way, free up our engineer to work on really big projects and really big things that may have an outsized impact, and that he doesn't need to be on the level of the things that are going to maybe help our workflow in some ways. Frankly, I still remain extremely skeptical. This will make us any more money. I really do. But I'm so happy we never had to have that argument. This is, I think, the first time we've ever talked about my opinions on this thing, which is really good. Because ultimately what this allows for is to just let the data show us, right? [SPEAKER_03] The data will show us now either this is driving a lot more free subscribers who become paid subscribers and we should scale this. [SPEAKER_03] Or it might show us that we have paywalled pieces that actually have GIFT-link redemptions that are converting, and we can turn it off. [SPEAKER_03] And it's so much better to just see this stuff play out with the user journeys and with the data rather than, which I think we've all done much before, us being in a meeting and me being like, this won't work. [SPEAKER_03] I don't want to waste time on it. [SPEAKER_03] And you being like, I actually think we should do it. And as we're collecting more data, I can also very easily just be like, hey, Codex, tell PostHog to set up these things on the dashboard. Start tracking these things. So it's something that is less of this thing where, okay, we wrote this huge spec around it and got all the buy-in and shipped it. [SPEAKER_02] And more truly an experiment, we'll put this out. [SPEAKER_02] We'll see what we learn from the early data. [SPEAKER_02] We'll refine it. [SPEAKER_02] We'll tweak it. [SPEAKER_02] We'll collect more data and we'll go from there. [SPEAKER_00] Yeah. And also a good reminder too, to be like, if you've literally never done something like this before, if you work in the spaces that we work in. And it feels too scary to ship PR to the website for your company, which it did for me for a long time too. Play around with a personal project, right? Jack, you built your own version of Codex, which is nuts. If you work in editorial and you want to try this, you can actually just build your own CMS, right? You can just ask it to build your own CMS and then push PRs to it. I think building up that confidence is important and finding a personal project to try this with so that you feel more confident and comfortable to do it. [SPEAKER_03] Both to do it at work and then to do it in front of people. [SPEAKER_03] Every time I ship a PR, I'm like, Andre is going to come at me and be like, this is the stupidest thing I've ever seen. [SPEAKER_03] And shipping enough stuff on my own personal projects that actually works is incredibly helpful. [SPEAKER_03] And I think I would encourage everyone. [SPEAKER_03] I have a few personal projects that I don't even really share with anyone, but I try new models on them and I try new tooling on them because it gives me a much better sense of what I can actually do at work, which is also really helpful. Yeah. [SPEAKER_03] To do it both at work and in front of people. [SPEAKER_03] Every time I ship a PR, I think Andre is going to come at me and say, "This is the stupidest thing I've ever seen." [SPEAKER_03] Shipping enough stuff on my own personal projects that actually works is incredibly helpful. [SPEAKER_03] I think I would encourage everyone. [SPEAKER_03] I have a few personal projects that I don't even really share with anyone, but I try new models on them and I try new tooling on them because it gives me a much better sense of what I can actually do at work, which is also really helpful. Yeah.