Attitudes About AI Adoption and Acceleration

Scott S NelsonLeave a comment

Much of the misplaced fear and distrust surrounding AI adoption traces back to a single omission in how people are often introduced to its use. Businesses and the media have fixated on the intelligence aspect while often ignoring the behavioral framework required to make it work in the real world.

The early representation of Generative AI suggested it was a shortcut that required very little effort. If users were told upfront about the level of detail, context-setting, and iterative refinement required to get a usable result, the hype might have been quieter (look how long Anthropic was off the radar of the general public), but the real work with these powerful tools might have started sooner for the average person and business (AI Adoption Puzzle: Why Usage Is Up But Impact Is Not, BCG, 2025)

We are essentially trading traditional coding hours for what some call vibe coding: throwing natural language at a problem and hoping the model catches the intent. Vibe coding is a legitimate way to prototype, but it becomes technical debt if you do not eventually solidify the logic. Replacing a clean specification with an open-ended series of guesses is how projects lose their shape before they find their footing.

The most effective approach is not simply plugging a model into an existing process because it looks like it might help. Genuine acceleration comes from a willingness to rethink how things get done, then determining how AI can facilitate those better ways. It is the difference between automating a flawed process and designing a new one.

The success stories often come from teams who looked at a failed output and wondered what specific lever they forgot to pull. They treat the model as a mirror. If the output is off-base, it usually means the instructions provided were incomplete or lacked the necessary constraints. It is an objective way to see where our own requirements are fuzzy.

This is particularly evident in workflow automation. Earlier automation projects often failed because they only mapped the mechanics. We drew boxes and arrows to show what happened next, but we ignored the intent.

AI-driven automation is succeeding where those attempts fell short because the machine requires the reasoning, not just the step. To make an agent navigate a workflow, you have to document why each step exists. This forces organizations to complete their process definitions rather than paper over the gaps. If you cannot explain the logic behind a decision point, the machine cannot execute it. This forced clarity is the real process improvement.

The Double Standard

There is a noticeable double standard in the modern workplace. When an LLM returns a hallucinated mess or fails a logic branch, we iterate. We refine the prompt. We provide more context. We give the machine a level of professional grace and patience that we rarely extend to our human peers.

Think about what that looks like in practice. A new team member submits work that misses the mark, and the first instinct is to question their judgment or capability. The same output from a model and the instinct is to wonder what context was missing from the prompt. One is treated as a character flaw; the other as a specification problem. They are often the same problem.

If organizations applied that same diagnostic instinct to people, treating an incomplete first draft as a gap in the brief rather than a gap in the person, productivity would likely increase. Instead, we frequently demand accuracy on the first pass from humans while subsidizing the machine’s learning curve with endless retry clicks. (The Human Side of AI Adoption: Lessons From the Field, MIT Sloan Management Review, 2025)

The Same Loop Applies to Both

Closing that gap is not primarily a technology problem. It is a management problem, and the same loop applies whether you are working with a model or a person.

Start by acknowledging that a wrong answer is often a sign of a logic path being tested; it is data, not a failure. Reward the attempt at solving the problem; in early iterations, the goal is narrowing the scope, not delivering the final answer. And when the output is off-base, assume the cause is a lack of clear boundaries before assuming incompetence. These are not novel management principles. They are just easier to see when the thing being managed cannot take it personally.

The teams getting real value out of these tools are not looking for a magic button. They treat the AI as a diagnostic tool for their own process gaps. They do not just want the answer; they want to see where the system broke so they can fix the underlying logic.

The One Attribute That Survives

This brings us to the attribute that determines whether a tool gets abandoned or mastered.

Curiosity is the only attribute and attitude that survives the hype cycle.

Expectations without curiosity lead directly to disappointment. If you aren’t wondering why the model failed, you will just conclude the tool is broken and move on. In a technical context, curiosity is the bridge between a strategy and a result. It leads to both the perseverance and the openness to changing the way we think about how things get done. It forces us to reprioritize the work based on what the machine reveals about our own internal logic.

