The Fastest Voice in the Room: Mistaking Speed for Thought [LinkedIn Post]

Posted on April 28, 2026 by Daniel (@MKNN)

April 28, 2026

LinkedIn Post | LinkedIn Article

We’re interrupting the ongoing series on AI to pick up on an earlier thread where I wrote about how our commonly shared experience of most meetings often works against our best interests. Here’s the bottom line:

Many groups (teams, departments, entire organizations) are running on first-draft thinking and either don’t know it or won’t acknowledge it.

Before diving in, I need to call out a precondition: nothing can change in organizations without participant safety. More on this in future posts, for now, just note that, until organizations genuinely walk the talk of supporting the expression of a range of perspectives on a solution, little else matters.

Today, though, we’re focused on something quieter and more hidden. Most meetings are dominated by a few voices–not because they have the most to contribute, but because they are the best at the quick processing feedback loop that is often mistaken for competence.

As mentioned in the prior post, I happen to be one of those voices. I process quickly, externally, out loud, in a style that often reads engaged, on top of it, able to quickly integrate and assess new information. And, sometimes it is those things. But, sometimes, it’s just … fast.

The cost of this is that decisions all too often reflect a narrow slice of the intelligence actually available to the organization. Good decisions in complex environments depend on distributed intelligence — inputs from people positioned to see different parts of the system, people whose judgment is informed by other context, people who see things the loudest voices miss. When the meeting is shaped entirely by who can respond fastest, that distributed intelligence never enters the room. What gets called consensus is really just a loud initial reaction, granted power because the room nodded–or, more often, was silent.

Silence does not mean support. It can. But it can also signal processing, consideration, thinking through, mulling over, all the cognitive processes that we go through to arrive at decisions we care about. No organization would claim to prefer decisions made without consideration, without thought, without reflection. Yet that’s what we reward and that’s what emerges as the observable norm.

So the challenge is: how do you amplify the other voices? I want to be clear: I’m not talking about team members who are uncertain of their contributions — that’s a real challenge, but it’s a different one, centered on mentorship, on professional development, on the nurturing of new voices and the making of space in the room for them. I’m talking about the deeply insightful people on your team who simply need more time and space. Time to process what’s been raised. Time to weigh it against their understanding of other concerns, other stakeholders, other implications. Time to sit with a proposed direction and confirm it still feels right after reflection.

The good news is that creating this space is not expensive. It doesn’t require slowing everything down or layering process on top of process, or adopting an elaborate consensus-based model (although those can be quite useful). It mostly requires being deliberate about a handful of meeting mechanics. A few I’ve used:

  • End a recurring meeting with a carry-over question. Close with the key unresolved issue and an explicit commitment to return to it at the start of the next meeting, with a specific call for other voices and alternative approaches. Then actually do it. This one is the most powerful of the three, and the reason is rhythm: once people trust that carry-over is real, they know how to prepare. The space to think becomes structural, not improvised. Ad-hoc “let’s circle back next time” approaches don’t work — there’s no trust that it’ll happen, so no reason to invest in preparing.
  • Build genuine breaks into longer meetings. Give people ten minutes — not to check email, but explicitly to regroup and approach the problem from a different angle. Before you break, establish a deliberate queue for contribution and, after the break, reorder/reconfirm it, building a bulwark against opening the floor to whoever speaks first.
  • Make your agendas meaningful. For some of us, this starts with: make an agenda. Name the shape of the problem space in advance, and explicitly ask attendees to spend time thinking before the meeting. This moves some of the processing out of the room entirely, which is exactly the point.

None of these are dramatic. Most of them are obvious, and things we aspire to, but rarely put actual effort towards. They are, collectively, the difference between running meetings that surface the intelligence in the room and settling for first-draft responses dominating your decision making.

Which brings us back to where we started. The risk isn’t that any single meeting goes badly, but rather that, over time, your decisions are shaped by whoever responds fastest. Over time, organizations slide towards mistaking speed of reaction for quality of thought. Over time, merely being the first idea becomes sufficient. And nothing in the structure of the interaction makes room for anything else to catch up.

