- Socrates on Writing.

If that’s true, then maybe we could leverage what we know about good management of human subordinates and apply it to AI interaction, and vice versa.

I have actually been improving in other fields instead like design and general cleanliness of the code, future extensability and bug prediction.

My brain is not 'normal' either so your mileage might vary.

So, is it ok for coding? :-)

for me, it's purely a research tool that I can ask infinite questions to

We find that people having to perform mental arithmetics as opposed to people using calculators exhibited more neural activities. They were also able to recall the specific numbers in the equations more.

... So what?

The consequence of making anything easier is of course that the person and the brain is less engaged in the work, and remembers less.

This debate about using technology for thinking has been ongoing for literally millennia. It is at least as old as Socrates, who criticized writing as harming the ability to think and remember.

>>And now, since you are the father of writing, your affection for it has made you describe its effects as the opposite of what they really are. In fact, it will introduce forgetfulness into the soul of those who learn it: they will not practice using their memory because they will put their trust in writing, which is external and depends on signs that belong to others, instead of trying to remember from the inside, completely on their own. You have not discovered a potion for remembering, but for reminding; you provide your students with the appearance of wisdom, not with its reality. Your invention will enable them to hear many things without being properly taught, and they will imagine that they have come to know much while for the most part they will know nothing. And they will be difficult to get along with, since they will merely appear to be wise instead of really being so.”[0]

To emphasize: 'instead of trying to remember from the inside, completely on their own ... not a potion for remembering, but for reminding ... the appearance of wisdom, not its reality.'

There is no question this is a true dichotomy and trade-off.

The question is where on the spectrum we should put ourselves.

That answer is likely different for each task or goal.

For learning, we should obviously be working at a lower level, but should we go all the way to banning reading and writing and using only oral inquiry and recitation?

OTOH, a peer software engineer manager with many Indians in his group said he was constantly trying to get them to write down more of their plans and documentation, because they all wanted to emulate the great mathematician Ramanujan who did much of his work all in his head, and it was slowing down the SE's work.

When I have an issue with curing a particular polymer for a project, should I just get the answer from the manufacturer or search engine, or take the sufficient chemistry courses and obtain the proprietary formulas necessary to derive all the relevant reactions in my head? If it is just to deliver one project, obviously just get the answer and move on, but if I'm in the business of designing and manufacturing competing polymers, I should definitely go the long route.

As always, it depends.

[0] https://newlearningonline.com/literacies/chapter-1/socrates-...

A door has been opened that cant be closed and will trap those who stay too long. Good luck!

/s

This is a non-study.

There's a famous satirical study that "proved" parachutes don't work by having people jump from grounded planes. This study proves AI rots your brain by measuring people using it the dumbest way possible.

I want a life of leisure. I don’t want to do hard things anymore.

Cognitive atrophy of people using these systems is very good as it makes it easier to beat them in the market, and it’s easier to convince them that whatever slop work you submitted after 0.1 seconds of effort “isn’t bad, it’s certainly great at delving into the topic!”

Also, monkey see, monkey speak: https://arxiv.org/abs/2409.01754

this doesn't seem like a clear problem. perhaps people can accomplish more difficult tasks with LLM assistance, and in those more difficult tasks still see full brain engagement?

using less brain power for a better result doesn't seem like a clear problem. it might reveal shortcomings in our education system, since these were SAT style questions. I'm sure calculator users experience the same effects vs mental mathematics

I'm very curious to see if we start to see things like this as a new skill, requiring a different cognitive style that's not measured in studies like this.

It's a tool, and this study at most indicates that we don't use as much brain power for the specific tasks of coding but do they look into for instance maintenance or management of code?

As that is what you'll be relegated to when vibe coding.

If you are feeling over reliant on these tools then I quickfix that's worked me is to have real conversations with real people. Organise a coffee date if you must.

Seems to focus only on the first part and not on the other end of it.

Similar mess with can be found in `Figure 34.`, with an added bonus of "DO NOT MAKE MISTAKES!" and "If you make a mistake you'll be fined $100".

Also, why are all of these research papers always using such weak LLMs to do anything? All of this makes their results very questionable, even if they mostly agree with "common intuition".

