What 105 AI experiments taught me

What the data actually say, and what I didn't expect to find

The bug wasn't new. Claude reintroduced in v30 exactly what it had just fixed in v29.

This tracking tool, the one behind every number in this post, isn't code I wrote. I asked Claude to build it, ran each version against my real files, and reported back what broke. That's the whole loop: it writes, I test, I tell it what's wrong, it revises. Iteration by iteration.

Somewhere in that loop, one bug turned up three separate times wearing three different disguises. I'd added a column to my tracking spreadsheet, and the code had three different places that needed to know about it: one to read data, one to write it, one to figure out which version of the spreadsheet it was looking at. Claude fixed the first. Then the second. It took a third pass, a week later, to catch the last one.

Same bug, three disguises, three iterations before it was actually squashed. Claude didn't remember catching it the first two times. I did.

I've been running AI experiments since April 2025, systematically enough to track them. As of June 2026, I've got 105 projects across 7 AI tools: Claude, ChatGPT, Gemini, Copilot, NotebookLM, Otter, Perplexity.

Most of what gets written about AI productivity is anecdote dressed up as insight. I wanted my own numbers. Here's what they say.

More than coding

That opening bug story is a coding story, and it would be easy to assume this whole dataset is about coding. It isn't. 105 projects sounds like a big number, but the mix behind it might be the more interesting one. Coding is the largest single category, at 20 projects, but it's less than a fifth of the total.

Type	Count	Example
Coding	20	Transcript Editing Tool (ChatGPT, 40 iterations)
Document editing & review	16	Firepit project (ChatGPT, 3 iterations)
Blog editing	11	Blogpost - Don't Wing It (Claude, 5 iterations)
Admin	10	Convert Bank Statements (Claude, 11 iterations)
Report	10	Life Insurance Options (Claude, 22 iterations)
Research	8	AI Impact on Jobs (Claude, 2 iterations)
Creative	7	Birthday eCard Video Game (Claude, 24 iterations)
Presentation	6	Alaska Tour (ChatGPT, 8 iterations)
Persona/voice projects	4	Ask Grandpa chatbot (NotebookLM, 9 iterations)
Personal	3	Credo, Values & Goals Update (ChatGPT, 13 iterations)
Product comparison	3	Dishwasher Comparison (Claude, 4 iterations)
Advising	3	Interview Practice (ChatGPT, 2 iterations)
Analysis	2	Chat & Project History (Gemini, 6 iterations)
Health	2	Health Data Conversion (Claude, 3 iterations)
Total	105

 

That range is its own finding. AI as a co-pilot shows up everywhere I let it in: a Christmas vCard, a fund proposal, a mentoring analysis, alongside the coding work. The rest of this post drills into a few specific examples, coding especially, because that's where the iteration counts get interesting. But the breadth matters before the detail. Most of what I do with AI isn't code.

What this dataset is, and isn't

One honest caveat before the numbers: this is one person's work.

105 is every AI project I did and saved, not a sample I picked from a larger pool. The selection happens upstream of that: which tasks I decided were worth bringing AI into in the first place, and whether the session left a file behind. A quick one-off question I didn't save doesn't exist in this dataset.

I'd treat these numbers as one careful person's pattern, not a population average. Your mileage will vary with what you use AI for and how you work.

The number that surprised me

The table above gives a glimpse of the range project to project, but the full spread is wider than any single row shows. Before I ran this, if you'd asked me the typical number of AI iterations to get something usable, I'd have guessed high. AI is capable, but it's incomplete, and getting from draft to done takes work.

Iterations ranged from 1 to 68.

That range is the real finding. A one-shot win and a 68-round project both count as "a project" in this dataset, and no single average captures what that spread means. The median is 4: half of my 105 projects wrapped in 4 rounds or fewer. The mean is 9.4, pulled upward by a handful of long projects.

Coding is where the range opens up. Coding projects average about 21 iterations. Everything else averages about 7. The clearest run-check-revise example is a Transcript Editing Tool, built with ChatGPT, to catch the repetitive fixes in my weekly Data4Good transcripts: correcting member names, product names, the same edits week after week. It took 40 rounds to complete.

So, the first thing the data says: it depends on what you're asking AI to do. Most knowledge work converges fast. Coding can be a long haul.

Why coding is different

That range doesn't come from bad prompting or a bad model. It's what coding actually requires: run it, test it, report back what's wrong, get a revision, uncover the next problem, repeat.

There's also a memory problem. AI memory is scoped to a single chat. As long as I stay in the same project chat, it can recall earlier versions. Start a new chat, even the next day on the same project, and I'm re-briefing from scratch. Even carrying context over myself means copying and pasting from the old chat into the new one.