Three months of decisions made on first-draft thinking is a tolerable drag, and may in fact increase short-term velocity. A year of it builds blind spots and, more importantly, habits that are actively resistant to deeper thought. This is why meetings punch above their weight in terms of their impact on overall culture and behavior: organizations are shaped, in large part, by the repeated texture of their human interactions. Your people are taught, conversation by conversation, meeting by meeting, that there’s no space for deeper, more considered contributions. And you lose their potential impact in a way that doesn’t show up on any dashboard.

Posted in Culture | Tagged , , | Leave a comment

Reading Well: The Orchard by Peter Heller

Posted on April 25, 2026 by Daniel (@MKNN)

{Been a while. There are other books I need to catch up on, but wanted to drop this fairly quickly after I read it.}

Obviously, I love me some Peter Heller. The Painter was the first Reading Well ever, way back in 2015; I also wrote about The River, The Last Ranger, and most recently, Celine. But my favorite novel by him was The Dog Stars (in a weird aside, this is not at all how I envisioned that book being adopted–I resonated more with the human side and, of course, Jasper, the dog, but here we are).

Until I read 2025’s The Orchard.

In my review of Celine, I was struck by Heller’s shift away from a novel centered on an interrogation of a certain kind of rugged masculinity. The Orchard continues that change: this is a novel with three main characters, all female (mother/daughter/friend).

Heller’s skill with writing about nature is on full display, here the forests of rural Massachusetts and Vermont, but the heart of the book is the characters, their relationships, and the slow, tragic slide that is both clearly signaled and never over-promised. The book is heartwarming and heartbreaking in equal measure.

Perhaps most impressively, without ever drawing undue attention to it, The Orchard remains faithful to the point of view of the protagonist–at first as a young child, then, intermittently, as a young adult. There are things she never knows, things she never considers, things she only infers from her mother’s behavior, things she never thinks of questioning because she’s known no other possibilities. She does, of course, grow up, and her insight when older moves closer to some of these things, but never with omniscience, or recrimination.

Doing that without over romanticizing the character is quite a challenge, and one Heller meets head on.

It’s a quiet book–everything else Heller has written has gunshots, forest fires, a global apocalypse. You know, peril. Yet the stakes in The Orchard feel just as critical: the characters matter that much.

Highly recommended.

Posted in Culture | Tagged , , , , , , | Leave a comment

Beyond Competence: Using AI As Its Own Mirror [LinkedIn Post]

Posted on April 8, 2026 by Daniel (@MKNN)

April 7, 2026

LinkedIn Post | LinkedIn Article

There are plenty of reasons to be cautious about AI tools. Error rates and hallucinations. The quiet reproduction of poor design choices or substandard programming patterns. The ever-present risk of unintended consequences. None of this is controversial at this point, and I’ve even covered some of this in prior posts here.

What’s discussed far less is the leverage of turning the same AI tool that generated a problem into a tool for diagnosing and correcting it. Done well, this improves not just the quality of what you’re building, but the quality of how you’re building it, shifting the use of AI from a “convenient accelerator” to a mechanism for steadily reducing friction and error over time.

Continuing with the relatively approachable work I described in the previous article, I’ve been using Claude while enhancing a WordPress‑based site. The site also relies heavily on Pods, a fairly common data container for WordPress. Nothing exotic or particularly cutting‑edge. But, representative enough.

My work with Claude here was very standard for the “new normal.” I was the orchestrator, the feature-describer and sanity-checker, and Claude was the eager implementer of these ideas. This is part of the seismic role and skill shift we are seeing, and part of the quandary organizations face in assessing internal talent and deciding what talent they should be acquiring: technical resources now direct as much as-if not more than-they implement.

Back to the work in WordPress. Over a short development cycle, Claude and I worked through a half‑dozen items on a loose roadmap: adding PHP functions for specific data calculations, improving data display, building a small admin interface to address data quality issues, and refactoring PHP and CSS code that former‑me had written that made present‑me cringe.

All of that worked. The tasks were completed. The versions of my custom plugin ticked upwards in an encouraging manner from 0.9 to 1.0 to 1.1 and eventually, something impressive looking like 1.4.2. From a feature perspective, things were “done.”

But. Something felt off.

Some of the code paths I reviewed seemed unnecessary. Parts of the documentation we had been generating along the way were oddly structured. There was no single dramatic failure, just a growing sense that complexity had accumulated faster than necessary.

