tech – joemac.io

I was originally invited to write this post for Abstract Security’s C2 corner blog. You can find the original post here.

Abstract Security is a vendor re-thinking SIEM and the future of security operations. Abstract uses a “composable” SIEM model that can obtain telemetry from a variety of dynamic sources. You can find more information at their website.

When Chris invited me to write for the C2 corner, I was just about to head out on our annual family vacation to coastal Delaware. Where the access ramps meet the sand at Bethany Beach, you will find that most effective of preventive control: umbrella rentals.

This “shade as a service” vendor offers a clear value proposition: “protect your skin, rent an umbrella.” Looking across the beach, you will see countless umbrellas offered by this vendor in a postcard-perfect scene. In the cybersecurity world, this level of voluntary preventive control adoption would be a miracle. But the strategy is straightforward: offer a product, be visible, make the value clear, and find common ground with your customers.

Deploying and managing your security controls is more difficult than renting shade, but the same rules apply: go where the value is, and align your controls with how your customers experience risk. Employees of your organization are the primary consumers of your security program – that’s your product – because the controls are usually established around their workloads.

Over the course of my career, I have seen the steady pressure applied to cybersecurity organizations to shed the (often accurate) perception that the security team is the “department of no,” and evolve into the “department of how,” with a grounded emphasis on strategic risk management as opposed to a default risk avoidance posture. I see less discourse on strategies or frameworks to actually make that shift happen, but opportunities well-grounded in research are worth unfolding here.

Security as a Product, Not an Edict

Many practitioners and security leaders will enact their charge like an edict: “forsooth, these controls are deployed to protect the business, and we shall have them in place” – the organizational variant of “because I said so.”

I encourage practitioners to shift to a product-oriented approach. “Here’s the risk. The sun can seriously harm you, and here is how we know. Luckily, we can prevent that harm by deploying this control. We will manage the control for you and measure its effectiveness. If it isn’t working, we’ll improve it or find another path.”

At a previous role, my organization had a surprisingly high incidence of malware on removable media (USB drives). As a result, we disabled mounting of removable media on endpoints via our EDR tooling. We knew this decision would be unpopular, so we took the product approach. We conducted internal research to determine how many employees actually needed to use removable media, and why. We then set up an offramp for those employees and set up an approval flow for the use of removable media for circumstances like conference speakers. We clearly defined the problem and presented the evidence to the company in plain English. Were people thrilled? No, but they did accept our findings in good faith and without resentment.

Your responsibilities as a product owner extend beyond control deployment. A product that people do not want to use isn’t a good product. Fostering empathy, a culture of blamelessness, and visibly celebrating wins serves as a worthy investment in leadership capital to be accessed in the unfortunate times where we really have to say “no.”

Supporting Frameworks: From Subjugation to Collaboration

Practitioners have made progress in moving away from the “department of no” and into a role where security teams can drive and bring real value, but many of us are still on the journey to a product-based approach. Early controls were deployed to teams, regardless of whatever impact the control had on their work, or if it was one of a hundred endpoint agents or authentication flows that was mostly security theater, or where the value just isn’t evident to users.

Right now, we’re in the middle, where controls can be built for teams. Secrets detection, for example, is a useful technical control for business data, but it also protects employees from their own mistakes. Accidents happen, which is where we can control the narrative: the detection is a product feature. When paired with a culture of blamelessness, an engineer stopped by a detection will feel relief, not anxiety.

Strive for the next step: build your security program with teams. “Security is everyone’s responsibility” is a common refrain among practitioners, but I rarely see it put into action that rewards rather than penalizes. Your employees should have a stake in the outcome, and they should have the opportunity to shape that product into one they want to use. Resist the urge to use “well, they’ll be forced to use it anyway” as a lever here, and instead explore two product-first ways of thinking.

The first is the “jobs to be done” framework, co-invented by Clayton Christensen and Bob Moesta. Your business is hiring your security program to perform a role, so consideration for both what the business is doing and how your security product canhelp them do their jobs can result in strategic and operational wins. You need not follow the framework to the letter, but consider its principles.

The second is a Scandinavian theory of collaboration called participatory design, which focuses on an iterative and diverse design process where users are encouraged to advocate for their needs. While we can’t accommodate every desire our teams have as they relate to control deployment, where we can’t fully meet a need, participatory design leads us to make meaningful and informed product compromises.

