Originally posted in Obics.io Observability vendors have been billing companies per data volume or per node count for many years. Both of those have exploded in the last decade and the vendors have been enjoying a rapid rise in income. But that also created frustration from the customers. The issue of cost is on everyone’s mind when it comes to observability and the #1 reason for switching vendors, even if you are perfectly happy with everything else.

The organizations that work with AI will not be those that replace people the fastest. They will be the ones that use AI to multiply their teams' judgment, experience, and capabilities, without sacrificing quality or accountability. AI accelerates what we can do, but if we don't keep all the other things we do day-to-day in mind, we can suffer extreme hardship from rash decisions or suddenly lose key oversight/control. Let's dig in!

Highlights this week include:

• The August 17 outage, and the work ahead by Vlad Fedorov - GitHub's recent outages underscored the necessity for faster reliability enhancements such as scaling infrastructure, optimizing Azure use, and improving operations to manage increased commits, pull requests, and Actions runs.
• Announcing General Availability of Managed Instance on Azure App Service by Gaurav Seth - Managed Instance on Azure App Service now provides a 99.95% production SLA, expanded regional availability in eight locations, and enhanced integration with Premium v4 features, simplifying enterprise migration of legacy .NET Framework applications with minimal code modifications.
• AKS Hyperscale Control Plane Now in Preview by Richard Hooper - Azure Kubernetes Service now offers a hyperscale control plane preview enabling users to specify tiered capacity guarantees during cluster creation for enhanced performance and reliability.
• Azure Quick Review (azqr) v4.0.0: What You Need to Know by Carlos Mendible - Azure Quick Review v4.0.0 adds VM sizing, Service Health analysis, SQL Server lifecycle management, and region selection capabilities with breaking changes requiring script reviews for upgrade.

And four AI related posts from my colleagues:

• How to trust your AI-assisted data analysis by James Broome - Trust in AI-assisted data analysis hinges on maintaining a clear audit trail of how results are derived, emphasizing the need for reproducible code over polished but unverifiable outputs.
• How to Implement Retrieval in RAG a 3-part series by Carmel Eve - Implementing effective retrieval in RAG is crucial because it ensures only relevant information is used, improving LLM response quality while enabling document citation and continuous knowledge updates. How to Implement Augmentation in RAG: Augmentation in Retrieval-Augmented Generation structures prompts with system instructions, retrieved context, and the user's question to guide LLMs toward accurate, context-aware responses while managing token limits and document formatting. How to Implement Generation in RAG: Generation in RAG depends critically on effective retrieval and augmentation for producing high-quality model responses.

Slashdot reader fjo3 shared this article from Wired: [Flock] has told the public for years that its technology "cannot recognize, identify, or track individuals." It has now built a system that does both, an artificial intelligence tool for police that can identify drivers and track vehicles by their patterns of movement alone, WIRED has learned... Because the system also reaches police case files, 911 dispatch logs, and commercial identity records, those plates can be turned into names, home addresses, and relatives. It can search for people in an area drawn on a map based on nothing more than a physical description... The code describes 45 tools at the AI's disposal, giving it access to plate scans and camera metadata, arrest records, case files, dispatch logs, ballistics results, and commercial databases that contain Social Security numbers, dates of birth, phone numbers, email addresses, relatives and associates. Flock says it is testing the product with a small group of law enforcement partners and describes it as still in development, with capabilities that may not reflect what it eventually sells. It arrives as the company faces bipartisan political pressure, a growing record of officers caught misusing its platform, and a wave of vandalism that has left cameras sawed off and lenses painted over in cities across the country... An officer no longer needs a plate, a name, or a crime to begin: They supply a place, a stretch of time, and a pattern of behavior, and the system is designed to hand back the people who fit... One prompt Flock preloaded into the system reads: "Find me witnesses based on vehicles most seen in [neighborhood] during [last 14 days] during [daily timeframe] *(will not include whitelisted vehicles)." An officer would fill in the blanks and submit it. The output is a list of plates, which other tools in the product then convert into names and home addresses. Another prompt instructs the system to list everyone arrested more than twice in two years for "any offense," exempting only narcotics arrests, and then says to map where those people live, retrieve the calls for service at their homes, and "do a workup on the top three individuals." The prompt begins with everyone in the area who has an arrest record and ends with dossiers on three of them, chosen by the software. A "workup," in Flock's terminology, is a one-command background check. It starts with a name and a date of birth and returns what the department's records and commercial data hold: vehicles, prior listings as a suspect, and, on a second screen, relatives, phone numbers, and online accounts. Wired shares this reaction from a law professor at George Washington University. "It is clear Flock has aspirations far beyond ALPRs to become a digital platform for policing,"

