Get caught up on the latest technology and startup news from the past week. Here are the most popular stories on GeekWire for the week of Aug. 2, 2026.

Sign up to receive these updates every Sunday in your inbox by subscribing to our GeekWire Weekly email newsletter.

Most popular stories on GeekWire

Zillow cuts more than 500 jobs in its largest layoff of the year

Zillow Group laid off more than 500 employees Tuesday, about 7% of its workforce, one day before it reports second-quarter earnings. … Read More

The startup idea that convinced a UW computer science legend to leave Google after 27 years

Jeff Dean, who earned his computer science Ph.D. … Read More

Tech Moves: Salesforce/Tableau exec departs; startups AIM and Gravitics add to C-suite

Teri Hatfield, Salesforce EVP and Tableau CRO, has taken a role at Iterable; Gates Foundation’s legal director has left for Arnold & Porter; and Seattle-area startups AIM and Gravitics have added to their C-suites. … Read More

Google to cut 52 employees in Washington state

Google is laying off 52 employees in Washington state, according to a state filing. … Read More

Salesforce cutting 59 jobs across Seattle and Bellevue offices

Affected positions include software engineers, product management directors, incident commanders, technical support engineers, and leadership roles across marketing and sustainability. … Read More

Microsoft 2.5: How EVP Charles Lamanna is helping turn Microsoft into the ‘Copilot company’

Charles Lamanna, who leads Microsoft’s Copilot, agents, and platform work, is helping build the coming Copilot Super App — a single front door meant to unify the company’s sprawling AI products. … Read More

Zillow layoffs hit 91 jobs in Washington state, with senior roles bearing the brunt

A WARN notice filed with Washington state shows Zillow Group is cutting 91 jobs in its home state, a fraction of the more than 500 layoffs announced this week. … Read More

‘Some things are better without AI’: How KEXP’s new tech chief will amplify human connection

Jyoti Shukla is taking the product strategy skills she developed at Microsoft, Starbucks, Nordstrom and SiriusXM and applying them to a station she has relied on as a fan for decades. … Read More

UW’s Allen School names Dan Grossman interim director as Magdalena Balazinska shifts gears

After nearly seven years at the helm of the Paul G. … Read More

This startup just raised $6M for an AI tutor that helps kids figure it out themselves

Wild Zebra raised $6 million to expand an AI learning platform for math and reading that asks students questions rather than just giving them answers. … Read More

When a compiler optimizes your program, it has to guess. Which functions are worth inlining? Which side of a branch is the common one? Which method does this interface call actually reach? At compile time it cannot know, so it uses heuristics. Profile-guided optimization (PGO) replaces the guessing with measurement: you run your program, record where it spends its time, and hand that recording back to the compiler for a second build.

PGO is a common feature of compiler systems. Google applied PGO to Chrome under Windows in 2016, reporting gains of up to 15%. I expect all mainstream Web browsers to be built with PGO.

There are now fancier techniques than mere heuristics with PGO. You can use AI to recognize patterns and so forth. But they are not always widely available.

Go has supported PGO since version 1.20. You collect a profile, and pass it to the compiler.

A CPU profile is a statistical record of where a program spends its time. While the program runs, the Go runtime interrupts it about a hundred times a second and writes down the call stack at that instant. After a few seconds you have thousands of such samples, and counting them tells you which functions were executing and who called them. In Go you produce one by wrapping the work you care about:

f, _ := os.Create("cpu.pprof")
pprof.StartCPUProfile(f)   // from runtime/pprof
defer pprof.StopCPUProfile()

The compiler reads the call-stack counts and uses them for two things above all: inlining call sites that turn out to be hot, and devirtualizing interface calls whose target is nearly always the same concrete type.

I took three JSON documents that I wanted to parse:

• twitter.json (632 kB), a nest of small objects with short string keys
• canada.json (2.25 MB), essentially one enormous array of floating-point coordinates
• citm_catalog.json (1.73 MB), deeply nested objects with numeric keys

I parse each of them with the standard library’s encoding/json into an interface{}. The baseline, with no profile, parses at 112 MB/s for twitter.json, 74 MB/s for canada.json and 116 MB/s for citm_catalog.json.

The procedure is three commands:

go build -o bench .                        # ordinary build
./bench -profile cpu.pprof -train twitter.json   # collect a CPU profile
go build -pgo=cpu.pprof -o bench_pgo .     # build again, with the profile

I did it three times, profiling each document on its own, and then measured all three documents against each of the three builds.

Each panel of the figure is one document being parsed, and the three bars inside it are the three PGO builds: the binary trained on twitter.json, the one trained on canada.json, and the one trained on citm_catalog.json. Bar height is the speed gain over the ordinary, profile-free build of that same document, in percent, so zero means PGO changed nothing and a bar below the axis means the PGO build was slower. The green bar in each panel is the matched case, where the profile was collected on the very document being measured.

