Blurblogs
Global
Popular
Log in
alvinashcraft's blurblog
Sr. Content Developer at Microsoft, working remotely in PA, TechBash conference organizer, former Microsoft MVP, Husband, Dad and Geek.
156996 stories
·
33 followers

Need a different partition key in Azure Cosmos DB? Pick the right approach by Abhishek Gupta
Monday July 6th, 2026 at 11:47 AM

Azure Cosmos DB Blog
1 Share

Once you create a container, its partition key is fixed at creation, and you can’t change it in place. However, if your original key starts causing problems like cross-partition queries or hot partitions, you need to consider your options for changing it. This post explains the mechanics of changing a partition key, and the tradeoffs between the options.

First, think about the intent of your change:

  • Re-partition the data. You want your items (and future writes) to live under a different key. This means moving to a new container and there are three ways, from least to most effort: Change partition key feature, container copy jobs, or a do-it-yourself migration.
  • Query by a different key without moving. Your writes are fine where they are, and you only have read patterns that fan out across partitions. A Global Secondary Index adds a separate, read-only, automatically-synchronized container with a different partition key and its own data model, a projection of your items (all properties, or just a subset). The source container stays unchanged.

Note that every “change the partition key” option is actually a move: get your data into a new container that has the new key, then point your app at it. The exception is a Global Secondary Index, which adds a different key for read patterns while the source container stays unchanged.

Let’s walk through each path and its tradeoffs.

Re-partition the data

The three options below all land your data in a new container with the new key. But, they differ in how much Azure Cosmos DB does for you, whether you can keep writing to the source while the copy runs, and how much control you have over the cutover.

Option 1: the portal Change partition key feature (least effort)

The portal feature is the managed path. In the Azure portal, open Data Explorer, pick your container, go to Scale & Settings → Partition Keys, and select Change.

The portal creates or selects a destination container in the same database, then copies your data into it using container copy jobs (Option 2 covers those, since they’re the same engine). If you let the portal create the destination container for you, all configurations except the partition key and unique keys are replicated to the destination, so you only restate those two. You can run the copy online or offline (the next section explains what that means). In online mode you finish the job by selecting Complete, and once the copy is done you start using the new container with the new key and optionally delete the old one.

Read more in the Change partition key limitations.

Option 2: container copy jobs directly (same engine, scriptable)

Container copy jobs us the engine behind the portal capability. You can also create and manage them yourself with Azure CLI (via the cosmosdb-preview extension), which is what you want for scripting, automation, or finer control. The workflow is: create the target container with the partition key (and throughput, unique keys, etc.) you want, create the copy job, monitor it, and cut over. When the source and destination are in different accounts, you first give the destination account’s identity read access to the source container. Same-account copies don’t need this step.

Container copy has two modes: online, where writes continue during the copy, and offline, where you stop writes before the job starts.

Online mode keeps writes flowing during the copy and ends with a short Complete-then-cutover, but every source write is charged double RUs while online copy is enabled, and it needs continuous backup, all-versions-and-deletes change feed, and the account-level capability switched on first. Offline skips those prerequisites at the cost of a write freeze on the source until you cut over. The Container copy jobs documentation walks through the prerequisites and cutover for both modes.

Both modes run on a best-effort basis (there’s no guaranteed completion time), and jobs run one at a time in the write region. Two things are worth planning for: a copy doesn’t carry TTL across, so an item that hasn’t expired restarts its countdown in the destination, and you’ll want the target provisioned at roughly twice the source throughput to keep up.

Before you cut over: A new container is also your one window to turn on features that can only be set at creation, the clearest being hierarchical partition keys, so weigh them now if they fit your workload. And since you’re re-keying everything, confirm the new partition key value plus id is unique across the destination, or two formerly distinct items can collide.

Option 3: roll your own migration (most control, most work)

If you need transforms during the move, your container exceeds the container-copy limits, or you just want full ownership of the process, create the new container yourself and move the data with your own pipeline. The large-scale migration guidance covers the building blocks:

  • Bulk ingestion to load the new container fast: the .NET v3 SDK has it built in, and the bulk executor library covers apps still on .NET SDK 2.x.
  • Azure Data Factory for smaller datasets (configure source and sink, no code), or the Spark connector if you already work in Spark.
  • Change feed to catch writes that land on the source after your bulk load and replay them into the new container until you cut over. Its default latest-version mode skips deletes and TTL expirations, so use all-versions-and-deletes (which needs continuous backup) to handle delete operations.

