DEV Community: Mark Ajzenstadt

Check out my list of top / best engineering newsletters

Mark Ajzenstadt — Mon, 24 Aug 2026 13:58:04 +0000

Mark Ajzenstadt

Jul 17

Top 26 Engineering Newsletters Actually Worth Your Inbox

#ai #leadership #softwareengineering #productivity

6 min read

forget about the ARR (AI DD)

Mark Ajzenstadt — Mon, 24 Aug 2026 11:34:14 +0000

If you're reading this, I trust the algorithm targeted you because you evaluate software companies for a living. Experienced deal teams love saying they run thorough diligence. I intend to show you why, for AI deals, they don't.

Most of an acquisition's risk surface gets covered by standard financial diligence. Revenue quality, customer concentration, churn cohorts, unit economics, TAM sizing. These playbooks exist because they work. They've killed bad deals and validated good ones for decades.

Technical diligence for traditional SaaS is solid too. Code quality reviews, infrastructure scalability, security audits. Proven. Reliable.

But AI companies are not traditional SaaS companies. The playbooks that evaluate a CRM platform or a project management tool were never designed for a world where the "proprietary technology" is an API call to someone else's model with a frontend on top.

Standard playbooks tell you how much revenue the company generates.

They can't tell you whether the company built what it's selling.

So why did I title this "forget about the ARR"?

All I've been doing is defending the importance of financial and technical diligence. It is important.

But in order to evaluate an AI company, you have to forget about the spreadsheet and open the codebase.

The spreadsheet shows ARR and growth. It doesn't show whether any of it is defensible. Forget everything you think you know about AI company evaluation, because you haven't been taught how to do it. You've been taught how to value SaaS companies, and you're applying the same playbook to a fundamentally different product category. That's what's holding your diligence back.

Quick disclaimer: I embed AI-native engineers into PE-backed firms.

I'm not a disinterested observer. I'm someone who's opened hundreds of codebases behind pitch decks that said "proprietary AI." Some were real. Most were not. I don't have all the answers on valuation. But I've learned a few things about what's behind the deck that might help if you're evaluating your next AI target.

Lesson 1: the pitch deck is a configuration file.

That sounds ridiculous. Let me show you.

A PE firm asked us to review an AI company before close. The pitch deck said "proprietary AI platform." The data room showed $4.2M ARR growing 40% year-over-year. The management presentation had 14 slides on their "foundational model architecture." Detailed diagrams. Proprietary terminology. Impressive.

We opened the codebase.

The "proprietary model" was gpt-4o with temperature set to 0.2. A system prompt. A React frontend. Six hundred lines of glue code any senior engineer could rebuild in a weekend.

They were asking 12x revenue.

The PE firm walked within the day.

I've reviewed a lot of codebases. The gap between pitch and product on this one was the widest I've seen in three years of reviews. No model. No training pipeline. No proprietary data. The entire product was an API call with a UI on top.

The ARR was real. The customers were real. Growing 40% a year. Real.

The AI was not.

You should not look at ARR and assume the technology behind it is defensible. You should open the codebase.

The ARR is real, but the thing generating it might be 600 lines of code anyone can rebuild. "Anyone can rebuild it" is a fundamentally different valuation conversation than "proprietary AI platform."

Bain & Company arrived at the same conclusion from a different direction. They introduced a specialist engineering capability in 2023 for PE diligence. The team vibecodes functional replicas of target companies' software using AI code generation tools, then evaluates whether the product's competitive advantage lives in the code, the data, the workflow design, or the marketing deck. Rebecca Burack, head of Bain's global PE practice, described the difference as "seeing something in 2D versus 3D."

They've built hundreds of these prototypes. In at least one documented case, a PE firm pulled its bid on an analytics platform after Bain's prototype showed the core logic was reproducible.

We do the same thing from the other side. They build replicas to test reproducibility. We open the codebase to test whether there's anything proprietary to reproduce.

The company we reviewed had zero proprietary model logic. Their competitive moat was a system prompt and an API key.