Shaping Your Product-First Approach

These are not ineffective platitudes I learned about in graduate school. Leveraging the jobs to be done framework and participatory design together informed a zero trust network access (ZTNA) implementation project I executed in 2024. We made the problem large, the risk visible, and the benefits clear. We listened to employees, gathered feedback, and knew how to defeat existing pain points while simultaneously enhancing security. Hearing the SVP of Engineering at the time say that the new solution was “way better, faster, and easier” than the old VPN-based solution was a highlight of my career.

Before I wrote this piece I took a look at the other entries in the C2 blog, and they reinforced a theme I have seen across my now 19-year career in technology: the technology is not the hard part. The technology is easier to use and the tools are more effective than they’ve ever been. Organizations have noticed: the bar is higher for security practitioners and teams to leverage these innovations and evolve into generating more value and business alignment. Here’s some career advice: in broad strokes, a career is always smoother when you are where the value is, whether you’re deploying umbrellas or ZTNA.

In security, finding the value and optimizing for it is challenging, moreso than looking good on a beach and selling umbrella rentals. Since I am half Irish and would not look good on a beach selling umbrella rentals, I have to try to solve the cybersecurity problems in front of me, and luckily the problem – mitigating the risk – is similar. Security has profound impacts on the day-to-day operations of the business, and these impacts can coexist with offering a compelling product.

Offer the product teams would want to choose.

“Someday, though not soon, Mr. Bernstein feels a program may be designed that will enable the computer to profit by its own mistakes, and improve…on the basis of its experience against human opponents.”
– Horizons of Science, Vol 1. No. 4. 1958.

In 1960, a hulking new IBM 709 mainframe was installed in the Massachusetts Institute of Technology as part of a 10-year collaboration between MIT and IBM called the MIT Computation Center. While the over one-ton vacuum tube computer’s lifespan was short lived (an improved version used transistors instead of tubes in a notable upgrade), the $2.6m ($25-30m in 2026 dollars) behemoth found a good home at MIT.

So good, in fact, that a system of “time-sharing” called the Compatible Time-Sharing System (CTSS) was developed to enable more than one user to use the computer. CTSS was primitive, but eventually led to the development of Multics, and eventually of Unix at Bell Labs. Time-sharing became a de facto standard to solve the problem of how to enable multiple users to operate the computer at the same time. At least that is how it appeared to work for the user – in reality, the computer offered each user or task a fraction of time in a process called slicing. The financial implications of such a system are obvious: if you know who the user is, and you know how much time they’ve used, you can bill them for it.

Consumption-based time-sharing schemes for what we now refer to broadly as “compute” lasted into the early 1990s, and were featured prominently in Dr. Clifford Stoll’s 1989 book The Cuckoo’s Egg, where Stoll was able to run a complex, lengthy, and at times overdramatic operation to catch a malicious hacker traced back to a 75-cent overage on the Lawrence Berkeley National Laboratory’s computer account. These schemes were eventually displaced by the advent of cheap, widespread, and accessible personal computers.

At least, they were for a while.

“Sooner or later, everything old is new again.”

– Stephen King, The Colorado Kid, 2005.

Generative AI has brought us full circle. We are, essentially, back to time-sharing. We have returned to consumption-based billing for scarce resources, leaving us in an alien and uncomfortable position – one we haven’t experienced in the last 30 years of information technology.

Some will interject here with a counterargument that I see regularly in internet discourse: that cloud computing is essentially time-sharing too, and we have already been full circle since the advent of *-as-a service models pioneered by cloud service providers like AWS. This notion, however, is a misunderstanding of the cause and effect that willed time-sharing into being.

Time-sharing, or any operation that leverages consumption-based billing like generative AI, and cloud computing solve problems that are structurally different for most customers. Time-sharing solves a problem of scarcity (for generative AI in particular, it’s scarcity of cognition), and cloud computing solves a problem of abundance. A core tenet of cloud computing is that its costs are predictable, and in practice is much closer to renting rather than time-sharing. The raison d’être for AWS is simple in retrospect: computers were so cheap, AWS was able to monetize excess compute to customers who were fed up with buying more capacity than they really needed. All AWS did was figure out a novel way for customers to turn many large computers into many more smaller ones on demand. This method took on the name of elasticity, and it worked spectacularly well. Anthropic, on the other hand, makes no claim that you can predict what your token costs are. That it is pure consumption is a feature.

