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,"
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.
This week, I had to write CSS for a design where a list of elements got a bit of extra design treatment if there were at least three nested items inside it.
<!-- Base design --><ulclass="magic-list"><li>Item 1</li><li>Item 2</li></ul><!-- Extra design --><ulclass="magic-list"><li>Item 1</li><li>Item 2</li><li>Item 3</li><li>Item 4</li><!-- ... --></ul>
.magic-list:has(>:nth-of-type(3)){/* extra styles... */}
This checks if the .magic-list has a direct descendant in the third spot. If so, it applies the styles. If not, it skips them. This works for any number of nested items above three.
Opposition to AI data centers has swung from 51% to 75% in six months, making it one of the fastest-moving bipartisan issues in recent polling. NLW unpacks the real drivers behind the anger — grid and water fears, NDA secrecy, a decade of big tech distrust, and communities feeling stripped of agency over their own future. Also covered: why moratoriums solve nothing, what Quincy and Loudoun County prove about the upside, and the compromise path voters actually prefer.
BONUS: When Burnout Looks Like Productivity—The Hidden Risk to Your Team's Innovation Capacity
In this BONUS episode, Alison Campbell shares the research that reframes burnout as a measurable threat to a team's ability to innovate. We learn why your most productive people may be your biggest innovation risk, how to spot capacity draining out of a team before the output drops, and where Scrum Masters have the leverage to protect the one thing that keeps teams building: the space to think.
From the ER to the Research
"I kept normalizing the stress, the exhaustion, eventually the stomach aches as, well, this is just the price of entry. This is part of being a busy, full-time executive and working mom."
Alison spent nearly twenty years in corporate roles—moving from finance to e-commerce to HR tech, with analytics as the through line and a love for the building phase inside companies. The pandemic was the turning point. With two young kids at home and a global team to hold together, she pushed through eighteen months of warning signs she had normalized, until severe stomach pain landed her in the emergency room needing surgery. That was the stop moment. What started as private shame—the feeling that she alone had failed while everyone else "had it all figured out"—became a research question the moment she started talking about it and heard the same story mirrored back from colleague after colleague. This wasn't one exhausted mom at a hard moment. It was a design and systems problem worth studying.
When Burnout Looks Like Productivity
"Even when that innovative work behavior was high, when burnout was high, that segment of our sample had the lowest innovation capacity of the entire group we surveyed."
The counterintuitive finding at the center of the research: activity, busyness, and visible output stayed high even when burnout was high. Burnout doesn't always look like withdrawal, disengagement, or someone who has already collapsed. Often it looks like the person still shipping, still moving fast, still showing up to every meeting—while the deeper capacity underneath quietly erodes. Alison's study measured this through two separate constructs, and the gap between them is the whole point:
Innovative work behaviors — the visible signs of innovation: coming to meetings, generating creative ideas, being present and active.
Innovation capacity — the cognitive and strategic bandwidth to hold complexity, make hard decisions, collaborate well over time, and translate ideas into durable, long-term company value.
The people scoring high on visible activity while burned out were exactly the people whose capacity to do the deep work had already dropped the lowest.
What Innovation Capacity Actually Is
"Not just, am I coming to the meetings, am I visibly showing up—but do I have the ability to translate these ideas into durable, long-term company value?"
This isn't only about product features or new products. Innovation capacity shows up in every layer of the work: the micro decisions, the macro strategy, the processes, the willingness to try a new tool or approach at all. Innovation capacity is present when people have the mental space to be curious, to ask questions, to explore, to want to play with something new. When that space disappears—when the answer to every new idea is "we don't want to hear no, we don't want to hear that there's a problem"—the work turns tactical and reactive. People narrow their thinking and just chip away. That's the moment you stop getting the best from your team, even though they look every bit as busy as before.
The Signals to Watch For
"Can I name what is blocking progress? Do I feel safe enough to say, this is what's at risk? Or is this a culture where we don't talk about what's not going according to plan, and we just keep our heads down and keep going?"
The conditions most strongly correlated with high burnout and low innovation capacity clustered around a few themes: uncertainty—especially about the role of AI in someone's work—unclear meeting outcomes where a lot of meetings produce little clarity on the next action, and a general cluster of fear and ambiguity. The fix isn't to make everything finite and remove all agility—that's the wrong message in a genuinely uncertain world. It's to provide bounds. Communicate clearly about what you do know and why, so teams can operate confidently even through an uncertain pivot. For Scrum Masters, this maps directly onto AI adoption conversations: when curiosity turns into anger, frustration, or blanket anti-AI resistance, that's a signal worth investigating. Get at the why—both by taking a genuine pulse on the team, and by making sure the team understands the bigger-picture why the whole company is driving toward. As Alison put it, strip it all down and you land on good communication and psychological safety: the conditions where people can name what's blocking them and still do their best work.
Fragmented Work and the Myth of the Finished List
"It's about baking in periods of rest and reset, and being comfortable with this notion that the list is quite literally never going to be done."
Fragmented work—context switching, too many things in flight, the sprawl of tools and issue trackers—came up as a real innovation-capacity killer, and it's something agile teams can actually measure. The study asked about context switching, interruptions, and how many channels people move between; a deeper follow-up study is now underway focused specifically on AI-driven uncertainty and tool-switching. Alison's guidance isn't "do less and stop switching," because that reality isn't going away. It's to design rhythm into the work: periods of sprint followed by a deliberate pull-back—reflective work, postmortems, space to talk about what didn't go to plan. She didn't put a number on the right ratio of recovery to sprint; it's contextual to the industry, the stage of the business, the size of the team. The leadership move is to look at the actual rhythm of the business, and to proactively plan and openly name the recovery after a big push—instead of treating "recovery" like a bad word.
Why Managers Are at Higher Risk
"Managers were 1.7 times more likely to experience high burnout—and about three times more likely to say, yes, I delay complex problems or hard decisions."
When the data was split between managers and individual contributors, the extra management layer showed up as a measurable source of additional pressure. Managers reported high burnout at 1.7 times the rate of individual contributors, and were roughly three times as likely to strongly agree with the statement "I delay complex problems or hard decisions"—a direct marker of eroded innovation capacity. There's more to unpack there, and a second paper is coming in September that adds caregiving as a third dimension, building toward a "responsibility index" that looks at how obligations outside of work—an aging or sick family member, for example—compound the burnout picture. For a Scrum Master, the takeaway is that the pressures draining a team's capacity are often invisible from the outside, and they land hardest on the people carrying the most responsibility.
One Thing to Start Tomorrow
"Not another meeting—but a reflective question first. Rate your energy, rate your stress, and look at where your time actually got spent versus the goals you had."
Alison's concrete recommendation for anyone who suspects something is off: start a weekly check-in. First an individual reflection—rate your energy and stress for the week, and compare where your time actually went against the goals you set. Then bring that same question into a Friday stand-up or retrospective and ask the team to weigh in: what was the team's stress and energy, and were there major constraints nobody saw coming? The first few weeks people may be hesitant to answer honestly. But keep the practice going week over week, and you build a real data set on how the team is actually feeling—and start surfacing the systemic blockers getting in the way of good work.
About Alison Campbell
Alison Campbell is the founder and CEO of unBurnt® and Executive in Residence at Bentley University's Center for Health and Business. Her 2026 research — "When Burnout Looks Like Productivity: The New Risk to Innovation Capacity" — surveyed 544 professionals across 17 industries and reframes burnout as a measurable threat to an organization's capacity to innovate. unBurnt® · Research · LinkedIn
Log in