That's not IP. That's a configuration file with a monthly bill attached.

The firms I know who evaluate AI companies correctly are not staring at the spreadsheet while they work. They're reading the code. The spreadsheet shows up as a secondary artifact. A byproduct of the technical reality, not a substitute for it.

This is not a feel-good LinkedIn point about "going deeper." I want you to change your relationship with how you evaluate AI acquisitions.

When you're fixated on financial metrics, every evaluation gets filtered through "what's the ARR growth rate" and "what multiple are comparables trading at." That filter consistently points you toward deals that look good on paper and collapse under technical scrutiny.

When you're focused on what's actually in the codebase, you make decisions based on "what did they build" and "can someone else build it for less." Those decisions may kill a deal in week one, save you from a write-down in year three, and look brilliant in year five. If it's unclear what I mean: the PE firm that hired us for that code review made one phone call after reading our findings. They walked the same day. Saved themselves a 12x multiple on 600 lines of glue code. Do you think they care about the lost deal fees? Probably. But the cost of acquiring a wrapper at platform pricing would've been harder to stomach than the cost of one more diligence workstream.

Lesson 2: the four blind spots your playbook doesn't cover.

The only diligence framework that matters for AI acquisitions: what risks does standard diligence miss?

Four gaps. The overlap between them is where deals look great on paper and destroy value after close.

PE firms I talk to have a financial diligence playbook and a commercial one. Almost none have a technical playbook built for AI codebases.

Gap 1: Model dependency.

If the target runs on a third-party model (OpenAI, Anthropic, Google), you need to know what happens when that provider raises pricing, deprecates the model version, or a competitor ships equivalent capability at 20% of the cost. Valutico calls this "agentic substitution risk" in their 2026 buyer's framework. I call it the thin-wrapper problem. If you can swap the underlying model in an afternoon, the "proprietary AI" is worth the React frontend it's wrapped in.

The company we reviewed scored a 10 out of 10 on this axis. Zero proprietary model logic. Zero fine-tuning. Their moat was a system prompt and an API key. That's a monthly subscription with a nice UI, not intellectual property.

Gap 2: Training data liability.

You acquire an AI company, you inherit how they sourced their training data. The datasets they scraped. The copyrighted material they ingested without permission. Most data rooms I've seen contain nothing on training data provenance.

Bartz v. Anthropic settled for $1.5 billion covering 482,460 books, roughly $3,100 per work after fees. Anthropic was required to destroy the pirated libraries and derivative copies within 30 days of final judgment. The settlement covers past conduct only; it doesn't establish future licensing frameworks.

EU AI Act penalties for prohibited AI practices run to 7% of global turnover or €35 million, whichever is higher. Other violations carry penalties up to 3% or €15 million. Six countries have already issued conflicting interpretations of whether AI training on copyrighted material qualifies as fair use. That creates a liability patchwork that any cross-border acquisition inherits.

You sign the purchase agreement, you sign for all of it.

Gap 3: Talent concentration.

In a traditional SaaS company, losing two engineers is a setback. In an AI company, the model pipeline often lives in three people's heads. I've seen shops where one ML engineer's departure would mean the company can't retrain or update its core product. Standard HR diligence counts headcount. It doesn't map who holds institutional knowledge about the model architecture, whether the training pipeline is documented, or whether a new hire could run it.

One engineer. No docs. 18-month earn-out. You're not buying a company. You're buying a countdown timer.

Gap 4: Integration failure rates.

RAND cited estimates that more than 80% of enterprise AI initiatives fail to deliver intended business value, roughly double the failure rate for comparable IT projects without AI. RAND's own study is qualitative, built on 65 interviews with data scientists and engineers. Treat the number as directional rather than precise.

Separately, MIT found roughly 95% of generative AI pilots returned zero measurable P&L impact. That measures financial return, not technical failure, and the study isn't peer-reviewed. But the direction is consistent.