Proficiency in this landscape is not about mastering a specific toolset, because those change every few weeks. It is about an underlying hunger to understand the mechanics of the work. If you have that curiosity, you will find the ROI because you will keep digging until the logic is sound.

Until next time…

Related reading from What IT Is:

If you found this interesting, please share.

© Scott S. Nelson

Efficient Claude Usage with Microsoft Word Documents

Scott S NelsonLeave a comment

The recent increase in usage limits has done what scarcity always does: it has made people pay attention to process. Suddenly, everyone wants to know how to get more out of Claude without burning through context on avoidable nonsense. The answer, at least for Word-heavy work, is simple enough: do the real work in Markdown, then convert to Word at the end.

That is not a trendy preference. It is basic resource management.

Start in Markdown

The common mistake is to treat Word as the working format just because the deliverable has to be a Word file. That feels tidy right up until Claude spends time and tokens dealing with DOCX structure instead of the actual writing. Claude’s own guidance is plain about the underlying constraint: “Claude’s context window fills up fast,” which is polite model-speak for “stop wasting it” (Best Practices for Claude Code, Anthropic).

Markdown avoids most of that overhead because it is plain text. That matters more than people want to admit. If you want Claude to help you think, draft, revise, and restructure, give it the cleanest working copy possible. Save Word for the part where human beings still insist on headers, footers, styles, and other ceremonial labor.

DOCX Costs More

A DOCX upload is not the same thing as a Markdown file with a fancier extension. It has to be unpacked and interpreted, and that processing overhead shows up in usage. Perplexity’s file-upload guidance makes the point indirectly but clearly enough: large files are handled by extracting the useful content, not by preserving some magical full-fidelity document soul (What We Can’t Do, Perplexity).

The practical difference is not subtle. Published guidance on Claude usage reports that Markdown can use roughly 65 to 90 percent fewer tokens than DOCX for the same content, and that converting to Markdown can reduce token usage by up to 90 percent (How to Convert Files to Markdown to Reduce AI Token Usage by Up To 90%, MindStudio). That is the sort of delta that turns a usable workflow into a quota sink. If you are doing any amount of iterative editing, those savings compound quickly.

The Plugin Assumption

It is natural to assume the Word plugin should be more efficient than uploading a Word file. It lives closer to the document, it feels integrated, and it avoids the mental friction of exporting and reimporting. That is a comforting theory. It is also the kind of theory people keep right up until the bill arrives.

The problem is that convenience does not eliminate document complexity. Claude still has to work within the same context constraints, and Word still produces the same heavy DOCX baggage underneath the friendly interface. The plugin may be better ergonomically for some editing tasks, but it is not inherently cheaper in usage terms (Best Practices for Claude Code, Anthropic). Word is very good at making labor look civilized. It is less good at making it light.

The Practical Workflow

The better approach is boring, which usually means it will actually survive contact with production. Draft in Markdown. Edit in Markdown. Use Claude on the Markdown version while the content is still moving. When the document is stable, export to DOCX and do the final polish in Word.

Pandoc is the clean bridge between the two. It can convert Markdown to DOCX and back again, and its --wrap=none option is useful when converting Word to Markdown because it avoids unnecessary line wrapping noise in the source text (Pandoc User’s Guide, John MacFarlane). That makes the round-trip easier to read, easier to diff, and easier to hand back to Claude without feeding it a bunch of formatting clutter.

A sane process looks like this:

  1. Convert the existing Word document to Markdown with Pandoc.
  2. Use Claude to edit the Markdown version.
  3. Convert the finished Markdown back to DOCX with Pandoc.
  4. Open the DOCX in Word and apply the styling, branding, and layout cleanup that Word insists on being asked for last.