The last one I saw was about smartphone users who do a test and then quit their phone for a month and do the test again and surprisingly do better the second time. Can anyone tell me why they might have paid more attention, been more invested, and done better on the test the second time round right after a month of quitting their phone?

Either way, that’s not how compliments nor insults work. The intent is what matters, not the word.

For example, amongst finance bros, calling each other a “ruthless motherfucker” can be a compliment. But if your employee calls you that after a round of layoffs, it’s an insult.

https://grugbrain.dev/

Carson Gross sure knows how to stay in character.

Is this an unironic usage of this word? If you're trying to make a different point, it doesn't come across.

> You've highlighted a very real equivalency in spite of yourself

The equivalence doesn't help you, because "possessed by demons" has been used to describe people who are sick, playing D&D, reading comics, listening to music, being women, and it is frivolous and embarrassing to take seriously.

Isn't the point of a lot of science to empirically demonstrate results which we'd otherwise take for granted as intuitive/obvious? Maybe in AI-literature-land everything published is supposed to be novel/surprising, but that doesn't encompass all of research, last I checked.

The only way I'll run out of credits is if my company isn't liquid any longer in which case I have bigger problems.

And there are plenty of LLM providers, almost only a few w/SOTA models but even for SOTA models there is no reason to be dependent on one.

If I had turned an AI loose against the original codebase, I think it would have just churned away copying the existing patterns and debugging any runtime errors that result. I don't think an AI would have ever voluntarily told me "this form library is costing time and effort, we should replace it with such and such instead"

In that sense, going from pseudocode to a programming language is no different from that, or even translating a piece of code from one programming language to another.

Everything to them is a social media post for likes.

I have explored all kinds of graph layouts in various network science context via LLMs and guess what? I don't know anything much about graph theory beyond G = (V,E). I am not really interested either. I am interested in what I can do with and learn from G. Everything on the right of the equals sign Gemini is already beyond my ability. I am just not that smart.

The standard narrative on this board seems to be something akin to having to master all volumes of Knuth before you can even think to write a React CRUD app. Ironic since I imagine so many learned programming by just programming.

I know I don't think as hard when using an LLM. Maybe that is a problem for people with 25 more IQ points than me. If I had 25 more IQ points maybe I could figure out stuff without the LLM. That was not the hand I was dealt though.

I get the feeling there is immense intellectual hubris on this forum that when something like this comes up, it is a dog whistle for these delusional Erdos in their own mind people to come out of the wood work to tell you how LLMs can't help you with graph theory.

If that wasn't the case there would be vastly more interesting discussion on this forum instead of ad nauseam discussion on how bad LLMs are.

I learn new things everyday from Gemini and basically nothing reading this forum.

It's similar to other abstractions in this way, but on a larger scale due to LLM having so many potential applications. And of course, due to the non-determinism.

Outsourcing learning and thinking is a double edged sword that only comes back to bite you later. It's tempting: you might already know a codebase well and you set agents loose on it. You know enough to evaluate the output well. This is the experience that has impressed a few vocal OSS authors like antirez for example.

Similarly, you see success stories with folks making something greenfield. Since you've delegated decision making to the LLM and gotten a decent looking result it seems like you never needed to know the details at all.

The trap is that your knowledge of why you've built what you've built the way it is atrophies very quickly. Then suddenly you become fully dependent on AI to make any further headway. And you're piling slop on top of slop.

E.g. "show me why <this assumption that is necessary for the code I'm currently staring at> holds" makes it far more pleasant to do reviews. AI code review tooling works well to reduce that burden. Even more so when you have that AI cod review tooling running as part of your agent loop first before you even look at a delivery.

"prove X" is another one - if it can't find a test case that already proves X and resorts to writing code to prove X, you probably need more tests, and now you have one,.

It's important that when you solve problems by writing code, you go through all the use cases of your solution. In my experience, just reading the code given by someone else (either a human or machine) is not enough and you end up evaluating perhaps the main use cases and the style. Most of the times you will find gaps while writing the code yourself.

Further elaborating from my experience.

1. I think we're in the early stages, where agents are useful because we still know enough to coach well - knowledge inertia.

2. I routinely make the mistake of allowing too much autonomy, and will have to spend time cleaning up poor design choices that were either inserted by the agent, or were forced upon it because I had lost lock on the implementation details (usually both in a causal loop!)

