Is AI Making Us More Productive, or Are Unrealistic Expectations Pushing Us to Work More? I've been thinking a lot lately about how AI is changing the workplace, particularly for those of us in software development. I'm curious whether others are experiencing something similar. As a web developer, I've always taken pride in writing clean, maintainable code and building reusable components. Recently, I've been diving deeper into AI, agents, skills, and structured workflows. I genuinely believe AI has incredible potential to improve how we work. But I've started wondering: Has the promise of AI productivity created unrealistic expectations for the people actually doing the work? We've all heard the claims that AI can make us 5x or even 10x more productive. But does that mean developers should suddenly be expected to handle 5x or 10x the workload? I recently went through an experience that really challenged my perspective. I had three major projects with overlapping deadlines. To keep everything moving, I regularly found myself working 12-hour days, sometimes stretching to 18 hours. For one particular project, I knew I wouldn't have the time to approach the code the way I normally would. So, under pressure, I leaned heavily on AI and essentially let it cook. And let me tell you, that cooking was painful. 😂 AI got me about 60% of the way there. At first glance, the design looked decent. But once I started digging into the details, the responsiveness, fluidity, and overall user experience were nowhere near where they needed to be. What initially looked like a time saver turned into weeks of troubleshooting, refining, and reworking the output just to get to a functional product. And here's the part that really bothered me. What I would typically expect to accomplish in roughly 3,000 lines of CSS ended up becoming approximately 14,000 lines! Did the code work? Yes. Did it meet the immediate business requirements? Yes. Was it clean, readable, and maintainable? Not even close!

Hey Clief Notes fam! 👋 I'm Jason. I figured it's finally time to say hello. 🙋 A little about me: I run a few small businesses and do tech consulting on the side. 🎯 My current goal: Turning client discovery from a weeks-long process into hours or days. 💪 What I'm currently building/working on: I have a few active projects. The one I am focused on right now is for the Lyceum. It's a client discovery ICM that works through everything a client can give access to and flags what's missing or doesn't add up. 🤔 My biggest struggle or question right now: Keeping things simple. I tend to over-build, so I'd love to hear how you all keep your scope tight. Let's get it! 🚀

Im considering going live later tonight to record a video talking about edubaware at a 101 level. Would anyone be interested? Update: couldn’t make it tonight but will do one tomorrow night 9/15 at 10:00 PM EST

There's nothing quite like comp week. A brief drops, you've got seven days, and suddenly you're building something real with Claude instead of just reading about it. The deadline makes you finish. And when you post your repo, you're standing next to other people who just did the same thing, which is so much fun! Every entrant in the weekly comps gets a feedback file from @Jake Van Clief , @David Vogel, @Bas Rosario, @Don Roy and @Matthew Creamer: what worked, two fixes, and the one thing that would have moved you up. I've learned more from those files than from anything else I've done with AI. People who build this stuff for a living, reading your work line by line, every week... Amazing! Comp #15 had 7 entries. There are 54,000 of us... so most people are watching, not playing. If that's you, here's how I'd start. You won't be doing it alone: Claude is your partner the whole way through. This is a framework for how I approach these competitions... 1. Read the brief twice, then copy out the judging lines. Those checkmarks are the whole test. Everything you build should answer one of them. 2. Brainstorm with Claude, starting from what you know. Paste in the brief, tell it about your own work, and ask for ideas. A workflow from your own job beats a clever idea you'd have to learn first. Don't worry if none of Claude's ideas are right. Once you start talking ideas through, your own start showing up... 3. Keep going until you land on the idea, then turn it into a PRD. A PRD (product requirements document) is a short plan of what you're building and why. The lessons from @Bas Rosario and @Don Roy give a great shape for it. Say what it's FOR, show what good looks like (an example or two), show what bad looks like, list what it can and can't use, and say how it checks its own work: done, try again, or stop and ask a person. Claude can write it with you. 4. Write one sentence that says what done looks like before you build anything. Claude can help you sharpen it. 5. Build it as an ICM folder, then trace the path. ICM is Jake's method: the folder structure is the plan, with one file per job, so the AI reads only what it needs at each step. The ICM architect skill helps Claude lay out the folders. Then ask Claude to trace a task through it: which files it would read, in what order, and why. If the route looks wrong, the structure is wrong, and it's much cheaper to fix now than after you build. 6. Test it the way the judges will. They clone your repo fresh and try to break it. So clone it into an empty folder, follow your own README like a stranger, and run every claim you make. Ask Claude to try to break it too. 7. Say where it falls short. The judges reward that. 8. Post it with the repo link on the first line, then read your feedback file. That's where the learning happens.

Hi All, Just thinking out loud as I am accessing the Lyceum recordings instead of attending the live event but not sure if skool is the next best thing since the recordings does not have Discord server access. One of the foundation knowledge Jake and his team is making sure an ICM user understands is knowing and qualifying what to build before touching any AI tool. Fair enough - not many build houses without at least planning the details. The process is, in my own words, 1. Know your target audience/user - what are you trying to build for this group, are you trying to solve a problem, help speed up their process (is this really bothering them) - book keeper entering spreadsheet numbers to an accounting system 2. What materials or inputs do you have to help solve for the user - status reports, where do these users normally start when they do the work - the spreadsheet of numbers 3. You have to convert the starting materials to a useful outcome - numbers entered into an accounting system 4. If I deliver 2 and 3, then accounting reports can be seen faster by decision makers and business owners. Is the chain of thought correct. Can the community who saw the Lyceum suggest other examples?