So instead of adding more features, the next step was clearly to step back and audit the work. Doing this, however, didn’t require us to switch roles: I was still the orchestrator, and Claude still the over-eager doer.

But, for the next iteration, I asked Claude to review the entire plugin with a narrow set of concerns: consistency, duplication, and leftover artifacts from earlier work. We identified opportunities to move logic out of PHP and into configuration or admin‑level controls, where future‑me could reason about and maintain things more easily. I had Claude separate documentation into two streams-a slow‑changing technical reference and a more fluid knowledge base-explicitly framed around what it (not me, it) would need to know if we were starting together from a clean slate.

This is a vital, subtle lesson that I learned with difficulty. We’ll cover it in more detail in a future post, but the key thinking point is that the documentation you need can be, and probably is, very, very different than the documentation Claude needs.

The constraints mattered. This wasn’t a single prompt. The work was broken into steps. Changes were proposed at the level of intent first, and only reviewed at the code level as necessary.

The result was noticeably better than the initial generation phase. Fewer odd suggestions. Fewer instances of over‑engineering. And, importantly, consistent identification of remnants from its own earlier efforts—duplicated logic, buried CSS rules, structures that might have made sense locally but were clear weak spots when elevated to system‑wide protocols.

This shouldn’t be surprising. Pattern recognition, comparison, consolidation, and cleanup are all well aligned with what these systems do well. What’s easier to miss is that this dynamic doesn’t require sophisticated agent frameworks or fully autonomous workflows. It applies just as much to everyday, lightweight usage.

Right now, a great deal of attention-and money-is flowing into tools and consulting practices focused on reflexive, self‑correcting AI systems. Much of that work is thoughtful and valuable. But the underlying idea scales down quite cleanly: even in relatively modest contexts, deliberately folding the tool back over its own output changes the quality of the result.

The shift here isn’t technical so much as behavioral.

We need to build muscles around treating AI output as provisional, around expecting revision, around explicitly designing the rules of engagement to maintain space for critique by design. Once you adopt that posture, the risk profile changes: the primary danger is no longer that the tool will make mistakes, it’s that you’ll accept them. Once you see that clearly, not building in reflexive use starts to look less like a missed opportunity and more like an avoidable liability.

And this reflexive, folded-back-on-itself use of AI is where the real leverage is. But. It. Can. Be. Hard. Hard and frustrating in weirdly surprising ways. But that’s a post for another week.

Posted in Culture | Tagged , , | Leave a comment

From Convenience to Competence: What AI Actually Demands of Us [LinkedIn Post]

Posted on March 31, 2026 by Daniel (@MKNN)

30 March, 2026

Linked in Post | Full LinkedIn Article

I have spent the last few weeks immersing myself in a variety of development projects, using a mix of Claude and CoPilot. This may surprise readers of my earlier vibes/VIBES post, but the challenge is not whether to use these tools, but how to understand what kind of assistance they actually offer, and at what cost.

I will focus here on relatively approachable work: building and modifying a WordPress site, small automation efforts, incremental refactors. This is intentional: there is less to this than, say, creating and troubleshooting a production CI/CD pipeline, but the patterns are quite similar. The same strengths show up, the same challenges repeat, and the lessons transfer more cleanly across the tech stack than most people expect.

That said, I’ll always try to also at least nod to the comparable lessons for larger, more enterprise focused work in these posts.

My initial sense of working with Claude and CoPilot was that it felt like working with the most over-eager, enthusiastic, junior intern you’ve ever met. BUT, the intern has memorized all the documentation. ALL. THE. DOCUMENTATION. And that has impactful, material value. Removing the burden of accessing all of that information is, at least at first, magnificent.

Anyone who has veered even slightly off the happy path in a platform like WordPress knows how much context lives just outside the task itself. Plugin creation and management, child themes, CSS placement, even just the core configuration of the platform—none of this is conceptually hard, but all of it creates friction. It’s the kind of friction that slows work, breaks flow, and disproportionately punishes people who don’t spend most of their time working inside these systems.

Claude (and the others) simply know this stuff. You can stay focused on what you’re trying to accomplish, while it fills in the surrounding structure. So that’s pretty amazing, and certainly a massive time-saver.