I just have a policy of moving slowly and carefully now through the critical code, vs letting the agent steer. They have overindexed on passing tests and "clean code", producing things that cause subtle errors time and time again in a large codebase.

> burn the time to understand it.

It seems to me to be self-evident that writing produces better understanding than reading. In fact, when I would try to understand a difficult codebase, it often meant that probing+rewriting produced a better understanding than reading, even if those changes were never kept.

This is true whether an AI wrote the code or a co-worker, except the AI is always on hand to answer detailed questions about the code, do detailed analysis, and run extensive tests to validate assumptions.

It is very rarely productive any more to dig into low level code manually.

Most of my work is on projects I have a long term vested interest in.

I care far more about maximally leveraging LLMs for the projects I have a vested interest in - if my clients don't want to, that's their business.

Most of my LLM usage directly affects my personal finances in terms of the ROI my non-consulting projects generate - I have far more incentives to do the job well than a permanent employee whose work does not have an immediate effect on their income.

Steve Yegge's a famous developer, this is not a joke :) You could say he is an AI maximalist, from your options I'd go with (b) serious with the idea, tongue-in-check in the style and using a lot of self-irony.

It is exaggerated, but this is how he sees things ending up eventually. This is real software.

If things do end up in glorified kanban boards, what does it mean for us? That we can work less and use the spare time reading and doing yoga, or that we'll work the same hours with our attention even more fragmented and with no control over the outputs of these things (=> stress).

I'd really wish that people who think this is good for us and are pushing for this future do a bit better than:

1. More AI 2. ??? 3. Profit

It's "true" in a sense. It helps. But it is also largely irrelevant for most of us, in that most of us are writing code you can learn to read and write in a tiny proportion of the time we spend in working life. The notion that you need to keep spending more than a tiny fraction of your time writing code in order to understand enough to be able to solve business problem will seem increasingly quaint.

> Because they didn't understand the architecture or the domain models otherwise.

My point is that requiring or expecting an in-depth understanding of all the algorithms you rely on is not a productive use of developer time, because outside narrow niches it is not what we're being paid for.

It is also not something the vast majority of us do now, or have done for several decades. I started with assembler, but most developers have never-ever worked less than a couple of abstractions up, often more, and leaned heavily on heaps of code they do not understand because it is not necessary.

Sometimes it is. But for the vast majority of us pretending it is necessary all the time or even much of the time is a folly.

> I do wonder, however, how much of your actual job also entails ensuring that whoever is doing the implementation is also growing in their understanding of the domain models. Are you developing the people under you? Is that part of your job?

Growing the people under me involves teaching them to solve problems, and already long before AI that typically involved teaching developers to stop obsessing over details with low ROI for the work they were actually doing in favour of understanding and solving the problems of the business. Often that meant making them draw a line between what actually served the needs they were paid to solve rather than the ones that were personally fun to them (I've been guilty of diving into complex low-level problems I find fun rather than what solves the highest ROI problems too - ask me about my compilers, my editor, my terminal - I'm excellent at yak shaving, but I work hard to keep that away from my work)

> If it is an AI that is reporting to you, how are you doing this? Are you writing "skills" files? How are you verifying that it is following them? How are you verifying that it understands them the same way that you intended it to?

For AI use: Tests. Tests. More tests. And, yes, skills and agents. Not primarily even to verify that it understands the specs, but to create harnesses to run them in agent loops without having to babysit them every step of the way. If you use AI and spend your time babysitting them, you've become a glorified assistant to the machine.

Your time would be better spent, in a permanent code base, trying to get that LLM to understand something than it would be trying to understand the thing yourself. It might be the case that you need to understand the thing more thoroughly yourself so you can explain it to the LLM, and it might be the case that you need to write some code so that you can understand it and explain it, but eventually the LLM needs to get it based on the code comments and examples and tests.

Most "know what has to be done, but not quite how it is done". This is just another level of abstraction.

I learnt the lesson 30+ years ago that while it was (and still occasionally is) useful to understand the principles of assembly, it had become useless to write assembly outside of a few narrow niches. A decade later I moved from C and C++ to higher level languages again.