I have to re-brief it. That's exactly what happened with the column-offset bug from the opening: I was the one who remembered catching it before, not Claude.

That's just where coding assistance is right now.

Working across AIs

There's something the iteration counts miss. Projects don't always stay in one AI. Looking back at the data, I combine tools within a single project in a few distinct ways.

•       Playing to strength. Different AIs are better at different things, and I'll use more than one in the same project. My Christmas video card is the clearest example: image generation in ChatGPT, storyboarding in PowerPoint with Claude, 18 iterations combined.

•       Critique and improve. I'll take one AI's code or output and hand it to another AI to review, tighten, or catch what the first one missed.

•       Switching when one struggles. Sometimes an AI just isn't working out on a project, so I'll move the whole thing to a different tool.

•       Cross-checking. Feeding one AI's answer to another is a form of fact-checking, or at least assumption-checking. It's a habit I recommend to my students. A second opinion is one prompt away.

None of this shows up in a single project's iteration count. It's part of the real workflow behind these numbers.

The time question

Here's the finding people pushed back on hardest when I shared an early draft: in my own rough sense of it, many AI-assisted projects took 3 to 4 times longer than if I'd just done them myself, without AI.

I want to be honest about that number. I didn't use a stopwatch for every session. It's an impression from watching myself work, not a precise measurement, and I'd treat it as directional.

But if it's even roughly right, it says something. For a lot of routine tasks, iterating with AI can take longer than just doing the work yourself. A key example is project #56, the Transcript Editing Tool.  By the time it took to get the program right (40 iterations, to be precise), I could have edited the doc a dozen times. In the end, I abandoned it: it rarely got all the edits right, and I've been correcting the transcripts by hand ever since. I've filed that one under learning experiences, not productivity wins.

Where AI earns its keep for me is capability. Coding is where this shows up clearly. I'm not a developer. I don't write Python code. Many of the project results exist because AI built them with me. That's capability I didn't have, and it's worth more to me than any hours saved.

Time-saver versus capability-extender. That distinction shapes what I hand to AI and what I keep for myself.

AI use compounds

One thing I didn't expect going in: using AI more makes you use it more.

My project pace nearly tripled over the 14 months I've tracked, from about 4 projects a month in early 2025 to 10 to 12 a month by early 2026. Part of that is speed. Most of it is habit. I got better at spotting when AI was the right first move, and the better I got, the more often I reached for it.

I wrote about this a while back as the conversational approach to AI [1]: treat it like a working session with a colleague, not a query to a search engine. The skill grows with practice, and practice compounds.

The human never left

105 projects. Zero ran start to finish without me in the loop.

I don't think the next model release closes that gap, because none of this is really a model-capability problem. AI can't see my file system unless I give it access, and I'm not willing to give it that kind of blanket access. That's my boundary, regardless of how good the model gets. It can't check its own facts against sources I haven't given it. It can't hold context across sessions without a re-brief. And it can't tell me when a result is wrong in ways specific to my world: a formula error in a financial model, a missing source in a research summary, a chart with the wrong axis, a blog post that reads like AI wrote it. That takes knowing my world. No model upgrade changes that.

The human is in the loop because that's where the judgment lives.

AI as co-pilot is still the right frame for me. AI makes me sharper. But I'm still the one who decides where we're going and when it's right.

Will Agentic AI change any of this?

I want to flag this one as speculation, not data. Nothing in my dataset covers agentic AI yet, because I haven't run enough agentic projects to say anything real.

My hypothesis: coding projects built on a run-check-revise loop, run it, test it, report back what's wrong, revise, repeat, will look the same whether the AI acts autonomously or waits for me at each step. The loop doesn't change. Only who triggers each round does.

I'll write about this properly once I have real agentic projects in the dataset instead of a hypothesis.

What I'd tell someone starting out

Here are my top 6 recommendations based on my 105 trials:

1.     Start with projects that need a lot of iteration: coding, detailed reports, financial models, multi-round research. These expose limitations fast and build your instincts faster than one-shot tasks ever will.

2.     Version your output files from day one. v1, v2, v3. It's a record of how the work evolved, and it happens to make iteration counting automatic if you ever want to track this the way I do. That also means asking for output files as you go, so you keep the history and the code you tested.

3.     Track your experiments, even in a plain spreadsheet. You can't see the patterns until you look at them together, and that's where the real learning is.

4.     Expect to iterate. Across 105 projects, iterations ranged from 1 to 68, with a median of 4. AI isn't a one-shot machine, and depending on what you're building, it might not be a four-shot machine either. Treating the first draft as the final one is the mistake I often see.

5.     Treat every session like a conversation. Pose the problem, see what comes back, add context, correct what's wrong, push on the weak spots. AI gets more useful as the conversation goes on, same as a colleague or research assistant does. [1]

