Every senior editor Jack Cheng explains how he used Codex to build a "gift links" feature — allowing paid subscribers to share full articles with non-subscribers — because the idea wasn't high enough on the roadmap for engineers to build. He joins Austin Tedesco and Kate Lee to walk through the research, internal buy-in, guardrails, implementation, and analytics behind the feature, and to discuss how AI coding tools let editorial and growth teams test more ideas without pulling engineers away from larger projects. # Video Identity Observations ## Title & Framing - **Title:** "I Vibecoded This Feature Using Codex" — positions the video as an AI-coding / workplace-transformation story, using the slang term *"vibecoded"* to signal an AI-native, experiment-friendly audience. ## Intended Audience - **Knowledge workers and non-engineers curious about AI agents**, especially in media/editorial roles: > "This is a great example of how dramatically job opportunities have changed, especially for knowledge workers like us." - **Editorial/content professionals afraid to touch code**, addressed directly near the end: > "if you've never done anything like this before, if you work in areas like ours, and you're scared to send PR to your company's website… Try experimenting with a personal project." - **Managers/leads weighing control vs. delegation** — a large portion of the transcript is Austin (head of growth) explaining his shift from gatekeeping to enabling: > "the best thing we can do is build an infrastructure for everyone on the team who has cool ideas… to quickly implement what they're passionate about." ## Claimed Scope - Not a coding tutorial; a **case study of AI-agent-driven workflow change at Every** (a media company), covering: - How an editorial team member (Jack/Jackie) shipped a **gift links feature** using Codex. - How AI tools changed prioritization dynamics ("It's not a priority… but if you want to do it—just use Codex"). - Practical tactics: using ChatGPT for research reports, asking Codex to review plans, tracking via PostHog. - Explicit advice-giving scope for outsiders: build confidence via **personal projects**, "build your own CMS," practice making PRs. ## Self-Description Evidence - The channel/organization describes itself as **enthusiasm- and experimentation-driven**: > "at Every everything is based on enthusiasm and experimentation." - It also self-identifies as both a software and media operation: > "We are not only software developers, but also a media organization." - Demonstrated presentation pattern: a **multi-participant conversational format** (Jack, Austin, Kate, plus references to engineer Andre) discussing internal process openly, framed as shareable lessons for viewers. ## Observable Presentation Notes - Heavy use of concrete tool names (**Codex, Opus, ChatGPT, PostHog, Slack**) as evidence of practice, not promotion. - Candid admission of unresolved skepticism ("Frankly, I'm still very skeptical that this will make us more money") suggests a transparent, debrief-style tone rather than hype. # Delivery Observations — "I Vibecoded This Feature Using Codex" ## Format & Participants - **Conversational panel-style discussion** among what appears to be three colleagues (Jack/Katie from editorial, Austin from growth, and a third speaker). Speakers address each other by name: *"Jack, now that you mentioned it..."*, *"Austin, you looked at the report and said..."* - The transcript reads like a **transcribed spoken conversation** — including filler words, restarts, and parenthetical asides (*"I, uh, shared your plan with Codex"*, *"And I think I would recommend it to everyone"*). ## Tone - **Warm, collegial, celebratory.** Praise is frequent and direct: *"I'm proud of you"*, *"that's just crazy"* (admiringly), *"This was truly a turning point."* - **Honest about disagreement.** One speaker openly states skepticism: *"Frankly, I'm still very skeptical that this will make us more money. Seriously, really."* Another recalls a blunt message: *"don't waste my time on this."* - **Reflective/confessional** in places: *"I'm a huge controller"*, *"I was scared of for a long time too."* ## Vocabulary & Recurring Concepts - **AI-agent vocabulary as routine nouns:** *Codex*, *agent*, *PR*, *diffs*, *dashboard*, *vibecoded* (title), *Codex replied*. - **Roadmap/prioritization jargon** recurs heavily: *"priority on the roadmap"*, *"P0 or P1 priority, compared to a P3 or P4"*, *"growth experiment"*, *"MRR"* (twice: *"increase our MRR"*, *"grow MRR"*). - **Systems language:** the phrase **"systems in place"** appears twice — *"whether we have systems in place for people to release what they are passionate about"* [73–83] and *"as long as there are systems in place to do that work well"* [454]. - **"Passion/passionate" recurs** (3×): *"release what they are passionate about"*, *"what they're passionate about"*, *"do what they're passionate about."* - **"Turning point" / "major growth point"** frames the change: *"This was truly a turning point"* [15–20]; *"This was actually a major growth point for me in the way I work"* [443]. ## Teaching Habits - **Direct address to the audience** near the end, shifting from anecdote to advice: *"it's worth reminding you: if you've never done anything like this before..."*, *"Try experimenting with a personal project."* - **Step-oriented, practical guidance:** *"You can simply ask him to create his own CMS and then do PR for it"*, *"build your own CMS."* - **Vulnerability as a teaching device:** normalizes fear of judgment — *"every time I do a PR, I think, 'Andre is going to come along and say, "This is the most ridiculous thing I've ever seen."'"* - **Narrative walkthrough of a process:** the story is told sequentially — curiosity → asking the agent (*"Tell me what we already have for gift links"*) → research report → approval → shipping → measuring (*"let the data show us the outcome"*). ## Communication Patterns - **Direct quotations of past dialogue** to dramatize the story: *"you just said, 'I can ask the agent to do it'"*, *"And Codex replied, 'No, it's a change in approach...'"* - **Rhetorical questions and trailing "right?"** as a verbal tic: *"The way we work is changing, right?"*, *"it will actually make us move much faster and work much better. I'm proud of you."*, *"either it attracts... or it will turn out... and we can turn it off."* — "right?" appears at least four times. - **Contrast framing ("before vs. now"):** *"If it was before, you would say... And instead you just said..."*; *"it's less like the case where we wrote a huge spec... and more like a real experiment."* - **Repetition of the video's thesis** (agents + systems let people ship without roadmap gatekeeping) at multiple points [20–27], [73–83], [419–454], [466–477], [499–509]. ## Uncertainty Notes - Speaker attribution is unclear in the transcript (no speaker labels); I could not consistently determine who says which line beyond names addressed, so individual voice patterns are **not** claimed here. - "Vibecoded" appears only in the title, not in the transcript body — repetition of that term cannot be assessed. - The "right?" tic and "systems in place" repetition are the only clearly repeated phrases; other vocabulary items occur only 2–3 times and may reflect topic necessity rather than habitual style. # Observed Positions: "I Vibecoded This Feature Using Codex" ## Context A conversation among three colleagues at **Every** (a media/software company) about how an AI coding agent (**Codex**) enabled the editorial team to build a **gift links** feature for paid subscribers without it being a formal roadmap priority. Speakers identifiable from the transcript: **Jack** (proposed and built the feature), **Austin** (head of growth), and **Kate** (editor-in-chief, identified by Jack as key editorial stakeholder). An engineer named **Andre** (who runs the site) is referenced but does not speak. --- ## Jack — Feature Instigator ### Motivation and origin - Began as **personal curiosity**: he has a personal newsletter and wanted to share Every's subscription-only articles with readers without them paying for access. - Observed that favorite blogs (e.g., **Jason Kottke's**) share paid content only through giveaway links, prompting the question: *"if we try to increase our followers, aren't we limiting ourselves and the potential for our articles to go viral?"* ### Process described - Asked his AI agent to **inspect the codebase** for existing gift-link functionality. - Identified whose support he needed: Austin (growth experiment), Kate (editor-in-chief), and buy-in more broadly. - Had **ChatGPT conduct in-depth research** on gift links and effectiveness, producing a report covering implementation requirements (site code) and success metrics, then shared it with Austin and Kate. - Shared his plan on Slack; Austin then ran Jack's plan through **Codex** to check whether it would break anything. ### Advice offered - For those afraid of sending PRs to their company's site: **practice on personal projects first**. - *"if you've never done anything like this before... which I was scared of for a long time too. Try experimenting with a personal project."* - Admits fearing judgment from Andre: *"every time I do a PR, I think, 'Andre is going to come along and say, "This is the most ridiculous thing I've ever seen."'"* - Keeps **private personal projects** to test new models and tools, which builds confidence applicable at work. --- ## Austin — Head of Growth ### Initial position (skeptical) - Told Jack initially: *"It's not a priority for the development team, but if you want to do it—just use Codex, let it do it, go ahead."* - Calls that moment *"truly a turning point."* - States bluntly that among things that could increase MRR, gift links *"rank very low on the list of ones that actually work or are worth our time."* - Recalls telling Jack, in effect, *"don't waste my time on this,"* while his actual reaction was "interesting." ### Shift in position - Describes a **personal growth point**: *"while I trust the people I work with, understanding that we have all these tools, it's actually much better to let people do what they're passionate about and try as long as there are systems in place to do that work well."* - New philosophy for the growth team: *"the best thing we can do is build an infrastructure for everyone on the team who has cool ideas... to quickly implement what they're passionate about."* - Contrasts this with his prior approach at previous companies: being *"very conservative with your resources... very conservative with your engineering time."* ### Residual skepticism — preserved as expressed - *"Frankly, I'm still very skeptical that this will make us more money. Seriously, really. But I'm so happy we never had to argue about it."* - Notes this is the **first time** his skeptical view has been openly discussed, and frames resolution via data: either gift links convert free subscribers to paid (scale it), or they don't (turn it off). --- ## Kate — Editor-in-Chief (Editorial Perspective) - Uses gift links herself constantly (New York Times, Wall Street Journal) and considered them *"something very desirable."* - Describes the historical bottleneck: a busy engineer (Andre) with many priorities; editorial requests couldn't realistically become P0/P1 vs. P3/P4. - Self-identifies as *"a huge controller"* from a paid media background, used to creators being *"very eager to give [content] away for free to reach more people."* - Notes a tension at Every: enthusiasm and experimentation are core, but she prefers focusing on a clear goal. - Observes an **irony**: editorial spends the most time in the CMS but is *"the least skilled at using it, changing it, or building it"* — historically dependent on engineers, since features affecting the most users win prioritization. - Frames a benefit: this frees Andre for big projects instead of *"the little things that just help us with our workflow."* - Qualification offered: *"links to diffs are not the same category of functions"* — acknowledges the analogy between gift links and editorial CMS needs is imperfect. --- ## Shared/Reconstructed Theses - **How work is changing**: AI tools let knowledge workers pursue ideas without roadmap gatekeeping — *"You now have the tools to do almost anything you want"* (Austin). - **Safeguards over prioritization**: the question shifts from *"whether everything someone is interested in is a priority on the roadmap"* to *"whether we have systems in place for people to release what they are passionate about"* (Austin). - **AI as risk-checker**: Austin shared Jack's plan with Codex, asking *"Will this break anything, or will it give away a bunch of content for free that I don't want?"* — and admits he *"haven't actually tested it on things that are really important to me."* (Preserved caveat.) - **Experiment over spec**: *"it's less like the case where we wrote a huge spec, got all the approvals and released it, and more like a real experiment: we release it, see what we learn from the first data, refine it, tweak it, and move on"* (Austin). He also notes using AI/Codex with PostHog to set up tracking easily. --- ## Feature Description (as stated) The editorial team implemented **gift links for paid subscribers**: a **"share full article"** button on article pages showing how many gift links a paid subscriber can copy and send to non-subscribers. --- ## Unresolved Tensions Preserved - Austin remains **skeptical of financial payoff** while endorsing the process; resolution is explicitly deferred to data. - Austin's own admission that Codex's safety review wasn't tested on his most important priorities. - Kate's tension between being a controller and Every's experimentation culture. - Kate's clarification that the editorial-CMS analogy doesn't map perfectly onto gift links. # Observation Record — "I Vibecoded This Feature Using Codex" ## Speaker Identification & Roles | Speaker | Role (explicit in transcript) | Evidence | |---|---|---| | **Jack** | Staff member at Every; initiated the gift-links experiment; "vibecoded" the feature | Addressed directly by name ("Jack, now that you mentioned it…"); wrote the research report; implemented the feature | | **Austin** | **Head of the growth department** at Every | Stated in transcript: "From the moment of growth, the head of the growth department, Austin" | | **Kate** | **Editor-in-chief** at Every | Referenced: "I understood that Kate had to play a key role because she was the editor-in-chief" | | **Andre** | Engineer who maintains the Every site (mentioned, **not** a speaker) | Referenced by Kate: "a wonderful engineer named Andre, who runs our site" | | Format | Multi-participant conversation between colleagues | Dialogue structure with direct address | > Note: Speaker attribution within the transcript is inferred from conversational turns and direct address; the transcript does not use labeled speaker tags. ## Referenced Sources & Tools (third-party claims) - **Codex** — AI coding agent used to review and implement the gift-links feature; repeatedly described as reviewing plans and answering safety questions. - **ChatGPT** — used by Jack to produce a research report on gift links and their effectiveness. - **Opus** — mentioned alongside Codex ("thanks to Codex, thanks to Opus"). - **PostHog** — mentioned for dashboard/tracking setup: "tell Post Hog to set this up on the dashboard." - **The New York Times / The Wall Street Journal** — cited as examples of publishers using giveaway links. - **Jason Kottke's blog** — cited as a favorite blog sharing paid content via gift links. - **Slack** — platform where the plan was shared. - **CMS** — the editorial team's primary working tool; discussion of building one's own CMS as a learning project. ## Provenance Facts - The **gift links feature** ("share full article" button for paid subscribers) was implemented by the editorial team, not the official development roadmap. - Jack compiled a **research report** (via ChatGPT) covering gift-link effectiveness, implementation requirements, and success metrics; sent to Austin and Kate. - Austin's initial position: the idea ranked low among MRR-growth priorities; screenshot/message of his reply referenced ("don't waste my time on this"). - Austin shared Jack's plan with Codex to check whether it would "break anything" before approval. - Decision framing: outcome to be determined by **data** (conversion of free subscribers to paid); feature can be turned off if not converting. - Kate describes personal background in "paid media" and identifies as a "controller." - **Acknowledged limitation**: Austin states "I haven't actually tested it on things that are really important to me." ## Promotional / Persuasive Segments - The video functions as a promotional narrative for **Codex/AI agents as workplace tools** ("thanks to Codex… this was truly a turning point"); flagged as such — no formal sponsor segment is declared. - Closing advice segment encourages viewers to experiment with AI agents and personal projects (persuasive, not a paid promotion per transcript). ## Comment Availability - No information about comments, availability limits, or platform restrictions appears in the transcript. ## Uncertainty - Exact speaker turns for some segments cannot be conclusively assigned from the unlabeled transcript. - The "Jackie" reference ("Jackie wrote to me") may be the same person as Jack; not confirmed explicitly. I wouldn't even, you know, try to create something like that. But thanks to Codex, thanks to Opus, Austin, you said, "It's not a priority for the development team, but if you want to do it—just use Codex, let it do it, go ahead ." This was truly a turning point for us to be able to implement gift links. The way we work is changing, right? This is a great example of how dramatically job opportunities have changed, especially for knowledge workers like us. You now have the tools to do almost anything you want. This allows you to do your core work better, and also gives you the opportunity to play and experiment. If it was before, you would say, "Oh, I see this problem. I wish we had gift links." You would come to me and say, "I think this should be a development experiment, or a team of engineers should build this." I would say, "Good idea. It's not a priority in our development plan. We'll do it later." And instead you just said, "I can ask the agent to do it." You no longer need to think so much about whether everything someone is interested in is a priority on the roadmap, but more about whether we have systems in place for people to release what they are passionate about. And if so, it looks like " just take it and do it." So, the editorial team implemented gift links on the site for paid subscribers. When you go to an article page, you may see a new "share full article" button. You can click on it and you'll see how many gift links you have to copy and send to those who aren't paid Every subscribers. It all started with the fact that I just wanted to satisfy my own curiosity. I have a personal newsletter and often want to share articles with my readers that are usually only available by subscription. There were some materials I wrote on the Every website that I wanted to share with them without paying for access. Another thing I've noticed: many of my favorite blogs, like Jason Kottke's blog, only share paid content through giveaway links. I started to wonder: if we try to increase our followers, aren't we limiting ourselves and the potential for our articles to go viral? I started interacting with my AI agent. I pointed him to our codebase and asked, "Tell me what we already have for gift links." "Do we have anything like that?" The next step was to determine whose support in the company I needed to get to make this happen. I knew it had to do with Austin, as it would be a growth experiment. I understood that Kate had to play a key role because she was the editor-in-chief. And I also knew I had to convince you that we should even try to do this. Therefore, I asked ChatGPT to conduct in-depth research on gift links and their effectiveness, compile a comprehensive report, and outline what we would need for implementation, including the site code, and what exactly we should track to measure success. So I prepared this report and sent it to both of you. And I think this is where our approach to gift links differs from how it worked before. Austin, you looked at the report and said, "This is great." " But at the same time, we have a whole bunch of other growth experiments that have a higher priority." If it weren't for AI agents and programming tools, that would be the end of it, right? Jack, now that you mentioned it, I realized that this is a feature I am very familiar with and use all the time myself. I often send giveaway links with articles from The New York Times or The Wall Street Journal. It always seemed like something very desirable. But from the editorial team's perspective, it usually worked like this: we have an engineer, a wonderful engineer named Andre, who runs our site, and he has a very busy schedule. And he has many priority tasks . So getting into this work plan requires a lot of coordination and significant resources and planning on his part. Given how pressing the issues we have to deal with every day are, it was hard to imagine how we would make this a P0 or P1 priority, compared to a P3 or P4. And yet, these are things we wanted to have. We are not only software developers, but also a media organization. We want to match the level of other organizations, and this is a habit that consumers are already accustomed to. Jack very convincingly justified this in a comprehensive document : what it is, how other sites do it, what the potential gains could be, and what is needed for implementation. From my perspective, I'm a huge controller , and having worked in paid media my whole life, I'm used to content creators being very eager to give it away for free to reach more people. Another thing I've often seen in Every is that people get excited about ideas, want to experiment, and this is where we can often get distracted from what our main goal is. This is good at the same time, because at Every everything is based on enthusiasm and experimentation, but for me it was a difficult transition, because I see a goal and just want to focus on achieving it. You can see here that Jackie wrote to me wanting to try this. And I, in essence, answer her: don't waste my time on this . My reaction is actually, “interesting,” right? “Guest linking” is an attempt to find a balance: giving away some content for free to attract new users, gain social proof, and encourage subscriptions. And I said that among the many things that could increase our MRR, this idea ranks very low on the list of ones that actually work or are worth our time . The cool thing that's possible now is that you took that and were able to say, "Hey, I have a plan." And you brought this plan and shared it on Slack. I, uh, shared your plan with Codex, and basically just asked him, "Will this break anything, or will it give away a bunch of content for free that I don't want?" I haven't actually tested it on things that are really important to me. And Codex replied, "No, it's a change in approach to how companies with smart, creative, ambitious people can operate, where I can say, 'Okay, these safeguards are in place for what I'm responsible for,' which is to grow MRR, and also safeguards that allow you to test and try it out without breaking the site." This is actually a major growth point for me in the way I work, to say, " Okay, while I trust the people I work with, understanding that we have all these tools, it's actually much better to let people do what they're passionate about and try as long as there are systems in place to do that work well." This was a great insight for me and the rest of the growth team: “Really , the best thing we can do is build an infrastructure for everyone on the team who has cool ideas for editorial and product experiments to quickly implement what they’re passionate about.” Because you are close to it as consumers of media and paid content, you will naturally have great ideas that can be useful for business. And instead of the way I worked before at previous companies, where you're very conservative with your resources, you're very conservative with your engineering time. Here, I think the best thing we can do is say: great, don't just implement this, you know how to do it, right? And we know how to see if it's not hurting something important, and it will actually make us move much faster and work much better. I'm proud of you. From the moment of growth, the head of the growth department, Austin. Many, many things with artificial intelligence have come down to the fact that all you need to do is be less of a controller in everything. Get out of your comfort zone. Well, we will get better. Yes, yes. Delegate work to your agents and teammates. I'm also curious, from a control perspective and where the work is done: as an editorial team, we spend the most time in the CMS, making sure the content is up to the highest standards every day, and yet , historically, we're the least skilled at using it, changing it, or building it. I at least considered myself dependent on the engineer, because the features he was going to develop were likely to be the ones that would have the biggest impact on the largest number of users. So if it's a small problem for me, even if I encounter it every day, it may not become a priority because it won't affect anyone but me. I should clarify that links to diffs are not the same category of functions, but this is how the relationship between the editorial team and the engineer who maintains the site usually developed. It's really nice to see that we can be a little more involved and have more control over this. And by the way, this frees up our engineer to work on really big projects and important things that can have a huge impact, and he doesn't have to get bogged down in the little things that just help us with our workflow. Frankly, I'm still very skeptical that this will make us more money. Seriously, really. But I'm so happy we never had to argue about it. This seems to be the first time we've discussed my views on this, and that's a really good thing. Ultimately, it just lets the data show us the outcome, right? The data will tell us: either it attracts significantly more free subscribers who become paid, and we should scale, or it will turn out that our paid materials with gift codes are not converting, and we can turn it off . It's much better to see it work in real user scenarios and based on data than—and we've all done this many times—to sit in a meeting where I say, "This won't work." I don't want to waste time on this. And you say, "I actually think we should do it." And as we collect more data, I can also very easily say, " Hey, Codex, tell Post Hog to set this up on the dashboard, start tracking these things ." So it's less like the case where we wrote a huge spec, got all the approvals and released it, and more like a real experiment: we release it, see what we learn from the first data, refine it, tweak it, and move on. Yes. And it's worth reminding you: if you've never done anything like this before, if you work in areas like ours, and you're scared to send PR to your company's website, which I was scared of for a long time too . Try experimenting with a personal project, right? Jack, you created your own version of the Codex, that's just crazy. If you work in an editorial office and want to try this, you can just build your own CMS, right? You can simply ask him to create his own CMS and then do PR for it. I think it's important to strengthen this confidence. And find a personal project for this so that you feel more confident and comfortable doing it both at work and in front of other people. Because every time I do a PR, I think, " Andre is going to come along and say, 'This is the most ridiculous thing I've ever seen.'" And creating enough things for your own projects that actually work helps a lot. And I think I would recommend it to everyone. I have a few personal projects that I don't even share with anyone , but I've been trying out new models and new tools on them. Because it gives me a much better understanding of what I can actually do at work, and it's also very useful .