Moving up the abstraction levels is learning leverage.

I deliver far more now - with or without AI - than I did when I wrote assembler, or C for that matter. I deliver more again with AI than without.

That's what matters.

What I have asked my children to do very often is back-of-the-envelope multiplications and other computations. That really helped them to get a sense of the magnitude of things.

For my setup, I make sure I have good markdown files and I use beads. I'll usually have an AGENTS.md, CLAUDE.md, GEMINI.md in every project and 99.9% of the time they're the exact same. I always make sure to keep these files up to date. If the LLM does something I don't like and I can foresee it being a problem, I'll add it to the markdown file as something not to do.

My markdown files generally have multiple sections. There's always a good chunk describing the app (or in a non software case, the goal or purpose). Some design/architecture decisions will make it into the markdown files. How to build/test are in the markdown files.

I think it helps that I already have good patterns and structure to most things I build. I have moved more to a monorepo since LLMs came out. So an android app won't be in a separate repo as the webapp, instead they're all in the same repo with different directories (frontend vs {app}-android/{app}-iphone/{app}-mobile). Everything I build gets deployed to AWS and I have good patterns for that. Make for builds/deploys/tests, I don't ever run terraform or npm or maven or any other builds on the cli, if I'm running it it goes in the Makefile. All apps follow the same Makefile patterns where certain commands all get rolled up into the same one (make plan, make build, make deploy) using the same general env vars.

Now for tools and such, I feel like just the cli agents themselves are it. On personal stuff that's 100% all I use, the cli agent. At work I integrate with some MCPs and I've created and use some skills/plugins, but tbh I don't feel like they make a big difference or are necessary. I think the non-deterministic nature of the tool makes these unnecessary. Like sometimes I have to explicitly tell the agent to use the MCP. Sometimes the MCP takes up more context than having the llm create a script to hit and API and recreate the MCP's functionality.

And when I have questions, like you did here, I ask the llms first. I ask a lot of "meta" questions to the llm in my sessions even. I like to think it primes it for going down the path you want.

For the rest, maybe you're the chosen one, who doesn't need to expend any cognitive load to learn a subject, and just glide on your curiosity. Good for you. There are, to a degree of approximation, zero other people who work this way.

If you outsource a skill consistently, you will be engaging less with that skill. Depending on the skill, this may be acceptable, or a desirable tradeoff.

For example, using a very fast LLM to interactively make small edits to a program (a few lines at a time), outsources the work of typing, remembering stdlib names and parameter order, etc.

This way of working is more akin to power armor, where you are still continuously directing it, just with each of your intentions manifesting more rapidly (and perhaps with less precision, though it seems perfectly manageable if you keep the edit size small enough).

Whereas "just go build me this thing" and then you make a coffee is qualitatively very different, at that point you're more like a manager than a programmer.

I have a whole half-written blog post about how LLMs are the cars of the mind. Massive externalities, has to be forced on people, leads to cognitive/health issues instead of improving cognition and health.

More like mobility scooter for disabled. Literally Wall-E in the making.

That said, if most people turn into hermits and start living in pods around this period, then I think you would be in the right direction.

A 2025 Homer is only plausible if he had some kind of supplemental income (like a military pension or a trust fund), if Marge had a job, if the house was in a depressed region, or he was a higher level supervisor. We can use the Simpsons as limited evidence of contemporary economic conditions in the same way that we could use the depictions of the characters in the Canterbury Tales for the same purpose.

Yeah, Homer Simpson is fictional, a unionised blue-collar worker with specialised skills, and he lives in a small town.

Wouldnt the endgame of externalized cognition be that humans essentially become cogs in the machine?

Perhaps he could. If there’s an argument to be made against writing, social media (including HN) is a valid one.

So we’ve externalised memory, we’ve externalised arithmetic. Personally the idea of externalising thinking seems to be the last one? It’s not clear what’s left inside us of being a human once that one is gone

In fact, I can feel my memory is easily worse now than from before ChatGPT's release, because we are doing less hard cognitive work. The less we use our brain's the dumber we get, and we are definitely using our brains less now.

How we work changes and the extra complexity buys us productivity. The vast majority of software will be AI generated, tools will exist to continuously test/refine it, and hand written code will be for artists, hobbyists, and an ever shrinking set of hard problems where a human still wins.

