I think that coding by hand is largely not going to occur anymore. What that does to the learning of new developers + the stagnation of old developers? I do not know.
I believe that what makes a good developer (a great developer, really) is the ability to do something at the smallest level "perfectly" or close to it. Chaining those tiny building blocks together. Understanding the entire flow of data + logically. Making something as fast as it can be. When you put more and more of those tiny blocks together, things get a little more imperfect - but a fantastic developer can keep them all perfect for a long time.
We're jumping way above that level. That small, perfect logic process, that visibility is now completely hidden from us, some of us wouldn't even know how to do it anymore. And juniors of today will never learn to.
And maybe they don't need to. Perhaps we will just build "bigger" software so that the level of imperfection becomes less noticeable. Larger systems, more functionality, more security.
I think the brain atrophy is going to hit us HARD though. It feels too fast to rip away the one thing that taught us all of this. Building something piece by piece was the way most of us learned. Then you can jump into bigger and bigger projects and your brain creates those pathways. Previous generations had months / years to learn new tooling - and now we threw ALL of the tooling away and said "use this instead". I think good developers will always find a way to learn and grow, but man is it going to take some time, we completely shifted the way the entire industry produces the machine in the matter of 12 months.
I still believe that code is the best way to represent a sufficiently complex specification, natural human language feels very ambiguous sometimes, like extra lossy compression (whatever that is worth).
It's really interesting to the vagueness of natural language and the fact that it's actually impossible to express a single concrete meaning in natural language. That is to say their is always a set of possible interpretations one can never simple refer to one single thing and a program in a programming language is always only one thing (I know that you could argue that compiling to different machine code means their is vagueness since it might produce a x86-64 binary or a powerpc binary and the issue of UB but you see my point).
I do think that if one simply 'vibe codes' something they can never really understand the program even if they prompted it unless they study the source in detail. In natural language you can only ever point to a set of things that containing a subset of thing(s) you want.
If I need heads down time during WFH, I literally turn on do not disturb mode and flip my teams to "busy". As in the office, I would put headphones on and find a quiet corner.
Meetings depend on the company, my team gets a lot of information transferred quickly whether it's on a call, in person, or async over teams messages.
Spyware - definitely sucks, I luckily have a pretty lax IT group (I'm part of them) but we're not super concerned unless something is malicious.
I think to some, remote work is a trade off. To others, remote work is a gigantic benefit. I would take remote work over a 25% raise, for example. Others might not.
To each their own, but for me - not putting miles on my. vehicles, getting 2+ hours of the day back, and being able to hit laundry / other chores over lunch is amazing for my work/life balance.
Reminds me of the Bootstrap era. I can't count the amount of websites with a centered header navigation, slightly rounded accent color buttons, hero section that was mostly text, and some "fun quirk" in the background, either geometric shapes or squiggles or something.
It's alright though, because some people are OK with middle of the road (Wordpress, Boostrap, Squarespace templates, now AI). And others are willing to either pay a developer to get involved or put in the extra effort to differentiate themselves.
Unrelated to the article, but I'm a big trackpad user and, man... I sure hate it when websites hijack my scrolling / pinch + zoom functionality. Totally throws me for a loop.
Soon they will start a program where you can either take a failing grade, or pay double tuition for those credit hours to get a pass in that class.
When I has in school we had a similar semester during covid. The school offered the entire student body to either take their letter grade, or take a PASS/FAIL (Which in some cases would improve GPA).
The idea is probably that if you give students good grades, they're happy to pay more in tuition. High drop-out classes and difficult coursework will go the way of the dodo.
If you are wealthy enough this already exists look up st Anne HS NYC - k thru 12, no grades ever, most kids go to Ivy league - tuition is like 60k per year starting in k
“It never reimplements git — it shells out to the system git CLI and rebuilds commits with git commit-tree, reusing each commit's original tree so file contents are provably never changed.”
Glad the LLM noted this - I was worried this would reimplement git
One of the most annoying quirks of LLMs for me is the insistence on, after being corrected, loudly noting what wasn't done. After getting it to change something stupid in code, it will leave a comment in the code boasting about how it doesn't do the stupid thing, which to future readers reads like an 'asbestos free!' label on a cereal box.
Lets assume one of two worlds - one where AI is constantly improving and one where the tooling is a dead end. In the first world the AI generated comments are no better than the commentary that would be generated in the next six months - in the second world the AI generated comments will obscure the human written comments.
In what world are AI generated comments actually value adds?
If the AI (or the person) ran into a non-obvious constraint, or some externality, or there’s a plan that just isn’t implemented yet- then the comment wouldn’t be able to be divined by the AI. But yeah just pointing the AI at something and saying “write me docs” will get you something at best equally good as what’s going to be available.
One of the reasons this is there is the "psychology" of the LLM performs better with these kinds of affirmations. If you've made a mistake once you're likely to make it again, so leave a note.
This indeed pollutes the code with a bunch of nonsense. One of the things I have it maintain instead is a "findings" document with lessons learned and such.
> If you've made a mistake once you're likely to make it again, so leave a note.
In my experience the comments behave as a form of prompt injection. The llm makes a conceptual mistake, writes it in a comment, and now subsequent agents make the same mistake!
I have a contrarian take on this: if most people working on the codebase are using the same model, then these comments serve a very useful purpose: they tell the model's future self that despite its tendency towards this solution, it is incorrect and here's why. It encodes useful context right when the model needs it next to avoid making the same error.
I imagine this style of commenting is partially responsible for model improvement in SWE work, a trained trait through feedback, since it makes the comments actually useful. Not to you or me, but to an LLM.
Some of these errors are obvious to a human, that's why we find the comments unnecessary. But if everyone's using LLMs and said model tends to make this error, then they are very useful. It's like a comment you would leave for another human to help them avoid a footgun. It's just a LLM footgun, not a human one.
I agree, but that information should be in the commit, which the model also has access to. Of course it's more token intensive to look through commits, but "good" models might know when some more research about a particular bit of code they find weird would be a good idea. Thoughts?
The problem is that the list of things one shouldn't do is infinite. The things one should do are narrow and get narrower along two independent axes of clarity/wisdom: system requirements and engineer seniority. LLMs overindex on any words given, so you only want to give them negative guidance around truly repeated, almost common-sense pitfalls. But in a large distributed system often the changes come from all different angles, and each agent will find it's own unique failure modes. Those comments will dilute critical context for diverse agents far more than they will help on average, at least for the systems I'm working on, given current claude code chattiness.
One way to clear some of the low-hanging slop is to just have a separate agent code reviewing and pruning any comments that don't stand on their own purely in the context of the diff, but it still doesn't catch it all.
If LLMs are any good, like many of you claim, they won’t need these comments. They will ingest the code and know what was done. They won’t need comments about what wasn’t done.
Ha ha fair. But yeah shelling out to git and reusing the original tree object was deliberate means file contents can't change even if I screw up elsewhere.
For what it's worth, I've used Claude to write a lot of smaller utility tools that I wouldn't normally have the time to sit down and implement, but which also solve straightforward problems.
One small example is an extension for the `gh` cli where I give it a PR number and multiple branches and it cherry-picks that PR to those branches, or lets me know if some of the branches don't work. For managing multiple release branches it's very handy, but not so handy that I would have spent a lot of time and energy doing a good job of it.
This seems like a similar sort of thing - a user friendly way to do something that most people don't need, and most people who need it probably don't need it very badly.
I haven't used claude to replace my actual skills - researching, solving problems, etc. - but I do use it to replace all the stuff which is essentially 'spend a few hours reading API docs and writing boilerplate code'.
That is in fact the difficult part. You have to explain it all coherently while adjusting to the reader's frame. No one does that for no good reason. It is hellish work.
Effective and clear communication is really important and often really hard for engineers. It is said that one goal of stackoverflow was to help programmers learn how to write through practice, as it’s both very hard and very critical to their effectiveness:
I mean, given that the English you wrote above didn't make it clear that was the only part you were complaining about, it's worth it to consider that maybe precision is hard in natural language regardless of how it's written
I'm reverse engineering a cherished video game from my childhood. I got to the audio engine part and things got pretty difficult. Managed to map out the locations of the audio data but figuring out which song was which was going to take a long time.
Claude somehow wrote a bespoke one-off Python script to play back the songs straight out of the ROM. I give it the ROM and a hexadecimal address and it just plays it. Converts the data from the ROM into PCM audio samples and pipes them over SSH into termux on my phone where they are played back via SoX play.
Yes, Claude wrote a literal sound synthesizer so I could do this. Claude painstakingly tuned the goddamn synthesizer too, he tweaked it over and over again until the output sounded right based on annoyingly human feedback like "these notes are supposed to be in the background but they are too loud".
This tool turned a painstaking reverse engineering task into a nostalgic listening experience that brought literal tears to my eyes. I mapped out every single song in the game this way.
Without LLMs, none of this would ever have happened.
“Editing” commits is not niche, and editing metadata like dates seems to come up a few times for a fair few number of people.
You can already expose the commit object as the headers (metadata) and the commit message. That’s like a spreadsheet: change these columns and we will make a new commit. That changed format can then be persisted as a commit object. So.
> A tool like this never sees the light of day without an LLM.
Are LLMs memory holing all the numerous tools built around Git (with git(1) or without)? There was already a query-Git-like-SQL tool before The Age of LLMs. I never tried that, but was that simpler to implement than this tool? Edit: Okay, maybe it wasn’t “niche” so that’s the differentiator.
i definitely used to write bash functions for this sort of thing tho. no GUI, but it was useful to do stuff like obscure my working hours (make it look like i did personal stuff after-hours. make it seem like stuff took all day instead of an hour..like adding sawdust to meat).
like you said, niche and probably unnecessary. and if i were to have published them (even in a gist!) i would have written the docs myself instead of forcing people to read LLM-speak. That's just lazy.
It’s not about using new technology, it’s about the signal of effort.
Blind copy-pasting an AI image anywhere is a poor signal of effort, because it was a deliberate decision by the author… “I didn’t do the work to make this look professional, but my hope is that people THINK it looks professional.”
I run into this quite a bit. We have users generating MANY apps at our small company (30 FTE), entirely with Claude. It's great to see people mess around and tinker. It's NOT great to see someone with a GH repo that has 750+ commits for what would be MAYBE 1 week of a developers time. SO these are non-developers now spending hours and hours working on software that is probably going to get thrown out.
We're in this spot where we don't know when to cut our losses on projects like this. (Is it even viable as production software? Does it currrently do what it's supposed to, or are they adding new features? Is there a return on continued development efforts?)
None of these apps they have built are seeing any major usage, and I don't think a single one is what I would call "done" (There was a gold rush stage at the beginning of 2026 where senior leadership wanted everyone to spend some time messing around with Claude). Unfortunately, they never told anyone when to stop messing around with Claude, so the ROI is ever diminishing.
It's been doing this for our non-technical folk. Giving users a gigantic single file for deployment. We saw one user deploy a JS file with around 3K-5K elements in an array, storing unique IDs of items they wanted to list.
Welcome to Software Development, Lindsey from HR - here's your first database!
People just don't really understand how these things work yet, and they don't know what to ask for, I'm hopeful that they eventually do become more tech-literate, but not sure yet.
There are big differences in what people call "tinkerers". Some are INTERESTED in building things, give it a little shot and find it to be daunting, and push it no further.
True tinkerers have no problem with this, because they enjoy learning how things work. Installing Linux, Steam, Portal are all relatively straightforward tasks for someone who uses computers on the regular - but to some people this is just something they've never done, are scared to do, or just don't want to learn. (Which is fine, but they'll never pick these agents up and run free.)
Barrier to entry used to be blog posts, documentation, watching poor quality Youtube videos of a thing that SEEMS related to what you're trying to do. Now we're getting that spoon fed to our particular case, so the friction is essentially just "follow the AI directives". (However, the depth of understanding probably struggles.)
You can get pretty dang far asking the AI to explain things and show you where it got that info, especially with IT/DEV stuff. Thing that has been very useful to me is specifically asking AI for that vocabulary. AI is suprisingly useful for giving a vague description of something you want and asking for possible words that match. But you have to KNOW to try that. A tinkerer might have started that convo with the chatbot by asking "What are web pages built from" "Can we use those building blocks to make our own simple app" and gotten there from a place of low expertise in web development but juicing out the knowlege from a place of low expertise is itself a skill.
I know you are not arguing from bad faith, but you are making an assumption along cultural lines, which is a mistake of missing the forest through the trees.
The vast majority of people (blanket statement, I know..) do not come from a culture where embracing curiosity, asking questions, or trying to break things down is the norm. Developers, tinkerers, etc., sure... you can reasonably make that assumption. But not everyone. A cultural practice of critical thinking and problem solving is HOW you KNOW to ask WHAT questions need to be answered FIRST, in order to solve a problem or progress toward a solution (if more information is needed).
You might even make the argument that everyone should have these skills, and I would agree with you. But the missing link here is a culture or cultural practice that provides those things (the WHY), and an AI/LLM will not provide those things in absentia, without "prompting", or build up that infrastructure in meatspace for a given set of users. Ignore this at your own risk.
for a lot of lower barrier to entry tinkering, for years i felt it was mostly just google a thing and follow directions. Feel like the only thing that really changed is the initial query can be a mess of kinda nonsense and still give you those nice directions, and you can instantly get clarity on a single direction if you get stuck.
So the barrier is still kinda there to just grab the instructions and follow them, its just incredibly easier to follow them.
> only thing that really changed is the initial query can be a mess of kinda nonsense
Little known fact maybe, but Google (also YouTube) search has been pretty great at this well before LLMs got really popular. I think it already started when they were changing from "keyword search" to "ask us a question search" but I'm not sure.
At some point I figured, if they want me to type a whole question, I might get even better answers if I ask the question like I was a complete idiot.
I believe that what makes a good developer (a great developer, really) is the ability to do something at the smallest level "perfectly" or close to it. Chaining those tiny building blocks together. Understanding the entire flow of data + logically. Making something as fast as it can be. When you put more and more of those tiny blocks together, things get a little more imperfect - but a fantastic developer can keep them all perfect for a long time.
We're jumping way above that level. That small, perfect logic process, that visibility is now completely hidden from us, some of us wouldn't even know how to do it anymore. And juniors of today will never learn to.
And maybe they don't need to. Perhaps we will just build "bigger" software so that the level of imperfection becomes less noticeable. Larger systems, more functionality, more security.
I think the brain atrophy is going to hit us HARD though. It feels too fast to rip away the one thing that taught us all of this. Building something piece by piece was the way most of us learned. Then you can jump into bigger and bigger projects and your brain creates those pathways. Previous generations had months / years to learn new tooling - and now we threw ALL of the tooling away and said "use this instead". I think good developers will always find a way to learn and grow, but man is it going to take some time, we completely shifted the way the entire industry produces the machine in the matter of 12 months.
I still believe that code is the best way to represent a sufficiently complex specification, natural human language feels very ambiguous sometimes, like extra lossy compression (whatever that is worth).
reply