Designers have spent years saying they would do better work if the organisation got out of the way. Not always in those exact words, obviously. It usually comes out as something more reasonable: we didn’t get enough engineering time, product had already decided the solution, the roadmap was too packed, leadership only cared about this quarter’s numbers, research got cut, the experiment was never run properly, the design debt was known about, but nobody wanted to spend a sprint fixing it.

Much of this is true. Most designers have worked inside that awkward middle space between product and engineering. Product frames the problem, or at least thinks it does. Engineering decides what is feasible, or at least what is affordable. Design is expected to make the thing clearer, simpler, more coherent, more usable, and occasionally more desirable, while also being careful not to disrupt the plan too much.

That position has always been uncomfortable.

Designers are told to think strategically, but often lack the power to act strategically.

They can spot the broken onboarding flow, the confusing upgrade path, the empty state that makes users feel stupid, the feature that looks reasonable in a product review but makes no sense in real use. Seeing the problem is one thing. Getting it fixed is another.

So design often becomes an argument. You make the case. You annotate the flow. You bring the research clip. You point to the support tickets. You show the Figma prototype. You explain why the “small edge case” is actually the first-run experience for half your new users. Then everyone nods, agrees it matters, and moves on to whatever had already made it onto the roadmap.

This is one reason AI is more interesting for design than the usual “will it replace designers?” debate suggests. The real change is not that designers can make more screens. Nobody needs more screens. The interesting change is that designers may need less permission.

The Bull Case: Designers Need Less Permission

A good designer can now move from “we should fix this” to “I fixed this, and pushed it live.” They can prototype the alternative onboarding flow, write and test clearer product copy, build a rough working version of the interaction, clean up small pieces of design debt without waiting three months for a roadmap slot, and make the better thing visible enough that it becomes harder to ignore.

That changes the politics of the work. Design has often relied on persuasion because designers lacked direct means of production. AI weakens that dependency. Not everywhere, and not for everything. Complex products still have architecture, infrastructure, data models, permissions, security, compliance, legacy systems, and all the other unglamorous reasons software is hard. But the boundary is moving.

More of the gap between having the idea and making the idea real can now be crossed by a motivated designer with the right tools.

In this version of the future, designers become less permission-dependent: less reliant on product to bless the problem, less reliant on engineering to make every small improvement real, less trapped in the role of internal critic, taste-provider, or Figma operator. More able to make, test, repair, and ship.

The best designers start to look less like traditional product designers and more like hybrid product leaders. They still care about interaction, hierarchy, language, flow, brand and craft, but they also understand the commercial shape of the problem. They can make trade-offs. They can prototype in code, or close enough to code. They can use AI to explore options quickly, then use judgment to throw most of them away. They can sit with a founder or PM and move from a vague product concern to something tangible by the end of the day.

There may be fewer of these people, but they will be harder to ignore. The current design-org model was partly built around scarcity: scarce engineering time, slow production, expensive prototypes, handoffs between specialists, heavy coordination across teams. If AI reduces some of that scarcity, it probably reduces the need for some of the roles that grew around it. The optimistic case is not that every designer keeps their job and gets a productivity boost. That feels like wishful thinking. The more believable version is that the total number of designers goes down, but the designers who remain have more direct influence over the product.

That is not a bad outcome for the strongest designers. It may even be the thing many of them have wanted for years.

The Bear Case: Autonomy Exposes The Gaps

Autonomy has teeth. If AI gives designers more room to act, it also removes some of the cover. The same constraints that held good designers back have also protected weaker ones from being tested too directly.

For years, it has been easy to say: I had a better idea, but we never got the engineering time. Sometimes that was exactly what happened. Sometimes the better idea was never really more than a critique. It had not been made concrete. It had not been tested. It had not dealt with the awkward trade-offs. It sounded strong because it lived safely in opposition to the shipped thing.

A lot of designers are good at noticing what is wrong. Fewer are good at deciding what should happen instead. Fewer still can make that alternative real enough for other people to judge. AI will expose this gap.

If you can prototype the recommendation, the recommendation has to get better. If you can make the alternative flow, the flow has to survive contact with details. If you can test the product copy, you have to care what happens when users read it. If you can fix the small piece of design debt, you have to decide whether it was really worth fixing.

Some designers are not as strategic as they think they are. They have learned the language of strategy without the discomfort of owning outcomes. They can talk about user needs, business goals, systems thinking, and product quality, but struggle when asked to make a call. They want influence, but not the exposure that comes with it.

The profession has spent a long time arguing that design deserves more power. Fine. But more power means fewer excuses. It means the work is judged less by the elegance of the argument and more by the quality of the thing you made, tested, or changed. That is a better standard, but it will not be kind to everyone.

There is a second bear case, and it is probably the one large design teams should worry about most. Product and engineering already have more institutional power than design in most companies. They own the roadmap, the technical architecture, the sprint machinery, the metrics, and usually the language leadership understands. Design often has to translate its concerns into someone else’s terms before they count.

AI may not rebalance that power. It may hand product and engineering enough design capability to make design easier to bypass. A PM who can generate a decent flow, decent copy, and a decent prototype may not feel the same need to involve design early. An engineer who can use AI to produce a reasonable interface may decide the design system covers enough of the decision-making. A founder who can get to a polished demo in an afternoon may confuse polish with product thinking.

The problem is not that these people will suddenly become great designers. The problem is that many companies do not know the difference between great design and plausible design. Plausible design is dangerous. It looks coherent in a product review. It uses the right components. The spacing is fine. The copy is not embarrassing. The flow mostly works. Nobody in the meeting feels strongly enough to object. So it ships.

A lot of bad product decisions already survive because they look plausible. AI will produce more of them. This is where design could lose ground quickly: not because taste, judgment, research, and interaction thinking stop mattering, but because the visible outputs of design become easier for other functions to imitate.

If a company already thinks design is mostly screens, prototypes, and polish, AI gives it a cheaper way to get those things.

In that world, design does not gain more agency. It gets narrowed. The remaining designers manage the design system, police component usage, review flows that have already been decided, tidy the interface, maintain brand consistency, and get pulled into high-stakes launches, executive demos, and the occasional messy cross-platform problem. Useful work, but a smaller surface area. Less shaping the product, more maintaining the furniture.

This is why the “AI will automate the boring 20%” argument feels too comforting. In some companies, perhaps that is what happens. But in large tech organisations, where design teams grew around coordination, production and process, the cut could be much deeper. Not 20%. Maybe 50%. Maybe more. Especially in places where leadership never really understood why the design team had grown so large in the first place.

Where I Think We Might End Up

The painful part is that both futures can be true at the same time. AI can make the best designers more capable and many average designers less necessary. It can give design more agency while reducing design headcount. It can help a small number of designers move closer to product leadership while pushing others into governance and clean-up work. It can free designers from waiting for permission, then reveal that some were more comfortable waiting than acting.

The designers who do well will not be the ones who merely use AI to produce more options. Options are cheap now. They will be the ones who know which option is worth pursuing, why it matters, how to test it, what to cut, where the product is lying to itself, and when “good enough” is quietly damaging the business.

They will have taste, but taste will not be enough. They will need product judgment, technical curiosity, commercial awareness and the nerve to make decisions before every variable is settled. They will need to be comfortable moving between a customer conversation, a prototype, a pricing concern, a brand question, and a messy implementation detail without insisting that all of those belong to someone else.

I’m not completely sure where we end up. I hope it is closer to the bull case: fewer permission structures, more making, more agency, better designers finally able to show what they can do without being held back by the machinery around them.

I fear it may be closer to the bear case: product and engineering absorb much of the work, companies decide plausible design is good enough, and design loses status, headcount, and strategic ground.

In reality, it will probably be some uncomfortable mix of the two. Some designers will use AI to gain more agency. Some companies will use it to need fewer designers. Some teams will produce better work because the distance between judgment and execution gets shorter. Others will ship more plausible mediocrity because nobody in the room can tell the difference.

For years, designers have said they could create more value if they were less constrained by the organisation around them. AI is about to test that claim. Some will finally get to prove it. Some will find out the constraints were doing them a favour.

Further Resources

• “Good from Afar, But Far from Good: AI Prototyping in Real Design Contexts,” Huei-Hsin Wang and Megan Brown (NN/Group)
  Lately, the UX design field has been flooded with AI-powered prototyping tools that generate interfaces instantly from natural-language prompts. Despite the massive marketing hype, this evaluation with real design scenarios revealed that while these tools can follow instructions to achieve a general goal, they often lack the sophistication to weigh design tradeoffs and to produce thoughtful, high-quality designs without extensive guidance from humans.
• “AI Design Tools Are Marginally Better: Status Update,” Megan Brown, Caleb Sponheim and Taylor Dykes (NN/Group)
  AI-powered design tools have improved, but we’re still nowhere near the usefulness we’ve been promised, nor are design professionals yet in danger of being replaced by AI. This article reviews in detail several tools and some specific AI-powered features, including: Figma’s Rename Layers, Rewrite This, Find More Like; Khroma Color; and Midjourney. The authors also take a look at the wireframe and prototype generation capabilities of some AI tools.
• design + AI conference

(mb, yk)

The post The Bull And Bear Case For Digital Design In The Age Of AI appeared first on The NOKIA Blog.

That community spirit connects nicely to the week’s biggest infrastructure news, which is all about bringing AWS closer to where builders actually are.

Now, let’s get into this week’s AWS news…

Headlines

AWS Local Zone in Athens, Greece: AWS has opened a new Local Zone in Athens, Greece, the second Local Zone in EMEA with support for Amazon S3 and Amazon EBS Local Snapshots, so you can store and process data within Greece to help meet local data residency requirements. The Athens Local Zone supports Amazon EC2 (C7i, M7i, and R7i instances), Amazon S3 with the One Zone-Infrequent Access storage class, Amazon EBS, Amazon ECS, and more.

With this launch, you can process and store data in-country while delivering single-digit millisecond latency to your end users. AWS Local Zones place AWS infrastructure much closer to large population and industry hubs to support workloads such as financial services, healthcare, media production, and real-time gaming. For builders in Greece, this means running latency-sensitive workloads locally and meeting in-country data residency requirements, without managing your own data center infrastructure. To learn more, visit AWS Global Infrastructure and Sustainability Blog post.

Last week’s launches

Here are some launches and updates from this past week that caught my attention:

• Claude Opus 5 on AWS: You can use Anthropic’s Claude Opus 5, the most advanced Opus model yet, matching Claude Fable 5’s top-tier intelligence in many domains at Opus-tier pricing. Amazon Bedrock offers Claude Opus 5 with zero data retention (ZDR) enabled by default, giving you Opus’ top-tier intelligence while meeting your data governance requirements unlike Claude Fable 5. You have two ways to access Claude Opus 5: Amazon Bedrock and Claude Platform on AWS. To learn more, visit the deep dive blog post.
• AWS Lambda durable execution SDK for .NET is now generally available: You can now build resilient, long-running workflows in C# using Lambda durable functions, without implementing custom progress tracking or integrating an external orchestration service. The SDK is a natural fit for multi-step applications like payment processing pipelines, AI agent orchestration, and human-in-the-loop approvals, it checkpoints progress automatically and can pause execution for up to a year. If you’re a .NET developer building serverless workflows, this removes a lot of the plumbing you used to write by hand.
• Amazon Bedrock AgentCore now delivers unified observability with traces and logs in a single log group: Amazon Bedrock AgentCore now delivers agent traces and prompts to the same Amazon CloudWatch log group as your agent’s logs. Previously, telemetry was split across destinations, trace spans went to a shared log group while prompts, inputs, and outputs went to a separate one, so debugging a single agent invocation meant searching in multiple places. You can now debug an invocation in one place, and apply fine-grained access control and customer-managed key (CMK) encryption at the individual agent level.
• Amazon Connect delivers more natural agentic voice experiences: Amazon Connect now supports more natural, human-sounding agentic voice experiences across 50+ languages, including Portuguese, Spanish, French, Italian, Japanese, Korean, and Thai, with over 100 new voice options and conversational improvements that make AI interactions sound more fluid. Connect’s agentic self-service lets AI agents understand, reason, and take action across voice and digital channels, adapting to a customer’s tone and sentiment. You can now build contact center experiences that feel natural to callers in far more of the languages your customers actually speak.
• Amazon SageMaker Unified Studio now supports Amazon OpenSearch: You can now query and analyze your search and log analytics data from Amazon OpenSearch directly alongside other data assets in Amazon SageMaker Unified Studio. With this connection, you can combine operational search data in OpenSearch with data from sources like Amazon Redshift, Amazon S3, and relational databases, all within a single, governed environment. It’s especially useful when you need to correlate analytical and operational workloads, such as joining application logs with transactional data to uncover insights.
• Amazon CloudWatch announces coding agent insights: Amazon CloudWatch now gives engineering leaders visibility into how AI coding tools are driving value across their organization. Coding agent insights integrates with the Claude apps gateway for AWS to collect telemetry from Claude Code without additional instrumentation, and also supports agents like Codex and GitHub Copilot. As teams scale AI coding adoption, you can now measure the return on that investment with metrics built on OpenTelemetry, no custom instrumentation required.