Pre-create the destination with enough RU/s and turn off indexing during the load to hold down write cost. You own incremental sync, error handling, cutover, and any reshaping along the way.

Query by a different key, without moving (global secondary index)

If your only pain is cross-partition queries (reads that fan out because your filter property isn’t the partition key), you may not need to move at all. For that case, use global secondary indexes.

A global secondary index (GSI) is a separate, read-only container keyed by a different partition key, with its own data model. That model is a projection query over your items (SELECT * for all properties, or just the subset you query), and it stays automatically synchronized with the source container. You keep writing to your existing container with its existing key, and queries whose filter matches the GSI’s partition key (the specific patterns you built the GSI for) can become single-partition queries against the GSI instead of cross-partition queries on the source. A GSI helps the patterns it’s keyed for, not every cross-partition query.

GSIs fit when changing your existing partition key would be disruptive, and you have multiple query patterns that no single key can satisfy. A GSI needs continuous backups on the account, stays eventually consistent regardless of your consistency level, and runs on autoscale with its own storage and RU costs. Once one exists, replace and delete on the source cost 50–100% more RU (creates aren’t affected), and global secondary indexes cover the rest.

A GSI fixes reads. It doesn’t change where your writes land, so it won’t relieve a write-side hot partition on the source. If your problem is write distribution, or you need a different primary key for the data, you’re back to the data re-partitioning option above and you have to move.

To wrap up

If your writes need a different key, you end up moving the data, and the only question left is how much of the copy you hand to Azure Cosmos DB. If only your reads fan out, a GSI fixes that without changing where your writes land. The table below puts all four side by side.

Decision table

Option Keep writing to the source during the move? Effort Use it when
Portal “Change partition key” Yes (online mode) or no (offline) Lowest You want point-and-click, container < 1,000,000 RU/s, < 4 TB, supported region
Container copy jobs (CLI) Yes (online) or no (offline) Low–medium You want the managed engine but scripted, with explicit online/offline control
Roll your own (bulk / ADF / Spark + change feed) Yes, if you build incremental sync yourself Highest You need transforms, are above the copy limits, or want full control of cutover
Global secondary index N/A, source stays as-is, GSI auto-synced Medium The pain is cross-partition reads, not write hot partitions, and you can keep the source key

Learn more

About Azure Cosmos DB

Azure Cosmos DB is a fully managed and serverless NoSQL and vector database for modern app development, including AI applications. With its SLA-backed speed and availability as well as instant dynamic scalability, it is ideal for real-time NoSQL and MongoDB applications that require high performance and distributed computing over massive volumes of NoSQL and vector data.

To stay in the loop on Azure Cosmos DB updates, follow us on X, YouTube, and LinkedIn. Join the discussion with other developers on the #nosql channel on the Microsoft Open Source Discord.

The post Need a different partition key in Azure Cosmos DB? Pick the right approach appeared first on Azure Cosmos DB Blog.

Read the whole story
alvinashcraft
just a second ago
reply
Pennsylvania, USA
Share this story
Delete

Fragments: July 6 by Martin Fowler (martin@martinfowler.com)
Monday July 6th, 2026 at 11:47 AM

Martin Fowler
1 Share

Last week, Thoughtworks ran a second Future of Software Development Retreat, this time in Europe. As with the previous event, I’ll be sharing some fragmentary thoughts on this. There were five parallel streams, so I could, at best, only attend ⅕ of sessions. This isn’t an event that forms conclusions, rather one that allows those exploring to share what they’ve found, and their visions for the future. The bliki post lists all the writing I’ve run into on this, by myself and others. I’ll be updating it as more posts appear.

Giles Edwards-Alexander “noticed a real difference between the retreats”:

Where Deer Valley had hesitancy and a belief that there was something here even if we weren’t yet sure what it was, Engelberg had confidence: the value is here. As I explained to a colleague today, this was not a conference for true believers: the evidence is in.

