Anthropic published a study called "How AI Impacts Skill Formation" exploring how AI assistance affects both productivity and learning when developers work with new concepts. They also published an article exploring some results from the study: "How AI assistance impacts the formation of coding skills" Here are some notes about things I found interesting: Study Design

The researchers recruited 52 software engineers who were familiar with Python and had experience using AI coding assistance tools. The task involved learning Python asyncio, a library most participants hadn't used before. One interesting detail: the article describes participants as "mostly junior" engineers, but when you look at the data, 55.8% have 7+ years of coding experience and 36.5% have 4-6 years. This matters because the findings apply more to experienced developers learning new concepts than to absolute beginners. ChatGPT agrees with me: 

The Core Finding: AI Doesn't Automatically Help Learning

Developers who completed tasks without AI assistance scored higher on comprehension tests. Using AI to generate code doesn't automatically translate to understanding that code. This pattern held true across all experience levels. This matches my experience. When I use AI to generate code, unless I make an intentional effort, I forget about that code very quickly. I need to actively review the code, build a mental model, and trace through the logic. Without that effort, I'm just watching the AI do something and forget about it in a couple of hours. Interesting Finding from the Pilot Study

During their pilot studies, the researchers discovered something telling about how integrated AI has become in developer workflows. Even when explicitly told not to use AI, 25-35% of participants still did. This shows we reach for AI tools almost instinctively now. It's become a default part of how many developers approach problems for a significant part of the developers maybe. What Actually Works: Two Practical Approaches The study identified two approaches that worked well for both task completion and comprehension: Approach 1: Generation-Then-Comprehension: Generate code with AI, then ask follow-up questions to understand what it did.

This group showed strong understanding in their quiz results. The key was not just generating the code but actively engaging with it through questions. They used AI as a learning tool, not just a code generator. Approach 2: Hybrid Code-Explanation: Ask AI to generate code AND provide explanations in the same response.

These participants spent more time reading, but developed better understanding. The explanation forced them to engage with the concepts rather than just copying the solution. The slower pace actually contributed to better learning outcomes. The Role of Debugging in Skill Formation

Encountering errors and debugging them plays a crucial role in skill formation. The control group (no AI) hit errors, had to understand why they happened, and learned through fixing them. I think so far this process can't be fast-tracked. Debugging and incidents are essential parts of becoming a better developer. These experiences build the mental models you need to work effectively with code. AI can help you explore codebases and libraries during debugging, but it shouldn't replace the process of understanding why something broke. In my experience, throwing a zero-shot prompt at AI about an error is still a dice roll. Sometimes it works, sometimes it doesn't. Few-shot prompting with specific context, possible root causes, and hints about the codebase helps. But you need to understand the problem first to provide that context. Implications for Engineering Leaders

If your developers rely heavily on AI for code generation, you need processes that ensure they understand what's being generated. During incidents or debugging sessions under pressure, developers need the skills to validate and debug code quickly. If they've been primarily copying AI-generated code without understanding it, they won't have built those mental models. This means thinking about:
- How do we ensure learning happens alongside productivity gains?
- What code review processes help developers understand AI-generated code?
- How do we create space for debugging and error-handling practice?
- What onboarding approaches help new developers build foundational skills?

Every week I curate what the Ruby community shares online and publish it in Short Ruby Newsletter.  In the last few months, I noticed a pattern that looks a lot like what happened with TDD in the early days. The Ruby community is experimenting again. Or at least this is how it feels to me.
As a curator, I spend time every week looking at what the Ruby community shares and talks about.  Let me share here few points I see: 

• Ruby code samples shared on social media are trending down. Posts about using AI and LLMs with Ruby are trending up.
• Article about Ruby and Ruby content seems not to be so much affected by this. There is an increase in articles about using AI and Ruby but there are still good technical articles published. 
• A vocal part of the Ruby community is embracing AI and LLM tooling.
• In general, the approach I see is not hyped-based, but there are many experiments on code quality and on how to use AI/LLMs to create better, faster products.
• I am happy that the Ruby community is running with this. New gems are being published. New skills are being shared. This brings me back to the early days of the Ruby community when we experimented a lot with web frameworks and pushed the boundaries of what could be done.