6.     Match the tool to the task. If a project needs more than one AI can offer, use more than one. When the stakes are high, get a second AI's take before you trust the first answer.

One more thing

The dataset I just described was built using AI. The Python, the PowerShell file indexer, the fuzzy matching logic: all of it developed iteratively with Claude, ChatGPT, and Copilot. This tool is, in a sense, all the other 104 projects looking back at themselves.

That's the part I find most interesting about running an experiment like this on myself. You're not just using AI. You're watching, from the inside, how it actually works on something that matters to you.

If you're doing anything like this yourself, tell me about it in the comments. And if you'd like a copy of the dataset, leave a note there too.

[1] See "You Are Your Career Pilot. AI Is Your Copilot," Blogpost, Feb. 26, 2026, https://eghapp.blogspot.com/2026/02/you-are-your-career-pilot-ai-is-your.html

Full disclosure: I used Claude to help draft this post, drawing from my AI Experiments Analysis Report (v5, June 2026) and 14 months of project notes. I provided the outline and edited the final copy. Another collaborative use of AI.

The postings on this site are my own and don't necessarily represent positions, strategies or opinions of any of the organizations with which I am associated.

Why We Present

The hidden returns of preparing a formal presentation

Marshall McLuhan famously said decades ago that the medium is the message.[1] I found that true again in coaching the Data4Good team through a recent presentation. What struck me was not what we delivered to the audience, which was good. It was what the process of preparing to present delivered to us.

I have given a lot of presentations over the years and coached a lot of people through theirs. What I keep relearning is that the returns are not limited to the day you give it. Most of the value accrues before you step in front of the room.

Here are six things I observed from watching the team prepare.

1.  A Hard Deadline Forces Things Done

There’s a management truism I’ve always believed: work expands to fill the time available, and important-but-not-urgent work never gets done without a forcing function. A presentation deadline is one of the best I know.[2]

In preparing for this one, the deadline moved things off the backlog that had been sitting there for weeks. Code got deployed to staging. Repositories got organized. Pages went live. Multiple items were explicitly deferred until after the presentation, which tells you exactly where all the urgency was going. The presentation did not just showcase the work. It got the work done.

2.  Preparation Is a Quality Review in Disguise

You don’t really know what you’ve built until you try to explain it to someone else. I’ve seen this enough times that it no longer surprises me, but it still impresses me.

In rehearsal the team caught things they had not noticed from the inside. Demos that were missing some features. Web pages that were not up-to-date. Technical details that made sense to the builders but would land as noise for a practitioner audience. I found myself asking on nearly every slide: what is the one sentence a listener should take away? That question sounds like presentation coaching. It is. But it is also a product question. If you cannot answer it for a slide, you probably cannot answer it for the feature.

Rehearsals feel like preparation for the presentation. They are actually a quality review of the work.

3.  Real Audiences Build Real Skills

We gave every team member a speaking role, each presenting their own section. The intent was deliberate: everyone having a speaking role is representative of how we work in our team.

For students and early-career volunteers, the difference between presenting in a seminar and presenting to a professional audience is higher stakes. A working group of experienced practitioners is not an audience of peers. They have opinions, real-world experience, and they ask hard questions. You do not build that skill by preparing to present. You build it by presenting.

4.  Each Deck Builds the Library

Presentations are not one-and-done deliverables. They are assets. I have been saying this to the team for a while, and I think it has proven true to us anew.

Each new deck links back to prior ones. Slides get borrowed, refined, and reused. The diagrams, the who-we-are framing, the product overviews accumulate into what I think of as a slide library: a growing inventory of well-crafted explanations, demos, and frameworks that any team member can pull from. The work of one presentation makes the next one cheaper to build and better to deliver. This mirrors our building blocks approach to systems that I wrote about earlier.[3]

5.  Outsiders See What Insiders Miss

When preparing to present one product we are working on, we ran into a problem. The pitch we had been using did not land with our host. As we pressed on why, we realized the framing was too narrow. It described one application of the tool but missed what the tool actually does at a more general level.

We got there by having to explain the product to people who were not in the room when it was built. Outsiders ask the questions insiders miss. The team came away with a clearer understanding of their own work than they had going in.

6.  The Audience Becomes an Advisory Board

A small volunteer team rarely has a formal advisory board, a product council, or a user research budget. What it does have, every time it presents to a group of experienced practitioners, is a room full of people with ideas and opinions.

We designed the Q&A and brainstorming sections specifically to surface that feedback, priming the audience with a question before opening the floor, not to plant an answer but to plant a direction. In one session we got more input on our product direction than from months of internal discussion. A formal presentation, structured well, is a feedback mechanism. The audience does not know it is serving as an advisory board. But it is.

