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!

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.

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

I am not new to software or AI, but have been trying to wrap my head around ICM for a while. Recently ran the script-to-animation workflow, asked it to make up a silly theme. Whadaya know, it worked. :) What I'm interested in, though, is whether ICM can be used for full SDLC. Let's say a game. Hypothetically (wink, wink.) Having trouble figuring out how to break it down, and if the middle "loop" (implement features until done, to oversimplify it) even fits ICM. The planning could probably be a workflow, at least. So I don't know if that should be split off as a separate workflow, create specs, and then - what? Has anybody used ICM for end-to-end software development? Did it work? Challenges? Tips?

A therapist asked me if I could shift my mindset from ‘achievement’ as the goal to ‘effort’ as the goal, and I can’t stop thinking about that. I’m aware that I look like a complete psychopath from the outside. I trained myself to work 80-90 hours a week after realizing everything in business takes so much more effort than anyone ever accounts for. In fact, it is so common that people underestimate how much work or how long something will take that someone named a law for it. Hofstadter's Law: "It always takes longer than you expect, even when you take into account Hofstadter's Law." Nobody realizes they are underestimating everything, and everyone is doing it constantly. It’s a wonder that humans can be as competent as we are and still be completely naive to our own patterns of behavior. Unfortunately, there are real consequences for being naive, at least at this time in history. Throughout human existence, entrepreneurship has been a few people sprinting to make progress while the rest of the world stands still or bursts into chaos. From an entrepreneurial stand point, we’ve been running a marathon, to eventually cross the finish line into an age of abundance. Every entrepreneur is trying to create their own little ecosystem of abundance, and on a long enough timeline those little ecosystems will pop up more and more, getting more resilient with each market change. This cycle will repeat until we have created so much value that we can automate goods and services. Once goods and services are automated (which is what an economy is built on) we will have achieved abundance for the first time. That comes with its own set of problems, which I’ll gladly take over our current issues, but until then, we’ve got to innovate our way out of this broken world. WE UNDERESTIMATE EFFORT Every entrepreneur that tried to make it will tell you that it’s so much harder than they could have ever imagined. Small business owners, which are the majority of business owners, are typically operating with very limited resources. The fact that anyone can make a company run at all is amazing, considering the enormous effort and resources that takes. It’s the most surprising lesson of entrepreneurship—realizing that the entire population is underestimating the amount of work it takes to make society function, let alone improve.