Another example that I think shaped our ways of working and producing software was TDD. It is maybe too early to tell if we are in the early days of a Cambrian explosion of using AI/LLMs in daily coding life, but could we be there as we were with TDD? Look around at testing frameworks in other languages and see the impact RSpec had on them. So the newsletter is reflecting this reality of our community and I try as a curator to make sure that I include what the community talks about every week.  The scope of the newsletter remains the same: primarily focused on code samples, news, gem releases, articles, and videos. AI and LLM content is there as it should be, showing where community interest lies. 

If you're writing API documentation, always specify units for duration parameters.
Not just "timeout: 30" but "timeout: 30 seconds" or better yet name the parameter if you can "timeout_in_seconds"

This is even more important inside your own codebase. Make sure that variables have proper names or descriptions or comments that specify the unit of measurements moreso in case you are working with durations.  It matters for both developers and LLMs.  When the unit is ambiguous, the LLM guesses. Sometimes it guesses wrong. Then developers debug code they didn't write, hunting for a bug that shouldn't exist. Clear documentation prevents bugs before they happen.

If you are doing some planning this week, consider adding checkpoints for upgrading your \#Rails app  Specifically, if you are still running Rails 7.2T.x  Security fixes end: August 9, 2026
Maybe it sounds like there is enough time but time flies.

Seems like Ruby is pretty well positioned as a language that is token-efficient when used with LLMs.

Source "Which programming languages are most token-efficient?" by Martin Alderson 

I was reading this article: https://www.humanlayer.dev/blog/writing-a-good-claude-md and found there the following:

Then I was curious to find out more about this system-reminder and to identify the source for this assertion. Seems like more sources points to the following article: https://medium.com/@outsightai/peeking-under-the-hood-of-claude-code-70f5a94a9a62 which seems to identify prompts that are send along with the data read by Claude Code from Claude.md.

The Ruby namespace will be renamed to `Ruby::Box`. A merge request regarding this was integrated into Ruby's master branch a couple of days ago by Satoshi Tagomori.

The renaming discussion was initiated by Xavier Noria, who shared compelling reasons for reconsidering the name.S

The accepted proposal, suggested by Satoshi Tagomori, was approved by Yukihiro Matsumoto:

But what is interesting is also that Matz hinted that this should be seen as a low-level API, with potential plans for a higher-level API in the future. This development is exciting as it could unlock new possibilities:

You can find all these and a lot more inside the Short Ruby Newsletter

Noel Rappin - Ruby And Its Neighbors: Smalltalk

Noel Rappin continues his series of writing about Ruby and languages that inspire it (if you have not read yet part 1 Ruby And Its Neighbors: Perl) and this time it is about Smalltalk. I liked very much this article as it goes into talking about the innovations that Smalltalk brings to the table, and at the end I almost felt sad that I never used Smalltalk professionally: 

Vinay Keerthi - Some Smalltalk about Ruby Loops

While Noel's article was writting from the persperctive of someone that wrote Smalltalk professionally here Vinay explores the influence of Smalltalk as someone who does not know Smalltalk. It is still refreshing to see how the influence can be identified:

I'm certain, although I haven't had the time to develop a proper data scraper to confirm, that Ruby articles are appearing more frequently on the front page of Hacker News this year. I'm specifically referring to technical articles. Here's the latest example: Yesterday, there were two posts:

• Joe Masilotti's article about "Ruby Already Solved My Problem" was on the front page and remained in the active list for a while.
• Bruno Sutic's article about the "Friendly Attribute Pattern" was also featured on the front page.