What does the evidence say? Well, that was less clear. Some patterns and practices are emerging (one attendee had catalogued dozens of agentic engineering pattern libraries) but they are emerging. There is more work to do to truly establish what is effective, and when.

Greg Herlein felt similarly:

Reading the reports of the February event, when a lot of these same folks last got together, the conversation was about what agentic development might look like. Aspirational. More about what was coming.

This time? Everybody in the room was doing it. Shipping it. Not slides - production. The whole debate about whether this changes software engineering is over. People have stopped arguing about whether a while ago. They’re arguing about how, and the how is getting real.

On a more micro level, I noted two other things. Firstly, there was much talk now about harness engineering, when that wasn’t even a term in Utah - an example of how rapidly things are moving. Secondly people are now worrying about the cost of tokens, where before folks were wanting to do almost anything to incentivize people to talk to The Genie.

 ❄                ❄

A question that continued from Utah was whether architecture and design are still important. There seems to be two landmark hypotheses here, one is that The Genie has such a Galaxy Brain that we no longer need to care about such matters, it will handle as much spaghetti as we can throw at it. The other is, in Laura Tacho’s memorable phrase: “the Venn Diagram of Developer Experience and Agent Experience is a circle”. The point being that The Genie uses the same constructs to understand a code base that humans do, so things like good modularity and naming help it as much as it helps humans. Adam Tornhill’s writing is a good example of this viewpoint.

Tidbits from our session on this:

  • to evaluate the value of architecture we need to focus on desirable outcomes. Internal design quality boils down to ease of change. The question is whether the lessons we’ve learned so far will continue for agents.
  • a way to measure design quality is to look at token costs. If the same change requires less tokens that indicates a better architecture.
  • a good architecture only shows its quality over time, we can’t easily measure it in the short term
  • why did 3GL languages continue when things like 4GLs, UML etc not take hold? It’s because these programming languages hit a sweet spot of human comprehension of computation
  • we’re at the first time ever where the computers care about code quality
  • will future models write machine code directly? If so what will humans review or specify?
  • we should beware of speculating about what LLMs may do in the future. Instead we need mechanical sympathy for our LLMs, so we can gain a sense of how they work and how best to use them.
  • One workflow:
    • take story from backlog
    • talk it over with an agent
    • once get an agreement, make an ADR for persistent record of spec
    • generate a task list
    • get agent to complete it
  • we need abstractions to communicate with agents (echoing Unmesh Joshi’s thoughts on building conceptual models)
  • we often find duplication in LLM generated code, together with mixing of concerns (eg intermingled domain and display logic) - even with a good harness
  • get agents to generate explanatory documentation at the end of a session
  • overnight quality checks with a report for humans to act on in the morning
  • LLMs look at existing code, so if that code has problems, the LLM will amplify them
  • we should be wary of drawing too many conclusions comparing LLM code with human code - human code varies enormously from team to team.

 ❄                ❄

In his account of the retreat, Mathias Verraes goes into the details of his perspective of these issues of software design. He adds another concern: we need good design as a hedge against the risk of dependence on AI. After all, we don’t know how high the costs may rise to. We see governments blocking access to models. We see popular opposition to AI campaigning against data centers and calling for regulation. How much can we rely on AI tools being available to maintain and extend our software in the future?

 ❄                ❄                ❄                ❄                ❄

Charity Majors has a post on the ethics of working with AI and does an excellent job of articulating how I feel about this topic. She outlines the harms inherent in AI, both in the creation of its models (training on stolen data) and in inference (slop, lack of accountability, skill atrophy). Her conclusion however, like mine, is that there’s no ethical gain from renouncing the use of AI and castigating those who use it. Such purity provides little practical help with a technology that is so powerful and so useful.

The way you show care is by showing up. The way you make the world a better place is by getting down in the muck and building it, using whatever skills and resources you have on hand. The way you drive change is you engage.

Yes, we are all complicit. Yes, we are all compromised. No argument. But what are you going to do with that feeling of conviction? Will you channel your discomfort into solidarity and action, or try to ease your conscience by removing yourself from the system? Which does more to help those being harmed?

