Work Sucks

It has been difficult to write the newsletter for a while. It's not that there is nothing to say; far from it - the number of unfinished pieces is becoming an organizational problem. However, dropping a nice, self-contained insight seems incomplete when so much of it stems from the same, unacknowledged elephant haunting everyone's boardroom: 

Work sucks right now.  

Software development, including APIs, feels worse right now not only because software continues to be squeezed of its craft, leaving only quantifiable throughput. It sucks because the proposed relief increasingly feels implicated in the problem. AI tools promise relief from impossible productivity demands, but they also create new dependencies, new security surfaces, and new channels of value extraction.

The result is a strange milieu of moral and professional fatigue, where even everyday routine feels like tacit compliance in building the torment nexus - making work less human, less governable, and less worth doing. 

The Stories Tech Tells Itself Have Changed

In discussing organization change, I've talked about the importance of stories to provide an "animating energy". For web-based development, our stories were about craft, connection, and empowerment for decades. We weren't just moving bits, we told ourselves at conferences and in blog posts; we were positively building new ways of working and supercharging how people interacted with the world. Sure, there was "Move fast and break things," but even then, it was in service of reconnecting you with your estranged bohemian hipster aunt.

That story has collapsed. 

Across the companies I encounter, the pattern is increasingly familiar: fewer people, higher expectations, more dashboards, more automation mandates, and less patience for the slow work of building systems that last. Post-ZIRP austerity did not just reduce headcount. It changed what leadership wanted software work to mean. 

The industry subtext changed from one of empowerment to a stance favoring control and extraction. 

The Productivity "Cure" Feels Like Yet Another Symptom of the Disease

AI tools have been introduced as the solution to this productivity exhaustion - a coping mechanism for the impossible expectations placed on shrinking teams. In API work, this might look harmless at first. Generate the OpenAPI description. Summarize the endpoint behavior. Draft the integration guide. Produce the sample payloads. Create the contract tests. 

Each step is defensible. Each one saves time. But if nobody is preserving the design rationale, validating the boundary, or asking whether the interface expresses a durable business capability, the organization has not improved its API practice - it has only accelerated artifact production to mimic one.

AI did not create the current workplace condition. But it did arrive at the exact moment organizations were already trying to get more output from fewer people, with less tolerance for thoughtful reflection. That timing matters. A tool introduced into a healthy craft culture might extend judgment. A tool introduced into a throughput culture will mostly accelerate throughput.

The unease felt by practitioners is entirely real. Many knowledge workers are being asked (or mandated) to use tools that promise immediate, tactical relief. However, this comes at the cost of making long-term sustainability more problematic. The tools offered as the solution to our burnout are deepening the collapse of the work itself. 

The result is people choosing to leave the industry. 

Rented Capability Is Not Owned Competence

The common critique of AI adoption is often individual and moralizing - worrying that engineers will get "lazy" or develop "AI brain". But from an enterprise tech strategy perspective, the real danger is organizational. 

With the rush to adopt AI chat, workflows, and agents, companies are rapidly outsourcing institutional capability into tools they do not control. Teams are being encouraged to rely on external models for everything from code generation to documentation, analysis, testing, ticket triage, and integration work. Yet the underlying capabilities, pricing models, terms of service, and platforms are at the whim of a (limited, somewhat at odds) vendor ecosystem. 

These AI tools may be new, but the pattern is not. A tool becomes embedded in daily work. The workflow adapts around it. Teams stop investing in the internal capabilities the tool appears to supplement: mentoring junior developers, maintaining clear documentation, preserving design rationale, and developing shared review practices. Then vendor costs rise, terms change, access narrows, and what looked like efficiency reveals itself as a limiting factor. 

The danger is not that AI tools make people lazy. The danger is that they let organizations conflate rented capability for owned competence. 

When efficiency is purchased by increasing dependency, you haven't optimized your architecture; you've just kneecapped your core competencies. 

Every AI Assistant Is an Integration Surface

This should sound familiar to API leaders. From Enterprise Service Buses (ESBs) to microservices, the history of enterprise integration is full of initiatives that began as accelerators and became dependencies. What's different this time around is that AI tools do not accompany the work the way a platform or process might. They produce the work product itself: the code, the documentation, the decisions, the meetings, the tickets, the designs, the reviews, and the explanations. 

This introduces a massive, leaky abstraction problem. Every AI assistant, IDE plugin, browser extension, prompt broker, and model gateway is a hidden integration surface. When a developer hooks an agent into their local workspace, they are introducing a distributed decision-support and data-routing layer across the company's intellectual property. 

We aren't just dealing with "shadow AI" in the abstract. We are looking at source code exposure, document uploads, confidential meeting summaries, and internal APIs exposed to third-party routing with unclear retention policies. The enterprise is introducing a complex, opaque connective layer faster than it can describe, govern, or observe it. 

AI adoption turns everyday work into an integration problem, often before anyone has admitted there is an integration architecture. 

And our systems aren't ready.

The Larger Question Is Not Training Data

This is about so much more than whether AI vendors are able to train new models with what we're giving them. That debate often gets oversimplified into narrow, contractual arguments: Is the vendor explicitly training their base model on the prompts we send them? No, we checked the box? Whew! I guess we're safe!

But focusing entirely on data privacy misses the larger value ceded to the vendors, likely unknowingly. Even when direct training is contractually restricted, every interaction is a signal. Aggregated together, everyday usage provides workflow knowledge, product telemetry, integration patterns, evaluation signals, and market demand. 

You may ask whether the vendor trains on your data. However, the larger question is whether your organization is teaching the vendor what work is worth automating next. In the worst case, we fund our own displacement, paying for the privilege of mapping out our internal efficiencies for external monetization. 

What Craft Looks Like While Waiting for the Bubble to Burst

So where does that leave us?

The responsible position here is not abstinence, and it is not surrender. It is completely unrealistic to say "do not use these tools." I use them. My peers use them. You probably use them in some capacity too. Organizations are deploying them whether the CISO or enterprise architecture team feels uneasy about it or not.

The stronger path forward is to ruthlessly reject magical thinking.

We must treat AI adoption exactly for what it is: a massive bid to not just boost productivity, but  to re-architect the modern workplace - defining who has decision-making authority, holds risk, and captures value.

When evaluating these tools, we have to look past the immediate velocity gains and ask the harder, structural questions:

• What capability is being built internally, and what capability is being allowed to atrophy?
• What data is moving across our boundaries, and what new integration surfaces are we failing to log?
• What dependencies are forming, what are the vendors learning from our workflows, and who ultimately captures the value?

These are not anti-innovation questions. They are the exact architectural, system-level questions people ask when they still believe that the craft of software engineering should matter.

The job is not to look to the past and pine for "the good ole days" that never actually existed. The task is to prevent every remaining form of judgment, craft, and institutional knowledge from being laundered through tools whose incentives we do not control.

Wrapping Up

So that is why the newsletter has been hard to write lately. The individual topics are still there - API governance, AI adoption, platform strategy, developer experience, integration architecture, and so on. But, increasingly, they all point back to the same underlying condition. The work is being reorganized around speed, dependency, and extraction while still borrowing stories of empowerment and innovation. 

Naming that does not fix it. But it does clarify what responsible technical work now requires: fewer magical stories, more structural questions, and a renewed defense of the judgement that makes software worth building.

Till the next edition,

Matthew (@matthew in the fediverse and matthewreinbold.com on the web)