Just about a week ago I launched a 100% AI generated project that shortcircuits a bunch of manual tasks. What before took 3+ weeks of manual work to produce, now takes us 1-2 days to verify instead. It generates revenue. It solved the problem of taking a workflow that was barely profitable and cutting costs by more than 90%. Half the remaining time is ongoing process optimization - we hope to fully automate away the reaming 1-2 days.

This was a problem that wasn't even tractable without AI, and there's no "explosion of AI generated code".

I fully agree that some places will drown in a deluge of AI generated code of poor quality, but that is an operator fault. In fact, one of my current clients retained me specifically to clean up after someone who dove head first into "AI first" without an understanding of proper guardrails.

In my own (classic) engineering work, AI has become so phenomenally powerful that I can only imagine that if I was still in college, I'd be mostly checked out during those boring lectures/bad teacher classes, and then learning on my own with the textbook and LLMs by night. Which begs the question, what do we need the professor for?

I'd be interested to see stats on "office hours" visitation time over the last 4 years (although admittedly its the best tool for gaining a professor's favor, AI doesn't grant that)

> To summarize, the delta-band differences suggest that unassisted writing engages more widespread, slow integrative brain processes, whereas assisted writing involves a more narrow or externally anchored engagement, requiring less delta-mediated integration.

There is no intellectual judgement regarding this difference, though the authors do supply citations from related work that they claim may be of interest to those wanting "to know if the offloading of cognitive tasks changes my own brain and my own cognition". If your brain changes, it might change for the worse at least as far as you experience it. Is this ableism, to examine your own cognitive well-being and make your own assessment? If you don't like how you're thinking about something, are you casting aspersion on yourself and shaming your own judgement? Ableist discourse is, unsurprisingly, a stupid language game for cognitively impaired dummies. It's a pathetic attempt to redefine basic notions of capability and impairment, of functioning and dysfunction as inherently evil concepts, and then to work backward from that premise to find fault with the research results. Every single person experiences moments or lifetime's of psychological and mental difficulty. Admitting this and adapting to it or remediating harmful effects has nothing to do with calling stupid people stupid or ableism. It's just a means of providing tools and frameworks for "cognitive wellness", but even just the implication of "wellness" being distinct from "illness" makes the disturbed and confused unwell.

> ableist rhetoric

Oh, so it's not actually a science podcast - it's anti-science ideological propaganda. Thanks for the heads-up.

To be clear, I agree that houses are way less affordable now, which was the point of this thread. I just don't think fictional TV is a good reference point for that. They famously exaggerate the spaces people live in so they can film better angles or block different scenes. See "Friends"

This is a dubious claim.

And with all the stacking LLMs against each other, that just sounds like more work than just… writing the damn tests.

I encountered something like this recently. I had to replace an exact data comparison operation (using a simple memcmp) with a function that would compare data and allow differences within a specified tolerance. The AI generated beautiful code using chunking and all kinds of bit twiddling that I don't understand.

But what it couldn't know was that most of the time the two data ranges would match exactly, thus taking the slowest path through the comparison by comparing every chunk in the two ranges. I had to stick a memcmp early in the function to exit early for the most common case, because it only occurred to me during profiling that most of the time the data doesn't change. There was no way I could have figured this out early enough to put it in a spec for an AI.

    some cognitive load 

I do, which is exactly why I found the presumption that not spending your time doing the coding is equivalent to a disability both gross and arrogant.

> Where are they supposed to learn good design when slop takes over?

You're not learning good architecture and systems design from code. You learn good architecture and systems design from doing architecture and systems design. It's a very different discipline.

While knowing how to code can be helpful, and can even be important in narrow niches, it is a very minor part of understanding good architecture.

And, yes, I stand by the claim the coding is by far the simplest part, on the basis of having done both for longer than most developers have been doing either.

> Meanwhile they're pulling the same or greater comp, working half the hours, and "drinking beers with important people" is an accepted part of their job

You took the words right out of my mouth. Almost like it's a made up job and not the real work that needs to get done.

So, what about outside of some set of categories? Well, generally, no such thing exists: new ideas are extremely rare.