Her suggestions on how to engage aren’t striking, but that’s hardly unusual. At the Future of Software Development Retreat I convened a session on this question, and nothing striking turned up there either. That said, I’ve never been much of an activist, so my imagination may be limited.

 ❄                ❄                ❄                ❄                ❄

Gergely Orosz has run into a case where an article of his was erased from Google search by a clearly fraudulent DMCA claim.

It seems that anyone can file a bogus copyright claim to get an article they don’t like removed from Google’s search index. This happened in this case. I have no information on who filed the copyright claim. Even less so on who claims to be the copyright owner? Because I am the only possible copyright owner!

He was able to find the DMCA complaint, it was made by “Ellie Piee” whose profile listed them as living on Bouvet Island, an uninhabited Norwegian dependent territory near Antarctica. It claimed Gergely’s article copied a New York Post article entitled “Band Leader Hits Winning Chord”. But Gergely’s article is “Inside Pollen’s Collapse: “$200M Raised” but Staff Unpaid”, and the two do not share a single sentence. There’s an obvious motivation for folks connected with Pollen to have done this, and I hope the resulting Streisand effect bites them where it hurts.

 ❄                ❄                ❄                ❄                ❄

404 media have a bunch of (paywalled) reports on the impact of companies realizing that token costs are getting out of control. They’ve acquired leaked Slack chats, internal dashboards, emails and other material from companies including Citi and Amazon.

Companies are urging staff to use less powerful models, or cutting off frontier models entirely. A dashboard indicates that one company has seen its token bill rise from $5 million in August 2025 to $15 million in May 2026, on track to spend over $120 million in the fiscal year.

404 earlier reported about Accenture taking steps to reduce token usage. The biggest problem wasn’t software engineering using agentic programming, but rather staff “chewing tokens” by using AI to do things like turning PDFs into presentation slides. They saw themselves, and their clients, grappling with exponential increases in token costs. Inevitably, after consulting firms spent time urging their clients to use AI heavily, they are now offering services to control these costs.

Another post says it appears that one way to reduce token costs is to get AI tools to speak like cavemen, using a skill/plugin.

There’s a good summary of all this on 404’s freely available podcast: The AI Tokenpocalypse Is Here.

 ❄                ❄                ❄                ❄                ❄

I share these thoughts just after the July 4th weekend here in America, indeed the Semiquincentennial. Historian Bret Devereaux celebrated this event with a careful reading of the Declaration of Independence, a document often talked about more than it’s read. Which is a shame since it is hardly very long, and its impact was remarkable, and not just in what is now the United States.

The Declaration of Independence was recognized as a radical, potentially explosive document at the time of its issuance, as we’ll see. And it was explosive: the world of 1775 was one dominated by monarchies with just a tiny handful of traditional republics (which we should not ignore!). It took a long time for the seeds of the declaration to spread, but the world it helped create is one where liberal democracies, while hardly universal (more people have always lived in unfree societies than free ones) represent the most economically and culturally dominant bloc in world affairs – something that had never happened before. The Declaration, in its way, remade not just the Thirteen Colonies, but slowly, surely, as water seeps through the cracks of rocks (or my floorboards, alas), it remade the whole world.

Devereaux shines a light onto the world of this text, illuminating its historic context, a world that is very different to the one anyone reading this grew up in. It’s assertions of a natural law that there is equality of rights among men and that governments ought to derive their powers from the consent of the governed would seem hardly worth stating now, yet were deeply radical in 1776. I’ve found that reading history like this has helped me understand how the world is, and gives me a broader perspective on the drama of current affairs.

Read the whole story
alvinashcraft
34 seconds ago
reply
Pennsylvania, USA
Share this story
Delete

Resetting XBOX by Joe Skrebels, XBOX Wire Editor-in-Chief
Monday July 6th, 2026 at 11:47 AM

XBOX Wire
1 Share
XBOX Logo

Resetting XBOX

This message was just sent to Team XBOX employees globally.

Team,

We are beginning the most significant restructure in XBOX history. After careful consideration, I’ve made the difficult decision to reduce our team by approximately 3,200 throughout FY27. This will include approximately 1,600 role eliminations today, and in addition, four studios will leave XBOX to new management. I recognize that a year-long restructuring creates additional challenges. Unfortunately, it is not possible to make all the necessary changes in a single day, and I wanted to be direct about the scale.

