jreynar

The post tracks two rather different things. AI is almost certainly the hottest topic in tech right now, just like mobile was hot after the iPhone launched or cloud was a decade ago. AI-generated text is a separate complaint, and it's the only one I think is controversial. Slop, no thanks. A human using AI tools to write better is fine by me, even if a tell or two slips through.

I already answered this, but responding led me down a path to a better answer both for me, and our product. I said last week that we were working (at this+that) on building and maintaining a db of operating knowledge for companies. A crisper answer is that we're solving the problem of "unrecorded knowledge." Apparently 42% of things known by a company are only known by one employee and three of our key features are designed to help with this but I hadn't connected the dots. 1) task extraction 2) automatic contact updating and 3) the one I wrote about before: maintaining a company's operating knowledge or "brain"

AI may indeed lead to a barbell shaped distribution - lots of people with modest skills and the need for lots of awesome people. But I don't think that's necessarily a bad thing.

One of the problems with the "middle class" in the past was that there were lots of mid-level jobs in big companies but people hit a ceiling and couldn't progress. Maybe the middle hollowing out will lead to more jobs with significant opportunity and responsibility rather than ones where you get trapped because you weren't at the company early enough or all the top jobs are filled.

I'm working on making unstructured operating knowledge maintain itself. If a customer's phone number changes, that goes in the CRM. But if a salesperson learns the customer is planning to open new locations, everyone else who talks to that customer should know, and today they mostly don't. In fact, there's probably not even a good place for that valuable nugget to be stored.

The information exists. It's in email and Slack, in threads with the customer, internal discussions, meeting transcripts. But nobody updates the customer page since the payoff is deferred. We're trying to update it automatically.

Maintenance looks doable. Cold start is the part I don't have a good answer for yet: how do you work out that a company cares about customers, competitors and products as entity types, and build those lists for them, without handing them a setup task? That's what we're tackling next.

https://www.thisandthat.chat

Reviewer burden is the right diagnosis and the rule doesn't really address it.

Oracle's own FAQ concedes that reliably telling AI content from human content is impossible. So reducing volume depends on people honestly checking the box or more likely not submitting or reviewers spotting AI tells. Some of their example tells don't seem AI-specific, just bad code smells that reviewers probably rejected for prior to gen AI.

I'm reminded of academic peer review, which has run into a similar volume problem. Since there's more writing involved, there's also a lot of slop submitted and the reviews themselves can degenerate to slop, too. It's an unsolved problem. The things that seem to be making a difference are process changes like caps on submissions per author, immediate rejection prior to review, making authors review in return, etc.

I 100% agree with this (and remember Bob from my time at Facebook, too!). Picking the right problem matters, but I also think there's an underlying quest for status that leads to a lot of productivity theatre.

People think -- and rightly in some environments -- that being busy will ensure they're valued. There's no better way to keep yourself busy than to insist on a new tool and become responsible for keeping the data in it up to date. Notion used properly can be invaluable but I've advised a couple companies where "tending the Notion garden" became someone's job despite there being no incremental value there.

The solution to the status problem is to focus on outcomes. No one cared that Bob's tool choice might've slowed him down when deciding the winner of the hackathon. And your manager shouldn't care if you use Superhuman and blaze through your mail or print it out and highlight important passages.

If you're working somewhere that gets that right, or close to right, then you can focus on picking productivity tools / approaches that genuinely matter and lead to better outcomes, ideally faster. In the era of agentic AI, there are more of them than ever before, though you have to choose wisely since there are plenty that could win a Tony for productivity theatre.

My two cents here is that if you're trying to growth hack yourself, you need to be on a platform that's also growth hacking. Building an audience anywhere is genuinely hard. Algorithmic feeds like those on LinkedIn, Facebook, etc. force you to play a game they control and that may not align with your content. Medium, substack, etc. will build your audience only to the extent that it aligns with their goals. Hosting your own blog means somehow getting traffic to it -- which might mean playing the google search game, which then depends on aligning with user queries and getting your site ranked. Or it may mean somehow driving traffic to your blog, such as from a newsletter or social site. But that brings us back to either algorithmic feeds or newsletter products. Don't think there's an easy answer here and I bet YMMV depending on the type of content you have, how much of audience you already have, etc.

I tried the reverse -- syndicating content on medium that we publish on our blog. 0 impressions, literally, for 5 posts that got some readership on our blog.

I think ACM should give everything away for free. US taxpayers pay for a lot of research and the previous administration required that government funded research be published and made freely available. See https://bidenwhitehouse.archives.gov/wp-content/uploads/2022...

The back catalog at ACM isn't subject to this requirement and nor is research that's not funded by the US government, but I completely agree with the spirt of this law: research should be shared knowledge that other intelligences can build upon, whether human or machine. If you want to limit access to what you've done, don't publish it. Get a patent if that's an option, or keep it internal to a company as a trade secret.

Completely agree. The worst sort of manager is the one who wants to stay "high level" and proposes things that either aren't possible or are vastly harder than their idea to "just do X" suggests. And the root cause is them not knowing the details.

What gets me excited about AI is that you can hand off some of the detailed work, specifically the repetitive sort. As a sales person, you ought to know how to create a quote for a customer. But creating the 50th one for the same product for the same number of seats becomes drudgery. As a software engineer, you should know how to fix (or at least you should have back in the day) a buffer overrun, but it gets tedious to fix hundreds of them (and I know since I was at Microsoft when we paused Office development to do just that, for months). I bet there's an example for every role.

And the benefit of having an AI handle those details -- not the first time, but once you're a master and the AI has become trusted -- is that you can focus on things that require a human being's attention. More creative, more collaborative tasks. Conveniently those tend to be more rewarding than fixing another teensy bug or writing another formulaic email.

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.