Author here. People are speculating about when the first solo founder will build a billion dollar business. I think it ties back to Coase's "The Nature of the Firm" and the question of why companies exist at all. The gig economy has been around a while and transaction costs have dropped dramatically, yet no unicorn was ever built on gig economy labor alone. I suspect that's because coordination is at least as important as direct transaction costs. That's what AI can transform, but not just any AI. It specifically needs to be AI tied into comms, so the solo founder isn't single-handedly coordinating an army of agents, contractors, and vendors.
First, I wonder about the value of the study about endoscopies. Comparing number of adenomas found before and after potential "de-skilling" with AI assumes the rate of adenomas is constant, which doesn't necessarily seem safe. Not sure if the issue is with the study or the summary, but measuring how well the population did compared to reference analyses seems like a much better study design and would give me more confidence that there had actually been a change in skill. I also wonder if the time allotted for reading was reduced or people felt more pressure when reading scans the old fashioned way since they were probably read quickly by the AI, that's a potential confounding factor.
Second, I'm not surprised you can find measurable de-skilling due to AI. But I bet you could find de-skilling related to spell checkers and calculators back in the day, but no one I know today suggests we shouldn't use word processors and ought to count on our fingers and toes or do long division. There's always a tradeoff around what skills and knowledge is genuinely important to be a domain expert and what we can outsource to technology. We're in a transitional phase right now not only because the tech is new but because it's changing so fast. In a few years, once we're further up the adoption curve and the pace has settled down in some domains, I bet we'll land on a way to use AI for coding and doctoring (or in some domain where AI progress has stabilized) that requires a combination of knowledge and skills but that we'll have gotten comfortable with people no longer needing to know or do things that today are considered core to the job.
I couldn't even get the video to play. Nonetheless I'm sort of meta excited by this product. It reminds me of the apocryphal "customers want a faster horse" thing associated with Henry Ford. Chat bolted onto an IDE was a great starting point, but if AI is writing the code, do even need an IDE? This doesn't go that far but it sounds wacky enough that it least it's trying to break out of the IDE mold. Not idea what we need instead of an IDE but if an IDE with chat is a faster horse then I'm really curious what the car looks like. Is it just reviewing UI? Even that seems like a short term solution since I'm not sure how long code reviewing will be around as agents get better at it and it might make more sense to do fractional launches and gather data than spend precious human time looking for a bug/needle in a diff / haystack...
Articles like this are exactly why I doubt that SWE jobs are going away. The SWE job of 2026 doesn't look like one from 2020, let alone 1990 so why would anyone believe the false dichotomy that either the SWE jobs of 2026 will remain or all be eliminated? I worked at Google a zillion years ago when the idea of reviewing all code was novel. Before that, when I worked at MS things mostly didn't get reviewed until the end of the project when the stakes were high because code got burned onto a CD and put in a box. The way SWEs spent their time changed radically from 2000 to 2004 and I think for the better since it increased shared understanding and fostered more collaboration.
If AI writes the code and humans spend more time reviewing it, that might not be a bad thing, but when the AI code is good enough, people are going to view thorough reviews as optional. Then the job of a SWE will look very, very different than before since SWEs won't write much code or spend much time reviewing it. The IDE may go the way of the dodo. And maybe the focus will move to setting up the goals and tests that keep the AI coding team on task. Maybe SWEs will spend more time architecting since they're likely to know where projects are heading and won't want AI to rewrite things as goalposts legitimately move. Maybe more will be spent exploring: build it one way and another and another and compare and generate new ideas from the different approaches.
I have no better idea than anyone else, but I'd be heavily against the role going away and in favor of it evolving, like it's done many times before, though perhaps never as rapidly as it is right now.
It's nice to see an explanation of how they think you should use Claude for a host of different job functions / aspects of building a business, but the tone makes it seem like founding a startup is something you wake up one morning and just decide to do instead of, say, going to the park. Over coffee, you ask Claude about your idea and when it tells you "you're a genius" you're off. That's silly in so many ways. Statements like this "Validation cycles that used to take months now take afternoons" have an element of truth but ring with false promise.
And that relates to the lack of timelines and focus on how long things took around 2020 BC, that is Before Claude. Building a startup isn't like having a lemonade stand as a kid where you just don't bother to do it if you forget to buy lemons or it's rainy or something more fun comes along. There's a significant compound interest element to startups that's easy to overlook. Your codebase grows over time and so does your feature set and that collection of features attracts customers in a way one thing might not. You learn as go, of course, too.
This seems particularly relevant to the GTM section, which I was particularly amused by since that's what I'm focused on right now. It's a long game. Your blog post doesn't get found by anyone in Google until you've built up your SEO mojo, your LinkedIn post isn't read without the followers you need to accumulate and your content has to get engagement for people to see it even then, you don't start off line with a million followers on X, etc.
I'm in the same boat. I've done a lot of work and hobby engineering projects and haven't run of tokens since moving to Claude max. I also haven't needed to let anything run over night because it needed hours to do the coding or design work.
Surprisingly, I have had one much longer run refactoring our marketing website. We have a lot of blog posts that were written before we had more detailed style and tone guidelines. I wanted to make everything consistent but it took 15 or 20 minutes per post because it required a number of passes through each post to fully enforce the guidelines and an overnight run was required. That was quite a surprise since the posts aren't terribly long...
Ugh. I'm sure we're not the only company that's going to face the difficult decision to either stay with Opus 4.8, switch to a different model provider or update and significantly weaken our terms of service around no model re-training, not sending data to third parties and the like. I understand why Anthropic wants to do this but I'd be much more comfortable with it if the data never made it to Anthropic unless an analysis Amazon ran, maybe even using tools from Anthropic, determined that there was something to look at. That'd be an easier carve out in an enterprise Terms Of Service / Privacy Policy.
I've built a handful of things, most of which mirror commercial / open source products but for which I had particular requirements that were hard to satisfy (like a wine cellar tracker where I wanted recommendations about purchases from an email list). The one that seemed most unique was a fitness / health tracking thing. There are lots of apps for logging data (like Strava), lots of coaching apps (training peaks and others), including AI coaching apps, and tools focused on recovery (whoop), but I couldn't find anything that would help me understand the drivers of my level of fitness. I run, bike, lift weights and do Pilates and wanted to understand where I got the most bang for the buck in terms of cardio and VO2 max. Turned out to be a fairly tricky proposition with a detour through understanding the limitations of measuring your heartrate with an apple watch compared to a chest strap. But I ended up getting a pretty good picture of how best to use limited fitness time in both the summer (when outdoor activities are easy) and winter (when I'm stuck inside more often due to snow, cold weather and gritty roads that making running questionable). I might open source it for other people who are as nerdy about fitness as I am...
I may be biased because I work on an AI powered enterprise productivity product, but while I agree they have PMF right now, I wonder whether people's use will evolve in ways that undercut the current PMF. Chatting with an assistant is great if there's no product with tailored UI available that also has the AI capabilities. But once there is, I suspect people may switch, or more importantly enterprises may switch because they'll get the benefits of AI without the clunkiness of a chat only interface. We may see another DOS -> GUI-like shift.
More specialized products will consume tokens but their builders will be incented to optimize token use and switch models as costs and capabilities change. And if search engines become more AI capable, and Google is clearly striving for this, then they may have pressure from two sides that could squeeze the number of use cases for AI chat. AI coding isn't going anywhere and nor is the need for AI in general but I wonder if the products will have to evolve significantly to maintain the current levels of PMF. And then there's the question of profitability...
I'm going to give people the benefit of the doubt here. It reminds me of the Google search phenomenon others have mentioned, which culminated in the joke website "let me google that for you." But, I don't think the cause is necessarily that people are dumb or lazy. Both are factors, but another big one is that people are overwhelmed at work. Another question coming in may not be viewed as an opportunity to learn or help a colleague but as just another task to complete as quickly as possible so the task mountain doesn't grow higher. I'd like to think that we'll eventually use AI to automate a lot of the mundane stuff at work so people have the opportunity to dig into questions from colleagues and provide real answers and genuinely have a conversation when they do. I realize that's pretty optimistic and it may take a while to get there but people stopped sending me google search results years ago. That phenomenon was relatively short-lived and hopefully this one is too.
Another problem with perception of AI tools, for coding and other things, is that people often adopt a one-size-fits-all view. If Claude/Codex whatever can fix a bug in my tiny hobby project then it's going to revolutionize all software engineering. If it can write a haiku, then it the great American novel will be dead in a few years and the novelists will starve.
There aren't many truly general purpose tools so viewing things this way seems like either a fantasy or an over-reaction. And if nothing else the processes we use will have to change along with the tools.
It's the early days so we still have a lot to figure out but one of the most significant is which tools are appropriate for what sort of tasks. I've had good luck refactoring a small code base, building some small hobby projects and building features for our company's product. But, I've also dodged bullets doing greenfield development on some features where Claude (my default) has made what seemed like sound choices early on, and which I approved of, only to build something fragile or with unforseen consequences. I haven't quite figured out what distinguished those situations from the successful ones but I'm trying. But it's complicated by the fact that things are evolving quickly and yesterday's failure mode isn't the same as today's and, for that matter, yesterday's successes aren't guaranted to be repeatable today.
I'm sure things could be better and maybe we've gotten lucky or perhaps being part of the AWS startup program bumps you to the front of the queue but we've had two recent issues -- both with cloudfront -- that were dealt with fairly promptly. Not quite as quick as the timeline they suggested but very hard to complain about when we're paying for support and AWS services themselves with credits from their startup program.
Web: https://www.thisandthat.chat LinkedIn: https://www.linkedin.com/in/jeffreynar/ X: @jreynar
jeff [at] thisandthat.chat