[{"data":1,"prerenderedAt":459},["ShallowReactive",2],{"navigation":3,"index":22,"index-blogs":112},[4],{"title":5,"path":6,"stem":7,"children":8,"page":21},"Blog","\u002Fblog","blog",[9,13,17],{"title":10,"path":11,"stem":12},"Build Today, Learn Tomorrow: In Defense of the Slop Fork","\u002Fblog\u002Fbuild-today-learn-tomorrow-in-defense-of-the-slop-fork","blog\u002Fbuild-today-learn-tomorrow-in-defense-of-the-slop-fork",{"title":14,"path":15,"stem":16},"Replacing a 15MB Calendar Dependency With 76KB of Our Own","\u002Fblog\u002Fkilled-15mb-calendar-dependency-with-claude-plugin","blog\u002Fkilled-15mb-calendar-dependency-with-claude-plugin",{"title":18,"path":19,"stem":20},"The Effort Didn't Disappear — It Changed Shape","\u002Fblog\u002Fthe-effort-didnt-disappear-it-changed-shape","blog\u002Fthe-effort-didnt-disappear-it-changed-shape",false,{"id":23,"title":24,"about":25,"blog":29,"body":32,"cta":33,"description":53,"experience":54,"extension":94,"hero":95,"meta":103,"navigation":104,"path":106,"seo":107,"stem":110,"__hash__":111},"index\u002Findex.yml","Hey, I'm Zain Wania, Developer",{"title":26,"description":27,"body":28},"About Me","I build software — full-stack, with an eye toward user experience and long-term maintainability.","Currently Staff Engineer at ContactMonkey, where I architect systems for a ~20-person engineering org and lead AI-powered product development. Based in Toronto.",{"title":30,"description":31},"Latest Articles","Some of my recent thoughts",null,{"title":34,"description":35,"topics":36,"link":49},"Let's Start a Conversation","I enjoy discussing how teams can level up their engineering practices and adopt AI-driven workflows.",[37,41,45],{"title":38,"description":39,"icon":40},"Creating a Design System","Building cohesive, scalable component libraries that unify your product experience.","lucide:palette",{"title":42,"description":43,"icon":44},"AI for Engineers & Beyond","Introducing AI-powered workflows for engineering teams and the broader organization.","lucide:cpu",{"title":46,"description":47,"icon":48},"Internal AI Knowledge Base","Making your team's collective knowledge accessible and searchable through AI.","lucide:library",{"label":50,"to":51,"color":52},"Get in Touch","mailto:zain@wania.dev","neutral","I build full-stack web applications with a focus on user experience, design systems, and AI-powered products. Based in Toronto.",{"title":55,"items":56},"Work Experience",[57,76,85],{"date":58,"company":59,"roles":63},"Oct 2019 - Present",{"name":60,"url":61,"color":62},"ContactMonkey","https:\u002F\u002Fcontactmonkey.com","#00A4EF",[64,68,72],{"title":65,"date":66,"description":67},"Staff Engineer","Apr 2024 - Present","Architecting systems and setting technical direction for a ~20-person engineering organization. Co-architected the AI email checker; independently designed and built the internal knowledge base agent and MCP server.",{"title":69,"date":70,"description":71},"Technical Lead","Feb 2022 - Apr 2024","Led the frontend platform team and drove design system adoption",{"title":73,"date":74,"description":75},"Senior Software Engineer","Oct 2019 - Feb 2022","Core contributor to the product's Vue.js frontend and internal tooling",{"date":77,"company":78,"roles":81},"Jan 2018 - Sep 2019",{"name":79,"color":80},"Ample Organics","#2ECC71",[82],{"title":83,"date":77,"description":84},"Software Developer","Built the Vue.js frontend, introduced E2E testing, and established the component library from scratch",{"date":86,"company":87,"roles":90},"Feb 2016 - Apr 2017",{"name":88,"color":89},"Exact Media","#95A5A6",[91],{"title":92,"date":86,"description":93},"Full Stack Developer","Full-stack development across client projects with Rails and JavaScript","yml",{"links":96,"images":102},[97],{"label":98,"to":51,"color":52,"variant":99,"size":100,"icon":101},"Contact Me","solid","md","i-lucide-mail",[],{},{"title":105},"","\u002F",{"title":108,"description":109},"Zain Wania - Developer","Developer based in Toronto, Canada. Building quality software with Ruby on Rails, Vue.js, and modern web technologies.","index","aNTriiKfjH7PkfDsUdmovK41b8RHa3pNnqDT36M7On0",[113,189,322],{"id":114,"title":10,"author":115,"body":117,"date":181,"description":182,"extension":100,"image":183,"meta":184,"minRead":185,"navigation":186,"path":11,"seo":187,"stem":12,"__hash__":188},"blog\u002Fblog\u002Fbuild-today-learn-tomorrow-in-defense-of-the-slop-fork.md",{"name":116},"Zain Wania",{"type":118,"value":119,"toc":178},"minimark",[120,124,127,130,133,136,139,142,145,147,150,153,161,164,167,169,172,175],[121,122,123],"p",{},"There's a gap in the Vue ecosystem. Streamdown — a clean, minimal markdown streaming renderer — exists for React. It works great. But if you're building in Vue and you want the same thing, you're on your own. Copy-paste Stack Overflow answers, roll something yourself, or just go without.",[121,125,126],{},"I went with option four: I forked it, pointed AI at it, and got a Vue port working in an afternoon.",[121,128,129],{},"Is the code beautiful? No. Did I write every line from scratch with full understanding of each decision? Also no. Is it a \"slop fork\" in the way people use that term to mean AI-generated, low-effort, probably-shouldn't-exist code? Honestly, kind of.",[121,131,132],{},"But it works. And before I built it, nothing did.",[134,135],"hr",{},[121,137,138],{},"Slop has earned its reputation. GitHub is flooded with AI-generated repos that are half-finished, wrong in subtle ways, and exist mainly because someone thought \"I could make a tool for that\" and let a chatbot do the rest. Nobody reviews it, nobody maintains it, and it quietly rots while people star it thinking it might be useful someday. That's the bad version of this story.",[121,140,141],{},"But I think we're conflating two different things: slop that shouldn't exist, and slop that fills a real gap. The first is noise. The second is just an unglamorous solution to an actual problem.",[121,143,144],{},"The Vue port of Streamdown is the second kind. The need was real. The gap was real. And now there's something where there was nothing.",[134,146],{},[121,148,149],{},"Here's the part I find more interesting though: AI changed the order of operations.",[121,151,152],{},"Before, if you wanted to build something you didn't fully understand, you were mostly blocked. You had to learn enough to build it, which meant the thing either got built slowly, got built badly, or never got built at all. The learning was a prerequisite.",[121,154,155,156,160],{},"Now you can flip it. Build today, learn tomorrow. Ship the thing, get it working, and ",[157,158,159],"em",{},"then"," go back and understand what it's actually doing. The learning still happens — it just happens on a working foundation instead of a blank page.",[121,162,163],{},"That's not laziness. That's a different workflow. And for filling ecosystem gaps — stuff that's niche enough that nobody's going to write a polished OSS library for it — it's actually kind of powerful.",[121,165,166],{},"I'm not going to pretend I have perfect command of every piece of that Vue port. But I understand it well enough to use it, debug it when something breaks, and improve it over time. That's more than I had before I built it. The gap between \"I used AI to build this\" and \"I don't know what I built\" is wider than people assume.",[134,168],{},[121,170,171],{},"The honest version of this post isn't \"AI-generated code is fine, actually.\" It isn't. A lot of it isn't fine. You still have to know enough to evaluate what you're getting, to know when something is subtly broken, to make real decisions about tradeoffs. AI doesn't replace that judgment — it just lowers the floor on what you need to get started.",[121,173,174],{},"What it does give you is permission to solve your own problem today, even if your understanding is going to catch up tomorrow.",[121,176,177],{},"The Vue ecosystem needed a Streamdown port. Now it has one. It's a slop fork. It works. I'll take that trade.",{"title":105,"searchDepth":179,"depth":179,"links":180},2,[],"2026-04-02","I forked a React library, pointed AI at it, and got a Vue port working in an afternoon. It's a slop fork. It works. I'll take that trade.","https:\u002F\u002Fimages.pexels.com\u002Fphotos\u002F11035471\u002Fpexels-photo-11035471.jpeg?auto=compress&cs=tinysrgb&w=1260&h=750&dpr=1",{},4,true,{"title":10,"description":182},"eHOkKsPkio7n8rSo_L7vTS2HOIT1y7aXEbeI1wr97wM",{"id":190,"title":18,"author":191,"body":192,"date":315,"description":316,"extension":100,"image":317,"meta":318,"minRead":319,"navigation":186,"path":19,"seo":320,"stem":20,"__hash__":321},"blog\u002Fblog\u002Fthe-effort-didnt-disappear-it-changed-shape.md",{"name":116},{"type":118,"value":193,"toc":308},[194,197,204,206,211,218,225,228,232,239,242,245,252,256,259,262,265,268,272,278,285,288,292,295,302,305],[121,195,196],{},"There's a new class of product showing up everywhere. You can feel it before you can name it. The landing page is clean but says nothing. The app works but solves a problem nobody has. The design is polished in the way stock templates are polished — technically correct, spiritually empty. It was made in a weekend, and it feels like it.",[121,198,199,200,203],{},"AI made it possible to go from idea to ",[157,201,202],{},"something"," faster than ever. But \"something\" isn't a product. And the gap between those two things is getting wider, not smaller.",[134,205],{},[207,208,210],"h2",{"id":209},"the-typing-was-never-the-hard-part","The typing was never the hard part",[121,212,213,214,217],{},"Here's the misconception I keep seeing: people think AI removed the need for skill. It didn't. It removed the need for ",[157,215,216],{},"typing",". Those are not the same thing.",[121,219,220,221,224],{},"Knowing the syntax for a React component was never the bottleneck. Understanding ",[157,222,223],{},"why"," you'd split state a certain way, when a component is doing too much, why this abstraction will bite you in six months — that was always the real work. The characters on screen were just the output of that thinking. AI can generate the characters. It can't generate the thinking.",[121,226,227],{},"Same thing in design. AI can produce a layout in seconds. But knowing that a user's eye will miss your CTA because the visual hierarchy is fighting itself? That comes from reps. From shipping things and watching people actually use them. No model gives you that.",[207,229,231],{"id":230},"you-dont-need-six-books-anymore-you-still-need-to-learn","You don't need six books anymore. You still need to learn.",[121,233,234,235,238],{},"The old path to building something was brutal. Seven-hour YouTube tutorials. Five Udemy courses. Three outdated Stack Overflow threads. A book that was already behind by the time it shipped. You had to grind through all of that just to get ",[157,236,237],{},"started",".",[121,240,241],{},"AI genuinely changed that. You can scaffold a project, generate boilerplate, get unstuck on a syntax problem in seconds instead of hours. The barrier to entry dropped, and that's a real, good thing. More people can build now. More ideas get to see daylight.",[121,243,244],{},"But somewhere along the way, people started confusing \"lower barrier to entry\" with \"no barrier at all.\" They skipped the learning entirely and went straight to shipping. And what shipped was... fine. Technically functional. Completely forgettable.",[121,246,247,248,251],{},"Because the learning wasn't just about acquiring the ",[157,249,250],{},"ability"," to type code. It was about developing taste. Judgment. An intuition for what users actually need versus what sounds cool in your head at 2am. You can shortcut the mechanics. You cannot shortcut that.",[207,253,255],{"id":254},"experience-still-compounds","Experience still compounds",[121,257,258],{},"Here's what's actually happening: AI is a multiplier, not a replacement. And multipliers are only as good as the base number.",[121,260,261],{},"A senior engineer who deeply understands system design, who's been burned by bad abstractions, who knows what \"simple\" actually means — hand that person AI tools and they become terrifying. They move at 3x speed with the same quality. They use AI to skip the tedious parts so they can spend more time on the parts that matter: architecture, edge cases, the subtle decisions that separate software that works from software people love.",[121,263,264],{},"A beginner with the same tools ships faster too. But they ship faster in the wrong direction. They generate code they can't debug. They build features they can't extend. They create technical debt at a pace that used to take entire teams months to accumulate.",[121,266,267],{},"The gap between these two outcomes is the gap between someone who learned and someone who skipped to the end.",[207,269,271],{"id":270},"the-idea-to-product-gap-is-growing","The idea-to-product gap is growing",[121,273,274,275,238],{},"This is the part that's counterintuitive. AI was supposed to make it easier to go from idea to product. In some ways it did. But in another, more important way, it made the distance ",[157,276,277],{},"wider",[121,279,280,281,284],{},"Because now everyone has the first 60%. The scaffolding, the boilerplate, the MVP shell — that's table stakes. The remaining 40% — the polish, the coherence, the decisions that make something feel ",[157,282,283],{},"intentional"," — that's where the real product lives. And that 40% still requires everything it always did: skill, taste, experience, and the kind of effort that doesn't have a shortcut.",[121,286,287],{},"More people than ever can get to \"almost there.\" Fewer people than ever seem to push past it.",[207,289,291],{"id":290},"the-effort-changed-shape","The effort changed shape",[121,293,294],{},"I'm not arguing against using AI. I use it constantly. It's the best thing that's happened to my workflow in years. But I use it the way a carpenter uses a nail gun — it makes me faster at the thing I already know how to do. I wouldn't hand a nail gun to someone who doesn't know where the studs are and expect a house.",[121,296,297,298,301],{},"The value of typing every character went down. Fine. The value of knowing ",[157,299,300],{},"which"," characters to type, and why, and what they mean in the context of a system that needs to hold together — that didn't move at all. If anything, it went up. Because now that everyone can produce output, the only differentiator is whether that output is any good.",[121,303,304],{},"The effort didn't disappear. It just changed shape. And the people who recognize that — who use AI to bridge their skills instead of replace them — are building things that are actually worth using.",[121,306,307],{},"Everyone else is just generating.",{"title":105,"searchDepth":179,"depth":179,"links":309},[310,311,312,313,314],{"id":209,"depth":179,"text":210},{"id":230,"depth":179,"text":231},{"id":254,"depth":179,"text":255},{"id":270,"depth":179,"text":271},{"id":290,"depth":179,"text":291},"2026-03-28","AI removed the need for typing, not the need for skill. The gap between idea and product is growing, and the people who recognize that are building things actually worth using.","https:\u002F\u002Fimages.pexels.com\u002Fphotos\u002F3861969\u002Fpexels-photo-3861969.jpeg?auto=compress&cs=tinysrgb&w=1260&h=750&dpr=1",{},5,{"title":18,"description":316},"6oeOTltMTsZj0m6XFpiXG3DnEiQhOReVxhU2JWSJmYQ",{"id":323,"title":14,"author":324,"body":325,"date":452,"description":453,"extension":100,"image":454,"meta":455,"minRead":456,"navigation":186,"path":15,"seo":457,"stem":16,"__hash__":458},"blog\u002Fblog\u002Fkilled-15mb-calendar-dependency-with-claude-plugin.md",{"name":116},{"type":118,"value":326,"toc":447},[327,330,333,335,339,342,345,348,351,358,361,368,370,374,377,380,408,415,418,421,423,427,430,433,436,439],[121,328,329],{},"There's a specific kind of developer pain that comes from working with a third-party UI library that costs money, fights you on every style change, and somehow weighs more than your entire app's feature code combined. For us, that library was Bryntum Calendar. And after months of quietly suffering, we finally ripped it out.",[121,331,332],{},"Here's how we did it - and why the messiest tool in my toolkit ended up being the most useful.",[134,334],{},[207,336,338],{"id":337},"the-vue-calendar-ecosystem-is-rough","The Vue Calendar Ecosystem Is Rough",[121,340,341],{},"Before I get into Bryntum specifically, I need to set the scene - because the whole situation only makes sense with that context.",[121,343,344],{},"If you're building a React app and need a full-featured calendar, you have real options. FullCalendar has solid React support. The path exists. In Vue - and especially Nuxt - the landscape is genuinely rough. You start googling and pretty quickly you're looking at libraries with last commits from 2021, wrappers around jQuery plugins, or things that technically have a Vue adapter but clearly weren't designed with Vue in mind. TypeScript support that ranges from \"grudging\" to \"why did they even ship types.\" APIs that feel like they were designed by someone who hated documentation. Event handling that requires understanding three layers of abstraction before you can do anything useful.",[121,346,347],{},"So when we landed on Bryntum, it wasn't naive - it was \"this is one of the few things that actually works.\" Except then it doesn't, kind of.",[121,349,350],{},"Bryntum is full-featured, no question. Recurring events, drag-and-drop, resource views - it does a lot. But a few months in you start finding the edges. The styling system is entirely its own world: custom theme engine, its own CSS variables, strong opinions about how everything looks. Want it to match your design system? You're not customizing it, you're fighting it - overriding generated class names and hoping nothing breaks. The TypeScript support has that same bolted-on energy as the rest of the ecosystem, autocomplete that ghosts you at the wrong moment. And it's a paid license, which is fine when you're getting value, but starts feeling heavy when you're spending two hours on a CSS change that should take ten minutes.",[121,352,353,354],{},"Then you ask the question you should've asked earlier: ",[355,356,357],"strong",{},"what are we actually getting for 15MB?",[121,359,360],{},"Turns out - a Gantt chart renderer, resource histograms, a spreadsheet module, a full enterprise scheduling engine. We were using maybe 10% of what we were shipping. Bryntum isn't a calendar, it's an enterprise scheduling platform, and we were awkwardly extracting the calendar slice while the rest came along for the ride. Forever. In our bundle.",[121,362,363,364,367],{},"Our in-house replacement ended up at ",[355,365,366],{},"76KB."," The whole thing - event rendering, date navigation, grid layout, all of it. Not because we did anything clever, but because we only built what we needed.",[134,369],{},[207,371,373],{"id":372},"how-we-built-it-and-what-helped","How We Built It (And What Helped)",[121,375,376],{},"We're already on Nuxt UI across the codebase, so the primitives were already there - buttons, inputs, dropdowns, popovers. The calendar-specific logic turned out to be the smaller part of what Bryntum was providing. We assembled what we needed from components we already trusted and wrote the calendar pieces ourselves. Styleable without therapy. Fits the design system natively. Still has some edge cases we're ironing out, but it's ours.",[121,378,379],{},"The part I'm both proud of and slightly embarrassed by: I used my own Claude Code plugin to help with the migration.",[121,381,382,383,390,391,396,397,402,403,407],{},"It's called ",[384,385,389],"a",{"href":386,"rel":387},"https:\u002F\u002Fgithub.com\u002FZainW\u002Fai-plugins",[388],"nofollow","auto-research",", and it's my own take on an idea that's been floating around in certain corners of the AI\u002Fdev world. The lineage goes: Andrej Karpathy's thinking on autonomous research-driven coding -> ",[384,392,395],{"href":393,"rel":394},"https:\u002F\u002Fgithub.com\u002Fnicholasgasior\u002Fpi-autoresearch",[388],"pi-autoresearch"," as an early implementation -> and then ",[384,398,401],{"href":399,"rel":400},"https:\u002F\u002Fx.com\u002Ftobi\u002Fstatus\u002F2032212531846971413",[388],"this tweet from Tobi Lutke"," that kind of broke my brain a little. Tobi ran ",[404,405,406],"code",{},"\u002Fautoresearch"," on Shopify's Liquid codebase and got 53% faster combined parse+render time and 61% fewer object allocations. His take: \"This is probably somewhat overfit, but there are absolutely amazing ideas in this.\" That was enough for me to start building my own version.",[121,409,410,411,414],{},"I'll be the first to say mine is rough around the edges. But here's what it does - when you run ",[404,412,413],{},"\u002Fresearch \u003Ctask>",", it kicks off a six-step pipeline: parse the task, spawn 3-5 parallel subagents to investigate approaches (web search + codebase analysis simultaneously), synthesize and rank what they found, implement using Claude Opus, verify against your toolchain, then auto-fix failures up to a configurable retry limit. It also persists session state so if it gets interrupted you don't lose everything.",[121,416,417],{},"For the migration I used it to front-load the thinking. Instead of manually digging through Bryntum's event model and figuring out what Nuxt UI components could replace what - I described the task, let the subagents go wide, and got back a ranked list of approaches with actual tradeoff reasoning. The implementation was smoother because the research wasn't skipped.",[121,419,420],{},"Is it production-grade? No. \"Scuffed and useful\" is an accurate description. But that's a totally valid category of tool.",[134,422],{},[207,424,426],{"id":425},"ai-is-putting-pressure-on-bad-software","AI Is Putting Pressure on Bad Software",[121,428,429],{},"Here's the broader take: a lot of the component libraries teams have been locked into for years aren't actually good. They were just the least bad option at a time when building alternatives was expensive and slow. The switching cost was high, the build cost was higher, and so mediocre software got to keep collecting license fees.",[121,431,432],{},"AI is changing that math. I'm not saying it writes perfect code - it doesn't. But it's genuinely good at producing UI components that are visually clean, properly typed, and styled the way you actually want. The gap between \"use the library\" and \"build it yourself\" used to be enormous. That gap is shrinking fast, especially on the visual and styling side where a lot of these tools have always been weakest.",[121,434,435],{},"The pressure this puts on component providers is real. If your moat is \"we did the hard work so you don't have to\" - but that work is measurably easier now - you need something else going for you. We asked a simple question about our bundle. The answer was uncomfortable. And replacing it wasn't the massive project it would've felt like two years ago.",[121,437,438],{},"That's not an argument for building everything yourself. Sometimes the library is genuinely the right call. But the bar for \"is it worth replacing\" just got lower, and some things that cleared it before might not anymore.",[121,440,441,442,446],{},"The plugin's at ",[384,443,445],{"href":386,"rel":444},[388],"github.com\u002FZainW\u002Fai-plugins"," if you want to try it. Lower your expectations appropriately - it's a work in progress. Aren't we all.",{"title":105,"searchDepth":179,"depth":179,"links":448},[449,450,451],{"id":337,"depth":179,"text":338},{"id":372,"depth":179,"text":373},{"id":425,"depth":179,"text":426},"2026-03-22","How replacing Bryntum Calendar exposed the cost of heavyweight UI dependencies, and how a rough internal Claude plugin helped speed up the migration.","https:\u002F\u002Fimages.pexels.com\u002Fphotos\u002F270348\u002Fpexels-photo-270348.jpeg?auto=compress&cs=tinysrgb&w=1260&h=750&dpr=1",{},7,{"title":14,"description":453},"h16eKjAXFSksCh0Vfb2ICzHL_Pu-L7zsdVPbHX6SFAc",1776374060697]