The Preparation Is the Message

McLuhan’s insight was that the form of communication shapes meaning as much as the content. The same is true here. The act of preparing a formal presentation shapes the team, the work, and the thinking, independent of how the presentation itself goes. The deadline, the rehearsal, the library-building, the product insight, the feedback loop: all of it happens before anyone enters the room.

If your team is doing good things and not presenting them formally, you are leaving most of the returns on the table.

Have you found this in your own team? I'd be curious to hear.

Full disclosure: I used Claude to help draft this post, drawing from team meeting transcripts and my own notes. I provided the outline and edited the final copy. Another collaborative use of AI.

The postings on this site are my own and don’t necessarily represent positions, strategies or opinions of any of the organizations with which I am associated.

---

[1] Marshall McLuhan, “Understanding Media: The Extensions of Man,” Kindle Edition, 2013, 1964, https://www.amazon.com/Understanding-Media-Extensions-Marshall-McLuhan-ebook/dp/B00DIEZI7U/

[2] Christopher Cox has written about this in "The Deadline Effect: How to Work Like It's the Last Minute—Before the Last Minute", Kindle, 2022, https://www.amazon.com/Deadline-Effect-Work-Minute-Before-Minute-ebook/dp/B08LDVGYDD/

[3] “The Lego Approach,”  Dec. 10, 2025, https://eghapp.blogspot.com/2025/12/building-blocks-lego-approach.html

Click Bloat

A 50-year-old principle from Bell Labs, and what your iPhone keeps getting wrong

At one of his seminars, I heard Brian Kernighan of Bell Labs fame say, that the purpose of computing is the conservation of typing.[1] I took that to heart during my development days, and it shapes how I think about technology to this day.

Which makes what I’m seeing now all the more frustrating. We’ve moved from keyboards to touchscreens, from typing to clicking, but the principle should have traveled with us. Conservation of typing should have become conservation of clicks. Instead, with every new iOS release, it seems to take more clicks to do what used to take fewer. I’ve started calling it click bloat: the quiet accumulation of extra steps that creeps into our devices with each update, usually unannounced and rarely acknowledged.

Let me give you three examples from my own recent experience.

Reading email on my iPad.

In the old layout, a simple < icon let me back out of a message in one click. Now there’s a three-part icon. You click to open it. You click the X, not the <, to close the email. Two clicks instead of one. Is there a setting to restore the old layout? I looked. There isn’t. Classic click bloat.

Picking up the NYT puzzle mid-game.

I usually start the daily crossword on my iPhone and finish it on my iPad, or vice versa. The app syncs well enough, at least it looks that way. Here’s my five-click adventure to simply resume where I left off: open the game board (1), select “Resume” (2), only to find a blank board, none of my answers in sight. So, I close the game (3), reopen it (4), and select “Resume” again (5). This time, mercifully, the words have synced. Five clicks to get back to where I already was. I suppose I should be grateful it didn’t ask me to upgrade my account!

Hiding options as a method of promoting new ones.

I explored this one at length in my last post, and it still bothers me. Here’s the pattern: a new release arrives, and somewhere in the shuffle, a button you’ve clicked a thousand times has quietly moved, or vanished entirely, to make visual room for something the designers want you to notice. Your muscle memory is now wrong. You go hunting. You feel, briefly, like a confused newcomer on your own device. The feature isn’t gone, of course. It’s just been demoted, tucked behind an extra click or two. Which means, yes, more click bloat, dressed up as innovation.

I genuinely understand the pressure to ship new features with most releases. But adding features while quietly inflating the click count on things people already knew how to do isn’t progress, it’s a trade-off the user never agreed to. Are the UX designers even tracking this? Are they measuring click counts against previous versions? Somewhere along the way, the user got left out of that conversation.

Kernighan’s principle was elegant precisely because it was measurable. How many keystrokes did this save? We should be asking the same question about every new release: how many clicks did this add, let alone save? If the answer is more than zero, someone owes the user an explanation. Click Bloat is real, and it’s time we started calling it out by name.

So what can you do about it?

Start by leaving feedback: most apps have a built-in mechanism for it, usually tucked somewhere in Settings. If the bloat is coming from your device’s OS, find your way to Apple’s or Google’s feedback channels. And if the culprit is an Amazon app? Well, good luck. I mean that sincerely. Navigating their customer feedback labyrinth may itself be the finest example of Click Bloat you’ll ever encounter.

And then there’s the brave new world of AI assistants. Try telling ChatGPT that you’d like to pass some feedback along to the development team. It won’t. Instead, you’ll click the thumbs down icon (intuitive, right?) and then manually copy and paste the relevant portions of your conversation into a feedback form. In 2026, that’s how you reach the people building the future. The irony writes itself.

