As AI agents become more capable, there's growing eagerness to develop long-running tasks that operate autonomously with minimal human intervention. However, my experience suggests this fully autonomous mode doesn't apply to most documentation work. Most of my doc tasks, when I engage with AI, require constant iterative decision-making, course corrections, and collaborative problem-solving—more like a winding conversation with a thought partner than a straight-line prompt-to-result process. This human-in-the-loop requirement is why AI augments rather than replaces technical writers.
Jen Abel is GM of Enterprise at State Affairs and co-founded Jellyfish, a consultancy that helps founders learn zero-to-one enterprise sales. She’s one of the smartest people I’ve ever met on learning enterprise sales, and in this follow-up to our first chat two years ago (covering the zero to $1 million ARR founder-led sales phase), we focus on the skills founders need to learn to go from $1M to $10M ARR.
We discuss:
1. Why the “mid-market” doesn’t exist
2. Why tier-one logos like Stripe and Tesla counterintuitively make the best early customers
3. The dangers of pricing your product at $10K-$20K
4. Why you need to vision-cast instead of problem-solve to win enterprise deals
5. Why services are the fastest way to get your foot in the door with enterprises
6. How to find and work with design partners
7. When to hire your first salesperson and what profile to look for
—
Brought to you by:
WorkOS—Modern identity platform for B2B SaaS, free up to 1 million MAUs
The Art of Virtual Synth Design II : Surge XT : Open Source Powerhouse !
"It's fun working on stuff that works!"
Hosted by Vin Curigliano of AAVIM Technology, I am joined by guest co-host Pete Brown of Microsoft and special guest Paul Walker, aka BaconPaul , who is a maintainer and one of the largest contributors on the Surge Synthesizer Team, and also a contributor to several other open source audio projects, including the CLAP plugin standard
We discuss Pauls early history with music and technology , and how he found his way to joining and forming the Surge team, and his ongoing role there.
We cover the history of Surge XT, and its initial development by Claes Johanson which he sold as a commercial product via his original company Vember Audio ( Released in 2005). We discuss how the development eventuated going the open source route , and how that makes it unique regards allowing access to the source code to all developers, over more traditional closed loop development of other major synths.
We discuss how the Surge Synth Team formed, the importance of the team dynamic and tools, (both technological and sociological) , other projects in the Surge Synth Team beyond Surge XT, and the constantly expanding catalogue.
We take a deeper dive into the features and direction of Surge XT, its unique architecture and feature set, and discuss area's like MPE, CLAP, MT-ESP (Microtuning ), accessibility, etc.
We also discuss the current state of Music Technology and the incoming zeitgeist being driven by AI, and much much more.
In our previous article Microsoft Dev Box Creation using Terraform, we explored how to create Microsoft Dev Boxes using Terraform. Now, we’ll take the next step: **deploying Dev Box catalogs and synchronizing them with a GitHub repository**. This ensures that your development environments remain consistent, version-controlled, and easily maintainable across teams.
In this article, we will extend the setup by:
Deploying Dev Box Catalogs using terraform.
Synchronizing these catalogs with GitHub for version control.
Why Dev Box Catalogs?
Dev Box Catalogs enable organizations to define, manage, and share standardized development environments — tailored to specific teams or projects. A catalog acts as a blueprint, containing Dev Box definitions, base images, pre-installed tools, and necessary configurations to ensure every developer has a consistent setup.
What Makes Dev Box Catalogs Valuable?
By leveraging Dev Box Catalogs, teams can streamline how they deliver and maintain development environments. This approach ensures developers can focus on writing code instead of setting up and troubleshooting local configurations.
A Dev Box Catalog allows you to:
Define customized development environments with pre-installed tools and dependencies
Maintain consistent configurations for specific projects or teams
Use version-controlled templates to manage changes over time
Terraform installed locally or via Azure Cloud Shell.
Azure CLI installed and authenticated.
GitHub repository for catalog synchronization.
Resources from Previous Blog
You should have already created:
Resource Group
Virtual Network and Subnet
Network Connection
Dev Center
Project
Dev Box Definition
Dev Box Pool
Now we will create the below set of resources as part of this deployment:
Dev Box Catalog
Azure Key Vault
Deploy the Dev Box Catalog and Key Vault to the 'West Europe' location.
Step 1: Create a Dev Box Catalog using Terraform
# This Terraform script creates a Dev Center Catalog in Azure.
#Creating a Dev Center Catalog
resource "azurerm_dev_center_catalog" "catalogs" {
name = "devCenterCatalog"
resource_group_name = azurerm_resource_group.resourceGroup.name
dev_center_id = azurerm_dev_center.devCenter.id
catalog_adogit {
branch = "feature/devCenterCatalog"
path = "/catalog"
uri = "https://github.com/devCenter-org/devCenter-catalog"
key_vault_key_url = "https://${azurerm_key_vault.this.name}.vault.azure.net/secrets/Pat"
}
}
**Explanation of Parameters: ** - `name`: Name of the catalog - `resource_group_name`: Name of the Resource group - `dev_center_id`: ID of the Dev Center resource - `uri`: URL of your GitHub repository - `branch`: Branch to sync (e.g., `main`) - `path`: Directory inside catalog - `key_vault_key_url`: Secure token for GitHub authentication
Step 2: Create Key vault and secure Your GitHub Token
“You can’t mock statics.” “You can’t test private methods.” “You have to refactor first.”
Every .NET developer has heard it. You hit a wall: a static class buried deep in legacy code, a private call controlling your logic, and a testing framework that just shrugs.
This is the story of how we made mocking statics in .NET possible, and why it changed everything.
public static class LicenseChecker
{
public static bool IsValid()
{
return ExternalService.Ping();
}
}
You can’t replace that call. You can’t fake it. You can’t test it – not without rewriting half your system.
Except… you can.
⚡ The Breakthrough in Mocking Statics in .NET
When Typemock started, we wanted to do something outrageous — mock what everyone said was unmockable. We didn’t want developers to be punished for using statics or privates. We wanted testing freedom.
So we did what every great engineer does when told “you can’t.” We found a way.
One line. The static vanished. Your test took control.
🧠 How It Works
Most mocking frameworks take the “safe” route. They force you to change your software to make it testable.
You add interfaces. You create wrappers. You invent abstraction layers that exist only for the sake of testing. You manage endless versions of the same logic.
On paper, it looks clean. In practice, it’s fragile, complex, and full of mental overhead. Every new developer has to understand a maze of fakes and indirections before they can even read your code.
That’s not engineering — that’s bureaucracy.
Complexity is not control. Simplicity is.
Typemock took the opposite approach. We intercept the actual method calls inside the CLR – not through proxies, not through code generation, but through direct runtime interception.
Instead of rewriting your code to make it testable, Typemock lets your code stay simple and still be fully testable. That’s the power behind mocking statics in .NET without refactoring
This innovation was so novel it was granted a U.S. Patent for its design – recognizing it as a new kind of runtime interception technology.
The result? Tests that respect your design instead of dictating it. Fewer abstractions. Fewer layers. More clarity. The simplicity that makes great software readable and great tests possible.
🔍 Why It Still Matters
Most frameworks evolve around language features. Typemock evolved around developer intent – the belief that you should test any code you own, even if it was written years ago, by someone else, under impossible constraints.
That’s why the same engine that once shocked .NET developers now powers AI-assisted test generation, Insights visualization, and deterministic test execution – all still built on that original, impossible idea.
We didn’t just make testing faster. We made it simpler.
💡 Try It Yourself
Stop rewriting code just to test it. Experience the freedom that started it all.
Log in
