The AI bubble I hope will pop is the one I am standing inside, holding a book, a consulting practice, and the survival instincts of a cartoon coyote who has just looked down.

The AI bubble argument is stuck on the wrong question. Whether it is a bubble matters far less than what a correction would reveal, which is precisely why so many people are working so hard to prevent one.

First, my interests, declared with the solemnity of a witness who has just noticed the prosecutor holding a printed email.

I have written a book about AI. I take consulting work that exists because of AI. My traffic is up because of AI, including yours, right now, meaning that by opening a post about the AI bubble you have personally inflated the AI bubble by approximately one page view.

Thank you. Please open it on another device. This is a very vulnerable economy.

If the whole thing collapses tomorrow I have a materially worse year and you lose a blogger with opinions about it. Only one of us is exposed here and it is not you, so weigh everything below accordingly, ideally while continuing to scroll and perhaps disabling your ad blocker out of respect for macroeconomics.

Everybody Is Arguing About the Wrong Thing

The question in every thread is identical. Is this a bubble, yes or no.

It is a rotten question, because both answers are true simultaneously and everybody keeps treating that as a paradox rather than as Tuesday.

The internet would prefer two buttons: VISIONARY and BITTER. This is excellent interface design for starting fights and a poor way to understand capital markets.

Britain built its railways during a mania so complete that Parliament held an inquiry, which in Victorian terms is roughly the equivalent of posting that we need to have an honest conversation as a community.

Investors were ruined. Fortunes evaporated. Extremely confident people wrote extremely confident pamphlets, some of which were later used as insulation.

And then the trains turned up and ran for a hundred and fifty years.

Nobody has ever known what to do with that, so mostly we do not bring it up.

A bubble is not a verdict on the technology. It is a mechanism for deciding who pays to find out.

The Thing I Actually Want to Say

I hope it pops.

Not because I think the technology is fake. I use it every day and it has genuinely changed how I work. I hope it pops precisely because I think there is something real in here, and at present there is no earthly way to establish which bits.

While money is free, nothing has to work.

A pilot that produced nothing gets renewed, because canceling it would require an actual named human being to say out loud, in a room, with witnesses, that it produced nothing. And that human being has a mortgage and a review coming up and would frankly rather set fire to their own car.

A tool nobody opens stays in the budget, because the license costs less than the conversation.

A program with no measurable output gets a second year, then a third, then a director, then a logo, then a mug.

By year four, the mug is the most successfully deployed part of the program. It works offline, requires no training, and has achieved daily active use.

And there is always a demo. The demo works. The demo has always worked. The demo has been working flawlessly for two years in a carefully controlled environment, like an extremely expensive zoo animal that cannot safely be released.

Which brings me to the thing I find quietly magnificent about this entire industry. Every AI initiative on earth is a pilot.

Not one of them has ever landed.

The runway is a PowerPoint transition. Air traffic control is asking whether the logo should be teal.

Cheap money is not neutral. Cheap money is an anaesthetic.

A correction is not the enemy of this technology. It is the only quality control it has ever been offered.

I will also note, as gently as I can manage, that the people most insistent this is not a bubble are, with almost supernatural consistency, the people holding the equity. That does not make them wrong. A weather forecast from a person selling umbrellas can be correct. You simply do not throw away the window. Their confidence is not evidence, any more than mine is, and mine is worth even less because I am about to mention my book twice.

The Bubble Is Not in Nvidia

Here is where nearly everybody is staring in entirely the wrong direction.

Every bubble conversation is about chip makers and model labs and valuations, and most of you do not own a share of any of it. You believe you are watching a fire on the news, in your pajamas, with a cup of tea.

You are not watching. You are in it. You are, in fact, standing quite near the middle of it holding a laminated badge.

The real overhang is not only on an exchange. It is sitting inside an unknowable number of internal AI transformation programs in perfectly ordinary companies. The exact count is impossible to establish because half are called Horizon and the other half are confidential. I would like to describe one to you, because you have met it and it may currently employ you.

It is called something with a colon in it. The word before the colon is a noun that means nothing. The word after the colon ends in -ing. Nobody has ever finished that sentence and nobody ever will.

Horizon: Reimagining. Velocity: Accelerating. Synergy: Please Stop Asking What It Does.

I have worked with an organization that had two of these running at once with the same word before the colon. They did not know about each other. They shared a floor. One of them had a mug.

It has a steering committee, which is a group of people who meet every two weeks to confirm that they are still steering. Nobody has located the vehicle.

It has a slide with three pillars on it. Always three. Never two, never four. In twenty years I have never once seen a fourth pillar, and I have quietly come to believe there is a role somewhere, possibly outsourced, whose entire function is removing the fourth pillar before the deck reaches the board. That person is doing more for global corporate stability than the rest of us combined and will never be thanked.

It has a RACI matrix. Four people built the RACI matrix. It took a full working day and there was a disagreement about who was responsible for deciding who was Responsible. It has been opened once since, by accident, by somebody looking for a different file.

RACI stands for Responsible, Accountable, Consulted and Informed. In practice it means everybody leaves the meeting saying, “I thought you had it.”

It has a Teams channel with 340 members and exactly one message, posted at launch, eighteen months ago. Eleven thumbs up. No replies. The message reads “excited to kick this off” and is, in a genuine sense, the only completely honest artifact the program has ever produced.

And it has somewhere between four and forty people whose continued employment depends on nobody sufficiently senior ever asking one specific question out loud in a meeting.

When the correction arrives, it will not be a headline about a chip maker.

It will be a calendar invite with no title.

I want to be careful here, because the cheap version of this joke sneers at people who worked extremely hard, and they did. Nobody in that program is a fraud. They were told to go and do AI. They went and did AI. At no point did anybody specify what done was supposed to look like, which is not their fault and is about to become their problem.

Most of This Is Not an Investment. It Is Insurance.

This took me far too long to see and now I cannot stop seeing it.

An enormous amount of AI budget is not buying a return. It is buying protection.

Nobody wants to be the executive who did nothing. Doing nothing is the single unsurvivable option on the entire menu.

You can spend four million on an initiative that produces a dashboard nobody has opened since the demo, and you will be completely fine, because everybody did that, and there is tremendous safety in a herd, particularly a herd that is all running in one direction toward the same cliff at a comfortable jog.

But do nothing, and at some future offsite a person in a quarter-zip will say the phrase “we were slow to move” while looking at a point roughly eighteen inches to the left of your head, and you will feel your career gently detach and drift upward like a balloon at a fair.

The quarter-zip will be charcoal. It will be zipped exactly halfway. Nobody knows why, but this is how strategy enters a room.

So the spending is entirely rational and it is not an investment. It is a premium, paid against a very specific personal risk, and it delivers precisely what insurance delivers, which is peace of mind and no output of any kind.

This explains the numbers considerably better than any thesis about productivity does. It also explains why the spending is so magnificently unbothered by results. Insurance does not become poor value simply because you failed to crash.

And if anybody does ask about results, there is a sentence for that, and everybody has agreed to accept it. We are still early.

We have been still early for three years now. A child born when we first said it can now ask why the dashboard needs a login. At some point still early stops being a stage and becomes a lifestyle.

My Extremely Scientific Bubble Detector