But try anyway, all of it, because the only way UX designers hear that this matters is if enough of us say so, loudly and repeatedly.

---

[1]The quote is commonly attributed to Bell Labs folklore, possibly originating with Rob Pike. It echoes Richard Hamming’s earlier remark that “the purpose of computing is insight, not numbers,” documented in Numerical Methods for Scientists and Engineers (1962).

Full disclosure: I used Claude to help draft this post, drawing from my notes. I edited the final copy you are reading. Another collaborative use of AI.

The postings on this site are my own and don't necessarily represent positions, strategies or opinions of any of the organizations with which I am associated.

A Lesson in UI (and IT Leadership)

Over the course of my career — and especially in the years since — I’ve been reminded that technology succeeds or fails not because of features, but because of how well it supports the way people actually work. Tools should reduce friction, not introduce it.

This week I ran into an example worth sharing.

Microsoft recently rolled out a new UI for the Edge browser. On the surface, it’s a cosmetic refresh. But for those of us who move between browsers as part of our daily workflow, the impact is more than visual. UI consistency isn’t about preference; it’s about productivity. When the layout shifts, when familiar controls move, when customization options disappear, the cost shows up in small but persistent interruptions to users’ workflow.

The previous Edge UI aligned well alongside Chrome, making it easy to switch between the two. The new design breaks that continuity. More concerning is the removal of options to tailor the interface, something power users have relied on for years. And the new menu structure feels deeper and less intuitive, making simple tasks harder to find.

These may seem like small changes, but they add up. Edge had been evolving into a strong, productivity-focused browser. This latest shift feels like a step away from that trajectory.

My hope is that Microsoft will revisit these decisions and re-engage with the needs of the people who depend on these tools every day. Flexibility, clarity, and respect for established workflows matter, especially for those of us who have spent decades building and supporting systems where usability is not an afterthought.

If you’ve noticed similar changes in the tools you rely on, I’d be interested in hearing about your experience and perspective.

This article was also posted on LinkedIn, here: https://www.linkedin.com/posts/edward-g-happ_microsoftedge-userexperience-productivity-activity-7451296572933378048-b6h9 

Full disclosure: I used Copilot to help draft this post, drawing from an interactive session we had about trying to restore my original Edge settings. I edited the final copy you are reading. Another collaborative use of AI.

The postings on this site are my own and don't necessarily represent positions, strategies or opinions of any of the organizations with which I am associated.

Don’t Wing It. Matrix It.

A 30-year-old decision tool showed up in last week’s team meeting, and it’s more relevant now than ever

Last Monday morning, one of our graduate team members at the Data4Good Center was walking us through the hosting options for two AI projects we’re building. He had done his homework. He’d evaluated four different cloud platforms, dug into their free tiers, compared their GPU access, tested their startup times, and mapped out the cost implications of each. He was articulate and thorough.

And he was stuck.

The problem wasn’t a lack of information. It was too much information pulling in too many directions. One platform had generous free resources but was nearly impossible to get allocated. Another had faster provisioning and better GPU integration but a stingier free tier. A third was simple and cheap but possibly not powerful enough. A fourth had the right capabilities but startup times that would drive users away.

Cost. Performance. Speed. Complexity. User experience. Every option was strong on some factors and weak on others. And we’re a volunteer team of students and graduates with a budget measured in double digits per month.

I listened to all of this and thought, I wrote an article about exactly this problem. In 1996.

A Bulletin from Another Century

In the mid-1990s, my brother and I ran a consulting company called HPMD, and we produced a series of short management articles for our clients called HPMD Bullets. Number six was titled “Values Clarification,” and the premise was simple: when you have a complex decision with competing factors, don’t wing it. Build a matrix.

The technique was borrowed from the social sciences [1].  You list your decision factors as rows and your options as columns. You weight each factor by importance. Then you rate each option against each factor, multiply, and add up the columns. The option with the highest weighted score isn’t necessarily the answer, but it clarifies the decision in a way that gut instinct alone cannot.

The original article walked through three examples: choosing between job offers, hiring candidates for a product manager role, and selecting a vendor. Different decisions, same technique. That was the point.

Back to Monday’s Meeting

So, I suggested to our team member that he build a decision matrix. List the factors that matter—cost, GPU availability, startup time, system complexity, ease of integration—as rows. List the platform options as columns. Weight the factors. Rate each platform. Do the math.

The conversation that followed was more interesting than the matrix itself. Romanus, who co-leads our team, said that when he presented technology decisions to senior management, arriving with a weighted matrix was almost more valuable than arriving at the right answer, because the matrix showed how you worked through the decision. It gave leadership a way to follow your reasoning and challenge your assumptions. “We should use Platform X because it’s better” is not a conversation. It’s an assertion.