For a full list of AWS announcements, be sure to keep an eye on the What’s New with AWS page.

Other AWS news

Here are some additional posts and resources that you might find interesting:

Upcoming AWS events

Check your calendar and sign up for upcoming AWS events:

• AWS Summits: AWS Summits are free events that bring the cloud and AI community together to connect, learn, and explore the latest technologies. Browse the full calendar to find a Summit near you in the second half of 2026.
• AWS Community Days: Community-led conferences where content is planned, sourced, and delivered by community leaders. If you’re in Latin America, don’t miss AWS Community Day Belo Horizonte on August 22, registration is open at awscommunityday.com.br.

Join the AWS Builder Center to connect with builders, share solutions, and access content that supports your development. Browse here for upcoming AWS-led in-person and virtual events and developer-focused events.

That’s all for this week. Check back next Monday for another Weekly Roundup!

This post is part of our Weekly Roundup series. Check back each week for a quick roundup of interesting news and announcements from AWS!

The post AWS Weekly Roundup: Local Zone in Athens, Claude Opus 5 on AWS, Lambda durable execution for .NET, and more (July 27, 2026) appeared first on The NOKIA Blog.

Seriously, some of us are spending something close to a BMW’s (or perhaps a Ferrari’s) monthly payment on AI. What started as a small monthly fee to use ChatGPT, Claude, or Copilot has turned into something completely different. We have become the proverbial kids in the candy store.

It’s a bad case of consumerism fueled by our desire to experiment with new toys. It doesn’t help that AI companies are making it easy to spend significant money without a second thought. Integrating with your favorite SaaS or even WordPress is easy. Yet, the virtual cash register silently rings with each prompt and automation we create.

Perhaps all of this is happening too fast (maybe that’s the intention). We may be falling into an AI-powered trap that will be difficult to escape.

The Grumpy Designer likes to keep things rational. So, let’s hit the brakes, take a step back, and analyze what we’re doing. We’re the only ones who can stop the insanity, after all.

Your Monthly AI Plan Isn’t All-Encompassing

The early days of AI (a whole 2-3 years ago) were exciting. I had fun playing around with ChatGPT and seeing what silly or productive things I could accomplish.

Its coding abilities may pale compared to what we have today. But it was still incredibly handy for troubleshooting and building basic WordPress plugins. I decided that their $20-per-month Plus plan was a relative bargain. It offered access to the latest models and improved performance.

And it’s still a good deal, if you use it in your browser or their app. An individual performing occasional coding, image generation, or file analysis will get a lot for their money. It’s once you step outside of those boundaries that things become costly and confusing.

Such monthly plans typically don’t provide you with API access. For that, you’ll need to purchase tokens. It’s a common practice across the big AI companies.

I won’t argue with the premise of token-based usage. AI requires a lot of computing power to do its job. It must provide quick and accurate answers to user queries. Then there is the cost associated with training and improving each model.

The real problem lies in educating consumers on the differences. It’s not until you need an API key that you realize your monthly plan won’t cover you.

How Much Will That Task Cost?

Generating an API key and connecting your favorite AI model to a third-party service is simple. Figuring out how many tokens you’ll need isn’t so clear. That’s the downside of not having a good/better/best pricing model.

Reputable AI companies let you set spending caps and disable auto-purchasing once you hit your limit. This will save you from a massive bill. It’s also a good security measure, should your API key fall into the wrong hands.

However, experimentation is the only way to understand the costs of using AI tokens. Figure out what you want to do, ask AI to do it, and check your account dashboard to see how much you spent. The trick is to extrapolate that cost based on how many times you’ll perform a given task.

The other challenge is that some tasks will use more tokens than others. For example, generating a headline for your blog post will likely cost less than generating a featured image. Thus, you’ll want to watch your token usage carefully.

Setting a small spending limit may be fine for light-duty tasks. That strategy won’t work for organizations with multiple users who are highly dependent on AI, though. You’ll quickly run out of tokens and will have to go without the service or set a higher limit.

It appears that companies are beginning to realize that willy-nilly usage of AI is costly. Some will narrow the scope of what these tools do for them. It’s also an argument for developing local AI models. Maybe we still need humans after all?

Put AI in Its Place

Sure, AI can do just about everything. But the decision on when and how to use it is ours to make. The increasing and uncertain token costs are reason enough to scrutinize every task. Some of what we’re doing may not be worth the price.

There are other benefits to being less reliant on AI. Fewer tokens spent means less electricity (and less pollution). The environmental impact is real and only getting worse as more of us employ these models.

It’s also an opportunity to stay connected to our humanity. Imagine all the knowledge we might lose if we cede every task to machines. There is also the potential to lose personal and professional relationships. Do you want to trade that for efficiency?

All of this makes me want to treat tokens as something to spend wisely. From now on, I’ll ask myself: Is this task tokenworthy?

here. He recently started a writing service for WordPress products: WP Product Writeup. He also has an opinion on just about every subject. You can follow his rants on Bluesky @karks.com.

Read more articles by Eric Karkovack

The post Cherish Your Tokens, Grumpy Designer appeared first on The NOKIA Blog.

React Server Components don’t send HTML to your browser. They don’t send JSON either. When a server component renders, what actually travels over the wire is a custom streaming protocol called Flight. It’s a line-delimited format with its own type system, its own reference resolution, and its own rules for reconstructing executable behavior on the client.

Most React developers have never opened the Network tab and actually looked at a Flight payload. It looks like a mix of JSON fragments, dollar-sign-prefixed references, and module pointers that the React runtime silently reassembles into a live component tree. The framework handles it, so nobody questions it.

I’m not sure most teams have thought carefully about what that trust actually implies.

I started pulling apart the Flight protocol after CVE-2025-55182 dropped in December 2025. The security community called it React2Shell, and for good reason. It was a CVSS 10.0, unauthenticated remote code execution vulnerability sitting in the Flight deserialization layer. One crafted HTTP request to a Server Function endpoint, and an attacker had shell access. No credentials needed.

The federal Cybersecurity & Infrastructure Agency (CISA) added it to the Known Exploited Vulnerabilities catalog. Sysdig tied in-the-wild exploitation to North Korean state-sponsored actors deploying file-less implants through the Ethereum blockchain. That’s the kind of CVE that gets your attention.

After spending time in the source (mostly getOutlinedModel and getChunk, which is where the resolution logic that matters actually lives), I realized React2Shell wasn’t a one-off parsing bug. It was a symptom. Flight reconstructs executable references, lazy-loaded components, server RPC endpoints, and async state from a stream of text. That’s a deserialization system.

The attack surface extends well beyond a single missing hasOwnProperty check. This article covers how Flight works on the wire, where the deserialization sinks are, what attackers have already weaponized, and what’s still exposed.

This leads to a ranked, practical set of defenses for your own Server Components: schema validation on every Server Action, the server-only package, cross-site request forgery (CSRF) hardening beyond framework defaults, and an assessment of what the Taint API and Web Application Firewalls (WAFs) provide.

Table of Contents

Flight On The Wire

Open your browser’s Network tab on any Next.js App Router page and look for requests returning Content-Type: text/x-component. That’s Flight. It’s not a single JSON blob. It’s a streaming, line-delimited format where each line is a self-contained “row” that the client-side React runtime processes as it arrives over the connection.

Here’s what a simple Flight payload looks like in practice:

1:I["./src/components/ClientComponent.js",["chunks/main.js"],"default"]
2:J["$","article",null,{"children":"$1"}]
0:D{"name":"RootLayout","env":"Server"}

Row 1 is an import directive. It tells the client to load ClientComponent.js from the bundler’s chunk map. Row 2 is a JSON tree that constructs an <article> HTML element, and the "$1" inside children is a reference back to chunk 1 (the imported component). Row 0 defines the server execution context, marking this as a RootLayout running in the Server environment. Even in this tiny example, you can see the mix of structural data, module references, and cross-chunk pointers that makes Flight different from plain JSON.

The Row Format

Every row follows the same syntax: <ROW_ID>:<ROW_TAG><PAYLOAD>n. The row ID is a numeric identifier that other rows can reference. The tag is a single character (or short string) that tells the parser what kind of data follows. The payload is the actual content.

Here are the row tags I found while reading through the source:

So far, this might look like a benign structured data format with some custom tags, but the real complexity and attack surface live in the prefix system.

The $ Prefix System

This is where I started paying closer attention.

When the client-side parser encounters a string value starting with $, it doesn’t treat it as literal text. It intercepts the string, checks the prefix, and routes it through a type-specific resolution path. The parseModelString function in ReactFlightClient.js is where this happens. It’s essentially a big switch statement on the character after $.

Every other prefix resolves a chunk and gives you the parsed result. $@ hands you the raw internal Chunk object instead, the wrapper React uses to track resolution state, pending callbacks, and internal metadata (which is why it’s used for Promises and why exploits use it to get a mutable handle). Exposing framework plumbing through the protocol looks like a design mistake to me, though I’d be interested to hear the rationale if there is one.

And $: (property access) is the other critical prefix. It lets the protocol specify a path like $1:user:name, which tells the parser to resolve chunk 1, then access .user, then access .name on the result. That’s arbitrary property traversal driven by data in the stream. If you’ve spent any time auditing JavaScript for prototype pollution, that pattern should feel familiar.

This Is Not Just A Data Format

Flight is not JSON with extra steps. JSON gives you data. Flight gives you behavior. It reconstructs module references that trigger client-side code loading, creates server action endpoints the client can invoke as RPC calls, sets up Promise chains that the React runtime will await, and builds lazy-loaded component boundaries that execute on demand.

Whether React developers think of it that way or not, the mechanics look very similar to deserialization systems that have historically caused problems. The stream doesn’t just describe what the UI looks like. It instructs the client runtime on what code to load, what functions to call, and what to trust.

If you want to read the implementation yourself, fair warning: the chunk resolution path is miserable to follow. State transitions bounce between helper functions, and the naming obscures what the code is actually doing. I gave up on static reading and just set breakpoints. The key files are react-client/src/ReactFlightClient.js for the client-side parser (look for parseModelString, getChunk, reviveModel, and getOutlinedModel) and react-server/src/ReactFlightServer.js for the serialization side. The reply handler for Server Actions lives in react-server/src/ReactFlightReplyServer.js.

Why Flight Is A Deserialization Sink

The deserialization pattern is familiar: Java’s ObjectInputStream gave us ysoserial, Python’s pickle executes code on load(), PHP’s unserialize chains __wakeup and __destruct methods, and .NET’s BinaryFormatter was deprecated entirely.

The pattern: deserialize attacker-controlled input → invoke behavior during reconstruction → lose control of execution.

So JavaScript should be immune to this, right? JSON.parse() only produces plain data objects. No constructors fire. No magic methods run. You get back exactly what the JSON string describes, nothing more.

That’s true for raw JSON.parse(). But it stops being true the moment a framework wraps custom deserialization logic around it. And that’s exactly what Flight does.

Prototype Pollution

JavaScript uses prototype-based inheritance. Every object has a __proto__ link to its prototype, and property lookups walk up this chain. If an attacker injects __proto__ or constructor.prototype as a key during reconstruction, they modify the shared base prototypes that all objects inherit from. Downstream code reads attacker-controlled values without knowing.

Flight’s $: prefix performs property traversal on deserialized objects. The getOutlinedModel function walks colon-separated paths like $1:user:name by iterating through each segment and accessing it on the parent object. If those path segments include __proto__ or constructor, the traversal walks straight up the prototype chain. That’s not a theoretical risk. It’s exactly how React2Shell worked.

Duck Typing and Thenables

The V8 engine (and the JavaScript spec) treats any object with a .then property as a Thenable. When you await something, the runtime checks for .then and calls it if it exists. No class check. No internal slot verification. If .then is callable, it gets invoked.

Flight resolves chunks asynchronously. If an attacker constructs an object with a manipulated .then property and gets it into the chunk resolution pipeline, the runtime calls the attacker’s function during normal await behavior. The language semantics do the work.

I initially focused on $F because forging Server Action references seemed like the obvious attack surface. After tracing the resolution path, $: property traversal looked much more interesting. I also spent a few hours examining chunk status transitions (pending, blocked, resolved, errored) to see if you could force a chunk into an unexpected state, though that approach didn’t yield any results.

The Core Problem

These two risks converge in Flight because the protocol doesn’t just deserialize data. It deserializes behavior. The $ prefix system dictates which execution path the parser takes: $F creates a callable server endpoint, $L sets up lazy code loading, $B triggers a blob handler, $@ exposes internal framework state. The parser’s control flow is driven entirely by what’s in the stream.