The gains are modest. The best result is canada.json at +4.7%, and most differences are in the 2–3% range. Profiling one document usually helps the others, but not reliably. Profiling twitter.json gave a decent improvement everywhere: +3.1%, +2.0%, +2.8%. But profiling canada.json bought 4.7% on canada.json and essentially nothing anywhere else. Interestingly, profiling citm_catalog.json produced a mere +0.8% on its own document while helping twitter.json more.

A 3% speedup is not exciting in isolation, but it may come nearly for free. Observe how you may get slightly negative results for cases you did not train for. That’s expected generally, but the effect is modest in the case of Go because its optimizations are themselves modest in the first pace. That is, you are not getting a much an effect, but the process is less likely to backfire for other workloads.

The code is available.

Modern software teams have become exceptionally good at reviewing production code.

Before almost every pull request is merged, another developer checks for bugs, readability, architecture, security, and maintainability.

Code reviews have become one of the most valuable quality practices in software engineering.

But there’s something missing.

Almost nobody reviews the tests.

Developers review the code.

The build verifies that the tests pass.

And then everyone assumes the tests themselves must be correct.

That’s becoming a dangerous assumption.

Code reviews have become a standard practice for maintaining software quality. Google’s engineering guidelines, for example, emphasize reviewing code for correctness, readability, maintainability, and design. Excellent reference for why code reviews matter.

We Treat Production Code Differently

Imagine a developer opening a pull request with 500 lines of production code.

No review.

No discussion.

No comments.

Most engineering teams would reject that immediately.

Production code deserves review because it can contain mistakes.

It can be duplicated.

It can be difficult to maintain.

It can introduce hidden dependencies.

Tests are no different.

They’re software.

They deserve the same level of attention.

Passing Isn’t a Review

Continuous Integration answers an important question:

Does everything still work?

It does not answer another important question:

Are these new tests actually improving the test suite?

A test can pass while still being:

• Redundant
• Fragile
• Difficult to understand
• Poorly isolated
• Expensive to maintain

A green build should never be confused with a quality review.

The Rise of AI Makes Reviews More Important

Only a few years ago, developers carefully wrote every test by hand.

Today, AI can generate dozens of tests in seconds.

That’s a huge productivity gain.

But it also means pull requests increasingly contain test code that nobody has deeply reviewed.

Reviewing every generated test manually doesn’t scale.

Teams need better ways to understand whether those tests actually contribute something valuable.

What Should We Review?

A good test review asks questions that go beyond syntax.

For example:

Does this test verify unique behavior?

Or does another test already validate the same thing?

Is the test properly isolated?

Does it unexpectedly access:

• Files?
• Networks?
• Environment variables?
• System time?

Is the fake actually necessary?

Complex mocking often hides unnecessary setup.

Unused fakes make tests harder to understand.

Will another developer understand this test?

Good tests communicate intent.

If the setup is more complicated than the production code, that’s often a warning sign.

Test Reviews Improve Software

Reviewing tests produces benefits far beyond cleaner test code.

Teams typically see:

• Faster CI pipelines
• Fewer flaky tests
• Less maintenance
• Easier refactoring
• Higher confidence before releases

Most importantly, developers begin trusting the test suite again.

That trust is incredibly valuable.

Manual Reviews Won’t Scale

Large organizations already maintain tens of thousands of automated tests.

Some maintain hundreds of thousands.

As AI continues generating more tests, manual review becomes increasingly difficult.

Developers simply don’t have time to inspect every assertion and every mock.

That’s why test review needs automation.

Not to replace developers.

To help them focus on the tests that deserve attention.

A New Quality Gate

For years our pull requests have contained several quality gates.

• Compilation
• Static analysis
• Security scanning
• Unit tests
• Code review

The next logical quality gate is obvious.

Test Review.

Not simply asking whether tests passed.

Asking whether the tests themselves improve the quality of the project.

The Future of Code Reviews

Code reviews transformed software engineering because they recognized a simple truth:

Every line of production code deserves scrutiny.

The same principle applies to automated tests.

As software teams continue embracing AI-assisted development, reviewing tests will become just as important as reviewing production code.

The organizations that adopt this mindset earliest will build cleaner, faster, and more trustworthy test suites.

Conclusion

We’ve spent years improving how we review production code.

Now it’s time to give our automated tests the same attention.

Passing tests aren’t enough.

Coverage isn’t enough.

A successful build isn’t enough.

The next step in software quality is reviewing the tests themselves.

Because the quality of your software depends not only on the code you write—

but on the tests you choose to trust.

Continue Reading

• Introducing TypeMock Test Review: The Missing Step in Modern Unit Testing
• Why 90% Code Coverage Doesn’t Mean Your Tests Are Good
• AI Can Generate Thousands of Tests. Who Reviews Them?
• Why Unit Tests Should Never Access Files, Networks, or the Registry
• Duplicate Unit Tests Are Costing You More Than You Think

Learn More

TypeMock Test Review, included in the TypeMock Isolator 9.5 , helps development teams automatically review automated tests by identifying hidden dependencies, duplicate tests, and ineffective fakes before they become long-term maintenance problems.

The post Why Every Pull Request Should Include a Test Review appeared first on Typemock.