But computers are expensive again. The good times are over.

This essay will not seek to explain why generative AI is computationally expensive, but it doesn’t take a PhD to know that it is, and that’s not the whole story. For the first time in history, video game consoles – of all things – are appreciating assets, which was set in motion before AI agents took over the infernal machine of work. Tariffs, COVID-19, the (more or less) failure of the CHIPS act as a hedge on the global semiconductor machine, and of course, generative AI. All in service of that damn computer.

All have led us back to this point – what’s old is new again. We kneel at the altar of the almighty token.

General purpose technologies don’t create sustainable competitive advantages for their customers in a vacuum. The general purpose tools made available to you by firms, even public benefit corporations like Anthropic, are available to everyone. That’s the point. The Harvard Business Review explores the conundrum in detail in their September 2024 issue. The MIT Sloan Management review addresses it in a similar article in their Summer 2025 issue:

“If a technology is valuable but not unique, then it is not an advantage; similarly, if a technology is unique to a company but not valuable, it is not an advantage. If a technology is valuable and unique to a company but can be imitated by others, then it does not confer a sustainable advantage. AI is unquestionably valuable, but it fails the other two tests because it is neither unique to any organization nor inimitable.”

The late anthropologist Dr. David Graeber also explores this idea in his 2015 book The Utopia of Rules:

“Competition forces factory owners to mechanize production, to reduce labor costs, but while this is to the short-term advantage of the firm, mechanization’s effect is to drive down the general rate of profit.”

In other words, the problem with the AI game is that everyone is playing it.

The most common thread about AI displacing jobs is simply that: jobs are truly being wholesale replaced by AI, and CEOs are seeing the endgame as leaner and more nimble enterprises without the use of those pesky employees, who must be paid, fed, trained, provided healthcare, and all of the other things that make for a fulfilling career.

This may be partially true, but as a technologist myself, I find the argument unsatisfying, partially because of my own experiences in using AI, but mostly because leaders of corporations have insofar struggled to rigorously quantify the impact of AI on their businesses as it relates to human productivity.

As a case study, let’s look at the layoff letter posted on X by Brian Armstrong on May 5^th, 2026, which looks essentially the same as every other one of the letters I’ve seen to this effect:

“AI is changing how we work. Over the past year, I’ve watched engineers use AI to ship in days what used to take a team weeks. Non-technical teams are now shipping production code and many of our workflows are being automated”

The problem with this statement is twofold:

There is little basis for the number of roles eliminated (for Coinbase, it’s about 700 people). Where is the evidence that 700 roles worth of work was replaced by AI? This evidence is conspicuously absent for each case of “AI layoff,” not just for Coinbase.
It’s incompatible with the idea that AI does not provide any sustainable advantage, even though that’s what he appears to be saying in the note. Are your workflows being automated well, or are you just compressing them? Or, when viewed from the lens of this analysis, is this actually an indirect admission that Coinbase isn’t seeing an advantage?

To be clear, I am not arguing that AI does not improve productivity. That is clearly untrue, including in my own experience. This puts insightful employers in an advantageous position – they can leverage employees’ pre-existing skills and AI to develop their real competitive advantage more quickly. So what’s with the layoffs?

The most generous read I can offer on the situation is this:

Consumption-based token costs are significantly higher than companies expected.
Companies must continue to use AI to appease investors and shareholders, who are demanding a return on these investments.
Frontier operators are propped up on a gigantic investment machine, keeping compute costs too high for most companies to deploy models in-house on their own hardware.
The money to pay for the cost of AI has to come from somewhere.
While AI is clearly improving productivity, it is not as good as its biggest boosters say it is.

In summary: operators of frontier models, shareholders, and investors have AI-using companies, to use a technical term, “by the balls.”

If companies were really seeing major returns on their AI investments, they wouldn’t have to justify their expense by cutting labor. Their bottom lines would be boosted proportionally to their AI investments. But that isn’t happening despite, or maybe because of, the market rhetoric about “becoming AI-native.”