Acquiring an AI company and plugging it into a portfolio company's stack is a multi-quarter engineering project carrying that same probability distribution. The product won't work on day one. It's an integration project with an 80%+ historical base rate of failure to deliver value.

These four gaps don't show up in the data room. They don't appear in the financial model. They don't surface in customer reference calls. You find them by opening the codebase and talking to the engineers who wrote it.

Be painfully honest with yourself: what does your current diligence process actually evaluate versus what should it evaluate for AI? Where do those two answers diverge?

That's your gap. Everything else is noise.

Lesson 3: this applies to every AI deal, but most firms won't do it.

A quick caveat: not every AI company is a wrapper. Companies with proprietary models, proprietary training data, documented pipelines, and distributed expertise exist. Acquiring those companies is a fundamentally different proposition.

I don't mean that as a hedge. I mean it statistically, practically, and honestly.

The nature of the current market is that there are companies that built something real and companies that wrapped someone else's model in a frontend and called it proprietary. Neither necessarily has bad ARR. Neither necessarily has bad growth. They look identical in the spreadsheet.

The difference shows up in the codebase. Most firms never look.

KPMG's 2025 Technology M&A Survey found that 66% of dealmakers acknowledge technical and AI debt as a concern during deal planning, but only 33% prioritize investigating it during pre-deal evaluation. Thirty-three points between acknowledging a risk and actually checking for it.

KPMG recommends seven diligence dimensions evaluated through an AI-specific lens. Traditional frameworks, they note, "fail to evaluate AI-specific signals."

If you're reading this far into an article about AI diligence, you're probably at least curious about whether your own process has these gaps. Curiosity is enough. You don't need a dedicated AI diligence team or a PhD in machine learning. You need someone who can open the codebase and tell you what's behind the pitch deck.

So open it.

Quick sidebar: many PE firms acknowledge the risk of AI technical debt during deal planning. They discuss it in IC meetings. They reference it in memos. Then they close without a single code review. When anyone suggests adding a technical workstream, the answer is "we're on a tight timeline."

Every deal is on a tight timeline. But the "tight timeline" crowd treats technical diligence like a luxury when it's actually the most asymmetric check in the entire process.

If you knew what was behind the pitch deck before you signed the LOI, you would not sleep. You'd rewrite the deal structure overnight.

Am I admitting that we run these reviews for PE firms as a paid service, and this article effectively argues for the exact thing we sell?

Yes. I'm admitting that. The PE firm that hired us for that code review spent a fraction of what the transaction fee would've been. They saved themselves a 12x multiple on 600 lines of glue code.

But hypothetically, if a firm were to add this one workstream to their process, even once, they'd dramatically reduce their risk. They'd have technical evidence to back up their thesis, and real data to inform their pricing. That's not a luxury. That's the cheapest insurance in the deal stack.

The "tight timeline" crowd acts like it's all-or-nothing. Full 90-day technical diligence or nothing. That's a false binary. A focused code review takes days, not months. You can scope it strategically. The timeline is real. The excuse is not.

Lesson 4: spend money on diligence to save money on deals.

This one took the market a while to internalize.

When you're in deal mode, every diligence dollar feels like friction. You've paid for the financial model. You've paid for commercial analysis. You've paid for legal review. Adding another workstream feels like slowing down a process that needs to close. This instinct persists even after you've seen bad outcomes. You'll want to cut corners, shorten the scope, compress the timeline. This is setting yourself up for a write-down.

When you're in operator mode, diligence spend is deployment, not cost. The goal is to deploy capital where it reveals the truth, not to minimize the diligence bill.

That means hiring the engineering team that can actually read the codebase even though they cost more than a checkbox audit. It means paying for the assessment that takes three extra days, because those three days tell you whether you're acquiring a platform or a prompt.

Invest in the evaluation that breaks your thesis before you invest $50 million based on it, because all returns from diligence capability are exponential. The only thing that's not exponential is the cost of one more workstream.