I have developed a diagnostic instrument for enterprise AI. It requires no GPU, no consultant and no steering committee, so there is almost no chance procurement will approve it.

Ask exactly three questions.

What number moved? Not how many people attended training. Not how many ideas entered the funnel. What useful thing became faster, cheaper, safer or better?

Compared with what? If nobody measured the work before the AI arrived, every improvement number is a horoscope wearing a spreadsheet.

Who would notice if it disappeared tomorrow? Not who would notice the budget disappeared. Not who would miss the standing meeting. Who would miss the product?

Three clear answers means you have a product. Two means you have something promising. One means you have a pilot. Zero means you have a keynote.

If any answer contains the phrase “unlocking value,” subtract one.

Ask Them for the Study

Now the part that will get me argued with. I have considered cutting it. I am not going to.

There is far less credible independent evidence of enterprise AI returns at scale than the confidence surrounding the subject would suggest.

Not none. But wildly, comically less than the sheer tonnage of confident assertion would lead you to expect, and much of what does circulate is vendor-produced, self-reported, or measuring something standing politely near the thing being claimed.

Try this. Next time somebody quotes a number at you, ask where it came from. Not aggressively. Curiously, the way you would ask somebody where they got a nice jacket.

What happens next is one of the great comedies of our age.

You will be sent a link. The link goes to an article. The article cites a report. The report cites a survey. The survey asked four hundred executives to estimate their own productivity gains, which is methodologically equivalent to asking four hundred people to rate their own driving and then publishing the results as national road safety policy.

I once followed one of these chains for eleven minutes and arrived back at the press release I had started from. I sat very still for a moment. Somewhere, a physicist felt a disturbance.

The citation had achieved a closed loop before the product had achieved a user.

There is, I have since discovered, a technical name for this.

There is not. I made that up two sentences ago and you believed me for one of them, which is, give or take a conference, the entire epistemic standard of this sector.

And nobody is lying. That is the genuinely remarkable part. Everybody is quoting somebody, in good faith, in a circle, indefinitely. It is a very well dressed game of telephone with a substantial budget and a lanyard.

An industry this large should not be this difficult to audit.

If somebody sends you a genuinely good study, read it properly and change your mind. I have done that twice this year and on both occasions I was significantly less right than I had been enjoying being.

The Part I Could Not Make Funny

I tried. I sat with this section for a while looking for the joke and there is not one in it, so here it is straight.

A meaningful share of current valuation rests on cost reduction that has not happened yet.

Not new products. Not new markets. The expectation that a great many companies will need fewer people, and that the savings arrive later.

Sit with what that actually is, as a financial instrument.

We have priced in a redundancy that has not been announced, at a company that has not decided, about a person who does not know.

I have written a lot recently about people on the receiving end of that. What I had not properly absorbed until this year is that their situation is not a side effect of the enthusiasm. It is the collateral. The number assumes them.

Which leaves two futures and I dislike both.

The savings arrive, and a great many people discover they were a line in somebody’s model. Or the savings do not arrive, which is your correction, and the same people lose their jobs anyway when the programs are canceled.

I have looked for a clean way out of that and cannot find one. Anybody offering you a comfortable answer here is selling something, and I would ask them where the number came from.

What Would Actually Survive

Right. Constructive section, because I am not arguing that none of this is real. I am arguing the exact opposite, at length, in a post that keeps making jokes about pillars.

If money became expensive tomorrow, some of it would be completely fine.

Anything with a measured before and after survives, because it can defend itself in a meeting where the mood has changed and somebody has arrived with a calculator and a grudge.

Anything that removed a real cost rather than adding a capability survives.

And anything a person would keep paying for out of their own money survives. That test is savage and I recommend applying it to your own work first, privately, somewhere nobody can see your face.

What does not survive is everything whose value has only ever been described rather than counted.

I would rather learn that in a correction than across ten more years of nobody checking. Ten years of nobody checking is not a bull market. It is a slow leak, and when it finally goes it takes the good work out along with everything else.

What I Would Do on Monday

Work out which category your own work is in. Not the program. You, personally. Can you point at a measured change, or only at activity that was warmly received? That is an uncomfortable ten minutes and it is considerably nicer to spend it voluntarily than to have it conducted for you by somebody from finance who has printed things.

Go and get the before number. If you are running anything AI-shaped and cannot say what it cost before you started, you have already lost an argument nobody has scheduled yet. Get it now. Roughly is fine. Late is fine. Guessing is not.

If your only metric is “people trained,” congratulations, you have measured attendance. The school system managed that without a model.

Stop repeating numbers you have not traced. This one is on all of us, very much including me. It is the load-bearing wall of the entire structure and it is made of press releases.

And keep using the tools. Genuinely. None of this is an argument for standing back and looking wise. The people who come out of a correction well are the ones who spent the froth years finding out where the thing actually breaks, not the ones who spent them announcing.

Where This Leaves Me

Let me end honestly rather than cleverly, which is harder and I resent it.

I do not know when it corrects. Anybody who tells you they do is guessing with an excellent face on, and their previous guesses are not available for inspection.

I do know I am inside it. I know my income has a shape that would change. And I know I have written sentences over the last two years that were more confident than the evidence deserved, several of which performed extremely well, which is precisely the mechanism I have spent this entire post complaining about while benefiting from it.

The question underneath all of it, who holds the judgment when everybody in the room is confident and nobody has checked, is the argument running through all thirty essays in my book AI: Nobody’s in There. But we’re still in here. Every essay is free to read in the complete online collection, and there is a paperback on Amazon if you would rather hold something real.

That was the second mention. I did warn you.

So yes. I hope it pops. I am fully aware that hoping for a fire while standing in the building, holding a ticket, wearing a lanyard, is not a coherent position.

It is simply the only honest one I have.

And when it does go, here is what I think actually survives.

Not the program. The Teams channel will still be there, all 340 members, one message, eleven thumbs up, excited to kick this off. Nobody will archive it, because archiving it requires a decision.

The mug survives. The mug always survives. Somewhere in about four years a person will open a kitchen cupboard at home, look at a logo for a thing that was canceled before their child could walk, and think nothing at all.

And somewhere the fourth pillar person is still at their desk, quietly removing, holding the whole edifice together with a discipline none of the rest of us managed.

I did check, incidentally, and I am not on the steering committee. After all of this, that feels like the single greatest achievement of my career.

If the bubble never pops, I was being constructively provocative. If it pops tomorrow, I was early. This is not forecasting. It is content strategy, and for once the return is measurable.

This is not a story about whether the AI bubble is real, it is a story about how much more fun everybody is having arguing about that than checking anything.