I encourage everyone in the \#Ruby community to move beyond the mindset that "Ruby is declining." From what I observe, Ruby is growing in terms of its presence in public discourse and the resources being created. Let's discuss Ruby more openly. Yes, there are many other languages and frameworks, both new and old. I'm not a fan of criticizing others, so I believe we can talk about Ruby without dissing other technologies. Engage with others and share what we have.

1️⃣ Noel Rappin published an article about Ruby And Its Neighbors: Perl

2️⃣ Sam Ruby published an article about Testing Frozen String Literals in Production

There is actuall an updated version of running the same test Frozen String Literals Redux - A More Rigorous Test.

3️⃣ Vinay Keerthi published a new article about Ruby Blocks

4️⃣ Sid Krishnan published a new article about How does Turbo listen for Turbo Streams?

5️⃣ Avo published an article about Open Graph Image Generation in Rails

You can find more articles to read in the Short Ruby Newsletter: https://newsletter.shortruby.com/p/edition-153\#more-content

Amabile, Teresa M. “A Model of Creativity and Innovation in Organizations.” Research in Organizational Behavior 10, no. 10 (January 1, 1988): 123–67. https://ci.nii.ac.jp/naid/20000708825. Here is how someone described where they were looking for inspiration: in variations and deviations

And then talking about their work environment they hint at something that I also talked in the past: there has to be slack time (and not time on Slack) during the work to be able to thinker with things without having the pressure of always making something that is directly productive:

Ghostty introduced this section to their CONTRIBUTING.md file

And I think this part here is a normal expectation for any AI code contributed to a serious project:

I've been using git worktree for at least five years now. Here's how I set things up at work.

Say I work on `short_ruby` project.  I create a folder called `short_ruby` and inside I have: 

• `short_ruby/main` -> which will always remain as head main
• `short_ruby/pairing` is where I pull branches for code reviews, dig deeper into changes, or show draft code to a colleague.
• `short_ruby/feature_<id>` is a new worktree I create for each feature I work on, and I remove it when I'm done.

Why these folders:

1. I always keep a local copy of the current main branch. This helps me review changes or start something new, since I can quickly check how production works if main is what's deployed.
2. I also want to quickly access any branch I'm reviewing, while still being able to see the main branch. Having separate folders makes it easy to switch between them.
3. I keep a folder for each feature, which is similar to using branches. The difference is that I can always check main or another branch while working on a new feature.

In case you wonder what do I do with DB: 

• When using SQLite this problem is solved by default as each folder will have their own database
• When using with PostgreSQL/MySQL I keep a single database and always do: rails db:reset + rails db:migrate when I have to run migrations inside a folder. In practice it works well. 

Why do I activate Vim in any code editor I work with? 
Imagine a list of emails in a Google Sheet in a single column, one per row, and need to convert it to a Ruby array.

1️⃣ Open Vim
2️⃣ Paste the list
3️⃣ :%s/^/"/ 
4️⃣ :%s/$/",/
5️⃣ Add `[` and `]` 

Done. Enjoy coffee!

I launched a personal newsletter at newsletter.lucianghinda.com This morning, I sent my first email.  Why start this newsletter? I had newsletters set up in multiple places, and managing them became challenging. I want to focus on writing. What will you find inside? 
Mostly the same content I share on social media: Ruby, Rails, Testing, Creativity, and tech-related topics that I find interesting and worth sharing. If you enjoy my content here, you'll appreciate what you find there. This isn't a replacement for the Short Ruby Newsletter, which will continue as usual. My personal newsletter is about my interests, passions, and writings, all related to Ruby, Rails, and tech. In the Short Ruby Newsletter, my role is as a curator, ensuring we include what's essential for the Ruby community. In my personal newsletter, I can focus on what I personally enjoy and find intriguing, while also compiling my writings from various sources. Here is an example of the first edition: https://newsletter.lucianghinda.com/p/welcome-to-my-personal-newsletter-a144