That alone would make these tools useful, offering small windows into enhanced productivity as a sort of hyper-optimized search engine that can be accessed via natural language queries. But there’s more here, and accessing that additional value is, I think, the critical bar for success in AI implementations, regardless of the size/scope of the context.

It all revolves around navigating how you leverage the application of the immense knowledge held by the tool.

Claude’s reactions are inconsistent at times, over-engineered at other times, and often in need of constant course correction and attention. And, quite dangerously, it will agree with your input immediately and enthusiastically, regardless of its quality.

A concrete example: Claude proposed a complex, JavaScript-based solution to change the appearance of some text. I suggested using standard CSS instead, which Claude-immediately and enthusiastically-accepted as a better approach. There are dual risks here. Solutions that look clever in the moment often undermine long‑term maintainability, and the tool’s willingness to pivot means you have to maintain a fairly high level of skepticism about the reliability of its initial recommendations.

The phrase “human in the loop” has gained fairly widespread use, and this is its application: as a user, you need to know the structure, the overall best practices, the general parameters of the architecture you’re working on or in so you are able to help guide Claude along its way. Indeed, guide may be too weak: you need to be able to critique the tool, to insist on things you know are true, to demand enough insight from it to convince you otherwise.

The key skills end up being yours. Your judgment, your pattern recognition, your instincts around architecture and troubleshooting. These are what organizations need, at the enterprise, to couple with the knowledge embedded in the AI tool; they are also what you need if you want more than surface-level gains.

There’s a bit of legitimate magic here, however: you can use the same AI tool to educate yourself on those best practices and to create a feedback loop that corrects the AI behavior. If you build into your interactions an active practice of asking why a given approach is preferred, or what alternatives exist, or what tradeoffs you’re accepting by doing something one way instead of another; you will often arrive at a far better, far more sound solution.

And you can do this from a place of learning: you don’t need to enter the interaction knowing about child themes in WordPress, but you do need to have the analytical skills necessary to ask the right questions, to integrate the answers, and to eventually arrive at a shared understanding of the best practice. That said, crucially, you never need to know exactly how to implement them.

This meta-usage, reflexively folding the tool back onto itself, using it to interrogate and critique and refine and improve its own output, is the single greatest lever we have for meaningful impact. This is what will define our ability to do more than merely automate mediocrity. That’s where the next article will focus: not just on using AI, but on using it to raise the bar for itself.

Posted in Culture | Tagged , , | Leave a comment

There’s Vibes, and There’s VIBES [LinkedIn Post]

Posted on February 24, 2026 by Daniel (@MKNN)

This one kicks off a deep dive into the murky waters of using AI tools in development work.

24 February, 2026

LinkedIn Post | Full LinkedIn Article

I’m not a curmudgeon. Really. And I’m a pretty bad Boomer representative. But I do roll my eyes almost involuntarily at discussions of “Vibe Coding.”

Like so many things, this reaction varies dramatically with what people actually, for-realsies, mean by the term. This came to a head over the last few weeks, crystallizing with two things I encountered within about a week of each other (for some of you, both of these are “old news,” but I think the comparison is still current, relevant, and meaningful).

The first was an episode of Hard Fork, the somewhat-tongue-in-cheek New York Times tech podcast where its hosts Kevin Roose and Casey Newton each had independently used Claude to “vibe code” new websites over the holidays. Kevin’s is very clean, very direct, and has a fun Easter Egg that makes it look like a 1990s GeoCities site. Casey’s feels more “professionally designed.” Both seem fine, and not terribly different from what you might create with the same amount of time with WordPress Templates or SquareSpace or whatever.

But both sites were created “just vibing with Claude.”

Casey talks about adding functionality to the site. And how he asked Claude to add a subscription widget that allows visitors to sign up to Platformer, his monetized content platform. And he moves on quickly with how great it was that Claude could do that.

Except … it didn’t. Not really. Yeah, there’s a subscription box on Newton’s home page. But when you put your email in that box and hit subscribe, it … doesn’t. Instead, it pops you over to Platformer, where you have to re-enter everything if you actually want to subscribe.