Read more of this story at Slashdot.

Anthropic released its AI-Native SDLC Playbook yesterday. It took me about 40 minutes to read through, and it addresses a question many engineering teams are starting to face:

If AI can write code faster than ever, why does it still take so long to deliver software?

The answer sits everywhere around the code: requirements, design, code reviews, security checks, testing, approvals, and production support.

Here’s a shorter read on how Anthropic suggests solving it.

The Bottleneck Has Moved

Traditional software development processes were designed for a world where writing code was often the longest part of the journey.

But AI has changed that.

A feature that might have taken days to build can now be created in hours.

And then it waits.

It waits for code review. It waits for security review. It waits for testing. It waits for someone to approve deployment.

The code got faster. The overall process didn’t.

To improve delivery, AI needs to be part of the entire software development lifecycle, not just the coding.

1. Plan: Capture the Problem Clearly

Instead of spending days translating conversations into requirements, AI helps capture the original problem in a simple document called intent.md.

It answers basic questions:

• What are we trying to solve?
• Who is affected?
• What constraints matter?
• What questions are still open?

A human reviews and approves the intent before the work moves forward.

2. Design: Build the Specification With Guardrails

Once the intent is approved, AI turns it into a more detailed specification called spec.md.

This is where requirements, architecture, user experience, security, and compliance can be considered together.

Instead of discovering a policy issue weeks later during a review, the system applies those requirements while the specification is being created.

3. Build: Make a Plan Before Writing Code

Before implementation begins, AI creates a plan.md outlining:

• Which files need to change.
• What risks exist.
• What order the work should follow.
• Which tests should confirm the result.

An engineer reviews the plan first.

Once approved, AI can build the feature, and engineers can coordinate multiple workstreams when appropriate.

The benefit is not just speed. It’s keeping the implementation connected to the original requirements.

4. Test: Let AI Verify Its Work

AI should not just generate code and hand it over.

It should run tests, check the build, inspect relevant behavior, and fix problems before the change reaches an engineer.

That feedback loop helps prevent a common problem: faster code generation creating even more manual review work.

If AI cannot check its own output, the engineering team becomes the bottleneck again.

5. Deploy: Speed Up Code Reviews and Security Checks

As AI produces more code, pull requests pile up faster.

That puts pressure on code reviews, security reviews, and compliance checks.

The playbook recommends using AI to review changes against established policies, identify potential issues, and address routine feedback.

Humans still make the important decisions:

• Does the change solve the intended problem?
• Is the risk acceptable?
• Is it ready for production?

Production access, release approvals, and security controls remain in place.

The difference is that engineers spend less time on repetitive checks and more time on judgment.

6. Maintain: Turn Production Issues Into New Work

The lifecycle doesn’t end when code reaches production.

AI can monitor systems, investigate anomalies, and document potential problems.

If something goes wrong, it can create a new intent.md describing the issue and feed it back into the same planning, design, development, testing, and review process.

The result is a continuous loop instead of a series of disconnected handoffs.

What This Means for Engineering Teams

Using AI to write code is only one part of the opportunity.

The bigger shift is applying AI across the full delivery process while keeping human oversight, security, and accountability intact.

If coding takes hours but delivery still takes weeks, the question is no longer whether AI can write better code.

It’s whether your development process has caught up.

Read Anthropic’s full AI-Native SDLC Playbook here.