For existing documents, the same rule applies. Convert the Word file to Markdown using Pandoc with --wrap=none, make the changes in Markdown, then convert back when you are done. If the edits are small, copy the updates back into the styled Word file. If the edits are substantial, rebuild the document from the Markdown and stop pretending the old layout deserves to survive unchallenged.

Where Pandoc Belongs

Your earlier post on Pandoc is the natural starting point for anyone who needs the setup and wants the shortest path to something useful: Boost Your GenAI Results with One Simple (and Free) Tool (me). That is the right companion piece here, because the real point is not “use Word better.” The real point is “stop making Claude pay the Word tax until you absolutely have to.”

The rule of thumb is simple. Do the thinking in Markdown, use Pandoc to convert at the edges, and let Word handle the final cosmetic work. If you start with DOCX, you are usually paying more than you need to. And Word, as always, will be happy to take the fee.

If you found this interesting, please share.

© Scott S. Nelson

Perspectives in Spec Driven Development

Scott S NelsonLeave a comment

There’s this great weekly online morning meetup I join when I can called “The Secrets of Product Management”, led by Nils Davis. Recently the topic of Spec Driven Development came up.

Full disclosure: I didn’t take notes in the meeting and there were a lot of concepts and thoughts shared verbally and in the chat. Some of what I recall may be off, and I hope that if anyone present reads this and has a better recall that they share their thoughts in the comments.

Some thought it was about a Product Manager gathering all of the specifications for a product in advance, and that it led back to waterfall style processes.

Some thought it was building a Proof-of-Concept to serve as the specification.

By the end of the discussion, the one thing everyone (mostly) agreed on is that it works much better when done iteratively, and includes direct references to standards.

As an architect who still codes, my understanding of SDD is that it is about the spec files that are carefully crafted to direct generative AI in how to write the code. It is a way to get better code from the AI that will require less refactoring after the first results.

The different perspectives made me think it was worth doing a little research and summing it up for my reader here. I admit to mentally vacuuming up a lot of content about AI in order to feed my own synthesis on its use, and the key thing that I saw differently was the ownership of the specification used for SDD.

When I presented the question “Who owns the spec in spec driven development?” to an AI, it responded with “…humans own the spec…”, which points out a whole new perspective.

So, that’s what drove me to dig in a little bit to improve my own understanding and share the results.

A Quick History Lesson

Like most things in IT, the earliest signals appear long before what we later label as “modern” computing (a term that conveniently tends to align with when each of us personally got excited about technology). As far back as 1987, Managing the Development of Large Software Systems: Concepts and Techniques outlined ideas that closely resemble what many now think of as Specification-Driven Development (SDD). Interestingly, its diagrams reflect structures similar to waterfall methodologies (an ironic reminder that many “new” ideas are refinements of older patterns rather than entirely novel inventions).

These concepts did not evolve in isolation. Over the following decades, they were reinforced by related disciplines such as formal methods and API design principles like Design by Contract* (which emphasized precision, verifiability, and clearly defined interfaces). Later, approaches like Behavior-Driven Development (BDD) carried some of this thinking forward, framing specifications as shared artifacts between humans and systems (but still largely as guidance rather than execution).

What has changed more recently is the role of AI in making specifications actionable. Around 2025, tools began to emerge that transformed specs from passive documentation into active drivers of implementation. Projects like AWS Kiro and GitHub’s spec-kit marked a shift. Specifications became executable guides for coding agents (not just references for developers). In this sense, “modern” has continued to compress (moving from spanning decades to evolving almost in real time), as specs shift from descriptive artifacts to operational components of the development process.

Opinions Still Differ

I don’t think my input in the recent conversation changed anyone’s mind about how they define SDD. And people will definitely have strong opinions on the value of SDD.

In a recent post, Allen Holub said:

“People talk about spec-driven design, but the best spec you can have is a test—a test you write before you write the code. You don’t write a test to see if the code adheres to a spec. The test IS the spec. Don’t write specs. Write tests.”