Firms that lost money on AI acquisitions (I mean this in outcome, not just valuation decline) optimized for closing fast. Firms that preserved capital optimized for evaluating correctly. One depletes portfolio value. The other compounds it. If you can't wrap your head around this one, come back to it after you've seen the inside of one AI codebase that didn't match its pitch deck.

I'm not saying be slow. Understand the difference between diligence spending and diligence investing: one adds to deal cost, the other subtracts from portfolio risk.

Bain understood this. They built an entire engineering capability to vibecode replicas of acquisition targets. That's a meaningful investment. But the alternative, closing on a deal where the core product is reproducible in a weekend with an API key and a frontend framework, costs a lot more.

Lesson 5: the asymmetric bet of walking away.

Most PE firms avoid walking away from deals with strong financial metrics. Some walk from obviously bad deals. Very few walk from deals that look good on paper but fail under technical scrutiny. Another truth that sounds obvious until you check the data: the biggest risk in AI M&A is acquiring something you haven't evaluated.

A smart walk is asymmetric: limited downside, unlimited upside.

Walking away from an AI wrapper with $4.2M ARR growing 40%? Asymmetric. Worst case, the company turns out to be real and you missed it. Best case, you deploy that $50M into something defensible instead.

Closing at 12x revenue without opening the codebase? Not asymmetric. You can inherit a $1.5 billion training data liability. You can acquire a product that one ML engineer can shut down by leaving. You can buy 600 lines of glue code for $50 million. That's not investing. That's gambling, and not the kind with favorable odds. There are more disciplined ways to deploy capital.

Thoma Bravo is learning this lesson at scale. The firm faces a projected $5.1 billion equity loss on Medallia, acquired for $6.4 billion in 2021. Orlando Bravo told CNBC: "We made a mistake." Peak-cycle pricing and overaggressive growth assumptions. The restructuring has become a cautionary reference for the entire 2021-2022 take-private cohort: Anaplan at $10.7B, Coupa at $8B, Citrix at $16.5B. All struck at peak multiples that no longer hold.

PitchBook reports PE software platform buyouts fell to 41% of deal value in 2026, the lowest level in a decade and a 30-percentage-point drop from the prior year. Only seven software platform transactions exceeded $100 million through May 2026. US software deal value is running at about one-quarter of 2025's $156 billion pace. Investors are shifting capital to add-ons and growth equity, which now represent 45% of deal value.

The pullback isn't just rates and credit tightening. Buyers are losing confidence that they can tell what they're buying.

Meanwhile, AI M&A deals grew 90% year-over-year in Q1 2026. 266 deals closed in Q1 alone. Nearly half of all tech deals now carry an AI component, up from one in four in 2024. Private-market AI companies command 8-15x revenue multiples versus 4-6x for comparable traditional SaaS.

But the premium is diverging: companies with proprietary data and embedded AI attract buyers. Pure wrappers without proprietary data, workflow, or distribution advantages are struggling to attract serious interest.

The game is finding deals where you can afford to be wrong about the growth trajectory, but being right about the technology creates defensible value. "Afford to be wrong" varies firm to firm. "Defensible value" varies deal to deal.

Most firms never walk because they're optimizing for the wrong metric: capital deployment instead of capital preservation. You're playing offense in a market that increasingly rewards defense. Evaluate more carefully before committing, because the other side of the table knows you're not checking.

Lesson 6: score it before you sign it.

The most counterintuitive thing I've learned from three years of code reviews: don't sign before you score.

But Mark, I thought you said do diligence. Shouldn't you already know the answer by the time you get to the LOI?

Every firm I've worked with has a version of this story. They had a deal that looked clean. Financial diligence cleared. Commercial diligence cleared. References checked out. They signed. Then they discovered the technical reality. The thing they paid 12x for turned out to be worth the frontend it was wrapped in.

The temptation to sign on strong financial metrics is enormous. When the ARR is growing 40%, when gross margins look right, when customer references are positive, adding another diligence workstream feels irrational. It feels irresponsible to slow down.

This could not be further from the truth.