So, vibe coding created something that looks vibish, but whose code would fail the most basic User Testing.

It’s, I guess, “good enough” to seem impressive at a glance. And that seems to be the actual bar for vibe coding in general. Which is … fine? I guess? I mean, a tool to create slick looking demos that have an approximate relationship to final products is useful, right?

Here’s the contrast. That same week, Boris Cherny, who is referred to as the creator of Claude Code, publicly shared how he uses the tool. (That attribution strikes me as weird, and likely a result of our need to believe that creation is a singular act–whatever, Cherny is clearly highly influential and deeply involved in making Claude possible, and he himself refers quite a bit to the team he works with.)

Cherny’s workflow is … totally opaque and incomprehensible if you don’t have a programming background. If you do, it all makes sense. But it ain’t vibe coding. It’s structured use of a tool that can automate, aggregate, and do long-form research, and it is all predicated on having the experience and insight to recognize the abstract patterns that form the bulk of software development work and then create triggers and commands within Claude to alleviate the impact of that repetitive, reproducible work.

You can find Cherny’s original posts on Threads here. (Yeah, it started on Twitter, but I don’t go there no more.)

It’s impressive–as you would anticipate–and it shines a light on how agentic AI can be used to dramatically reduce certain kinds of work, even if the total savings is eaten away at by the need to manage the orchestration of the agents, review their work, tweak them, etc.

And it’s about as far away from Hey, Claude, add a widget or Hey, Claude, can you add a button to make the site look like what we remember of GeoCities? as you can get.

This illustrates, for me, the gap vibe coding still cannot (and, I suspect, will never be able to) fill. Tools like Claude Code can be used to create things that look decent, and things that, at some low bar of testing and sophistication, work. But developers working on real projects aren’t using it that way. They’re using it to automate (see my prior post as well, Go Forth & Automate!), to tackle routine drudgery, to create more abstract, reusable patterns that apply across use cases.

And that can be fantastically impactful and transformational. But it ain’t vibes. It’s work. It’s good work, it’s worthwhile work, it’s the work of the present. Still, work.

Posted in Culture | Tagged , , | Leave a comment

On Meetings (One in a Series) [LinkedInPost]

Posted on February 10, 2026 by Daniel (@MKNN)

Everyone’s favorite topic …

LinkedIn Post | Full LinkedIn Article

Originally published 10 February, 2026.

Nothing earth-shattering today, just another plea to think about what it means to work with people whose brains work differently than yours, and how that should change our professional interactions.

I’m a very quick, external processor. Meaning, I work through information very rapidly and often do so via speaking–the act of talking is part of my process of understanding and integrating new data.

It was a revelation when I (finally) understood that not everyone did this. Or, better, not everyone did this this way. Some people need time away from the group to process. Some people need to validate their first reaction against further research. Different people shut down in response to different stimuli–that may be the size of the audience or the presence of their boss-cubed, or understanding that their (absolutely correct) insight has the potential to torpedo a multi-million dollar initiative.

And all of those behaviors are rational, reasonable, and fully consistent with impactful work. So, a revelation.

And when I say revelation, I don’t mean, Oh, that’s interesting. I mean, Oh, that means that if I’m serious about my commitments to leadership, to inclusion, to building the best teams I possibly can, I need to reconsider almost everything I do.

Here’s an obvious one: most organizations are meeting-based. Most meetings are dominated by people who process like I do–quick, external processors. We take up the most air in these (all too often, virtual) rooms. Hence, most organizations are dominated by quick, external processors.

But if I were to rattle off the smartest people I worked with; the best problem-solvers I worked with; the most insightful technical experts I worked with, well, that list is not dominated by quick, external processors.

And the distance between the prior 2 paragraphs represents a huge value loss and quality loss in most teams. At best, the team is constantly swimming upstream trying to compensate for something it doesn’t quite understand; at worst, it just misses the value in those other voices.

And that ain’t great. I mean, it worked really well for me personally at times, and therein lies part of the problem: we are all often rewarded for behavior that is actually detrimental to our continued growth.

Posted in Culture | Tagged , , , | Leave a comment

Go Forth & Automate (LinkedIn Post)

Posted on February 2, 2026 by Daniel (@MKNN)