I agree with TDD proponents, because it is part of a Continuous Testing cycle, a process that was just starting to really catch on before GenAI went GA, and is even more important since. That said, tests are part of the spec, they are just managed a little differently because the developer doesn’t happen to be human. That’s the whole point of SDD. It is how developers work with agents through clear communication. Because, let’s face it, the Agile approaches of sitting with a user won’t work with AI until after the code has been written, and pair-programming with an AI was only modern for a moment.

Helpful Tools to Try

Tools make this less painful than it sounds.

GitHub’s spec-kit is a good entry point. It gives you Markdown templates for a “constitution” file with principles, then spec.md, plan.md, tasks.md. You slash-command it in your IDE, and AI fills in the gaps. They put it well: “The specification captures intent clearly, the plan translates it into technical decisions.” ([GitHub Blog], Spec-driven development with AI: Get started with a new open-source toolkit) Amazon’s Kiro does staged workflows, Tessl flips code to byproduct. Red Hat talks up “lessons learned” files to feed back into future specs, cutting errors over time ([Red Hat Developers], How spec-driven development improves AI coding quality).

Wrapping Up

All in all, my sense is to treat specs like your IaC or database schemas. Human owned from the start, iterated carefully, governed with some structure. Reference standards to ground it. Try it small, on a utility script maybe, and see how it holds up in real work.

If it fits your flow, it can add real velocity with AI. If not, no big loss; plenty of paths forward.

*Side note: Yes, I usually have these inline in parenthesis (a habit my AI editors hate), but this one seemed too long for that, so… I did some research with Gemini where it insisted on a correlation between design by contract and spec driven development, which at first I took to mean it prefers its training data rather than current information, so I switched to my usually research LLM wrapper, Perplexity. After some hind-brain thinking, it occurred to me that Gemini may have semantically equated specification with contract, which is another quirk of AI: it is so darn literal!

If you found this interesting, please share.

© Scott S. Nelson

Take the Tax out of Taxonomy

Scott S NelsonLeave a comment

TL;DR: Your GenAI output is failing because your local workspace is a disaster. If your desktop is a dumping ground, your enterprise data lake is guaranteed to be a swamp. Stop blaming the model, establish a strict folder taxonomy, and kill the bad data habits before they scale.

For my regular reader, you know I can’t resist a pun, and the initial research note for this post was “Timely topic title: Take the Tax out of Taxonomy”. You also know I digress, so I thought I would get it out of the way at the start. Done. Moving on to the next level…

You are paying a massive hallucination tax. You bought a premium AI subscription or deployed a desktop agent. You pointed it at a project directory full of deprecated drafts, unstructured notes, “versioned” files, maybe even some sample code. Now the AI is confidently generating output based on requirements from three years ago, and maybe Wednesday’s lunch order.

The AI users assume a better foundation model or highly complex prompt engineering will fix output inaccuracy. They will not. According to the research paper A Comprehensive Taxonomy of Hallucinations in Large Language Models, hallucinations are not merely a bug, but a theoretically inevitable feature of computable LLMs, irrespective of architecture or training.

You cannot patch out hallucinations with a clever system prompt. You have to restrict their oxygen.

Generative AI operates entirely on the context it is fed. When you open a workspace (or upload a zip file, or point it at SharePoint), the model uses the folder structure to understand relationships. It assumes every file in the provided directory is equally valid, current, and relevant.

To get faster, accurate output, you must adopt a standardized, hierarchical folder taxonomy. This is not a housekeeping chore. It is a strict data contract for your AI. The academic consensus supports this structural approach. As outlined in A Systematic Framework for Enterprise Knowledge Retrieval, transforming a static blob of data into a navigable, context-rich knowledge architecture significantly improves model accuracy and reduces retrieval latency.

The Prep Station Metaphor