If you're evaluating something that's working financially, the best move is almost always to open the codebase before you sign. Let the technical reality inform the valuation. Don't interrupt the diligence with a closing deadline. You can take shortcuts on timeline management. But never skip the code review entirely.

Valutico published a four-axis framework for evaluating AI vulnerability in M&A. We run a version across our engagements. Score each axis from 0 (low risk) to 10 (high risk):

Axis 1: Model Dependency. 0 = fully proprietary model. 10 = pure API wrapper. What percentage of core functionality depends on third-party model APIs? What's the contractual relationship with each provider, including pricing terms, usage limits, and termination clauses? If the primary provider raised prices 5x tomorrow, what happens to margins? Can the team demonstrate the product running on an alternative model within 48 hours? What proprietary fine-tuning, training data, or model modifications exist beyond prompt engineering? Red flag: the team describes "prompt engineering" as their moat. That's a configuration file with a monthly bill attached.

Axis 2: Data Moat. 0 = irreproducible dataset with clear provenance. 10 = no proprietary data. What proprietary datasets does the company own, and can they demonstrate legal provenance for each source? Is training data provenance documented anywhere in the data room? Could a competitor with access to public data reproduce the company's model performance within six months? Do data licensing agreements survive a change of control? Red flag: no training data documentation. After Bartz ($1.5B, 482,460 books), this is a liability you inherit on signing.

Axis 3: Talent Concentration. 0 = knowledge distributed and documented. 10 = single point of failure. How many people can retrain or update the core model? Is the training pipeline documented and reproducible by someone who didn't write it? What happens to the product roadmap if the top two ML engineers leave after their earn-out? Can a new hire run the full model update cycle from documentation alone? Red flag: one engineer, no docs, 18-month earn-out. You're buying a countdown timer, not a company.

Axis 4: Substitution Risk. 0 = mission-critical with unique workflow. 10 = commodity automation. Does the product automate a task that an off-the-shelf AI agent could replicate tomorrow? What would it cost a well-funded competitor to rebuild the core functionality? Does the product's value come from the model, the data, the workflow, or the distribution? Red flag: core functionality is reproducible in a weekend with an API key and a frontend framework. We know. We've seen the codebase.

Score each axis. More than one score above 8 means the asking price needs to reflect the risk profile, not the growth rate. Two or more axes above 8 and the deal structure, escrow holdbacks, earnouts tied to technical milestones, acqui-hire pricing, should reflect it. Run this before your LOI, not after.

This applies to capability, too. Don't cash in your deal flow for a comfortable close too early.
Keep evaluating. Keep building the playbook.

The gap between firms that run surface-level technical checks and firms that run full AI diligence isn't 2x. It's the difference between owning a platform and owning a prompt.

The gap between having an AI playbook and not having one isn't incremental. It's the gap between Thoma Bravo's Medallia and walking away from 600 lines of glue code.

Invest in the capability. Build the playbook.

Don't stop improving it until every deal in your pipeline has been scored.

Alright Mark, just drop the Limestone Digital technical diligence pitch. We all know you wrote this as an article because the algorithm is boosting long-form and you embed AI engineers into PE firms.

Fine. The takeaway is:

Stop looking at the spreadsheet and start looking at the codebase. What is the actual technology behind the ARR, and can someone rebuild it in a weekend?

Run the four-axis scorecard on every AI deal: model dependency, data moat, talent concentration, substitution risk. Be honest about whether your current diligence process covers any of it. If it doesn't, add the technical workstream. Invest in evaluation: your scorecard, your team, your process. Score it before you sign it. Don't close early on strong metrics alone.

The spreadsheet shows ARR and growth. It doesn't show whether the company built what it's selling.

The diligence is not the friction. It's the filter.

Point that filter at the codebase, and the real valuation follows.

Every deal I've worked where the firm ran full technical diligence ended one of two ways: they walked away knowing why, or they closed knowing what they bought.
Three years ago we started opening codebases behind pitch decks that said "proprietary AI."

We're still finding wrappers.