He also made a point about failure: when a decision turns out to be wrong, the matrix lets you go back and ask what happened. Was the premise flawed? Did you weight something incorrectly? Miss a factor entirely? You can’t do that retrospectively without documentation. As Romanus put it, it’s just good management hygiene.

What I’d Add Thirty Years Later

First, make it a team exercise. When a team argues about whether GPU access should be weighted higher than system simplicity, that argument is itself the point. The matrix gives structure to a discussion that otherwise devolves into everyone advocating for their preferred option.

Second, use it for project triage. We’re preparing for a presentation to the NetHope Impact Data Working Group in May, and that deadline means we need to decide what’s in the demo and what gets pushed to phase two. List the candidate features as rows. Weight them by impact, feasibility, and readiness. The features with the highest scores are your phase one. In crisis response, we call this triage.

Third, and this is the 2026 addition, use AI to help build the matrix. Describe your decision to Claude or ChatGPT. Ask it to suggest factors you might be missing. Ask it to challenge your weightings. The AI won’t make the decision for you, but it can help you think more completely about the problem. This is another instance of what I call the conversational approach to AI: not asking for an answer but using the back-and-forth to sharpen your own thinking.

A Skill Worth Practicing

I told the team something I believe strongly: every technology person should have practice with this technique. Whether you’re choosing cloud platforms, evaluating AI tools, deciding which features to build first, or sorting out your own career options, the discipline of listing your factors, weighting them honestly, and rating your options is one of the most practical management skills I know.

It requires some brainstorming, honest assessment, a spreadsheet, and the willingness to let the math challenge your assumptions. That’s it.

The original 1996 Values Clarification article and a blank Excel template are available for the asking. If you’d like a copy, send me a note at ehapp@data4good.center.

Have you used a decision matrix in your own work? What factors do you find hardest to weight? I’d love to hear from you in the comments.

[1] The values clarification method was developed by Louis Raths, Merrill Harmin, and Sidney Simon, and published in their 1966 book Values and Teaching: Working with Values in the Classroom. I first encountered it during a student internship at Planned Parenthood in the 1970s, where it was used to help clients work through personal decisions. The weighted matrix I describe here is my adaptation of their framework for technology and management decisions.

Full disclosure: I used Claude to help draft this post, drawing from a D4G team meeting transcript, the original 1996 Values Clarification bulletin, and my own notes. I provided the outline and edited the final copy you are reading. Another collaborative use of AI.

“The postings on this site are my own and don’t necessarily represent positions, strategies or opinions of any of the organizations with which I am associated.” 

You Are Your Career Pilot. AI Is Your Copilot.

What a 25-year IT career transition taught me about AI, conversations, and standing out in a changed job market

A colleague reached out to me recently. After nearly 25 years at a major international humanitarian organization, his position was being eliminated in a restructuring. He is not a junior person. He is a seasoned enterprise architect with PMP, CISA, and ITIL credentials, and a career that spans infrastructure, cloud migration, ERP programs, and data architecture on a global scale.

His question, between the lines, was the same question a lot of experienced IT professionals are sitting with right now: where do I fit and what are my options?

We had a good conversation. Here is what I shared with him.

The Job Market Has Changed. So Has the Competition.

Here is what is actually happening in hiring right now: it is often AI talking to AI. Candidates are using AI to generate resumes and cover letters. HR systems are using AI to screen and rank them. By the time a human being gets involved, you may already be in or out of the pile.[1]

That creates a trap. If your resume looks like an AI wrote it, and the screener is AI, you will score like everyone else who used AI. You will be generic. You will be invisible.

The way out of that trap is the same principle that has always applied in marketing: long copy sells. Tell a story. Not a list of job duties. Not a summary paragraph full of keywords. A story: here is a problem I faced, here is what I did, here is what happened as a result. What did the organization gain? What did you learn? That kind of resume stands out precisely because most submissions do not have it.

The question to ask yourself is: what can only I say? What is in my experience that no one else can claim? Find that, and build your materials around it.

AI Fluency Is Now a Baseline. Build Your Credentials.

Every organization I follow right now is either adopting AI or scrambling to figure out how to. And the ones further along are discovering a surprise: AI takes more supervision than they expected, not less.

In my own experiments, which now number more than 50 projects since last summer, technical work typically takes more than six iterations to get right. The AI is capable. But it needs direction. It needs someone who can frame the problem, evaluate the output, catch the wrong turns, and keep the project on track.

That is the skill I call orchestration. Not coding. Not prompting tricks. The judgment to know when the AI is going in the right direction and when to redirect it. That kind of judgment comes from experience. You have experience.

