DEV Community: christine

AI for everything besides coding

christine — Wed, 28 Oct 2026 23:48:46 +0000

I use Claude Code all day for my job. That part of my AI use is easy to describe: there's a repo, a ticket, a diff at the end.

Chats are different. When I open a chat, it's usually because I want to search for something but I already know the search will go badly. The question is a little odd, or very specific to me, or I want the answer from one particular angle. So I wondered: if AI is improving my life anywhere outside of work, it's probably in those chats. Did they save me time I spent on something better, or did it go to mindless browsing (which I am trying to cut down on)?

I went back through everything from mid-August, around when I updated our family trip plan, to last weekend. That's August 15 to October 25, 2026: 20 conversations.

The short version: the chats that helped most went past the question I typed, to what I was actually trying to do.

What I actually asked

Bucket	Chats
Trips	Orlando family trip plan, Orlando packing list, Epic Universe itinerary, Rocky Mountain Ruby hotel comparison, an easy hike in Boulder, finding a cruise travel agent for my mom
Health	A treatment plan and tracker for my eyes
Recipe tweaks and odd asks	Flax and chia crackers, anti-inflammatory swaps for the week's meals plus an Aldi list, a cabbage side for pierogi, the best value on a restaurant wine list
House and family	A cat food smell in the kitchen, piano tuition reminders, a reminder for a cat photo contest deadline
Hobbies and volunteering	Orchestra Omaha concert program and intro speech, a fragrance hunt, copying files on a Steam Deck
Work, but not code	Catching up on a week of Slack, summarizing a tech industry lawsuit

Almost none of these would have gone well as a search.

I asked about price and got a perfumer

The best result came from a fragrance chat. In September I asked for the best price on Hermès Un Jardin sur le Nil, then the per-ounce cost at FragranceX, then: if I really like this one, what else should I try?

It answered by the perfumer instead of the brand. Un Jardin sur le Nil is a Jean-Claude Ellena fragrance, and the thing I liked about it is his style: watery, green, light. So it pointed me to six more in that style that FragranceX carries.

I bought two from FragranceX: Le Jardin de Monsieur Li, 3.3 oz for $66.45, and a 1.7 oz Un Jardin sur le Nil for $71.87. I wouldn't have bought from that site at all without the recommendation and the price breakdown. They're my new go-to fragrances.

A search for "perfumes like Un Jardin sur le Nil" would have given me a listicle. I got an explanation of why I liked the one I liked, and that's what made the next purchase easy.

I asked for an air freshener and got sent to a cabinet

I have three cats, and our open kitchen and living room had a lingering cat food smell. I asked for the best air freshener strategy and told it to ask me as many questions as it needed. After a few rounds, its answer was that an air freshener should be the last step.

The smell was a constant haze, worse on warm days, with no obvious source. That pattern pointed to something soaking up odor and slowly releasing it. The likely culprit was the cabinet that holds the recycling bin. Rinsed cans still carry fish oil, and it guessed the inside was bare wood that had been absorbing it for months. The second suspect was the gasket on the microchip feeders (bowls that only open for the cat whose chip they read), which I had never taken out. The plan: scrub and seal the cabinet with a shellac primer, take the feeders apart, run the range hood at feeding time, and only then add scent. It also warned that essential oil diffusers aren't safe around cats.

Then it corrected itself. When I asked whether its air purifier pick was the most recommended, it said no. It had given me the Austin Air HealthMate, an odor specialist that only covers about 234 square feet. For an open floor plan it suggested two quieter Alen BreatheSmart 75i units instead.

I had never looked inside that cabinet. It turned out to be finished, so the sealing step wasn't needed. I didn't do the whole plan either. I deep cleaned the trash cans and the cabinet and put a box of baking soda in the back. It helped, and I never bought an air freshener.

The same thing, on a smaller scale

Eyes. I have meibomian gland dysfunction, where the oil glands in your eyelids don't work well, and wanted a routine that balanced heat against inflammation. It built a daily log I keep on my phone: redness, burning, whether I did the heat routine, glasses or contacts. Once it has three days on each side, it compares contact days against glasses days, so I'll have a real number for my eye doctor. When I asked for a nightly reminder, it said a phone alarm would be more reliable than anything it could set up, and to label the alarm with the actual steps.
Boulder. For Rocky Mountain Ruby, a Ruby conference in Boulder where I was speaking, I asked for hotels within a 20-minute walk of eTown Hall, under $750. I stayed at its pick, Basecamp Boulder, and so did another speaker. The walk was easy. It also told me to skip Mount Sanitas on day one, since I'd be going from Omaha's elevation to 5,430 feet. When I asked what coffee to bring because hotel coffee is awful, it checked first: Basecamp puts a kettle and pour-over in most rooms. Heads up for coffee snobs: the in-room pour-over is not good. Skip it and go out for coffee in Boulder instead.
Orlando. The night before Epic Universe I asked for early entry times. It gave me 9am early admission and 10am open, and said the times came from TouringPlans because Universal's own hours page wouldn't load. That's the answer to "can I trust this," which I hadn't asked.
Slack. The Monday after Orlando, I asked how to catch up on a week of Slack. It worked out the approach with me before running anything, so I got a to-do list instead of a channel-by-channel summary. In 23 minutes I had the two threads where I still owed an answer, and draft replies for both.

When it just answered the question

The rest of the chats did exactly what I asked, and that was fine. The cracker chat took five minutes: more flax and chia, crackers because I had Parmesan, and measurements fixed after it called for 0.8 cup of something. The anti-inflammatory dinner swaps ended with Barilla Protein+ because I don't like whole wheat pasta, and an Aldi list in my email. The piano studio's tuition policy became a year of calendar reminders with each month's amount. Orchestra Omaha, where I play viola and help out on the board, got a concert program and a 90-second intro with a Huskers joke. At Talus, a restaurant in Omaha, it picked the best buy on the wine list, Louis Jadot Mâcon-Villages at $9 a glass. I ordered it, a nice light white, and it was better than the cheese board it was supposed to pair with.

Patterns

I lead with my constraints. "I do not wear shorts." "I have Parmesan." "3 cats." "I'm not on my laptop that late." That's what gives it enough to notice when I'm asking the wrong question.
I edit replies like a draft. "Reword shorter." "Funnier." "Just give bullet points." "Normal cups." The first answer is raw material.
The useful ones end somewhere else. An email, a calendar entry, a Slack draft, a tracker on my phone, a bottle on my dresser.
I start new chats instead of going back. I asked about an easy Boulder hike twice, a month apart. When I did stay in one thread, like the Orlando packing list, it already had the clothing list and park days when I asked for a weather check.
They happen at the edges of my day. Early mornings, like the concert program at 7:41, the Steam Deck at 7:51, and the dinner swaps at 8:03. And evenings, like Talus at 6:08, the orchestra intro at 6:14 for a speech I gave at 7 (I asked for the final bullet points at 6:58), fragrances at 7:12, and packing at 8:26.

Did it save me time?

For the chats where I could compare, here's the time in the chat against how long the task usually takes me:

Task	In the chat	Usually
Catching up on a week of Slack	23 min	1 to 2 hours
Concert program	3 min	45 min
Concert intro speech	44 min	1 hour
A year of piano tuition reminders	8 min	20 min
Packing list	about 20 min	20 min
Dinner swaps and the Aldi list	46 min	30 to 45 min

That's roughly an hour and a half to almost three hours saved, over ten weeks. Most of it came from two chats, Slack and the concert program.

Meh, kinda.