Anyone who truly enjoys entering code character for character, refusing to use refactoring tools (e.g. rename symbol), and/or not using AI assistance should feel free to do so.

I, on the other hand, want to concern myself with the end product, which is a matter of knowing what to build and how to build it. There’s nothing about AI assistance that entails that one isn’t in the driver’s seat wrt algorithm design/choices, database schema design, using SIMD where possible, understanding and implementing protocols (whether HTTP or CMSIS-DAP for debugging microcontrollers over USB JTAG probe), etc, etc.

AI helps me write exactly what I would write without it, but in a fraction of the time. Of course, when the rare novel thing comes up, I either need to coach the LLM, or step in and write that part myself.

But, as a Staff Engineer, this is no different than what I already do with my human peers: I describe what needs doing and how it should be done, delegate that work to N other less senior people, provide coaching when something doesn’t meet my expectations, and I personally solve the problems that no one else has a chance of beginning to solve if they spent the next year or two solely focused on it.

Could I solve any one of those individual, delegated tasks faster if I did it myself? Absolutely. But could I achieve the same progress, in aggregate, as a legion of less experienced developers working in parallel? No.

LLM usage is like having an army of Juniors. If the result is crap, that’s on the user for their poor management and/or lack of good judgement in assessing the results, much like how it is my failing if a project I lead as a Staff Engineer is a flop.

They are, but you go on to assume that they will adapt in a good way.

Bodies are adaptive too. That didn't work out well for a lot of people when their environment changed to be sedentary.

Launching a search engine and searching may spew incorrectness but it made you make judgement, think. You could have two different opinions one underneath each other; you saw both sides of the coin.

We are no longer critical thinking. We are taking information at face value, marking it as correct and not questioning is it afterwards.

The ability to evaluate critically and rationally is what's decaying. Who opens an physical encyclopedia nowadays? That itself requires resources, effort and time. Add in life complexity; that doesn't help us in evaluating and rejecting consumption of false information. The Wall-E view isn't wrong.

You think it's likely that we offload cognitive difficulty and complexity to machines, and our brains don't get worse at difficult, complex problems?

It literally does. If your brain shuts down the moment you can't access your LLM overlord then you're objectively worse.

But I generally agree with your point.

Using AI myself _and_ managing teams almost exclusively using AI has made this point clear: you shouldn't rely on it as a black box. You can rely on it to write the code, but (for now at least) you should still be deeply involved in the "problem solving" (that is, deciding _how_ to fix the problem).

A good rule of thumb that has worked well for me is to spend at least 20 min refining agent plans for every ~5 min of actual agent dev time. YMMV based on plan scope (obviously this doesn't apply to small fixes, and applies even moreso to larger scopes).

Let us use an analogy. Many (most?) people can tell a well-written book or story from a mediocre or a terrible one, even though the vast majority of the readers hasn't written any in their lives.

To distinguish good from bad doesn't necessarily require the ability to create.

Computing is always abstractions. We moved from plugging to assembly, then to c, then we had languages that managed memory for you -- how on earth can you understand what the compiler should be doing or what it is doing if you don't deal with explicit pointers on a day by day basis.

We bring in libraries when we need code. We don't run our own database, we use something else, and we just do "apt-get install mysql", but then we moved onto "docker run" or perhaps we invoke it with "aws cli". Who knows what teraform actually does when we declare we want a resource.

I was thinking the other day how abstractions like AWS or Docker are similar to LLM. With AWS you just click a couple of buttons and you have a data store, you don't know how to build a database from scratch, you don't need one. Of course "to build a database from scratch you must first create the universe".

Some people still hand-craft assembly code to great benefit, but that vast majority don't need to to solve problems, and they can't.

This musing was in the context of what do we do if/when aws data centres are not available. Our staff are generally incapable of working in a non-aws environment. Something that we have deliberately cultivated for years. AWS outputs are one option, or perhaps we should run a non-aws stack that we fully own and control.

Is relying on LLMs fundamentally any different than relying on AWS, or apt, or java. Is is different from outsourcing? You concentrate on your core competency, which is understanding the problem and delivering a solution, not managing memory or running databases. This comes with risk -- all outsourcing does, and if outsourcing to a single supplier you don't and can't understand is acceptable risk, then is relying on LLMs not?