I know this is painful. These changes will directly affect people who have poured their creativity into building XBOX. Many joined us through acquisitions, while others were recruited here, or sought us out because they loved this industry and loved XBOX. Today’s decisions do not reflect their talent or dedication.

Our business today is not healthy. We are operating at margins that are 3-10x lower than comparable platform and publishing businesses. We entered Gen 9 with a smaller install base and a higher cost structure. To grow, we bet on Game Pass, multi-platform, and a broader portfolio of content. While those businesses have created meaningful value, they did not grow at the pace we expected. As that happened, our core business weakened, and we added more teams, more investment, and more time, hoping for a better outcome. And now the industry is facing the most severe hardware crisis in its history. We must reset XBOX. 

First, we will reset our content portfolio.

Since 2018, we have aggressively expanded our studio portfolio while the number of games created each month across the industry now outpaces the last ten years combined. We now find ourselves competing not only with the largest publishers, but also with smaller independent studios. It is neither possible nor desirable to own every great independent studio. We have also learned that we are not the best home for every type of studio; in a typical year, we lost 64 cents for every dollar we invested. As we reset XBOX, we will help independent creators succeed by providing open development tools and audiences to realize their vision. 

Compulsion Games and Double Fine Productions will return to management and transition to independent studios with their IP, catalog, and runway for their next games. Ninja Theory and Undead Labs have entered terms to join new ownership with funding to complete and grow Senua and State of Decay 3. In France, Arkane’s management is beginning required consultation with its Works Council to review potential strategic options. 

We are also making reductions across other units, and in some cases, shifting investment to focus on higher priority projects. These changes vary in size across Activision, Bethesda/ZeniMax, Blizzard, King, Mojang, and XBOX Game Studios. None of our first party publicly announced games or projects are being cancelled as part of these reductions. 

In addition, Mojang and King will now report directly to me. These two studios have increasingly become platforms and are our largest by monthly active players. They bring critical geographic, demographic, and differentiation to XBOX.

Second, we will reset our platform.

We know that great technology gets better when it gets simpler, not bigger. Today, in some parts of the company, work passes through as many as 14 layers of management. Our platform teams are 40% larger than they were at the start of this generation, even as our player base and playtime have declined. That complexity has slowed decisions, blurred accountability, and made it harder to deliver for players. As we reset XBOX, we will simplify.

We will reduce management layers to no more than 5, and where possible, 3. We will deliver success through a flatter organization that is built around makers (individual contributors focused on building), player-coaches (leaders who remain deeply involved in the work while developing their teams), and directly responsible individuals (DRIs) who own key decisions and outcomes. And we will streamline how we work across our tools, with a cleaner code base, shared services, and 50% reduced vendor spend.

Third, we are resetting how we operate. 

As XBOX grew our headcount, we became more fragmented. Teams, studios, and functions often operate independently, and it became harder to work towards a shared goal, make the right tradeoffs, and get things done.

For the first time, we are establishing a Chief Operating Officer with end-to-end P&L responsibility across content, hardware, platform, and services. Helen Chiang has been promoted to this role and will report directly to me. Over nearly two decades at XBOX, Helen has helped build some of our most important businesses, from XBOX Live to leading Mojang and the Minecraft franchise. She will bring our businesses together under one operating model, making sure we make clear investment decisions, learn from our successes and failures, and hold ourselves accountable for results.

Thank you, Dave McCarthy, who is retiring after 17 years with XBOX. Dave has played a defining role in building the platform that millions of players rely on every day and has been a trusted partner through many of the biggest moments in XBOX’s history. We wish him all the best.

These changes are about a bigger future for XBOX, not a smaller one. The next decade of gaming will be larger, more global, and more creative than anything we’ve seen before. This year, we’ll invest as much in XBOX as we ever have, but we’ll invest with greater focus, greater discipline, and greater clarity, all in service of making XBOX where the world plays and creates.