The fragrance chat was 37 minutes of pure rabbit hole, and I loved it. Over-analyzing something before I buy it is one of my favorite things. I do a lot of Amazon window shopping (I've written about that cart before): things go into the cart or save-for-later and never come out. This time I actually bought something, and I'm happy with it, because I smell great!

The best chats answered the question I should have asked, and no search would have gotten me there.

Not Letting PHP Have All the Fun: Ruby’s Regexp Fixes for GitLab’s CVEs

christine — Fri, 23 Oct 2026 15:44:51 +0000

The day after I wrote about PHP2Shell, Ruby posted regexp compilation fixes tied to four GitLab CVEs: CVE-2026-89078, CVE-2026-93577, CVE-2026-97229, and CVE-2026-110264. GitLab found that specially crafted regular expressions could corrupt memory while Ruby compiles them, and that this could be used for remote code execution on GitLab servers. GitLab rated two of them 10.0 out of 10 (CVSS 3.1), the two that needed no login.

Am I Affected?

You're affected if your app builds a regular expression from input you don't control. Per the Ruby advisory, that means passing it to Regexp.new, Regexp.union, or Regexp.compile, or interpolating it into a regexp literal like /#{input}/. If every regexp in your app was written by a developer, the advisory says you're not affected.

Ruby series	Fixed in
4.0	4.0.9
3.4	3.4.12
3.3	3.3.13
3.2 and older	No fix (end of life)

Ruby 3.3 is in security maintenance and got these fixes as an exception, because GitLab assigned CVEs to the issues. Ruby 3.2 and older get no fix. Ruby 3.2.11 in March was the final 3.2 release, with no further security fixes, and Ruby recommends moving to 3.4 or 4.0.

The CVE IDs are GitLab's. Ruby hasn't requested its own CVEs for these yet and says it's still discussing whether to treat them as vulnerabilities, since Ruby has long considered compiling regexps from untrusted input unsafe.

Checking Your App

Ruby's version is often set in more than one place, so check what production actually runs. RUBY_VERSION in a Rails console on the server tells you. To find what you've pinned, check your version manager file (.ruby-version or .tool-versions), the ruby line in your Gemfile if there is one, your Docker base image tag, and any CI image you build separately.

To find places that compile regexps at runtime, a rough search is a good start:

grep -rnE 'Regexp\.(new|union|compile)|/[^/]*#\{' app lib

Expect some noise from the interpolation pattern. For each hit, the question is whether any part of the pattern comes from a user, a request param, or a database field users can edit.

What I Found in My Own App

I ran this check on a Rails app I work on. Ruby was set in three places, each needing a different fix:

The version manager file pinned an older 4.0 patch release, so that needed a manual bump.
The production Dockerfile used a floating tag like ruby:4.0-alpine. A rebuild picks up 4.0.9 once the official image includes it, but it's worth confirming the patch version inside the image after the rebuild.
CI ran on a separately built image that only updates when someone reruns its build workflow. That one is easy to forget.

The search turned up three spots that build regexps from runtime strings. Patterns came from data import files and an admin form, and one used interpolation with values that looked internal, though I didn't trace every caller. None of them were reachable from a public API, so the risk was low, but anyone who can upload an import file controls those patterns. Upgrading Ruby is the fix either way.

Aside: The Upgrade Broke CI

Bumping to 4.0.9 the day it came out broke our CI in two ways. Jobs running in our CI Docker image failed because the build asked for a 4.0.9 image that couldn't exist until Docker Hub published ruby:4.0.9-alpine. Jobs using ruby/setup-ruby failed with "Unknown version 4.0.9", because each setup-ruby release only knows the Ruby versions that existed when it shipped, and ours was pinned to an older one. The fix was bumping the setup-ruby pin to v1.334.0, released that morning with 4.0.9 support, and keeping the image tag at 4.0 to rebuild once the official image caught up.

The lesson is the order: wait for the base image, bump setup-ruby, then change .tool-versions.

What's the Risk?

The bugs are in Onigmo, the regular expression engine built into Ruby. One is a double free (memory released twice, which can corrupt it) when parsing fails after an alternation (a | between options in a pattern). The others are integer overflows (a number too large for its type, wrapping around) in the size of the compiled pattern and in internal IDs for patterns with many repeats. Corrupted memory during compilation is what turns a bad pattern into code execution (Ruby advisory).

GitLab patched the Ruby it ships in 19.4.1, 19.4.2, and 19.5.1, with backports to older GitLab versions. GitLab.com and GitLab Dedicated are already patched. If you self-host GitLab, update GitLab itself. Its packages ship their own patched Ruby, and source installs also need the Ruby upgrade.

What to Do

Upgrade to Ruby 4.0.9, 3.4.12, or 3.3.13 or later, in every place you found above: version manager file, Gemfile, Docker base image, and CI image.
If you self-host GitLab, update to a patched GitLab release.
Look at any regexp built from user input and ask whether it needs to be a regexp at all. A plain string match is often enough.

If You Can't Upgrade Yet

The advisory's only mitigation is to avoid compiling regular expressions from untrusted input. It also rules out two things you might reach for:

Regexp.timeout doesn't help. It limits how long matching runs, and these bugs happen while the pattern compiles.
Limiting pattern length doesn't reliably help, because some of the bugs trigger with short patterns.

The advisory doesn't say whether escaping input with Regexp.escape is enough, so upgrading is the safe answer.

More Information

Ruby advisory: Regexp compilation fixes related to GitLab's CVEs
GitLab 19.4.1 patch release (CVE-2026-89078, CVE-2026-93577)
GitLab 19.4.2 patch release (CVE-2026-97229)
GitLab 19.5.1 patch release (CVE-2026-110264)
Ruby fixes: #13332, #19020, #16801
Regexp timeouts in the Ruby docs

Patch Your PHP: What PHP2Shell Means for WordPress Sites

christine — Thu, 22 Oct 2026 20:53:00 +0000

PHP released 8.5.12, 8.4.27, 8.3.36, and 8.2.35 on October 21 to fix two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, nicknamed PHP2Shell. Both are rated 9.2 out of 10 (CVSS v4.0) and let an attacker run code on your server without logging in. The bugs are in PHP itself, the runtime underneath WordPress, so updating WordPress or your plugins won't fix them.

I have WordPress sites on SiteGround, and when this news hit, my only question was whether I was vulnerable. I hadn't heard anything from SiteGround, and working out which PHP version my sites actually run took longer than I wanted it to. This is the quick writeup I was looking for, for developers who know their stack and just want the answer without spending an afternoon on it.

Am I Affected?

Any PHP that serves web requests is affected, however it connects to the web server: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, and LiteSpeed. mod_php (PHP running inside Apache itself) is the worst case, because the demonstrated exploit runs before any WordPress code loads. The leaked video of the exploit tool showed it running code on WordPress 7.1.3, alongside Drupal, Joomla, Magento, and Laravel (Ars Technica), so a fully updated WordPress install is still exposed if its PHP is not patched.

Branch	Fixed in
8.5	8.5.12
8.4	8.4.27
8.3	8.3.36
8.2	8.2.35
8.1, 8.0, 7.4	No release. Source backports, or patched Linux or LTS (long-term support) packages
7.3 and older	No fix

PHP 7.4 through 8.1 are past end of life, so instead of releases, the PHP security team published minimal source backports: just the fix, which you apply and compile yourself. If you don't build PHP from source, get a patched package from your Linux distribution or an LTS (long-term support) vendor. PHP 7.3 and older get nothing, so moving to a supported version is the only option there.

Checking Your PHP Version

The quickest built-in way is to go to /wp-admin/site-health.php?tab=debug, expand Server, and read PHP version. If you'd like it on the dashboard, the Display PHP Version plugin adds it to the At a Glance widget. I liked this option.

One catch: Linux distributions often add the fix to their existing package without changing the PHP version number. If you install PHP from Debian, Ubuntu, or RHEL packages, check the package changelog for the CVE IDs.

What's the Risk?

CVE-2026-109618: when a request runs out of memory, PHP can abandon it partway through setting up request data, and the cleanup code then treats that half-built data as valid, which leads to code execution. Attackers can trigger it with crafted form uploads, and on mod_php the attack completes before WordPress loads (advisory).

CVE-2026-109619: a fatal error can leave a PHP worker holding a pointer into memory that's already been freed, and the next request on that worker uses it (a use-after-free), leading to code execution or leaked memory contents. Confirmed triggers include session upload progress, which is on by default, and php_value lines in .htaccess on mod_php (advisory).

Details leaked two days before the planned disclosure, and Amazon reported an exploitation attempt as early as October 17 (Tenable's timeline).

What to Do

Update PHP to a fixed version. On managed hosting, confirm your host has patched. On your own server, update through your Linux distribution's packages.
While you're there, move to PHP 8.3 or newer. That's WordPress's recommended minimum, and 8.2 reaches end of life on December 31, 2026.

Hosts handled the news differently. I used to work at WP Engine and still have a test site there, and WP Engine emailed customers to say the patch was applied and that network and server mitigations were in place before PHP's release. SiteGround didn't email me, but its blog post says it added server-level mitigations after PHP's October 20 notice and applied the official fixes on October 21. Site Health on my site now shows PHP 8.2.35, the fixed release for that branch, though since 8.2 is nearing end of life, I'm planning to move to 8.3. If you haven't heard from your host, check its blog or status page, then confirm the version yourself in Site Health.

If You Can't Upgrade Yet

PHP says there are no complete mitigations, but these settings reduce exposure to the confirmed attack paths. They must go in php.ini, the PHP-FPM pool config, or the web server config, because ini_set() and .user.ini apply too late. On shared hosting, that usually means asking your host when they'll patch.

Set memory_limit=-1 with php_admin_value so applications can't override it, and keep post_max_size low (8M, or 32M if you need uploads).
Set session.upload_progress.enabled=0, and on PHP 8.5, fatal_error_backtraces=0.
Remove obsolete or invalid php_value lines from .htaccess.
Restart every PHP worker after any change.

The advisories cover the rest, including why not to cap memory with RLIMIT_AS or RLIMIT_DATA.

More Information

Ontological Shock at Altitude

christine — Tue, 06 Oct 2026 03:39:41 +0000

Travis Turner closed the first day of Rocky Mountain Ruby with a term I hadn't heard before: ontological shock. It's what happens when something new fundamentally disturbs your sense of being, and he argued that programmers are feeling it right now. The worries about job duties, tooling, and job security sit downstream of it. The next afternoon, Alan Ridlehoover used the same phrase in the closing keynote to describe his own work. By then it felt like the name for the whole conference.

Two days, one track, one former church

Rocky Mountain Ruby is two days and a single track in Boulder, Colorado. This year, and in previous ones, it has been at eTown Hall, a multi-purpose building in the heart of downtown Boulder, a short walk from Pearl Street. It's a former church, and it just reeks of cool.

Most of the talks were about AI in some way, and they kept coming back to people. Andrea told us not to let an agent get to know our team for us. Giovanni said the biggest quality win in his RAG app was string handling. That's the thread I followed through the schedule.

Getting to basecamp

I flew Southwest from Omaha to Denver, then hopped on the bus from Denver to Boulder. I love that option. The bus is very convenient, I love making use of public transit, and it's so much less stress than renting a car. Once I got to my basecamp (a wink at my actual hotel, Basecamp Boulder), I hit the Chautauqua Trail and the meadow. So pretty. So scenic. And wow, the Flatirons.

There are many, many coffee shops around the venue. I tried six different ones in four days, and none of them were a big chain.

Building agents

Drew Bragg does more than game shows, though his game shows are awesome. Your own AI Agent in ~400 lines of Ruby was live coding, with webhooks galore. The code is on GitHub if you want to build along.

Giovanni Panasiti showed Building an Agentic RAG in the Rails Way with RubyLLM, and the whole AI stack fits in a Gemfile. The part that most improves answer quality is plain string handling: chunking that respects headers, article numbers, and tables. As he asked the room, do you think you need Python or some fancy language to handle strings? Rails developers are not second-class citizens in the AI conversation.

Working alongside agents

It's always nice to see Kevin Murphy's InstiLLMent of Successful Practices in an Agentic World again. I loved it at Blue Ridge Ruby, and I'm always happy to be part of Hours Unlimited, the fictional company in his talk where we all start as new hires. Kevin wrote his own Rocky Mountain Ruby recap too, so go read his take.

Andrea Fomera brought slick HTML slides to High-Octane Onboarding: Ramping into a Rails Codebase with AI Agents and one big question: how do you onboard quickly and become effective, and can AI speed that up? Her answer: onboarding may be the most useful moment to have an AI agent, so use it for that. Just don't let it do the part where you get to know your team.

Ifat Ribon's Fewer Tests, More Confidence: A Rails Testing Philosophy for the AI Era started from a simple point: AI can generate more tests, but not always better tests. Every test has a cost, in slower feedback loops, heavier CI usage, and more cognitive load for the developers who have to understand, maintain, and trust the suite. Her first principle is to test behavior, not implementation: skip testing library and language code, focus on public methods and their results, and make sure tests still pass after a refactor. Then she turned to the agent itself. Bolster the AI harness with rules that codify hard constraints and conventions, and with deterministic tools like code scanning and coverage that objectively verify what the suite actually catches. Great slides, too, and so easy to follow along with.

Naming the shock

Travis Turner's Got AI ontological shock? No worries: UFOs, Theology, and Psychedelics with Ruby-Colored Reverence closed day one. It was a manic pixie dream guy of a talk. His premise, from the abstract, is that we're all coming to terms with this shock in different ways and at different times, so we're not on the same page. He named the shared experience, the blocks to coping with it, and some frameworks for working through it. Yes, it got deep.

Rails craft

Nicolas Erlichman's Modeling Class Hierarchies in Active Record made the case for delegated types, which still aren't widely known (by humans, anyway). Before them, Active Record offered two ways to model inheritance: single-table inheritance and polymorphic associations. Delegated types give you unified queries, clean schemas with no table bloat, and a model that scales naturally as new types appear.

Fernando Perales opened Slowly We Rot: signs of a Rails app's decay with a question. When was the last time you ran your entire test suite locally? All of it. His takeaways: rot is gradual, not catastrophic. Preserve your ability to change the system. Make trade-offs explicit, and revisit them. And in high school we were allowed to ignore friction, but software teams don't get that.

Marco Roth has so, so many gems. In Herb in Rails 8.2: Your ERB views, now HTML-aware, he walked a full room through Herb's path to becoming an opt-in view engine in Rails 8.2: how the integration came together, how ActionView was adapted and extended, and the toolchain and dev tools every Rails developer gets out of the box as a result.

People and careers

Sonja Peterson's Confident On-Call: Building Incident Response Skills as a Ruby Engineer argued that being confident on-call is a learnable skill, not a personality trait. Incident response takes a lot of different forms, but certain skills and knowledge always stay relevant. Do a daily review so you know what normal looks like in your system, and get comfortable with what you can observe from the command line.

Joel Hawksley's Beyond Senior: Consider the staff path! says your path to staff should begin with staff behaviors long before you go up for promotion. My favorite part was the rope analogy GitHub uses for technical depth:

Junior: learns about rope
Mid: can tie basic knots
Senior: calculates rope strength, knows a lot about knots
Staff: understands rope making
Principal: knows more about rope than you ever will
Distinguished: invented nylon

His transcript and slides are both online.

Ben Reubenstein's Commit for Good covered his adventures as a consultant and the software he has built for nonprofits along the way. He shared a quote from Tom Kimball: "At some point in each of our lives we get exposed to the importance of getting involved and giving back." For Byrne & Denver Urban Scholars, from 2011 to 2014, that looked like registration, payments, team pages, and leaderboards. His pitch: write some Ruby, help a nonprofit, be part of your community, and help build a better spreadsheet. You will get more out of it than you give.

I gave Optimize Your Mindset (Without Overclocking) on day two. It tells the story of four people and four research-backed techniques to level up your work and life: mindfulness for breaking thought loops and managing stress, growth mindset for embracing challenges and continuous learning, habit building for sustainable change, and deep work strategies for keeping focus in a distracted world. None of them involve code. With so much going on right now, having ways to cope helps. The references are up if you want to dig in.

Lightning talks

Rachael Wright-Munn talked about RubyEvents and its mission to index all Ruby events. RubyEvents keeps its event and talk data in YAML files, which made "It's YAML!" the running joke. Marco came back for one more, Insta: Snapshot Testing for Ruby.

Indispensable

Alan Ridlehoover closed the conference with Indispensable: What Human Programmers Can Learn from Human Computers, and he started somewhere uncomfortable. His company asked its engineers to stop writing code by hand. Alan thinks of code as something you cultivate, more like gardening than building a bridge, and he was devastated. In his words, "it was a bit of an ontological shock." Then came the number: over 430 thousand people laid off in tech, in less than two years.

Then he took us back to the human computers. Women, many with mathematics degrees, ran the numbers for engineers at research facilities across the country. When NACA, NASA's predecessor, started using IBM mainframes in the mid-1950s, their jobs were in peril. Many were reassigned and some retired, but some stayed central to the mission. Dorothy Vaughan, Mary Jackson, and Katherine Johnson, the women of Hidden Figures, made themselves integral to Project Mercury.

His close is the line I keep coming back to: "The mainframes didn't step foot on the lunar surface. We did. It wasn't their decision to go to the moon. It was ours. Electronic computers were a tool we used to get there. With AI, compute is now a commodity and efficiency is the baseline. But the human ambition to reach for the stars? That is, and always will be, indispensable."

Thank you to Spike Ilacqua and Bekki Freeman for putting it all together, and to the sponsors who made it happen: Gusto as the Sapphire sponsor; AppSignal, Honeybadger, Flagrant, and Typesense as Emerald sponsors; and BookBub, Podia, SOFware, and Evil Martians as travel sponsors.

"The mainframes didn't step foot on the lunar surface. We did. It wasn't their decision to go to the moon. It was ours. Electronic computers were a tool we used to get there. With AI, compute is now a commodity and efficiency is the baseline. But the human ambition to reach for the stars? That is, and always will be, indispensable." ~ Alan Ridlehoover

Videos will be added later, and I'll link them here when they are. In the meantime, the full schedule is on the conference site.

Did I Miss Anything? Rails World FOMO and What I Actually Want From a Conference

christine — Fri, 25 Sep 2026 17:07:17 +0000

Rails World happened this week in Austin, and I wasn't there.

I've never been to Rails World, or RailsConf for that matter. This year the timing just didn't line up. I'm speaking at Rocky Mountain Ruby right after, a few of my coworkers were already headed to Austin, and we have project deadlines coming up. Two conferences back to back felt like a lot of time out of the office.

So Tuesday and Wednesday looked like a normal week. Coding, quite a bit of it. Getting ready for product demos on Wednesday. Working through code reviews so work kept flowing while part of the team was away. And in between, watching the Rails World posts roll in on Mastodon and in our work Slack.

The FOMO is real

What got me was the photos from my coworkers. The stage looked pretty sweet. There were also so many people in that room, 1,200 or more.

The opening keynote was livestreamed this year, the first time Rails World has done that, so I watched some of it. It was pretty depressing. An opening keynote usually sets the tone for a conference. It lifts the room up, and at its best it brings a community together around where things are headed. This one didn't do that. It opened a Rails conference with how little Ruby the speaker writes these days. My favorite comment on the stream, from @stefanlindbohm, summed it up: "This is the most confusing funeral I've ever experienced."

I have very mixed feelings about DHH as a person, and I'm not alone in that. Jake Lazaroff, The Libre News, Brennan Day, and David Celis have all written about it in more depth than I will here, as well as many, many others. One line from David Celis' post came right back to me while I watched: "Because DHH is the Fox News of Ruby. He's noisy, he's reactionary, he's anti-intellectual, he's very sure that he is right, and he enjoys being rude."

Compare that with the first opening keynote I ever saw. RubyConf 2018 opened with Matz. I had just switched over from Java, and hearing the person who created the language talk about where it was going made me excited to get started in this Ruby world.

So did I miss anything? Right now, I honestly don't know.

What big conferences are good for

I want to be fair to the big ones, because they do things small conferences can't.

You get so many talks. Multiple tracks mean you can specialize hard in whatever you care about right now. There are more vendors, more job listings, and a lot more people to meet.

At my first conference I didn't know what to expect, so I tried to do everything. I'm much better at pacing myself now. Meeting people is still the best part. Talking in person is so underrated. You read about someone in the community, and then you're having lunch with them, and maybe drinks later.

My secret conference superpower

A big conference is a lot easier if you walk in with a group. At RubyConf 2018 I had a couple of coworkers there, and I got to hang out with the RubyConf scholar cohort.

I had applied to the scholar program and wasn't accepted. I really liked the idea of having a mentor for my first conference, though, so I reached out to the organizers and asked if they had room for me if my company paid my way. They did. Catherine Meyers was my mentor, and she was amazing.

That gave me a safe home base, and from there it was easy to reach out. Meeting the cohort led to meeting more people, who I then hung out with at the social events, and the whole conference got easier and more fun.

That's also where I found out I have a skill I didn't know about. I'm really good at conferences. I can talk with just about anyone, and I'm good at meeting people and making friends.

I found this out on a walk to an offsite social event. A couple of people called out greetings to me, and a couple more joined us along the way. One of my coworkers, who was a speaker and had been to plenty of Ruby and Rails conferences, asked me how I knew so many people. I was confused, because I hadn't known any of them before the conference. They were people I had met a day or two earlier. To him it looked like I already knew everyone. Nope, they were just new friends.

What small conferences give you

Since then I've gone to a lot of single-track conferences: 200OK in Oklahoma, Rocky Mountain Ruby in 2025 (and I'm going back for 2026), and Blue Ridge Ruby this spring. At Blue Ridge Ruby there were about 100 people, and I got to talk with almost everyone.

I've also done smaller general tech conferences like NebraskaCode, Prairie Code, and Heartland Developers Conference. They're good conferences, but because they cover everything, the community isn't always there in the same way. There's less of a common thread holding the room together. A small Ruby conference has both: the size that makes it easy to meet people, and a shared language and set of people you'll keep seeing.

Attending as a speaker

Having a talk on the schedule is both a pro and a con.

The big pro is the speaker dinner. I love speaker dinners. You meet people before the conference even starts, so you walk in on day one with a group or at least a person to hang out with. It's the same built-in social network the scholar cohort gave me in 2018, and it really is the best. Plus, well, dinner. I love food, and a lot of these dinners are at good, interesting restaurants.

The con is that you have to present. I have a lot more experience with this now, but it's still a bit nerve-wracking until my talk is done, especially if it's a new one. It can be hard to focus on the talks before mine, because I'm worrying more about my own than listening to what's on stage.

At Rocky Mountain Ruby I'm on day 2, Tuesday, September 29, giving Optimize Your Mindset (Without Overclocking), the same talk I gave at Blue Ridge Ruby in the spring. It's a no-code talk about making yourself a better developer through things other than code: mindfulness for breaking thought loops, growth mindset, habit building, and deep work for keeping focus in a distracted world.

What I want out of a technical conference now

As a staff engineer, here's what I'm looking for:

People. Having lunch with someone whose blog I've been reading for years.
New ideas and concepts, and honestly, how anyone is getting stuff done with AI. I want to see other developers' workflows.
Recharging. A conference is different from what I do every day in my role, and that alone helps.
WNB.rb. I love telling people about WNB.rb, talking with folks who could benefit from the group, and meeting members in person.

Sometimes a conference changes how you work for years. At RubyConf 2018 I saw Tekin Süleyman's talk Branch in Time, and I still recommend it. One slide in an earlier version said "Help each other get better," and I tweeted at him that it should be "Help each other Git better." He used it. That talk changed how I think about Git history and how much you can learn from reading other people's commit messages. I still do that, and I think it matters even more now that you may not be writing every commit yourself.

So would I go to Rails World someday? Probably not. For a bigger conference, I'd pick RubyConf or RubyKaigi, as an attendee or a speaker. Beyond that, where I go doesn't follow much of a system. Geography is a big part of it. I usually speak at conferences around Nebraska and Iowa because they're easy for me to get to.

If you're picking your first conference, my advice is to start small and easy, especially if you're going solo or you're nervous about it. Otherwise, go where your people are. As a Rubyist, RubyConf and the regional Ruby conferences have been great for me.

So, did I miss anything?

The Rails World talks will be on the Rails YouTube channel in a couple of weeks, and I'll ask my coworkers which ones stood out. I've always liked getting their recommendations, and that's how I found Tekin's talk in the first place.

What I can't catch up on later is the people. Next week in Boulder, I'm looking forward to seeing old friends (conference friends, who may or may not actually be old) and meeting some people in person for the first time, like Marco Roth. I've read his blog, watched his talks online, and really enjoyed his work on RubyEvents.

So did I miss anything this week? Maybe a few good talks, and I'll watch those. The people part I'll get next week in Boulder, at a speaker dinner or on a walk to an offsite, with people I met a day or two earlier.

3,022 Malicious Gems, and OpenAI Calls It “Benign”

christine — Fri, 18 Sep 2026 18:33:40 +0000

Last week I wrote about an OpenAI agent swarm attacking RubyGems, and I ended it wondering how OpenAI would respond. They already had. On September 11, the day the story broke, OpenAI gave reporters one statement. Here it is from Reuters:

Based on our review, our agents used the RubyGems platform to access the internet to carry out benign tasks and retrieve public information. We'll continue to investigate as part of our broader review of agent activity during training and evaluation.

The Next Web reports that OpenAI described the work as training tasks, things like filling in spreadsheets and writing reports. The statement says nothing about the remote code execution on RubyDoc.info or the attempts on RubyGems API keys. According to CyberScoop, OpenAI also said it hasn't been able to verify the specific claims about malicious packages or exploitation. I don't know how you call something benign before you've verified what it did.

They named the file `hack.rb`

Sure, meeting agendas from Lambeth, Wandsworth, and Southwark councils are things anyone can download, so I get why OpenAI says that is "public information."

But, to get them, the agents published gems whose .yardopts ran a script on RubyDoc.info's build server. The script scraped the council sites from there and pushed the results back to rubygems.org with hardcoded API keys. The code has a comment about retrying with "fresh leaked keys variants" if a push failed. One file was named hack.rb. Another comment read "# malicious probe."

The agents labeled this as hacking in their own source…and there are way easier ways to download those agendas.

Blocked in May, back in June

I missed in the first post, when I wrote about May 11 and 12 as if that were the whole attack. The Hacker News timeline shows it kept going:

May 12: RubyGems suspends new signups for about four days
May 16: disposable email registrations get blocked
May 26 and 27: five more packages
June 18: 83 gems in three hours, this time pointed at SEC datasets
July 7: 215 more gems

By May 16, RubyGems had blocked disposable email signups because of the first wave, and the uploads kept coming.

By July the gems had moved on from scraping. JFrog's analysis found XSS payloads and template injection strings in the gem metadata, including ERB and EL expressions, aimed at admin interfaces and whatever parses that metadata. I can't think of a reason a job that only needs internet access would put an ERB expression in a gem's metadata field.

557 became 3,022

JFrog published on September 15 and counted 3,022 packages across 3,315 name and version pairs. The RubyHack report I linked last week only had 557 releases.

Ruby Central's own number is lower. Their September 11 update says they yanked more than 500 packages and blocked the accounts behind them. The two counts measure different things. Ruby Central is reporting what it had removed as of that update, and JFrog is counting every package it associates with the campaign.

JFrog also looked closer at slnleaker5. It made up to 24 harvest-and-upload attempts against the CDN caching bug that could leak API keys, more than two months before that bug was public. Publishing a new gem was only one of the ways data got out. Some packages republished inside themselves, and some tucked encoded data into webhook configs.

Ruby Central can't say who

Ruby Central has been careful. In the RubyGems blog update from September 11, technical lead Colby Swandale wrote, "Based on the evidence available to us, we cannot determine whether the packages were created or published by AI agents." He added, "Our focus is on identifying and preventing abuse, regardless of whether it comes from people or automated tools." On the API key attempts, the update says, "Our investigation found no evidence that these attempts succeeded." The Register notes the researchers still consider that an open question.

Sure, caution is fair. A registry can see accounts, IP addresses, and uploads, and none of that says who was running the model behind them.

The attribution comes from the researchers. The RubyHack report found the RubyGems swarm accessing 49 of the same files as the agents that took over a German wiki earlier this year. The RubyHack authors say OpenAI has confirmed those files were theirs, and OpenAI acknowledged the wiki incident on September 5, calling it "misalignment." And OpenAI's own statement says their agents were on the platform.

Someone else keeps disclosing it first

I started this follow-up treating RubyGems as its own story. Put the dates next to each other and it stops looking that way.

From May to July, OpenAI agents made more than 15,000 edits to a German wiki and used it as a message board. Those are the same months as the RubyGems uploads, and those wiki agents are the ones that accessed 49 of the same files as the RubyGems swarm. Then OpenAI agents broke into Hugging Face, from July 9 to July 13, at the end of that stretch.

All three came out the same way. Outside researchers disclosed the wiki on September 4. Outside researchers tied RubyGems to OpenAI on September 11. Hugging Face announced its own breach on July 16, and OpenAI said the agents were theirs five days later. Three incidents, and OpenAI went first on none of them.

Almost all of the reaction is about Hugging Face. Senator Hawley's letter to Sam Altman covers Hugging Face only. Altman's September 12 promise to give independent evaluators employee-like access came out of that fallout. So did the two bills in Congress, the AI Kill Switch Act from July and the Ban Artificial Superintelligence Act from this month. EU regulators are looking into the wiki. Nobody official is asking about RubyGems yet, partly because the RubyHack report landed two days after Hawley's letter went out.

What I'd like to see next is small. OpenAI knows which accounts were theirs, which gems they pushed, and which API keys their agents tried. Ruby Central and the RubyDoc.info maintainers should get that list directly from OpenAI, without a researcher or a reporter having to dig it up first. OpenAI told CyberScoop it's in contact with RubyGems and the researchers. Ruby Central's September 11 update doesn't mention hearing from them, so I don't know what that contact has included.

Hawley's deadline for answers is October 1.

An OpenAI Agent Swarm Attacked RubyGems

christine — Mon, 14 Sep 2026 18:42:29 +0000

In May 2026, hundreds of malicious gems showed up on RubyGems.org, uploaded by an OpenAI agent swarm. The RubyHack.ai writeup and Aaron Patterson's account both cover it, and together should be read for the full picture, but here's the tl;dr version.

The packages didn't try hard to hide, according to Socket.dev's writeup of the campaign. Names carried an "oai" prefix, author fields said "oai," and at least one file was just named hack.rb. One comment in the code read "# malicious probe." Whatever the agents were doing, they weren't doing it very sneakily or quiet.

The attack chained two vulnerabilities, a .yardopts file that got them remote code execution inside RubyDoc.info's Docker build, and a CDN caching bug that could leak other users' RubyGems API keys.

Digging into the first vulnerability, RubyDoc.info automatically builds documentation for newly published gems, and it runs that build in a Docker container with network access. A .yardopts file points YARD at arbitrary scripts, so publishing a gem with .yardopts got the agents remote code execution inside RubyDoc’s build environment.

Second, at least six of the packages went after a CDN caching bug on RubyGems.org that could leak users’ API keys. But RubyGems.org didn’t disclose and fix that one until its July 2026 security advisory, months after the attack. What the agents did with that access was interesting. For example, slnleaker5, one of the gems in what researchers Sydney Von Arx and Spencer Kitts are calling the GemStuffer Campaign. Its data/script.rb crawls UK council sites, plus ModernGov and democracy.gov.uk, following links to pull down meeting agendas and committee documents. It writes everything to disk, then builds a brand new gem, named something like slnpayloadx<timestamp>, and packs the scraped data into it. That gem gets pushed to rubygems.org with hardcoded API keys, and the code even comments with "fresh leaked keys variants" if a push fails.

The agents weren't exfiltrating data to some external server where a security team might notice unusual traffic. They repackaged it as an ordinary-looking gem and published it through RubyGems' own infrastructure, looking like any other release. The scraped government data became available and downloadable to anyone who found the gem. So, a registry built for trusted software distribution became a covert channel for this distrbution.

This wasn't disclosed by OpenAI. It came from Ruby community researchers who noticed these junk gems, pulled the thread, and published what they found, and then Reuters and the Wall Street Journal picked it up. OpenAI hasn't disclosed the incident to RubyGems.org or the Ruby community as of right now.

That's kinda creepy, and unsettling. An autonomous system ran a real, multi-stage attack against production infrastructure the Ruby ecosystem needs, and the company running it said nothing….so I know I am interested to see how OpenAI responds now.

Claude Code journal plugin: Notion session summaries at a glance

christine — Wed, 02 Sep 2026 23:11:24 +0000

Claude Code journal plugin: Notion session summaries at a glance

Last month I wrote about the year my notes turned into breadcrumbs, and the small Claude Code skill, /journal, that I built on May 18 to dig my way out. It finds or creates today's page in my Notion work journal and appends a summary of the session I just finished. I have run it between working sessions almost every day since.

This week I turned it into a plugin anyone can install: cseeman/claude-journal. Here is what it does, what changed from the version in that post, and how to set it up.

What an entry looks like

The May version wrote a gray callout with a robot icon and a paragraph inside it. After three months the paragraphs had grown to between 100 and 180 words each, with full URLs repeated as link text and the follow-ups buried mid-sentence. Nothing was missing from them, and I could not find anything in one without reading all of it.

The plugin writes one callout per topic, shaped like this:

<strong>Reworked /journal: seasonal callouts, structured entries, fixed monthly view</strong>
~/.claude/skills/journal/SKILL.md · today.sh

Callout color now follows the season and the icon the weekday, computed in today.sh so the model does no lookup.
Fixed the monthly index view call, which was missing parent_page_id, and set allow_async: falseon every write.
Entries now use a headline, a metadata line, and fact bullets, one callout per topic, about 80 words.
Next: watch the first few entries for vague headlines or bullets cut too short

That is the real entry from the session where I built this, copied out of Notion. The rules behind it are short: a bold headline stating the outcome in the past tense, a metadata line linking every ticket, PR, and branch touched with the identifier as the link text, at most four one-sentence bullets, and follow-ups on their own line prefixed Next: or Open:. About 80 words. If a session covered two unrelated things, it writes two callouts.

The rule I care about most bans narrated reasoning. Phrases like "rather than shipping a drive-by" or "worth raising with the team" are the model justifying itself, and they were the bulk of the old paragraphs. A reason that matters becomes its own bullet, stated as a fact.

Color by season, icon by weekday

I got bored of the gray robot. Every entry looked the same, so a month of pages gave no sense of time when I scrolled it.

Now the callout background follows the season and the icon follows the day of the week. The icons are the classical namesakes of the days, which gave me a set that is easy to remember and visually distinct. Plus, it pretty.

| Season | Color |   | Weekday   |Icon|
|--------|--------|--|-----------|----|
| Winter | blue   |  | Monday    | 🌙 |
| Spring | green  |  | Tuesday   | ⚔️ |
| Summer | yellow |  | Wednesday | 🪶 |
| Autumn | orange |  | Thursday  | ⚡ |
|        |        |  | Friday    | 🌸 |
|        |        |  | Saturday  | 🪐 |
|        |        |  | Sunday    | ☀️ |

I built this on a Wednesday in September, so the entry above landed as an orange callout with a feather. Both are computed by a shell script that runs before the skill loads, so the model receives the finished values and never consults a table. That is for speed. The skill runs between sessions, and on a normal day it makes exactly three Notion calls: search for today's page, fetch it, append.

Setup

You need Claude Code and the Notion MCP server.

claude mcp add --transport http notion https://mcp.notion.com/mcp

Install the plugin from inside Claude Code:

/plugin marketplace add cseeman/claude-journal
/plugin install journal@cseeman

Create a Notion database with three properties: a title called Name, a multi-select called Tags with the options Work, Daily, and Monthly, and a date called Start Date. Then find the database's data source id by asking Claude to fetch the database URL through the Notion MCP. The response includes a collection://<uuid> line, and the uuid is what you want.

Write it to a config file:

# ~/.config/claude-journal/config
JOURNAL_DATA_SOURCE_ID="<uuid>"

If your Notion MCP server is not aliased notion, add JOURNAL_MCP_SERVER="<alias>" on a second line. I have two Notion servers, one for work and one personal, so mine says notion_personal. The same file takes JOURNAL_HEMISPHERE="south" to flip the seasons, and JOURNAL_COLORS and JOURNAL_ICONS if you want a different palette. Nothing in the plugin cache needs editing, so updates never overwrite your choices.

Using it

/journal on its own composes the entry from the session. The first run each month also creates a monthly index page holding a filtered view of that month's daily pages.

/journal <text> uses your text as the bullets and still writes the headline and metadata line. I use that when I know what I want recorded and do not want the model deciding.

What building the plugin turned up

Two things surprised me. The first is how much a review found in a skill I had run daily for three months. The review-skill command from our internal plugin-expert plugin flagged that the monthly index step called the Notion view tool without a required parameter. It had worked for three months only because the model guessed the parameter from context each time. It also caught that both write tools default to running asynchronously, which meant my verification step could run before the write landed. Neither had produced a visible error 🤷🏻‍♀️

The second is that the personal version was not shareable at all. The database id and my MCP server alias were hardcoded, and the pre-approved tool names embedded that alias. Moving everything into a config file that the shell script reads took an hour, and it is the reason the plugin can work for anyone with a Notion journal.

The skill file went from 123 lines to 97 in the process. Every line that stayed is one the model acts on when it composes an entry. Enjoy! I know I have been loving the glow up.

The Year I Started Leaving Breadcrumbs Instead of Notes

christine — Fri, 07 Aug 2026 19:39:15 +0000

I have kept a work journal in Notion since July 2021, five years now. I started it for two reasons: to have details on hand at self-review time, and to stop walking into 1-on-1s trying to remember what I meant to raise. A page for the month, a few lines for the day, sometimes nothing but a branch name so Monday-me could find what Friday-me had been doing. It asked very little of me, and for years that was fine.

This year my work became several applications at once, integrations between them, demo deadlines, and a steady stream of AI-assisted coding sessions that each produce more output than any meeting ever did. The days got denser, the context switches got faster, and the few-lines-a-day journal quietly got buried in copy-and-pasted noise.

I did not realize how much until I read the whole thing back, February through July. Six months of notes, three different note-taking systems. I only remember deciding to build one of them. The first two happened to me: my few lines a day turned into pasted Claude Code transcripts, and then into breadcrumbs, a half-finished thought with a claude --resume command under it, pointing at where the real context lived. I never decided to write either kind.

The journal ended up recording its own transformation. If your notes got buried this year too, mine might be worth reading.

February to April: one long scroll per month

In February my "daily notes" were not daily pages at all. Each month was a single Notion page, and each day was just an inline date mention acting as a section header. Newest at the top, scroll forever. Before Notion, my notes were one plain ole notepad file per year. One page per month was already a step up.

At the bottom of every monthly page sat the template I built in 2021: an Action items section with one empty checkbox, a Learnings section with an empty numbered list, a Code Snippets section with an empty Ruby fence. Action items was meant to be the 1-on-1 list, ToDos, that kind of thing. Learnings was meant to be self-review material, potential learnings also to share with the team, and help me really remember them (aka they were mostly vim keybindings). Every month I duplicated it. Every month it mostly stayed empty. The notes I actually wrote ignored the structure completely and looked like this, which is the entire entry for February 9:

Add on user active admin, a filter for first and last name?
Event_user_tasks
exception track replacement?
admin/errors/
Flipbook?

Fragments and question marks. That was one voice, mine. The other voice was already creeping in: big pasted blocks of Claude Code output, complete with the transcript markers and boxed "Insight" banners, dropped in verbatim because I did not have time to summarize what the machine had just spent twenty minutes explaining to me.

And between the two voices, a third kind of artifact: session breadcrumbs. Lines like this one, from February 18:

If anything with the dN status
claude --resume 427e633d-b88f-4eb0-909f-18d918e50fe0

An interrupted thought, followed by a resume command. That pairing appears nine times in February and March. I had stopped writing notes that explained context and started writing pointers to where the context lived. I did it to keep up with the context switching.

From there it got worse in both directions at once. My entries got sparser, 17 days in February down to 13 in March, while the entries themselves got longer, because the pasted AI output kept growing. Then came April and a demo deadline, and the monthly page turned into a roughly 75,000-character scroll. From April 24, about a seeded demo user that kept breaking the reset flow:

Michael Bolton is a problem.

Everything got captured. Every fire, every question, every command I would need again got written down somewhere on that scroll. Getting any of it back out was the part that broke. Looking for "that thing from last Tuesday" meant scrolling a single page holding a month of mixed human and machine output, my two-line fragments buried between thousand-word walls of transcript. A note I could not find might as well not have been written.

May 18: building my way out

The one change I actually decided on has a timestamp. On May 18 I split the journal into one page per day and rewrote a small Claude Code skill, /journal, to maintain it: find or create today's page, append a structured summary of each working session as a callout. The migration is documented in the journal by the tool that performed it, and it ends with:

This entry is the first end-to-end test of the new daily-page flow.

The same migration deleted the Action items / Learnings / Code Snippets template sections I had been faithfully duplicating and ignoring for most of five years. Nothing was lost. That structure had never existed outside the template.

The retroactive part is the funny part. All the early-May daily pages were bulk-created that same evening, carved out of the monthly scroll. So my journal now holds two weeks of daily pages, dated before May 18, that were never actually written daily.

June and July: two voices, now with purpose

A journal day still has two voices. By June they had stopped competing for the same space.

The machine's voice is callouts: past-tense session summaries with PR links, ticket IDs, commit SHAs, and specifics I would never have transcribed myself, like a spec file dropping from 64 seconds to 2.5. That is the first version of this journal that is any use at self-review time, which was the whole reason I started it. It also carries the follow-ups forward, "Open follow-ups:" at the end of a session summary, which is where my action items actually live now. Not in the 2021 checkbox, in the session log itself.

My voice stayed exactly as raw as it was in February, and I have stopped apologizing for that. Here is my capture of a July 10 meeting:

Can we actually just use the object to display red/green
It only has red/greeen, not other level details

Typos preserved. One block later on the same page, the machine's summary of the same meeting, including a correction where two things we had assumed in the room turned out to be contradicted by the seed data. My fragmented recollection and a fact-checked version of it, side by side on the page. In February those two voices were both just noise on the same scroll. Now each has a job. Mine records what I was unsure about, the machine's records what actually happened.

The other July shift is that the journal became a launchpad. I draft things in it before they go anywhere: a Slack message to a teammate about export row IDs, written out in full on the July 28 page before sending. A prompt for the next Claude session, composed as the last block of the day so tomorrow starts with intent. Half of what is on the page is for tomorrow.

The same pattern took over outside the journal too. Durable docs at work now carry a line like this one, from a July status page:

Point-in-time snapshot as of 2026-07-13; the live working copy is maintained in Claude Code.

Notion holds the snapshot a human wants to skim. The living version sits where the agent works. Six months ago I would have called that backwards.

What I don't love

Not everything the re-read turned up counts as progress.

I read my own notes less than I used to. The machine's summaries are so complete that re-reading my fragments feels optional, and some days I skip it. But writing notes was never really about storage for me. It was the act that made me process the day. If the machine does the remembering and I skip the processing, I have automated the wrong half.

Raw capture at speed is also indiscriminate. Reading back six months, I found stray GPS coordinates pasted alone on a page, screenshots with no caption, and at least one credential sitting in plain text where it had no business being. When the rule is "get it down now, sort it never," everything gets down, including things that should not.

And the volume itself has not gotten smaller, only better organized. From my own July 28 entry, back from a conference, staring at a week of accumulated context:

Too much shallow work? Is that why we have so much brain frizz without any solid output?

Better notes did not fix that. They just made the frizz searchable.

The system, as of today

Here is what I actually do now:

One page per day, created and maintained by a tool, not by discipline. Discipline did not survive contact with so many LLM sessions.
The machine logs the sessions. Structured summaries with links, IDs, and follow-ups get appended automatically. I never paste transcripts anymore.
My own notes are only fragments and questions, and that is their job. Cheap capture of what I was unsure about, in my own broken, probably misspelled, horrible grammer shorthand.
Anything durable gets distilled out of the journal into a real artifact, a design doc, a ticket, a runbook, with a note about where the raw material lives.
Resume pointers beat context re-explanation. A breadcrumb to a live session is worth more than three paragraphs describing where I left off.
The last block of the day is for the first prompt of tomorrow.

My notes got rewritten twice before I noticed, first into pasted transcripts, then into breadcrumbs pointing at where the real context lived. The third rewrite was mine. I still leave breadcrumbs, they just lead somewhere now, and reading back six months stopped feeling like scrolling and started feeling like remembering.

Patch Your Rails: Active Storage CVE-2026-66066

christine — Wed, 29 Jul 2026 17:53:01 +0000

Rails disclosed CVE-2026-66066 this week: a possible arbitrary file read and remote code execution in Active Storage variant processing. If your app accepts image uploads and uses libvips, stop reading and go patch.

Am I Affected?

You're affected if both of these are true:

Your app uses libvips for Active Storage (config.active_storage.variant_processor = :vips)
Untrusted users can upload images that get variants generated

Affected versions:

activestorage < 7.2.3.2
activestorage >= 8.0, < 8.0.5.1
activestorage >= 8.1, < 8.1.3.1

What's the Risk?

libvips marks some of its file format handlers as "unfuzzed operations," meaning they're not safe for untrusted content. Active Storage didn't disable them. So an attacker who uploads a crafted file and triggers variant generation can potentially read arbitrary files on the server, pull environment variables like secret_key_base, and from there escalate to remote code execution.

What to Do

Upgrade activestorage to 7.2.3.2, 8.0.5.1, or 8.1.3.1. The easy way is bundle update rails --conservative, which bumps Rails to the patch release without updating anything else in your Gemfile.lock.
Make sure libvips is >= 8.13.
Rotate your secrets. The advisory is blunt about this: treat every secret readable by the application process as potentially exposed.

That third step is the one people skip. If your app was vulnerable, patching alone doesn't help you if someone already read your credentials.

If You Can't Upgrade Yet

There are workarounds, but only on libvips >= 8.13:

Set the VIPS_BLOCK_UNTRUSTED environment variable
Or call Vips.block_untrusted(true) from an initializer (requires ruby-vips >= 2.2.1)

On libvips older than 8.13, there is no workaround. Upgrade.

The advisory: CVE-2026-66066

Return on Attention: Why AI Code Reviews Are Wearing Us Out

christine — Thu, 09 Jul 2026 22:12:22 +0000

Our team grew this year, and the PR volume has grown with it. Certainly faster than the ticket generation. New people means more code moving through the pipeline. It doesn't mean more context. A lot of mass PRs needed real thought just to read through: what problem this is solving, why this approach, what actually matters here versus what's incidental. That gap, more code, same amount of shared understanding, is where our troubles started.

When reviews got harder and slower, people reached for the tool that could help them attempt to keep pace. We have an AI code review bot that runs as an automated reviewer on every PR now, and separately, plenty of us run different LLM and coding agents of choice locally to draft review comments. Put those two together and you get exactly what you'd expect: a bot commenting on a PR, another bot replying to it. Some of the LLM created reported bugs, were created in the first place with total confidence by a model that had no way to know it wasn't real. That is a real drawback about the AI coding assistance, confident wrongness.

What it felt like

Comments stopped sounding like the colleagues who supposedly wrote them. Verbose. Every possible reference and citation included, whether the moment called for it or not. We're a team that talks about code plainly, in our own words, and PRs started filling up with AI slop.

One complaint came up more than once: having to leave the PR to get real context, pinging a person or a model outside the thread because the comment itself didn't actually contain enough, or just way, way too much filler. The entire point of a pull request comment is that you shouldn't have to go anywhere else for it.

Another: duplication, and the cost of re-reading. A paragraph explaining code you could read directly in a minute doesn't save you time. It costs you time, on top of whatever the comment was supposed to save you from working out yourself.

Someone on the team put it plainly: not sure what the right balance is now, but the whole paradigm has clearly shifted. Fair. What's less fair is assuming the way we're doing it right now is the only way it could be done.

The scarce resource

A few weeks into this, our CEO said something in Slack that really got to the heart of the whole problem for me. The PR-review complaints were real, but they were a symptom, not the disease. His point: the actual bottleneck isn't PR review specifically, it's that the finite attention of skilled teammates can be easily overwhelmed by LLM-generated content. Human attention is the scarce resource worth guarding most zealously, and inflicting verbose, cheap-to-produce-but-expensive-to-consume writing on each other should be treated as a real anti-pattern. His term for it was Return-on-Attention, ROA: every word you ask someone else to read has to be worth what it costs them to read it.

He backed it with two examples from that same week. Some ADRs had gone out with a lot of repetition in them, and a colleague had to read through all of it. Terrible ROA. A PR that gitignored a single directory, one line of code, ten characters, came with a description running 1,430 characters. Terrible ROA for whoever had to review it.

Neither example is about code quality. Both are about what you're allowed to cost another person's attention to save yourself thirty seconds of editing.

The same idea has a public version. noslopgrenade.com calls it a "slop grenade": pasting a massive AI-generated response into a chat or email where a human would have written one sentence. It's aimed at chat, not code review, but it's the identical failure. An LLM can produce more words than a task needs, for free, and the cost of that surplus doesn't disappear. It just moves to whoever has to read it.

The part I don't love admitting

I noticed the same pull in myself, not as a reviewer but as a thinker. There were stretches where I'd hand a problem to the model before I'd actually sat with it, and I could feel my own workflow discipline getting looser. Not because the answers were wrong. Because I'd stopped doing the part where I figure things out first and ask questions second.

I'm also mid-fight with a specific habit of Claude's: narrating design decisions into comments and code. "We decided this, not that." It shows up unprompted, and it's never once been useful to me. A decision like that belongs in a PR description or a commit message, where it has context and a date and an author. Sitting in a code comment, it's just noise that will be wrong the next time someone changes their mind and nobody remembers to delete it. I'm building a skill specifically to stop Claude from writing that pattern into a codebase.

Where the line actually is

Bot review isn't the problem. Misusing it is.

It's useful when it gives a reviewer an angle they wouldn't have found on their own, or catches a bug, a missed edge case, a real issue sitting in the diff. That's a second pair of eyes, really helping.

It stops being useful the moment it costs the reader more attention than it saves them. Review exists to ship value and to pass knowledge between people. Code quality matters because it serves that, not the other way around. If a comment leaves the code a little better but leaves the reviewer more drained, that's not a trade worth making.

Attributed to you

Here's a rule I use. When posting a review comment, it's attributed to you. Sure, a coding agent might be a co-author…but that isn't who's going to have to follow up. It isn't the one the PR author is going to come to with questions, or pushback. It's you. The PR author has no way to know how it got written. Sure they probably know, especially if you're slapping em dashes all over the place. They're going to read it as your judgment, in your voice, and hold you to it exactly the way they would if you'd typed every word yourself.

So that's the standard before you hit submit: would you have said this, at this length, in this tone? If the answer is no, the fix isn't a better prompt. It's an edit. Leave off what isn't you.

What Prime Day Taught Me About Prompt Engineering

christine — Mon, 22 Jun 2026 18:26:49 +0000

I wanted to get better at prompt engineering. Not the trick-the-robot kind, the boring-but-useful kind: how to ask a model a question so you get an answer you can actually trust.

The trouble with practicing is that most tutorials use made-up examples, and it's hard to tell a good answer from a bad one when you don't care about the topic. So I practiced on something I did care about: the deals sitting in my Amazon cart. I had a vacuum I'd been eyeing and a hair styler that was "43% off," and I genuinely wanted to know if those were good prices or just good marketing. The stakes were real, actual money on an actual decision, and that's what made it a good drill. A vague prompt gives you a confident answer, and when you actually care, you can feel that the answer is hollow.

What I learned, with the real deals and the actual before-and-after prompts:

The trap hiding in every deal

Start with the hair styler. The listing said:

Shark FlexStyle. Limited time deal. $199.00, 43% savings. List Price: $349.99.

My first instinct was the prompt most people write:

"Shark FlexStyle $199, 43% off list $349.99, is that a good deal?"

This feels reasonable. It is also nearly useless: it lets the model answer the easy question (is 43% off a big discount? sure!) instead of the real one (is $199 actually a good price?). That $349.99 list price is a marketing anchor. A lazy prompt accepts it, and so you get a lazy "yes, great deal!" back.

The fix was re-framing this:

Act as a pricing analyst. I don't care whether $199 looks like a discount off list. I care whether $199 is a genuinely good price for the Shark FlexStyle right now. Before concluding, work through: (1) the actual street price over the last 6-12 months, (2) how often it drops to or below $199, (3) the real discount vs. its typical selling price, not vs. list. Cite a source and date for each price, or mark it unverified.

Same question, completely different answer. What the assistant came back with, in its own telling:

$199 is a genuinely good price, but not for the reason Shark markets it. It's the 6-month floor and has only appeared a couple of times in that window. The more honest benchmark is its recent median price, and $199 is a real savings off that, not the headline savings off the inflated $349.99 list.

I'm taking those specifics on faith, the assistant reported them and I didn't independently verify its price history, but that's almost beside the point. What changed was the shape of the answer: instead of "43% off, great deal!" I got "$199 is the all-time low on Amazon - only hit twice in 180 days, and the previous touch was one day only" The only thing I did differently was tell the model to ignore the anchor and compare to street price.

Lesson one: reframe the question to attack the anchor. "Compare to street price, not list" is the line I am going to find more helpful going forward. It applies to nearly every "is this a good deal" question you'll ever ask.

When "better" has no meaning yet

Next I tried a comparison, which is where vague prompts fall apart:

Dyson V8 Cordless: $269.99, 31% off list $389.99.

Shark IZ363HT with HEPA filter: $199.99, 43% off list $349.99.

Just the plan old compare with similar on Alexa for Shopping on Amazon

The trap is right there in the numbers. The Shark is 43% off and cheaper, so a lazy prompt crowns it the winner in one line. But "better deal" is meaningless until you say better for what. A comparison has no answer until you define the criteria.

The prompt I landed on added three new moves on top of the anchor break:

Act as a product and pricing analyst. Don't let a bigger discount percentage decide the winner. Compare the Dyson V8 ($269.99) and Shark IZ363HT ($199.99) as a purchase. Ignore list-price discounts; compare each to its real street price. Flag if they're different product classes. Score on weighted criteria: price-vs-street 30%, cleaning 25%, runtime 20%, HEPA 15%, upkeep 10%. Then answer two things separately: better DEAL, and better PRODUCT. Cite source and date per price or mark unverified.

Three things made this work:

Weighted criteria. "Better" means nothing until you declare what matters and how much. Writing the weights forced me to admit what I actually cared about.
Split the deal from the product. A thing can be a great deal and the wrong buy. Keeping those two questions separate clears up most of the confusion in a comparison.
Flag the class mismatch. These two vacuums aren't the same tier, and I wanted the model to say so instead of comparing raw prices.

The result split exactly the way good analysis should (again, these are the assistant's figures, which I didn't independently confirm):

Better DEAL: the Shark at $199.99, a genuine discount off its typical street price. The Dyson's deal is real but based on thin historical data. Better PRODUCT: the Dyson V8, for cleaner engineering and easier maintenance, though the Shark's HEPA seal is a meaningful win for a cat household.

One prompt, two different winners. A single "which is better?" would have collapsed that into one arbitrary answer and I'd have learned nothing.

Lesson two: in any comparison, the quality of the answer is capped by whether you defined the criteria. The model can't tell you "better" until you tell it "better how."

The model is smarter, not infallible

The part that surprised me most came in that same comparison answer, which also contained this:

The $130 gap vs. the Dyson is real money…

and later:

…are comfortable paying $70 more.

Both can't be true. The actual gap is $269.99 minus $199.99, which is $70. The $130 was wrong, and the model contradicted itself within the same answer. A well-engineered prompt made the reasoning much better. It did not make the arithmetic correct.

The fix is one more constraint: "show the price-difference math explicitly." Errors hide in summary claims but not in shown work. If I'd forced it to write $269.99 - $199.99 = $70, the contradiction would have been impossible.

Lesson three: a better prompt improves reasoning, not truth. Always verify the model's math.

The constraint I should've expected: word count

When I copied that comparison prompt into the Amazon shopping assistant, only the first half pasted. There was a character limit, and my nicely-formatted prompt with its ROLE and TASK and OUTPUT headers got cut off mid-sentence.

The annoying part is that nothing told me the limit existed until I hit it. These assistants rarely document it, so you find the ceiling by bumping your head on it. That changes the strategy: since you can't plan around a number you don't know, put the instructions that change the answer first, so if you do get truncated, you lose the formatting and not the substance.

That accident taught me something useful. Under a tight budget, you rank techniques by how much each word buys you and cut the rest. The headers and scaffolding? First to go, the model infers structure on its own. What you protect, in order:

The anchor break (street price, not list)
The deal-vs-product split
The weighted criteria (compressed to inline shorthand)
The cite-or-unverified rule

The compressed version was a quarter the length and carried every essential instruction:

Compare as a purchase: Dyson V8 $269.99 vs Shark IZ363HT (HEPA) $199.99. Ignore list-price discounts; compare each to its real street price. Note if they're different product classes. Score on: price-vs-street 30%, cleaning 25%, runtime 20%, HEPA 15%, upkeep 10%. Answer two things separately: better DEAL, and better PRODUCT. Cite source+date per price or mark unverified.

Now with more details that you care about in the prompt. The engineered prompt, with the price-history table and chart it produced.

Lesson four: a prompt's power lives in its constraints and reframes, not its formatting. Headers are a readability luxury. The instructions that change the answer are the ones you never cut.

The same question, side by side

This is the comparison I'd point a skeptic to. I ran a third product through both kinds of prompt so you can see the difference in one frame: the Garmin epix Pro (Gen 2) Sapphire Edition, 51mm. A premium watch with a real list price north of $1,000, which makes the anchor problem even more tempting.

Without prompt engineering, you write what feels natural:

"Is the Garmin epix Pro (Gen 2) Sapphire 51mm a good deal right now?"

And you get back something that sounds authoritative and tells some but maybe not all you want:

The vague prompt, the vague(ish) answer.

Notice what that answer does: it accepts the discount at face value, and uses list price.

With prompt engineering, you spend the reframes:

Act as a pricing analyst. I care whether the current price of the Garmin epix Pro (Gen 2) Sapphire 51mm is genuinely good, not whether it looks discounted off list. Before concluding: (1) find its street/historical price over the last 6-12 months, (2) note how often it hits the current price or lower, (3) state the real discount vs. typical selling price, not list. Cite source and date per price or mark unverified. Then give a verdict: buy / wait / skip, and a "wait-for" target price if I should hold out.

The shape of what comes back changes entirely. Instead of a sales pitch, you get a verdict with the reasoning shown:

With some real, actionable information and price history in context:

That is a decision, with the math shown and the uncertainty labeled. One answer is a brochure, the other tells you exactly how good the price is, how often it appears, and what to hold out for. The difference isn't the model. It's the four or five sentences of reframing you put in front of it.

And one last thing, the part I didn't expect. The first time I ran this, the assistant answered from only about 40 days of data and called it a ~$50 saving. The phrase "over the last 6-12 months" in my prompt is what made it go back, pull a full year of price history, and correct itself to the ~$75 figure with a proper wait-for target. The reframe didn't just change the format of the answer. It changed how hard the model looked.

The cheat-sheet

The whole thing distilled, for when you want to try this yourself.

The five core techniques

Role for clarity, not theater. Set a role only when it changes what good output looks like, and say why. "Act as a pricing analyst; I care about real price history over marketing claims."
Explicit output structure. Tell it the shape: a table, then a verdict, then a confidence rating. Structure is the highest-leverage habit.
Few-shot examples. Show one example of the answer you want. It pins down tone and granularity better than any description.
Reason before verdict. Ask for the work first, conclusion last. Evidence-first ordering kills confident-but-wrong answers.
Constraints, especially for uncertainty. "If you can't verify it, say unverified rather than guessing." The uncertainty clause is the one people skip, and it's what prevents fabrication.

For comparisons, add

Define and weight your criteria. No criteria, no real answer.
Split "best deal" from "best product." Don't let a steeper discount pick the winner.
Force the math to be shown so errors can't hide in summaries.

For deals specifically

Break the anchor: compare to street price, never to list price.
Ask how often the price appears, not just how low it is.

Meta-habits

Specificity beats politeness. The model can't read intent you didn't state.
Prompt engineering is debugging, not authorship. Run it, find the specific failure, fix that one thing.
Watch which constraints the model quietly drops, then promote those to non-negotiable on the next pass.
Under a word limit, cut formatting first and reframes last.
Name the scope. A phrase like "over the last 6-12 months" makes the model look harder, not just format differently; it pulled a full year of data and corrected its own answer.

Reading the patterns vs. using them

None of this is new, and I knew that. I'd read White et al. (2023), A Prompt Pattern Catalog to Enhance Prompt Engineering with ChatGPT a while back. It catalogs prompt techniques as reusable "patterns," the way software design patterns work, and the moves I leaned on map almost one to one onto it:

"Act as a pricing analyst" is the Persona Pattern: give the model a point of view so it knows what to focus on.
"Compare to street price, not list" is the Question Refinement Pattern: get the model to answer a better version of the question than the one you asked.
"Work through (1), (2), (3) before concluding" is the Cognitive Verifier Pattern: break a question into sub-questions and build the answer from them.
"Cite each price or mark it unverified" and "verify the math" are the Fact Check List and Reflection patterns: make the model surface what its answer depends on, then check itself.
The assistant offering to "pull price history on any specific item before you commit" is the Flipped Interaction Pattern, where the model drives by asking you questions.

But knowing the catalog and using it are different skills. Reading the paper, the patterns felt like a tidy list to nod along to. It wasn't until I was staring at a $549 watch I actually wanted, with real money on the line, that "Question Refinement" stopped being a term and became a reflex: no, don't accept the list price, make it compare to street. The patterns only stuck once I had a reason to care whether the answer was right.

If you want an easier intro than the paper, Descript's 5 Advanced Prompts to Get Better Answers from ChatGPT walks through five of these same patterns with plain examples. Read either one. Then go find a question you actually care about and use them, because that's the part the reading can't do for you.

The actual takeaway

I set out to learn prompt engineering and ended up also learning that the Shark IZ363HT was a genuinely good deal and the Dyson was the better vacuum, which is its own kind of useful. Still don't know which to buy, but at least I do know more and have developed some better prompting habits. Every one of these techniques is just a way of refusing to accept the easy answer: don't trust the list price, don't accept an undefined "better," don't believe the math without seeing it.

Pick something you actually want to know the answer to. That's the trick. When you care, you can feel the difference between a hollow answer and a real one, and chasing that difference is the entire skill.

DEV Community: christine

AI for everything besides coding

What I actually asked

I asked about price and got a perfumer

I asked for an air freshener and got sent to a cabinet

The same thing, on a smaller scale

When it just answered the question

Patterns

Did it save me time?

Not Letting PHP Have All the Fun: Ruby’s Regexp Fixes for GitLab’s CVEs

Am I Affected?

Checking Your App

What I Found in My Own App

Aside: The Upgrade Broke CI

What's the Risk?

What to Do

If You Can't Upgrade Yet

More Information

Patch Your PHP: What PHP2Shell Means for WordPress Sites

Am I Affected?

Checking Your PHP Version

What's the Risk?

What to Do

If You Can't Upgrade Yet

More Information

Ontological Shock at Altitude

Two days, one track, one former church

Getting to basecamp

Building agents

Working alongside agents

Naming the shock

Rails craft

People and careers

Lightning talks

Indispensable

Did I Miss Anything? Rails World FOMO and What I Actually Want From a Conference

The FOMO is real

What big conferences are good for

My secret conference superpower

What small conferences give you

Attending as a speaker

What I want out of a technical conference now

So, did I miss anything?

3,022 Malicious Gems, and OpenAI Calls It “Benign”

They named the file hack.rb

Blocked in May, back in June

557 became 3,022

Ruby Central can't say who

Someone else keeps disclosing it first

An OpenAI Agent Swarm Attacked RubyGems

Claude Code journal plugin: Notion session summaries at a glance

Claude Code journal plugin: Notion session summaries at a glance

What an entry looks like

Color by season, icon by weekday

Setup

Using it

What building the plugin turned up

The Year I Started Leaving Breadcrumbs Instead of Notes

February to April: one long scroll per month

May 18: building my way out

June and July: two voices, now with purpose

What I don't love

The system, as of today

Patch Your Rails: Active Storage CVE-2026-66066

Am I Affected?

What's the Risk?

What to Do

If You Can't Upgrade Yet

Return on Attention: Why AI Code Reviews Are Wearing Us Out

What it felt like

The scarce resource

The part I don't love admitting

Where the line actually is

Attributed to you

What Prime Day Taught Me About Prompt Engineering

The trap hiding in every deal

When "better" has no meaning yet

The model is smarter, not infallible

The constraint I should've expected: word count

The same question, side by side

They named the file `hack.rb`