Think of an LLM as a highly skilled line cook with zero short-term memory. If you ask the cook to make an omelet, but point them to a kitchen counter where the fresh eggs are mixed in a pile with old receipts, bleach, and rotten produce, the resulting meal will be toxic.

You have to prep the station before you ask for the work.

This requires changing how you manage your local environments. You must segment your files and organize your folders explicitly by client, project, or (and sometimes “and”) specific activity. When the AI opens that specific folder, the taxonomy forces it to focus strictly on the given task.

The Micro-Macro Data Contagion

Local file structures often mirror enterprise data architecture. If your team’s shared drive is a chaotic dumping ground of nested, unnamed folders, your enterprise data lake is likely more of a content swamp.

Organizations often fund massive, top-down enterprise data transformation projects. They deploy tools to wrangle petabytes of unstructured data. Consultants are brought in to describe how it should be done, walk you through clean up, and leave you with a perfectly indexed wiki on how to maintain it.

The reason other organizations don’t do this kind of clean up? Aside from the few that don’t need it, the rest have someone recruited from an organization that did need it, then did it…then did it again a few years later. At least some had the excuse of acquisitions as a cause. The rest just forgot to make being organized part of the organization’s culture.

The report What Is Data Taxonomy? Use Cases & Best Practices points out that taxonomy programs do not fail because the classification structure was wrong. They fail because nobody owned it after launch, or the controlled vocabulary was written for data engineers rather than the business users who needed to adopt it. A taxonomy that nobody actively owns becomes outdated within twelve months.

If you build a pristine enterprise knowledge graph but your teams still save raw client notes to a local desktop folder named “Misc”, your clean data architecture will erode. Bad habits always defeat good infrastructure.

Start locally. Expand globally. Treat your team’s shared folder as the training ground for enterprise AI.

Here is the implementation baseline for engineering a reliable folder taxonomy.

  1. Force Local Discipline: The guide Document Taxonomy Simplified notes a critical reality: AI can read full text, but without consistent indexing and classification, it has a harder time understanding which documents are current or relevant for a specific question. Humans must define the taxonomy. Organizations that rely solely on AI risk amplifying bad data.
  2. Build a Strict Domain Hierarchy: Segment folders strictly by project and lifecycle status. Your AI should never have read access to a “Drafts” directory when you are asking it to write production documentation.
  3. Establish the Data Contract: Metadata like document type, owner, client, date, and status tells AI not just what a document says, but how it should be used. This context improves AI ranking and reduces irrelevant hits that happen to share keywords.
  4. Separate Human and AI-Native Formats: Segment your directories into files meant for humans and files meant for the AI. Lean towards using markdown files, text files, and CSV files for AI consumption. Keep heavy, formatting-rich files in a separate reference folder that the AI does not scan unless explicitly commanded.
  5. Isolate Contextual Boundaries: Open-ended prompts can generate answers that blend multiple disciplines or outdated content. When your library is indexed by department, project, and lifecycle stage, AI can narrow its focus and answer questions within the right slice of your information.

You’ll note that there is a lack of solid reference examples of good taxonomies. This is, again, related to data cleanliness being driven by culture. The same taxonomy may or may not work for another organization. But a solid taxonomy based on how the organization thinks and processes can easily be maintained through training, communication, and the occasional reminder (preferably automated).

The ROI of a strict folder taxonomy is immediate. Output precision goes up. Token waste goes down.

If your AI is only as reliable as the context it receives, your unstructured file storage is an active threat to your workflow. Build the hierarchy locally. Clean up the directories.

Credit to Dylan Davis‘s video 5 Changes That Make ChatGPT & Claude 10x Better for sparking this research.

If you found this interesting, please share.

© Scott S. Nelson

Windows 11 Policy Gremlins