If an attacker can influence the stream’s content, they control which functions the parser calls, which objects it constructs, and which internal state it exposes.

The Mechanics Of React2Shell

This is the CVE that proved the theory. CVE-2025-55182, nicknamed React2Shell, is a CVSS 10.0 unauthenticated remote code execution vulnerability in the Flight deserialization layer. One HTTP request, no login required, full shell access.

I want to walk through the entire gadget chain because understanding it reveals how much power the Flight protocol hands to an attacker who can control the stream.

The Root Cause

The vulnerability sits in getOutlinedModel, a function responsible for resolving deep property paths from the $: reference system. The instance used in the exploit chain lives in the server-side reply handling code (ReactFlightReplyServer.js). When the parser encounters a reference like $1:user:name, it splits on the colons and walks the path segment by segment. Here’s the vulnerable loop:

for (key = 1; key < reference.length; key++)
    parentObject = parentObject[reference[key]];

Two lines. No hasOwnProperty check. No validation that the property exists on the object itself rather than somewhere up the prototype chain. Just parentObject[reference[key]] and move on.

So an attacker supplies $1:__proto__:constructor:constructor, and the loop traverses from a plain JSON object up through Object.prototype to the Object constructor to the Function constructor. Function in JavaScript behaves like eval(). Function("arbitrary code")() executes.

No allowlist on property names. No check for __proto__. I searched reviveModel and the chunk initialization path for any filtering. Nothing.

The Gadget Chain

Getting from “I can reach the Function constructor” to “I have RCE” requires chaining several Flight protocol features together. The Resecurity write-up covers the full chain in detail; here’s the high-level sequence:

• Step 1: Prototype walk to Function.
  The $: path __proto__:constructor:constructor walks from any plain object to Object.prototype, then to the Object constructor, then to Function — JavaScript’s built-in eval() equivalent.
• Step 2: Raw chunk self-reference.
  $@0 returns the raw internal Chunk wrapper instead of its resolved value, giving the attacker a mutable handle on React’s internal state machine.
• Step 3: Thenable hijack.
  The attacker sets the chunk’s .then to Chunk.prototype.then, so React’s resolution pipeline treats the manipulated chunk as a legitimate Promise-like object and awaits it.
• Step 4: Context confusion.
  During the second deserialization pass, the payload overwrites _response._formData.get to point to the hijacked Function constructor and places the attacker’s shell command into _response._prefix.
• Step 5: Trigger via blob handler.
  $B0 invokes the blob handler, which internally calls response._formData.get(response._prefix + blobId) — now equivalent to Function("attacker_shell_command")(). That’s arbitrary code execution with whatever privileges the Node.js process has.

Each step uses a legitimate Flight protocol feature in a way the designers didn’t anticipate. There’s no single “broken” feature. The vulnerability emerges from how these features compose when an attacker controls the input.

Impact

The numbers on this one are stark:

• CVSS 10.0. The maximum possible score.
• Unauthenticated and pre-auth. No credentials needed — and the deserialization happens before any application-level auth checks run, so even endpoints behind login walls are exposed.
• Single HTTP request. One POST to a Server Function endpoint.
• Affected React 19.0.0, 19.1.0, 19.1.1, and 19.2.0, across react-server-dom-webpack, react-server-dom-parcel, and react-server-dom-turbopack.
• CISA added it to the Known Exploited Vulnerabilities catalog within days.

What Happened In The Wild

Exploitation was immediate. Sysdig published research linking EtherRAT deployments to North Korean state-sponsored actors who weaponized the vulnerability within hours of disclosure. EtherRAT is a file-less implant that uses the Ethereum blockchain for command-and-control communication — a technique researchers call “EtherHiding” — making takedown nearly impossible because you can’t seize a blockchain.

Separately, Palo Alto’s Unit 42 documented a backdoor called KSwapDoor that masquerades as [kswapd1] on infected Linux systems, blending into process lists alongside the legitimate kswapd0 kernel swap daemon; their analysis confirms KSwapDoor uses RC4 encryption to protect its internal strings and configuration data, while C2 communications run over AES-256-CFB with Diffie-Hellman key exchange across a P2P mesh network. The speed and sophistication of these campaigns — state-sponsored actors deploying novel implants through a single unauthenticated HTTP request — underscores why a CVSS 10.0 in a deserialization layer demands immediate patching, not triage.

The Fix

The React team’s patch is clean and targeted. The core change caches the genuine hasOwnProperty method at module load time:

var hasOwnProperty = Object.prototype.hasOwnProperty;

Then every property check in the deserialization path uses .call() to invoke the cached reference:

hasOwnProperty.call(value, i);

Even if an attacker shadows hasOwnProperty on a malicious object, the check uses the original prototype method. The prototype chain traversal that powered the gadget chain is blocked. This fix shipped in React 19.0.1, 19.1.2, and 19.2.1.

The fix is correct. But reading through the patches, I noticed the React team hardened ownership checks while leaving the property traversal model intact. The $: prefix still walks colon-separated paths; it just validates each step now. I think exposing arbitrary property traversal through a network protocol was a design mistake, and the patch treats the symptom. If future bugs emerge, they’ll likely come from this same area.

The framework patch closes the known gadget chain, but it doesn’t change the fundamental dynamic: the Flight protocol still reconstructs behavior — executable references, module imports, RPC endpoints, async state — from a stream of text. That reconstruction happens before your application code runs, before your validation logic fires, before your auth middleware even sees the request. Relying solely on the framework to protect your Server Components means trusting that every edge case in a complex deserialization parser has been found and fixed. The defenses that follow are the practical steps you can take to limit the blast radius on your own.

Defenses, Ranked By Impact

Some of these close real attack paths. Others mostly make you feel safer than you are. I’ve ranked these from most-to-least impactful based on what I’ve seen in the vulnerability research. If you only have time for one change, start at the top.

1. Input Validation On Server Actions (Zod, Valibot)

This is the single most impactful thing you can do at the application level. The Flight deserializer processes raw, unvalidated network input before your code takes control. Strict schema validation is your primary defense against whatever the protocol reconstructs.

Put a schema validation call at the very top of every Server Action, before any business logic runs — and I mean before anything, including logging. If you log an argument before validating it, and that argument triggers the stringification bug from CVE-2025-55183, you’ve leaked source code before your validation even had a chance to run.

Zod and Valibot both work well for this. Validate types, shapes, string lengths, numeric bounds, and enumerated values. Reject anything that doesn’t match. Use .safeParse(), not .parse() — the throwing variant can surface internal error details in the response if you’re not careful with your error boundaries.

"use server"
import { z } from "zod"

const UpdateProfileSchema = z.object({
  name: z.string().min(1).max(100),
  email: z.string().email(),
  role: z.enum(["user", "editor"]),
})

export async function updateProfile(formData: FormData) {
  const parsed = UpdateProfileSchema.safeParse({
    name: formData.get("name"),
    email: formData.get("email"),
    role: formData.get("role"),
  })
  if (!parsed.success) return { error: "Invalid input" }
  // proceed with parsed.data, this is now the only shape
  // your business logic ever sees
}

One important nuance: If your Server Action accepts a plain object argument (not FormData), validate the whole argument — don’t destructure first and validate fields individually. Destructuring before validation means you’re already accessing properties on the unvalidated input, which is exactly the kind of operation the Flight deserializer can exploit.

"use server"
import { z } from "zod"

const CommentSchema = z.object({
  postId: z.string().uuid(),
  body: z.string().min(1).max(5000),
})

// Good: validate the raw argument first
export async function addComment(data: unknown) {
  const parsed = CommentSchema.safeParse(data)
  if (!parsed.success) return { error: "Invalid input" }
  await db.comments.create(parsed.data)
}

// Bad: destructuring before validation
export async function addCommentUnsafe(
  { postId, body }: { postId: string; body: string }
) {
  // by the time this runs, you've already accessed properties
  // on the deserialized input
  const parsed = CommentSchema.safeParse({ postId, body })
  // ...
}

If your Server Action doesn’t start with a schema parse, it’s a vulnerability waiting to happen. I’d argue this should be a lint rule — and if you’re running eslint-plugin-react, consider writing a custom rule that flags any "use server" export without a validation call in its first statement.

2. The server-only Package

The server-only package is straightforward and effective.

Import server-only at the top of any file that contains database credentials, raw API calls, internal business logic, or anything else that should never cross the server-client boundary. If a Client Component tries to import that file (directly or transitively), the build fails with a clear error.

import "server-only"
import { db } from "./database"

export async function getUser(id: string) {
  return db.query("SELECT * FROM users WHERE id = $1", [id])
}

The failure mode to watch for is barrel files. If you re-export a server-only function through an index.ts that also exports client-safe utilities, any Client Component importing from that barrel will pull in the server-only module transitively and break the build — or worse, if the barrel doesn’t include the server-only import itself, it may silently let server code through. Keep server-only modules in separate files with their own import paths.

// Don't do this: barrel re-export mixes boundaries
// src/utils/index.ts
export { getUser } from "./users"     // has "server-only"
export { formatDate } from "./dates"  // client-safe

// Do this: separate import paths
// Client Component imports from "src/utils/dates" directly
// Server Component imports from "src/utils/users" directly

It also won’t protect you from data leaking through return values. If a Server Component calls getUser() and passes the full user object (including passwordHash or internalRole) as props to a Client Component, that data rides the Flight stream to the browser. The server-only guard prevents the code from crossing the boundary, not the data the code returns. You must explicitly filter your return shapes.

3. CSRF Protections

After CVE-2026-27978, relying solely on Next.js’s built-in Origin vs. Host header check isn’t enough. The Origin: null bypass showed that framework-level CSRF protection has edge cases.

For state-changing Server Actions (anything that writes data, deletes records, or modifies permissions), layer your own protections on top of the framework’s defaults.

Cookie configuration.
Set SameSite=Strict or SameSite=Lax on session cookies. If you’re using next-auth or a custom session library, verify this is set explicitly — don’t rely on browser defaults, which vary.

// next.config.js or your auth configuration
cookies: {
  sessionToken: {
    name: "__session",
    options: {
      httpOnly: true,
      sameSite: "strict",
      secure: process.env.NODE_ENV === "production",
      path: "/",
    },
  },
}

Explicit CSRF tokens.
For high-value operations (password changes, role assignments, payment actions), generate a per-session CSRF token on the server, embed it in a hidden form field or custom header, and validate it in the Server Action before proceeding.

"use server"
import { cookies } from "next/headers"
import { validateCsrfToken } from "@/lib/csrf"

export async function deleteAccount(formData: FormData) {
  const token = formData.get("csrf_token") as string
  const sessionToken = (await cookies()).get("csrf_secret")?.value
  if (!validateCsrfToken(token, sessionToken)) {
    return { error: "Invalid request" }
  }
  // proceed with deletion
}

The allowedOrigins gotcha.
Never, under any circumstances, add 'null' to experimental.serverActions.allowedOrigins in your Next.js config (even if the officially advisory is more nuanced, saying “unless intentionally required and additionally protected”). That string literal matches Origin: null — the exact header that sandboxed iframes send — and it reopens the CVE-2026-27978 bypass. If you’re seeing CSRF failures from legitimate requests, the fix is to configure your reverse proxy to set the correct Origin and Host headers, not to weaken the validation.

// Never do this
module.exports = {
  experimental: {
    serverActions: {
      allowedOrigins: ["null"],  // reopens CSRF bypass
    },
  },
}

4. The hasOwnProperty Patch

I covered this in detail in the React2Shell section. The fix is correct, and it completely neutralizes the known gadget chain. It shipped fast, which I respect.

The action item here is to verify you’re actually running a patched version. The RCE fix landed in React 19.0.1, 19.1.2, and 19.2.1. Check your lockfile:

# npm
npm ls react react-dom react-server-dom-webpack

# pnpm
pnpm ls react react-dom react-server-dom-webpack

# yarn
yarn why react-server-dom-webpack

If you see 19.0.0, 19.1.0–19.1.1, or 19.2.0, you’re vulnerable to the RCE. Update immediately. And don’t stop there: the DoS fixes (CVE-2025-55184, CVE-2025-67779, CVE-2026-23864) require 19.0.4+, 19.1.5+, or 19.2.4+. If you updated after React2Shell and then stopped paying attention, you may still be running a version vulnerable to the DoS variants.

It’s a reactive patch, not a structural redesign.

Note: More on that in Where This Goes Next.

5. The Taint API

React’s taintObjectReference and taintUniqueValue functions register objects or strings with the runtime. If tainted data tries to pass through the Flight serializer, it throws an error. The idea is to prevent sensitive data — user records, API keys, tokens — from accidentally leaking into the client.

Here’s how it looks in practice:

import {
  experimental_taintObjectReference as taintObjectReference
} from "react"
import "server-only"

