Hyper-Personal Software with Python
For every app you can actually see, there are ten of these sitting in the shadows, frozen. Michael Booth thinks that just changed. He read my article on hyper-personal software and ran with it, writing about hyper-team software: small teams inside big companies finally building the tools that were never going to get built.
We cover where this works, where it quietly goes wrong, and the guardrails that keep it from turning into a mess. Let's get into it.
Episode Deep Dive
Guest Introduction and Background
Michael Booth is an independent data and software consultant who runs DataBooth, a solo consultancy he started coming out of COVID, roughly five years ago. His path into it is unusual and it shapes everything he says in this conversation. He began in academia with a PhD in computational chemistry, finishing in the late 1990s, and deliberately chose theoretical over experimental work because, as he puts it, experiments are much easier to control on a computer than in real life (and organic chemistry smells bad). From there he spent a long stretch in quantitative finance, including a lot of time reviewing the models that finance runs on. In 2017 he did a data science boot camp in Oakland, identified data science as a growth area, and eventually decided he wanted to build things again rather than only review them.
As a solo practitioner he gets to choose small, interesting projects. One favorite: working with a researcher studying stress responses in horses, where he wrote both the code to control a Raspberry Pi based experiment and the code to analyze the results. He mostly writes Python and SQL, reaches for Streamlit when he needs a UI, leans on SQLite and DuckDB rather than standing up client-server database infrastructure, is a self-described big Mermaid fan for diagrams, and cheerfully admits that CSS and friends are "dark arts" to him. He has also spent a lot of his career in Excel, which gives him an unusually grounded view of what real end users actually touch.
The episode exists because Booth read Michael Kennedy's article on hyper-personal software and riffed off it with his own essay, "From Hyper-Personal to Hyper-Team Software: Small Team-Built, AI-Assisted Tools Inside the Enterprise."
- github.com/mjboothaus
- www.databooth.com.au
- www.databooth.com.au/posts/hyper-team-software
- mkennedy.codes/posts/what-hyper-personal-software-looks-like
- duckdb.org
- sqlite.org
- streamlit.io
- mermaid.js.org
- raspberrypi.com
What to Know If You're New to Python
This episode is less about Python syntax and more about where small Python tools fit inside a large organization, so the useful background is about the shape of internal software and the tooling that keeps AI-generated code honest. Here is the context that will make the conversation land.
Internal tools versus product software: Most companies have a visible product plus ten times as much unglamorous internal software: log parsers, expense approval apps, data connectors, scripts. This episode is entirely about that second category, where the quality bar, the user count, and the risk profile are all completely different from the flagship product.
Embedded databases (SQLite and DuckDB): Not every application needs a database server running on separate machines with replication and failover. SQLite is a single file that runs inside your process, and DuckDB is an in-process analytical database. Booth and Kennedy argue these are often the right answer for a tool used by six people, and understanding why makes the "hyper-team databases" segment click.
Linters, formatters, and type checkers: Tools like Ruff, mypy, ty, and Pyrefly check your code automatically and exit with an error code when something is wrong. In this episode they show up as guardrails on AI coding agents: the agent is not done until the tools pass, which turns "vibe coding" into something closer to disciplined engineering.
Agentic coding assistants: These are AI tools that do not just chat but read your whole codebase, run commands, and edit files. Claude Code, Codex, GitHub Copilot, and Microsoft Copilot all come up. The key mental model is that they can explain unfamiliar code and generate documentation as easily as they write new features.
Dependency supply chain: Python packages come from PyPI and JavaScript packages from npm. Both have seen malicious package incidents, and agents happily install whatever they think they need. Knowing this makes the risk discussion near the end concrete rather than abstract.
Key Points and Takeaways
Hyper-team software: the same idea as hyper-personal, aimed at the team
Kennedy's original concept was hyper-personal software: build a small tool that solves exactly your problem, for exactly one user, with no intention of ever shipping it. Booth's move was to ask what happens when you scale that to a small team inside a big company. The result is software that solves a real internal problem without spinning up a capital-P Project, without pulling in a dozen stakeholders, without standing up client-server infrastructure, and often without authentication because the security surface is genuinely small. Booth is explicit that there is nothing new about people building little widgets to solve problems. The game changer is the speed. Because you can now build and discard experiments in hours instead of weeks, an entire class of problems that never cleared the cost/benefit bar suddenly does.
- www.databooth.com.au/posts/hyper-team-software
- mkennedy.codes/posts/what-hyper-personal-software-looks-like
- duckdb.org
- streamlit.io
The two golden rules that freeze internal software solid
Kennedy names the two unwritten laws that govern internal tools at most companies. First: don't change it, it's working. He half-jokingly calls this the principle of least touching. Second: if you break it, you bought it. Together they mean nobody goes near the thing. Booth points out this is worse than it sounds because typical tenure these days is under two years, so the likelihood that anyone still on the team understands the tool is very small. He describes suggesting to a previous employer that they upgrade off Python 3.7 because it was end of life, and being met with blank stares and "why would we?" Both men are fair about it: not changing working software is often the economically rational call, and change is genuinely expensive. But the same instinct is how you end up exposed when something like the log4j vulnerability lands.
Competing against non-consumption is the real unlock
This is the framing Kennedy keeps returning to, and it is the sharpest idea in the episode. When you ask whether an AI can do a job as well as a specialist, you are usually asking the wrong question. For most internal tools, the specialist was never going to be hired at all. Nobody was going to commission a twenty thousand dollar pen test for the expense tracking tool Jane wrote in 2021 before she left. Nobody was going to book an accessibility expert to review a dashboard six people use. Those reviews were not going to happen, period. So the comparison is not "AI review versus expert review," it is "AI review versus nothing." Booth pushes back usefully: even when it is nearly free, you still have a token budget and other things to investigate, so you should still think about which risks you are actually trying to mitigate.
Onboarding accelerators are the low-hanging fruit
Booth's first concrete example is onboarding, which is painful in most teams. Some of it is social and gets fixed with a buddy system, but a lot of it is technical setup that lives in a wiki page you hand a new hire on day one. Instead, you can write a setup script robust enough to run for more than one person on one day, which kills the "works on my machine" problem before it starts. Kennedy extends it: the script can verify the OS version is current enough, wire up database connections, and be re-run later to check whether a machine configured two years ago is still in a good state. Booth adds the piece people forget, which is that you can point the machine at the script you just wrote and generate documentation that stays in sync with it, because plenty of your users cannot read shell.
Internal tool UX polish, including accessibility
Booth writes Python and SQL and spins up Streamlit when he needs an interface, but considers CSS a dark art. That used to cap how good his tools could look. Now a little work with the machine gets him meaningfully past where he could get alone, not to graphic designer level, but better. And appearance is not vanity: as Booth puts it, a perfectly functional interface that looks rubbish does not get trusted. Kennedy recalls the era of desktop apps described as "battleship gray," technically colored but visually joyless. The examples are small and real: making a form drag-and-drop reorderable so users no longer have to delete everything and start over when they enter items in the wrong order, or asking the assistant to act as a UX expert and improve accessibility for screen reader users. Booth is careful to say this is not a call to get rid of UX designers. It is a call for them to work with the tools so that instead of polishing one dashboard they can polish a whole heap of them, and get consistency across them.
Decision pack generators kill the copy-and-paste tax
Every enterprise has packs going to decision makers and governance forums, and they are assembled by hand through cut and paste, which is both slow and a reliable source of errors. Booth sees real opportunity in automating the assembly of those materials, whether that is scripting the PowerPoint generation (his advice: avoid PowerPoint at all costs if you can) or pulling together documents with proper linkages between them. His point is the classic non-consumption argument again: nobody automated this before because the cost of building the automation was far too high relative to the payoff. That ratio has flipped.
Hyper-team databases: right-size the infrastructure
Booth uses DuckDB and SQLite so he does not have to set up a whole client-server database. For a tool where six people out of a thousand-person company approve expenses, you probably do not need replicated failover Postgres. Kennedy notes the deployment and backup story becomes dramatically simpler when the database is a file that runs in-process with the app. Booth ties this to a broader complaint about the 2018 to 2019 era push to sell data infrastructure, where he thinks companies spent far more than they needed to, and points at DuckDB and MotherDuck materials calling out that most people do not actually have big data. Kennedy adds the hidden cost that nobody prices in: a Spark cluster does not just cost money, it requires a person who understands Spark clusters and gets paged when one goes down. Booth also mentions that DuckDB has released an extension called Quack that opens up a client-server model.
Template app patterns: extract the sameness into config
This one surprised Kennedy. Booth noticed while experimenting that many of these small tools share a repeatable architecture. Rather than building ten different little applications, you can extract the differences into a config file, TOML or YAML or whatever you prefer, and have a whole suite of applications with essentially the same architecture doing very similar things with different settings. Kennedy points out that big companies already have this shape imposed on them: you must talk to this single sign-on system, you must log to this central place. Encoding those repeated requirements once, in a template plus config, is valuable. Booth's caveat is the money argument: those policies are often well founded, but if they do not apply to your tool, do not pay for the bulletproof solution when the 99 percent uptime one will do.
Guardrails are what separate this from vibe coding
Booth is emphatic here: there is no way he lets a coding assistant run without locking it down severely. Ruff, ty, mypy, and good tests are how you constrain the machine so that each iteration produces a better product. Kennedy agrees and makes it operational: tell the agent it cannot move on until Ruff passes, cannot move on until the type checker passes, and set up the config files that encode how your organization writes code. The tool returns exit code one instead of zero, and the agent tries again. Booth frames these as very basic software disciplines that let you move both faster and better, and notes that this is precisely what moves you away from the vibe coding view of the world. He also expects to keep accumulating best practices as each experiment teaches him something.
- docs.astral.sh/ruff
- github.com/astral-sh/ty
- mypy-lang.org
- github.com/facebook/pyrefly
- github.com/psf/black
Documentation is no longer an excuse, and the "why" matters most
Kennedy points out that one of the things agentic tools are genuinely excellent at is being pointed at an unfamiliar application and asked what it does, and which parts are involved in adding a given feature. That directly attacks the "you break it, you bought it" fear, because it lets you scope the change before you commit to it. Booth's reply is the natural next step: if the machine can explain it, why not have it document it and keep the docs in sync with the code? The old excuse that there is no time to document does not survive when the machine gets you 95 percent of the way and you review and tweak. He is passionate about one specific structure for a README: what are we doing, why are we doing it, and how are we doing it. The why is the part most often missing from technical descriptions, and it is the part that matters most.
The hidden risks are organizational, not just technical
Booth is clear that end-user-developed software inside an organization can introduce a bunch of risk if it is not done well. The dependencies he worries about are not Python packages but interactions between tools that nobody fully understands. Ownership matters: a team can own a tool in principle, but you still want a real person who will fix it when it breaks. Regulatory and data controls are the big one, because an end user genuinely may not know what data controls they are required to have. Kennedy gives the sharp example: SQLite is great until someone decides the backup process is copying the .sqlite file, and that file is full of PII, and now it has been copied somewhere it should never be under HIPAA. Both agree the answer is not to stop, it is to have sufficient knowledge for the class of application you are building.
Supply chain risk and agents that install whatever they want
Kennedy raises supply chain attacks as an additional hidden risk, noting how much this has been in the news lately with npm and, to a lesser but nonzero degree, PyPI, including the LiteLLM incident that was live for only a couple of hours. The specific danger with agents is that they love to grab a package and install it, with no check on whether it installed correctly, whether it has a known CVE, or any record of where it ended up so you could patch it later. Booth notes enterprises typically have internal mirrors for exactly this reason, but they have to be governed well. Kennedy's follow-up is the real question: does your AI know to use them? The further you slide toward "just make it look like Instagram," the less likely the answer is yes. Booth's response is one line: you need some discipline around this stuff.
The decision tree: when it stops being an afternoon project
Booth's article ends with a Mermaid decision tree, and he walks through the questions. Is it causing actual friction? Why solve a frictionless problem? Does it have an owner, meaning someone who cares enough to make it work again when it breaks? If you cannot find an owner, maybe nobody cares. Can you explain what it does in two sentences? If you cannot articulate it to stakeholders, why should they care, and the Unix philosophy of doing one thing well applies here too. Do you know how to disable it quickly, and can you get things back the way they were? He notes the tools he has in mind are deterministic, not generative AI powered, and that generative ones definitely need a kill switch. The clearest boundary marker is authentication: once you need auth, you are almost certainly talking to other teams anyway, which is a sign this may be a real software project rather than an afternoon project. He also cites an old boss's rule that if you are going to solve a problem more than twice, automate it.
Unicorns, and why the unicorn team beats the unicorn person
The "unicorn" in Booth's article is someone who combines genuine software engineering capability with deep domain expertise. He argues that combination is a potent force, because being embedded in the business means you understand the business problems by definition much better than an outside builder does. Kennedy agrees these people are ideal and also hard to come by, and proposes the workaround: pair someone who really understands the problem and has a little programming skill with someone who is strong at programming and knows a bit about the domain. Booth likes it, and lands on the better formulation: you do not necessarily need the unicorn person, you need the unicorn team. He adds that he is a believer in creating environments where people can do their best work, and that having people talk to each other in teams is itself quite powerful.
Everything is an experiment, but don't outsource your thinking
Booth's recurring theme is that everything in life is an experiment and he tries to keep his experiments orderly in GitHub, where you can find his work. The upside of AI-assisted building is that experiments get cheap: you learn quickly, you fail quickly, you refine, and sometimes you discover the team down the road already solved it and you can just borrow their work. But he draws a hard line on the failure mode he is most worried about, which is people outsourcing their thinking to the machine. You still need qualified experts to review results. He notes, as a sign of the times, that the University of Washington now teaches a course on critical thinking, and wonders aloud why you would need to teach people critical thought. His answer is that experience is what teaches you which shortcuts are the right ones, and if you are not scrutinizing output and applying critical thinking, you are asking for problems.
Prototypes beat wireframes, and that changes how ideas get funded
Both men have lived the version of enterprise life where you draw a diagram on a piece of paper, hand it to business analysts, produce wireframes, and hold hypothetical discussions. Booth's position now is blunt: no wireframes, just build it, because it does not take very long and then people can see the real thing. He is careful to say this is not a critique of BAs, it is that the world has changed. Kennedy adds the political dimension, which matters if you care about your career. Describing a capability gets you a shrug. Showing a working thing you built in two hours gets you trust and adoption, and if you fix something that annoyed every data scientist at the company, everyone knows it was you. Booth, who describes himself as not much of a limelight guy, agrees there are real opportunities to make an impact and be seen.
Getting started: ignore the hype and run one experiment
Asked what he would tell a decision maker who has declared no AI at their company, Booth first admits he does not know the statistics and that it may be a bit of a straw person these days. Then his real answer: experiment within your risk tolerances. Try things inside boundaries you are comfortable with. His observation is that if you have not used an LLM firsthand, you tend not to believe it is true. His own path went from being amazed that autocomplete could finish a pd.read_csv call, to trying Perplexity a couple of years ago and thinking "you have got to be kidding me, this can't be real." He recommends non-work experiments too, like planning a week of meals or a school holiday, as the fastest way to build the intuition. And he warns against partnering with anyone who is just trying to extract money out of your company rather than solve your business problems. Kennedy adds that these tiny internal apps are the lowest-risk rung available: you may have a thousand employees and a million customers, but here is the app three people use, so try it there. His other note is that working with these tools is an engineering skill in its own right, not a casual chat with a buddy.
- pandas.pydata.org
- perplexity.ai
- anthropic.com/claude-code
- github.com/openai/codex
- github.com/features/copilot
- copilot.microsoft.com
- www.warp.dev
Interesting Quotes and Stories
"You don't want to outsource your thinking, I would say, to a machine that's very good at multiplying and adding matrices together very quickly." -- Michael Booth
"You can build a lot of good things quickly, or you can potentially build a lot of bad things quickly." -- Michael Booth
"Maybe in the past I could do it at the 90% level, but nowadays I can build the 99% and still do it 10 times faster than the 90% solution." -- Michael Booth
"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
"You can't say I want to live five years ago because that world's gone." -- Michael Booth
"If you have an interface which is perfectly functional but looks rubbish, people don't trust it." -- Michael Booth
"If you can't find an owner, then maybe nobody cares about it." -- Michael Booth
"There's no way I let a coding assistant run without locking it down severely." -- Michael Booth
"I don't think you necessarily need maybe the unicorn person, but the unicorn team." -- Michael Booth
"Everything's an experiment. The question is, will you learn from the experiment?" -- Michael Booth
"Ignore the hype and just try something." -- Michael Booth
"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. I just thought, here's a problem I have. I bet in 20 minutes I can make it go away." -- Michael Kennedy
"What used to take like two weeks and a $20,000 pen testing engagement is now like an hour or less." -- Michael Kennedy
"It's a hassle or it could be smoother, could automate more. But it's going to take four weeks and it just doesn't justify someone working on it for four weeks. But if it's going to take four hours, you know what? It might be worth four hours." -- Michael Kennedy
"Whereas SQLite is just a file. If the app is running, the SQLite quote database is also running in process, you're good to go." -- Michael Kennedy
Some of the stories worth listening for:
The horse experiment. As a solo consultant, Booth got to work with a researcher trying to understand when a horse is stressed. She had a Raspberry Pi based experimental rig, and he wrote both the code to control the experiment and the code to analyze the results. He had never worked with a Raspberry Pi before and learned a heap, and it got him back to his research roots. His observation: when you do not play in a space, you do not realize how far things have advanced.
"Why would we?" At a previous company Booth pointed out that the Python 3.7 they were running was out of support and end of life, and asked whether they were going to upgrade. People just stared at him. As he puts it, that is what you should do on paper versus what you actually do in reality.
The two-page ad wall. Kennedy's own hyper-personal software origin story. The Startpage search engine started showing so many ads that it filled roughly two pages before the first actual result. He did not mind supporting them with an ad, but two pages was ridiculous. So he had Claude build him a browser extension that strips them out, for an audience of exactly one, with no plan to ever ship it.
Battleship gray. Kennedy's name for the old Visual Basic era of internal desktop tools. Technically they had a color. They just did not care how they looked: gray backgrounds, black and white bits, maybe a green button if you were feeling wild.
"This can't be real." Booth's own conversion arc, from being amazed that autocomplete could finish a pd.read_csv call, to trying Perplexity a couple of years ago and not quite believing it. His point is that until you use one firsthand, you tend not to believe any of it is true, which is why he keeps telling friends, including a lawyer friend and a mate who has never touched one, to just run an experiment.
Chemistry, and why he went theoretical. Booth did his PhD in computational chemistry, finishing in the late 90s. Organic chemistry was his least favorite branch, partly because it smells bad, and he preferred theory because experiments are much easier to control on a computer. Kennedy, who loved organic chemistry and spent hours playing with HyperChem in the 90s, admits the volatile chemicals gave him headaches and that is a large part of why he went and did math instead.
Key Definitions and Terms
- Hyper-personal software: Kennedy's term for software you build for an audience of one, yourself, with no intention of shipping it. The classic example in this episode is the browser extension that strips ads from a search page.
- Hyper-team software: Booth's extension of the idea. Small, AI-assisted tools built by and for a single team inside a larger company, scoped so they do not require a formal project, extra infrastructure, or coordination with other teams.
- Dark matter software: Kennedy's framing for why we do not see an obvious explosion of new apps despite AI coding tools. The explosion is real, but most of it is invisible: small internal tools and fixes that are never launched, marketed, or made public.
- Competing against non-consumption: The observation that the alternative to an AI-assisted review or tool is frequently nothing at all, not a human expert. Nobody was going to pen test the tiny expense app or accessibility-audit the internal dashboard, so a cheap imperfect pass is a large improvement over zero.
- Principle of least touching: Kennedy's joke name for the first unwritten rule of internal software: it works, so do not change it, do not touch it, leave it alone over there.
- You break it, you bought it: The second unwritten rule. If you modify a working internal tool and it stops working, it is now permanently your problem, and the person who originally wrote it probably left the company years ago.
- Capital-P Project: Booth's shorthand for the formal enterprise project model with lots of stakeholders, governance, and process. Hyper-team software is explicitly the thing you do instead of starting one.
- Decision pack: The bundle of slides and documents assembled for decision makers and governance forums, traditionally built by hand with cut and paste, and therefore both slow and error prone.
- Unicorn / unicorn team: A unicorn is a person with both real software engineering skill and deep domain expertise. Because those people are rare, Booth prefers the unicorn team: pairing domain depth with engineering depth so the team collectively has both.
- Battleship gray: Kennedy's description of internal tool UI that is functional but visually dead, a holdover from the Visual Basic desktop era.
- Observability data: The logs and usage data a tool emits. Booth's point is that once you capture it, even in something as simple as a local DuckDB or SQLite file, you can start asking how people actually use the software and learn from it.
- Kill switch: The ability to disable a tool quickly and cleanly. Booth notes the tools he is describing are mostly deterministic, but anything generative AI powered definitely needs one.
- Supply chain risk: The danger of malicious or vulnerable third-party packages entering your codebase, made worse by agents that install dependencies enthusiastically and without checks. Enterprises usually mitigate it with internal package mirrors, assuming the agent knows to use them.
Learning Resources
If this episode has you thinking about the little tools sitting frozen inside your own company, here are a few places to go deeper. These are the courses that map most directly to what Michael and Michael talked about: working effectively with agentic coding tools, putting a real security pass on internal software, and adding just enough engineering discipline to keep small tools from becoming the next thing nobody wants to touch.
Agentic AI Programming for Python: The most direct match for this episode. It covers working with AI that reads your whole codebase, runs your tests, and formats your code, plus the guardrails, roadmaps, and workflows that separate disciplined agentic development from vibe coding, on both greenfield projects and legacy systems.
Python Web Security: OWASP Top 10 with Agentic AI: This is the "quote hire a pen tester for the little app" idea made concrete. You work through the OWASP Top 10 with Flask, Django, and FastAPI examples and build a reusable Claude Code security agent that audits a codebase in minutes.
Just Enough Python for Data Scientists: For the analyst or data scientist who has the domain knowledge and wants the engineering half of Booth's unicorn. Clean reusable functions, importable packages, git, debugging, reproducible environments, and how agentic tools speed up refactoring, docs, and tests.
Overall Takeaway
The most useful thing in this conversation is a reframe. The question is not whether an AI can build software as well as your best engineer. For the vast majority of software inside a company, the honest comparison is against nothing at all: the tool that was never built, the dashboard nobody polished, the app nobody documented, the review nobody commissioned. That is the dark matter, and it has been sitting there frozen for years behind two rules that made perfect economic sense right up until the cost of change collapsed.
What Michael Booth adds is the discipline that keeps this from becoming a mess. Yes, you can build a lot of good things quickly, and yes, you can build a lot of bad things just as quickly. The difference is whether you lock the machine down with Ruff and type checkers and real tests, whether you write down what you are doing and why, whether the tool has an owner who will fix it when it breaks, and whether you can turn it off. Those are not new practices. They are very basic software disciplines, and they are exactly what lets you move faster rather than slower.
So pick something small. The app three people use, the onboarding script that fails half the time, the report someone assembles by hand every Friday. Treat it as an experiment, apply your own critical thinking to what comes back, and see what you learn. The teams that quietly do this over the next year are not going to have a dramatic launch to point at. They are just going to have a hundred small things that work better than they did, and a growing sense of what is actually possible now.
Links from the show
Michael Booth: github.com
Talk Python AI Integrations: talkpython.fm/blog
From Hyper-Personal to Hyper-Team Software: Small Team-Built, AI-Assisted Tools Inside the Enterprise: www.databooth.com.au
What hyper-personal software looks like (MK's article): mkennedy.codes
Databooth Site: www.databooth.com.au
Wall Street just lost $285 billion because of 13 markdown files: martinalderson.com
SaaSpocalypse is real but everyone is panicking about the wrong thing: www.reddit.com
Warp Terminal: www.warp.dev
Watch this episode on YouTube: youtube.com
Episode #558 deep-dive: talkpython.fm/558
Episode transcripts: talkpython.fm
Theme Song: Developer Rap
🥁 Served in a Flask 🎸: talkpython.fm/flasksong
---== Don't be a stranger ==---
YouTube: youtube.com/@talkpython
Bluesky: @talkpython.fm
Mastodon: @talkpython@fosstodon.org
X.com: @talkpython
Michael on Bluesky: @mkennedy.codes
Michael on Mastodon: @mkennedy@fosstodon.org
Michael on X.com: @mkennedy
Episode Transcript
Collapse transcript
00:00 Every company has one.
00:01 The little internal tool that Jane built back in 2021, and then Jane left.
00:06 Nobody understands it.
00:07 Nobody touches it.
00:08 There are two unwritten rules around this internal software.
00:12 First, if it's working, don't change it.
00:16 Second, if you break it, you bought it.
00:19 That's Dark Matter Enterprise software.
00:21 For every app that you can actually see, there are tens of these sitting in the shadows, frozen.
00:27 Michael Booth thinks that just changed.
00:29 He read my article on hyper-personal software and ran with it, writing about hyper-team software.
00:34 Small teams inside big companies finally building the tools that were never going to get built,
00:39 or modernizing the ones trapped in the 90s.
00:42 We cover where this works, where it quietly goes wrong, and the guardrails that keep it from turning into a mess.
00:48 Let's get into it. This is Talk Python To Me, episode 558, recorded July 15, 2026.
01:11 Welcome to Talk Python To Me, the number one Python podcast for developers and data scientists.
01:16 This is your host, Michael Kennedy. I'm a PSF fellow who's been coding for over 25 years.
01:22 Let's connect on social media.
01:23 You'll find me and Talk Python on Mastodon, BlueSky, and X.
01:27 The social links are all in your show notes.
01:29 You can find over 10 years of past episodes at talkpython.fm.
01:33 And if you want to be part of the show, you can join our recording live streams.
01:37 That's right.
01:37 We live stream the raw uncut version of each episode on YouTube.
01:41 Just visit talkpython.fm/youtube to see the schedule of upcoming events.
01:46 Be sure to subscribe there and press the bell so you'll get notified anytime we're recording.
01:50 This episode is sponsored by Sentry's Seer.
01:53 If you're tired of debugging in the dark, give Seer a try.
01:56 There are plenty of AI tools that help you write code, but Sentry's Seer is built to help you fix it when it breaks.
02:02 Visit talkpython.fm/sentry and use the code talkpython26, all one word, no spaces, for $100 in Sentry credits.
02:11 Talk Python and Python Bytes both now have MCP servers.
02:14 Point your AI at 10 plus years of Python episodes, transcripts, and show notes.
02:19 Free.
02:20 click mcp in the nav at talkpython.fm and at pythonbytes.fm Michael welcome to Talk Python To Me great to have you here it's a great name I think this is the
02:29 the Michael square there's a lot of things we can do with this is going to be really fun I think
02:34 Michael squared is the most I don't think I've ever had a Michael cubed on the show with three
02:38 Michaels but yeah it's Michaels across the board or it could be Michaels all the way down like
02:42 turtles yeah it's going to be fun whatever it is and thanks for having me you know what I saw your
02:46 article. And I thought, oh, we got to talk. So you wrote an article called Hyper Team Software.
02:53 And right before that, I wrote a blog post, an article called Hyper Personal Software.
02:58 And we were both, I could tell we were both thinking kind of in the same ways and
03:02 your article riffed off of mine. And so I thought, well, let me try to do a little bit of like
03:07 technical jujitsu here. You wrote an article off of mine and I'm going to have you on the show to
03:12 talk about your article and like I said Michael's all the way down. Your article really resonated
03:18 when I had a look at it the first time. Yeah well thanks. We're going to talk about we've got a
03:23 couple of names here so mine was hyper personal software because I wrote this for me. Yours is
03:28 hyper team software because the same concept applied to the enterprise honestly is way more
03:34 powerful than anything that I'm doing although I'll talk about some of the things I'm doing and people
03:37 can decide that but the potential for what you can do to make companies better and teams work
03:42 better is tremendous. And I honestly feel like it's an opportunity squandered for a lot of folks. So
03:49 hopefully you can inspire them to, you know, crack the door open a little bit and see what they can
03:54 do. Coding assistants are changing the world pretty quickly, right? So in good ways and bad.
03:59 In good ways and bad and over and over again, right? For example, six months ago to today could
04:06 be a totally different experience of what's, how things work or how well they work or what's
04:10 possible and so on. So yeah, it's just, I don't know. It's a weird time, Michael. It's a weird
04:15 time. It is a weird time, especially when you've been doing it for a while. It's very weird.
04:19 Exactly. I mean, I've been programmed for over 25 years in tech and I feel like you must be in a
04:24 similar time journey there. And I don't know, weird. Just so many times I've seen technology
04:31 come up that, oh, this is the thing that's going to kill programming. This is going to be the end
04:35 of programmers, UML, drag and drop, visual basic, low code, no code, et cetera. And all those things
04:42 are fine, but they're absolutely not the end of software. I don't think coding agents are either,
04:48 but they're certainly the biggest dent that they can put into software is anything that's come along
04:52 before it. Yeah. The speed and scale is sort of interesting, but sometimes you can just do a lot
04:57 of bad things much faster. Yeah. I mean, that's a big debate, right? Is it, is, is our agentic
05:02 coding tools. Are these amplifiers or are they skilled little separate things that do their own
05:07 work? I think there's a case to be made for amplification to a large degree. Before we get
05:11 into all that, let's just hear a little bit of background about you. Tell us about yourself.
05:15 I started off sort of academic life as doing a PhD in computational chemistry. I've worked in
05:23 quantitative finance for a long, long time. More recently, I started the data booth consultancy
05:28 things. So just the brand for me working as a single consultant and I've been doing that sort
05:34 of coming out of COVID, I decided to do something different. So yeah, about the last five years,
05:39 I've been doing that. Computational chemistry, huh? Are you familiar with a program called
05:43 HyperChem? I think I am actually, that's pretty old. We're talking 90s. I mean, I think we're
05:49 talking 90s. Yes, definitely 90s. So I finished my PhD in late 90s. I vaguely remember the tool,
05:55 But I vaguely remember chemistry now as well.
05:57 I studied a lot of chemistry and I loved organic chemistry.
06:00 And I found this program called HyperChem and it was just so incredible.
06:05 It was like the Google Earth equivalent of complex chemistry.
06:09 And wow, was it a neat thing to play with.
06:11 And I figured maybe it's like right around a similar time frame.
06:14 Yeah, I do remember it now that you mentioned it.
06:17 Organic chemistry was my most unfavorite element of chemistry.
06:21 That's why I did theoretical because experiments are much easier to control on a computer than real life.
06:26 And organic chemistry smells bad.
06:28 It does.
06:29 Honestly, I would tell you that probably is the reason that I didn't work in chemistry is like I'd get headaches all the time from like the super volatile chemicals and stuff.
06:37 I'm like, if I did this every day, I don't know what this would do to me, but it wouldn't be good.
06:40 So let's go do math.
06:42 Math doesn't hurt physically.
06:44 Yeah, I did math and computing in a chemistry school.
06:47 Give us a bit of information about Data Booth.
06:50 You've got some nice articles there. You've got some consulting. Yeah, just tell us about DataBooth before we move on.
06:55 As I said, coming out of COVID, I decided to do something different. I've been working for others for a long time.
07:01 So I thought, and I'd also directly before this been reviewing a lot of models and things that are used in finance.
07:08 So I thought it'd be nice to actually build some things again. I sort of identified data science as a place to hang out.
07:14 I did a boot camp in Oakland, actually, in 2017, and just decided this was sort of a growth area.
07:21 I think that conclusion was correct, as it turns out.
07:24 Working as a single consultant can not always be easy.
07:27 Being seen are tricky at times.
07:29 I still wanted to just have a go.
07:31 It's the first time I've done something on my own.
07:34 And I've had a chance to do some interesting things.
07:36 So I worked with a lady who does experiments with horses, for example.
07:40 And she trying to understand when a horse is stressed, for example.
07:46 So she had a Raspberry Pi based experiment.
07:49 I wrote code to control the experiment and then I wrote the code to analyze the results.
07:53 So I guess being small, you can make choices to do small projects.
07:58 And for me, that was helping out somebody doing fundamental research.
08:02 And I guess it got me back to my roots a bit.
08:05 So I've been able to do something like that.
08:06 And then I've been able to do stuff in finance.
08:09 Again, I worked for a small media company at one point as well, helping them do some analysis.
08:15 So it's been fun, but it's also, as I say, it can be hard to be seen when you're small.
08:20 I'm fortunate I have a wife who is happy to give me some flexibility around those things.
08:26 So yeah, shout out to her as being a great support.
08:29 I think the connection's a little bit up and down.
08:32 I think it's super important to have a spouse who is understanding of those kinds of things,
08:37 because it lets you do really, really interesting things.
08:39 Like I can say the same thing for my family as well in a slightly different way.
08:42 What a cool story about the horse.
08:45 You know, it's mixing biology and IoT and tech.
08:49 And that's the kind of stuff that you learn a whole bunch in a real short period of time.
08:53 But also you can make a big difference, you know.
08:55 I learned a heap.
08:56 I'd never worked with a Raspberry Pi, for example.
08:59 So it's quite interesting when you don't play in a space, you don't realize just how
09:04 far certain things have advanced.
09:06 So it's pretty cool what you can do on very small devices these days.
09:09 That's Data Booth.
09:10 Very cool.
09:10 People can check that out.
09:11 Let's take it out a bit and talk about sort of internal company software.
09:16 There's a lot of people listen to this show who are not what you would call enterprise developers, right?
09:23 They are students.
09:24 They're maybe data scientists kind of on their own or they work at a research or they work at a startup.
09:32 So give us a sense of what internal software, like these bigger companies, looks like today
09:36 and like maybe before the AI world and so on.
09:39 Every company is different.
09:41 And I'm sure you've experienced that as well.
09:44 Lots of different operating models.
09:46 But I guess enterprises always need to make sure that things are orderly to some degree.
09:52 So when I work on my MacBook as a solo practitioner, I can make decisions about what software I
09:58 want to use, how I want to use it.
10:00 Ideally, when I'm working with data, you've got to make sure that you've got certain controls in place.
10:05 But within companies, those things really matter, right?
10:07 So you do need to make sure that things are secured appropriately, that people only have access to the things that you want them to.
10:15 So I think in that context, there's always going to be sort of overheads and friction on developing any sort of software.
10:22 So you've just got to be aware that you need to allow for those things.
10:26 So I think the idea that we'll talk about coming up is the sense that when you're actually working within a team, within an enterprise, maybe there's certain things that you can do that don't need to impact too many other people.
10:39 And therefore, you can achieve a greater degree of autonomy.
10:43 There's certainly the things that you need to be thinking about within the enterprise.
10:47 So it's not choose your own adventure.
10:49 It's a work within the constraints which are appropriately there.
10:52 And particularly between industries, you can have some industries which have little regulation.
10:58 And then in other industries, they're highly regulated for very good reasons.
11:02 But again, that can provide an additional layer of complexity as you start to think about how you develop and what you develop.
11:10 I've not spent a ton of time working at large companies.
11:12 I worked at a company for maybe six months that had 1,200 people.
11:17 And I got there by being acquired from a company that had 10 full-time employees.
11:21 So it was a little bit of a shift, but I did do professional software training for a long
11:27 time.
11:28 So I taught week-long courses over a hundred different companies.
11:31 And, you know, you just, you get a look inside these places.
11:34 You're like, wow, this is, this one is really different.
11:37 This is like really unique in this way or that.
11:40 But the, one of the, I mean, maybe not with the tech companies, but maybe even so, but
11:45 like for many of the companies, I would say there's, there's two golden rules of a lot
11:49 of this kind of stuff.
11:50 One of them is don't change it.
11:53 It's working.
11:53 Just don't change it.
11:54 You know what I mean?
11:55 And there's something to that, right?
11:57 If it is working, why would you fix it?
11:59 It can be very expensive to change things, right?
12:01 Yeah.
12:01 So maybe we'll call that the principle of least touching.
12:04 Like, just don't touch it.
12:05 It's just leave it.
12:06 It's over there.
12:07 Just don't touch it.
12:08 And that leads to like you're talking about on your MacBook.
12:10 Like, oh, I could use like Python 3.14 and we could pick, oh, let's try FastAPI.
12:14 And they're like, that's cute.
12:15 We use Python 2.
12:16 You're like, huh, really?
12:17 Okay.
12:18 You don't want to change it.
12:18 No.
12:19 Principle of least touching.
12:20 We don't touch this.
12:21 It works.
12:21 When I was in a previous company, they were using 3.7, for example.
12:26 I'm like, yeah, but it's out of support.
12:28 It's end of life.
12:30 Aren't you going to upgrade things?
12:31 And people just stared at me.
12:33 It was like, why would we?
12:35 So, yeah, I guess it's the what you should do on paper versus what you do in reality.
12:39 Both of those ways are right, I think.
12:41 Like, you maybe don't want to mess it up because it is working.
12:44 But at the same time, we had things like Log4J and other stuff where, like, there are really big problems.
12:49 And it's just because people didn't want to update their software.
12:52 So the other core principle, I think, is you break it, you bought it.
12:57 And that's like, if you do touch it and it was working and now it's not working, this
13:02 is now your problem.
13:03 And maybe the person who knows how it works doesn't even work here anymore.
13:07 The person that did it almost certainly does not work there anymore, right?
13:11 If you look at the stats, I think sort of typical tenure, at least these days, is less
13:15 than two years.
13:16 So the likelihood that you're going to find anybody in the team that knows anything is, can be just very, very small, right?
13:24 It could be very small.
13:24 And so that leads to just some interesting gaps or in a more half glass, half full way, like opportunities.
13:31 There's so much of these little tools and these little connectors and these things or just software that was never built because you don't want to take it on if you build it.
13:39 and they're just sitting there inside these huge companies that have so much internal software,
13:45 but they just, they're either really outdated or they're just really ugly and they work clunky,
13:50 but people just like the person who built it left and no one else can even build it.
13:54 So like, be thankful it works, not that it's hard to use, you know?
13:57 So there's just so much opportunity for this concept of hyper team software, I think.
14:02 Yeah, no, I think there's lots of opportunities out there, but I think like any problem,
14:06 you want to think through a solution maybe before you start changing anything.
14:10 I think it's very tempting just to jump in.
14:12 And I think, yeah, taking a few steps back.
14:15 And again, just understanding the scope of the problem that you're trying to solve.
14:19 So like most of life, if you choose a smaller problem to start with, maybe you learn something from it and it helps you as you start to tackle bigger problems.
14:28 I think it's also just, you know, as an aside for people who are looking to advance their career,
14:33 If you can improve these tools and make life better for everybody at the company, that's
14:38 a really high visibility thing to do.
14:39 It used to be all the data scientists had this super annoying thing that they had to
14:44 do.
14:45 And then you spent two weeks on it.
14:46 And all of a sudden, everybody's happier at work.
14:49 And they know that it was because of you.
14:50 Like that shines a pretty good halo on you.
14:53 No, like there's great opportunities to like make a real impact, I think.
14:58 And for me, coming out of a sort of science background, and I try and see everything as
15:03 an experiment in life.
15:05 And I try and put all of my experiments orderly in GitHub, for example.
15:09 You can move quickly and you can experiment and you can identify the paths not to go down
15:16 so that you can actually work out the paths that are worth pursuing.
15:19 And to your point, yeah, there are opportunities to be seen.
15:23 And you can move from that.
15:24 I just wanted to draw a diagram on a piece of paper and convince you that this was a good idea to, well, here's the working prototype or proof of concept.
15:33 And we actually now can talk about, have a real discussion rather than a hypothetical one.
15:38 That's so interesting that you bring that up.
15:39 Because one of the things that I found really challenging working at bigger companies, even not huge companies, so just in general, is you can describe something and people go, oh, maybe that's nice.
15:51 You can tell them you can do it.
15:53 And they're like, yeah, probably you can.
15:54 But then you just take a little bit of time and you show them like, no, look, it's not I could do this.
16:00 It took me two hours to do this.
16:02 If we keep going on it, it'll be really nice.
16:04 Look, wait, you already kind of did this?
16:08 Like, this is actually really amazing.
16:09 I really think that makes a huge difference in how much trust and sort of adoption you get for like your ideas.
16:16 Absolutely.
16:17 Like in a previous employer, you sort of had the business analysts go, okay, let's draw up wireframes and whatnot.
16:24 And then we can prove out this and do that.
16:27 Like, no, we're not using wireframes.
16:29 We're just building it because it doesn't take very long.
16:31 And then people can see it, see the real thing.
16:34 That's not a critique of the sort of BAs at all.
16:37 It's just the world's changed, I think, from when you used to work like that.
16:42 This portion of Talk Python To Me is brought to you by Sentry and Sear AI.
16:46 There are plenty of AI tools that help you write code, but Sentry Seer is built to help you fix it when it breaks.
16:53 The difference is context.
16:54 Seer isn't just guessing based on syntax.
16:57 It's analyzing your actual Sentry data, your stack traces, logs, and failure patterns.
17:02 Because it has the full context, it can A, spot buggy code in review and help prevent issues before they happen,
17:09 and B, identify the root cause of production errors.
17:12 It can even draft a fix and hand the work off to an agent-like cursor to open a PR for you.
17:18 Seer turns Sentry into a complete loop.
17:20 You have your traces, errors, logs, and replays to see the problem, and now AI to help solve it.
17:25 Join millions of devs at companies like Claude, Disney+, and even Talk Python,
17:30 who use Sentry to move faster.
17:31 Check them out at talkpython.fm/sentry and use code talkpython26, all one word,
17:38 for $100 in Sentry credits.
17:41 Thank you to Sentry for supporting Talk Python.
17:44 This like, I think leads into where we're going. There's, we're going to build software in a manner
17:49 that a bank could run on it because that's our company philosophy and our culture way of working.
17:56 We build solid software. That's no frills that works versus, yeah, but do you need to do that
18:02 for the log parsing thing? That's just going to help us see if the server's up. Like, no,
18:06 you probably don't, but don't, you know what I mean? Like it's, it's, I think it's hard for some
18:09 of these groups to kind of break away from treating everything as like mission critical
18:14 and i think that's pretty germane to this conversation you know yeah like i think you
18:18 need to work out what mission critical actually means right and whether certain things particularly
18:23 within teams actually are mission critical because that will sort of help guide maybe how you develop
18:29 things and who should be developing them maybe just picking up on the logging comment there if i
18:35 understood it correctly the argument used to be that putting in sort of baseline good practices
18:40 was expensive and i think that's also changed so the effort to put logging into a piece of software
18:45 is like almost trivial these days right so i think there's a whole bunch of things where people go oh
18:50 we couldn't possibly do that or maybe that isn't warranted but if it doesn't really cost you
18:56 anything why wouldn't you put it in like if it's a point pointless piece of functionality then fair
19:00 enough right we don't want we don't want animated gifs in everything but um yeah the there's just
19:06 basics of good software engineering that i think you should put into sort of any tool that you're
19:11 developing that's a good point it used to be you'd build software and you might have some kind of
19:16 team lead review it for security or run bandit against it or something like that and hope that
19:21 it's kind of okay i mean you don't call this function wrong like um print s print f or something
19:27 or, you know, the unsafe version of YAML load, whatever, right?
19:32 Those are the kinds of things that you should get checked.
19:34 But now, I mean, we basically have Mythos as a co-worker.
19:39 You know, if we subscribe to Claude Code or the new ChatGPT stuff or Codex,
19:43 and you can just say, look, do a security review on this.
19:46 And what used to take like two weeks and a $20,000 pen testing engagement
19:50 is now like an hour or less.
19:52 It's pretty crazy.
19:53 I think you, of course, still need qualified experts to review the results, right?
19:58 So you don't want to outsource your thinking, I would say, to a machine that's very good at multiplying and adding matrices together very quickly.
20:06 The machines bring a lot to the table, right?
20:09 But yeah, even if you're doing those sort of reviews, you want to leverage the machine's capability and not just completely rely on it.
20:16 And I think that's one of the things that we talked about good and bad at the start.
20:19 I think that's one of the things where I get slightly concerned when people seem to be
20:24 outsourcing their thinking that's not across the board. Turn off their critical thinking.
20:29 Yeah, 100%. It is interesting. I noticed the University of Washington teaches a course now
20:33 on critical thinking, which is somewhat interesting, right? Why would you need to
20:37 teach people critical thought? Like clearly, clearly you get taught critical thought through
20:42 a whole bunch of experiences and courses in life. But I think it speaks somewhat to the age that
20:47 you'd actually have an official course on that. I guess that's what experience brings.
20:52 Right, right. And the more you can sort of shortcut your way through literature and philosophy and
20:58 math and so on, then you kind of, I guess, need to make it up somewhere else.
21:01 I think experience plays into this a lot, right? So the longer you've been around,
21:06 just the more things that you've seen them gone wrong, right? And that's not unexpected in life,
21:11 I don't think, because we all like to take shortcuts. But I think, as I often say to people,
21:16 Just choose the right shortcuts.
21:17 This one, I had to come in the middle of the night because the server went down.
21:20 We don't want to do this anymore.
21:22 Or the car broke down on the side of the road because of this.
21:24 We're not doing that anymore.
21:26 You learn the lessons over time, I suppose.
21:28 Hopefully you learn the lessons over time.
21:31 That's the goal, I think.
21:32 As I say, everything's an experiment.
21:34 The question is, will you learn from the experiment?
21:36 Maybe you'll learn.
21:36 Not 100%.
21:37 There's no guarantees.
21:38 Before we jump into the details of your article, I do want to put one more concept out there
21:43 for people that I think can sometimes get lost in the fray as well. And that's the concept of
21:48 competing against non-consumption. So for, put it in context for my example of like, oh, we have a
21:54 pen tester now that can work on this thing. You would hire a pen tester for the most important
21:59 part of your software, but your little tiny, like expense tracking tool that Jane from 2021 wrote
22:07 and left the company, you're probably not going to hire a pen tester for that. But now these days
22:11 with these tools, you can, quote, hire a pen tester for it, and it takes half an hour.
22:17 And it's not that, ah, you probably should have hired, you probably should really use
22:21 like a real person.
22:22 Like there was never going to be a pen test of that at all.
22:25 And now there can.
22:26 Like there will be for the real software, maybe, but not for like these little internal tool
22:30 things that like, I think we're going to talk about.
22:32 So I think this concept of competing against non-consumption is worth keeping in mind.
22:36 Good point.
22:37 I guess the question still is, would you, is there a case to actually use the machine for that? If
22:42 it's sort of free, then I guess, why not? But there's still lots of other things that you might
22:47 investigate, right? So do you actually want to spend some of your token budget on that even?
22:52 So I think, again, it's thinking well about problems and going, what are the actual pros
22:56 and cons here? Or what are the risks that we're trying to mitigate? Okay, let's jump into Hyper
23:01 team software and we're going to talk through your excellent essay from hyper personal software to
23:09 hyper team software small team built ai assisted tools inside the enterprise because i like i said
23:14 i think there's just a gold mine of opportunity here to solve some of these principle of least
23:20 touching and you break it as yours sort of type like things that are a hassle for everyone and
23:25 just no one's going to go near it and no one understands it i think there's a huge possibility
23:29 there. So, but since you said, you know, this is, this is based on my concept of hyper-personal,
23:34 let me just give people a really quick, definite, like a starting point from there. So I said like,
23:38 look, I think there's a lot of people that say, if this AI stuff is so good, why don't we see an
23:43 explosion of software? And my article said, I think there is an explosion of the software,
23:49 but so much of it is like dark matter in a sense. Like you can't see it because it's not worth
23:54 bringing out into a great big flash. It's just a bunch of these little things that solve or polish
23:58 a bunch of stuff. So for my example was I was using the start page search engine and they'd
24:04 started putting ads that would fill like two pages before you even got to the first search result.
24:09 Like I don't mind having an ad. I want to support you, but two pages, this is ridiculous, right?
24:13 Yeah. So I said, I just had Claude build me an extension that would just remove,
24:17 remove the ads just for me. I have no intention of ever shipping it. I just thought, here's a
24:22 problem I have. I bet in 20 minutes I can make it go away, you know? So that sets the stage.
24:28 tell us about this concept here like tell us about your idea apologies for the name first of all
24:33 because i don't think it's particularly the right name but i just wanted to riff off your name so
24:38 that was the initial thinking behind it and also apology for the length of my articles i try not
24:45 to write so much but sometimes that's just what happens so yeah i guess as i reflected on your
24:51 article and thought well if michael can build stuff that solves his problem surely people in
24:56 smaller teams within companies actually have plenty of problems to solve and you don't want to be
25:03 necessarily starting up a capital p project and having lots and lots of people involved which is
25:09 sort of a typical model because of the way companies are structured but if you can just yeah solve a
25:15 small problem and it doesn't involve any sort of other people outside your team or any great
25:21 infrastructure so you're not trying to set up a client server database necessarily to solve it
25:27 you're not trying to include sort of authentication because the security of it doesn't really really
25:32 matter in this case you're just solving a small problem within your team then why not take a
25:37 similar approach like i've already beat to death i think there's tons of opportunity here but you
25:41 know give me your sense of this at my limited experience i would say for everything that you
25:46 look at a company and you see oh here is their product here's their software or at least the
25:50 software that powers their product like if they were a car company maybe it's like their website
25:54 ordering i don't know there's 10 times as many hidden little small somewhat unpolished things
26:01 that would fall into this category that that are critical to making everything work as we've
26:05 discussed offline like there's nothing new here people have always been building little widgets
26:10 to solve problems i guess the game changer here is that you can do this incredibly quickly so you
26:16 can build a lot of good things quickly or you can potentially build a lot of bad things quickly
26:21 so having some sort of vision around how to do it with some degree of discipline I think matters
26:27 but there's always been those solutions out there and I think again with this theme of make
26:32 everything an experiment if you can do experiments quickly then you can work out well is this does
26:36 this actually fly is it actually solving a real problem and well maybe in the past I could do it
26:42 at the 90% level, but nowadays I can build the 99%, still do it 10 times faster than the 90%
26:48 solution. Yeah. It really takes away some of the limitations. You know, you're like, yeah,
26:53 everyone hates this. It's a hassle or it could be smoother, could automate more, but it's going to
26:58 take four weeks and it just doesn't justify someone working on it for four weeks. But if it's going to
27:03 take four hours, you know what? It might be worth four hours, right? There's that unproductive
27:08 afternoon anyway that you had the big meeting in the morning and you can't focus it's just you
27:12 could build it then you know yes and the implication here is that you have requisite skills to build it
27:18 so of course everybody can build software these days and I think that's a great piece of
27:22 democratization that has occurred I would argue that not everybody can build good software or
27:27 sufficient software and that's not a critique of anything other than I think experience matters and
27:33 some degree of training matters still so that you can actually shape things that work together or
27:38 have thought through some of the problems that are coming next. So it's not just about building
27:44 a solution that works for today, although in some cases that may be warranted, but it's also
27:48 thinking about, well, how might this fit in a broader ecosystem? I think we should put the
27:53 whole sort of vibe coding stuff as like, all right, not that. I could use AI to try to do
27:58 computational chemistry, but I'm highly unqualified to do so, like highly unqualified, even though I
28:04 studied it long ago so it's not a knock on me that i'm dumb it's just i don't know chemistry that
28:09 well right i don't i don't already do that so i think it's fair to say like look you have these
28:13 companies full of people who are already programmers and they have i think a really
28:17 important part is the domain name domain knowledge to like understand and solve these problems like
28:22 not just from like writing code but this is actually what we want to accomplish here not just
28:27 this is how the code works make the code better yeah it's always just about making the code better
28:31 But I think, and this hope comes out in the article, is that if you actually have skills and you're embedded more so within a business, then you can understand the business problems by definition much better.
28:45 And I think combining that domain knowledge with if you're bringing the software engineering skills, I think that then becomes a really potent force.
28:53 I'm not saying that like within sort of more technology focused parts of businesses that you don't have people who can now build things much faster and probably better and pen testing and other things.
29:05 But I think my focus here is really just if I'm, if I have the requisite skill, if I can do my computational chemistry in my small team, as it were, what can I, how can I then sort of leverage those skills to really build software that matters for my team and solves, solve those sort of problems, which probably never would have got off the ground before. Or if they did, as I say, they're only getting sort of maybe 90% of the way there and not really nailing the problem.
29:33 Let's talk through some of the main points of your article. So top one here is what this looks
29:38 like in practice. And you give a bunch of good examples. So maybe you could talk through each
29:42 one of these. So the first one is onboarding accelerators. Tell us about that. In most teams,
29:48 onboarding can be a little bit painful. How much of your budget as it were, do you want to spend on
29:53 fixing that problem? So some of it can just be fixed by you have a buddy system and people talk
29:58 to each other better, right? In other ways, it may be technical setup. And if you can actually
30:04 develop a script, which runs for more than one person on one day, so you can build in that
30:09 robustness where a script might have used to have failed, you can now sort of, yeah, just accelerate
30:14 that onboarding. And everybody then is on hopefully a very similar footing, which helps as well. So
30:20 you don't have the, it works on my machine only problem. This is great. And it's such low hanging
30:24 fruit. And I'm sure people can tell that I'm excited about this idea. But as you describe
30:29 that, I'm like, okay, and we could do this and this and this. So for example, I imagine a typical
30:35 onboarding is here is a wiki, go read the setting up your machine, select Mac or Linux or Windows
30:41 or whatever you're doing. I think go down the script, right? You're like, okay, well do that.
30:45 And then we'll see you at lunch. That's one way. But with some of these AI tools, you could build
30:50 like cool little scripts that will go along and do a lot of it, but also do things like check and make sure that you have the right service pack
30:57 because we're not going to allow you to run this old version of Windows and then install this connection to our database,
31:02 potentially even if it is Q&A or whatever.
31:04 And beyond just the setting up, maybe something about the way things are set up changes.
31:09 So you could write a little program that says, here's the things we want set up.
31:13 When it changes, I want you to go look at the machine again and tell me if it's still good or if we need to evolve it right.
31:20 Like that's really hard to do.
31:21 Say like you set it up two years ago, is it still good?
31:24 And I think the other thing is you can actually document it, right?
31:27 So you can easily point the machine at the script that you've just written
31:30 and make sure that the documentation is in sync because some users are not going to be able to like read shell, for example,
31:37 if it's that sort of thing.
31:38 But if you have the documentation which is tightly synced with it, then you've, I think, hopefully got the best of both worlds.
31:45 This portion of Talk Python To Me is brought to you by our AI tools.
31:49 You know that thing where you ask an AI something about Python and it confidently tells you about the library version from 18 months ago?
31:57 Well, we fixed that, at least for our shows.
32:00 Talk Python and Python Bytes both have MCP servers now.
32:04 Connect Talk Python and your AI can search over 550 episodes, full transcripts, every guest, and the entire course catalog of Talk Python courses.
32:13 Connect Python Bytes, and it gets almost 500 episodes of Python news going back to 2016,
32:19 including every link we've ever put in the show notes.
32:22 This means you can say things like, ask Talk Python what astral joining OpenAI means for uv,
32:29 or what has Python Bytes said about Locust, and get a real answer with real links, not a hallucination.
32:36 Name one of our shows in your prompt, and your AI knows exactly where to look.
32:40 And if you live in the terminal, Talk Python now has a CLI too.
32:44 One line, uvtoolinstalltalk-python-cli.
32:49 Then search the episodes, transcripts, guests, and courses without ever even opening a browser.
32:54 It's open source and it outputs text, JSON, or Markdown.
32:58 So it also feeds AI tools that don't speak MCP.
33:01 And here's the real reason I built it.
33:03 Both shows cover around 10 years of Python history.
33:06 The people, the decisions, the packages that took over, and the ones that quietly didn't.
33:11 This enhanced access to all of our information is free.
33:15 No account, no API keys, nothing to buy.
33:18 That history contained in these shows should be there for all of us.
33:22 So visit talkpython.fm and PythonByte.fm and click the MCP link in the nav bar.
33:27 Connect them right now to your agents so that they will be accessible anytime they're needed in the future.
33:32 Hope you all enjoy the access.
33:34 Okay, the next one I'm also super excited about, Internal tool, user experience, polish.
33:39 For somebody like me, I tend to write Python and SQL, right?
33:43 I'll spin up Streamlit if I want a UI for something as an example.
33:47 But I typically think that CSS and similar are sort of dark arts, right?
33:52 However, this sort of opens up possibilities with dashboards and whatnot where they were
33:57 sort of okay, but actually with a little bit of polish, they'll become much more usable.
34:02 And for somebody like me, yeah, I don't want to have that specific set of skills,
34:06 But with a little bit of work with the machine, I can probably get it.
34:10 Not to the point of a graphic designer's sort of capability, but maybe a bit better than it was.
34:15 And people respond to interfaces, right?
34:18 If you have an interface which is perfectly functional but looks rubbish, people don't trust it.
34:24 Back in the day when it was more desktop apps, a lot of Visual Basic type of stuff,
34:28 people would describe these kind of tools as battleship gray.
34:32 Like technically they have a color.
34:34 They just don't care about how they look.
34:37 They're just gray backgrounds with black and white bits, you know, like maybe a green button if you go crazy.
34:43 Who knows?
34:44 You know what I mean?
34:45 And they were just uninspiring.
34:47 No, absolutely.
34:48 I, throughout my career, have done a lot in Excel, right?
34:50 And one can argue the merits of that.
34:53 And I think there's lots of reasons not to like Excel.
34:56 However, lots of people use it.
34:57 So I think if you're working with end users who do have to use it, then even in Excel, you can make a UI,
35:04 which looks not too bad, or you can have one which is just completely horrible.
35:08 So I think it doesn't matter what you're developing the tool in.
35:12 If you can polish the interface, you can get some much better usability.
35:15 And it's simple things like you've got to enter all this stuff in an order,
35:18 but if you enter it in the wrong order, it's really hard to change it.
35:21 But hey, Claude, could you make this drag and drop reorderable?
35:25 Sure.
35:27 Now a drag and drop reorder.
35:28 Like, oh, we have to use to delete it and start over if we entered it in the wrong order.
35:33 Now we just reorder it.
35:34 That's incredible, right?
35:35 That kind of stuff is just so good.
35:37 Claude, you're an expert UX designer, and you need to allow for appropriate accessibility features.
35:44 Can you draw on your best practice knowledge to create a beautiful UX, potentially?
35:50 I haven't done that experiment, but I suspect it probably works.
35:53 It would work fantastically.
35:54 You could say, like, look, I think we wrote this website, and I don't necessarily think it's accessible to blind people.
36:00 Could you go through and just look and see what's not great and just fix that for me.
36:05 Or if you need help, ask me, but probably you can fix 95% of it.
36:09 Like that kind of stuff would be great.
36:10 Yeah, again, I didn't think this is a call out to get rid of all UX designers.
36:14 I think it's to say to the existing UX designers, how do you work with the machine?
36:19 And rather than you only had time to polish one dashboard or whatever it was,
36:24 now you can polish a whole heap of them and get consistency where it's appropriate
36:29 and things like that.
36:30 So people are nervous, right, around the AI is going to take my job stuff, right?
36:34 And I feel that and I see that as I sort of go around places.
36:38 But I think that's the wrong mindset.
36:40 And I'm trying to get the view out there that you can work with the tools to get really good results.
36:45 But you can't not do that.
36:46 You can't say, I want to live five years ago because that world's gone.
36:49 Again, this is a case of like potentially competing against non, what did I,
36:54 I forgot the term I was using, non-consumption.
36:57 It could be this is a tool that was just never was going to get somebody who knew about accessibility
37:01 review it. And now since it's basically free to ask, you might as well ask, like, could you just
37:07 make that a little bit better? Because we do have some folks in our company who would really benefit
37:10 from that, right? Yeah. Because the people who work on the accessibility, they're working on the
37:14 real website and the real tools, you know what I mean? Again, it opens up opportunities for
37:18 inclusion, right? So yeah, I think that's very exciting. Absolutely. There's so many cool things
37:22 like that. All right. Decision pack generators. Typically, you've always got packs going to
37:28 decision makers and governance forums and cut and paste and all those sort of awful things can
37:34 both introduce errors and just be time consuming so i think the ability to pull those sort of
37:40 materials together in a automated way which you probably would never have done because
37:45 the cost of that was just far too high compared to the effort and result you're after so i think
37:51 again whether it's a script which is automating some sort of powerpoint thing again avoid
37:56 PowerPoint at all costs if you can. But yeah, anything to pull together packs, which make it
38:00 accessible to people that have relevant linkages to other documents and stuff. There's just a lot
38:05 of opportunities there. I think that's a huge opportunity, actually. Hyperteam databases. So
38:10 before you jump into this, I think one of the big areas that is not solved with AI very well,
38:16 maybe almost at all, is operational stuff like DevOps. I need to make sure that this server is
38:23 up and running and that we have backups for this and that they run and we can, you know, like just
38:28 this managing multiple machines is not, it's just not really where the AI works that well. I know you
38:33 can make it do these things, but generally it's on local files and chats and stuff, right? So this
38:39 concept of hyper team databases ties into like basically avoiding that, right? Yes and no, I'd say.
38:43 Okay. I'm not a DevOps expert at all. I have very limited expertise, in fact. So that's something I
38:49 I wouldn't talk to. But in terms of, I guess, the thrust of this is really, so databases sort of used
38:56 to be hard, maybe, or harder. I guess, yeah, one of the things I do is use tools like DuckDB or
39:02 SQLite. So I don't have to have the whole client server database thing set up. So if I just want
39:08 to capture data within my team, and it's just my team sharing it, then there's a lot of options here,
39:13 I think. And although DuckDB, that being said, has just released an extension called Quack,
39:19 which opens up sort of client server model.
39:22 But yeah, so I think that's really the idea here.
39:24 How do you allow for just a really lightweight place where you can capture data as part of your application
39:30 or something like that?
39:31 Or you can shove your logs in there or whatever it is.
39:35 Because I think as soon as you sort of side point, but related is as soon as you have observability data,
39:41 you can start to ask questions about, well, how are people actually using this software
39:45 and can we learn from that?
39:47 Right, like time series type stuff and so on.
39:49 Or user flow, they went here, then here, and then they did this.
39:52 And traditionally, it just would have been expensive to do that.
39:55 And nowadays, I try not to use the trivial word too much because it understates the amazing capability of these packages
40:03 to actually deliver functionality.
40:05 I think some interesting ways that this recommendation is really powerful
40:08 is so many of these internal tools that people have, even in a company of 1,000 people,
40:15 there might be six people that need to use this little internal web app.
40:19 They're all the ones who approve expenses.
40:22 And it's about scanning and approving expenses.
40:25 Do you need replica failover Postgres for that?
40:30 Probably not.
40:31 I mean, maybe.
40:31 But if it's really a small thing, it could just be a SQLite file.
40:35 And then the deployment and management of it and backup of it becomes so simple.
40:39 I think there's a lot to do with this.
40:41 Yeah, through late 2018, 2019, three or four years there, this whole push was to sell a whole bunch of infrastructure.
40:50 And I think people spent way more than they needed to.
40:54 And I think you'll see that in the DuckDB sort of materials and mother duck and things like that,
40:59 where they've just called out the fact that most people don't have big data.
41:02 And I feel you're probably overpaying for infrastructure.
41:06 Again, depends on your industry, right?
41:08 some industries have mandated requirements how they handle their data but i think again depending
41:13 on the nature of your business and your team if you've just got a backup of the database
41:18 that might be good enough it's not just paying for the infrastructure you know like we now have
41:23 like a huge spark cluster that does whatever yeah you now need somebody who understands what a spark
41:30 cluster is how to run it what happens if it goes down someone's getting called whereas sqlite is
41:35 just it's a file if the app is running the sqlite quote database is also running in process you're
41:42 good to go that really like fits a lot of these apps well yeah but i think the marketing arms of
41:47 some of these uh big data infrasers just it's i don't know whether it's they're selling fomo or
41:52 what but um i think you see a lot of suboptimal decisions in that space i 100 agree with you i
41:58 think what they're selling is the ability to like dream big like when we get a petabyte of data we're
42:05 going to need to be able to ask questions about it. Like, yes, maybe, but you just launched the site
42:10 and you don't really have any users yet. So later, when you get there, that'd be a great idea, but
42:15 like, don't kill yourself with that kind of stuff early, right? So anyway, that's, I think that's
42:20 neat. All right. Template app patterns. This one is, I didn't expect this one. Tell us about this.
42:25 Yeah. So this was just as I played with some things, it occurred to me that maybe it would
42:30 work okay so it doesn't have to be toml yaml whatever your favorite language is there for
42:36 config depending on what you're doing you might find that there's just repeatable patterns and
42:43 so rather than having to build 10 different little applications you may just be able to again extract
42:49 the relevant things out into config and have a whole suite of applications which are pretty much
42:54 the same architecture do very very similar things and you're just tweaking the config you know a lot
43:00 big internal companies they're like you have to talk to this single sign-on thing that we have
43:05 and you have to log to this thing that every app log you know there's just like this repetitive
43:10 stuff and it seems like it's pretty valuable to document that yeah and again depends on your
43:15 industry depends on internal policies and stuff like that and those policies can be well very
43:20 well founded right but if you're not doing that why would you invest the money because it all comes
43:25 down to money, right? There's costs, there's real costs to all this stuff. So if you don't need the
43:31 bulletproof solution, then go with the one that gives you 99% uptime as it were. Absolutely. And
43:36 that someone who is not an expert can continue to manage. So let's talk about upside, risk and
43:42 unicorns. So what's the upside here, you think? We talked about some already, but give it, give it a
43:47 rundown. I think you can just move faster. Everything's an experiment. You learn quickly,
43:53 you fail quickly you refine and you decide yeah do we do we move forward or is this just an
44:00 experiment which taught us that this is not something that we want to do or as we did it
44:04 we discovered that the team down the road has actually solved this problem and we'll just
44:08 borrow what they've done so but i think sometimes getting away from that piece of paper we drew a
44:13 diagram which nobody can quite decipher to well here's what we're thinking about and the people
44:18 can react to it and go yep we've already done that or no that's a great idea and you guys should
44:24 pursue that the autonomy thing i think matters i think autonomy isn't a bad word i think it can be
44:29 viewed that way at times but i think taking charge of your own team's productivity is not a bad
44:35 thing yeah a lot of times it would be well we're not really the developers that mess with the api
44:40 or the database we just consume that stuff so if we want any of these features we've got to get them
44:44 on board. Whereas here, it's like, actually, we can just build enough of our own stuff. Or maybe
44:50 it's, yeah, but that part of the application is written in Swift. No one here knows how to write
44:55 Swift. Well, you know what? You could bring Cloud in. Cloud could help you work through that portion,
44:59 right? Get that integrated or whatever. So I think there's a lot of power to the autonomy.
45:04 Yeah. And something's that critical within an app, right? So if the UI is sort of good enough,
45:10 maybe it doesn't matter about having that skill. But if you have the skill for the
45:13 sort of internal engine bit, maybe you can work well enough. I think another one to throw in here
45:18 on the upside is the getting over the fear of you touch it, you break it, you bought it kind of thing.
45:25 Because if you're not the one who wrote it and the person who wrote it left, there's a lot of
45:29 unknown. But one thing that Claude and those other Agenic tools are good at is just study this
45:35 application, tell me what it does and what parts are involved in trying to add feature X. It's
45:43 all are like no one understands it too well no one's worked on it but this looks pretty straightforward
45:48 and here's all we got to do you know yeah no the explain functionality is quite amazing isn't it but
45:53 equally if you're going to explain it why not document it yeah keep your document in sync with
45:57 your code right and again the excuse that oh we don't have time to document it's like well really
46:03 if the machine can sort of get you 95 of the way there and you actually review it and just tweak it
46:09 feels like a win-win to me. 100%. It's like, if I can just kick off Clutter Codex and say,
46:15 spend all the time you need to document it, and here's the format where it goes,
46:18 and then I switch another tab and just go do something else, like, you should have documentation.
46:22 I always, as part of the readme or whatever, do the, what are we doing? Why are we doing it? And
46:27 how are we doing it? Because I think that framing is quite often missing from technical descriptions
46:32 of things. So the why is pretty important, I would say. It absolutely is. All right,
46:37 Not all perfect, though. Hidden risk. What are we talking about here?
46:40 Any sort of software developed by end users within organizations is, if not done appropriately well, can just introduce a bunch of risks.
46:50 Unknown dependencies, I guess, is just the idea that, yeah, you don't necessarily, I'm not talking about Python dependencies here.
46:57 I'm talking about you just don't understand how things interact.
47:00 So I think if your tool is, there's dependencies there between tools and stuff, you just want to make sure that they're well understood.
47:08 And that may not be immediately obvious.
47:10 Ownership sort of matters, right, in terms of you do want somebody to own a tool.
47:15 Can you have a team owning a tool?
47:17 Well, maybe you can, but I think you still want that sort of clear ownership.
47:21 So typically teams don't own things, like they might in principle, but you still need a real person.
47:27 And again, depending on what the solution is and depending on your organizational requirements and if you've got regulatory obligations.
47:36 Yeah. Do you have appropriate controls in place?
47:38 And it may be that you just don't really understand that at all.
47:41 If you're an end user, you may not appreciate what data controls you have to have in place or security controls and things like that.
47:49 Although to your point, maybe just get the machine to help some of that stuff.
47:52 For sure. But it's not easy.
47:53 Like, for example, like, oh, it's so great. We can just use SQLite now and that's our database.
47:57 And then somebody's, well, the way we back that up is we just copy the.sqlite file.
48:01 And it has all this PII and HIPAA violations by copying that file to the wrong place.
48:06 And like, it could be bad.
48:07 Data really matters, right?
48:09 And again, on industry, there are some very, very strict requirements on that stuff, as
48:14 there should be.
48:15 As an end user, you may not have appropriate understanding or visibility of those things.
48:20 So there are certainly applications where you need to have sufficient knowledge, right?
48:24 I would add another hidden risk is supply chain badness.
48:28 Yep.
48:29 That's actually been in the news so much lately, right?
48:31 Like with npm and PyPI to a lesser degree, but not to a zero degree.
48:36 But I mean, there's light, it was LiteLLM was pretty bad.
48:40 I was only out for a couple hours, but, and what these agents love to do is they love
48:44 to grab a package off of npm and install it and then, you know, get it.
48:48 Then either maybe there's no checks to make sure that they get installed.
48:52 Okay.
48:53 Right.
48:53 that they don't have a CVE in them, or if they do later, who knows to patch it?
48:58 Because who knows even where it was used, right?
49:00 There's none of that stuff.
49:01 Yeah, so typically enterprises will have solutions in place to sort of have internal mirrors of those sort of things.
49:07 But again, you've got to make sure that you're governing those well, otherwise you can easily miss stuff.
49:11 Right, but does your AI know to use them?
49:13 Because if you're in the far, the more you go toward the vibe side, you just say, just make it.
49:18 I want it to look like Instagram or whatever, right?
49:20 It's like, well, Instagram uses this, so we're going to grab it.
49:22 You need some discipline around this stuff.
49:24 And then the unicorns.
49:26 I like this idea.
49:27 I'm on board with you.
49:28 What is this?
49:28 Sorry about the name.
49:30 Can be a bit pretentious, right?
49:31 The unicorn is just somebody with a pole in the head, right?
49:34 I think the idea is though, if you've, as I sort of flagged before, if you've got somebody
49:39 who has capability around software engineering, but also who has deep domain expertise, they
49:46 bring a lot to the table, right?
49:48 So every person in team brings something to the table.
49:50 I'm a great believer that you try and create environments where people can do their best work,
49:55 but you do have people who quite often have done different things in their careers and therefore
50:00 bring a unique set of skills in terms of just that depth in both software engineering and domain.
50:08 And those people can really, I think, bring a lot to the table in a team, which you don't necessarily
50:14 see a lot of. A lot of people like to stick to a particular single domain. So that's not a critique,
50:19 It's just my observation.
50:21 Yeah, I think having either somebody who has a lot of domain knowledge and programming skills or data science skills, depending on what you're trying to do, that's really, that would be ideal.
50:30 But those people are hard to come by.
50:32 So maybe you create a pair, like this person really understands the problem and has a little bit of skill in programming.
50:39 And this person is really good at programming and they know a little bit of what's going on.
50:42 You know what I mean?
50:42 Like that would be a really powerful combination, I think.
50:45 Those sort of buddy-pair type relationships, yeah, can certainly be another model there.
50:50 And having people talk to each other in teams in general is quite powerful, right?
50:56 And you can get some really good results.
50:58 So, yeah, I don't think you necessarily need maybe the unicorn person, but the unicorn team.
51:03 I imagine this will be companies and teams who adopt this.
51:07 It will probably feel a little bit like if you've never used a linter on your program,
51:12 rough black, something like that, that says you're doing all these things wrong. And you run it the
51:16 first time you're like, there's a thousand and seven problems. You're like, oh my, we can't hire
51:21 somebody for each one of those problems. You know what I mean? Like if those represent sort of these
51:26 apps that could really be improved. But I think with the velocity you can get with a couple of
51:31 people and Claude or Codex on them, you know, you could do this week, we're going to modernize
51:36 these two apps. The next week we're going to modernize those. And after a couple months,
51:40 six months, depending on how big your company is, you'll have a lot of apps that are in good shape
51:44 and don't need much attention.
51:46 They've been running without being touched forever.
51:48 Now they just run better.
51:50 And you would like to think that as you do each of these experiments, you learn stuff, right?
51:54 So I'm probably going to use Ruff, for example.
51:59 But you build up best practices, right?
52:01 So there's no way I let a coding assistant run without locking it down severely, right?
52:08 And I think using your roughs and your TYs and mypyes and all that sort of stuff allows you to constrain the machine so that you're building a much better product each time.
52:18 And I think as you take those learnings out of the process, I think you can uplift the quality of the software that you're building, having really good tests there.
52:28 So just all those what I would consider very basic software disciplines enables you to move both faster and better.
52:34 Yeah, that's really cool.
52:35 I totally agree.
52:36 think you should tell your agent it can't move on until rough passes it can't move on until ty or
52:42 pyrefly or whatever you chose to pick and you set up the config files to like this is how we work in
52:47 our organization we format it like this we do this and so on and then it has to write code that
52:54 conforms to what you're supposed to be doing right because the tool will tell that no you're not done
52:57 like rough returned code one instead of zero try again with those disciplines which move you away
53:03 from maybe your vibe coding to the view of the world.
53:06 It really does allow for some pretty good software to be built.
53:09 But like most things, if you're not scrutinizing it appropriately, you're not applying your critical thinking skills,
53:15 then you sort of are asking for a few problems, I would say.
53:18 All right, you put a little decision tree down here.
53:22 Talk us through where you think this is a good idea and where people should maybe not do it or so on.
53:26 Like walk us through this.
53:28 Big mermaid fan.
53:29 So the diagram is down below.
53:31 But yeah, like if you're not solving, I used to have a boss who said, if you're going to solve a problem more than twice, then you should automate it.
53:38 We can argue the merits of that, but there's something to it in terms of just thinking about a problem.
53:42 So in this case, yeah, are you solving something that's causing some friction, right?
53:48 So why would you solve a problem that is frictionless?
53:51 Sort of as I flagged before, yeah, do you have an owner?
53:55 Like does somebody, is somebody going to care about this problem to the degree that they will actually take ownership of it?
54:00 Because if you can't find an owner, then maybe nobody cares about it.
54:04 AKA, if it stops working, will they make it work again?
54:07 Can we explain what it does in two sentences?
54:08 Well, again, the machine can help you with that.
54:10 But if you can't articulate things to your stakeholders, then why should they care?
54:15 And if you're, I think it's in the Unix world, you sort of have the philosophy of a tool.
54:22 The command line tool sort of does one thing well.
54:24 I think, again, similarly here, you're trying to make sure that whatever tool you're building
54:28 is very, very explainable.
54:30 Do we know how to disable it quickly?
54:32 Yeah, can we turn it off?
54:33 So I guess most of the tools that I'm thinking about here are deterministic.
54:37 So I'm not talking about tools that are necessarily generative AI powered or something like that,
54:42 because you definitely want to kill switch for those.
54:44 But yeah, just if you turn it off, is anybody going to notice?
54:48 And or if people do notice, can you turn it off and quarantine it appropriately?
54:53 Yeah, I think sort of along the same lines here as a parallel would be, could you get it back to the way it was before?
54:59 Absolutely.
55:00 And again, I think documentation can be a good control around some of those things.
55:05 You're just not writing the documentation for, quote unquote, the tool, but maybe making
55:09 sure the process and the problem that you're solving is well articulated.
55:13 And the other one there, maybe the other one's in the article.
55:16 I can't remember exactly where, but just, yeah, does it require that database thing?
55:20 And do you need to do some sort of authentication?
55:23 Because by the time you're doing authentication, it feels to me like in the enterprise that
55:28 somebody probably should be taking a look at things more closely. It's not impossible that you may not
55:34 want an authenticated tool within your team, but you sort of got to talk to people in other teams
55:39 typically if you're doing authentication anyway. So that may be a sign that you're getting outside of,
55:45 not that the tool necessarily is a bad tool, but it's time to talk to others.
55:48 It might be a software project, not just an afternoon project.
55:52 Absolutely.
55:53 Michael, we're pretty short on time at this point. I mean, there's a lot more we could talk about.
55:57 You can see I have many tabs.
55:58 There are many tabs on my...
55:59 I'll say hi again now.
56:01 Yes, exactly.
56:01 The internet's stable.
56:02 Good, yeah.
56:03 It seems like it's been better.
56:04 So this has been really interesting.
56:06 And I think it's going to give a lot of people a lot to think about.
56:09 Give us your thoughts about if there's a company or a decision maker at the company, really
56:14 is probably the right way to, like this will envision, like manifest.
56:18 If there's somebody who's like, no AI at our company.
56:22 I feel like they're missing a big opportunity and it's not a huge risk.
56:25 But what would you tell that person?
56:27 Yes, it'd be interesting to put the statistics on how many companies have not embraced AI to some degree.
56:32 So maybe it's a little bit of a straw person hypothetical now.
56:37 But yeah, I have great enough visibility to know the numbers.
56:41 But you've heard me say the experiment word a lot, right?
56:44 So I guess it's experimenting within your risk tolerances.
56:48 Just try some things within the boundaries that you're comfortable with, right?
56:52 Do some experiments.
56:53 I think for a lot of people, if you haven't used an LLM firsthand, you tend not to believe it's true.
56:58 When I first use one, I'm like, oh, wow, I can write a menu plan for a week with the help of a machine.
57:04 Or I can plan a holiday.
57:05 And I think I was talking to a mate actually during the week about this because he literally has not played with them.
57:11 And I'm like, just do an experiment.
57:13 Go and say, what should I do for my kid's school holiday plan?
57:17 Right.
57:18 Because I think, yeah, until you've done it, you don't sort of believe it.
57:21 So I sort of started with the autocomplete and I'd do pd.readcsv and amazingly it would autocomplete and it's like, wow, this is crazy.
57:30 And then I started to use perplexity for the first time a couple of years ago.
57:34 I'm like, you've got to be kidding me.
57:36 This can't be real.
57:37 And I think as you start to work with the machine and get that comfort, you start to go, I think there's a whole bunch of problems that we could solve.
57:43 So I would say, yeah, experiment and then maybe partner with someone that is looking to help you solve your business problems and be a trusted partner, not somebody who's just trying to extract some money out of your company.
57:58 Yeah, there's so much of that right now.
57:59 It's such a, the whole industry is full of grifters, like selling you like the next best thing.
58:03 Like I get probably 10 emails a day.
58:05 Like, have you considered using AI to accelerate your company?
58:07 Like, yeah, I've considered it.
58:08 Go away.
58:09 I don't want to talk.
58:10 I mean, it's so bad.
58:11 I apologize for those emails.
58:13 I won't send any more.
58:15 I'll add a couple of things here.
58:17 These little internal apps, and this is why I was so excited about your article,
58:21 is they offer an opportunity to experiment in the smallest, lowest risk rung
58:28 of working with the stuff in your company.
58:30 You might have a thousand people and a million customers, but here's the app that only three people in your company use.
58:35 And it could make their life better.
58:37 Try it there, right?
58:38 That would be amazing.
58:39 And the other one is I would say, this is an engineering skill, like writing code, like object-oriented programming,
58:46 like memory management, and so on.
58:48 And if you treat it like a casual conversation with a buddy or whatever,
58:53 you're not going to get the right results.
58:55 So there is engineering around here.
58:57 It's very weird and it's very different.
58:58 But if you apply it, you get good outcomes.
59:01 I have a close friend who's a lawyer, for example.
59:04 And I say to her, yeah, just experiment, right?
59:07 Because like if you run the same problem through the same machine multiple times, you do get
59:12 different answers, right?
59:13 So you've got to understand what LLMs are good at and things like that.
59:16 But as you develop confidence in what's actually being produced and that trust builds, I think
59:21 you'll actually start to solve some interesting problems.
59:23 But if you don't experiment, you won't know.
59:26 There are many levels.
59:27 There are many levels of which this can be employed and are awesome.
59:30 And you can just start easy, start low.
59:32 And then like I said, experiment, try it out, be careful.
59:35 Yeah, it'll be fun.
59:37 All right.
59:37 So last, here's the final word.
59:39 I'll give you the final word.
59:40 People getting started, what advice do you have for them?
59:42 Yeah, so there's lots of hype out there.
59:44 Ignore the hype and just try something.
59:47 In enterprises, most people will have access to like a Microsoft Copilot,
59:52 or maybe if you're on the more tech side, GitHub Copilot or Claude Code.
59:56 I don't think it matters what the tool is.
59:58 Give it a go.
59:59 I use a thing called warp.dev at home, and I tend to use Claude quite often as well.
01:00:05 Again, you learn stuff by using different tools, right?
01:00:08 And no tool is perfect.
01:00:10 No human is either.
01:00:11 So good to try different things.
01:00:13 Yeah, it absolutely is.
01:00:15 So I'm a fan of warp.
01:00:16 Good recommendation.
01:00:17 And yeah, Michael, thanks for being on the show.
01:00:19 It's been great to chat with you.
01:00:20 Thanks for having me.
01:00:21 I really enjoyed it.
01:00:22 Yeah, you bet.
01:00:22 Bye.
01:00:22 Bye-bye.
01:00:24 This has been another episode of Talk Python To Me.
01:00:26 Thank you to our sponsors.
01:00:27 Be sure to check out what they're offering.
01:00:28 It really helps support the show.
01:00:31 This episode is sponsored by Sentry's Seer.
01:00:34 If you're tired of debugging in the dark, give Seer a try.
01:00:36 There are plenty of AI tools that help you write code, but Sentry's Seer is built to help you fix it when it breaks.
01:00:42 Visit talkpython.fm/sentry and use the code talkpython26, all one word, no spaces, for $100 in Sentry credits.
01:00:51 Talk Python and Python Bytes both now have MCP servers.
01:00:55 Point your AI at 10 plus years of Python episodes, transcripts, and show notes.
01:01:00 Free.
01:01:01 Click MCP in the nav at talkpython.fm and at pythonbytes.fm.
01:01:06 If you or your team needs to learn Python, we have over 270 hours of beginner and advanced courses
01:01:11 on topics ranging from complete beginners to async code, Flask, Django, HTMX, and even LLMs.
01:01:18 Best of all, there's no subscription in sight.
01:01:21 Browse the catalog at talkpython.fm.
01:01:23 And if you're not already subscribed to the show on your favorite podcast player, what are you waiting for?
01:01:29 Just search for Python in your podcast player.
01:01:31 We should be right at the top.
01:01:32 If you enjoyed that geeky rap song, you can download the full track.
01:01:35 The link is actually in your podcast blog or share notes.
01:01:38 This is your host, Michael Kennedy.
01:01:39 Thank you so much for listening.
01:01:41 I really appreciate it.
01:01:42 I'll see you next time.
01:02:01 of getting whole.
01:02:03 We tapped into that modern vibe over to each storm.
01:02:07 Talk Python To Me.
01:02:09 async is the norm.