Scott S NelsonLeave a comment
Remember the movie Gremlins? A friendly creature that if you fed it after midnight, all heck would break loose and humans would be left to clean up the mess in the morning.
Despite setting all of the basic configurations to the contrary, Windows 11 occasionally reboots after an update on its own. It restores all of the running windows afterward in an attempt to hide this from users. Sometimes it fails on the restart, and I have to dig my laptop out from under the monitor stand where it is connected to everything via a USB dock. Other times it succeeds and most users wouldn’t notice. I, on the other hand, have a massive amount of data and virtual machines collected over 34 years of Windows versions (and another 6 of DOS and whatever the original Mac OS was), all of which reside on encrypted external drives, and there is only one reason they will all have been disconnected: a stealthy reboot.

Step 1: Spot the Sneaky Restart in Event Logs (Skip the Freezing GUI)

Event Viewer sounds official, but it freezes like molasses when filtering big logs. Don’t bother with it—use PowerShell instead (search “PowerShell” → Run as Admin).
First command to check for crashes/power losses:
PowerShell
Get-WinEvent -FilterHashtable @{LogName='System'; Id=41,6008} -MaxEvents 20 | Sort-Object TimeCreated -Descending | Select-Object -First 1 TimeCreated, Id, LevelDisplayName, Message | Format-List
  • What it does: Looks for “dirty” shutdowns (ID 41 or 6008). No results? Good news—your restart was “clean” (planned). (Mine showed nothing, so not a crash.)

Step 2: Dig for the Real Story with Broader Boot/Shut Logs

No crash? Check all reboot clues:
PowerShell
Get-WinEvent -FilterHashtable @{LogName='System'; ID=12,13,1074,6005,6006,6009} -MaxEvents 10 | Sort-Object TimeCreated -Descending | Format-Table TimeCreated, Id, LevelDisplayName, ProviderName, Message -Wrap
  • Key IDs: 1074 reveals who restarted (e.g., “TrustedInstaller.exe… Operating System: Upgrade (Planned)”).
  • The Culprit: TrustedInstaller (Windows Update’s installer) often forces an “upgrade” reboot. (Mine hit at 10:51 PM—classic move.)
Bonus quick boot time check:
PowerShell
Get-CimInstance -ClassName Win32_OperatingSystem | Select-Object LastBootUpTime

Step 3: Lock Down Future Restarts (Microsoft’s Hidden Maze)

Your BSOD “no auto-restart” setting? Useless here. Windows ignores it for updates. Time for the real fixes.

Quick Registry Shield (Copy-Paste PowerShell as Admin)

PowerShell
New-Item -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" -Force
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" -Name "NoAutoRebootWithLoggedOnUsers" -Value 1
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" -Name "AlwaysAutoRebootAtScheduledTime" -Value 0
gpupdate /force
  • Why it works: Tells Windows “Don’t reboot if I’m logged in.” Verify with Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU".

Pro GUI Version (gpedit.msc)

  • Run gpedit.msc → Computer Config → Admin Templates → Windows Components → Windows Update → Manage end user experience.
  • Enable Configure Automatic Updates → “2 – Notify download/install”. (This stops the OS from making decisions for you.)
  • Enable Turn off auto-restart during active hours → Wide hours (e.g., 6 AM–11 PM).
  • gpupdate /force.

Nuclear Option: Tame Update Orchestrator

  • services.msc → Update Orchestrator Service → Startup: Disabled → Stop.
  • No sneaky scheduling anymore (updates still work manually).

Why Microsoft Makes This So Hard (Minor Rant)

I get why the default configuration reboots on its own. Most users will never bother to check updates on their own, and if they are installed automatically but require a reboot, the message will be ignored by the general populace until the next upgrade. Anytime a non-technical friend or family member brings me a device that is giving them problems, finishing an update fixes it 92.8% of the time. But…

There’s a bunch of us nerds who came up from our basements (or down from the attic, in my case) and still want fine control over our own equipment without having to spend 4 hours on Google (or Gemini, or Claude, or…you get the idea). Or blowing up a movie theatre.

If you found this interesting, please share.

© Scott S. Nelson