# Hyper-Team Software and Enterprise Dark Matter: A Visual Guide to Talk Python Episode 558

**Guide**: https://talkpython.fm/guides/558/hyper-personal-software-with-python
**Episode**: [Talk Python to Me #558: Hyper-Personal Software with Python](https://talkpython.fm/episodes/show/558/hyper-personal-software-with-python)
**Featuring**: Michael Booth (founder of DataBooth)
**Published**: October 23, 2026

**TL;DR:** Most software inside a company is small, internal and frozen: tools nobody understands and nobody dares touch. AI coding agents have collapsed the cost of building and fixing that kind of software, which opens the door to hyper-team software, small tools a team builds for itself. Michael Booth and Michael Kennedy walk through where it pays off (onboarding, UX polish, embedded databases, documentation), where it quietly goes wrong, and the guardrails that keep it honest.

Every company has one. The little internal tool that Jane built back in 2021, and then Jane left. Nobody understands it, and nobody touches it. Michael Kennedy, host of Talk Python, opened the episode with that story, along with the two unwritten rules that keep it frozen: if it's working, don't change it, and if you break it, you bought it.

That kind of software is everywhere, and almost none of it is visible. Kennedy calls it dark matter. For every app you can actually see, there are many more of these sitting in the shadows.

The idea behind this guide started as a pair of blog posts. Kennedy wrote about hyper-personal software, tools he builds for an audience of one with no plan to ever ship them. Michael Booth, a consultant who runs DataBooth, read it and riffed on it with an essay of his own, *From Hyper-Personal to Hyper-Team Software: Small Team-Built, AI-Assisted Tools Inside the Enterprise*. His question: what happens when a small team inside a big company takes the same approach?

Isn't this just another round of predictions about the end of programmers? Kennedy has seen plenty of those, from UML to drag and drop to low code and no code, and he doesn't think coding agents end software either. But he does think they're the biggest dent anything has put into it. Booth's caveat came early and stays relevant the whole way through: with all that speed, "sometimes you can just do a lot of bad things much faster."

This guide goes from the problem to the practice. It covers the dark matter itself and the rules that freeze it, why the honest comparison for an AI-built tool is usually nothing at all, what hyper-team software looks like in practice, the hidden risks, the guardrails, and how to tell when an afternoon project has turned into a real software project.

## What is dark matter software? The internal tools nobody sees

![For every visible flagship product, ten internal tools sit frozen in the shadows. A crystal on a pedestal labeled Flagship Product sits above a dark room labeled Dark Matter: Internal Tools, Scripts, and Dashboards. Callout: the little internal tool that Jane built back in 2021 before she left. Nobody understands it. Nobody will touch it.](https://blobs.talkpython.fm/guides/558/02.webp?cache_id=a15f1029)

If AI coding tools are as good as people say, where's the flood of new software? It's a fair question, and Michael Kennedy's answer is that the flood is real. You just can't see most of it. It's dark matter: small tools that solve or polish one problem and were never worth bringing out with a big launch.

Here's an example. Kennedy used the Startpage search engine, and it started showing ads that filled about two pages before the first search result. He didn't mind an ad. He wants to support them. But two pages was ridiculous, so he had Claude build him a browser extension that strips them out, for exactly one user. He figured he could make the problem go away in about 20 minutes. Nobody else will ever see that extension. That's what makes it dark matter.

Now scale that up to a company. Kennedy's estimate from what he's seen: for every product a company shows the world, say a car company's ordering website, there are 10 times as many hidden, small, somewhat unpolished things that are critical to making everything work. Little tools, little connectors, software nobody wanted to take on. Many are outdated, ugly or clunky. The person who built them left, and nobody else could rebuild them. So people are just thankful they work.

Why don't these get fixed? Part of it is the company itself, and Michael Booth gives that side its due. Enterprises need things to be orderly. Things have to be secured appropriately, and people should only have access to what they're meant to see. That means there's always overhead and friction on developing any software inside a company. As Booth puts it, "it's not choose your own adventure." Some industries carry little regulation, and others are highly regulated for very good reasons, which adds another layer of complexity to what you build and how.

So the dark matter sits there. Kennedy sees it as a gap, or with the glass half full, an opportunity. Booth agrees there are lots of opportunities, with a caution: think through a solution before you start changing anything. It's very tempting to just jump in. Pick a smaller problem first, learn something from it, and let that help you with the bigger ones.

> "I just had Claude build me an extension that would just remove the ads just for me. I have no intention of ever shipping it."
>
> Michael Kennedy

**Resources**

- [What hyper-personal software looks like (Michael Kennedy)](https://mkennedy.codes/posts/what-hyper-personal-software-looks-like/?featured_on=talkpython)

## Why nobody touches internal software: the two unwritten rules

![Enterprise internal software is paralyzed by two unwritten rules. A block of ice with frozen code sits in a vise. 1. The Principle of Least Touching: don't change it, it's working. 2. You Break It, You Bought It: if you touch it and it fails, it is permanently your problem. Callouts on Python 3.7, log4j and tenure under two years.](https://blobs.talkpython.fm/guides/558/03.webp?cache_id=09b68c9f)

Michael Kennedy spent years teaching week-long software courses at more than a hundred companies, and that gave him a look inside a lot of them. Each one was different in its own way. But for many of them, he says, two golden rules govern internal software.

**Rule one: don't change it, it's working.** Kennedy calls it the principle of least touching. Just leave it over there. Picture someone new suggesting Python 3.14 and maybe FastAPI, and the reply is "that's cute. We use Python 2."

Is that irrational? Not entirely, and Michael Booth gives it its due: if it is working, why would you fix it? It can be very expensive to change things. But he's also lived the downside. At a previous company the team was on Python 3.7, which was out of support and end of life. He asked whether they were going to upgrade, and people just stared at him. The answer was "why would we?" Booth sees it as the gap between what you should do on paper and what you do in reality.

Kennedy thinks both sides are right. You don't want to mess up something that works. At the same time, things like Log4J showed how big the problems get when people won't update their software.

**Rule two: you break it, you bought it.** If you do touch it, and it was working and now it isn't, it's your problem now. And the person who knew how it worked may not even work there anymore. Booth goes further. The person who built it almost certainly isn't there anymore, since typical tenure these days is less than two years by his reading of the stats. The chance of finding anyone on the team who knows anything about the tool can be very, very small.

Put the two rules together and nobody goes near the thing. It sits there, ugly or outdated, and everyone works around it. Kennedy's half-full view is that this is exactly where the opportunity lies, and the rest of this guide is about how to take it without becoming the person who broke it.

> "The person that did it almost certainly does not work there anymore, right? If you look at the stats, I think sort of typical tenure, at least these days, is less than two years."
>
> Michael Booth

**Resources**

- [Status of Python versions](https://devguide.python.org/versions/)

## AI code review versus nothing at all: competing against non-consumption

![The alternative to an AI-assisted audit isn't a $20,000 expert review, it's nothing at all. A chart of quality and security against cost. The Status Quo, complete non-consumption, sits low; The $20k Perfect Pen Test, never going to happen for an internal 6-person app, sits high and costly; an arrow lifts the status quo to The AI Agent.](https://blobs.talkpython.fm/guides/558/04.webp?cache_id=378c5e19)

Is an AI security review as good as a professional one? That's the question most people ask, and Michael Kennedy thinks it's usually the wrong one.

Start with how security review used to work. You'd build the software, maybe have a team lead review it, or run Bandit against it, and hope it was okay. You'd want someone to catch the unsafe version of YAML load and that kind of thing. Now, with Claude Code or Codex, you can say "do a security review on this." Kennedy's comparison: "what used to take like two weeks and a $20,000 pen testing engagement is now like an hour or less."

Kennedy has a name for what changes here: competing against non-consumption. You would hire a pen tester for the most important part of your software. But the little expense tracking tool that Jane wrote in 2021 before she left the company? Nobody was ever going to hire a pen tester for that. With these tools, you can "quote, hire a pen tester for it," and it takes half an hour.

So the real comparison isn't AI review versus expert review. For that expense tool, it's AI review versus no review. The real software might still get a real person. The little internal tools never would have.

Michael Booth doesn't let this off the hook entirely. His first point is that you still need qualified experts to review the results, so you lean on what the machine can do without completely relying on it. His second is about cost. If a review is sort of free, why not? But there are lots of other things you might investigate too. Do you actually want to spend your token budget on that one? For Booth, it comes back to thinking well about the problem: what are the actual pros and cons, and what risks are you trying to mitigate?

So the bar is lower than people assume, but Booth still wants someone deciding which reviews are worth the tokens. The same idea shows up again with accessibility, covered in [UX polish and accessibility for internal tools](#ux-polish-and-accessibility-for-internal-tools-escaping-battleship-gray).

> "Like there was never going to be a pen test of that at all. And now there can."
>
> Michael Kennedy

## What is hyper-team software?

![Hyper-Team Software solves local problems without spinning up a Capital-P Project. A crowded construction site beside a clean lab. Small, AI-assisted tools built by and for a single team: no project charters or dozen-stakeholder meetings, no heavy client-server infrastructure, often no complex authentication, prototypes in an afternoon.](https://blobs.talkpython.fm/guides/558/05.webp?cache_id=878b570e)

Michael Kennedy's hyper-personal software is built for one person. Michael Booth's hyper-team software asks the next question. If Kennedy can build things that solve his own problems, surely small teams inside companies have plenty of problems to solve too. (Booth apologizes for the name. He says he doesn't think it's particularly the right one; he just wanted to riff off Kennedy's.)

What makes something hyper-team software? Booth's description comes down to a few things it avoids:

- **No capital P project.** Companies are structured so that solving a problem usually means a formal project with lots and lots of people involved. Hyper-team software is the small problem you solve without that.
- **No one outside the team.** It doesn't involve other people outside your team.
- **No big infrastructure.** You're not setting up a client-server database to solve it.
- **Often no authentication.** You're not adding it, because the security of the tool doesn't really matter in this case.

Kennedy thinks the same concept applied to the enterprise is "way more powerful" than anything he's doing with it on his own.

Is any of this new? Booth is clear that it isn't. People have always built little widgets to solve problems. The game changer is that you can do it incredibly quickly. That cuts both ways: you can build a lot of good things quickly, or a lot of bad things quickly, so some vision and discipline matter. The speed also makes experiments cheap. You can find out whether an idea actually solves a real problem before you invest in it. And the bar has moved. Where he might once have reached 90%, Booth can now build the 99% solution and still do it 10 times faster.

There's a catch, and Booth names it himself. The implication is that you have the skills to build it. Everybody can build software these days, and he calls that a great piece of democratization. But not everybody can build good software, or sufficient software. Experience and some training still matter, so a tool works with the things around it and you've thought through the problems coming next. It's not only about building a solution that works for today, but about how it might fit in a broader ecosystem.

Booth also likes replacing wireframes with working prototypes, which gets its own section next: [building prototypes instead of wireframes](#build-the-prototype-instead-of-the-wireframe).

> "Maybe in the past I could do it at the 90% level, but nowadays I can build the 99%, still do it 10 times faster than the 90% solution."
>
> Michael Booth

**Resources**

- [From Hyper-Personal to Hyper-Team Software (Michael Booth)](https://www.databooth.com.au/posts/hyper-team-software/?featured_on=talkpython)
- [DataBooth](https://www.databooth.com.au/?featured_on=talkpython)

## Build the prototype instead of the wireframe

![A fundamental shift in how internal utility is generated. A table compares traditional enterprise software with hyper-team software: client-server and Spark vs DuckDB and SQLite, company-wide vs 1-10 local users, battleship gray wireframes vs AI-polished and accessible, business analysts vs prototypes, four weeks vs four hours.](https://blobs.talkpython.fm/guides/558/06.webp?cache_id=18c0b17c)

Anyone who has worked in a larger company knows the old process. You draw a diagram on a piece of paper, the business analysts turn it into wireframes, and everyone has a hypothetical discussion about something that doesn't exist yet. Michael Booth has done it that way. At a previous employer, the business analysts would say, let's draw up wireframes, and then we can prove this out. His answer now: no wireframes. Just build it, because it doesn't take very long, and then people can see the real thing.

He's careful to say that's not a critique of business analysts at all. The world has changed from when you used to work like that. A diagram on paper invites a hypothetical conversation. A working prototype or proof of concept gets you a real one.

Michael Kennedy has felt the same thing from the other side. Describe an idea and people say, oh, maybe that's nice. Tell them you could build it and they agree, yeah, probably you could. But spend a little time and show them, and the reaction changes: it took two hours to build, and with more work it'll be really nice. Kennedy thinks that makes a huge difference in how much trust and adoption your ideas get.

Why does the cost of building matter so much here? Kennedy's example is the tool everyone hates. It's a hassle, it could be smoother, it could automate more. If fixing it takes four weeks, nobody can justify someone working on it for four weeks. If it takes four hours, it might be worth four hours. Maybe it's that unproductive afternoon after a big meeting in the morning when you can't focus anyway.

Booth also sees prototypes as a way to find out what not to build. You learn quickly, fail quickly, refine, and decide whether to move forward. Sometimes the prototype reveals that the team down the road has already solved the problem and you can just borrow what they did. Either way, people can react to something real instead of a diagram nobody can quite decipher.

There's a career angle too, and Kennedy doesn't shy away from it. If all the data scientists at a company have some super annoying thing to deal with, and you spend two weeks fixing it so everybody's happier at work, they know it was you. That's a high-visibility thing to do. Booth agrees there are great opportunities to make a real impact and to be seen.

> "Like, no, we're not using wireframes. We're just building it because it doesn't take very long. And then people can see it, see the real thing."
>
> Michael Booth

## SQLite and DuckDB for internal tools: right-sizing the database

![Stop paying for five-nines of reliability when an in-process file is exactly what you need. A scale weighs a tangle of servers (replicated failover Postgres and a Spark cluster with an expert on pager duty) against a small cube under glass (DuckDB or SQLite, runs in-process, backup is copying a file). Right-size the engine.](https://blobs.talkpython.fm/guides/558/07.webp?cache_id=fb21640c)

Does a six-person internal app need a replicated database cluster? Michael Kennedy's example: in a company of 1,000 people, maybe six of them approve expenses, and they're the only ones who use the little web app for scanning and approving them. Do you need replica failover Postgres for that? Probably not. If it's really a small thing, it could just be a SQLite file, and then deploying it, managing it and backing it up become simple.

Michael Booth works this way himself. He uses DuckDB or SQLite so he doesn't have to set up a whole client-server database. If he just wants to capture data within his team, there are a lot of options. (DuckDB has just released an extension called Quack that opens up a client-server model, too.) The idea is a really lightweight place to capture data as part of your application, or to shove your logs. And once you have that observability data, you can start asking how people actually use the software and learn from it. Kennedy's examples: time series, or user flow, where they went here, then here, then did this. That kind of analysis used to be expensive.

Why do so many teams overbuild? Booth points to the late 2018 and 2019 years, when the push was to sell a whole bunch of infrastructure. He thinks people spent way more than they needed to, and points to DuckDB and MotherDuck materials that call out the fact that most people don't have big data. It depends on your industry, since some have mandated requirements for how they handle data. But depending on your business and team, a backup of the database might be good enough.

Kennedy adds the cost nobody puts on the invoice. It's not just paying for a huge Spark cluster. You now need somebody who understands what a Spark cluster is and how to run it, and someone gets called when it goes down. His read on what the big data vendors sell is the ability to dream big, to plan for the day you have a petabyte of data. Maybe. But if you just launched and don't have users yet, don't kill yourself with that early.

It all comes down to money for Booth. Company policies can be very well founded, but if they don't apply to your tool, why invest? There are real costs to all this. If you don't need the bulletproof solution, go with the one that gives you 99% uptime. Kennedy adds one condition: someone who is not an expert should be able to keep managing it.

Not that a database in a file is free of risk. Kennedy has a cautionary tale about exactly that backup step, covered in [the hidden risks section](#the-hidden-risks-of-team-built-software-data-controls-and-supply-chains).

> "Whereas SQLite is just, it's a file. If the app is running, the SQLite quote database is also running in process."
>
> Michael Kennedy

**Resources**

- [DuckDB](https://duckdb.org)
- [DuckDB Quack extension](https://duckdb.org/docs/current/core_extensions/quack)
- [SQLite](https://sqlite.org)
- [MotherDuck](https://motherduck.com)
- [Apache Spark](https://spark.apache.org)

## Where to start: onboarding scripts, decision packs and template apps

![The immediate high-leverage targets for Hyper-Team automation. Three pedestals: 1. Self-healing Onboarding Scripts that check OS versions and wire DB connections. 2. Automated Decision Packs that script PowerPoint and documents for governance forums. 3. Template App Architectures with SSO and logging encoded once in TOML or YAML.](https://blobs.talkpython.fm/guides/558/08.webp?cache_id=75e7640f)

So where does hyper-team software actually pay off first? Michael Booth's essay lists several places. Three of them go after plain drudgery.

**Onboarding accelerators.** Onboarding is a little bit painful in most teams. Some of it is social, and a buddy system where people talk to each other fixes that. A lot of it is technical setup. If you can write a setup script robust enough to run for more than one person on one day, you speed up onboarding and put everyone on a very similar footing. Booth's bonus: no more "it works on my machine" problem.

Michael Kennedy was excited enough to add to the list. The typical onboarding today is a wiki page: go read the setup steps, pick Mac, Linux or Windows, work down the script, see you at lunch. An AI-built script could do most of that and also check things, like making sure you have the right service pack because the company won't let you run an old version of Windows, and then install the connection to the database. It could also be re-run later. If the expected setup changes, the script looks at the machine again and says whether it's still good. You set it up two years ago; is it still good? That's really hard to answer today.

Booth adds the piece people forget: document it. Point the machine at the script you just wrote and keep the documentation in sync, because some users won't be able to read shell.

**Decision pack generators.** There are always packs going to decision makers and governance forums, put together with cut and paste. That's time consuming and it introduces errors. Nobody automated it before because the cost was just far too high compared to the result. Now a script can pull those materials together with proper links to related documents. That might mean automating some PowerPoint, though Booth's advice is to avoid PowerPoint at all costs if you can. Kennedy calls it a huge opportunity.

**Template app patterns.** This one surprised Kennedy. As Booth experimented, he noticed that many of these small tools follow repeatable patterns. So rather than building 10 different little applications, you pull what differs out into config (TOML, YAML, whatever your favorite is) and get a whole suite of apps with the same architecture. Kennedy points out big companies already impose that shape: you have to talk to this single sign-on system, you have to log to this place every app logs to. Documenting that repetitive stuff once seems pretty valuable.

> "You may just be able to again extract the relevant things out into config and have a whole suite of applications which are pretty much the same architecture."
>
> Michael Booth

**Resources**

- [TOML](https://toml.io)
- [YAML](https://yaml.org)

## UX polish and accessibility for internal tools: escaping battleship gray

![AI accelerators finally let us escape the era of battleship gray internal tools. A worn gray control panel joined by a latch to a bright dashboard of glowing dials. Callout: a functional interface that looks like rubbish does not get trusted. UX Polish: drag-and-drop reorderable lists. Accessibility: screen-reader navigability.](https://blobs.talkpython.fm/guides/558/09.webp?cache_id=e4d9dbb0)

Michael Booth writes Python and SQL, and he'll spin up Streamlit when he needs a UI. CSS and the like? He thinks of them as sort of dark arts. That used to put a ceiling on how good his tools could look. Now, with a little work with the machine, he can get them further. Not to a graphic designer's level, but better than they were.

Why does that matter for an internal tool? Because people respond to interfaces. As Booth puts it, "If you have an interface which is perfectly functional but looks rubbish, people don't trust it." He's spent a lot of his career in Excel, and even there you can build a UI that looks not too bad or one that's completely horrible. It doesn't matter what the tool is built in. Polish the interface and you get much better usability.

Michael Kennedy has a name for the old look. Back in the desktop and Visual Basic days, people called these tools "battleship gray." Technically they had a color. They just didn't care how they looked: gray backgrounds, black and white bits, maybe a green button if you went crazy.

The fixes can be small. Kennedy's example is a form where you enter items in order, and if you get the order wrong it's really hard to change. Ask Claude to make it drag and drop reorderable, and suddenly people who used to delete everything and start over can just reorder.

Accessibility is a bigger step. Booth sketched the prompt: tell Claude it's an expert UX designer who needs to allow for appropriate accessibility features. He admits he hasn't run that experiment, but suspects it probably works. Kennedy thinks it would work fantastically: ask it whether a site is accessible to blind people and to fix what isn't, and it can probably handle 95% of it. This is non-consumption again. The people who work on accessibility are working on the real website and the real tools. An internal tool was never going to get that review, and now it's basically free to ask. It opens up opportunities for inclusion, too.

Does that mean fewer UX designers? Booth says no. He doesn't see this as a call to get rid of them. It's a question of how they work with the machine: instead of having time to polish one dashboard, they can polish a whole heap of them and get consistency where it makes sense. He knows people are nervous about AI taking their jobs, and he sees it as he goes around. He just thinks it's the wrong mindset.

> "You can't say, I want to live five years ago because that world's gone."
>
> Michael Booth

**Resources**

- [Streamlit](https://streamlit.io)

## The hidden risks of team-built software: data controls and supply chains

![The hidden risks are organizational, and they live in the dependency supply chain. The Eager Agent: a robot arm drops a molten gear into a bin, agents eager to grab malicious external packages. The Silent Leak: a .sqlite canister beside a cracked pipe, a local database backup leaking PII and triggering HIPAA violations.](https://blobs.talkpython.fm/guides/558/10.webp?cache_id=a84ea134)

It's not all upside. Any software developed by end users inside an organization can introduce a bunch of risks if it isn't done well, and Michael Booth names several of them.

**Unknown dependencies.** Booth is clear he doesn't mean Python dependencies here. He means not understanding how things interact. If there are dependencies between your tool and others, you want them well understood, and that may not be obvious at first.

**Ownership.** You want somebody to own a tool. Can a team own it? Maybe in principle, but you still want clear ownership, and that means a real person.

**Regulatory and data controls.** Depending on your organization and your regulatory obligations, do you have the right controls in place? If you're an end user, you may not appreciate what data or security controls you're required to have. Booth's partial answer is to get the machine to help with some of that.

Michael Kennedy's example shows how easily this goes wrong. SQLite is great, it's just a file, so the backup plan becomes copying the .sqlite file. Then that file turns out to be full of personal information, and copying it to the wrong place is a HIPAA violation. It could be bad. Booth's response: data really matters, and some industries have very strict requirements, as they should. As an end user you may not have the visibility to know them. Some applications need sufficient knowledge before you build them.

**The supply chain.** Kennedy adds one more, and it's been in the news a lot lately: supply chain attacks on npm, and on PyPI to a lesser degree, but not to a zero degree. He mentions LiteLLM, which he says was pretty bad even though it was only out for a couple of hours. The trouble with agents is that they love to grab a package and install it. Nothing checks that it installed okay, or that it doesn't carry a CVE. And if a problem shows up later, who knows where it was used so it can be patched?

Enterprises usually have an answer for that, Booth notes: internal mirrors of package indexes. But you have to govern those well, or you can easily miss things. Kennedy's follow-up is the real question. Does your AI know to use them? The further you lean toward the vibe side, the less likely it is. Ask an agent to make something look like Instagram, and it'll grab whatever Instagram uses.

Some of that discipline can be built into the tools the agent has to answer to, which is where the next section picks up.

> "Any sort of software developed by end users within organizations is, if not done appropriately well, can just introduce a bunch of risks."
>
> Michael Booth

**Resources**

- [PyPI](https://pypi.org)
- [npm](https://www.npmjs.com)
- [LiteLLM on GitHub](https://github.com/BerriAI/litellm)

## Guardrails for AI coding agents: Ruff, type checkers and tests

![Strict mechanical guardrails are what separate disciplined engineering from vibe coding. Tangled wires labeled Vibe Coding pass through filters labeled Ruff Linters, ty and mypy Type Checkers, and Internal Package Mirrors, coming out as Disciplined Engineering. Callout: the agent cannot move on until the linter passes.](https://blobs.talkpython.fm/guides/558/11.webp?cache_id=7803176a)

What separates hyper-team software from vibe coding? For Michael Booth, it's the guardrails, and he doesn't do without them. Ruff, ty, mypy and that sort of tooling let you constrain the machine so you build a much better product each time. Add really good tests. As you learn from each experiment, you build up best practices and lift the quality of what you ship. He calls these very basic software disciplines, and they let you move both faster and better.

Michael Kennedy makes it operational. Tell your agent it can't move on until Ruff passes. It can't move on until ty or Pyrefly, or whichever checker you picked, passes. Set up the config files to say how your organization works: we format it like this, we do this. Then the agent has to write code that conforms, because the tool tells it it's not done. Ruff returns exit code one instead of zero, and the agent tries again.

Booth sees those disciplines as what moves you away from the vibe coding view of the world, and they allow some pretty good software to be built. His caveat: if you're not scrutinizing the result and applying your critical thinking, you're asking for a few problems.

How much work is this across a whole company? Kennedy compares it to running a linter on a codebase for the first time. It tells you there are a thousand and seven problems, and you think, we can't hire somebody for each one of those. That's what all the neglected internal apps look like. But with a couple of people and Claude or Codex, a team could modernize two apps this week and two more next week. After a couple of months, or six, depending on the size of the company, a lot of apps would be in good shape and need little attention. They've been running untouched forever anyway. Now they'd just run better.

The cost argument from earlier applies to basics like these too. Booth remembers when putting baseline good practices into software was considered expensive. Adding logging is almost trivial now. So if it doesn't really cost you anything, why wouldn't you put it in? A pointless feature is fair enough to skip (nobody wants animated GIFs in everything), but the basics of good software engineering belong in any tool. It also helps to work out what mission critical actually means for a given tool. Kennedy's example is the company that builds everything to a standard a bank could run on, including the log parsing tool that just helps it see whether the server is up.

> "So there's no way I let a coding assistant run without locking it down severely, right?"
>
> Michael Booth

**Resources**

- [Ruff](https://docs.astral.sh/ruff/)
- [ty](https://github.com/astral-sh/ty)
- [mypy](https://mypy-lang.org)
- [Pyrefly](https://github.com/facebook/pyrefly)
- [Black](https://github.com/psf/black)

## Using AI to explain and document legacy code: what, why and how

![When the machine can explain legacy code, lack of time is no longer an excuse. A robotic camera scans a crumbling stone tablet of runes onto a clean glass page. AI scopes changes by generating documentation answering: 1. What are we doing? 2. How are we doing it? 3. Why are we doing it?](https://blobs.talkpython.fm/guides/558/12.webp?cache_id=2cc0644b)

Remember rule two, you break it, you bought it? Much of that fear comes from not knowing how the thing works. The person who wrote it left, and there's a lot of unknown. Michael Kennedy's point is that this is one of the things Claude and the other agentic tools are good at. Point one at the application and ask it to study it, tell you what it does, and tell you what parts are involved in adding feature X. The answer might come back that nobody understood it well and nobody has worked on it, but the change looks pretty straightforward and here's all you need to do. Now you can scope the change before you commit to it.

Michael Booth takes the next step. The explain functionality is quite amazing, but if the machine can explain it, why not have it document it? Keep the documentation in sync with the code. And the old excuse that there's no time to document doesn't hold up. If the machine gets you 95% of the way there and you review it and tweak it, Booth sees that as a win-win.

Kennedy's version is even lazier, in a good way. Kick off Claude or Codex, tell it to spend all the time it needs documenting the application, give it the format and where it goes, then switch to another tab and go do something else. You should have documentation.

What should that documentation say? Booth has a structure he uses in every README: what are we doing, why are we doing it, and how are we doing it. He thinks that framing is quite often missing from technical descriptions, and the why is the piece he singles out as pretty important.

That matters later too. When you're deciding whether a tool is worth keeping or how to turn it off, a clear statement of the problem it solves is part of the answer, as covered in [when an afternoon project becomes a real software project](#when-does-an-afternoon-project-become-a-real-software-project).

> "I always, as part of the readme or whatever, do the, what are we doing? Why are we doing it? And how are we doing it?"
>
> Michael Booth

## The unicorn team: pairing domain experts with software engineers

![Stop searching for the Unicorn Person and start building the Unicorn Team. Two fused steel rings, Deep Domain Expert (understands the business problem) and Software Engineer (understands scale, security and architecture), glow at a join labeled Agentic AI. Caption: use AI to bridge domain experts and engineering talent.](https://blobs.talkpython.fm/guides/558/13.webp?cache_id=02cdaaa5)

Who should build hyper-team software? Michael Booth's essay has an answer he calls the unicorn, and he apologizes for the name first, since it can be a bit pretentious. The unicorn is someone with real software engineering capability and deep domain expertise. People like that bring a lot to the table, because many people stick to a single domain. Booth is careful to say that's not a critique, just his observation.

Why does the combination matter so much? Booth's argument is that someone embedded in the business understands its problems, by definition, much better. Combine that domain knowledge with software engineering skills and you have a really potent force. His own career is that kind of mix: a PhD in computational chemistry, then a long stretch in quantitative finance, then data science. His framing is to ask, if he can do his computational chemistry in his small team, how can he use those skills to build software that matters for that team?

Michael Kennedy makes the same point from the other direction. He could use AI to try to do computational chemistry, but he's highly unqualified to do so, even though he studied it long ago. Companies are full of programmers who already have the domain knowledge to understand what they actually want to accomplish, not just how to make the code better.

So what do you do if you can't find a unicorn? Kennedy agrees those people would be ideal, and that they're hard to come by. His suggestion is a pair: one person who really understands the problem and has a little programming skill, and another who is really good at programming and knows a little about what's going on. Booth agrees that buddy pairs can be another model, and he's a great believer in creating environments where people can do their best work. Having people talk to each other in teams is quite powerful in general.

Where does AI fit into the pairing? The episode's clearest example is about a skill gap, not a person. Kennedy describes a team that has always consumed the API and the database rather than changing them, so any new feature meant getting another team on board. Or part of the application is written in Swift and nobody on the team knows Swift. Claude could help them work through that portion. Booth sees the autonomy as a good thing. Taking charge of your own team's productivity, he says, is not a bad thing.

> "I don't think you necessarily need maybe the unicorn person, but the unicorn team."
>
> Michael Booth

## When does an afternoon project become a real software project?

![Recognizing the boundary between an afternoon experiment and a full-scale enterprise project. A flowchart: Does it cause actual friction? Is there an owner to fix it? Can you explain it in 2 sentences? Does it require external authentication? Yes means stop, it's a real software project. No means build the hyper-team app.](https://blobs.talkpython.fm/guides/558/14.webp?cache_id=c839936f)

Not every annoyance should become a tool. Michael Booth's essay ends with a decision tree (he's a big Mermaid fan, so it's a Mermaid diagram), and the questions in it are a good filter before anyone opens an editor.

He starts with a rule from an old boss: if you're going to solve a problem more than twice, automate it. You can argue the merits of that, Booth admits, but there's something to it. Then the questions:

- **Is it causing friction?** Why would you solve a problem that is frictionless?
- **Does it have an owner?** Is somebody going to care about this problem enough to take ownership of it? Michael Kennedy's shorthand: if it stops working, will they make it work again? If you can't find an owner, Booth figures maybe nobody cares about it.
- **Can you explain what it does in two sentences?** The machine can help you with that. But if you can't articulate it to your stakeholders, why should they care? Booth points to the Unix philosophy, where a command line tool does one thing well. The tool should be very, very explainable.
- **Do you know how to disable it quickly?** Can you turn it off? If you turn it off, will anybody notice? And if they do, can you turn it off and quarantine it properly? Kennedy adds a parallel question: could you get things back to the way they were before?

Booth notes that most of the tools he has in mind are deterministic. Anything powered by generative AI definitely needs a kill switch. Documentation is a useful control here too. Not just documentation for the tool, but making sure the process and the problem you're solving are well articulated.

Where's the line? Booth's clearest marker is authentication, along with whether the tool needs that database thing. By the time you're doing authentication in the enterprise, it feels to him like somebody should probably be looking at things more closely. You'll typically have to talk to people in other teams anyway. That doesn't make it a bad tool. It's a sign it's time to talk to others. Kennedy's summary: it might be a software project, not just an afternoon project.

> "Because if you can't find an owner, then maybe nobody cares about it."
>
> Michael Booth

**Resources**

- [Mermaid](https://mermaid.js.org)
- [From Hyper-Personal to Hyper-Team Software (Michael Booth)](https://www.databooth.com.au/posts/hyper-team-software/?featured_on=talkpython)

## Getting started with AI at work: ignore the hype and run one experiment

![Ignore the hype, refuse to outsource your critical thinking, and run one experiment today. A glowing loop: Hypothesize, Build, Test, Learn. Start Small: pick the app that exactly 3 people use. Stay Sharp: experience teaches you which shortcuts are right. The Future: winning teams will quietly have 100 small things that work.](https://blobs.talkpython.fm/guides/558/15.webp?cache_id=54504ef7)

What would Michael Booth tell a decision maker who has declared no AI at their company? He isn't sure many are left (maybe it's a bit of a straw person now), but his answer is a word he uses a lot: experiment. Try things within your risk tolerances, inside boundaries you're comfortable with.

Why not just read about it? Booth's experience is that if you haven't used an LLM firsthand, you tend not to believe it's true. His own path ran from autocomplete finishing a `pd.read_csv` call to trying Perplexity a couple of years ago: "you've got to be kidding me. This can't be real." His own early tries were a week's menu plan and a holiday plan, and he told a mate who had never touched one to start by asking what to do for his kid's school holidays. And pick partners trying to solve your business problems, not ones trying to extract money out of your company.

Michael Kennedy's advice has two parts. Start at the smallest, lowest-risk rung: you might have a thousand employees and a million customers, but here's the app only three people use. Try it there. And treat it as an engineering skill, like object-oriented programming or memory management, not a casual chat with a buddy.

The other half is staying sharp. Booth doesn't want people to "outsource your thinking, I would say, to a machine that's very good at multiplying and adding matrices together very quickly." Experience teaches you what goes wrong, and everybody takes shortcuts. His advice: "Just choose the right shortcuts."

His final word: "Ignore the hype and just try something." Microsoft Copilot, GitHub Copilot, Claude Code: he doesn't think the tool matters much. At home he uses Warp and Claude. No tool is perfect, and no human is either.

For a structured way in, Talk Python Training has three courses that line up with this conversation: [Agentic AI Programming for Python](https://training.talkpython.fm/courses/agentic-ai-programming-for-python?utm_source=talkpythondeepdive) for working with agents and their guardrails, [Python Web Security: OWASP Top 10 with Agentic AI](https://training.talkpython.fm/courses/agentic-ai-python-security?utm_source=talkpythondeepdive) for a real security pass on internal tools, and [Just Enough Python for Data Scientists](https://training.talkpython.fm/courses/just-enough-python-for-data-scientists?utm_source=talkpythondeepdive) for the domain expert who wants the engineering half of the unicorn.

So pick something small: an app three people use, an onboarding script that fails half the time, a report someone assembles by hand every week. Treat it as an experiment and see what you learn.

> "Everything's an experiment. The question is, will you learn from the experiment?"
>
> Michael Booth

**Resources**

- [Michael Booth on GitHub](https://github.com/mjboothaus/?featured_on=talkpython)
- [Perplexity](https://www.perplexity.ai)
- [Claude Code](https://www.anthropic.com/claude-code)
- [Codex](https://github.com/openai/codex)
- [GitHub Copilot](https://github.com/features/copilot)
- [Warp](https://www.warp.dev/?featured_on=talkpython)

---

Listen to the full episode: https://talkpython.fm/episodes/show/558/hyper-personal-software-with-python
Episode show notes as Markdown: https://talkpython.fm/episodes/show/558/hyper-personal-software-with-python.md