I’ve been using and writing about Microsoft Copilot since it was publicly released in 2023. I’ve reviewed it, written articles about using it more effectively, explained how to curb hallucinations in it and other similar tools, and detailed how to use it in concert with Microsoft 365. It’s also been my go-to generative AI (genAI) tool for personal projects and advice.
But the time has come for me to leave it behind for my personal use. It’s become abundantly clear that for those tasks, Google Gemini is better. Here’s why.
Like many people who know something about technology, I’m the IT staff for friends and family. I’ve often used Copilot to help solve issues I can’t fix myself. Sometimes Copilot helps. And other times…, well, the last time I turned to it for troubleshooting advice is when I realized it was time to abandon Copilot.
My wife had bought a new iPhone, and I noticed she was receiving texts sent to her email address but hadn’t received any sent to her phone number. I asked Copilot for help.
I won’t go into the details of the wild goose chase Copilot sent me on — I’ll just offer a few lowlights. It first told me, with absolute authority, that there are “only two real explanations” for the problem and asked me to look at several settings to confirm which explanation would fix the issue.
It turned out that neither of the “two real explanations” were the cause. Undeterred, Copilot assured me, again with complete confidence, that it was going to send me “straight to the switch” that would immediately solve the problem.
I tried it. The switch didn’t work. Neither did the “final fix” it promised me. Nor did any of the other many “solutions” if offered after that so-called final fix. For more than an hour, it flailed with utter confidence and utter futility trying to diagnose and fix the problem.
And then came the final indignity: After doing some digging, I realized Copilot was trying to solve the problem based on an old version of iOS, not the current one on my wife’s phone. When I confronted Copilot about that, it briefly apologized and promised it knew the solution: I had to call the cellphone carrier.
That was it for me. I’d had enough. I turned to Gemini for help.
Thirty seconds later, Gemini diagnosed the problem and recommended a simple fix, which didn’t require a call to my phone carrier. It worked like a charm. Gemini had solved a tech problem in 30 seconds that Copilot couldn’t resolve after an hour.
I often used Copilot for personal research projects. A recent one involved Parisian neighborhoods in the 1870s. I was looking for information about the area around the Saint-Lazare train station. When I asked Copilot, it told me the area was dangerous and poverty-ridden back then, with poor housing whose exteriors were heavily stained by coal smoke from arriving and departing trains.
That didn’t sit right with me. I recalled a well-known painting Paris Street; Rainy Day by the Impressionist painter Gustave Caillebotte, which depicted the neighborhood in the 1870s as wealthy and fashionable, filled with elegant Hausmann-style apartment buildings. I asked both Gemini and Claude about the neighborhood in the 1870s. They both told me it was expensive, fashionable and sought after by the well-off. I confirmed that with my own follow-up research.
Once again, Copilot had whiffed.
I swim for exercise three or four times a week at my health club’s indoor pool. The club closed the pool for several months, so I decided to swim at the pool of an elementary school a short walk from my house. I hadn’t exercised there before and wanted to find the times on Monday through Friday when the pool would be least crowded. I asked Copilot for help.
As always, Copilot spoke with a solid air of authority. And once again, it was wrong. It told me that the least crowded time for public swimming on weekdays was between 11:30 a.m. and 12:30 p.m. or between 12:00 p.m. and 1:00 p.m.
On one count it was right: the pool would certainly not be crowded with public swimmers at those times. Because the pool doesn’t open to the public until 3 p.m.
I turned to Gemini, which told me that 3 p.m., when the pool opened, would be the least-crowded time. Claude was no help. It demurred and said it didn’t know the answer – a rare, refreshing admittance of ignorance from a chatbot.
Gemini was on target again — 3 p.m. did indeed turn out to be the least-crowded time to swim. I often get a lane to myself, and at worst have to split a lane with one other swimmer. I asked several lifeguards if 3 p.m. was the least-crowded time on weekdays; they all confirmed it was.
For all those reasons, when it comes to personal research and advice, I’ve abandoned Copilot. I typically use Gemini now, although on occasion, I ask for a second opinion from Claude.
For my Computerworld work, I’ll keep using Copilot, and continue to write reviews of it, offer advice on how to use it and keep you informed about the latest news about it.
But other than that, for my personal use, Copilot is dead to me.
For the past few days, I’ve been immersed in Google’s latest vision of the future — an AI-infused dashboard that taps into info from all of your Google app activity and then uses that data to cook up a series of daily “stories” designed to “connect you with what matters.”
And — believe me, I don’t say this lightly — the experience of interacting with this system has me longing more than ever for the past.
The app is called Dreambeans. Google launched it as an experiment last Wednesday, and I was offered the opportunity to skip the standard waitlist and get immediate access to explore it.
I won’t beat around the bush: Using the app really has been an eye-opening, enlightening experience for me. Just not in the way that Google had presumably wanted.
[Get level-headed knowledge in your inbox with my free Android Intelligence newsletter. Something new and useful every Friday — from my keyboard to your email.]
In many ways, Dreambeans feels like the ultimate example of everything Google’s been gunning for — and AI in general has been building up to — over the past several years.
With your permission, the app accesses your ongoing activity data from Google Workspace (including such services as Gmail, Google Calendar, and Google Drive) along with Google Search, Google Photos, and YouTube to create an evolving profile of your life and interests. That means everything from who you email to what’s on your agenda, what you’re writing or saving files about, and what sorts of subjects you’re searching for, videos you’re watching, and activities you and your friends, family, and other associates are appearing in throughout photos (and even how you all look in those photos) gets constantly analyzed and processed and used as fodder for a personalized feed that updates a few times a day.
On the surface, it sounds a little like Google Now — the excellent and all-too-short-lived proactive intelligence feature Google added into Android for a while back around 2012.
In practice, though, lemme tell ya: It feels dramatically different. Whereas Google Now felt almost magical in its ability to anticipate what you needed before you ever asked for it — with proactive cards on things like flight statuses based on itineraries in your inbox or flight-related searches you’d performed, traffic alerts based on your typical daily routes or appointments in your agenda, and links to maps for businesses you’d been researching — Dreambeans takes those same basic concepts to a whole other level that ends up feeling creepy and invasive, both in the info it’s offering and in the way it’s presenting it.
And, more broadly, it feels indicative of the way AI is heading in general — not just with this one app or with Google but across the industry and in a style that I think most people are increasingly finding off-putting and will only find ever more intrusive in time.
Now, let’s be clear: I’m no technophobe. Far from it: I love clever tech creations and thoughtful new touches that make our lives easier. Heck, I’ve spent much of my life searching for and writing about such feats. And that’s precisely why my reaction to Dreambeans strikes me as so significant: If I’m this put off by this concept, how will average tech users — most of whom are far less tuned into tech trends and intrigued by interesting new options then I am — react?
I’ll tell you more about what I’ve heard so far in a second. First, let me show you exactly what I’ve been seeing, so you can assess this thing for yourself and see how it comes across to your spidey senses.
Here’s a handful of the Dreambeans “story” suggestions that appeared in the app upon its first day working for me, with a few names and personal details blurred for privacy purposes:
JR Raphael, Foundry
I’m honestly not even sure where all of these suggestions came from, but what jumped at me right away were the (occasionally flattering) caricatures of me and my wife and the general sense of invasion from all the slightly too personal stuff and too familiar integration of family members’ names and interests integrated into the material.
For the record: I had been looking into speaker stuff at some point in the not-too-distant past; I’ve never once typed, uttered, or even considered the phrase “hand-loomed textiles” until just now; we had been looking at the arts festival it mentioned; I’ve never specifically searched for or expressed any interest in Scary Movie 6; and I am not into the band Genesis — though, to be fair, I can’t dance.
I showed all this same material to my wife as well as to several other friends and family members I’d categorize more as typical tech users — not tech professionals or card-carrying geeks but just regular people who own and use a variety of devices, as we all do, and rely on ’em for both personal and professional purposes with varying levels of dread, excitement, and/or indifference. Without exception and without any prompting or personal opinions presented to sway them, every single one of ’em responded the same basic way: “Oh. That’s creepy.” And: “I do not like that.” Without fail.
It doesn’t get much better from here, either. Most of the app’s subsequent suggestions have continued to veer just a touch too far onto the “ick” side of the spectrum, as well as occasionally being off-base in some pretty perplexing ways. For instance:
JR Raphael, Foundry
For the record on this set: I do love the show Seinfeld — SERENITY NOW! more than ever — though it’s been some time since I’ve actively watched it; I somewhat famously am allergic to Apple products and avoid ’em whenever possible (notice the name of this column, anyone?); I don’t live in the same city as my brother but do find it creepy to have him pictured in ghoulish caricature form and brought randomly into a discussion about Plex (something he wouldn’t even remotely be interested in hearing from me about); and my various editorial newsletters are all powered by a service called Kit — not Beehiiv — which is mentioned in plenty of places both on my websites and throughout my emails.
Also, while my hairline may not be what it once was, I’m (ahem) not that bald yet — thankyouverymuch, Dreambeans.
Another example that I won’t show here was an item that pictured me in overalls working on installing some “coated stainless steel wire for [my] gallery canvases” — a reference to a community art gallery (with all sorts of details wrong and in some cases flat-out fabricated) connected to my mother’s recent passing. It casually mentioned her by name, too, alongside that eerie illustration of me performing a skill I definitely don’t have in my nonexistent home workshop. I don’t think I have to elaborate on how unsettling, unappreciated, and — again — invasive it felt to have that pop up in this feed.
More than anything, what I’ve been feeling while seeing all of this is a combination of (a) egad, it knows too much — especially when it casually name-drops and caricature-pics my wife, kids, and other family members — and (b) at the same time, the info it’s giving me isn’t especially helpful or insightful. It’s mostly just flat, generic, and — well, more or less exactly what you’d expect from something AI-generated.
JR Raphael, Foundry
More than anything, in other words, it’s a combination of creepy and not particularly useful.
JR Raphael, Foundry
And it’s the “creepy” part that really sticks with me the most.
Maybe if the info I’m being served up here were exceptionally useful, this could be a tradeoff I’d be at least a little more likely to accept. Maybe. But in this scenario, it just feels odd and a little too invasive — which I’ve come to realize is a common theme surrounding much of what seems to be the next level of our forced-upon-us AI future.
Take Google’s Gemini Spark, for instance — the “agentic” AI assistant announced at Google I/O that’s meant to be a “proactive” helper tackling tasks on your behalf. David Pierce from The Verge got an early look at the tool in action and called it “the most impressive and terrifying AI experience” he’s had to date, also bringing that “creepy” word into the equation:
I can’t shake the deeply creepy feeling I get from the whole thing. What Spark did feels sort of magical, and very invasive. It’s weird that Spark is so casually telling me the names and ages of my children, reminding me that it knows where I live, and finding information I know for a fact I’ve never volunteered to Google. Intellectually, I know that Google knows an incredible amount about me — add up my emails, my calendar, my photos, and my search history, and you’ve pretty much got me pegged. But seeing Spark treat all that data not as something to be protected, but as something to be mined, just feels bad.
And that, I think, mirrors the exact reaction I’ve been experiencing with Dreambeans. We’ve all always known that Google knows a lot about us, but we’ve also — at least intellectually — understood how all of that data is and isn’t being used. And it’s never been rubbed in our faces just how much the company can figure out about us by putting all the various pieces together and creating an awkward sense of robotic intimacy.
I remember years ago, being in a Google press briefing where someone from the company talked about how much more their systems and services could accomplish but how they deliberately held back on going that far and overdoing the personalization — ’cause even though they had all that info and could make all those connections, they knew (at the time) that people wouldn’t respond well to seeing all their personal activity put together in such shocking ways. They knew (at the time) that most of us weren’t looking for an artificial BFF who knew too much about us. They knew (at the time) that giving us that sensation would cross the line into being creepy.
Well, this just in: That line’s officially been decimated. We’re in AI’s creepy era. And seemingly no one is worrying anymore if it’s actually something any of us want or will appreciate.
It kinda feels now like tech companies are actively rubbing in our faces how much they know about us — and even if there’s nothing truly nefarious going on with what they’re doing, it sure doesn’t feel good. It feels creepy. And at a time when trust in tech titans is shockingly low and most folks outside of the Silicon Valley bubble are feeling more and more frustrated with AI and all of the effects it’s foisting upon us, that isn’t a great look to be giving off.
Put those sensations alongside the sigh-inducing explosion of AI “content creators,” the proliferation of lifeless AI-generated “writing” (been on LinkedIn much lately?), and the troublingly blurry line between photorealistic AI-generated images and actual real-world photographs — not to mention the maddening experience of interacting with an AI bot support agent or encountering the ever-expanding array of AI-powered scams and security threats and AI-generated job cuts, just to name a few other problematic consequences this movement is imposing — and it’s hard not to question if all this purported progress is ultimately more helpful or harmful for us, as living, breathing humans in the real world.
A few months ago, at the three-year mark of Gemini’s launch, I posed the question: Did anyone actually ask for this? And, more pressingly: Is this the future we wanted? As we’re moving now into yet another era of AI innovation and seeing how it’s affecting our lives, it gets tougher every day to imagine many folks outside of the tech industry who’d answer with an emphatic yes.
And, unfortunately, you don’t need any fancy-schmancy AI chatbots to tell you that things are only gonna get more extreme — and, yes, more creepy — from here.
Find the tips and tools that’ll *actually* help you with my free Android Intelligence newsletter. No hype, no nonsense — just useful new stuff in your inbox every Friday, from one (alleged) human to another.
I’ve been around long enough to remember when deploying an application meant copying a *.exe file from the developer’s machine right into production. I am not making this up. It was that simple, and that fraught with peril. Applications weren’t complex — they were often not anything more than that simple *.exe file — and the process around deployment didn’t need to be anything complex, but it probably should have been.
Proper deployment of an application is something we’ve learned to do over the years. The process of properly building, testing, and deploying an application has grown more complex for two reasons. First, the process must ensure that every deployment succeeds. Deploying complex applications can be convoluted and challenging, and a strict deployment process ensures everything happens properly and runs correctly. Second, the process must thoroughly test the application to make sure that all the moving parts work together to create a properly functioning application.
Today’s continuous deployment processes were hard-won from many lessons learned. Eventually, these practices became formalized, even to the point where the Sarbanes-Oxley Act was understood to require that IT departments formally document their deployment processes.
This kind of governance is what separates professional software development organizations from those that, well, don’t know what they are doing.
Agentic development is headed in this same direction, but it’s all happening a bit more quickly. It was just a few months ago that people began to use AI to write code seriously. At first, most of us were doing it furtively, having Claude Code find and fix bugs, and then quietly checking in the solutions. Maybe we were a bit hesitant to mention that we had done this, but then we felt guilty about doing it and taking credit, and eventually we mentioned it. But it soon became apparent — like “within a week” soon — that Claude Code was up to the task, and we became pretty open about it.
Very quickly, it not only became accepted but actually encouraged, and we were off to the races. In a month, everyone was tokenmaxxing.
It almost seems a bit out of control. Sure, there is a lot of code being generated and non-trivial amounts of money being spent, but it isn’t quite clear if the results are worth the effort. I’m not at all sure if anyone can say that the money spent is returning the value needed.
At some point, as an industry, we are going to have to get control of all of this. I fear that there will be a rush to impose governance over the whole thing. This, like deploying an .exe directly, is also fraught with peril. Right now, there appears to be little control over what tools are being used where, how much is being spent for what purpose, and what that spending is actually getting us.
The governance over our deployment processes was successful and useful because it arose organically. The accepted, codified procedures arose from the lessons that practitioners learned by actually building and deploying applications. We all should work to ensure that a similar process happens with agentic coding.
Because agentic coding is happening so quickly and so furiously, the danger is that a governance process will be imposed over the top just as quickly and furiously. I want to encourage us all to take a deep breath, slow down a bit, and take a close look at what we are doing, and more importantly, how we are doing it.
Agentic coding will be governed in some manner. It’s critical that we practitioners take the lead in providing that governance, or we’ll have governance forced upon us. We are the ones that know what matters and how the tools should be used. We are the ones with skin in the game and the ones keeping pace with the technology.
Top-down governance of a technology moving this fast will never be able to keep up. Or as Uri Haramati, co-founder and CEO of Torii says, “The person closest to the tool usually understands why it’s being used, and governance works better when it includes those people instead of trying to control them.”
Copying that *.exe file into production is comically reckless. We don’t do that anymore because we know better. It took time, but we learned the right way to deploy software. Right now, we are in the “copying the *.exe” phase of agentic coding, and we need to figure out the right way to do it before someone comes along and does it for us.
AI-generated code is riddled with security flaws, yet enterprises are shipping more of it than ever before. Why? Perhaps they’re over-confident, lack true visibility into security risks, or are simply choosing to ignore the problem and hope it goes away.
It’s a dangerous game to play at the dawn of the agentic AI era, as underscored in a new report from app security company Checkmarx.
The survey of thousands of security leaders exposes an underlying naivete about AI-built code and its vulnerabilities, even as tools like Anthropic’s Mythos are uncovering security flaws orders of magnitude faster than any human security team could ever hope to.
“Mythos-class models collapse the window between a vulnerability existing and a working exploit being available from months to minutes,” the report notes. Enterprises relying on traditional security tools and methods, it says, “cannot survive this reality.”
Checkmarx’s survey of 2,350 CISOs, AppSec managers, and developers across 14 countries focused on how much AI-developed code enterprises are deploying, the vulnerabilities it introduces, how it impacts developer workflows, and overall sentiment about AI code and security posture.
Today, nearly half of production code is AI-generated, and the majority of enterprises also report that at least half their codebase is made up of open-source components, according to the report.
But the more AI-generated code that is pushed out, the more vulnerabilities are exposed. Enterprises who said 81% – 100% of their code is built by AI ship vulnerable code 3.4 times more often than businesses using AI more conservatively, relying on 20% or less AI code.
Additionally, 70% of developers said that AI code generation created vulnerabilities in 2025, and almost all enterprises surveyed (93%) had at least one security breach as a direct result of in-house developed apps.
Still, risk is becoming “normalized,” the report notes, with three-quarters of enterprises knowingly deploying vulnerable code as they face increased pressure for ROI. Startlingly, about 30% of respondents admitted they ship compromised code and hope the vulnerability won’t be found. Similarly, more than a third of organizations leave half of their known vulnerabilities unfixed for 90 days or more.
The report points out that the organizational bottleneck isn’t detection, “it’s the human decision to ship anyway, suppress the finding, or defer to the next sprint.”
Along with this, AppSec teams are often limited to reactive incident response as they deal with tool sprawl. And developers only continuously secure code a small percentage of the time (18%), even though nearly all are equipped with security tooling.
Ultimately, developers are “set up to fail,” the report contends. They face significant pressure to deliver, and are forced to choose quantity and speed over security. Yet, even as they face significant consequences when it comes to post-mortems, performance reviews, escalation, and blocked releases, the tools that contribute to security issues, delivering low-value findings, unclear guidance, or late feedback, continue to go unfixed.
“Developers remain accountable for outcomes, even when systems and workflows are not aligned to support them,” the report notes.
Alarmingly, many enterprises seem to be deluded when it comes to their security posture. Of those that rate themselves as “highly mature” AI organizations, 42% often ship the most vulnerable code, and have breach rates “barely distinguishable” from other enterprises.
“Confidence isn’t protecting them,” the report notes. “It’s blinding them.”
Underscoring this, only 22% of organizations have formal AI governance, and developers still rely on manual code reviews to ensure their code meets compliance standards.
The result is a mismatch between the speed of software creation and the speed of governance, the report notes. “Compliance frameworks are evolving, but many organizations are still attempting to govern AI-scale development with processes designed for a slower era of software delivery.”
Enterprises do seem to have wised up (a bit) after Anthropic’s Mythos proved capable of not only discovering vulnerabilities across major operating systems and browsers, but exploiting them 100 times faster than previous Claude models. And the subsequent Project Glasswing almost immediately surfaced thousands of previously-unidentified security flaws.
Checkmarx’s survey, which, it should be noted, was conducted a month prior to Mythos’ arrival, found that enterprises are finally taking proactive measures, focusing more heavily on AI security threats overall, and investing more in DevSecOps practices, automation, and developer training.
The report emphasizes the importance of prioritizing risk over code volume; vulnerabilities should not be considered isolated incidents. Also, it’s critical to embed security into developer workflows rather than treating it as a checkpoint. Enterprises must have systems that reduce noise, provide clear guidance, and allow them to take action when an issue arises.
Security “must be integrated directly into how developers write, test, and ship code within the IDE, pipelines, and AI-assisted workflows where development now happens,” the report notes.
Similarly, enterprises would benefit by reducing fragmentation and tool sprawl and defining ownership of the AI tools. By simplifying security stacks, they can align responsibilities and ensure consistent tool use, according to the report.
Further, AI needs strong governance, and teams must move beyond outdated manual triage and “human-gated remediation.” AI can fight AI in a strong system built to prioritize, remediate, and resolve risk “without waiting for a human to approve each step,” the report notes.
Ultimately, it says: “Progress depends on embedding intelligence directly into workflows, enabling risks to be prioritized, remediated, and resolved, all within the systems that they operate in.”
This article originally appeared on CIO.com.
AIs struggle to understand documents designed for humans; the DocLang working group seeks to flip that imbalance with its specification for machine-readable business documents “built from the ground up for LLM tokenizers.”
The working group, founded by IBM, Nvidia, and Red Hat and hosted by the Linux Foundation’s LF AI & Data project, aims to create an open, universal, AI-native document format designed to improve how enterprises prepare, exchange, and govern document data for AI systems. ABBYY and Human Signal will also be involved in its development, and other contributors are welcome.
“Enterprises today work across a fragmented landscape of document formats, including PDFs, JPEGs, and other file types built primarily for human consumption rather than AI interpretation,” the group said in its launch announcement.
“This disconnect can introduce complexity, raise costs, and reduce reliability when extracting meaning from business documents,” as organizations increasingly rely on generative AI and agentic systems, it said.
Mark Collier, executive director of LF AI & Data, said the goal of the DocLang Specification Working Group is to “develop a vendor-neutral, interoperable standard that helps organizations prepare document data for AI more reliably, transparently, and at scale.”
DocLang defines a structured, machine-readable format for documents of any type, like JSON for data, that any tool can implement and any pipeline can consume. It builds on DocLing, a document processing toolkit hosted by LF AI & Data that can transform human-readable PDFs, word processor documents or spreadsheets into structured data.
Something like DocLang is needed, said independent technology analyst Carmi Levy. “Existing document standards have done an admirable job allowing global stakeholders to confidently collaborate for decades, but it’s becoming increasingly clear that they are in desperate need of an update as AI reshapes the rules around how work gets done,” he explained.
Largely static document types, he said, “can be somewhat limiting when AI is redefining the very word, ‘document.’ In many ways. AI-age documents are far more iterative and dynamic than what they once were, and the definitions need to evolve with the times. The documents we currently live with simply weren’t designed for the AI age.”
Within that context, Levy said, “DocLang represents an early, best hope of achieving some kind of foundational baseline for document standards, one that will hopefully allow more intelligent, more efficient, lower-risk workflows than is currently the case.”
Taking an open-source, vendor-agnostic approach to the process ensures the collective will take precedence over the needs of specific vendors, he said, adding, “earlier standards-setting efforts around networking, documentation, the web, and the cloud powered the free-flowing digital landscape that defines modern life.”
An AI-centric documentation standard will carry that reality into the next generation of technology, said Levy.
The entire concept of LLMs, Jason Andersen, principal analyst at Moor Insights & Strategy said, “involves using natural human languages. The computer is supposed to understand us without us changing our syntax or language. Forcing a syntax on users is exactly what we have today with SEO and more advanced programming languages.”
With something like DocLang, where the standard can be applied to content ingestion, he said, “I would be OK with that being automated, which seems to be the intent. The use case I envision is that when I upload a document to an agent, a skill can be run to preprocess the document into the DocLang standard format, saving tokens.”
That makes sense, he said, adding that he thinks it’s good “if it can help generate outputs, like a visualization, that can be shared outside an AI tool. On that front, that is also why I am liking Web MCP, since you are just adding some code to the page, like CSS or JavaScript, and the consumer, in this case, an AI browser or skill, is better equipped to handle the site.”
The point, he said, is, “these standards need to preserve the fact that humans can still do what they want, and do not need to know any coding to be proficient. In terms of governance, I am not sure if it matters.”
But one analyst did foresee governance problems arising from DocLang’s use.
Yaz Palanichamy, senior research analyst at Info-Tech Research Group, said DocLang adoption will require organizations to implement and review controls in order to scale its use accountably and securely.
This article originally appeared on CIO.com.
Login