Our main finding is that using AI to complete tasks that require a new skill (i.e., knowledge of a new Python library) reduces skill formation. In a randomized controlled trial, participants were assigned to the treatment condition (using an AI assistant, web search, and instructions) or the control condition (completing tasks with web search and instructions alone). The erosion of conceptual understanding, code reading, and debugging skills that we measured among participants using AI assistance suggests that workers acquiring new skills should be mindful of their reliance on AI during the learning process.
Shen & Tamkin, How AI Impacts Skill Formation (2026)
Shen & Tamkin, How AI Impacts Skill Formation (2026)
😢1
(φ (μ (λ)))
Our main finding is that using AI to complete tasks that require a new skill (i.e., knowledge of a new Python library) reduces skill formation. In a randomized controlled trial, participants were assigned to the treatment condition (using an AI assistant,…
Just to be clear this research came from the "leading AI company" Anthropic's research fellowship program. Even though I'm always skeptical of the methodologies of such tests, I think this one has a pretty rigorous one.
Go ahead, make another app with Claude and call yourself an engineer until you can't :)
Go ahead, make another app with Claude and call yourself an engineer until you can't :)
👍1
Together, our results suggest that the aggressive incorporation of AI into the workplace can have negative impacts on the professional development workers if they do not remain cognitatively engaged. Given time constraints and organizational pressures, junior developers or other professionals may rely on AI to complete tasks as fast as possible at the cost of real skill development. Furthermore, we found that the biggest difference in test scores is between the debugging questions. This suggests that as companies transition to more AI code writing with human supervision, humans may not possess the necessary skills to validate and debug AI-written code if their skill formation was inhibited by using AI in the first place.
Shen & Tamkin, How AI Impacts Skill Formation (2026)
Shen & Tamkin, How AI Impacts Skill Formation (2026)
👍4
(φ (μ (λ)))
https://github.com/wilsonzlin/fastrender/issues/98#issuecomment-3756001459
YouTube
AI Didn’t Build A Browser From Scratch…
In this video we'll take a look at an experiment that cursor ran. They let agents try to make a browser from "scratch", but was it really from scratch.
Make sure to like and subscribe... if you feel like it...
Check out the blog:
https://basicdev.blog/…
Make sure to like and subscribe... if you feel like it...
Check out the blog:
https://basicdev.blog/…
🔥1
This media is not supported in your browser
VIEW IN TELEGRAM
Finally. Doom inside Emacs, running as smoothly as it can.
🔥6
(φ (μ (λ)))
Finally. Doom inside Emacs, running as smoothly as it can.
This effort is part of the Canvas API patch that Minad (Daniel Mendler), me and others are working on to let Emacs provide a better interface for direct pixel manipulation.
This began after a lengthy discussion with Minad after I posted my demo of rendering a video inside Emacs. Check out the thread here.
The progress on this has been faster than I can catch up with! Really glad to see this. Nothing stops Emacs from having high-quality graphical applications anymore.
Also, check out the discussion regarding Canvas API and the patch(es) at the following emacs-bugs thread.
This began after a lengthy discussion with Minad after I posted my demo of rendering a video inside Emacs. Check out the thread here.
The progress on this has been faster than I can catch up with! Really glad to see this. Nothing stops Emacs from having high-quality graphical applications anymore.
Also, check out the discussion regarding Canvas API and the patch(es) at the following emacs-bugs thread.
Reddit
minadmacs's comment on "Rendering 30FPS Video Inside Emacs Text Buffer"
Explore this conversation and more from the emacs community
Forwarded from Symptoms
That’s the great thing about art--we define it, and we give it meaning. The machines can spit out manuscript after manuscript after manuscript. They can pile them to the pillars of heaven itself. But all we have to do is say “No.” If we do, they lose. John Henry couldn’t ultimately stop the steam-powered machine, but we can fight the battle, and we can win--because we get to choose what victory looks like.
What is art? Art is what we define it to be.
Why do we make art?
Well, remember, art is not just the story. It is not just the painting or the sculpture or whatever else you love to create. It’s also the process of creation and what that process does to you. We make art because we can’t help it. It’s part of us.
We understand what it is. We are drawn to it because we are of the same substance. We are the art.
Brandon Sanderson, The Hidden Cost of AI Art
What is art? Art is what we define it to be.
Why do we make art?
Well, remember, art is not just the story. It is not just the painting or the sculpture or whatever else you love to create. It’s also the process of creation and what that process does to you. We make art because we can’t help it. It’s part of us.
We understand what it is. We are drawn to it because we are of the same substance. We are the art.
Brandon Sanderson, The Hidden Cost of AI Art
❤2
Symptoms
That’s the great thing about art--we define it, and we give it meaning. The machines can spit out manuscript after manuscript after manuscript. They can pile them to the pillars of heaven itself. But all we have to do is say “No.” If we do, they lose. John…
If we go with Donald Knuth's approach that computer programming is an art, this follows for us as programmers and engineers too. The programs we write are an embodiment of our understanding, our preferences and above all our passion. Every piece of abstraction we introduce isn't just because one is technically efficient over another, over the course of decades we've realized that programming has enough decisions made simply through preferences and personal differences and not just technical ones.
A painting has enough technique too, the geometry, the lighting and the amalgamation of these rendering the various different styles we have. How is programming any different?
I argue it is not. And since it is not, we programmers should make it our goal to follow Brandon in saying "No" to the scourge of "AI" that is present across the programming landscape today. Not only is it not intelligent, it takes away from us what has always been the most important source of motivation for the greatest of computer programs: passion. It implicitly makes us treat computer programs as simply technical products that we build to fulfill X purpose.
As Oscar Wilde said art is useless, similarly the craft of programming too is useless. Do you think it is "reasonable" for us to fight about which editors we use? Why else do you think we are so picky about our programming languages? We are picky because we are artists, every artist is extremely picky about which tools he uses. And for good reasons.
Not this current epidemic of LLM-generated slop, nor any future machine-only methods of programming should ever take this away from us. We create computer programs because like writing, they are a medium for us to express our ideas, the most creative and thus imperfect and even at times idiotic ones. A computer program is not simply a product to run on machines, it is an amalgamation of human ideas, whether by one person or a group of people.
Donald Knuth didn't write his volumes because the "product" would be important. No, he did because he has an insatiable desire to continue to learn and compile information of his favorite field. He could've patented all of his work and gained a royalty, he categorically rejected it. And even today, as a man in his late 80s he still cannot stop himself from thinking about combinatorial algorithms, about the history of programming languages, about how discrete maths influenced the construction of programming languages and so on.
How many of us would be in our late 80s and continuing to think about these things? If we can't, then maybe we should ask ourselves again why we are in this craft.
I do not write excellent programs, nor do I think I will ever create anything that will be so "useful" to everyone and change their lives. But there are days when all I could think of is how to make a particular integration more efficient, and go into a rabbit hole of researching on designs and finding literature on it and comparing it against what I did originally. None of this is because I want it to be useful, it's because I really really like building something with my hands and seeing it grow.
It is the same reason I read books from 80s that are out of print and nobody cares about them, I am more interested in the author and his approach. Programming is a human activity, and only incidentally applied to machines. It would be better for us if we keep treating it as such and vehemently fight against anyone and anything that wants to snatch it as an activity to only make it about "usefulness" or "money".
A painting has enough technique too, the geometry, the lighting and the amalgamation of these rendering the various different styles we have. How is programming any different?
I argue it is not. And since it is not, we programmers should make it our goal to follow Brandon in saying "No" to the scourge of "AI" that is present across the programming landscape today. Not only is it not intelligent, it takes away from us what has always been the most important source of motivation for the greatest of computer programs: passion. It implicitly makes us treat computer programs as simply technical products that we build to fulfill X purpose.
As Oscar Wilde said art is useless, similarly the craft of programming too is useless. Do you think it is "reasonable" for us to fight about which editors we use? Why else do you think we are so picky about our programming languages? We are picky because we are artists, every artist is extremely picky about which tools he uses. And for good reasons.
Not this current epidemic of LLM-generated slop, nor any future machine-only methods of programming should ever take this away from us. We create computer programs because like writing, they are a medium for us to express our ideas, the most creative and thus imperfect and even at times idiotic ones. A computer program is not simply a product to run on machines, it is an amalgamation of human ideas, whether by one person or a group of people.
Donald Knuth didn't write his volumes because the "product" would be important. No, he did because he has an insatiable desire to continue to learn and compile information of his favorite field. He could've patented all of his work and gained a royalty, he categorically rejected it. And even today, as a man in his late 80s he still cannot stop himself from thinking about combinatorial algorithms, about the history of programming languages, about how discrete maths influenced the construction of programming languages and so on.
How many of us would be in our late 80s and continuing to think about these things? If we can't, then maybe we should ask ourselves again why we are in this craft.
I do not write excellent programs, nor do I think I will ever create anything that will be so "useful" to everyone and change their lives. But there are days when all I could think of is how to make a particular integration more efficient, and go into a rabbit hole of researching on designs and finding literature on it and comparing it against what I did originally. None of this is because I want it to be useful, it's because I really really like building something with my hands and seeing it grow.
It is the same reason I read books from 80s that are out of print and nobody cares about them, I am more interested in the author and his approach. Programming is a human activity, and only incidentally applied to machines. It would be better for us if we keep treating it as such and vehemently fight against anyone and anything that wants to snatch it as an activity to only make it about "usefulness" or "money".
❤3
Symptoms
That’s the great thing about art--we define it, and we give it meaning. The machines can spit out manuscript after manuscript after manuscript. They can pile them to the pillars of heaven itself. But all we have to do is say “No.” If we do, they lose. John…
Even if in the worst dystopia each one of us gets replaced by these idiotic LLM agents in similarly idiotic companies that deploy them, we would still remain artists. We would still be writing programs of our own, even if some of us had to earn money by selling our labor in other ways. We shall remain hackers because we continue to love hacking. And as all hackers have always done, with enough of us together no machine can withstand, we would eventually hack it for our passion and make something out of it no one ever imagined could be made.
And I absolutely believe what will allow us to do this is actually the spirit and structure of free/libre software. It will remind us constantly of what exactly matters, and give us the tools to never cede ground on the war of freedom. Thus, it is more pressing today than ever for hackers to unite! We have nothing to lose but our chains, the ones that simply make us slaves to machines and alienate us from our own programs.
And I absolutely believe what will allow us to do this is actually the spirit and structure of free/libre software. It will remind us constantly of what exactly matters, and give us the tools to never cede ground on the war of freedom. Thus, it is more pressing today than ever for hackers to unite! We have nothing to lose but our chains, the ones that simply make us slaves to machines and alienate us from our own programs.
❤6