export async function getUserRecord(id: string) {
  const user = await db.users.findUnique({ where: { id } })
  taintObjectReference(
    "Do not pass the full user object to Client Components. " +
    "Select only the fields you need.",
    user
  )
  return user
}

If a Server Component passes the tainted user object as props to a Client Component, React throws it at serialization time with your custom error message. That’s genuinely useful as a development-time guardrail.

The catch — and it’s a significant one — is that taint tracks object references, not data content. Any derivation breaks the tracking:

const user = await getUserRecord(id)

// taint is lost. Spread creates a new object.
<ClientProfile user={{ ...user }} />

// taint is lost. Individual properties aren't tracked.
<ClientProfile token={user.apiToken} />

// taint is lost. Serialization round-trip creates new refs.
<ClientProfile user={JSON.parse(JSON.stringify(user))} />

// taint fires. Same object reference.
<ClientProfile user={user} />

taintUniqueValue works on specific strings (like API keys), but it’s also reference-based. If the same key value appears in a different variable, the taint doesn’t follow.

Think of taint as a development guardrail, not a security boundary. It catches honest mistakes: a developer accidentally passing a full user object to the client. It won’t stop an attacker who can influence what gets serialized, and it won’t survive routine data transformations that your own code performs. It’s a useful defense-in-depth layer, but shouldn’t be your primary boundary.

6. WAFs