I believe this is why managers are now demanding obsessive levels of tracking around AI usage by their workforces. Of course, Goodhart’s law applies: “when a measure becomes a target, it ceases to be a good measure.” Demanding employees use AI leads to…more AI consumption, which leads to higher costs, which leads to more desperate attempts to justify the cost, whether that desperation takes the form of layoffs or other (arguably more) pernicious schemes like cutting benefits.

It has always interested me that there are AI PaaS companies like Base44 and Lovable – the companies that claim they can build entire apps for you using generative AI.

Here’s a question: if AI were really that capable, wouldn’t those companies just sell the apps? Marketing your product as a “platform” is a convenient exit for an uncomfortable “marketing meets reality” truth: the capability is not there. The gulf between an AI-built scaffold and working, maintainable software is massive.

Look, there is certainly no shortage of low-quality SaaS out there, and some of these solutions really are going to be displaced by AI. But the “SaaSpocalypse” predicted by tech pundits feels very far away, and you are right to be skeptical of the idea that AI will simply replace developers wholesale.

I do not know where this ends. In his 2023 book Cointelligence, Wharton professor Dr. Ethan Mollick defines a set of principles for using AI effectively. One of his principles is “assume this is the worst AI you will ever use.” What he means is that he expects the capabilities of AI to continue to improve over time.

I agree. While I hesitate to call this point “a bubble,” we are at an uncomfortable interlude where the capabilities of generative AI are good enough to enhance productivity but not good enough to truly supercharge growth. We are in an earlier phase of generative AI than I think most leaders would like to admit. To get out of this phase, assuming generative AI remains in the lane of a general-purpose technology a few things need to happen.

Organizations using AI need to figure out a way to create sustainable advantages, enhance their existing sustainable advantages, or both. The most likely path to this for most organizations is by leveraging their own data in training the AI, but this path conflicts with structural or even regulatory barriers around how institutional data is shared.
The capabilities of AI need to improve dramatically as a general-purpose technology to create additional opportunities for profit.
The cost of compute needs to decline and/or we need to see increased competition around frontier models in a way that drives down costs.
Per 3, large players may be able to justify running models on their own hardware to escape the time-sharing model.

None of these solutions seem imminent. If you are an employee at a company aggressively pursuing AI, especially a tech company, I think we are in for a bad time save some miracle of progress in AI development.

While we are in this moment, here is my practical advice for you as an employee trying to navigate it: if you are an AI skeptic, this is not the right time to showcase your perspective in view of your employer. YouTuber Mo Bitar has a hyperbolic but achingly funny video about this moment, and it was one of the reasons I decided to write this essay. It’s aching not because it is so funny, but because of how right he really is.

I say all this because the moment is currently seeking an answer to the question of whether AI will durably replace human labor or if it will just raise expectations for performance and output for its users. No matter what the answer to the question is, “I don’t want to use AI because it sucks” fails. You will be using AI. Pandora’s box is wide open. I would again turn you to a suggestion from Dr. Mollick – “always invite AI to the table.” You’ll laugh, you’ll cry, you’ll be surprised at how capable (or hopelessly incapable) it is for a given task.

Time-sharing died when the computer was made available, portable, and reasonably reliable to everyone at a low cost. Microprocessors brought in a new era of affordable and plentiful computing. The microprocessor may yet save us again, as history repeats itself.

What if the solution is not, as leaders like Sam Altman say, “AI as a utility,” but lightweight and portable models that are tailored to the specific purpose of the person in control of the model, and tailored to the specific needs of the company deploying the model, or that particular version of the model?

We solved the problem of wasted compute with cloud computing – the excess capacity was repackaged and efficiently resold as smaller, purpose-built technologies like EC2 instances, S3, and RDS. Where is the wasted compute now? I would suggest that it is on your developers’ endpoints. The $3500 MacBook Pros with 48GB of RAM. Why are we not taking advantage of that capacity with a purpose-built model? Small, lightweight, and developer-centric. No consumption. As legendary game developer Brian Moriarty says: “The treasure is right there.”

This is just an idea. Will it work? I don’t know. But we need more of them, and probably not from AI. A few things are abundantly clear: we must reduce costs, we must optimize for competitive advantage, and we must realize that AI as a general-purpose technology is not quite at the point where we are able to reap revolutionary benefits, nor do we know if it ever will be.

Until we figure that out, we will remain stuck in the AI middle, time-sharing with Claude, the computer that profits by its own mistakes.