P. S. If you're actually interested about what we do at Limestone Digital, feel free to explore our website.

We embed AI-native engineers into existing codebases. Half of our clients are PE-backed.

https://limestonedigital.com or Book a Call

Top 26 Engineering Newsletters Actually Worth Your Inbox

Mark Ajzenstadt — Fri, 17 Jul 2026 15:56:34 +0000

Everyone recommends ByteByteGo and The Pragmatic Engineer.

Don't get me wrong, they're great... but the best engineering writing of the last two years is coming from newer publications nobody's put on a list yet. Here's what survived my filter.

I have a rule: if I haven't opened a newsletter in three weeks, I unsubscribe. No guilt, no "maybe later" folder. It's the only way to keep email useful when every engineering team, indie hacker, and AI startup on the planet is running a Substack.

That rule has consequences. Over the past couple of years it has killed off almost every famous-name newsletter in my inbox — not because they got worse, but because they got comfortable.

Meanwhile, a new generation of engineering publications launched around 2023–2024 started earning their slot every single week. They're smaller, sharper, and written by people still close to the work.

The other thing my rule revealed: AI engineering quietly became its own discipline. Not "AI news" — there are a thousand newsletters rehashing model launches. I mean the craft of building production systems on top of LLMs: agents, evals, brownfield integration, governance, cost. That coverage barely existed two years ago. Now it's the most valuable section of my inbox, which is why it leads this list.

So here's what survived. Twenty-six newsletters, organized by topic, heavy on publications you haven't seen on every listicle. Steal the whole list.

🤖 AI Engineering & Production AI

Two years ago this category didn't exist. Today it's the most important one here, because building with LLMs in production is genuinely different work — different failure modes, different economics, different skills — and general engineering newsletters mostly aren't covering it.

Latent Space — swyx & Alessio Fanelli. swyx literally coined "AI engineering" as a discipline, and this is its watering hole: podcast, essays, and the AINews digest covering frontier models, agents, and the career path itself. The anchor of the category.

AI Foundation — Limestone Digital. The one I'd add first. One tight email every Tuesday, written from inside AI-native engineering teams actually shipping AI to production. Recent issues like "the brownfield problem" (AI in greenfield is easy; AI in brownfield requires real work), "AI governance is not sexy (but it's a must-have)," and "tokens ≠ value" hit the operational bottlenecks nobody else writes about. No hype, no launch rehashes — just what works when the demo ends and the migration begins.

Ahead of AI — Sebastian Raschka. The most technically honest LLM writing on Substack — model architectures, paper roundups, and tutorials from the author of Build a Large Language Model From Scratch. Zero hype.

Interconnects — Nathan Lambert. AI research explained from inside frontier labs: RLHF, post-training, open-weight models. Essential if you build on top of open models.

Turing Post — Ksenia Se. Goes several layers deeper than typical AI roundups, with explainers on LLMs, agents, and AI infrastructure that stay bookmark-worthy for months.

AI Tidbits — Sahar Mor. A practitioner's filter on the firehose. The deep dives on agentic workflows and AI-assisted coding are consistently ahead of the curve.

🧠 Software Engineering & System Design

System Design Codex — Saurabh Dashora. Practical system design through real-world case studies rather than abstract theory. A recent launch that's already a staple for interview prep and architecture thinking.

Hungry Minds — Alexandre Zajac. One system design or AI concept per week, curated from 100+ sources by an ex-Amazon SDE III. The Monday brief format is ruthlessly efficient: one deep idea, a few trends, done.

The T-Shaped Dev — Petar Ivanov. JavaScript/React/Node architecture plus career growth in the AI era. One of the freshest voices (launched ~2024) on staying valuable as a full-stack engineer while AI reshapes the job.

🧑‍💼 Engineering Leadership & Management

groCTO — the Typo team. Most leadership newsletters predate AI-assisted development. groCTO tackles the new questions: measuring productivity when agents write code, restructuring teams, AI-era engineering metrics.

