I Built a Chrome Feature 15 Years Ago

Tim Williams: Hey, it's episode 20 of the Rubber Duck Radio, I'm Tim Williams and I've got Paul Mason held captive on the other Mic. [short pause] How are you Paul? Paul Mason: I'm dandy, let's dive in! Tim Williams: Paul, [pause] do you remember the first time you built something and then, years later, you see a big company announce the exact same idea? Paul Mason: Oh yeah. That mix of vindication and, uh, mild annoyance? Tim Williams: Exactly. [pause] So here's what happened. I'm scrolling through my feed and I see this post from the Chrome team — [emphasis] Declarative Partial Updates. And I start reading, and my heart rate actually goes up. Paul Mason: [surprised] Over a Chrome API proposal? Tim Williams: [laughing] I know how that sounds. But hear me out. [inhale] This proposal describes a system where you mark places in your HTML with declarative attributes, and then the browser — [emphasis] the browser itself — stitches in content from the server as it arrives, out of order, replacing placeholder content progressively. Paul Mason: Okay... Tim Williams: And I'm reading this and I'm thinking — [short pause] I built this. [pause] I built this [emphasis] fifteen years ago. Paul Mason: [shocked] Wait, what? You built declarative partial updates? Fifteen years ago? Tim Williams: Not the browser API, obviously. But the pattern. [inhale] I built an internal JavaScript framework for my company — I called it AppCore — that used declarative HTML attributes to wire up server interactions. You'd put a data-ac-module attribute on a div, and on page load it would fetch content from the server and stitch it into the DOM. You could nest them. They loaded progressively. It had placeholder content. Paul Mason: [pause] And when was this? Tim Williams: Before Angular 1 was open source. Before React existed. [short pause] jQuery was the hot thing, and I built this on top of it. Paul Mason: [low voice] Okay, that's actually wild. So you're telling me you anticipated a Chrome platform feature — [emphasis] in the jQuery era — with a custom framework? Tim Williams: [chuckle] I didn't anticipate anything. I just had a problem to solve. [pause] My company — we have all these different sites. Different properties. Different teams. And we needed interactive experiences — forms that submitted without page reloads, modules that loaded dynamic content, progressive updates. And we needed it to work [emphasis] everywhere. Paul Mason: So you built a framework. Tim Williams: I built a framework. [inhale] AppCore was a single jQuery based JavaScript plugin. It lived in a common directory shared across all our sites. And the idea was beautifully simple — you'd sprinkle data-ac attributes on your HTML, and the framework handled everything else. Paul Mason: What were the attributes? Like, what did data-ac-module actually do? Tim Williams: So there were four main ones. [pause] data-ac-module — that was the big one. You'd put it on any element, and on page load, AppCore would fire off a request to the server, get back HTML, and inject it into that spot in the DOM. You could have placeholder content inside the div — like a loading spinner or a skeleton — that would get replaced when the response came back. Paul Mason: So basically server-side includes, but with JavaScript and progressive loading. Tim Williams: [emphasis] Exactly. And you could nest them. A page-level module would load, and inside that response could be [emphasis] more data-ac-module elements that would fire off their own requests. It was recursive progressive loading before anyone called it that. Paul Mason: That's... [short pause] that's actually pretty sophisticated for jQuery-era JavaScript. Tim Williams: And that was just one attribute. [inhale] We had data-ac-button — on click, it would send a request to the element's href with JSON data. data-ac-submit — on click, serialize the form and submit it via AJAX. And data-ac-onChange — any time a form field changed, submit the whole form. [pause] You could build an entire interactive application without writing a single line of JavaScript. I did a bunch of trickery to make it work cross domains too, obviously trying to preserve security, but since this was an internal tool, I figured I could get away with bending the rules a bit. Paul Mason: So HTMX, basically. But years before HTMX. Tim Williams: [laughing] Yeah! And HTMX is great — I love what Carson's done. But AppCore had a different trick up its sleeve that I think is actually [emphasis] more relevant to what Chrome is proposing now. Paul Mason: Okay, I'm hooked. What was the trick? Tim Williams: The server response format. [pause] When AppCore made a request, the server didn't just return HTML. It returned a JSON object with a functions array. [short pause] Each entry had a functionName — like html, replaceWith, append, modal — and an args object with a target selector and the content. Paul Mason: So the server could say "replace this selector with this HTML" or "open a modal with this content" — all declaratively from the backend. Tim Williams: Exactly. [energetically] And here's the key — a single response could contain [emphasis] multiple function calls targeting [emphasis] different parts of the page. So one AJAX request could update three different divs, close a modal, and append something to a list. [pause] The server was orchestrating the entire DOM update, not the client. Paul Mason: [pause] That is... [short pause] honestly, that's a really elegant architecture. The backend knows what needs to change, so why make the frontend figure it out? Tim Williams: That's exactly how I saw it. [inhale] And I built PHP controller shortcuts to make it dead simple — ajax_html, ajax_replaceWith, ajax_modal. You'd call one method in your controller, pass in a selector and some HTML, and the framework would build the JSON response for you. Paul Mason: So the developer experience on both sides was clean. Declarative markup on the frontend, one-liner controller methods on the backend. Tim Williams: And it worked. [pause] I built interactive experiences with this thing — complex multi-step forms, dynamic dashboards, progressive content loading — all running across a half-dozen different company websites, all sharing the same slim JavaScript frontend and an orchestrating PHP layer on the backend. [exhale] It was [emphasis] fun. Genuinely fun to build. Paul Mason: So what happened to it? Why isn't AppCore a thing today? Tim Williams: [sigh] The same thing that happens to a lot of internal frameworks. The company moved on, React ate the world, and AppCore stayed where it was — believe it or not, the library is still in use today. [pause] The idea that the browser should be smarter about partial updates — that it shouldn't require a hundred kilobytes of JavaScript to stitch content into a page. Paul Mason: Which brings us to Chrome. Tim Williams: Which brings us to Chrome. [pause] So let me walk you through what they're actually proposing, because it's [emphasis] eerily similar in spirit. Tim Williams: The Chrome team has been working on something called Declarative Partial Updates. It's two new sets of APIs. [inhale] The first one is out-of-order streaming using processing instructions and the template element. You put a processing instruction in your HTML — like a marker — and then later in the document, a template element can replace it. Paul Mason: Processing instructions? Like XML-style PIs? Tim Williams: Exactly. They've existed in XML forever but HTML just treated them as comments and ignored them. Chrome is making them [emphasis] meaningful. So you can write something like — and I'm paraphrasing here — a div with a marker inside it, and then later a template element that says "for that marker" with the actual content. Paul Mason: So the browser parses the document top to bottom like normal, hits the marker, keeps going, and then when it hits the template it stitches the content back up into the marker? Tim Williams: [emphasis] Yes. Out of order. There are also range markers — start and end processing instructions — that wrap placeholder content. So you can show "Loading..." inside a div, and then later in the document stream, a template replaces that placeholder with the real content. Paul Mason: So it's like... [short pause] skeleton screens, but done by the HTML parser itself. No JavaScript. Tim Williams: No JavaScript. [energetically] And you can chain these things. A template can include a marker for the next template, so you can stream in list items one by one as they become available on the server. Each template replaces the previous marker and leaves a new marker for the next item. Paul Mason: That's... [pause] that's actually really cool! You could have a search results page where the layout loads instantly, and then results stream in as the database returns them. I can think of [emphasis] many React applications I've built that do something like this. Tim Williams: Exactly. And the Chrome team explicitly calls out island architecture as a use case. [pause] You know — the pattern Astro popularized, where you have static content with independent interactive islands that hydrate separately. Paul Mason: But now the islands can be server-streamed HTML instead of JavaScript components. Tim Williams: The second part of the proposal is even more directly relevant to what AppCore did. [inhale] They're introducing a whole suite of new HTML insertion and streaming methods — setHTML, replaceWithHTML, beforeHTML, afterHTML, appendHTML, prependHTML — each with a stream equivalent. Paul Mason: So instead of innerHTML and insertAdjacentHTML and all those different APIs with different behaviors... Tim Williams: They're cleaning it up. [emphasis] Finally. Consistent naming, consistent behavior, and every method has a streaming version that works with the Streams API. You can pipe a fetch response directly into a DOM element. Paul Mason: [excited] Okay, that's huge. So I could do something like — fetch an endpoint, pipe the response body through a text decoder, and stream it directly into a div with streamHTMLUnsafe? Tim Williams: That's exactly the example they give. [pause] And look — [short pause] the naming convention alone is worth celebrating. No more guessing whether something overwrites or appends. setHTML sets the content. replaceWithHTML replaces the element. appendHTML appends. It does what it says. Paul Mason: [chuckle] Future you will thank present Chrome team. Tim Williams: [laughing] Exactly. But here's the thing — [pause] the real power comes from combining both APIs. You stream template elements into the bottom of your HTML document, and they slot into markers placed throughout the page. [emphasis] You don't need JavaScript to know which DOM elements to target. The markers handle that declaratively. Paul Mason: So the server controls the layout, the browser handles the stitching, and the JavaScript layer just... gets out of the way. Tim Williams: Which is [emphasis] exactly what AppCore was trying to do — minus the browser-native part. In AppCore, the server returned JSON with function calls, and the JavaScript framework iterated over them and called the right jQuery method. [pause] With Chrome's proposal, the browser [emphasis] is the framework. Paul Mason: [pause] So let me get this straight. AppCore had declarative attributes to mark update targets, a server-side orchestrator that decided what to update, and a response format that described DOM mutations. And Chrome is proposing markers to declare update targets, server-streamed templates that dictate content, and browser-native DOM stitching. [short pause] It's the same pattern, just moved down the stack. Tim Williams: Yes! [energetically] And that's why my heart rate went up. I wasn't just seeing a new API — I was seeing the platform [emphasis] validate an architecture I'd believed in for over a decade. Paul Mason: That's a good feeling. Tim Williams: It really is. [exhale] But let's talk about what this actually means — practically — for developers today. Tim Williams: The big one is [emphasis] performance. [pause] Right now, if you want to stream content into a page, your options are... not great. You either wait for everything and then do one big innerHTML, or you use document.write — which is deprecated and breaks in a lot of scenarios — or you ship a framework that handles chunked responses and DOM diffing. Paul Mason: Or you do what a lot of people do, which is just accept the delay and show a spinner. Tim Williams: [sigh] The spinner. The universal admission of defeat. [pause] With these APIs, you can have the fast stuff render immediately and the slow stuff fill in as it arrives. The Chrome team's demo shows a photo album where the layout and status load instantly, and the images stream in progressively. Paul Mason: And that's not just a UX win — that's an actual business metric win. Time to interactive, largest contentful paint, all the Core Web Vitals stuff. Tim Williams: Right. And think about mega menus. [pause] You know those massive dropdown navigations that have a ton of HTML but the user doesn't see them until they hover? Right now that HTML is in your initial page payload, competing with your hero content for bandwidth. [emphasis] With out-of-order streaming, you can put the mega menu HTML at the end of the document and have it slot into the right place. Paul Mason: So you can prioritize what the user actually sees first without restructuring your entire page. Tim Williams: Exactly. Order is no longer a constraint. [pause] And the other big advantage — and this is the one that really excites me — is [emphasis] reduced JavaScript complexity. Paul Mason: Yeah, I mean, if the browser handles the DOM stitching, you don't need a virtual DOM, you don't need a diffing algorithm, you don't need state management for what is essentially server-driven UI. Tim Williams: Consider this. [pause] A typical React app today downloads React, downloads your components, hydrates the page, sets up state management, handles routing — all to do something that, in many cases, is fundamentally [emphasis] server-driven content display. [short pause] If the browser can handle the streaming and stitching natively, a huge chunk of that JavaScript just... disappears. Paul Mason: Which means smaller bundles, faster parse times, less memory usage. Tim Williams: And better user experiences on low-end devices. [pause] The web has a reach problem — we keep building for high-end phones and fast connections, but billions of people are on older devices and spotty networks. Moving complexity into the browser engine, where it can be [emphasis] heavily optimized, is a win for everyone. Paul Mason: That's the thing about platform features versus framework features. When it's in the browser, it's in C++. It's fast. It doesn't need to be downloaded, parsed, and executed. Tim Williams: And it works with the parser's native streaming behavior. [pause] The browser already streams HTML — it's been doing that since the 90s. It parses incrementally, renders progressively. These APIs just give developers [emphasis] control over that streaming behavior instead of fighting against it. Paul Mason: So it's not a new capability — it's exposing an existing capability to developers. Tim Williams: That's a great way to put it. [pause] And that's actually how the best web platform features work. They don't add something new — they [emphasis] expose something the browser already does. Paul Mason: Okay, so let's talk about frameworks. [pause] You mentioned Vue and Svelte. How do you see this playing out? Tim Williams: So here's my prediction. [inhale] If this catches on — and the Chrome team says they're getting positive feedback from other browser vendors, which is [emphasis] crucial — then frameworks like Vue and Svelte are going to pick this up and it's going to supercharge their capabilities. Paul Mason: How so? Tim Williams: Think about Vue's single-file components. [pause] Right now, when you server-side render a Vue component, you're either doing full page reloads or you're shipping the component JavaScript to the client for hydration. But with out-of-order streaming markers, you could stream component HTML directly into the page — [emphasis] in whatever order it's ready — without shipping the component's JavaScript at all for purely presentational pieces. Paul Mason: So Vue becomes more like... a server-side templating engine with optional client-side interactivity, rather than a client-side framework that can also do SSR. Tim Williams: Exactly. And Svelte — [pause] Svelte already compiles away the framework. There's no virtual DOM, no runtime library. It's already heading in this direction. Adding browser-native streaming markers to Svelte's output would be a natural fit. Paul Mason: What about React? I feel like React's model is so heavily client-side that this might not fit as neatly. Tim Williams: React's in an interesting spot. [pause] React Server Components are already pushing rendering to the server and streaming HTML to the client. The streaming APIs Chrome is proposing would make RSC [emphasis] dramatically more efficient — instead of React managing the streaming protocol in JavaScript, the browser handles it natively. Paul Mason: So React would still be React, but the transport layer gets way simpler. Tim Williams: Right. And the framework authors I've talked to over the years — [short pause] they [emphasis] want this. They don't want to reimplement streaming HTML in JavaScript. They want the platform to do the heavy lifting so they can focus on the developer experience and the component model. Paul Mason: That's the dream, right? The platform absorbs the hard parts, and frameworks become thinner, more focused on ergonomics. Tim Williams: And we've seen this pattern before. [pause] jQuery was enormous because it had to paper over browser inconsistencies. Then the browsers standardized, and jQuery's core value proposition evaporated. [short pause] The same thing could happen with the DOM manipulation parts of modern frameworks. Paul Mason: So the frameworks that survive are the ones that add value [emphasis] above the platform — component models, state management, developer tooling — not the ones that are essentially polyfilling missing browser features. Tim Williams: That's exactly it. [pause] And the Chrome team has already released polyfills for both APIs — the template-for polyfill and the html-setters polyfill — so you can start using these patterns today, even in browsers that don't support them yet. Paul Mason: Wait, there are polyfills already? For a proposal that's behind a flag in Chrome 148? Tim Williams: [chuckle] That's how serious they are about this. They want developers to kick the tires [emphasis] now. The template-for polyfill covers most use cases, though it can't directly update the browser's HTML parser so there are some limitations. And the setters polyfill doesn't actually stream — it buffers and applies when complete — but it gives you the API shape to develop against. Paul Mason: So you can write the code today and it'll get faster when browsers ship native support. Tim Williams: Progressive enhancement at the API level. [pause] Which, I have to say, is [emphasis] very satisfying. Paul Mason: [chuckle] So let me ask you this. [pause] Looking back at AppCore — if Chrome had shipped these APIs fifteen years ago, would you have built AppCore at all? Tim Williams: [long pause] That's a really good question. [inhale] I think I still would have built [emphasis] something. AppCore wasn't just about DOM stitching — it had opinionated conventions about how the server and client communicate. The function-call response format, the PHP shortcuts, the way modules composed together. [pause] But the JavaScript would have been dramatically smaller. Maybe a hundred lines instead of eleven hundred Paul Mason: So the framework becomes a thin orchestration layer instead of a DOM manipulation engine. Tim Williams: Exactly. And that's where I think we're heading. [pause] The web platform is slowly absorbing the patterns that frameworks pioneered. Components? We're getting those. Streaming HTML? We're getting that. Declarative partial updates? We're getting that. [short pause] The frameworks that embrace this and get thinner are going to thrive. The ones that fight it... Paul Mason: [dryly] They'll join the jQuery museum. Tim Williams: [laughing] Alongside my beloved AppCore. [pause] But here's the thing — I'm actually [emphasis] happy about that. The goal was never to build a permanent framework. The goal was to solve a problem. And if the platform solves it better, [emphasis] use the platform. Paul Mason: That's a healthy attitude. A lot of people get attached to their tools. Tim Williams: Alright, [pause] speaking of building tools — [inhale] let's shift gears to something I've been wrestling with lately. And honestly, it connects directly to what we just said about platforms absorbing patterns. [short pause] How do you run a coding interview in the AI era? Paul Mason: [exhale] Oh man. [chuckle] That's the question, isn't it? Tim Williams: I've been interviewing candidates recently, and here's what I keep coming back to. [pause] I don't need someone who can type fast. I need someone who can [emphasis] grok everything the AI is writing. Someone who — when things go sideways, and they [emphasis] will — can dive deep, diagnose the problem, and explain it. [short pause] Not just accept whatever the AI spits out. Paul Mason: Yeah. [tsk] And here's the thing — I've been deep in Claude, Codex and Cursor for years now, and I can tell you: the AI is [emphasis] confidently wrong a lot. [short pause] If you can't read the code it's generating, you're not engineering. You're gambling. Tim Williams: And that's exactly the problem I'm trying to solve in interviews. Because — [pause] you've seen the term that's been going around, right? [short pause] Vibe coding. Paul Mason: [groan] Oh, I've seen it. [unhappy] People prompting, accepting, prompting, accepting — never reading the output. Then they burn two hundred dollars in API credits trying to fix a bug that's literally a one-line logic error they'd catch if they just [emphasis] read the code. Tim Williams: Right. And those developers — [pause] they're spending untold amounts of money spinning in circles on things the AI simply can't understand, or they can't properly explain to the AI. [short pause] So when I interview someone, I need to see evidence that they're [emphasis] not that person. Paul Mason: So how do you actually test for that? Tim Williams: [inhale] Well, that's where it gets fascinating — because the industry is splitting into three camps right now. [pause] Let me break it down. Tim Williams: Camp one: [pause] AI-allowed. [short pause] Meta just launched a pilot this year — they're doing a sixty-minute coding round in CoderPad with built-in AI. GPT-4o, GPT-5, Claude Sonnet, Gemini Pro, Llama 4 — all available right in the interview environment. [pause] And here's the key — it's not LeetCode. It's a [emphasis] multi-file project. Real-world task. Candidate chooses when and how to use AI. Paul Mason: [surprised] Wait — so they're [emphasis] encouraging AI use? Tim Williams: Not just encouraging — they're [emphasis] evaluating on it. The rubric covers prompt quality, critical review of AI output, how well you course-correct when the AI gets it wrong. [pause] Meta's actual guidance says: '[emphasis] AI is best used as a productivity booster for well-defined subtasks, NOT as an end-to-end solver.' And they explicitly tell candidates — never accept AI output at face value. Review every line. Paul Mason: [impressed] Okay. That's... [short pause] that's actually really well thought out. [pause] Because that's exactly what the job is now. You're not just writing code — you're reviewing AI-generated code, steering it, catching its mistakes. Tim Williams: Exactly. And Canva published a whole piece called '[emphasis] Yes, You Can Use AI in Our Interviews.' They expect you to use Copilot, Cursor, Claude. [pause] The philosophy is: eighty-four percent of developers already use AI tools daily. Why would you test people in a way that doesn't reflect their actual job? Paul Mason: [chuckle] Alright, so that's the forward-leaning camp. What's the other side? Tim Williams: Camp two: [pause] AI-banned. [short pause] Google — no AI tools during virtual interviews. They want to verify what they call '[emphasis] fundamental coding skills.' [pause] And they're not alone. Cisco explicitly says if you're not invited to use AI, it's off-limits. McKinsey is pushing in-person interviews to assess — and I'm quoting here — '[emphasis] human qualities that can't be automated — judgment, empathy, creativity, and connection.' Paul Mason: [skeptical] I mean... [pause] I get it, but — [tsk] it feels like fighting the last war. Tim Williams: Here's the thing — they have a point, and we should be fair about this. [pause] Gartner's data shows over seventy-two percent of recruiting leaders are now conducting in-person interviews specifically to combat fraud. [short pause] At least half of applications for remote IT roles are estimated to be false. There are people using deepfakes to have someone [emphasis] else do the interview. Paul Mason: [shocked] Wait — actual deepfakes? For coding interviews? Tim Williams: Actual deepfakes. [pause] And then there are the cheating tools. Did you hear about Interview Coder? Paul Mason: I don't think so — what's that? Tim Williams: Columbia student named Roy Lee built an invisible AI tool — it takes screenshots of the interview question, runs them through an LLM, and overlays the answer on the screen. [short pause] Undetectable to proctoring software. He got suspended, dropped out, and then [emphasis] raised five million dollars for it. [pause] He called it '[emphasis] not even really cheating.' Paul Mason: [laughing incredulously] Not even — [short pause] wow. [exhale] Okay. So on one hand you've got Meta saying 'AI is the job, use it,' and on the other hand you've got an arms race of cheating tools and deepfakes. [pause] No wonder companies are running back to in-person. Tim Williams: And that's the tension. [pause] But here's where I land on this. [inhale] I think Meta's approach is the right direction — not because it's easier, but because it's [emphasis] more honest. The job has changed. If eighty-four percent of developers are using AI daily, testing them in an AI-free environment tells you how they'd perform in a job that [emphasis] doesn't exist anymore. Paul Mason: Yeah. [pause] I'd add one more thing — Google can't hold this line forever. [short pause] Eventually, the talent market forces their hand. When Meta and Canva are offering interviews that actually simulate the real job, and Google is asking you to pretend AI doesn't exist — [pause] which one attracts the pragmatic, experienced engineers? Tim Williams: That's a great point. [pause] But — [short pause] and I want to push on this a bit — there's a real danger here for junior developers. Paul Mason: Mm. Say more. Tim Williams: If the interview expects you to use AI [emphasis] critically — to catch its mistakes, to know when it's confidently wrong — that requires judgment that comes from experience. [pause] A junior developer who's never debugged a production memory leak doesn't have the instincts to know when the AI is leading them off a cliff. [short pause] So the AI-allowed interview might actually be [emphasis] harder for juniors, not easier. Paul Mason: That's exactly what worries me. [pause] How do you break into this industry when the interview expects you to [emphasis] supervise an AI — but you haven't built the instincts yet to know when it's wrong? Tim Williams: And that's the question nobody has a good answer for yet. [pause] It reminds me of — [short pause] do you remember when calculators started showing up in math class? Paul Mason: Oh yeah. 'You won't always have a calculator in your pocket.' Tim Williams: Right. [laughing] And now we literally have supercomputers in our pockets. [pause] But here's the thing — the math teachers weren't [emphasis] entirely wrong. You still need to understand the concepts to know when the calculator is giving you a nonsense answer. [short pause] The difference is: with a calculator, the nonsense is usually obvious. With an LLM, the nonsense is [emphasis] very confident and very plausible. Paul Mason: And that's the trap. [pause] I've seen senior engineers get burned by AI-generated code that looked perfect but had subtle logic errors. [tsk] A junior would have no chance of catching it. Tim Williams: So I think the answer — and I'm still working through this — is that AI-allowed interviews need a [emphasis] junior track. [pause] Where you're not testing 'can you catch the AI's subtle mistakes,' you're testing 'can you understand the code the AI wrote, can you explain it, and can you extend it.' [short pause] Different bar, same format. Paul Mason: That's actually practical. [pause] And honestly, future you will thank present you for thinking about this now — because in two years, every company is going to be doing AI-allowed interviews, and they're going to have to figure out the junior pipeline. [short pause] The companies that are designing for it [emphasis] now are going to have a huge advantage. Tim Williams: The moral of the story — [chuckle] and I promise this connects back to AppCore — is that the [emphasis] pattern matters more than the implementation. The pattern of 'here's how we assess real engineering judgment' is what matters. [pause] Whether you use AI or not in the interview is secondary. What you're [emphasis] actually testing — that's what counts. Paul Mason: And the pattern we need is: [pause] can you think critically about code, regardless of where it came from? Tim Williams: Exactly. [pause] Alright Paul, we covered a lot of ground today. jQuery-era frameworks, Chrome proposals, deepfake interviews... Paul Mason: [laughing] It's a wild show when those three things are in the same episode. Tim Williams: It really is. [pause] If you're a hiring manager trying to figure out your AI policy for interviews, we'd love to hear what you're doing. And if you've been through an AI-allowed interview — especially Meta's pilot — reach out and tell us how it went. Paul Mason: And if you're a junior developer trying to figure out how to break in — [short pause] keep building things. The instincts come from reps. [pause] Use AI as a tool, not a crutch. Future you will thank present you. Tim Williams: I'm Tim Williams. Paul Mason: And I'm Paul Mason. Tim Williams: Here's looking at you.