Wrapture is a new project from Graham, who previously developed wrapt (a 20+ year old Python monkey patching library) and built the first version of the New Relic Python agent - the library that instruments your app so New Relic can show you watt its doing.
Wrapture provides the ability to both mock and instrument code in the same toolset. You can use it in tests for "did this method fire" or "when this method fires return this dummy data instead", and you can also use it to instrument your code to measure what's called and how long things take.
It can instrument existing Python code without you modifying that code - you can instead define a TOML file saying which methods you want to instrument and Wrapture will live patch the code for you. This means you can instrument any Python code that you need to run without changing it, and export the results to OpenTelemetry.
Awesome! Thanks for distilling the (significant) value prop and highlighting the author's bona fides, Simon!
It's signal in the noise (which noise includes both the annoying/distracting "mannered" claudisms in the post, and the inevitable complaints in the comments -- which nearly drowned the signal).
EDIT: Also thanks for the link to his index post! Graham's expertise and generosity and suitability as a library maintainer are evident, e.g.:
> Learning it by doing
> Reading about a library only gets you so far, so alongside the posts there is now a wrapture-workshops repository on GitHub containing 24 workshops you can work through to learn wrapture in an interactive workshop format. Each takes one thing you might want to do with wrapture and walks you through doing it in a live JupyterLab session, with the instructions in a side panel whose actions drive the session and check your work as you go. The early workshops track the blog posts, one per post, and the later ones go into areas the posts have not covered yet, such as using wrapture with pytest properly, converting an existing mock based test suite, async code, patching third party libraries, distributed tracing across two processes, and writing an instrumentation package of your own.
> You need nothing installed to try them.
I appreciate how Graham set himself a high bar for what success looks like for his exploration of AI-assisted coding.
A takeaway for me (drawn from what he wrote^1) is that a big increase in velocity can unlock the ability to incorporate things learned along the way into a JIT / as-you-go full redesign (for coherence) vs traditional approach (slower, incremental, features added closer to release can't influence overall design).
Also I'm really impressed by Graham's approach; treating all 3 of (monkey-patching, unit testing, observability / instrumenting / tracing live running apps) as facets of the same whole... it's just beautiful.
Every "experienced software developer with expertise across multiple programming languages and technologies" in 2025:
Currently, I'm on sabbatical (micro retirement) and pondering full retirement. The IT industry has undergone significant upheavals in recent years ... the rapid advancement of AI technologies has created new challenges for experienced developers seeking meaningful work opportunities.
In 2026:
The cheaper cousin. Everything above retained a duration. Sometimes the answer is just a number, and the Counter collector counts operations as they begin and keeps nothing else, which makes it cheap enough to leave running under a whole test suite. Bind a database layer's execute once, register a counter, and give every test a query budget in a fixture, and the classic N+1 regression fails with a number attached rather than slipping through as a test that merely got slower.
How do people not see this? I don’t know if this is a useful library, probably it is. The author is legitimate and accomplished. But it’s hard to disregard that they’re willing to paste barely readable unedited LLM output on their website under their name. Or rather, maybe that they’ve spent so much time talking to Claude that they’ve been warped into thinking this is something approximating normal English for communicating with humans.
I'm really excited about this library.
Wrapture is a new project from Graham, who previously developed wrapt (a 20+ year old Python monkey patching library) and built the first version of the New Relic Python agent - the library that instruments your app so New Relic can show you watt its doing.
Wrapture provides the ability to both mock and instrument code in the same toolset. You can use it in tests for "did this method fire" or "when this method fires return this dummy data instead", and you can also use it to instrument your code to measure what's called and how long things take.
It can instrument existing Python code without you modifying that code - you can instead define a TOML file saying which methods you want to instrument and Wrapture will live patch the code for you. This means you can instrument any Python code that you need to run without changing it, and export the results to OpenTelemetry.
The linked article is part of a series of posts Graham wrote about it. I suggest starting here: https://grahamdumpleton.me/posts/2026/08/introducing-wraptur...
Then hit the index post he just published that links to his others: https://grahamdumpleton.me/posts/2026/09/trying-out-wrapture...
Awesome! Thanks for distilling the (significant) value prop and highlighting the author's bona fides, Simon!
It's signal in the noise (which noise includes both the annoying/distracting "mannered" claudisms in the post, and the inevitable complaints in the comments -- which nearly drowned the signal).
EDIT: Also thanks for the link to his index post! Graham's expertise and generosity and suitability as a library maintainer are evident, e.g.:
I appreciate how Graham set himself a high bar for what success looks like for his exploration of AI-assisted coding.
A takeaway for me (drawn from what he wrote^1) is that a big increase in velocity can unlock the ability to incorporate things learned along the way into a JIT / as-you-go full redesign (for coherence) vs traditional approach (slower, incremental, features added closer to release can't influence overall design).
Also I'm really impressed by Graham's approach; treating all 3 of (monkey-patching, unit testing, observability / instrumenting / tracing live running apps) as facets of the same whole... it's just beautiful.
1. https://grahamdumpleton.me/posts/2026/08/introducing-wraptur...
I’m excited by the library too, but the post was so Claude I had to stop. Actual docs are at https://wrapture.readthedocs.io/en/latest/index.html
Every "experienced software developer with expertise across multiple programming languages and technologies" in 2025:
Currently, I'm on sabbatical (micro retirement) and pondering full retirement. The IT industry has undergone significant upheavals in recent years ... the rapid advancement of AI technologies has created new challenges for experienced developers seeking meaningful work opportunities.
In 2026:
The cheaper cousin. Everything above retained a duration. Sometimes the answer is just a number, and the Counter collector counts operations as they begin and keeps nothing else, which makes it cheap enough to leave running under a whole test suite. Bind a database layer's execute once, register a counter, and give every test a query budget in a fixture, and the classic N+1 regression fails with a number attached rather than slipping through as a test that merely got slower.
How do people not see this? I don’t know if this is a useful library, probably it is. The author is legitimate and accomplished. But it’s hard to disregard that they’re willing to paste barely readable unedited LLM output on their website under their name. Or rather, maybe that they’ve spent so much time talking to Claude that they’ve been warped into thinking this is something approximating normal English for communicating with humans.
Who would have thought that writing like a human would become a moat one day?
lmao. Yep. I guess they all took a sabbatical and decided F** it, lobotomize me, I'm all in.
I read this first and I thought the second example was random words you made up. Nope.