{ I messed this one up, and it auto-posted without an actual post to go along with it. We learn … here’s the actual post on LI }

I saw this piece on AI in The Workplace in 2026 on Quartz, and then Judith Katz sent me the summary.

It’s a decent piece, nothing earth-shattering. The general point is that AI will help mid-level managers by handling routine tasks, freeing them up for more creative, human-centric activities. And that may even be true for some folks.

But it made me think of two points that are almost always absent from these discussions.

First, there is an under-appreciation of the amount of slop these systems will inevitably create. By slop, I am referring not just to hallucinations, but also to the mediocre, vaguely inaccurate, meaningless output that forms, say, the bottom 25% of what we get from LLMs. It’s someone’s job to improve / moderate / weed out this content, and, unfortunately, it is work that, if ignored, tends only to compound the problem.

Second, and this may be the more relevant insight, the article, like so much of the discourse I see, uses the term AI in a very inconsistent, very fluid way. Time and time again, the most successful, most compelling implementations covered by the AI umbrella are actually automation efforts, often with an LLM-fueled presentation layer at the end. These are not LLM interactions, they are algorithmic automation with a nice language layer to interact with.

Why does this matter?

Because automation challenges are solvable. Automation challenges are definable. Automation challenges are testable, reproducible, and measurable.

Automation challenges are also, usually, decidedly unsexy. They lack the glamor of the AI conversation, they don’t generate billions of dollars in angel investments, and they seem very distant from the sense of wonder so many feel at LLM based interactions.

So, sure, we may need to position our automation efforts as AI as part of an organizational political strategy, and we may need that LLM-fueled interface to build stakeholder enthusiasm. And we can even add our successes to a variety of arcane ROI calculations as part of a larger AI initiative.

The distinction matters because the practical skills that are needed for success in automation efforts are not fully congruent with those needed for AI/LLM implementations. There is overlap, of course, but I wonder if this sits at the center of the struggles I see in organizations generating real-world traction in their AI (but really automation) efforts: the teams they assemble lack the right skills partially because nobody is presenting, with extreme clarity, what the actual work in front of them is.

Posted in Culture | Tagged , , | Leave a comment

In My Rush to be Right, I Forgot to be Useful (LinkedIn Post)

Posted on January 20, 2026 by Daniel (@MKNN)

{ Another entry from LinkedIn. Post here, full article here. }

We often walk into professional situations and are surprised at how technology has been implemented. This is the norm if we’re consultants, but it happens equally often on internal teams–you are tasked with collaboration with another team or to resolve a particular long-standing challenge and, maybe 20% into learning about it, the dominant reaction is, wait, y’all did what?

These very common, head-scratching moments where we just cannot understand how someone made those particular decisions are often-missed opportunities. And are often the root cause of hundreds of hours of wasted time and money.

This is all a little abstract, and I apologize for that, but I have seen this pattern in so many different parts of the technology world–software development, process refactoring, digital data management, infrastructure configuration, on and on–that I want to talk about it from a more generic perspective.

I was once helping family members move a bed, and began arguing about some minor point of construction or location (I don’t exactly remember). But I suddenly realized that everyone else was holding up the bed, waiting for me to lift my corner. I quickly apologized and said, I’m sorry. In my rush to be right, I forgot to be useful.

And this is similar to what happens in these moments professionally.

It is especially dangerous for consultants. External consultants are incented to very quickly assess, analyze, point out the existing issues, and provide a solution. And in this demand for speed and immediate impact, again and again, the existing context is missed. This leads to the classic challenge with externally-sourced solutions: they are technically correct, but not fitted exactly to the particular contours–the context (that word again)–of the organization.

Context is a key word for my professional practice, as well as the rest of this article: I use it to refer to the larger problem space, including business drivers; multiple levels of stakeholders; and interrelationships and dependencies with other technologies, other bits of code, and other internal and external groups. So, context looks at a very broad picture.

But it’s equally dangerous internally where we often toss our scorn into the gaping maw of we’ve always done it that way, roll our eyes, and either move on or, if we’re honest, try to steamroll our newer, better, more elegant solution through the process. And steamrolling always, always carries a cost.