I want XBOX to be one of the few companies that entertains more than a billion people each day and gives everyone the opportunity to create and connect. I know we can achieve this goal. XBOX has many of the most beloved franchises in entertainment history, talented studios around the world, and we will return to growth in 2027. 

History is full of companies that mistake longevity for inevitability. We will not be one of them.

Asha

The post Resetting XBOX appeared first on XBOX Wire.

Read the whole story
alvinashcraft
49 seconds ago
reply
Pennsylvania, USA
Share this story
Delete

The code review bug hunt is dead. Here’s what developers get wrong. by Adrian Bridgwater
Monday July 6th, 2026 at 8:52 AM

The New Stack
1 Share

The software code review process is a systematic, peer-driven quality assurance procedure that scrutinizes code when a developer submits a pull or merge request. 

Although poor code review procedures are bemoaned for their inevitable delays and the potential for people to create bottlenecks over inconsequential niggles, good code review catches bugs early, fosters mentoring relationships, and is seen as a democratic way of sharing responsibility.

That’s all there is to it, except that it’s not.

Senior software engineer Mark Dominus tells The New Stack that although many companies do obviously perform code reviews, they don’t “articulate what the result of the review is supposed to be”, and that’s a problem.

“Say you’re a junior engineer, and you’re told for the first time to do a code review. What’s your deliverable? In many places I’ve worked, the deliverable has been left unspecified,” Dominus says. 

In a Mastodon post on this subject, Dominus wrote that “anyone who depends on code review to find bugs is living in a fool’s paradise”, primarily because it is “not in general possible” to find bugs by examining code. He underlined his comment, saying that the “primary purpose of code review” is to find code that will be hard to maintain in the future.

A sure path to code review bad results

He suggests that in scenarios where a software engineer is expected to take a leisurely walking tour through the change set and call out things they don’t like, that leads to bad results, i.e., it encourages people to try and enforce their own preferences about how things should be done, and arguments generally ensue.

“Finding bugs, just from examining a change set, is extremely difficult and requires a certain amount of luck.” – Mark Dominus. 

“Sometimes the boss gives the junior engineer a little more to go on, such as: ‘see if you can find any bugs,’ and this puts the junior in an unpleasant position,” clarifies Dominus. “Maybe they do find a bug, great! But what if they don’t? Finding bugs, just from examining a change set, is extremely difficult and requires a certain amount of luck.”

He suggests a different approach in which software team project leaders drive the code review process by saying: “Look at this for two hours, write a note about anything you don’t understand, and if you don’t get all the way through, make a note about where you stopped.”

A route to delivering real software engineering value

“Now, if the reviewer doesn’t have time to look at everything, you have learned something valuable: the changes are too big or complex to be understood in two hours. Perhaps the change set should be broken into two or more smaller submissions that should be reviewed separately. No matter how junior, inexperienced, or hungover the reviewer is, they can deliver what was asked, and what they deliver will have real engineering value,” explains Dominus. 

That real engineering value is a positive negative in this case. The team has now identified code that another team member can’t understand, or that the change set is too unwieldy for the current code review process… or both.

Code review is theatre, playing soon, near you

Agreeing broadly with these sentiments, Mikhail Golikov, a QA engineer at a high-load e-commerce platform company, tells The New Stack that “code review is theatre” if a team is leaning on it to catch bugs.

“When a team treats review as its bug filter, it ships with a warm feeling and no evidence, then finds out in production,” – Mikhail Golikov. 

“A human skimming a diff cannot see a race condition or a discount that goes negative under load. Review is for code you will hate maintaining later; tests are for code that is broken now,” Golikov underlines. “A reviewer reads a clean diff, sees sensible names and tidy functions, and clicks approve. None of that tells you a key part of the app malfunctions and delivers a broken service to the user.”

Golikov, who is also a maintainer of open-source Python testing tools, explains that the kind of bugs that cause these errors don’t live in the code developers can read. Instead, they live in the states the code gets into at runtime. 

Don’t ship with a warm feeling and no evidence

“When a team treats review as its bug filter, it ships with a warm feeling and no evidence, then finds out in production,” Golikov confirms. “Review is for the question ‘will I hate maintaining this in six months’ and ‘does it actually work’ when a test is run against real inputs, not for a human skimming a pull request at 5 pm.”