But here is the practical reality: you also need to signal AI fluency on your resume, because every job description now asks for it. The good news is that credentials are available, many of them free or nearly free.

Where to start:

Google AI Essentials on Coursera is a solid entry point. Microsoft Azure AI Fundamentals (AI-900) is relevant if your background includes infrastructure or cloud. For those in data architecture, Retrieval-Augmented Generation (RAG) architecture is worth understanding: it is the design pattern of combining your own data with an LLM to produce outputs grounded in your specific context, and it is already standard in enterprise AI deployments. A course in prompt engineering also signals that you understand how to direct AI effectively, which is what orchestration is at its most practical.[2]

Take the class. Get the certificate. Put it on your resume and your LinkedIn profile. These credentials tell a hiring manager that you are not just familiar with AI in the abstract; you have done the work to understand it and apply it.

Treat AI as a Conversation, Not a Search Engine.

This is the insight I find myself repeating most often, to my students, to colleagues, and now to anyone navigating a career transition with AI as a tool.

Most people approach AI the way they approach Google: type a query, get an answer, move on. That approach produces mediocre results, because the AI does not have enough context, and you never give it the chance to develop any.

The better approach is a conversation. Pose the problem. See what comes back. Add context. Make comments. Correct what is wrong. Ask a follow-up. Push on the weak spots. The AI gets more useful as the conversation develops, just as a colleague does on a team when you are working through a problem together.

I have applied this directly to my own writing. I loaded samples of my own writing into Claude, Gemini and ChatGPT and said: analyze my voice. What patterns do you see? The AIs identified three distinct writing modes I use depending on the context. Now, when I want to draft something, I can say: write this in my voice, mode one (which is how I write blog posts). The output sounds like my blog posts, not like an AI template.

You can do the same with your resume, your LinkedIn profile, your cover letters. Load your own writing. Ask the AI to model your voice. Then use that voice in everything you send out.

The Shadow IT Problem Is a CIO-Level Insight.

My colleague and I also talked about something that I think is worth naming directly for anyone positioning themselves for a leadership role.

Many organizations believe they have AI governance under control. They have approved tools, usage policies, token limits, data handling rules. And yet employees are regularly working around all of it. Loading data into personal accounts. Using consumer AI tools from home. Emailing themselves results. I know this not from research but from direct experience with my family and friends.

Governance by restriction does not work when the tools are this accessible. The better frame, one I borrowed from an old political saying about keeping people inside the tent, is to build a bigger tent. Get the experimentation inside the organization where you can see it, learn from it, and harvest what works. If people are going to experiment with AI regardless, and they are, the organization is better served by knowing about it and talking about it.

If you are going into an interview for a senior IT or architecture role, having a clear point of view on this question sets you apart. Most candidates do not.

A Practical Plan for the Next 90 Days

If I were in transition right now, here is what I would focus on.

First, get AI credentials on your resume. Pick the one most relevant to your background and complete it. Do not wait until you have several. One, done, visible, is better than several in progress.

Second, load your own writing into an AI tool and ask it to identify your voice. Then practice using it. Your materials should sound like you, not like everyone else who used the same AI tool with no customization.

Third, rewrite your resume as a story. Not a duty list. For each significant role, answer: what was the situation, what did I do, what resulted? Specific outcomes, specific scale, specific impact. The AI screener and the human reader both respond to this.

Fourth, upgrade your LinkedIn profile and consider LinkedIn Premium at least during your active search. Pay attention to where you rank against other applicants for target roles. That is real signal.

Fifth, reach out personally to former colleagues, mentors, and advisors. Not a mass message. Individual notes. The human network still matters once you clear the AI screening stage, and you need someone who will say: I know this person, and I stand behind them.

One More Thing

My team at the Data4Good Center is building a tool called Career Lighthouse, designed specifically for professionals in transition, especially from the nonprofit sector. It does skill matching across industries and will eventually flag where a targeted course or credential closes the gap for a near-match role. We are not live yet, but we are close. Stay tuned.

In the meantime, the principle is the same whether you use Lighthouse, LinkedIn, or just a good conversation with a trusted advisor: your 25-year career has more range than your job title suggests. The skills transfer. The question is whether your materials make that legible.

AI is not replacing experienced IT professionals. But experienced IT professionals who know how to work with AI will replace those who do not. You are the pilot. AI is the copilot. Get comfortable in that seat.

What are you finding in your own job search? What is working, and what is not? I would love to hear from you in the comments.

Full disclosure: I used Claude to help draft this post, drawing from a recent advisory conversation, my own AI project notes, and D4G team discussions. I provided the outline and edited the final copy you are reading. Another collaborative use of AI.

 