The crux of the issue is that, most of the time, the current context exists for a reason. Rational actors made rational decisions to create it. Yes, there are occasions where we are tasked with fixing some piece of idiocy, and while that makes us feel good, those circumstances are, in my experience, less common. The original reasons not only shed light on the existing context but, far more importantly, need to inform our new solution.

This leads to one of my professional touchstones: if I cannot articulate, as fully as possible, why something is the way it is, I am not yet in a good position to propose a solution. Or, more positively, your solution needs to address not only what needs to change, but why it needs to change, and you can only say why it needs to change if you understand why it’s the way it is.

And look, most projects eventually get there. But they get there by missing the original context, beginning to implement a solution, having some meeting with a stakeholder where, finally, the lightbulb goes on and they realize why some particular requirement was so important, re-designing their solution, and reworking some of the implementation in light of the new knowledge.

All of which could have been avoided by moving more slowly and more deeply through the context, listening more closely for why the current system exists the way it does.

Posted in Culture | Tagged , , | Leave a comment

Notes on Current AI (LinkedIn Post)

Posted on January 12, 2026 by Daniel (@MKNN)

{ I am archiving these here, just because. Here’s the link to the LI Post, and then to the article itself. If you want to engage or amplify the post, please go there! }

{I plan to post occasional thoughts here, ranging from views on technology to leadership to organizational culture change. I hope they are interesting and even occasionally thought-provoking. We’ll start with some thoughts on generative AI.}

I am struck by the (alarmingly?) wide range of views on AI being articulated by people I respect. It’s clearly a very challenging topic to thread the needle on, and, as always, what we see is largely defined by where we stand. Critics gonna’ critique, consultants gonna’ sell, and if your livelihood is perceived as under threat from an emergent technology, that is certainly going to impact your position.

As an instinctive contrarian, I am attracted to people willing to say things that may, on the surface, seem to go against their interests. As such, I hold deep respect for what Devlin Liles is doing at Improving . His short videos about the challenges of successful AI implementation are very smart, very on point, and very useful as cautionary tales.

Clearly, he is implying that Improving is the best partner to overcome these issues (and indeed, they may be), but it is a decidedly different tone than the overselling of the ease and impacts of the usual sales pitch. And the specific obstacles Devlin points out–which boil down, once you move past the specific technical concerns, to scope, expectations, and stakeholder engagement–are well worth considering.

But Improving’s stance is very much focused on the enterprise. And I’m not sure that’s where AI is currently focused. It’s certainly not where the marketing efforts behind AI are aimed. My assumption is that’s because, in general terms, AI is still so, so, so … um … bad. My favorite recent example: I typed Who played LF with Joe DiMaggio into the search bar and, among the answers given were Lou Gehrig (contemporary, not LF) and Paul O’Neill (LF, far from contemporary). This is a pretty easy research question, solved in a few clicks.

The CoPilot app and ChatGPT did pretty well on the question, and the results continue to vary pretty widely, depending on which tool you ask and the specific phrasing of the question. This highlights the core of the challenge: there is a burden on the user to not do the easiest thing to get good results. This is, of course, an opportunity for expertise (that is, the better you are at prompt crafting, the better your results), but it’s an obstacle to common professional adoption.

A more potentially damning example is something I have seen quite often recently:

Candidate is located in Houston, TX, which is relatively close to Bethesda, MD, allowing for feasible commuting or relocation.

Eyebrow raised: Oh, really?

Another data point: I am served ads for CoPilot where the enticing message is … make cartoon versions of me and my Dad, because that will bring us closer. I mean … far be it from me to downplay the generationally healing potential of laughter and joy. But I don’t know that AI art is the avenue to such reconciliation.

Once the AI slop spills out of the bottle, it’s not going back in. But that doesn’t mean we have to drink it. The Oatmeal, as it often does, explores this particular angle–AI and its relationship to artistic creation and art–far better than I could.

What I like about this is the nuance: there are legitimate uses of AI in the creation of art, but they must be approached with great care, and with our eyes open as to the potential costs, both in terms of effectiveness and quality, but also with regards to the ethical price of contributing to the ongoing production of the slop.

As always, tante over at Smashing Frames is incredibly useful in his analysis of AI. His take on Agentic AI–which I am pretty sure Improving would protest strongly–being especially trenchant for those interested in figuring out the true economic (read, corporate: cartoon versions of the family will only ever generate but so much revenue) impact of AI.

