How's everybody doing? Good to see y'all.

My name is Steve Lavigne, President and CTO of Craft and Crew, a digital agency out of Ottawa, Canada, just had our 16th birthday a couple days ago. I'll talk about how the Claude Connector isn't just a productivity tool but has to be an accountability tool, treating it like a team member, a junior developer or designer, adding gates and guardrails into the process to be successful without blowing things up. Recap: who's used the Claude Connector for MCP, almost everybody. We connect it to Webflow, ask Claude to do stuff in plain English, it connects through APIs, endpoints, the designer, the data layer, and something happens on the site magically. For the most part it's logged in as you or whoever's using it, a blessing and a curse, blessing because it can do anything, curse because it can do anything and blow stuff up, especially closer to production with clients or others using it. Everyone knows how fast MCP is, table stakes now, but also more economical, same budget and team but now with time for extra audits, content entry, site cleanup before support and maintenance or client handoff. Why this talk exists, did Steve screw something up, do I have a horror story, not quite, have I blown up sites in 20 years, absolutely. It's really about using my experience managing the team to put things in place proactively rather than have a horror story. Savings are real, table stakes, we'll keep using MCP for real work, but the guardrails cost is that we have to slow down a little, still get a massive efficiency gain but not get in trouble, momentum is what gets us in trouble, getting comfortable clicking allow, allow, always allow, forgetting it's doing real stuff, not reading the whole output. I came up with the concept of blast radius, tiering work based on potential blast radius on the site. First tier, advisory: connector does a lot, audits, reports, recommendations, plans, nothing changes on the site, we do a little. Second tier, additive: new components, new fields, drafting items, reversible if caught, maybe 50/50 or 60/40 connector versus us. Third, dangerous, structural tier: connector does very little, we do a lot more, schema changes, deletes, bulk updates, publishing, things that can really blow up the site if you click always allow. Example prompts. Design file to component, Figma or PDF or screenshot to a component. What it gets right: visual fidelity, why we click allow because it looks like the image we sent. How it fails: writes its own markup or classes, doesn't account for what we've done before. Gate: give it the systems first, then let it design, tell it about pre-built classes and systems before asking it to build. Without that gate I've seen it generate a bunch of custom code, assuming the easiest way to build a component is a custom code block, looks amazing at first glance but then you can't find anything in the style panel to tweak, causing downstream issues. Second prompt: CMS schema from a brief, build collections and fields based on a description of sections, blog, events etc. What it gets right: structure and speed, way faster than us. How it fails: field types you can't undo, whatever it thinks is necessary, if you add data you can't easily undo without starting over. Gate: approve the field table first, send a CSV or list, or ask Claude to tell you what collections and fields it'll produce before you approve. Without the gate, never a sensible mix of fields, everything rich text or everything plain text, no in between. Third example: site-wide SEO/AEO audit, advisory blast radius. What it gets right: coverage you'll never do by hand, faster than third parties. How it fails: confident false findings, Claude is very confident with every answer which can get you in trouble making unnecessary fixes. Gate: verify a few findings at random after the audit, review some random aspects, maybe rerun the audit before turning advisory into structural action. Without the gate, false negatives that prompted action, made changes that weren't necessary, costing time rather than blowing up the site. Fourth example: internal linking at scale, structural tier. What it gets right: sees the whole library at once, faster than we can. How it fails: execution has no quick rollback, if there's 1000 links and only 100 succeed, how do you roll back which worked and which didn't. Gate: it recommends, you execute, ask for a CSV to review, break work into chunks by pages or collections. Nothing observed without the gate because I knew this one would get me in trouble, so put the gates in from the start. Last example: accessibility cleanup at scale, structural. What it gets right: finds gaps quickly across everything. How it fails: satisfies the checker not the human, doesn't account for real screen readers or humans behind the monitor. Gate: alt text is human written, not unwritten, Claude can recommend a CSV or list but we write it. Without the gate, wrong alt text altogether, alt text that would score worse than none, especially for decorative images. Six rules we implement at the office. Rule one: ask for the plan before it touches anything, then read all of it, prevents clicking allow allow always allow, take a breath, don't get caught in momentum. Rule two: never start in production, common sense but not always followed, especially once trust builds, it'll work until it doesn't, always clone into staging first. Rule three: give it your system before the design, agent instructions and context, remind it about your class list, existing JavaScript, so it doesn't overwrite or cause downstream conflicts, we've had issues where it wrote JavaScript on every component causing conflicting or duplicate scripts firing multiple times because we didn't follow this rule. Rule four: scope to one page or one collection, still fast and efficient but test on one or two first, avoid the dangerous word site in a prompt covering thousands of pages, or Claude will try to do everything. Rule five: restore point before anything starts structural, similar to rule two, back it up even if you trust it, you will get burned eventually. Rule six: publish is a human action, everything before publish can be reverted or massaged but once published it's the client's, marketing's, or support's problem, make sure a human always does the actual QA and publish action, not necessarily the physical click but making sure a human reviews everything Claude or MCP did. On top of the rules, a never list: never let it choose field types, never let it name things since it'll invent its own naming convention, never let it write alt text, never let it execute across an entire collection or set of pages, never let it approve a plan we just skimmed, always pause and read. Do we tell clients how we use AI, our accountability process, who QAs things? Yes, be transparent, they'll find out anyway, the reason we hesitate isn't not wanting to be transparent but worrying clients will ask why they're paying if it's all AI, and it's the accountability layer, the QA layer, the rules that let us be transparent while showing we're still the experts managing and building the site. Recommend pairing transparency in an SOW with a named human doing QA or accountability, whether that's QA or a project manager. Created a one-pager you can scan, summarizing everything, something to pass around on Slack. Recommend looking at the tiers, figuring out your own tiers, accountability metrics for your team, and start writing gates and guardrails before doing more of this work. Going back to the title: you didn't only get a productivity tool, you got a direct report named Claude, excellent at doing stuff but needing accountability and hand-holding, you wouldn't give a junior developer all this and let them go in the corner unsupervised, there are reviews and checks. Thank you, I'll be around for questions, LinkedIn or email works too. One funny request: this is Peanut, a gift from my 14-year-old daughter when she was 2 or 3, I take Peanut everywhere I travel for work and take pictures in airports and hotels, want to take a selfie with Peanut to share with my daughter. Thank you so much, guys.