Web Application Firewalls can add a detection layer for known attack patterns. They can inspect POST requests carrying the Next-Action header, block payloads containing constructor:constructor or __proto__ chains, and flag error responses containing E{"digest" patterns that indicate the server is leaking internal error details.

If you’re running a WAF, here are specific patterns worth adding:

# Block prototype pollution attempts in request bodies
Rule: body contains "__proto__" OR "constructor:constructor"
Action: BLOCK
Scope: POST requests with header "Next-Action"

# Flag potential Flight error leakage in responses
Rule: response body matches /E{"digest":"[^"]+"/
Action: LOG + ALERT
Scope: responses with Content-Type "text/x-component"

# Block excessively large Server Action payloads
Rule: Content-Length > 1MB for POST with "Next-Action" header
Action: BLOCK (mitigates CVE-2026-23864 zipbomb vector)

But attackers know about WAF inspection buffers, and they’re usually around 128KB. Prepend 130KB of padding before the malicious payload, and the WAF inspects the padding, finds nothing, and lets the request through. Chunked Transfer-Encoding tricks accomplish the same thing.

The failure mode is treating WAF coverage as a security boundary rather than a noise-reduction layer. WAFs catch automated scanners and low-effort attacks, and that has real value. But a motivated attacker will bypass them with padding or encoding tricks. The defenses that actually stop sophisticated attacks are the ones earlier in this list: validating input before it reaches your business logic, keeping sensitive code off the wire, and staying on patched versions.

What Came After React2Shell

React2Shell wasn’t the end of it. The security audits that followed the December 2025 disclosure shook out a series of related vulnerabilities in the same deserialization surface. None of them are as severe as the original RCE, but they’re worth tracking because some of them required multiple rounds of patching.

The DoS pair (CVE-2025-55184 and CVE-2025-67779) is a textbook example of why deserialization parsers are hard to patch correctly. The first fix shipped, researchers found edge cases it missed, and a second round was needed. CVE-2026-23864 added a third DoS vector through unbounded memory allocation rather than CPU exhaustion. (See the defenses section above for specific version checks.)

CVE-2025-55183 is the sneaky one. It’s a source code exposure bug that triggers when a Server Function calls JSON.stringify (or any implicit stringification) on one of its arguments. Developers do this constantly for logging, debugging, or error reporting.

The attacker sends a crafted argument that, when stringified, causes the deserialization parser to reflect the function’s own source code back in the response. Business logic, database queries, and any hardcoded secrets sitting in Server Action files become readable by anyone who can send an HTTP request.

CVE-2026-27978 is a different class of bug entirely. It’s a CSRF bypass in Next.js’s Server Action handling. Next.js validates that the Origin header matches the Host header to prevent cross-site request forgery. But when a request comes from a sandboxed <iframe>, the browser sends Origin: null.

The Next.js parser in action-handler.ts treated the string 'null' as a missing origin rather than an explicit cross-origin indicator. So an attacker could embed a form inside a sandboxed iframe, submit it, and invoke Server Actions using the victim’s authenticated session cookies. Fixed in Next.js 16.1.7.

What’s Still Exposed

The CVEs above have patches. But some of the risk is structural, baked into how Flight is designed to work.

Man-In-The-Middle (MITM) On The Flight Stream

If an attacker can sit between server and client (CDN compromise, cache poisoning, rogue proxy), modifying the Flight stream in transit looks feasible. The format is plain text with a predictable structure.

Assuming stream control, an attacker could alter $I (Import) rows to redirect component loading to a different module in the webpack chunk map. They could inject $F (Server Reference) tags to embed hidden RPC triggers in the rendered UI. They could modify D (Data) rows to change component props, and if the target component uses dangerouslySetInnerHTML, that’s a direct XSS vector.

Flight escapes $ prefixes in user-supplied strings to prevent data from being interpreted as protocol instructions. But that only applies to data flowing through the serializer. A MITM attacker writes raw protocol directly into the stream. The escaping doesn’t help.

Server Action Enumeration

Server Action IDs are obfuscated hashes generated at build time. They look random. But server-reference-manifest.json maps every action ID to its source implementation. A public manifest hands an attacker a complete API map. This exposure usually stems from misconfigured hosting, an exposed .next directory, or path traversal.

Known action IDs expose Server Actions to standard IDOR and parameter tampering attacks. An attacker can forge direct requests with manipulated arguments. Developers often trust these inputs blindly because they originate from React’s internal machinery. The architectural consequences of that misplaced trust will be the focus of my next piece.

Encrypted Closure Tampering

When a Server Action captures variables from its surrounding scope (closures), Next.js encrypts them before sending to the client. The key is in NEXT_SERVER_ACTIONS_ENCRYPTION_KEY, AES with a base64-encoded key (16, 24, or 32 bytes). decryptActionBoundArgs handles decryption on each invocation.

By default, this key regenerates every build. But multi-server setups often use a static key. If an attacker gets file read access (path traversal, SSRF), they extract the key, decrypt the closure state, modify it (changing a userId, a role, a query parameter), and re-encrypt. The server accepts the forged closure as legitimate.

Supply Chain Activation via Module IDs

I haven’t demonstrated this end-to-end, but the theory is straightforward.

Flight references client components by module ID, something like ["360","static/chunks/app/page-7f3480.js"]. The bundler assigns these IDs at build time based on the module graph. A compromised npm package sitting in node_modules as a transitive dependency gets bundled into a chunk but never loaded because no component references it. Inert.

But if an attacker injects $I import references into the Flight stream (via MITM, cache poisoning, or server-side injection), the parser should load that dormant module. There may be chunk-level validation I’m not seeing. But if the module ID is valid and present in the manifest, I don’t see what stops it. The attack doesn’t require the package to be imported anywhere in your code. It just needs to exist in the bundle output.

This Has Happened Before

React Flight isn’t the first framework to invent a custom serialization format for server-client communication and then discover it’s an attack surface. And it won’t be the last.

Google Web Toolkit (GWT) used a custom RPC protocol to sync Java objects between browser and server. BishopFox demonstrated that attackers could manipulate the wire format to achieve arbitrary deserialization; GWT eventually disabled binary serialization entirely. It took years.

Java Server Faces (JSF) and ASP.NET both serialized ViewState to the client as a hidden form field. When cryptographic signing was weak or missing, attackers tampered with the serialized state and achieved remote code execution. Microsoft and Oracle patched it repeatedly. The underlying pattern kept resurfacing.

The pattern is always the same: a framework invents a custom wire format to move rich, stateful, sometimes executable data between server and client. The designers assume the server is the sole producer of that data and the client is a trusted consumer. Then someone demonstrates that the wire format can be manipulated in transit, or that the server can be tricked into deserializing attacker-controlled input. React Flight is the latest entry in this pattern. It is not an anomaly.

Where This Goes Next

The React Flight protocol solves a genuinely hard problem: streaming interactive component trees from server to client in a way that enables progressive hydration, async data loading, and server-driven code splitting. It works. I don’t want to lose sight of that.

But it works by serializing executable references, async state, module pointers, and RPC endpoints over a streaming text protocol, and then trusting the structure of that stream on both ends. The React team has patched the known gadgets. The hasOwnProperty fix is correct. The DoS fixes are in place. The source code exposure bug is closed.

I think exposing arbitrary property traversal and executable Thenable reconstruction through a network-facing protocol was a design mistake. $:, $@, and $B are powerful internal primitives that were reachable through a parser that didn’t validate ownership of the properties it traversed. One check was missing, and the result was CVSS 10.0.

As more frameworks adopt server-driven UI patterns, the industry is going to need stronger primitives than “the server is trusted”: cryptographic validation of serialized payloads, signed component trees, and content integrity checks on the Flight stream itself.

Hoping the parser handles every edge case hasn’t worked historically, and I don’t see why it would start working now.

The code is in react-client/src/ReactFlightClient.js. If you ship Server Components, read it. Know what your framework is trusting on your behalf.

(gg, yk)

The post Weaponizing And Defending The React Flight Protocol: Deserialization Sinks In RSCs appeared first on The NOKIA Blog.

Last week, my team visited Seoul to meet AWS Korea User Group (AWSKRUG) leaders. AWSKRUG is the largest cloud developer community in Korea, with 20 meetup groups organized by topic and area that collectively host over 100 events each year, primarily in Seoul.

My team regularly visits countries across the Asia-Pacific region, listens to feedback from user group leaders, and works to support their communities. At this meeting, leaders honestly shared what they did well in the first half of the year, what needs improvement, and what they asked of AWS Developer Experience team. We also enjoyed a pleasant conversation during our Chimaek time together.

Now, let’s take a closer look at key launches of last week.

A one-click Lambda setup prompt for coding agents caught my eye most last week. This prompt configures your agent with AWS Serverless skills and the Serverless Model Context Protocol (MCP) server, embedding serverless best practices from the start. This prompt references the Lambda agent setup guide, which includes installation commands for Claude Code, Kiro, Cursor, GitHub Copilot, Codex, Devin Desktop, and OpenCode.

To get started, choose the Copy agent prompt button on the Lambda console screen or copy fetch https://docs.aws.amazon.com/lambda/latest/dg/samples/aws-lambda-agent-setup.md directly, and paste this URL in your preferred AI agent.

You can also use Agent Toolkit for AWS to give your coding agent current AWS knowledge and safe resource access. Use fetch https://raw.githubusercontent.com/aws/agent-toolkit-for-aws/refs/heads/main/setup-instructions/setup.md for installing AWS MCP Server.

Last week’s launches

Here are last week’s launches that caught my attention:

• OpenAI GPT-5.6 Sol, Terra, and Luna on Amazon Bedrock: You can use the smartest family of models from OpenAI yet on Bedrock’s next-generation inference engine built for high performance, security, and reliability. The three models span capability tiers from flagship reasoning (Sol) to balanced performance (Terra) to fast, cost-efficient inference (Luna), all accessible through the Responses API on Amazon Bedrock.
• Same-day transitions to Amazon S3 Standard-IA and S3 One Zone-IA: You can now transition objects to S3 Standard-Infrequent Access (S3 Standard-IA) and S3 One Zone-Infrequent Access (S3 One Zone-IA) as soon as the day they are created, without the previous 30-day minimum retention period in S3 Standard. These storage classes offer up to 40% lower storage costs than S3 Standard while still providing millisecond access when needed, making them ideal for backups, log analytics, and compliance workloads where data becomes cold within hours or days.
• Self-managed code storage on AWS Lambda: With self-managed Amazon S3 buckets for code storage, you can reference source code directly from your own S3 buckets without Lambda creating intermediate copies. This eliminates code storage limits and reduces function activation time after function creates and updates by removing the copy step.
• Importing users with password hashes on Amazon Cognito: You can now import users with password hashes in CSV user imports. Previously, imported users had to reset their passwords on first sign-in. Now, you can include password hashes in the CSV import, enabling users to sign in immediately with their existing credentials. When creating a CSV import, you specify the password hashing algorithm used by your source system.

For a full list of AWS announcements, be sure to keep an eye on the What’s New with AWS page.

Additional updates

Here are some additional news items that you might find interesting:

• Amazon SQS turns 20: Two decades of reliable messaging at scale: When Amazon SQS launched publicly in July 2006, it made this pattern available to every AWS customer. Twenty years later, that core function, decoupling producers from consumers, remains the reason customers use SQS. Let’s look back important milestones after Jeff’s 15th anniversary post.
• Open Protocols with the Strands Agents SDK: Learn how open AI protocols such as MCP, A2A, UTCP, AG-UI, and x402 work together using Strands Agents SDK for building AI agents as an example implementation, though the patterns apply to any agent framework.
• Open source Bulk Executor for Amazon DynamoDB: Performing bulk operations against all items in a DynamoDB table has historically required custom coding. The Bulk Executor for DynamoDB simplifies bulk tasks like these. You can use this feature to invoke commands like count, find, delete, or update. No coding is required, even when running at large scale.
• Transform AWS Support Case Workflows with Kiro CLI: Explore how Kiro CLI’s MCP integration accelerates support case workflows by combining investigation, documentation lookup, and case creation into a single conversational interface across three real-world scenarios: AWS Glue job failures, AWS Lambda cold start investigation, and AWS WAF false positive analysis.

For a full list of AWS blog posts, be sure to keep an eye on the AWS Blogs page.

Learn more about AWS, browse and join upcoming AWS-led in-person and virtual events, startup events, and developer-focused events including AWS Summits. Join the AWS Builder Center to connect with builders, share solutions, and access content that supports your development.

Finally, some customers experienced an issue with Cost Explorer displaying inaccurate estimated billing data in last weekend. They may have received erroneous budget and cost anomaly detection alerts, and observed inflated estimated cost and usage data. The issue has been resolved, and all AWS services are operating normally. We apologize for the concern this incident caused our customers and are conducting a thorough retrospective to prevent events like this from reoccurring, as well as improving our response when billing incidents occur. For more information, visit the AWS Health Dashboard.

That’s all for this week. Check back next Monday for another Weekly Roundup!

— Channy

The post AWS Weekly Roundup: One-click Lambda setup prompt, OpenAI GPT-5.6 models on Bedrock, and more (July 20, 2026) appeared first on The NOKIA Blog.

Today, we’ll introduce you to some fantastic color-grading LUTs for Adobe’s Lightroom. These presets help you tell visual stories by adjusting aspects of your images, such as color, saturation, curves, and white balance. It’s a way to convey emotion, mood, and even time.

Our collection features a variety of color grading options. Use them to depict times of day, seasons, and color temperature, among other unique effects. The possibilities are nearly endless!

You might be surprised at what can be accomplished through these simple add-ons. Not to mention the time you’ll save by not having to edit your images manually.

Ready to get started? Keep reading to find the perfect fit for your visual storytelling project.

You may also like our free collection of Lightroom LUTs.

Add warmth to your photos with these Lightroom presets. They’re designed to bring out orange, red, and yellow tones. Use them to improve landscapes and portraits with a sunny glowing effect.

Are you looking to add a cool touch to your shots? These LUTs accentuate cool color tones, making your image stand out to a whole new level. They’re perfect for making your subject pop.

Quickly add beautiful vintage film effects to your images with this collection. You can use these presets to bring out rich film tones and create a sense of magic. You’ll find everything you need to design a classic look.

This LUT collection offers a variety of cinematic styles. You’ll find presets for different color temperatures and moods. It’s an easy way to add a bit of Hollywood to your work.

Enhance your lifestyle photography with this set of muted tone presets. They’re great for setting a dark or serious mood. Even better, you can apply these eye-catching looks with a single click.

Create just the right mood with these LUTs. Inspired by a good cup of coffee, they bring rich, warm tones to photos. The large number of presets will help you find the perfect effect for your project.

These color-grading LUTs are designed to add cinematic tones to your photographs. Bring out a dramatic matte finish in an instant. You can also adjust these presets to fit your needs.

Soft pastel tones are great for portrait and landscape photography. They add a gentle touch and create a light mood. This LUT collection will help you add a look that will produce smiles.

Enhance your urban landscapes with this set of desaturated Lightroom LUTs. Use them to create a moody and contemporary look with just a click. You’ll find a variety of presets here to achieve your desired result.

Nothing stands out more than an image with rich color contrast. These presets will help you create high-end contrast effects with minimal effort. Add them to your collection and bring out the best in your photos.

The warm glow of the “golden hour” is a longtime staple of photography. The color-grading LUTs in this pack can help you improve or even simulate the effect. Best of all, they work well with just about any photograph.

Use this collection of presets to add cool blue tones to your photos. They can bring a moody vibe to your landscapes and portraits. The effect is gentle on the eyes and easy to implement.

Bring your images to life with a bright, sun-kissed effect. The presets in this collection can improve even the dullest low-light photos. The gorgeous glow of a sunset is within your reach.

Here’s a fun collection to make your images look otherworldly. Multiple styles are available, each with a unique spin on infrared film effects. Experiment with these presets to discover a whole world of possibilities.

Ensure your color stands out with this set of cross-processed LUTs. Choose your desired color, and the preset will do the rest. It’s a great way to add a dominant hue to your photos.

These LUTs will desaturate your image – resulting in an understated tone. They’re an excellent choice for fashion and landscape photos where a touch of nostalgia is needed. You’ll have professional effects in no time.

Add a vibrant touch with these color-popping presets. You can turn your images from dull to vivid with just one click. Use them to create attention-grabbing social media, web, or print photos.

#

Transform your photos with rich autumn tones that evoke the season’s spirit. Each LUT offers cinematic quality with an array of options to choose from. A simple way to decorate your images for fall!

Think of lush greens, pastel yellows, and bright whites. Bring out these springtime colors with a collection that’s blooming with potential. It’s perfect for outdoor nature shots and portraits.

Turn up the intensity with this collection of summer-themed LUTs. They’re designed to accentuate the rich, warm tones of your photos. Use them to beautify your summer shots without breaking a sweat.

These presets create a sharp and cool style reminiscent of winter. Each option focuses on a different shade, giving you multiple ways to make a statement. Use them on fashion, lifestyle, and outdoor images.

More Lightroom Presets

here. He recently started a writing service for WordPress products: WP Product Writeup. He also has an opinion on just about every subject. You can follow his rants on Bluesky @karks.com.

Read more articles by Eric Karkovack

The post 20+ Best Color Grading LUTs for Lightroom appeared first on The NOKIA Blog.

We’ve all heard of the sacred rule in modern web development, the rule never to be broken. The rule of “Never block the main thread.”

You almost can’t miss it as a web developer; it’s in almost every performance guide, and to be fair, it is good advice. We all know the browser’s main thread is single-threaded, meaning it can only do one thing at a time.

Plus, as we know, the main thread isn’t ours alone; we share it with the browser’s rendering engine, input handlers, and other critical tasks. As a result, the less time we hold onto the main thread, the more responsive an app feels. That leads us to share tasks with background workers as we’ve convinced ourselves there should be a hard line between the UI and any computation, and that line shouldn’t be crossed.

And that is what a “recommended” architecture looks like.

But I dare say that *sometimes*, moving the data to a worker is slower than just letting the main thread do the work.

I found this out a few months ago while building a Chrome extension with screenshotting features called Fastary. I kept finding a latency of about 2 to 3 seconds in all my testing, even after using an Offscreen Document (a background process in Chrome extensions) to handle the canvas operations. A screenshot task should feel instant without lag, after all.

It is quite ironic that by reflex, we move work away from the main thread to avoid freezing the UI, but sometimes the act of moving that work (e.g., serializing, copying, and deserializing) can also freeze the UI. And sometimes the recommended approach of letting the background do the work can be slower than just doing the work on the main thread.

Let’s talk about that.

The Architecture Of Browser Context Isolation

To put things in perspective, let’s understand why we isolate browser contexts and how they communicate with each other, with emphasis on the communication part.

A browser is more than a single environment. Different environments are running at the same time, each having its own memory space, what it can access, and rules:

• The main thread is what we are most familiar with; this is where JavaScript logic runs, where the DOM lives, where styles get rendered, and where users interact.
• The Web Workers are separate threads that can also execute JavaScript without DOM access. We mostly use this for heavy data tasks.
• The Service Workers are network-related proxies in charge of intercepting network requests and can even run when the page is closed.
• And then there are Chrome extension contexts, where we have background service workers, content scripts, and Offscreen Documents (the relevant ones for this article).

Each one of these is isolated from the others. A web worker or background script lives in a different memory space from the main thread. They cannot just reach and read each other’s variables or logic, and this is known as the “shared-nothing” architecture.

How do these isolated environments communicate? They explicitly message each other back and forth using APIs, like postMessage().

The Structured Clone Algorithm

postMessage() tells the browser to take a piece of data and deliver it to the context that requested it. But to do this, the browser relies on the Structured Clone Algorithm (SCA).

You’re probably familiar with JSON.stringify(). SCA is similar, but much stronger and smarter. In its simplest form, SCA is a deep, recursive copy operation, i.e., cloning. It walks through the entire data structure it is given, clones every single value, serializes it into a transportable format, ships those bytes to the target contexts, and then reconstructs the original object on the receiving side.

SCA is fast, or maybe fast-ish… For a small regular config object like {theme: "dark"}, it is imperceptible; you don’t even notice it. The story changes, however, when dealing with heavy data because the SCA is a synchronous blocking O(n) operation, i.e., the cost increases linearly with the size of your data.

Let’s put that into perspective. A user clicks a button, and internally, an 8MB image payload is sent to a background worker for processing. When you call postMessage(), the main thread must immediately stop what it is doing to run this serialization and copying process.

So, if the time it takes to pack, ship, unpack the data, and go back to the start is longer than the time to just process the data on the main thread, why not do that instead?

What About Transferable Objects?

I’m sure some of you are already thinking, “Why not just use Transferable objects?” And that is a valid point. Let’s talk about that.

Developers who really pursue ultra-high-performance web apps usually use Transferable objects (e.g., ArrayBuffer, ImageBitmap, or MessagePort) to bypass the Structured Clone Algorithm. This is because when you transfer an object, you’re not making a copy (like SCM). Instead, the browser switches ownership of the data from one context to another.

The browser performs a hand-off whereby the sending context loses access to the data instantly, and the receiving context takes full control. It is actually insanely fast. According to Chrome Developers’ benchmark, transferring a massive 32MB ArrayBuffer can take under 7ms, compared to about 300ms when cloning with SCM. That’s a 43x speed boost.

But like all good things, there are downsides. To name a few:

• You lose it once you send it.
  If the UI still needs that data (like to show an image preview), you can’t access it anymore.
• Not all data is transferable.
  A plain JS object is not. A Blob is not. Even a Base64 string is not.
• API limitations.
  In the context of browser extensions, Chrome’s internal messaging (chrome.runtime.sendMessage) traditionally forces everything through JSON serialization.

So, as far as my screenshot extension went, Transferable objects were not an option.

Why We Isolate Contexts Anyway

Why do we even bother isolating contexts at all? Why not just leave it all to the main thread?

Offloading long-running CPU tasks to a background thread is absolutely the right thing to do. The browser needs to paint a new frame every 16.6ms to keep things fluid; that means any task that takes >50ms is generally considered “long”. Offloading to the background is absolutely the right thing to do.

The issue, however, is that we’ve turned this “never block the main thread” into an absolute rule, without asking is this task expensive to process or expensive to move?

I have come to realize now that the rule is less “never block the main thread” than “never block the main thread for too long.”

When The Right Architecture Is The Wrong Architecture

My goal with the Fastary extension was to make it feel like a native app, running as smoothly and instantly as you would expect a native app to.

As you already know, I took the recommended approach to use the Offscreen Document to handle DOM work in the background. But to my surprise, that took a different turn.

The Offscreen Document API is a clear winner. You create a hidden, undisplayed document that runs entirely in the background. It has a DOM and supports Canvas. For example, if I want to crop a screenshot, stitch multiple screenshots together, perform heavy image manipulation, or add a watermark, Offscreen Document was made for that.

Turns out that was not the best approach. This was my architecture:

1. The background Service Worker captures a screenshot with chrome.tabs.captureVisibleTab(), which returns a Base64-encoded data URL string.
2. The background Service Worker uses chrome.runtime.sendMessage() to ship this image payload to the Offscreen Document.
3. The Offscreen Document receives the image, loads it into an <img> element, then draws it onto a canvas before it applies the user’s crop coordinates, encodes the result, and sends the processed image back to the background worker.

But when I tested it, the screenshot didn’t feel instant. As I said earlier, there was a consistent 2–3 second lag.

I figured out that when captureVisibleTab() takes a screenshot, it returns a Base64 URL string, and on a standard 1080p screen, that string could be approximately 1MB or more, depending on how detailed the image is. It gets even more interesting on modern Retina displays (e.g., MacBooks) as they tend to automatically double the image’s size by default.

Keep in mind that since the image payload could be doubled and extension messaging relies on JSON serialization (as of this writing), we potentially deal with massive synchronous communication that costs an entire round trip.

The image string data is JSON-serialized at least twice: once when going into the Offscreen Document and once coming back out with the processed results to the background worker. The actual image processing (cropping) done inside the Offscreen Document was fast, no doubt, but I can’t say the same about the transfer overhead.

The Retina High-DPI Problem

As if the latency itself wasn’t enough, I noticed a rather subtle bug — which, now that I think of it, was more of my ignorance. After a screenshot was taken, the crop result was completely off in a way that either weirdly scaled the image or resulted in incorrect coordinates.

It turns out that when a user selects a region to crop, the content script gets the box coordinates using getBoundingClientRect(), which is measured in CSS pixels; this is what the DOM uses. But when the screenshot is captured natively in Chrome, the browser doesn’t crop it automatically; it instead uses the physical hardware pixels to get the full screen capture. And the browser uses devicePixelRatio (DPR) to know how many physical pixels should represent one CSS pixel. Basically, if a user on a Retinal display (DPR = 2) highlights an area of 400×300 CSS pixels, the actual captured image area is 800×600 physical pixels.

Note: One CSS pixel is equal to 1 physical pixel (DPR of 1) on a standard monitor. On a Mac Retina display or a modern 4K monitor, however, the DPR is usually 2 or 3.

For an accurate crop, I needed to apply these two different measurement systems with the right DPR, i.e., scale the crop coordinates by the DPR. But remember, Offscreen Documents have no physical display. Processing any image would have a default DPR equal to 1. To fix this, I would have to capture the exact devicePixelRatio from the active tab, serialize it, pass it alongside the image payload, and manually do the scaling math inside the Offscreen Document. The complexity starts to compound.

What if I broke the golden rule and did the work on the main thread instead?

Working On The Main Thread

Some developers will argue that UI tasks are the only things that should run on the main thread, but I don’t fully agree with that. Personally, I believe that user explicitly-invoked actions that need immediate results can sometimes get a solid pass to run on the main thread, provided the work is incredibly fast (e.g., 1s).

That’s what I did: scrap out the Offscreen Document and reengineer the logic. Instead of:

Background → [serialize] → Offscreen Document → [serialize] → Background → Content Script

…I decided to run the whole image processing in the active tab:

1. The background Service Worker captures the screen and gets the Base64 string (same as before).
2. The background sends the payload directly to the content script in the active tab using chrome.scripting.executeScript().
3. The content script (running on the main thread) receives the payload, draws it to a canvas, performs the crop using the correct DPR value, and copies the result to the clipboard.

// Background Script
const screenshotUrl = await chrome.tabs.captureVisibleTab(undefined, { format: "png" });

// Inject the processing function into the active tab as a content script
await chrome.scripting.executeScript({
  target: { tabId: activeTab.id },
  func: processAndCopyImage,
  args: [{ base64Image: screenshotUrl, cropData: userSelection }]
});

This approach completely clears out multiple context hops and round trips that JSON serialization requires. The only cross-context transfer involves sending the data URL from the background to the content script.

The Retina DPI issue essentially solved itself, as the content script runs directly inside the real, active browser tab because it knows the monitor’s real devicePixelRatio.

But there’s an elephant in the room that you may have noticed.

Sure, the image is now processed on the main thread, and the background manipulates the canvas in the active tab. I could technically be blocking the main thread. That’s where I amended the “no blocking the main thread” rule to “no blocking the main thread for too long.” In this specific case, at least, blocking the main thread for a task the user requests for approximately one second is justifiable. It works conversely as well: maybe don’t isolate processes if the data transfer cost is greater than the processing cost.

Conclusion: When To Isolate And When Not To

I’ve boiled it down to a mental model that depends on whether the task is:

1. Compute-Heavy Tasks (CPU-Bound)

These are tasks where the primary cost is computation and not the size of the data itself. These are tasks where most of the time is spent on doing calculations or heavy transformations, e.g., image compression, audio profiling, physics simulation, etc.

The transfer cost for these tasks is minuscule compared to the actual work.

2. Data-Heavy Tasks (Data-Bound)

These tasks are the exact opposite. These tasks are only expensive because of the size. The processing time is almost insignificant, but the data is expensive to transport, e.g., image cropping, filtering an array, shallow copy, etc.

In my specific case, offloading the task to the background falls mostly into negative-sum efficiency. If we are talking about moving megabytes of data to perform a 50ms operation, there is no benefit to offloading it to the background.

Perhaps we can think of it like this:

Total Time = Serialization Cost
  + Transit
  + Background Processing Time
  + Deserialization Cost

Looking at this, if the “background processing time” is the most dominant task in your operation, then isolation is the clear winner. But if serialization, plus deserialization, plus transit exceeds that cost, then there’s no need to isolate things.

And if you can’t figure out if the task is CPU-heavy or data-heavy, it certainly doesn’t hurt to measure it, for example, using performance.mark() and performance.measure() around postMessage calls to profile the transfer cost.

(gg, yk)

The post When It Makes Sense To “Block” The Main Thread appeared first on The NOKIA Blog.

Many companies silently assume that everybody wants more AI in their lives. That people are craving new AI features, new AI products, new AI workflows — that would all magically replace all existing outdated practices and broken ways of working.

But in reality, it seems like people don’t want more AI at all — at least not in the way most AI leaders envision it. Unsurprisingly, many AI features have low adoption and retention — at a very high cost of delivery, and a high risk of reputation damage.

The AI People Don’t Need

It’s remarkably difficult to make a strong argument with senior leadership, but AI is not a value proposition. New AI features don’t magically make for happy or excited customers. Because AI features are often bolt-ons and separate tools for employees to use, they typically take people out of their regular way of working.

AI is pretty good at amplifying shortcuts and shortcomings in organizations — from data quality to decision making. It can’t magically fix years of accumulated quick patches, technical debt, broken culture and internal politics. If anything, they become more visible with AI as inconsistencies or conflicting priorities and get handed directly to users, who are then left to make sense of the mess themselves.

Because in most organizations, work typically requires hopping on and off between plenty of disconnected and fragmented systems, with a new AI tool, they now have yet another system that they also need to hop on and off. Often it produces more work, and typically it’s not particularly rewarding work either.

On top of that, people are very much aware of the cost of finding and fixing AI hallucinations. Asking AI to generate a response might feel easier than writing from scratch, but it has a cost:

• Skim through the entire AI output,
• Spot key points to focus attention on,
• Review/verify key points, one-by-one,
• Check rationale for what follows next,
• Articulate corrections + regenerate,
• Review the response (a number of times).

For many people, AI isn’t something they can proactively choose and explore on their own — it arrives uninvited, at someone else’s pace. On top of that, plenty of messages amplify fears and worries about AI replacing work — so it’s hardly surprising that the perception of AI isn’t excitement. It’s resistance to change and deep anxiety about one’s place in a world that seems to be changing without them.

At best, AI features might be silently accepted or nodded away. At worst, AI raises concerns, doubts, caution — and calls for a healthy dose of skepticism. And sometimes it’s perceived as a threat or liability — because unlike other features, AI is neither predictable nor reliable.

People don’t dream of AI art museums or AI fridges or AI hotel reception or AI-narrated children’s books. They don’t want their children to have romantic AI partners. Most people don’t want to actively manage (and clean up after) a swarm of AI agents roaming in their bank accounts and acting on their behalf in the real world. And most notably, people don’t really want a magical box to speak to or type into all the time.

The AI People Actually Need

I’m always puzzled by the comparison of AI features with how unreliable humans are. But people don’t compare software with other people. They compare features with features — and if one feature in one product is unreliable, while a similar feature works flawlessly in another, they choose the latter. It’s not about AI or not AI, but rather what works consistently and reliably, and what doesn’t.

Many conversations about AI are conversations about the speed of delivery. But to many people, there is little value in increasing the speed of delivery. They want to do things well, with enough time to think and make good decisions. They also want to enjoy the time they spend working on things, rather than just ship faster. There is an enormous feeling of reward and achievement that slowly disappears, one vibe-coded change at a time.

People don’t change much. And after all these years, they (still) want features that are fast, accessible, reliable, predictable and useful — every single time. And ideally not the ones that replace their entire workflow, but that augment their way of working — and that take over the most mundane, annoying, and boring tasks that they find no pleasure in.

Many jobs are exposed to AI automation, but in many of them there is a rewarding, unique, creative part that requires taste, point of view, and perhaps even human intuition. And if AI automates boring parts of it, that’s an advantage for everyone. That’s also what enhances productivity and brings more joy in daily life.

When AI automates tedious and mentally exhausting tasks, its value is much easier to grasp. But for that, AI shouldn’t feel like a bolt-on. It should be deeply integrated into people’s existing workflows. It must also match existing mental models that they have developed and fine-tuned for years or decades. AI should adapt to how people think and make decisions, not the other way around.

And it doesn’t really matter if these features are branded as “AI”, “smart” or “automation”. However, they must work well for people using them. And that means that people must be aware of use cases where it actually helps them, and be inspired to find more use cases on their own.

Ironically, tools that work well there aren’t “AI-first” — they are “AI-second”. Subtle, humble, calm, ambient, taking a supportive role in the background for work that otherwise is remarkably dull and unnecessary.

I don’t want to read books written by AI. I don’t want to gaze upon paintings by AI. I don’t want AI to teach my children. I don’t want to have an AI therapist. I don’t want AI making my medical decisions. I want AI to do all the physical and mental labor that taxes me so I can read books written by humans and go to art galleries to engage with art made by humans. I want AI that makes my life easier rather than forces me to change myself.

— Bo Young Lee

Wrapping Up

Perhaps I’m missing a bigger picture, and perhaps I’m just old school — but I really do like people. Their stories, their thinking, their emotions, their enthusiasm, their laughing. AI can be remarkably helpful in many situations, but so are people. And between the two, I would favor spending time with a human — however imperfect they are — every single time.

No, people don’t need more AI in their lives — they need AI to automate all the boring stuff they have to deal with every day, so they have more time and headspace to do things that they actually love and enjoy doing. That doesn’t mean spending more time with AI — but spending more time with people they love.

Meet “Design Patterns For AI Interfaces”

Meet Design Patterns For AI Interfaces, Vitaly’s new video course with practical examples from real-life products — with a live UX training happening soon. Jump to a free preview.

Useful Resources

(yk)

The post No, People Don’t Want More AI In Their Life appeared first on The NOKIA Blog.

On July 13, 2006, we launched Amazon Simple Queue Service (Amazon SQS) as one of the first three services available to customers, alongside Amazon EC2 and Amazon S3. We had learned firsthand that distributed systems need a reliable way to pass messages between components without creating tight dependencies. If one service called another directly and that service was slow or unavailable, failures cascaded through the entire system. Message queuing solved this by letting services communicate asynchronously: a producer could drop a message into a queue and move on, while a consumer picked it up when ready. This approach kept individual service failures from affecting the rest of the system.

When Amazon SQS launched publicly in July 2006, it made this pattern available to every AWS customer. Twenty years later, that core function, decoupling producers from consumers, remains the reason customers use SQS. The scale, performance, and operational controls around it look very different now though.

Jeff Barr covered the first 15 years of SQS milestones in his 15th anniversary post, from the original 8 KB message limit in 2006 through FIFO queues, server-side encryption, and Lambda integration. Over the last five years, we have continued to scale SQS, added stronger security defaults, and introduced new capabilities that address increasingly complex workload patterns.

Key milestones between 2021 and 2026

High throughput mode for FIFO queues (2021): In May 2021, we launched general availability of high throughput mode for FIFO queues, supporting up to 3,000 transactions per second (TPS) per API action, a tenfold increase over the previous limit. We continued raising this ceiling over the following two years: to 6,000 TPS in October 2022, to 9,000 TPS in August 2023, and to 18,000 TPS in October 2023, before reaching 70,000 TPS per API action in select Regions by November 2023.

Server-side encryption with SSE-SQS (2021): In November 2021, we introduced server-side encryption with Amazon SQS-managed encryption keys (SSE-SQS), giving customers an encryption option that required no key management. In October 2022, we made SSE-SQS the default for all newly created queues, so customers no longer needed to explicitly enable it.

Dead-letter queue redrive enhancements (2021): We progressively expanded how customers recover unconsumed messages from dead-letter queues. In December 2021, we added DLQ redrive to source queue directly in the SQS console. In June 2023, we extended this capability to the AWS SDK and CLI through new APIs, including StartMessageMoveTask, CancelMessageMoveTask, and ListMessageMoveTasks. In November 2023, we added redrive support for FIFO queues.

Attribute-based access control, ABAC (2022): In November 2022, we introduced ABAC, giving customers the ability to configure access permissions based on queue tags rather than maintaining static policies as resources scaled.

JSON protocol support (2023): In November 2023, we added support for the JSON protocol in the AWS SDK, reducing end-to-end message processing latency by up to 23% for a 5 KB payload and lowering client-side CPU and memory usage.

Amazon EventBridge Pipes console integration (2023): We added the ability to connect a queue directly to EventBridge Pipes from the SQS console, routing messages to a broad range of AWS service targets without writing custom integration code.

Extended Client Library for Python (2024): We brought the Extended Client Library, previously available for Java, to Python developers, allowing messages up to 2 GB to be sent through SQS by storing the payload in Amazon S3 and passing a reference through the queue.

FIFO in-flight message limit increase (2024): We increased the in-flight message limit for FIFO queues from 20,000 to 120,000 messages, so consumers can process significantly more messages concurrently without being constrained by the previous ceiling.

Fair queues for multi-tenant workloads (2025): We introduced fair queues to mitigate the noisy neighbor problem in multi-tenant standard queues. By including a message group ID when sending messages, customers can prevent a single tenant from delaying message delivery for others, without any changes required on the consumer side.

1 MiB maximum message payload size (2025): We increased the maximum message payload from 256 KiB to 1 MiB for both standard and FIFO queues, helping customers send larger messages without offloading data to external storage. AWS Lambda event source mapping for SQS was updated in parallel to support the new payload size.

The constant underneath the change

Despite two decades of feature additions, the fundamental use case for SQS has not shifted. Customers use it to decouple services, buffer bursts of traffic, and build systems that stay resilient when individual components fail. That same pattern now extends to AI workloads. Customers use SQS queues to buffer requests to large language models, manage inference throughput, and coordinate communication between autonomous AI agents operating as independent services. For an example of this architecture in practice, read Creating asynchronous AI agents with Amazon Bedrock.

To learn more about Amazon SQS, visit the Amazon SQS product page, review the developer guide, or explore recent updates on the AWS Blogs.

— Esra

The post Amazon SQS turns 20: Two decades of reliable messaging at scale appeared first on The NOKIA Blog.

AWS Builder Center turned one year old last week. Launched on July 9, 2025, the platform has grown from a community hub with Wishlist voting, community profiles, and a toolbox into a full ecosystem with sandbox environments, workshops, Spaces, and a Builders’ Library. To mark the anniversary, Rick Suttles published a full feature timeline covering everything shipped over the past year: AWS Capabilities by Region (1,500+ services across 37 Regions), Spaces for community-created groups, workshops with category and complexity filters, badges and streaks, article series, view counts, saved items, student status, availability notifications, sign-in with GitHub and Amazon, and sandbox environments.

Jeff Barr published a retrospective summarizing Builder Center’s first year. Since launch, 5,548 authors have published 6,448 articles with more than 10.4 million page views combined. Builders have earned 99,226 badges since the badge system launched in March 2026. Community members have submitted 565 wishes, 10 of which have shipped with another 20 on the near-term roadmap.

The top community article Building an AWS Study Buddy with MCP + Strands Agents SDK by Dineshraj Dhanapathy reached 50,000+ views. Chris Miller’s Migrating an EOL Linux Server to AWS in 8 Hours with Kiro followed at 45,000+, and Yash Aggarwal’s AIdeas: NeuroVoice – Multimodal AI for Early Screening of Neurological Diseases article reached 38,000+.

The week’s headline addition is Sandbox Environments by Rick Suttles. Sandboxes give you a free, pre-provisioned AWS account to complete a workshop exercise. Each environment is active for 8 hours, after which the account and all its resources are automatically de-provisioned. You can have one active sandbox at a time and request one per week. No personal AWS account, credit card, or manual cleanup required.

Last week’s launches

Here’s what else happened this week.

• AWS Security Hub introduces Network Scanning – Security Hub introduced Network Scanning, a capability that identifies resources in your environment that are reachable from the public internet. Network Scanning probes your resources from the internet to detect actual reachability, complementing the existing network reachability findings in Security Hub that identify configurations that could make a resource reachable. It discovers public IP addresses, virtual machines, and load balancers across your AWS and Azure environments, identifies reachable ports, and determines what services are running behind them. Each reachable port generates a Security Hub finding with evidence of the port and service discovered. Security Hub Exposures then automatically correlates these findings with other findings and resource configurations to determine broader risk. Existing customers can enable Network Scanning in individual accounts and Regions, or across an organization through a configuration policy. For new customers, Network Scanning is on by default. It is included with Security Hub Essentials at no additional cost.
• Security Hub also extends unified security management to Microsoft Azure – Security Hub now monitors Microsoft Azure resources, providing unified posture management, vulnerability management, and security response across both clouds. It automatically discovers Azure VMs, container images, Function Apps, and identities, and evaluates them for misconfigurations, internet exposure, and software vulnerabilities. AWS and Azure findings appear in the same prioritized view with the same formats and automation workflows.
• Amazon SageMaker Studio integrates with Hugging Face for one-click model deployment and customization – You can now go from discovering a model on Hugging Face to working with it in SageMaker Studio in a single click. Select any supported model on Hugging Face and choose “Customize on SageMaker AI” or “Deploy on SageMaker AI” to land directly on the corresponding workflow page with the model pre-loaded. New customers receive a Studio environment created in seconds with pre-configured permissions for serverless model customization (including fine-tuning with custom reward functions for reinforcement learning), model evaluation, and deployment to SageMaker or Bedrock endpoints. Verified customers receive default GPU access to G5, G6, and G4dn instances without requesting quota increases, and quota utilization is visible directly inside the Studio environment.
• Amazon EKS Auto Mode and Amazon ECS Managed Instances reduce GPU management fees by up to 60% – Beginning July 1, 2026, EKS Auto Mode and ECS Managed Instances reduce management fees for accelerated instance types: G-series fees are down 35%, and P-series and AWS Trainium fees are down 60%. The reductions apply automatically to existing clusters and require no action from customers. Both services include capabilities built for accelerated workloads. EKS Auto Mode provides automatic parallel image pulling on GPU instances with local NVMe storage and accelerator-aware node repair. ECS Managed Instances provides GPU metrics through Amazon CloudWatch Container Insights and automatic health monitoring for GPU hardware failures.
• Amazon Aurora DSQL change data capture (CDC) is now generally available – Aurora DSQL CDC streams the results of insert, update, and delete operations as change events to Amazon Kinesis Data Streams. You can use it to synchronize data across microservices, trigger Lambda functions, or deliver changes to S3, Redshift, and OpenSearch Service through Amazon Data Firehose. CDC streaming is designed to have zero impact on database workload performance and requires no infrastructure to manage.

For a full list of AWS announcements, be sure to keep an eye on the What’s New with AWS page.

Other AWS news

Here are some additional posts you may find useful:

• Building secure AI agents at scale: Introducing Loom for AWS – Loom is an open-source enterprise platform for building agents with AWS Strands Agents and deploying them on Amazon Bedrock AgentCore Runtime. It provides a unified management UI and backend API with identity provider integration, scope-based authorization, multi-persona navigation, and full lifecycle management for agents, memory, MCP servers, and agent-to-agent integrations. Loom enforces automated resource tagging for cost attribution, implements RBAC and ABAC for multi-tenant security, uses paved-path blueprints for agent deployments, manages identity propagation through delegated actor chains, integrates with AWS Agent Registry for discovery and governance, and supports human-in-the-loop review before sensitive actions. The project is available in AWS Labs on GitHub.
• Introducing Claude apps gateway for AWS – The Claude apps gateway is a self-hosted control plane that gives organizations centralized control over access, cost, and policy for Claude Code and Claude Desktop. It connects to any OIDC-compliant identity provider, enforces managed settings on every request, routes inference to Amazon Bedrock or Claude Platform on AWS, and supports per-user and per-group spend caps. The gateway runs as a stateless container in your private network, backed by a PostgreSQL database for short-lived sign-in state. No long-lived secrets are stored on developer machines. Deploy it through Amazon Bedrock to keep data within the AWS security boundary, or through Claude Platform on AWS for the native Claude platform experience.
• Introducing OAuth support for AWS MCP Server – You can now connect agents to the AWS MCP Server using browser-based OAuth with the same credentials you use for the AWS Console or CLI. The new sign-in path supports IAM federation, AWS IAM Identity Center, and root or IAM users. AWS Sign-In issues short-lived access tokens and refresh tokens, with automatic token management so developers stay authenticated across restarts. For headless use cases, a non-interactive flow lets applications with existing AWS credentials obtain OAuth access tokens through the create-oauth2-token-with-iam API. New governance controls include OAuth-specific IAM condition keys, token introspection and revocation, dynamic client registration, and CloudTrail audit elements.

For a full list of AWS blog posts, be sure to keep an eye on the AWS Blogs page.

Upcoming AWS events

Check your calendar and sign up for upcoming AWS events:

• AWS Summits – Free in-person events for builders and innovators to learn, think big, and make new connections. Coming up: Taipei (July 15), Bogotá (July 30), Jakarta (August 6), Ciudad de México (August 12), Johannesburg (August 19), and Zurich (September 2).
• AWS Community Days – Community-led conferences planned and delivered by community leaders. Upcoming events include Yaoundé, Cameroon (July 25), Ahmedabad, India (July 25), Belo Horizonte, Brazil (August 22), Ottawa, Canada (August 22), Tulsa, USA (August 22), and Toronto, Canada (August 29).

Visit the AWS Builder Center to meet other builders, contribute solutions, and find resources that help you keep building.

Wishing everyone a restful and enjoyable summer. Whether you’re building, learning, or recharging, I hope you find time for all three. I’ll be heading to Scandinavia for a few weeks to trade the heat for some cooler weather and longer evenings. Come back next week for more news!

— Esra

The post AWS Weekly Roundup: AWS Builder Center at 1 year, Network Scanning in Security Hub, Loom for AWS, and more (July 13, 2026) appeared first on The NOKIA Blog.

Much of the excitement around this development surrounds AI’s potential to transform WordPress. It opens the door to easier site management and (hopefully) a better onboarding experience for new users. We’re only beginning to see what this technology can do when combined with the content management system (CMS).

Now that AI integration is available to the masses, the question is: What tasks is AI best-suited for?

You can theoretically use it for everything from changing a post title to generating new plugins on the fly. That’s great, but there are a few considerations.

The first is practicality. We likely don’t need AI to check a box on a settings page for us. Seriously, you could do it yourself in the time it takes to write a prompt. But there are also complex tasks that would be too dangerous or inefficient to perform on a production website.

Then there is the cost of using AI tokens. Connecting your website to for-profit models like Anthropic or OpenAI means paying for every prompt or automation. Thus, using AI for everything isn’t for the budget-conscious among us.

Developers and website owners must decide how to get the most value from AI. Here are a few questions to ask yourself or your client before taking the plunge.

Can AI Do It Better or More Efficiently?

The overlap of what humans and AI can do inside WordPress depends on your experience. A professional who has used the software for years will have more capabilities than a beginner. The longer you use WordPress, the more likely you’ll understand its features and quirks.

So, the trick is to identify what AI can do better or more efficiently than you. Relatively small tasks like inserting an image or formatting text are probably best left to humans. There isn’t much time to be saved unless you’re struggling with the basics.

Advanced jobs, such as creating page layouts in the Block Editor, are where things get murky. Here’s where experience really matters. A web designer may have no problem building layouts, while a novice may become stuck. Therefore, the decision comes down to your comfort level.

On the other hand, AI’s potential to perform tasks at scale is where it shines. For example, maybe you want to find every image on your site without an ALT attribute and implement descriptive text. That could take hours for a human. Meanwhile, you can use AI to search for and identify such images. From there, you can manually write the text or ask for help.

It’s also worth noting that using AI isn’t a replacement for learning. In fact, you can use it to guide you through various tools and processes. You may find that you no longer need AI to do something after it shows you how. That’s a powerful and perhaps underrated use case.

How Often Will I Need the Task?

The frequency of a given task is also a consideration. A one-off task, such as a deep code analysis, could be a wise use of AI. Spending a few tokens may be well worth the time saved when compared to other methods.

Automation is another great example, as it’s available any time you need it. You can run a task in the middle of the night or first thing in the morning – it doesn’t care or complain. AI models can schedule and perform such jobs. There is also the potential for it to recognize changing needs and adjust accordingly.

Perhaps the best measure of value is how much time a task takes a human. Consider creating custom data reports, for example. It can be extremely complicated, depending on the data you need. You can use plain language to describe what you need, and AI will do the rest.

This approach also works at scale. Agencies and freelancers managing dozens or even hundreds of websites can use AI as an extra set of eyes. Even something like troubleshooting a buggy plugin could be performed in the background while you tend to other things.

Is There a Suitable Non-AI Solution?

Here’s the elephant in the room: we don’t need AI to do most things inside of WordPress. As such, the technology may be overkill for some tasks.

There are plugins for virtually every need. They can manage automations, data exports, and everything else under the sun. This is how we got by for the 20-odd years before AI came along.

A non-AI plugin is still a viable option. You’re likely to get the functionality you need, along with cost certainty. There is also a human ready to support you if you run into problems.

However, plugins can’t cover every niche, and they aren’t always easy to use. Some require coding skills to get the most out of them. Using AI makes perfect sense in these scenarios.

The benefits of AI include speed and a seamless experience. But in many cases, a plugin will suffice. It’s a matter of looking at your needs and determining the best fit.

AI in WordPress Is Helpful, but Not Always Necessary

The most interesting part of WordPress AI integration may be in how people decide to use it. The CMS powers all types of websites, from small bespoke blogs to corporate multisite installations. There is a nearly endless supply of use cases.

And using AI in the dashboard could benefit users of all skill levels. The challenge is in finding the tasks that make the most sense for you. It’s a more personal decision than you might think.

Our advice? Experiment with this new tool and think of ways it can help you get more done. Keep track of token usage and determine what’s most valuable to your workflow.

You might find that you’re more productive than ever, or that you can safely hold off on using AI for all the things. It’s your choice!

here. He recently started a writing service for WordPress products: WP Product Writeup. He also has an opinion on just about every subject. You can follow his rants on Bluesky @karks.com.

Read more articles by Eric Karkovack

The post AI in the WordPress Dashboard: Which Tasks Are Worth It? appeared first on The NOKIA Blog.

When a branding project fails, it usually happens long before the logo stage: in the strategy phase, when words like “modern,” “trustworthy,” “premium,” “friendly,” and “disruptive” are left undefined. The result is a gap between what the brand is supposed to communicate and what the designer is expected to create. This is the space I like to call the “pre-concept” phase.

At the beginning of a project, designers usually receive many inputs: a brief, a few stakeholder conversations, competitor references, maybe a moodboard or a list of adjectives. From there, they are expected to create visual concepts that feel right. But “right” is difficult to judge when the team has not agreed on what the brand is supposed to communicate in the first place.

As an example, a health tech company we worked with said they wanted to look modern, trustworthy, and disruptive. At first, “disruptive” sounded like a push toward something bold and unconventional. But as we talked, it became clear that disruption, for them, still had to feel credible inside a conservative healthcare environment. Their clients were large government medical institutions. A brand that felt too rebellious, experimental, or visually loud would not create the right kind of trust.

In other words, their version of “disruptive” looked more traditional than the word suggested.

The problem was not that the client used the wrong language. The problem was that the language was too broad to guide design decisions. Before a designer can turn strategy into a visual concept, those words need to become more specific. What kind of modern? Trustworthy in what way? Disruptive compared to whom? And how far can the brand move away from category expectations before it starts to feel wrong for its audience?

This article is about that pre-concept phase: the work that happens after the kickoff but before the first visual direction. While the broader brand identity process for digital products includes strategy, concepts, implementation, and the assets a product team needs to build consistently, this article focuses on the earlier work that makes the first concept possible: researching the brand context, uncovering hidden assumptions with stakeholders, and turning shared direction into a visual foundation. Rather, a practical bridge between what the brand needs to mean and how it might begin to look.

The first place to build that bridge is the brand workshop, where broad discovery needs to become a clearer understanding of the brand context.

Stage 1: Research The Brand Context

A brand workshop will naturally cover the standard discovery topics: the business, its goals, the product or service, the competitive landscape, and the target audience. This article will not try to list every question a designer should ask in that workshop. For readers who want a broader starting point, we prepared a Brand Workshop Toolkit: Questions and Exercises, a FigJam framework we use in our studio to structure discovery conversations.

Here, I want to focus on a smaller set of questions that are easy to skip but extremely useful before visual work begins. These questions are less about collecting facts and more about clarifying perception. They help the team understand what the brand needs to make people believe, where it needs to feel credible, and which category assumptions it should follow or challenge.

Perception sits at the center of brand discovery because the brand is shaped in someone else’s mind.

“A brand is a person’s gut feeling about a product, service, or company.”

— Marty Neumeier, The Brand Gap

If the brand ultimately lives in someone else’s perception, the workshop has to clarify what perception the team is trying to create.

The perception questions I focus on are:

• What should people believe about the company after seeing the brand for the first time?
• What would make the brand feel credible in this category?
• If the brand were a person in the room, how would they speak?
• What do customers currently misunderstand about the company, product, or category?
• Where does the brand need to fit the category, and where does it need to break from it?

These questions help reveal the assumptions behind people’s opinions, instead of simply adding more opinions to the room. The questions matter because brand attributes often sound aligned before they are actually understood. A stakeholder may say the brand should feel “premium,” and everyone may nod. But one person may mean refined and editorial. Another may mean expensive and exclusive. Another may mean clean, quiet, and minimal. The word sounds shared, but it can lead to three completely different visual systems.

For instance, in the health tech project mentioned earlier, the client described the desired brand as “disruptive.” In many categories, that might suggest something bold, loud, or unconventional. But their audience was large government medical institutions, so disruption had to be expressed through clarity, efficiency, and confidence rather than rebellion. If we had taken the word at face value, the visual direction could easily have moved too far from what their audience would trust.

In another project, a fintech team wanted the brand to feel “bold” without losing credibility. That word created useful tension. The word bold could mean bright colors, oversized typography, and a highly expressive system. But in a financial category, it also had to carry signals of security, control, and competence. The question was not whether the brand should be bold, but what kind of boldness would still feel trustworthy.

When the team can define what these attributes mean in context, the designer is no longer working from broad adjectives. They are working from a clearer design problem.

Stage 2: Reveal Hidden Assumptions With Stakeholders

Strategically selected questions can uncover part of the verbal layer, but words alone are rarely enough. To move from language into visual direction, it helps to incorporate exercises that make stakeholders think through images, associations, and relative perception.

Jake Knapp makes a similar point in GV’s Three-Hour Brand Sprint:

“The point of these exercises is to make the abstract idea of “our brand” into something concrete.”

— Jake Knapp

The following two exercises help translate what stakeholders say about the brand into material that can later inform look and feel, design principles, and concept development.

This is also where stakeholder participation becomes important. When clients only receive a strategy presentation, they can stay passive. They may agree in the meeting without noticing the assumptions they are bringing into the process. But when they have to place a competitor on a map, choose an image, or explain why a certain reference feels credible, they become active participants. Their attitudes, beliefs, and disagreements become visible before they have a chance to derail the first concept review.

I usually start by looking outward at the category, then inward at the brand itself.

Exercise 1: Competitor Perception Mapping

Before the workshop, collect screenshots of competitor brands, websites, product interfaces, social visuals, or other visible brand touchpoints. During the workshop, ask the client team to place those competitors on a simple two-axis map.

This exercise is not about deciding which competitors have “good” or “bad” design. It is about understanding how the client reads the category: what feels credible, what feels generic, what feels too conservative, what feels too experimental, and where there may be an open visual territory for the brand.

The axes should be chosen based on the tension the brand needs to solve. For example:

• Traditional to progressive.
• Corporate to human.
• Understated to bold.
• Accessible to exclusive.

For a health tech company that wants to feel innovative but works with conservative medical institutions, the map might use traditional to progressive and corporate to human. For a fintech brand that wants to stand out without losing trust, it might use understated to bold and accessible to exclusive.

The most useful part of this exercise is often not the final map, but the disagreement it creates. One stakeholder may read a competitor as progressive, while another sees it as generic. One may see a brand as premium, while another reads it as cold. These disagreements reveal how different people define trust, innovation, credibility, and differentiation. That is exactly the kind of ambiguity that needs to be resolved before design begins.

Exercise 2: Visual Brand Driver

After the team has discussed the category, I like to turn the conversation inward. One exercise we use for this is called Visual Brand Driver. Each stakeholder is asked to choose images for a set of unrelated categories: transport, typeface, activity, furniture, mood, object, animal, architecture, and drink.

The instruction is important: the images should not represent the person’s personal taste. They should represent the company.

For example, if the company were a type of transport, what would it be? A quiet electric car, a high-speed train, a private jet, a bicycle, a delivery van? If it were a piece of furniture, would it be a soft lounge chair, a precise modular desk, or a heavy boardroom table?

After choosing the images, each person adds four or five adjectives to explain why they selected them. This part matters more than the image itself. The same object can mean different things to different people. A train might suggest speed, structure, reliability, mass accessibility, or a fixed route. A lounge chair might suggest comfort, calm, informality, or lack of urgency.

The exercise helps create a deeper layer of brand perception. Instead of asking people to describe the company directly, it asks them to think through metaphor and association. Patterns and contradictions become visible. One stakeholder may see the brand as refined and calm, another as energetic and experimental. One may describe the company as precise and structured, another as warm and flexible.

Those differences are not a problem. They are useful materials. They show what needs to be clarified before the visual concept phase begins.

This exercise is also helpful because it separates brand perception from aesthetic preference. A stakeholder may personally like a certain image, but if it does not describe the company, it should not be part of the exercise. That distinction is important throughout the branding process. The question is not “Do we like this?” but “Does this express the right thing about the brand?”

Stage 3: Turn Shared Direction Into A Visual Foundation

Once the workshop has revealed the main assumptions, the next client meeting can turn that shared understanding into a visual foundation. This is still not the first identity concept. It is a working layer between strategy and design, where the client can react to perception, visual principles, and early asset directions before the designer invests time in full concepts.

We usually structure this meeting around three connected layers:

1. Look and feel
   What should the brand feel like?
2. Design code
   How can key brand ideas become visual principles?
3. Branding assets
   What early choices should guide typography, color, logo direction, imagery, and illustration?

Together, these layers move the conversation from perception to practical design boundaries.

Look And Feel

Look and feel boards are not collections of visuals the team likes. They are perception boards. The designer collects references based on the workshop: desired perception, category tension, competitor codes, stakeholder disagreements, and brand character.

If the brand needs to feel trustworthy, modern, and human, the board should help the team discuss what kind of trust, modernity, and humanity are appropriate. Is the brand calm and institutional, or warm and accessible? Is it progressive through precision, or through a more expressive editorial tone?

The point is to let the client respond to perception before reacting to a logo, color palette, or finished visual system.

Design Code

Design code makes the direction more specific by translating key brand ideas into visual principles.

For a parenting app in Germany, personalized support for your unique journey might become organic shapes, handwritten lines, and softer compositions. Parenting is messy and magical might become soft gradients, layered imagery, and playful irregularity. Research-backed support for real life might introduce doctor calls, data snapshots, infographics, and editorial layouts that make the brand feel credible.

For a PR agency working with prop tech companies, momentum in motion might become lines, arrows, ripple effects, or motion blur. Springboard might become a lift-off moment and elastic visual energy. Building blocks might become modular shapes or stacked compositions.

The team is not choosing the final graphic expression here. It is testing whether the visual metaphors make sense before concept design begins.

Brand Assets

The final layer brings the conversation down to the building blocks of identity: typography, color, logo style, photography, illustration, and graphic language.

At this stage, the team can discuss questions such as:

• Should the typography feel editorial, technical, warm, precise, expressive, or restrained?
• Should the color palette follow category codes or create contrast?
• Should the logo be a quiet typographic mark, a flexible symbol, or a more expressive character?
• Should photography feel documentary, polished, intimate, product-led, everyday, or aspirational?
• Should illustration explain complex ideas, add warmth, or become a distinctive brand language?

This gives the designer boundaries without making the final identity predictable. The next step is still concept design, but the team is no longer starting from vague adjectives or private expectations.

Pre-Concept Checklist

Before moving into the first concept, it helps to pause and check whether the team has enough shared direction. The checklist is not meant to make every decision in advance. It is meant to make sure the designer is not starting from vague words, hidden assumptions, or unresolved disagreements.

Before creating the first concept, check whether the team has:

• A clear understanding of what the brand needs to communicate.
• A defined brand character.
• A shared sense of what that character means and what it does not mean.
• Visual references tied to perception, not taste.
• Key brand ideas translated into visual principles.
• Early direction for typography, color, imagery, and graphic language.
• Documented areas of agreement and disagreement.
• A clear sense of which concept directions would be wrong before designing them.

This last point is especially useful. A strong pre-concept phase not only tells the designer what to explore. It also clarifies what to avoid: directions that would be too expected, too cold, too playful, too conservative, too loud, too generic, or too far from what the audience can trust.

When the team can name those boundaries, the first concept becomes easier to evaluate. The conversation shifts from “I like it” or “I do not like it” to “Does this express the brand we agreed on?”

The First Concept Should Not Be A Guess

The first concept should not feel like a guess or a surprise reveal. It should feel like the next step in a direction the team already understands.

That does not mean removing intuition, experimentation, or creative risk from the branding process. It means giving those things a sharper problem to solve. When the team has clarified the brand character, tested visual perception, translated ideas into design principles, and discussed the early building blocks of the identity, the designer can explore with more confidence.

Pre-concept work does not need to make the final identity predictable. It needs to make the conversation around it more meaningful. Instead of asking whether the work matches someone’s private expectation, the team can ask a better question: Does this visual direction express what the brand needs to become?

(yk)

The post From Kickoff To First Concept: How To Turn Brand Strategy Into Visual Direction appeared first on The NOKIA Blog.