Notes

[1] See Nino Paoli, “Trust is at an all-time low for both job seekers and recruiters’: Hiring platform CEO says talent acquisition is in an ‘AI doom loop’,” Fortune, November 18, 2025.

[2] Recommended starting points: Google AI Essentials; Microsoft Azure AI Fundamentals; Prompt Engineering for ChatGPT, Vanderbilt University; Google Career Certificates — AI. See the Resources section below for direct links.

 

Resources

AI Credentials

• Google AI Essentials (Coursera, free to audit): coursera.org/learn/google-ai-essentials
• Google Career Certificates — AI: grow.google/certificates
• Microsoft Azure AI Fundamentals (AI-900): Microsoft Learn
• Prompt Engineering for ChatGPT, Vanderbilt University (Coursera, free to audit): coursera.org/learn/prompt-engineering

 RAG Architecture Background

• IBM explainer on RAG: research.ibm.com
• AWS RAG overview: aws.amazon.com 

Job Search Tools

• Indeed Career Advice: indeed.com/career-advice
• LinkedIn Premium: linkedin.com/premium

Data4Good Center

• Career Lighthouse (coming soon): data4good.center

The postings on this site are my own and don’t necessarily represent positions, strategies or opinions of any of the organizations with which I am associated.

The Personas Project: Now on NotebookLM

An Update on the Evolution of AI-Powered Conversations

When I first introduced The Personas Project in October 2024, I shared my vision of using AI to create conversational access to decades of professional experience, teaching materials, and personal stories. The original implementation used AnythingLLM and Ollama—powerful tools that demonstrated the concept worked.

Since then, Google has significantly advanced NotebookLM with features that align perfectly with my "dinner conversation, not the library" philosophy. NotebookLM's Audio Overview podcasts, improved chat interface, and public sharing capabilities offer a more engaging and accessible experience for visitors.

The New Workspace Series

I'm rebuilding the Personas workspaces on NotebookLM, starting with:

1. "Ask the Professor" (available now) - Teaching materials, Crisis Informatics, and IT Leadership & Management insights
2. "Ask the CIO" (coming soon) - IT strategy, leadership, and professional experience
3. "Ask the DR Tech" (coming soon) - Disaster response technology and humanitarian innovation
4. "Ask Grandpa" (private, invitation-only) - Personal stories and family wisdom

Try "Ask the Professor" on NotebookLM

The new workspace brings together years of teaching materials from courses on Crisis Informatics and IT Leadership & Management. It includes classroom discussions, guest speaker insights, student perspectives, and practical applications of theory.

How to Get the Most from This Resource:

1. Start with the Audio Overview - Click Studio Audio button for the Audio Overview podcast. NotebookLM created an engaging 19 minute conversation between two AI hosts who synthesize the key themes. It's like listening in on a dinner conversation about the content—the perfect introduction.
2. Then explore through chat - After listening to the overview, use the chat to ask questions, dive deeper into topics, or explore connections between concepts.

Starter Questions to Try:

• What are the core principles of crisis informatics and how do they apply to disaster response?
• What lessons from IT leadership are most relevant for today's technology leaders?
• How can "conversations as a way of knowing" transform organizational learning?
• How can humanitarian disaster response lessons be applied to IT management?
• How do you build effective communication practices during emergencies?
• What are the key differences between managing technology and leading with technology?

Access "Ask the Professor"

NotebookLM Workspace: https://notebooklm.google.com/notebook/1217ce8a-eab1-48d5-a6aa-d94681487b76

You'll need a Google account to access the workspace. Viewers can listen to the podcast, ask questions, and explore generated content, but cannot edit the original sources.

Why NotebookLM?

The transition to NotebookLM offers several advantages:

• Audio Overview podcasts provide an accessible entry point that synthesizes complex material into conversational format
• Public sharing via simple links makes the workspaces easier to access
• Improved chat interface creates more natural, contextual conversations
• Generated artifacts like study guides, FAQs, and briefing documents offer multiple ways to engage with the content

What's Next?

I'll be releasing "Ask the CIO" and "Ask the DR Tech" workspaces in the coming weeks. Each represents a different facet of my professional experience and will serve different audiences—from IT leaders to disaster response practitioners to students.

"Ask Grandpa" will remain private, shared by invitation only with family and close friends who want to explore personal stories and family history.

Your Feedback Matters

Please try the workspace and share your thoughts. What works well? What could be better? Your insights help me refine this approach and determine whether it truly delivers on the vision of creating meaningful, accessible conversations with accumulated experience.

Let the conversation begin—this time, with better tools for the journey.

---

"The postings on this site are my own and don't necessarily represent positions, strategies or opinions of any of the organizations with which I am associated."