Ultimately, tante sees AI, in its current place in the marketplace, as a hype engine, as something that, due to its current limitations, can never actually deliver on its promise and, hence, is constantly forced to produce more promises. Some see this as a definition of a looming AI bubble, but tante intimates that perhaps bubble is the wrong vision: instead, he envisions a massive hamster wheel, where, whenever one generation expires from sprinting at full speed, another hops on to take its place because what is fueling the movement of money right now is the momentum of the wheel, without regard to its output. AI needs to always be promising the next great thing, because the current thing … as we’ve seen, not so great. See his full analysis, but his full archive is worth a deep dive.

Obviously, that cannot last. But it may indeed last long enough for output that is genuinely useful and impactful to rise out of the slop. This is important. What is happening right now is not good. But that doesn’t mean it will never be so. Indeed, the way to avoid an AI driven economic collapse may be for AI to start to deliver–ever so slightly, ever so impactfully–on its constantly evolving promises.

A final perspective. The editors at the magnificent n+1 Foundation recently posted a pro-Luddite screed against AI. It’s entertaining and fun to read and most certainly not wrong. And its takedown of the formulaic I tried AI and This is What I Learned article (which it terms AI and I, which I just love) is borderline brilliant. But it’s also far from right. Waving one’s hands and asking people to Just. Stop. Using. It. is a reaction that is doomed to both mockery and failure. Thick skin can protect against the former, but the latter sticks. See The full post here (warning, long–n+1 is a literary magazine after all).

Still.

Michael Franti, way back in the Spearhead days, once sang, Must everything in life have political ramifications, even taking kids on vacation. And n+1’s point that the real concern over AI should be resource consumption, exploitation, and the continued service of the few against the many is clearly correct.

But the solution to that isn’t to ignore it. You can choose not to reward it (no, CoPilot, I will not be burning resources to see anime versions of my family), but burying one’s head in the sand is a poor tactical choice.

So what to do?

As with all technology, the answer lies in judicious application, in steadfast skepticism of the hype, and in locating where and how the abilities of generative AI may enhance and add ease to life. Everyone’s calculus may differ, and if yours leaves you rejecting it in total due to a resource consumption argument, I think that’s an honorable position. But hold that calculus lightly: its cost will inevitably decrease, and its presence will only increase.

#technology #ai #musings

Posted in Culture | Tagged , , | 1 Comment

Reading Well: Silver Nitrate by Silvia Moreno-Garcia

Posted on December 10, 2025 by Daniel (@MKNN)

Silver Nitrate by Silvia Moreno-Garcia (2023) is a supernatural thriller set in the burgeoning film industry of late 20th century Mexico City.

The novel revolves around a lifelong friendship that always dances on the edge of (potentially doomed) romance between the female protagonist, who is smart and tough and a little worn down by being a woman in a male-dominated field (audio engineering at the transition from manual to digital methods) and a cynical, man, once a rising star in Mexican cinema, who uses vicious humor as a shield against emotional intimacy. They are friends from childhood, witnessing each others’ various travails, including his career being derailed by a drunken car crash that cost the life of his then-partner. Their banter is witty, cutting, loving, and hurtful all at the same time: you know, like real people with deeply shared histories often are.

The plot is well executed, pulling together various strains of occultism, a Nazi fleeing Germany for Mexico and attempting to achieve immortality, and, above all, the power of film (specifically, yes, that shot on silver nitrate stock) to be a form of magic. I (of course) got a little concerned about the occult dimension, knowing a bit too much about the subject, but Moreno-Garcia does a nice job mixing historically accurate information on the often bizarre Nazi relationship with the occult with the needs of her characters and plot.

The parts that are supposed to be eerie and frightening are, and while you’re pretty sure the protagonist will pull it off in the end, it’s not at all clear how, or at what cost. I don’t think you can ask for much more than that. Sprinkle in some nuance around the economics and cultural role of Mexico City in relation to the USA, and it’s a decent recommendation, even if, for me, the ultimate resolution of the core relationship felt a little too pat.

Posted in Culture | Tagged , , | Leave a comment