The Engineering Manager — James Stanier. Monthly deep dives on management, org design, and the human side of software, from the author of Become an Effective Software Engineering Manager. His writing on prioritization alone is worth the subscription.

Software Lead Weekly — Oren Ellenbogen. 700+ issues of consistent, high-quality curation on people, culture, and leadership. The most reliable link-list on this entire page.

Level Up — Patrick Kua. Curated reading for EMs, VPs, and CTOs, running for over a decade. Kua's commentary around each link is where the value is.

📈 Career Growth

A Life Engineered — Steve Huynh. Treats your career like an engineering problem to be optimized, from an ex-Amazon Principal Engineer. The promotion-packet and compensation content is uncommonly specific.

Strategize Your Career — Fran Soto. Launched in 2023 and grown fast by being genuinely actionable — every Sunday issue gives you something to do, not just something to think about.

🧰 Frontend & Web Development

Bytes — Fireship. The JavaScript ecosystem's news, twice a week, served with actual humor. Now run by Jeff Delaney, so the entertainment density is even higher. (Most lists still credit ui.dev — that changed.)

This Week in React — Sébastien Lorber. Exhaustive React and React Native coverage from a Docusaurus maintainer, with sharp analysis of what actually matters versus what's just loud.

Web Weekly — Stefan Judis. Surfaces the small web platform features — HTML, CSS, JS, performance, accessibility — that you'd otherwise miss entirely. Consistently delightful.

☁️ DevOps, SRE & Platform Engineering

Platform Weekly — Luca Galante. The flagship newsletter of the platformengineering.org community, with 100k+ readers. If "platform engineering" is anywhere on your roadmap, this is the source.

SRE Weekly — Lex Neva. Curated reliability and incident-response reading that takes the holistic SRE view — human factors and process, not just failover architectures. Running strong since 2016.

DevOps Bulletin — Mohamed Labouardy. Weekly AWS, Kubernetes, cloud security, and FinOps news with original stories and open-source picks alongside the headlines.

Last Week in AWS — Corey Quinn. AWS news with the noise strained out and gently, lovingly mocked. The most efficient — and funniest — filter on AWS's firehose of releases.

📰 General Tech & Daily News

tl;dr sec — Clint Gibler. Weekly AppSec, cloud security, and DevSecOps tools and research, trusted by 90k+ subscribers. The security newsletter for engineers who aren't full-time security people — which is most of us.

TLDR. Byte-sized daily tech and programming news in a 5-minute read, with 13 specialized editions. Subscribe to the daily plus whichever verticals match your stack.

Changelog News — Adam Stacoviak & Jerod Santo. Open source and developer news from two people who've covered the space since 2009. Nobody contextualizes what a project or license change means better.

Programming Digest — Jakub Chodounsky. The anti-overload newsletter: five handpicked articles per week, no filler. The constraint forces the best curation on this list.

What my unsubscribe rule taught me

Look at what survived and a pattern emerges. The newsletters that last aren't the ones with the biggest audiences or the most famous authors — they're the ones with a sharp filter and a point of view. Five links instead of thirty. One concept instead of a news dump. A Tuesday email that assumes you ship production code, not that you collect bookmarks.

The second pattern is the one I'd bet on for the next two years: the center of gravity in engineering content is moving from "here's what shipped" to "here's what works." Everyone can read a model-release changelog. Almost nobody is writing honestly about what happens after — the brownfield migrations, the governance conversations, the gap between token spend and actual value. That's exactly the territory the AI engineering section of this list occupies, and it's why AI Foundation by Limestone Digital has become the first thing I open on Tuesdays: it's written from the side of the work where the demo has ended and the real problems begin.

If you take nothing else from this post, take the rule itself. Subscribe liberally, unsubscribe ruthlessly, and let your inbox become a place that makes you better at your job instead of busier at it. Start with two or three from the AI section, give them three weeks each, and keep only what earns its slot.

And if there's a newer newsletter in your inbox that survived your own filter — I genuinely want to know about it. Drop it in the responses.

Mark A. https://limestonedigital.com