Reference: Pinal Dave (https://blog.sqlauthority.com/), AI Bubble, X

First appeared on AI Bubble: I Hope It Pops

Naming your book? Here are 10 tips for choosing a memorable, intriguing title that captures your story and makes readers want to read it.

Choosing a title for your book can be harder than writing the book itself. You may have written 80 000 words, solved your plot problems, developed your characters, and finally typed The End. Then you realise you still have to name it.

A good book title can make a reader curious. It can hint at the story, suggest the genre, introduce a theme, or create a question that the reader wants answered. So how do you choose a title that works?

Here are 10 things every writer should consider when naming a book.

How To Choose A Book Title: 10 Things Every Writer Should Know

1. Make Sure It Suits Your Genre

Your title should give readers an idea of what kind of book they are about to read.

A reader looking for a cozy mystery, a romance, or a horror novel has certain expectations. Your title can help you meet those expectations.

There is a difference between:
1. The Murder At Willow House
and
2. A Very Merry Murder

Both could be mystery novels, but they create different expectations.

Look at successful books in your genre. What do their titles have in common? Are they short and sharp? Mysterious? Romantic? Humorous? Dark? Here are some examples:

1. The Haunting of Hill House by Shirley Jackson – It suits the horror genre. The title creates an eerie image and tells us the house is at the heart of the story. It is easy to remember and easy to pronounce. The word ‘haunting’ suggests both ghosts and the psychological effects of fear. It makes you wonder what happened at Hill House and why it is haunted.
2. The Firm by John Grisham – It suits the legal thriller genre. The plot is all about The Firm. It is easy to remember and easy to pronounce. It makes you wonder what it’s about. It creates an image in the reader’s mind. The impersonal name suits the sinister thread of the plot.
3. The God of Small Things by Arundhati Roy – It suits the literary genre. The spiritual implications are intrinsic to the plot. It is also unusual but not so unusual that you would forget it. It is easy to pronounce. It is incredibly descriptive and reveals the lyrical quality of the book.
4. The Silence Of The Lambs by Thomas Harris – It suits the crime genre. It is eerie and unsettling. It is easy to remember and easy to pronounce. It has immediate intellectual and emotional appeal. Why are the lambs silent? What does it mean? As you read the book you realise how the title impacts the main character.
5. A Court of Thorns and Roses by Sarah J. Maas – It suits the romantasy genre. It suggests a magical world with danger and beauty. There is also a hint of romance. It is creates a vivid image in the reader’s mind. The title makes you wonder what kind of court this.

2. Make It Relevant To Your Story

Your title should have some connection to the book. It doesn’t have to explain your story. It simply needs to feel as if it belongs to it.

It could refer to:

1. The main character
2. A place
3. An object
4. An event
5. A relationship
6. A line of dialogue
7. A central idea
8. A recurring image
9. The main conflict
10. The theme

For example, The Book Thief tells us something important about the protagonist and immediately makes us curious about the story. The Hunger Games tells us about the central event of the novel, and it makes the reader wonder what the games are.

3. Make It Memorable

Readers see hundreds of book titles. You want yours to stick out. A memorable title is often simple, distinctive, or unexpected. It may create a strong image or raise a question.

Think about titles like:

1. Gone Girl
2. The Great Gatsby
3. The Road
4. The Fault In Our Stars
5. The Seven Husbands Of Evelyn Hugo

These titles are very different, but they all give the reader something to remember.

Try saying your title aloud. Then say it again later. Can you remember it? If you can’t, your reader may struggle too.

4. Make The Reader Curious

A good title can create a question in the reader’s mind.

1. Gone Girl: Who is the girl? Where has she gone?
2. The Seven Husbands Of Evelyn Hugo: Who is Evelyn? Why did she have seven husbands? What happened to them?
3. The Silent Patient: Who is the patient? Why isn’t she speaking?

Give the reader just enough information to make them want to know more.

5. Make It Easy To Say And Spell

Your title should be easy to read, say, and remember because people talk about books. They recommend them to friends, search for them online, and try to remember them later. If your title is difficult to pronounce or spell, it may be harder for readers to share.

This doesn’t mean you should avoid unusual words or names. A distinctive word can make a title better. Just make sure that the difficulty is deliberate.

But, if your reader sees your title and thinks, How do I say that?, you may want to reconsider.

6. Don’t Be Afraid Of A Short (Or Long) Title

Short titles are often powerful.

1. Beloved
2. Rebecca
3. Dune
4. It
5. Normal People

A short title can be easy to remember and look good on a book cover. But don’t assume that shorter is always better.

Some good titles are long:

1. The Curious Incident Of The Dog In The Night-Time
2. The Guernsey Literary And Potato Peel Pie Society
3. The Seven Husbands Of Evelyn Hugo

Don’t cut a great title simply because it has more than five words.

7. Make It Visual

Think about what happens when someone sees your title on a book cover.

1. Can they picture something?
2. Can the words create an image, mood, or feeling?

Where The Crawdads Sing is a good example. The title creates a sense of place and mystery before the reader knows anything about the story. As does Little Fires Everywhere.

A visual title can also give you, or your publishers, ideas for the cover.

Try writing your title on a blank page. Does it look interesting? Does it create an image?

8. Let Your Title Reflect The Heart Of The Book

Your title can reveal something about the deeper meaning of your story. A book may have a complicated plot, but underneath it there may be a simple idea. It might be about:

1. Love
2. Loss
3. Freedom
4. Family
5. Revenge
6. Identity
7. Belonging
8. Ambition
9. Forgiveness

Find the theme at the heart of your story. Then see if there is a word, phrase, image, or idea that captures it. This can give you a title that means more to the reader after they have finished the book.

1. The Secret Garden by Frances Hodgson Burnett – The garden is not just a physical place. It represents healing, growth, friendship, and emotional renewal.
2. The Kite Runner by Khaled Hosseini – The kite becomes a symbol of childhood, friendship, betrayal, guilt, and redemption.
3. Atonement by Ian McEwan – The single word captures Briony’s lifelong attempt to make amends for the harm she has caused.
4. The Remains of the Day by Kazuo Ishiguro – The title reflects the literal days remaining in the protagonist’s life and the regrets left behind by the life he has lived.

9. Look For The Title Inside Your Book

You may already have your title without realising it. Look through your manuscript. Highlight phrases that stand out. Look at chapter titles (if you have them), descriptions, dialogue, letters, poems, and songs. Pay attention to anything your characters repeat.

You can also look for:

1. Interesting phrases
2. Unusual combinations of words
3. Questions
4. Contradictions
5. Metaphors
6. Recurring images
7. Important objects
8. Places
9. Lines of dialogue

You don’t need to use the words exactly as they appear in your manuscript. They could simply lead you to your title.

1. Look at The Things They Carried by Tim O’Brien. The soldiers carry physical objects with them, but they also carry fear, memories, guilt, grief, and responsibility. The phrase appears throughout the book, so O’Brien found his title in an idea that was already woven into it.
2. In The Perks of Being a Wallflower by Stephen Chbosky, ‘wallflower’ captures Charlie’s position as an observer who feels apart from the people around him, and the idea is woven into the story.
3. Look at Catch-22 by Joseph Heller. Heller turns a phrase from the novel into the title. ‘Catch-22’ becomes the name for the impossible situation at the heart of the story.

10. Test Your Title

Don’t fall in love with your first idea. Write down 10, 20, or even 50 possibilities. Then test them.

Ask yourself:

1. Does it suit my genre?
2. Is it memorable?
3. Does it make the reader curious?
4. Is it easy to say and spell?
5. Does it create an image or mood?
6. Will it look good on a book cover?
7. Is it too similar to another well-known book – especially a recent one?

Ask other people too. Give them your shortlist without explaining the story.

1. Which title makes them curious?
2. Which one do they remember?
3. Which one sounds as though they would actually pick up the book?

Where Else Can You Find Ideas For A Book Title?

If you’re completely stuck, look beyond your manuscript.

You can find inspiration in:

1. Shakespeare – The Fault in Our Stars – the title comes from Shakespeare’s Julius Caesar.
2. The Bible – The Sun Also Rises – the title comes from Ecclesiastes and is echoed by the novel’s ideas about renewal and endurance.
3. Poetry – Things Fall Apart is taken from ‘The Second Coming’ by William Butler Yeats.
4. Songs – One Flew Over the Cuckoo’s Nest – the title comes from a nursery rhyme that appears in the novel.
5. Literature – The Curious Incident Of The Dog In The Night-Time – the title comes from a line in Arthur Conan Doyle’s Silver Blaze, which is referenced in the novel.
6. Proverbs – The Daughter Of Time – the title comes from the old proverb ‘Truth is the daughter of time’.
7. Myths and legends – The Penelopiad – Margaret Atwood takes the figure of Penelope from Homer’s Odyssey and builds her own story around her.
8. History – The Paris Wife – Hadley Richardson was Ernest Hemingway’s first wife. The historical figure and setting are central to the novel.
9. Art – Girl With A Pearl Earring – the title comes rom Vermeer’s famous painting. The novel imagines the story behind the painting.
10. Places – Brooklyn – the title is simply the name of the New York neighbourhood, but it becomes connected to Eilis’s new life and sense of belonging.
11. Old sayings – The Devil’s Advocate – the title is an established expression about a person who takes an opposing or unpopular point of view in a discussion.
12. Newspapers and dictionaries

The Last Word

Choosing a book title is a creative process. Your first title may not be your final title. You may discover a better one halfway through writing the book. You may find it in a character’s dialogue, a line you nearly deleted, or an image that keeps appearing in your story. Don’t rush it. Write down every possibility, even the silly ones. Combine words. Try different lengths. Read them aloud. Look at them on a page. Then choose the title that makes you want to open the book.

For fun – try our generators for these genres:

1. Fantasy Book Title Generator
2. Literary Book Title Generator
3. Thriller Book Title Generator

by Amanda Patterson
© Amanda Patterson

More posts from Amanda:

1. 10 Ways To Move Your Plot Forward
2. 10 Ways To Create Dangerously Nuanced Antagonists (With Examples)
3. The 4 Pillars Of A Memoir
4. Writing A Memoir? Narrow Your Focus
5. How To Write A Query Letter In 12 Easy Steps (With Examples)
6. 5 Essential Exercises For Creating Characters
7. 7 Reasons Introverts Make Great Writers
8. What Is Anger? 37 Ways To Write About Anger
9. How To Write A One-Page Synopsis (With Examples)
10. 9 Ways To Set Up A Believable Fictional Breakup

Top Tip: Sign up for our free daily writing links.

The post How To Choose A Book Title: 10 Things Every Writer Should Know appeared first on Writers Write.

Scott Thurlow isn’t a morning person. So much so, he wants to change state law.

In 2019, Washington lawmakers voted to put the state on permanent daylight saving time if Congress ever allows it. Thurlow has a different idea: Stop changing the clocks now, even if that means staying on Pacific Standard Time for a while.

Thurlow spent 32 years at Microsoft in product management for franchises including the original Outlook, Teams and, most recently, Copilot. A constant stressor was working across time zones. 

“We always dreaded the time zone changes on either end because it was meeting chaos,” he said. “Talking with India, which is like 12 hours off, went from really bad to worse.”

In July, Thurlow took part in Microsoft’s voluntary retirement program, and was featured in a GeekWire story along with several others. Last week, he launched Last Fall Back Washington, a nonprofit campaign built around what he’s calling the Last Fall Back Act. The idea is straightforward: Washington should move to permanent Pacific Standard Time immediately. 

Thurlow’s campaign is timely: British Columbia is dropping its seasonal clock changes and moving to permanent daylight time, meaning Washington will fall an hour behind its northern neighbor from November until March. Thurlow argues the difference could complicate everything from cross-border travel to transportation schedules and business meetings.

His own proposal would make that gap year-round at first, since Washington would sit on the winter clock while B.C. stays on the summer one. He accepts the tradeoff: stop the switching now, and get back in sync later if Congress makes daylight time permanent nationwide.

He also points to research linking the spring clock change with short-term increases in heart attacks, workplace injuries and fatal crashes — in 2020, one study published in Current Biology reported that fatal crashes increase by about 6% in the week after the spring time change.

Under the federal Uniform Time Act, states can opt out of daylight saving time changes, but only by staying on standard time. Permanent daylight time requires an act of Congress. Permanent standard time does not, which is how Arizona and Hawaii do it. That’s the path Thurlow’s proposal would take.

“If and when Congress ever really does act,” Thurlow said, “we would snap into daylight time.”

Done waiting for Congress

In July, the House passed the federal Sunshine Protection Act by a 308-117 vote, sending the bill to the Senate. The legislation would make daylight saving time permanent nationwide, but the Senate has not taken it up. Thurlow isn’t counting on that changing — although President Trump is pushing for it.

“It’s going to end up withering on the vine and stalling,” Thurlow said.

Washington’s Legislature has also considered permanent-time legislation, but bills introduced since 2022 have stalled without reaching a floor vote.

Washington has two types of citizen initiatives: an initiative to the people, which goes directly to the ballot, and an initiative to the Legislature, which gives lawmakers the opportunity to pass the measure themselves or send it to voters.

Thurlow plans to spend the coming months building support for the latter approach and pushing legislators to introduce and pass the Last Fall Back Act when the 2027 session begins.

“The single most effective thing we can do is have lots of people contacting their legislators,” he said.

If lawmakers again decline to act, he expects to file an initiative to the Legislature around March 2027. The campaign would then need to collect about 386,000 signatures, providing a cushion above the 309,000 valid signatures required. If lawmakers still don’t pass the measure, it could go before voters in November 2028. 

Experts are divided 

Experts seem to agree Washington should stop changing its clocks — but disagree on how to go about it. 

University of Washington law professor Steve Calandrillo has long advocated permanent daylight time, and has testified against Washington legislation that would put the state on standard time. He told GeekWire he appreciates Thurlow’s efforts to pressure Congress, but doesn’t want Washington to spend years on standard time while waiting for federal action.

“I don’t want to see us go in the wrong direction,” he wrote in an email.

Under Washington’s current system, daylight saving time effectively functions as the state’s default for about two-thirds of the year. Permanent standard time would move sunset an hour earlier throughout that period, Calandrillo argues, creating safety risks and other costs.

Evening darkness is more dangerous than morning darkness, he argues, because more people are traveling and spending time outside in the evening — and there’s a greater chance of crime.

Other UW researchers have split on the question. Biology professor and circadian researcher Horacio de la Iglesia has testified in favor of permanent standard time. 

Environmental and forest sciences professor Laura Prugh testified against the 2024 bill alongside Calandrillo, citing research she co-authored that modeled about an 8% increase in deer-vehicle collisions in Washington under year-round standard time. She also worked on a study across 23 states that showed collisions with deer jump by 16% in the week following the autumn clock change. 

National groups are similarly divided. Save Standard Time has supported Washington legislation favoring permanent standard time, while Lock the Clock has pushed Congress to give states more flexibility rather than taking a position on which permanent time is best.

Temporary costs for long-term gains

Thurlow’s campaign acknowledges the tradeoffs: permanent standard time would put Washington out of sync with Oregon and California for much of the year, shorten summer evenings and potentially increase deer collisions.

But those costs would be temporary, he argues. The twice-yearly clock changes, by contrast, would continue indefinitely unless someone breaks the stalemate.

Thurlow also expects opposition over winter darkness, particularly concerns about children walking to school before sunrise. His response is that many Washington students already do so under the current system, and that changing school start times can address the problem. Seattle and other districts have already adjusted schedules for other reasons.

“There’s sort of a set of gut reactions and instant responses that people have, which may not be grounded in truth,” he said. 

Thurlow is betting that enough Washingtonians are tired of changing their clocks that the campaign can turn a decades-old annoyance into a political issue — and give the state a way out before Congress decides on the issue. His campaign is in early stages, with a handful of signups through his website.

Per month, GitHub now sees 2.9 billion commits, 130 million merged pull requests, and 24 million new repos. Back in April, GitHub already had a hard time handling ‘only’ 1.4 billion commits.

To a large degree, that’s thanks to how popular coding agents have become and how quickly software development is changing. But it’s also no secret that GitHub, despite its efforts to move to a more modern architecture, simply hasn’t been able to scale fast enough to meet this demand.

“We have made progress, but these incidents make clear that we must accelerate this work.” — GitHub CTO Vlad Fedorov.

Why GitHub went down on August 17

The new data comes from a postmortem of its August 17 outage, which lasted almost eight hours. That was GitHub’s second major outage in August alone.

As GitHub CTO Vlad Fedorov notes in the postmortem, “We have made progress, but these incidents make clear that we must accelerate this work.”

He stresses that the outage was due to scaling issues, not any code changes. GitHub’s infrastructure ran out of capacity, and those issues cascaded into this outage.

“Our investigation found that the outage began when traffic reached a new peak, and a critical infrastructure component in our Central US data center failed to scale with it,” he explains. “The resulting capacity pressure spread through our systems, causing authentication failures and disrupting multiple GitHub services.”

3M new CPU cores and GitHub still can’t keep up

It’s worth noting that this is not because GitHub isn’t scaling its infrastructure. Fedorov used the post to disclose that 58% of GitHub’s platform load is now served by Azure. That’s up from 12% in May. Half of all Git operations are now served by Azure, too.

The team added 3 million CPU cores this year, as well as 120 petabytes of high-speed storage, Fedorov writes.

As for GitHub’s own data center, that’s maxed out now. “We installed as much hardware as available power allowed in our existing data centers while accelerating our migration to Azure,” Fedorov says.

He also acknowledges that GitHub is facing other challenges as well.

“As the pace and complexity of change increased, our existing operational practices did not keep up. We have redirected teams and resources toward availability and invested in stronger testing, safer rollouts, better observability, and more effective alerting. We have made progress, but this work is not complete,” he writes. “In addition, we are also isolating critical systems and removing shared dependencies between them. This work is designed to reduce the likelihood of an outage and limit its impact when one occurs.”

For now, to avoid the issues that triggered the recent outages, GitHub is making a few concrete changes: it’s applying consistent retry limits and budgets, and tweaking timeouts across service-to-service interactions “to prevent retry storms and cascading load,” as Fedorov writes.

A creaking GitHub is an opportunity for others

GitHub is central to the developer ecosystem — and especially the open source ecosystem. Its recent issues, however, have created an opening for others to launch competing products.

That includes Entire, the startup founded by GitHub’s former CEO Thomas Dohmke, which is betting on a distributed system to better handle agent-driven development workloads. With Origin, Cursor, too, is getting into this game.

The post GitHub added 3 million CPU cores. It still couldn’t keep up with your commits. appeared first on The New Stack.

The Best Feature in Software Is What You Get to Forget

In software engineering, we usually measure framework upgrades by what they add: new syntax, new macros, new features, new abstractions.

But as any developer who has maintained large Flutter applications over several years knows, the most profound upgrade in developer experience isn't what new concepts you are forced to memorize—it’s the mental gymnastics, framework-specific edge cases, and defensive rituals you finally get to forget and unlearn.

Before we dive into technical specifics, let's establish something essential: Rémi Rousselet is a pioneer and a brilliant engineer. When Rémi created provider in Flutter's early days and later built Riverpod in 2020, he solved real, glaring flaws in Flutter's core InheritedWidget mechanics (such as conditional dependency leaks and lack of compile safety). The entire Flutter ecosystem owes Rémi immense gratitude for pushing the boundaries of Dart architecture.

For years, I was a vocal, passionate—at times almost zealous—advocate for Riverpod. In discussions, community forums, and client architectures, I routinely recommended Riverpod above classic BLoC, Provider, and almost every other state management alternative. I championed its compile-time safety and global declarative graph vision because it genuinely solved tough problems we faced in earlier Flutter eras.

However, over the course of Riverpod's evolution across v1, v2 (the code-gen era), and v3, solving every edge case within a global declarative provider graph led to a staggering accumulation of cognitive surface area. Building real-world Flutter apps with Riverpod today requires developers to maintain a complex internal rules engine just to avoid subtle runtime footguns.

And yet, recognizing how much mental gymnastics this has gradually demanded, I find myself genuinely thrilled and relieved to be pivoting. When you switch to BlocSignal (which combines the proven discipline of BLoC/Cubit with the synchronous speed and fine-grained reactivity of Signals), you realize just how much mental baggage you were carrying—and I am excited to share that journey with all of you.

A Quick Note on Lints and IDE Assists

It is worth acknowledging that the Riverpod ecosystem has invested heavily in custom analyzer lints (riverpod_lint), IDE plugins, and automated quick-fixes (such as "Wrap with ConsumerWidget" or "Convert to Notifier").

While these tooling aids are genuinely helpful, they only address surface-level syntax—they cannot eliminate the underlying cognitive load. An IDE shortcut that automatically rewrites your widget class hierarchy does not prevent a controller from disposing mid-flight during an await gap, nor can a linter rule save a navigation stack from wiping when a router provider re-evaluates.

Tooling assists can bandage syntactic friction, but true architectural simplicity removes the friction at the root.

Here is the running list of everything you get to forget—and why your architecture gets significantly cleaner the moment you do.

1. 🗑️ Forget build_runner and Code-Gen Rituals

The Riverpod Gymnastics:

In modern Riverpod (v2/v3), code generation is the officially recommended path. That means:

• Annotating classes with @riverpod.
• Extending obscure generated private base classes (extends _$AuthNotifier).
• Running dart run build_runner watch --delete-conflicting-outputs in a separate terminal tab, spinning laptop fans while consuming gigabytes of RAM.
• Waiting several seconds every time you rename a parameter or add a method just for IDE autocomplete to work again.
• Dealing with noisy .g.dart generated files cluttering Git diffs and code reviews.

(Yes, Riverpod still technically supports manual NotifierProvider / Notifier syntax without code generation. But code-gen is the officially documented standard and recommended default throughout modern Riverpod tutorials and guides. Writing manual syntax is verbose and forfeits features like typed .family parameter records.)

// 🤯 Riverpod (Code Generation Required)
import 'package:riverpod_annotation/riverpod_annotation.dart';

part 'counter.g.dart';

@riverpod
class Counter extends _$Counter {
  @override
  int build() => 0;

  void increment() => state++;
}

What You Do in BlocSignal:

You write pure Dart. No build_runner. No part files. No code-gen watchers. Instant autocomplete in every IDE, 100% of the time.

// ⚡ BlocSignal (Zero Code-Gen, Pure Dart)
import 'package:bloc_signals/bloc_signals.dart';

class CounterCubit extends CubitSignal<int> {
  CounterCubit() : super(initialState: 0);

  void increment() => emit(stateValue + 1);
}

2. 🗑️ Forget Widget Class Hierarchy Gymnastics & WidgetRef Plumbing

The Riverpod Gymnastics:

In Riverpod, you cannot read or watch state from standard Flutter widgets without either:

1. Converting your StatelessWidget into a ConsumerWidget and changing build(BuildContext context) to build(BuildContext context, WidgetRef ref).
2. Converting your StatefulWidget into a ConsumerStatefulWidget and State<T> into ConsumerState<T>.
3. If using Flutter Hooks, extending HookConsumerWidget (a Frankenstein base class).
4. Passing WidgetRef ref down private helper functions, widget sub-methods, and domain callbacks because ref is not accessible from standard BuildContext.

// 🤯 Riverpod
class UserProfileView extends ConsumerWidget {
  const UserProfileView({super.key});

  @override
  Widget build(BuildContext context, WidgetRef ref) {
    final user = ref.watch(userProvider);
    return Text(user.name);
  }
}

What You Do in BlocSignal:

You use standard Flutter widgets. StatelessWidget, StatefulWidget, or HookWidget. You interact via idiomatic BuildContext extensions or dedicated declarative widgets (BlocSignalBuilder, BlocSignalListener, BlocSignalConsumer):

// ⚡ BlocSignal
class UserProfileView extends StatelessWidget {
  const UserProfileView({super.key});

  @override
  Widget build(BuildContext context) {
    final user = context.watch<UserCubit, UserState>();
    return Text(user.name);
  }
}

Zero custom base classes. Zero WidgetRef drilling. Native Flutter.

3. 🗑️ Forget the Provider "Alphabet Soup" & Deprecation Whiplash

The Riverpod Gymnastics:

Over the last few years, Riverpod developers have had to navigate an exhausting taxonomy of provider variants:

• Provider
• StateProvider (deprecated in v2/v3)
• StateNotifierProvider (deprecated)
• ChangeNotifierProvider
• FutureProvider
• StreamProvider
• NotifierProvider
• AsyncNotifierProvider
• StreamNotifierProvider
• AutoDisposeProvider / AutoDisposeFutureProvider
• .family modifiers with tuple parameter records

Each variant had its own slightly different rules for error handling, disposal, and lifecycle callbacks.

What You Do in BlocSignal:

There are only two intuitive, unified primitives:

1. CubitSignal<State>: For method-based state management (call methods, compute derived state, emit new values).
2. BlocSignal<Event, State>: For formal, event-driven unidirectional data flow with explicit event hierarchies and concurrency transformers (droppable, restartable, sequential).

Both use standard Dart constructors, synchronous emit(), and expose state as a reactive ReadonlySignal<State>.

(While Riverpod's generic AsyncValue is handy for basic fetch-and-display screens, real enterprise applications quickly outgrow generic 3-state wrappers and require rich domain models—such as partial validations, optimistic rollbacks, and multi-step forms. With BlocSignal, you leverage the full expressive power of Dart 3 sealed classes for domain state, while retaining access to AsyncSignal when you want declarative async futures.)

4. 🗑️ Forget the "Ref World vs. Non-Ref World" Boundary

The Riverpod Dilemma:

As I taught developers and engineering teams about Riverpod over the years, I gradually adopted a mental model of the "Ref World" vs. the "Non-Ref World" to help students understand a fundamental reality of Riverpod's design.

In Riverpod, reactive state is strictly confined inside a ProviderContainer—the "Ref World". As long as you are inside a ConsumerWidget or inside another provider, you hold a Ref or WidgetRef, and everything connects. But the moment you step into standard Dart code—such as HTTP client interceptors, WebSocket listeners, background database services, or routing configurations—you are stranded in the "Non-Ref World". To connect the two, you are forced to:

• Drill a Ref ref parameter through every layer and pollute pure Dart domain classes with framework dependencies.
• Or expose a global top-level ProviderContainer variable as an escape hatch.

What You Do in BlocSignal:

bloc_signals is a 100% pure Dart package with zero Flutter dependencies.

• You can instantiate and observe a CubitSignal or BlocSignal anywhere: inside Flutter widgets, CLI tools, Jaspr web applications, or Serverpod backend services.
• Pure Dart services can read cubit.stateValue or subscribe directly to cubit.state.subscribe((state) => ...) with zero container ceremony.

What about cross-container coordination? In classic stream-based BLoC, coordinating two Blocs was notoriously clunky (often forcing developers to nest multiple BlocListener widgets in the UI tree). In BlocSignal, because every state is exposed as a reactive ReadonlySignal<State>, cross-Cubit derived state is trivial in pure Dart business logic:

// ⚡ Pure Dart Cross-Cubit Derivation (Zero UI Listeners Needed)
late final isCheckoutReady = computed(() => 
  authCubit.state().isAuthenticated && cartCubit.state().items.isNotEmpty
);

Zero widget tree nesting. Zero stream subscriptions. 100% testable in pure Dart.

5. 🗑️ Forget the routerProvider Navigation Stack Nuke

The Riverpod Footgun:

Perhaps the most notorious casualty of the "Non-Ref World" boundary is routing. Because routers like GoRouter are standard Dart objects that live squarely in the Non-Ref World, developers frequently attempt to pull their router into the Ref World by wrapping it in a Riverpod Provider so it can access ref and observe live authentication state:

// 💣 The Innocent-Looking Riverpod Disaster
final routerProvider = Provider<GoRouter>((ref) {
  final auth = ref.watch(authProvider); // 💣 DISASTER
  return GoRouter(
    redirect: (context, state) => auth.isLoggedIn ? null : '/login',
    routes: [...],
  );
});

The Runtime Bug: Whenever authProvider emits (or background token refresh occurs), ref.watch destroys and recreates the entire GoRouter instance.

• The user's entire navigation history stack is wiped clean.
• Deeply nested tabs and modal sheets vanish instantly.
• Scroll offsets reset to the top.

To fix this in Riverpod, you cannot just write intuitive code; you must possess a deep, esoteric understanding of both how GoRouter manages its internal delegate and how Riverpod rebuilds provider dependencies. The prescribed workaround is constructing a custom ChangeNotifier bridge with ref.listen to feed refreshListenable.

Worse still, when this bug strikes in production, there are no error logs or stack traces—just an unexplained navigation reset. Developers are often left struggling with a complete lack of information and traceability, unclear even where to place debugger probes or log statements to catch why the router is vanishing.

What You Do in BlocSignal:

Your GoRouter instance is created once and remains permanent. You connect it directly using toListenable():

// ⚡ BlocSignal: Stable Router, Live Redirects
final router = GoRouter(
  refreshListenable: authCubit.toListenable(),
  redirect: (context, state) => authCubit.stateValue.isLoggedIn ? null : '/login',
  routes: [...],
);

Zero router destruction. Unbroken navigation stacks. 100% deterministic.

6. 🗑️ Forget the "Self-Disposing Async Mutation" Crash

The Riverpod Footgun:

In Riverpod 3.0, auto-disposal is enabled by default. While the intended goal of automatic disposal is commendable (preventing memory leaks in long-lived trees), using implicit UI reference counting to govern asynchronous business logic creates severe race conditions:

// 💣 Riverpod 3.0 Trap
@riverpod
class NoteController extends _$NoteController {
  @override
  Future<List<Note>> build() => repository.fetchNotes();

  Future<void> deleteNote(String id) async {
    state = const AsyncLoading();
    await repository.deleteNote(id);

    // 💥 CRASH: "Cannot use Ref after it has been disposed"
    // If the user navigates away or no widget is watching this controller during the `await`,
    // Riverpod garbage-collects this instance mid-flight!
    ref.invalidateSelf(); 
  }
}

To work around this in Riverpod, developers are forced into defensive gymnastics:

• Defensive Guards: Sprinkling if (ref.mounted) checks after every single asynchronous await.
• Action Controller Sprawl: Creating an entirely separate NoteDeleteActionController class just to execute a single async method call without auto-disposing the main list provider.
• Keep-Alive Token Juggling: Manually acquiring and releasing KeepAliveLink tokens:

  final link = ref.keepAlive(); // 🤯 Manual retain-count management in Dart!
  try {
    await repository.deleteNote(id);
  } finally {
    link.close(); // Remember to release the token, or leak memory forever!
  }

Think about how absurd that is: you find yourself having to write meta-state management just to manage the lifecycle of your state management system. High-level declarative Dart is suddenly reduced to manual reference-count lock juggling.

What You Do in BlocSignal:

In BlocSignal, state containers are standard Dart objects with explicit, predictable ownership. If an async method is running, it executes to completion. If a Bloc is closed, emit() is safely dropped with zero unhandled runtime crashes:

// ⚡ BlocSignal
class NoteCubit extends CubitSignal<NoteState> {
  NoteCubit({required this.repository}) : super(initialState: const NoteState.initial());

  final NoteRepository repository;

  Future<void> deleteNote(String id) async {
    emit(stateValue.copyWith(isLoading: true));
    await repository.deleteNote(id);
    final notes = await repository.fetchNotes();
    emit(stateValue.copyWith(isLoading: false, notes: notes));
  }
}

7. 🗑️ Forget .family Parameter Isolation & Cache Silos

The Riverpod Dilemma:

When you use Riverpod's .family modifier to parameterize queries:

final userPostsProvider = FutureProvider.family<List<Post>, String>((ref, userId) => ...);
final postDetailProvider = FutureProvider.family<Post, String>((ref, postId) => ...);

Each parameter generates an isolated provider instance. If the user likes a post in postDetailProvider('post-123'), userPostsProvider('user-456') still contains the old, unliked copy of that post in memory. You now have to build complex cache invalidation bridges across multiple isolated providers.

What You Do in BlocSignal:

You use normal Dart parameters in constructors (PostCubit(userId: id)) and share live reactive signal stores (like mapSignal or computed()) across containers. When a post is updated in the central signal store, every widget and cubit observing it updates synchronously in the exact same frame.

8. 🗑️ Forget the ref.watch in Callbacks Infinite Loop Trap

The Riverpod Gotcha:

One of the most common mistakes for Flutter developers learning Riverpod is calling ref.watch inside an onPressed or gesture callback instead of ref.read:

// 💣 Riverpod Bug
ElevatedButton(
  onPressed: () {
    // 💥 Calling watch inside an event handler registers an invalid dependency
    // or creates unexpected rebuild cascades!
    ref.watch(authProvider.notifier).login();
  },
  child: const Text('Login'),
)

What You Do in BlocSignal:

The distinction in BlocSignal is natural and enforced by Flutter's existing BuildContext idioms:

• In callbacks/handlers: context.read<AuthCubit>().login() (O(1) lookup, zero subscription).
• In UI builders: context.watch<AuthCubit, AuthState>() or BlocSignalBuilder<AuthCubit, AuthState> (explicit reactive rebuild boundary).

9. 🗑️ Forget In-Place Mutation Silent Drop Traps

The Riverpod Footgun:

In Riverpod 3, notifying listeners relies strictly on reference equality (identical(oldState, newState)). If you mutate a list in-place:

// 💣 Riverpod 3 Silent Failure
state.add(newItem);
state = state; // ❌ Does NOT trigger UI rebuilds because identical(state, state) is true!

What You Do in BlocSignal:

BlocSignal provides explicit, customizable equality checks via SignalOptions(equals: ...) or standard value equality (using Dart 3 records, Freezed, or fast_immutable_collections). When you call emit(newState), the transition is explicit, logged through BlocSignalObserver, and propagated synchronously.

10. 🗑️ Forget Subtree ProviderScope(overrides: [...]) Scoping & Modal Traps

The Riverpod Gymnastics:

In Riverpod, when you need to scope data down a specific widget subtree—such as passing item data down a list view or customizing a controller for a nested section—Riverpod prescribes nesting a ProviderScope with overrides::

// 🤯 Riverpod: Scoping data in a list
ListView.builder(
  itemCount: todos.length,
  itemBuilder: (context, index) {
    return ProviderScope(
      overrides: [
        currentTodoProvider.overrideWithValue(todos[index]),
      ],
      child: const TodoItemTile(),
    );
  },
);

This pattern introduces several subtle, high-friction pitfalls:

1. Container Overhead in Lists: Wrapping 100 list tiles in ProviderScope instantiates 100 nested Element widgets and separate internal provider container nodes.
2. The "Split-Brain" Dependency Trap: If Provider B depends on Provider A, and you override A in a nested ProviderScope without also explicitly overriding B, Provider B still resolves against the root un-overridden A, causing baffling data desynchronization bugs.
3. The Modal & Dialog Disconnection Bug: When you call showDialog() or showModalBottomSheet(), Flutter pushes the new route to the root Navigator overlay. Because the dialog is mounted outside the local subtree's ProviderScope, all local overrides are instantly lost—causing the modal to either crash with missing providers or silently read outdated root state.

What You Do in BlocSignal:

You use standard Dart and Flutter idioms:

• In lists: Pass data directly via constructor parameters (TodoItemTile(todo: todos[index])).
• In subtrees: Use standard Flutter scoping with BlocSignalProvider.value(value: todoCubit, child: ...) or provide scoped instances cleanly.
• In dialogs: Pass the Cubit directly to BlocSignalProvider.value in the dialog builder, or let it resolve naturally up the Flutter element tree.

11. 🗑️ Forget Complex ProviderContainer Mocking & Test Rigmarole

The Riverpod Testing Ceremony:

In Riverpod, unit tests and widget tests require assembling a ProviderContainer or wrapping test widgets in ProviderScope(overrides: [...]):

// 🤯 Riverpod Test Ceremony
final container = ProviderContainer(
  overrides: [
    authRepositoryProvider.overrideWithValue(mockAuthRepo),
    apiClientProvider.overrideWithValue(mockApiClient),
    // ⚠️ Miss just one transitive provider in this list, and your test
    // will accidentally make real network calls or throw late-init errors!
  ],
);
addTearDown(container.dispose);

What You Do in BlocSignal:

State containers are plain Dart classes with direct constructor injection. You instantiate your Cubit or Bloc with your mock repository directly:

// ⚡ BlocSignal: Declarative, Instant Unit Testing
blocSignalTest<CounterCubit, int>(
  'emits [1] when increment is called',
  build: () => CounterCubit(repository: mockRepository),
  act: (cubit) => cubit.increment(),
  expect: () => [1],
);

Because BlocSignal state transitions are synchronous, assertions execute immediately without flaky tester.pumpAndSettle() timeouts or async race conditions.

12. 🤖 Forget the AI & LLM Hallucination Nightmare

The Riverpod AI Friction:

If you pair-program with AI coding assistants—whether Claude, Cursor, GitHub Copilot, ChatGPT, or Gemini—you have likely experienced how difficult Riverpod is for modern LLMs:

1. The Version Multi-Verse: LLM training data contains years of conflicting Riverpod eras (v0.14 ChangeNotifierProvider, v1.0 StateNotifierProvider, v2.0 @riverpod code-gen, and v3.0 Notifier). AI models constantly mix up these eras, hallucinating deprecated APIs, invalid provider types, or incompatible syntax.
2. Code-Gen Blindness: LLMs cannot see generated code before build_runner executes. When an AI generates a @riverpod class, it frequently botches the synthesized _$ClassName inheritance, misnames the generated provider, or forgets the part 'file.g.dart'; declaration.
3. Ref Scope Confusion: AI models frequently lose track of the "Ref World" boundary—attempting to access ref inside widget constructors, passing WidgetRef into deep business logic layers, or failing to convert widgets to ConsumerStatefulWidget.
4. Implicit Auto-Disposal Bugs: LLMs routinely write async mutation methods inside auto-disposing notifiers without accounting for ref.mounted guards or keep-alive tokens, generating code that looks plausible but crashes in production.

What You Do in BlocSignal:

LLMs excel at pure, standard Dart with explicit contracts:

• Standard Dart & Predictable Conventions: Pure classes, direct constructor injection, and idiomatic Flutter BuildContext lookups. There is no code-gen magic for the LLM to guess.
• Zero build_runner Feedback Loops: AI agents can write features, scaffold tests, and immediately verify analyzer diagnostics without waiting for external code generation steps.
• Vast Training Ground: BLoC and Cubit are among the most consistently documented and deeply represented architectural patterns in AI training datasets. LLMs generate accurate, idiomatic BlocSignal code on the first try.
• Deterministic AI-Generated Tests: AI tools generate rock-solid, synchronous blocSignalTest suites without getting tripped up by ProviderContainer setup boilerplate or async frame timing issues.
• First-Class AI Skills From Day One: Rather than leaving LLMs to guess architectural boundaries, BlocSignal ships from day one with installable agent skills covering migrations, interop adapters, and production best practices.

Summary: The Cognitive Weight You Leave Behind

🌉 Currently Mired in Riverpod? You Don’t Need a Big-Bang Rewrite

If you maintain a large production codebase built on Riverpod, you might be thinking: "This sounds wonderful, but our entire team is already knee-deep in Riverpod. We cannot afford to halt feature delivery for a massive rewrite."

You don't have to.

Through bloc_signals_riverpod, you get a seamless, bidirectional interop bridge that allows you to adopt BlocSignal incrementally, one feature or screen at a time.

Direction 1: Expose a BlocSignal to Existing Riverpod Widgets

If you build a new feature using a clean, pure Dart CubitSignal, you can expose it directly to existing Riverpod widgets as a standard NotifierProvider using .toProvider():

// 1. Build your new feature with a pure Dart Cubit
final cartCubit = CartCubit();

// 2. Adapt it into a Riverpod provider with a single call
final cartProvider = cartCubit.toProvider();

// 3. Existing Riverpod ConsumerWidgets watch it seamlessly:
class CartBadge extends ConsumerWidget {
  const CartBadge({super.key});

  @override
  Widget build(BuildContext context, WidgetRef ref) {
    final cartState = ref.watch(cartProvider);
    return Badge(label: Text('${cartState.itemCount}'));
  }
}

Direction 2: Consume Legacy Riverpod Providers in BlocSignal

Conversely, if your new BlocSignal architecture needs to read data from legacy Riverpod providers that you aren't ready to rewrite yet, you can adapt any ProviderListenable with .toBlocSignal(ref):

// Adapt any legacy Riverpod provider into a reactive BlocSignal
final userBloc = legacyUserProvider.toBlocSignal(ref);

// Read stateValue synchronously or subscribe to state changes
print(userBloc.stateValue.userName);

You can migrate your application piece by piece—shedding the cognitive load on new features immediately while existing code continues running uninterrupted.

Getting Started

If you want the architectural discipline of BLoC combined with the modern, zero-latency reactive power of Signals—without the code-gen or cognitive overhead—give BlocSignal a spin.

dependencies:
  bloc_signals: ^1.0.0
  bloc_signals_flutter: ^1.0.0

  # Optional for incremental migration:
  bloc_signals_riverpod: ^1.0.0

Learn more at blocsignal.dev or explore the source on GitHub.

I’m adding things to my “you should try this technology” list much faster than I’m getting through it. At some point I’m going to declare bankruptcy and start over. Tomorrow’s looking like a clean “no meeting day” so I stand a chance to get through two of my top ones. Stay tuned.

[blog] Expanding Google Antigravity for enterprise customers. Now Gemini Enterprise users get the Antigravity harness across their favorite IDEs, pooled usage among teams, and backend enterprise controls. More here.

[blog] Practical Loop Engineering. Educational post on the type of agent loops, and how Addy applies them in his own work.

[blog] Add telemetry and observability to your AI agents. Does it really make a big difference to give your agent a memory? Jason built a reference system to test it out and see how behaviors diverge over time.

[article] Your coding agent got the onboarding your developers never did. I chuckled at the headline, because it hit home for me. Are we giving better budget, sponsorship, and patience to agents than we did to humans? Probably.

[blog] How Google Cloud MCPs Give Claude Code Inside Access. Investments in skills and MCPs shouldn’t be tool specific. The whole point is to make sure anyone can use them. Here’s one example.

[article] Only daily AI users feel positively about job security. I guess that doesn’t feel surprising. Those embracing and using the latest thing are likely more future-proofed.

[blog] 20× the CI traffic without getting slower: How we rebuilt Git serving at Datadog. You probably don’t have a git setup as complicated as this. But there are good lessons on unnecessary cloning, recognizing that CPU is the bottleneck, and being smart on your fetching strategy.

[article] Is Your Organizational Culture Too Nice? You know what this looks like. Bland feedback. Everyone gets great performance reviews. Everyone gets a voice. Stop that. Care deeply about others, while aiming for candid, results-focused kindness instead.

[blog] How AlloyDB ScaNN scales vector search to 10 billion vectors. Tremendous performance for a relational database. Here’s how we did it.

[article] When Your Buyer Is an AI Agent. Time to challenge your existing assumptions on pricing and managing buyer relationships.

Want to get this update sent to you every day? Subscribe to my RSS feed or subscribe via email below: