Honest question: Do you actually read any of these notes? I think there is a fundamental flaw with not taking notes. I'm convinced taking notes forces you to properly consider what is being said and you store the information in your brain better that way.

Taking notes during meetings isn't to improve understanding, or to "read" afterwards.

They're a record of what was discussed and decided, with any important facts that came up. They're a reference for when you can't remember, two weeks later, if the decision was A and B but not C, or A and C but not B.

Or when someone else delivers the wrong thing because they claim that's what the meeting decided on, and you can go back and find the notes that say otherwise.

I probably only need to find something in meeting notes later once out of every twenty meetings. But those times wind up being so critically important, it's why you take notes in the first place.

Still I think it's better to discuss "action points" in that case and give a clear owner to those points. This always helps me to understand who's accountable and what actions actually need follow up.

Notes do. Ideally there is a meeting owner who produces official notes and emails them to everyone, but frequently that never happens. And when it does happen, sometimes they're wrong and you need to correct them.

Which is why you need your own meeting notes. Plus, like I said, there are facts that come up that you want to document as well, that aren't part of the action items, but have value.

I think the person you're replying to is suggesting that the shared place for recording these things in a medium-large software department would be in project tracking software like Jira or Github Projects.

The kind of stuff stored in Jira is a very specific subcategory of all the types of things that get mentioned and decided in meetings. It doesn't cover all of it, not even close. And the person putting the information in might also get part of it wrong, that happens surprisingly frequently. It's not a substitute for personal meeting notes.

Yes, this is like listening a guided meditation in 2x speed because it is faster.

Isn't that pretty much the whole selling point of AI coding tools?

Does anyone know if a plugin for this?

Like, a history buff could just tell the LLM "quiz me on the Taiping Rebellion, who what where when and why."

The LLM then enters this instruction into an API that handles the spaced repetition data and algorithms.

The LLM could pull that API daily and quiz you daily.

Actually knowing all this stuff sounds so much better than having a bunch of notes in a fancy graph.

For learning new material, make your LLM assume a Socratic position. Kagi Assistant has a custom Study model that does this. The key is causing the model to increase your friction (causing learning and memory) instead of decreasing it.

I suspect it would be less effective to learn similar-yet-slightly-different LLM-generated content generated every time you want to study.

When the LLM enters the "card" into the API it would define the required information, and then every time it would ensure you cover the required information. You could tell the LLM, "make sure I remember the date of this historical event", and then the LLM would ensure you mention the date when answering the card. If you get the date wrong, then it does the API equivalent of pressing "wrong / again" in Anki.

It also lets me ask questions like “When did we decide to change the login modal?” and get an accurate response.

Where the value for me comes from is sending them out immediately after the meeting, not archiving them in a vault I never look at. "Here's the summary of what we discussed, and the distilled action items we each agreed to take."

Like the author, I've gone out of my way to avoid hosting my personal stuff with Big Tech providers, but when it comes to work, I give in to whatever we use, because I just don't have capacity to also be IT support for internal technology. It's still uncomfortable, but I have to be honest about what I have time for.

That's par for the course, honestly. News-cycle-driven anti-big-tech sentiment is weak fuel for a lifelong commitment. Something new was going to come along.

I am always happy for anyone who felt stuck on their side projects and no longer does, though.

> I’ve spent the past year moving away from surveillance platforms... And yet I willingly feed more context into AI tools each day than Google ever passively collected from me. It’s a contradiction I haven’t resolved. The productivity gains are real enough that I’m not willing to give them up, but the privacy cost is real too, and I notice it.

>I’ve settled into an uneasy position: AI for work where the productivity gain justifies the privacy cost, strict boundaries everywhere else. It’s not philosophically clean. It’s just honest.

I can't claim that AI has no benefit to our organization, but I do think that as my career has matured, I find myself spending more time thinking about how code changes will effect the system as a whole, and less time doing the actual coding.

This has been an relentless goal of the industry for my entire 40 year career.

> At a point you're more work for your self/organization because unless you get everything perfect the first time you're creating more work than you're resolving.

Nothing is correct the first time (or rarely). Accelerating the loop of build, test, re-evaluate is a good thing.

There IS experimental evidence on this and anyones anecdotal opinion is instantly blown to smithereens by the fact that this was tested and producing code faster is provably better.

Code was always a limiting factor. It's why we built large companies.

Now we can do more with fewer engineers. This will enable small teams and small startups to be even more nimble.

Was code typically a limiting factor? It doesn't seem to have been in the companies I've worked for.

LLMs allow us to generate new code much more quickly than before, but reviewing that code (alongside other institutional issues) remains a bottleneck.

AI can review my code.

LOL, good one

I've worked in multiple start-ups and more mature companies, they always slow down because producing code is easier then building a product. More code is only better when quality hardly matters, which is basically never

Both my personal and social circles experience has been these tools are spotty at best. They often miss important things, overemphasize the wrong things, etc. At a surface level they look good but if you actually scrutinize them they fall apart.

This is true for a huge amount of AI output in my experience.

This is overwhelmingly true for AI generated code in my experience.

FWIW it makes me highly discount the perspectives of internet commenters who argue that LLMs generate "better than human" or even "mostly working" code.

The top 25% percentile of coders in my org definitely code better than most agents. The rest? I trust the output of an LLM to be far more consistent when adding/deleting features across service layers than a human that can create accidental typos. Same thing with bog-standard React components or Docker build scripts.

In that study they found that pretty much everyone was using AI all the time, but they were just using their personal accounts rather than the company provided tools (hence the failures)

In light of this, I'd say there is a very good chance that people are offloading their work on AI, and then taking that saved time for themselves i.e. "I can finish the job report in 30 minutes rather than 3 hours now, so by 9:30 I'm done with work until after lunch."

The end result of this will either be layoffs to consolidate work or blocking of non-company monitored AI ensuring they can locate those now empty time slots.

What products? This blog post is long on vibes and short on evidence.

> The actual gains are granular and personal, which makes them hard to count and easy to dismiss.

It also means the trillion dollar valuations might be bunk?

> It also means the trillion dollar valuations might be bunk?

Yes, unless the selling point is the institutional and social instability you can create by handing LLMs to technically incapable users and telling them they can write code now.

Productivity in large organizations has never been and can never be purely of the legible work which is written in Jira tickets, documented, expressed clearly, but is sustained by an illegible network of relationships between the workers and unwritten knowledge/practices. AI can only consume the work which is legible, but as more work gets pushed into this realm, the illegible relationships and expertise becomes fragmented and atrophies, which puts backpressure on the system's productivity as a whole. And reading said book, my guess that attempting to impose perfect legibility for the sake of AI tooling will ultimately prove disastrous.

If you take 100 people not all of them will have the intellectual curiosity, enthusiasm and flexibility to turn their ChatGPT license into productivity gains. No amount of training will overcome a fundamental lack of curiosity & willingness to experiment

And in very corporate environments there are lots of people like that who thrived just fine thus far because everything is written down in a step by step policy etc.

Plus you get a wildly different payoff the more you can take humans completely out of the loop. If it writes the code but humans review, you’re still bottleneck. If it designs and codes and reviews and goes back to designing, and so on, there’s no effective speed limit.

Big businesses aren’t going to work that way though. Which is why we shouldn’t be looking to them as thought leaders right now.

Are you sure? It feels like the same exact bullshit to me.

At my company, if you don't use AI, you're productivity will be much slower than everyone else and that will result in you getting fired. The expectation is 3-4 PRs a day per person.

> “AI is everywhere except in the incoming macroeconomic data,” Apollo chief economist Torsten Slok wrote in a recent blog post, invoking Solow’s observation from nearly 40 years ago. “Today, you don’t see AI in the employment data, productivity data, or inflation data.”

So I don't feel like TFA is a necessarily a rebuttal to this. The proof would be in the pudding.

So I guess he’s making the case that the tools are good… the employees are just holding it wrong.

I feel like this applies for many of you.

People talk about how non-AI code will become an artisanal craft and I think it's a bit of a stretch. The one exception might be when code has an intrinsic aesthetic quality in itself, rather than just the functional output, something like the obfuscated C code competition entries. Hand-worked wood might be crappy too, like a school woodwork birdhouse project made by a beginner, but a truly artisanally crafted piece of furniture or cabinetry has a very tangibly superior output to an IKEA bookshelf or other industrial stuff.

On the point of doing work for the sake of doing work and not for the sake of the value of the output, this is nothing new, as suggested in the blog post. But the more apt analogy would be all the "bullshit jobs" that have existed for decades in modern corporations. People who expand their teams to justify more budget to hire more people to create more work to expand their teams to get bigger budgets, etc. All the while producing nothing of real value in the company. The thing that AI seems to have done is accelerated and exaggerated this tendency, maybe since it was already the natural tendency within the logic of our corporate work culture.

Great take, thanks for sharing this article!

---

LLM tools were sold to firms as game-changers. The truth is that they work, but by saving bits of time and mental energy here and there. Those savings are meaningful in the aggregate and compound over time.

But there are a few catches.

First, most of the savings is realized by integrating the tools into workflows that are personal and often sui generis. That takes, on the one hand, know-how (but firms deployed the tools without clear direction and without training workers); and, on the other hand, time and effort (but many of the largely untrained workers aren't investing time and effort to do so, even if they have the know-how).

Second, even where the training, time, and effort hurdles are cleared, the benefits inure primarily to the workers themselves: less time and mental energy spent doing what appear to be coordination tasks — ones that, so far, have been considered necessary but do not meaningfully represent the firm's actual value creation. For the benefits to inure to the firm (and thus appear on the radar of CEOs like those interviewed for the Fortune survey tangentially mentioned in TFA) the workers would need to "reinvest" the time and mental-energy savings in activities directly causing the value the firm is presumed to produce. They have little incentive to do so and they do not. Hence no increased firm productivity.

And third, even where the "reinvest your new-found ease to benefit the firm" hurdle is overcome — here I'm visualizing Lumbergh's "Is This Good for the COMPANY?" banner — firms often have to trade their private data for those hard-won benefits.

Thus the author arrives at his main conclusion: he will happily use "AI" (read: LLM tools) at work, on the company dime and with company data, to make his life easier, but he won't use the tools in his private life because he's privacy conscious.

The other conclusion is that firms could theoretically derive benefits from LLM tools — but they haven't figured out that, in exchange for their own valuable data, over and above the monetary cost of the LLM tools, they need to train workers to use them; ensure workers use them, and properly; and ensure workers then do even more intensive work to drive the value creation the company is supposedly engaged in, instead of simply making their own lives easier.

---

My personal conclusion is that people are going to start seeing even more clearly than before that most of what they and their colleagues do during most of their time is busy work that creates no actual value.

AI isn’t a silver bullet. It takes many iterations to get right. Yes, there is a lot of on-the-surface-it-looks-correct-so-ship-it stuff going on. I cringe when someone says “Well AI says..”

I don’t care what AI says! Unless you have done the research yourself and applied your own critical thinking then don’t send me that slop!

That is to say, there are some really good LLMs out there. I started using Claude and it is better for code than ChatGPT. But, you must understand and appreciate the code before you push it.

The article mentions that the survey is wrong because the productivity gains do not show up in the metrics, etc. But what about your personal metrics? What projects did you ship, how many per week, what was the total amount of minutes saved per week, how did you use those minutes instead?

Otherwise its just productivity theater.

Most people never use a LLM assistant beacuse their lives aren't complicated enough to require a dedicated 24x7 assistant.

The points being made are fine, I think, but look, if it's faster for you to generate than it is for us to read, I think this qualifies as denial-of-service-lite.

I used to debate with people about this, but it didn’t really change anything. Now, I just shrug and continue on with my work and, if someone asks, I help them use AI better.

My main worry now is when the AI bubble is going to burst, and what’s affordable now becomes unaffordable.

If you were unproductive, it allows you to be more "productive" while stalling or reversing your learning and growth.

Of course, person number 2's newfound "productivity" comes at the expense of leeching productivity away from the experienced and productive people by overloading them with reviewing and validating their non-deterministic generated spaghetti.

It amazes people who think pumping out code is the hard part of a project, when in fact that's the easiest part...

We've apparently collectively forgotten that lines of code is one of the worst metrics for measuring productivity.

It sounds like you already have your mind made up about AI, but I disagree. The rest of your comment make assertions and assumptions to points I did not make, so I'll leave those alone and leave them for someone else to address.

Is this productivity or paper pushing?

The AI note taker sounds genuinely useful but beyond that he never discusses the actual techniques that he used to go from 1 week to implement a side project to 1 day.

What do you mean when you say that you use LLMs for *Code Scaffolding*?

The only question will be whether or not it gradually develops further from my assistant to my controller and then ... its own HR firing department.