There’s little argument among developers and vendors alike that code review processes need to change, especially in the era of AI with the increasing presence of agentic coding tools.

Judah Taub, managing partner at Hetz Ventures, agrees with the narrative here and tells The New Stack that for years, engineering teams have treated code review as the last line of defense against bugs, but that was never really their strength.

“The role of the engineer continues to move further away from the actual code and toward validating architecture, intent and business logic. In the future, even that may be automated,” Judah Taub.

“Code review catches style, architecture, readability and maintainability,” Taub says. “Tests catch bugs. Production catches everything else. The best engineering organizations don’t rely on another developer spotting a subtle edge case buried in hundreds of lines of code – they build systems that automatically verify correctness long before a pull request reaches another human. Code review is to ensure the next engineer can work on the code seamlessly.”

The future for code review

As AI-generated code now enters the fray, Taub thinks the inevitable new equilibrium will be one in which humans review less code directly and increasingly review AI reviews of code instead. 

“The role of the engineer continues to move further away from the actual code and toward validating architecture, intent, and business logic. In the future, even that may be automated,” he predicts.

We can surely extract key trends here and say that software engineering teams certainly need to get out of the nineties, if that’s where they currently reside. 

The combined revolutions of cloud-native, platform engineering, and vibe coding onward to agentic coding (you can add in big data, DevOps, and the standardization towards enterprise open source if you wish) have changed the way software developers work, so there should arguably be a commensurate change in the way they review what just happened.

The post The code review bug hunt is dead. Here’s what developers get wrong. appeared first on The New Stack.

Read the whole story
alvinashcraft
2 hours ago
reply
Pennsylvania, USA
Share this story
Delete

Google Ordered to Pay $2 Billion For Anti-Competitive Practices By Swedish Court by EditorDavid
Monday July 6th, 2026 at 8:51 AM

Slashdot
1 Share
Google was ordered to pay almost $2 billion this week to Pricerunner, reports Bloomberg: The Patent and Market Court in Stockholm, which issued the judgment on Wednesday, dismissed most parts of the claim in which Pricerunner sought 80 billion Swedish kronor, or roughly $8.2 billion, in the wake of a European Union antitrust crackdown... The Swedish price-comparison website argued that Google has been abusing its dominant position as a search engine by favoring its own comparison shopping service over competing portals for more than a decade. Wednesday's award compensates for lost revenue caused by Google's preferential treatment of its own comparison-shopping service over independent price-comparison services, conduct that also drives up costs for consumers, [Pricerunner owner] Klarna said in a statement after the judgment... A Google spokesperson said the company doesn't agree with the court's decision and will consider its legal options. [The ruling can be appealed.] Changes implemented in 2017 to Google's platform are working and generating growth and jobs for hundreds of comparison shopping services operating more than 1500 websites across Europe, according to the statement. The litigation is linked to a 2017 decision by the European Commission to fine Google €2.4 billion for illegally leveraging its search dominance to give its own shopping service an edge. The EU decision unleashed a wave of so-called follow-on suits, which were delayed for years as Google appealed the EU fine. Two years ago the EU's top tribunal confirmed that the company did violate antitrust laws — meaning EU-based plaintiffs no longer have to prove that in court. A Berlin court last year ordered the tech giant to pay €573 million in damages to two German price-comparison websites, a ruling Google appealed. Similar cases are pending across Europe.

Read more of this story at Slashdot.

Read the whole story
alvinashcraft
2 hours ago
reply
Pennsylvania, USA
Share this story
Delete

LangChain With SQL Databases: Natural Language to SQL Queries by Varun Joshi
Monday July 6th, 2026 at 8:51 AM

DZone AI/ML Zone
1 Share

Every business runs on a database, but not everyone who needs an answer from the database speaks SQL. Data Analysts wait on engineers, and stakeholders wait on analysts, and by the time the query runs, the decision window has passed.

LangChain's SQL integration fixes this, translating plain English questions like "Which product category had the highest revenue last year' into valid SQL, executing it, and returning a human-readable answer.

Read the whole story
alvinashcraft
2 hours ago
reply
Pennsylvania, USA
Share this story
Delete
Next Page of Stories