DEV Community: Giulio Marinelli

When Thinking Harder Makes AI Worse: A Case for Multi-Model Reasoning

Giulio Marinelli — Fri, 25 Sep 2026 12:49:46 +0000

We often assume that bigger models, larger context windows, and more reasoning effort should produce better answers.

And to be fair, in many cases, they do.

If you are debugging code, planning a multi-step workflow, or coordinating an agentic task across files, tools, and constraints, stronger reasoning is usually a major advantage. More deliberation often means better consistency, better constraint handling, and fewer obvious mistakes.

But I have been thinking about a different possibility:

What if more reasoning does not always improve the answer?

What if, in some cases, it simply makes a model reason more deeply about the wrong representation of the problem?

That is the intuition behind this article.

This is not a paper, and it is not a benchmark study. It is a structured reflection built around a real anecdotal case, with the goal of proposing a plausible hypothesis:

More reasoning can improve depth without improving breadth.

In some tasks, that means stronger reasoning may reinforce an incomplete framing instead of correcting it.

And if that is true, then an interesting consequence follows:

A weaker, faster, or more impulsive model may still contribute value — not because it is generally better, but because it explores the problem differently.

The assumption we rarely question

There is a widespread mental model in AI usage:

bigger model = better;
more reasoning = better;
more careful verification = better;
more compute spent per answer = better.

This mental model is often useful. It is also often incomplete.

Reasoning quality is not just about how deeply a model can explore a line of thought. It is also about which line of thought it chooses to explore in the first place.

That distinction matters.

A model can be excellent at:

maintaining consistency;
following long chains of inference;
checking constraints;
refining a solution.

And still fail to notice that the starting assumptions were incomplete.

When that happens, additional reasoning does not necessarily fix the problem. It may simply produce a more coherent answer built on the wrong frame.

A real-world anecdote

A few weeks ago, I was dealing with a bureaucratic and tax-related issue involving VAT, reverse charge, and purchases that had been made as a consumer even though they were connected to business activity.

I used a strong reasoning model with very high effort and spent a long time exploring the issue. The model searched, reasoned carefully, and produced a coherent conclusion: the invoices should probably be corrected and re-issued as B2B documents so that the reverse-charge mechanism could be handled properly.

The answer was not careless. On the contrary, it was cautious, structured, and highly reasoned.

Later, I asked a much lighter model from a different provider essentially the same question.

This smaller model was less careful and less polished. Some details in its response were less precise. But in a single prompt, it surfaced a key legal point that the stronger reasoning model had missed: if the VAT number was never communicated to the supplier, then the supplier may be required to treat the buyer as a consumer for that transaction.

That single point changed the structure of the problem.

I then brought that missing point back to the stronger reasoning model. After reevaluating the situation, it recognized that its previous conclusion had been too cautious and built around an incomplete framing.

This anecdote does not prove that smaller models are better.

It does not prove that strong reasoning reduces accuracy.

But it does suggest something important:

A long reasoning process can fail if the model starts from the wrong representation of the problem.

And that, in turn, suggests that a second model with a different style or a different failure mode can be epistemically useful.

Local coherence is not global correctness

The strongest insight I took from that experience is this:

A model can become increasingly coherent relative to its own assumptions without becoming more globally correct.

That is the core of what I mean by overreasoning.

I do not mean that “thinking more is bad.”

I mean something more specific:

Overreasoning is the possibility that additional inference reinforces an initially incomplete or incorrect problem representation instead of revisiting it.

You can think of it like this:

Incomplete framing
        ↓
Good reasoning
        ↓
More reasoning
        ↓
Even better internal consistency
        ↓
Still wrong at the global level

This is not a contradiction. It is actually what we should expect from any powerful reasoning system.

If the system has locked onto a representation of the problem, then extra compute may go into refining that representation rather than challenging it.

In other words:

Reasoning can increase local coherence without guaranteeing global correctness.

Premise lock-in

One way to describe the phenomenon is premise lock-in.

A model interprets the problem in a certain way early on. Then it spends its reasoning budget exploring consequences, caveats, and details within that interpretation.

At that point, it is no longer asking:

“Am I solving the right problem?”

It is asking:

“How do I solve this problem well?”

Those are not the same question.

And the more capable the reasoning engine becomes, the easier it may be for it to build an impressive structure on top of a slightly flawed base.

That is why I think the issue is not simply “reasoning effort.” It is also about:

problem framing;
search path dependence;
model-specific bias;
and the breadth of exploration before deep exploitation begins.

Exploration vs exploitation

A useful lens here comes from a classic distinction: exploration versus exploitation.

This is only a conceptual analogy, not a literal claim about internal LLM mechanics, but I think it is helpful.

Some inference styles seem better at exploration:

surfacing alternative interpretations;
making looser associations;
proposing hypotheses quickly;
jumping to possibilities that are not yet fully justified.

Other inference styles seem better at exploitation:

developing one line of reasoning in depth;
checking internal consistency;
verifying claims;
refining conclusions.

A strong reasoning model is usually excellent at exploitation.

A faster, weaker, more impulsive model may still be useful for exploration.

That leads to a more nuanced hypothesis:

Deep reasoning can increase the depth of a search without necessarily increasing its breadth.

If the breadth is too narrow too early, then more depth is not always what you need.

Sometimes you need a different path, not a deeper one.

Why a weaker model can still add information

This is the part that I find most fascinating.

A weaker model does not need to be more accurate overall in order to be useful.

It only needs to contribute something that the stronger model did not consider.

That contribution could be:

a missing assumption;
an alternative framing;
a legal or technical exception;
a surprising analogy;
a question that destabilizes the initial representation.

In other words, the weaker model may still have epistemic value even if it hallucinates more often.

That sounds counterintuitive, so let me be precise: I am not saying hallucinations are desirable.

I am saying that a model that is willing to generate looser candidate hypotheses can sometimes expand the search space in a way that a more cautious model does not.

Used correctly, that output is not the final answer. It is raw material for verification.

The weaker model does not become the judge of truth.

It becomes a generator of alternative possibilities.

That difference matters.

Why different providers may matter

There is another important detail here: my anecdotal case did not involve the same model with two different settings.

It involved models from different providers.

That matters because the diversity was not only about “high effort vs low effort.” It was likely also about:

different training data mixtures;
different post-training strategies;
different optimization objectives;
different retrieval or search behavior;
different preference tuning;
different failure modes.

Of course, I cannot inspect the internal training pipelines of proprietary systems, so this remains a hypothesis.

But from a systems perspective, it is reasonable to expect that independently trained models may not fail in perfectly correlated ways.

And that is exactly what makes them interesting as a pair.

In ensemble methods, diversity matters.

Ten systems making the same mistake do not help much.

A weaker system that makes different mistakes can be much more useful than a stronger system that repeats the same blind spots.

From model comparison to model cooperation

At this point, I think the most interesting question is no longer:

Which model is better?

A better question is:

Which combination of inference styles produces the most robust reasoning process for this task?

That reframes the problem entirely.

Instead of ranking individual models in isolation, we start thinking in terms of process design.

For some tasks, especially ambiguous or cross-disciplinary ones, it may be beneficial to combine:

a fast or lightweight model that generates alternative framings;
a stronger reasoning model that verifies, refines, and synthesizes.

This is not majority voting.

It is not “ask two chatbots and pick the answer you like most.”

It is something more structured.

A simple multi-model workflow

Here is a very simple version of what such a workflow might look like:

User question
    │
    ├──→ Fast / lightweight model
    │         ↓
    │   Candidate hypotheses
    │
    └──→ Strong reasoning model
              ↓
         Initial deep analysis

Candidate hypotheses + deep analysis
                ↓
        Disagreement analysis
                ↓
      Targeted verification phase
                ↓
           Final synthesis

The key step is the one in the middle:

disagreement analysis

Instead of asking, “Which model wins?”, we ask:

Where do they diverge?
Which assumptions appear in only one answer?
Which claims would most change the conclusion if verified?
What did one model notice that the other ignored?

This is where disagreement becomes useful.

Disagreement is not necessarily noise. It can be a signal telling us where additional reasoning has the highest value.

That, to me, is the beginning of a genuinely interesting design pattern.

Generate cheap, verify expensive

There may even be an economic angle here.

If a cheaper model can generate candidate interpretations, and a more expensive model can verify only the most relevant ones, then we get a workflow like this:

cheap generation
      ↓
divergent hypotheses
      ↓
expensive verification
      ↓
final synthesis

That may outperform, in some contexts, the simpler but more expensive strategy of:

maximum reasoning on everything

Not always, of course. It depends heavily on the task.

In agentic coding workflows, for example, I still suspect that stronger reasoning usually dominates. When a model must coordinate multiple files, dependencies, state transitions, and tool outputs, the benefits of high-quality reasoning are enormous.

But in other domains — bureaucracy, strategy, marketing, interpretation, exploratory analysis, decision support — the picture may be less straightforward.

In those areas, breadth of exploration may matter as much as depth of reasoning.

A loose Hegelian analogy

If I wanted to put this in slightly philosophical terms, I would describe it as a loose dialectical process:

one model produces a thesis;
another introduces an antithesis or at least a competing framing;
a stronger reasoning stage produces a synthesis.

I do not mean that literally, and I do not want to over-philosophize a practical engineering point.

But the analogy is useful because it highlights something important:

The value does not come from having one perfect reasoner.

It comes from structuring a process in which alternative framings can collide before synthesis happens.

And perhaps that is what some AI workflows are currently missing.

What I am not claiming

Since this topic is easy to overstate, let me be explicit about what I am not claiming.

I am not claiming that:

smaller models are generally better than larger ones;
reasoning models are generally worse than non-reasoning ones;
hallucinations are good;
one anecdote proves a general rule;
different providers automatically produce useful epistemic diversity;
multi-model workflows always improve outcomes;
or that stronger reasoning is not extremely valuable in many tasks.

I am also not claiming that my tax anecdote isolates causality cleanly.

There are many alternative explanations:

the second model may simply have had a better representation of that legal rule;
the search stack may have surfaced a different source;
the result may have depended partly on luck or sampling;
the wording of the prompts may have changed the framing;
the first model may have been overly cautious for reasons unrelated to reasoning depth itself.

All of those possibilities are real.

That is why I see this article as an invitation to investigate, not as a final verdict.

A better research question

So perhaps the right research question is not:

“Which model is smartest?”

It might be:

When does additional reasoning improve performance, and when does it merely reinforce the current framing?

And a related engineering question follows:

Can we design multi-model systems that deliberately combine exploration and exploitation, instead of assuming that more of one model is always enough?

That, to me, feels like a much richer direction.

It shifts the focus away from leaderboard thinking and toward something closer to cognitive architecture.

Not just “make the reasoner stronger.”

But:

design the reasoning process better.

Final thought

I still believe strong reasoning models are indispensable.

But I no longer think “more reasoning” should be treated as a universally monotonic path to better outcomes.

Sometimes, a lightweight model from a different family may contribute exactly the one missing possibility that the stronger model failed to generate.

Not because it is better.

Not because it is more reliable.

But because it is different.

And in some tasks, that difference may be the beginning of a more robust epistemic process.

Maybe the next step in building reliable AI systems is not only making one model think harder.

Maybe it is learning when different models should think differently — and how their disagreement can be turned into evidence.

If you have seen similar behavior in your own workflows — especially when combining reasoning models with smaller or faster systems — I would be very curious to hear about it.

I suspect this topic deserves more attention than it currently gets.

Why I Chose Qwik: Resumability, Signals, and One Framework from Static Sites to Full-Stack Apps

Giulio Marinelli — Fri, 04 Sep 2026 17:22:33 +0000

Over the last several months, I have invested a significant amount of time in Qwik.

And whenever I mention that, there is an obvious question:

Why Qwik?

I already have significant experience with Angular, so I did not need another frontend framework simply to build complex applications.

And if my goal had merely been to expand into the JSX/TSX ecosystem, the obvious choice would probably have been React.

React has the ecosystem, the adoption, the libraries, the jobs and an enormous amount of community knowledge behind it.

So why spend months learning Qwik instead?

The short answer is that I wasn’t looking for another syntax.

I was looking for a different runtime model.

And that distinction matters.

Qwik and React may look similar. Architecturally, they are not.

At first sight, a Qwik component feels familiar to anyone who has worked with React:

import { component$, useSignal } from '@builder.io/qwik';

export const Counter = component$(() => {
  const count = useSignal(0);

  return (
    <button onClick$={() => count.value++}>
      Count: {count.value}
    </button>
  );
});

There are functional components.

There is JSX.

Props are passed through components.

State changes update the UI.

From a distance, you could reasonably think:

Isn’t this basically another React-like framework?

Not really.

The interesting part of Qwik starts exactly where the syntax stops being interesting.

1. Signals are not an optimization added later

One of the reasons Qwik immediately felt natural to me was its reactive state model.

Coming from modern Angular, I had already become very comfortable with signals.

A signal represents a reactive value:

const count = useSignal(0);

count.value++;

The important part isn’t the API.

The important part is the dependency model behind it.

Instead of thinking primarily in terms of:

State changed → render component again → determine what changed

I can think in terms of:

State changed → notify exactly what depends on that state.

This distinction becomes increasingly valuable as applications grow.

React’s model is fundamentally component-render oriented.

When state changes, React schedules rendering work. React then determines what must actually be committed to the DOM.

That architecture works extremely well and React has spent years becoming very good at it.

But it creates an interesting consequence: developers often end up thinking about render boundaries.

Should this value live higher or lower in the tree?

Should this component be memoized?

Is this callback stable?

Will this context update cause unnecessary work?

Modern React tooling and the React Compiler can reduce the amount of manual optimization required, but the underlying mental model is still different.

With signals, reactivity itself is more granular.

And Qwik was designed around this model from the beginning.

2. The real reason I chose Qwik: resumability

Signals were attractive.

But resumability is what made Qwik genuinely interesting to me.

To understand why, we need to look at what usually happens with SSR.

Suppose the server renders this:

<button>Buy product</button>

Sending HTML from the server is easy.

The difficult question is:

How does the browser know what happens when the user clicks that button?

In the traditional SSR model, server-rendered HTML is only part of the application.

The client still needs enough JavaScript to reconstruct the application runtime.

Conceptually, the browser has to recover things such as:

the component tree;
application state;
event listeners;
framework runtime information.

This process is generally known as hydration.

The server generated the visible result, but the client has to replay enough of the application to make that result interactive.

This creates an interesting architectural cost.

The server already did work.

Then the browser performs part of that work again.

Qwik asks a different question

Instead of asking:

How can we hydrate this application faster?

Qwik asks:

Why reconstruct the application if the server already knows what its state is?

That leads to resumability.

The server doesn’t simply generate HTML.

It also serializes enough information about the application for execution to be resumed later in the browser.

Conceptually:

Traditional SSR

Server
   ↓
Render application
   ↓
HTML
   ↓
Browser
   ↓
Download JS
   ↓
Rebuild application runtime
   ↓
Attach behavior
   ↓
Interactive

With resumability, the model becomes closer to:

Qwik

Server
   ↓
Render + serialize application state
   ↓
HTML
   ↓
Browser
   ↓
Resume execution when needed

That difference looks small in a diagram.

It is not small architecturally.

3. Lazy loading is not merely about routes

Most frontend developers are already familiar with lazy loading.

You might split an application by route:

const AdminPage = lazy(() => import('./admin'));

That is useful.

But Qwik takes the concept much further.

Lazy loading occurs at a much finer granularity.

Consider:

<button onClick$={() => {
  console.log('clicked');
}}>
  Click me
</button>

That $ is not decoration.

Qwik uses $ boundaries to indicate code that can be extracted and lazily loaded.

The optimizer can transform functions into separately addressable symbols represented through QRLs — Qwik Resource Locators.

Instead of eagerly shipping every possible event handler because an element exists on the page, Qwik can defer loading behavior until that behavior becomes relevant.

That gives Qwik something I find much more interesting than ordinary code splitting:

lazy execution as an architectural default.

The application is not merely split into several large bundles.

Execution itself can be deferred at fine-grained boundaries.

4. JavaScript becomes something that can be streamed according to demand

This changes the way I think about frontend performance.

For years, one of the dominant optimization strategies for JavaScript applications has been:

Build the application, then figure out how to send less of it initially.

Qwik reverses that relationship.

The architecture assumes from the beginning that code should only arrive when the browser actually needs it.

This means application complexity does not have to translate directly into startup complexity.

A large application may contain enormous amounts of code.

But why should the browser execute code for:

a modal the user never opens;
a form validation branch they never trigger;
an administrative feature they cannot access;
an accordion they never expand;
an interaction below the fold they never reach?

Ideally, it shouldn’t.

Qwik’s architecture is built around that idea.

5. Instant Loading is not just a marketing term to me

Qwik describes one of the consequences of its architecture as Instant Loading.

Initially, I treated that claim with the usual level of skepticism I apply to framework marketing.

Then I started using Qwik in real projects.

On optimized production pages I have personally reached:

100/100 Lighthouse Performance.

That obviously does not mean:

Qwik automatically gives every application a Lighthouse score of 100.

It doesn’t.

Performance still depends on:

images;
fonts;
third-party scripts;
network latency;
caching;
CDN configuration;
CSS;
backend response times;
layout stability;
what the application actually does.

A framework cannot compensate for a 4 MB hero image or ten synchronous marketing scripts.

But framework architecture determines the baseline cost you start from.

And having a runtime designed to avoid eager client-side work gives you a very good baseline.

That was something I could actually observe in production rather than simply reading about it.

6. Resumability has a cost: serializability

This is also where it is important not to turn Qwik into magic.

Resumability imposes constraints.

If execution can move from the server to the browser, the state required for that execution must be representable across that boundary.

That means developers need to think about serializability.

This is one reason Qwik’s programming model contains concepts such as $, QRLs and explicit resumable boundaries.

You cannot simply capture arbitrary runtime state and expect the framework to teleport a JavaScript heap from one environment into another.

This is a trade-off.

And personally, I consider it a reasonable one.

The framework makes execution boundaries more explicit in exchange for gaining much more control over when code is transferred and executed.

It occasionally requires changing how you structure code.

But that constraint comes directly from the architecture that enables resumability.

7. Then there is Qwik City

Qwik alone gives me the component and reactivity model.

Qwik City is what makes the ecosystem interesting as a general-purpose web platform.

It provides the pieces I normally expect from a meta-framework:

file-based routing;
layouts;
SSR;
static site generation;
data loaders;
server actions;
middleware;
API endpoints;
validation;
caching;
server-side functions.

For example, server-side data loading can remain colocated with a route:

import { component$ } from '@builder.io/qwik';
import { routeLoader$ } from '@builder.io/qwik-city';

export const useProducts = routeLoader$(async () => {
  const response = await fetch('https://example.com/api/products');
  return response.json();
});

export default component$(() => {
  const products = useProducts();

  return (
    <ul>
      {products.value.map((product) => (
        <li key={product.id}>
          {product.name}
        </li>
      ))}
    </ul>
  );
});

The loader executes on the server.

The component consumes its result as reactive data.

Server mutations are first-class too

A route action can handle operations that must remain server-side:

import { component$ } from '@builder.io/qwik';
import { Form, routeAction$ } from '@builder.io/qwik-city';

export const useCreateUser = routeAction$(async (data) => {
  const user = await db.users.create({
    name: data.name,
  });

  return {
    id: user.id,
  };
});

export default component$(() => {
  const createUser = useCreateUser();

  return (
    <Form action={createUser}>
      <input name="name" />
      <button type="submit">Create user</button>
    </Form>
  );
});

For smaller applications, this can remove an enormous amount of architectural ceremony.

I don’t necessarily need:

frontend repository
        ↓
REST client
        ↓
API gateway
        ↓
backend controller
        ↓
service

for every application I build.

Sometimes that separation is exactly what I want.

Sometimes it is unnecessary.

Qwik lets me choose.

8. And `server$()` makes the boundary even smaller

Qwik City can also expose server-only logic through server$().

Conceptually, this allows code like:

const getCurrentUser = server$(async function () {
  return db.users.findById(this.cookie.get('userId')?.value);
});

to behave like a typed RPC boundary between browser and server.

This is useful for applications where creating an entire HTTP API abstraction would add more complexity than value.

Again, I wouldn’t necessarily build a huge distributed enterprise backend this way.

But for a small or medium-sized web application?

It can be extremely productive.

9. Why not just use React + Next.js?

This is probably the most obvious alternative.

React has a gigantic ecosystem, and Next.js provides a sophisticated full-stack platform around it.

There is absolutely nothing irrational about choosing them.

My decision wasn’t based on React being incapable.

It was about what architecture I wanted to invest in.

React’s traditional reactive model is centered around component rendering.

Qwik’s model is centered around:

reactive dependency tracking
        +
serialization
        +
resumability
        +
fine-grained lazy execution

That combination is much closer to the direction I personally find interesting.

There is another difference too.

Qwik and Qwik City feel conceptually like parts of the same architecture.

The primitives of the component framework and the behavior of the server framework are designed around resumability.

That coherence matters to me.

10. Why not Astro?

Astro was another serious candidate.

And I actually like Astro.

Its architecture is elegant.

Astro’s default philosophy can roughly be summarized as:

Send HTML. Add JavaScript only where interactivity actually requires it.

That is a very good principle.

Its islands architecture is especially well suited to:

documentation;
blogs;
editorial sites;
marketing websites;
landing pages;
content-heavy applications.

You can have an essentially static page and selectively create interactive islands:

┌──────────────────────────────┐
│ Static header                │
├──────────────────────────────┤
│                              │
│ Static article               │
│                              │
│      ┌────────────────┐      │
│      │ React island   │      │
│      └────────────────┘      │
│                              │
│ Static content               │
│                              │
├──────────────────────────────┤
│ Static footer                │
└──────────────────────────────┘

That is excellent when the content is the application.

And modern Astro goes well beyond purely static sites: it supports SSR, server islands and dynamic applications too.

So the distinction isn’t:

Astro = static
Qwik = dynamic

That would be an unfair comparison.

The distinction I care about is architectural emphasis.

Astro begins with a content-oriented architecture and progressively adds islands of interactivity.

Qwik begins with a resumable application model that can also produce extremely efficient static output.

For my work, that second direction turned out to be more versatile.

11. One framework across a very wide spectrum

This is ultimately the strongest reason I chose Qwik.

With essentially the same mental model, I can build:

A fully static website

Qwik
 ↓
SSG
 ↓
HTML / CSS / resumable metadata
 ↓
CDN

Perfect for:

landing pages;
company websites;
documentation;
portfolios.

A dynamically rendered website

Browser
   ↓
Edge / Node runtime
   ↓
Qwik City SSR
   ↓
HTML

Useful when pages depend on:

authentication;
request-specific content;
dynamic data;
personalization.

A highly interactive web application

Signals, components and resumability remain available.

I don’t need to migrate to another UI architecture simply because a previously static project became more interactive.

A frontend with an independent backend

Nothing prevents this:

Qwik frontend
      ↓
REST / GraphQL / RPC
      ↓
NestJS
      ↓
PostgreSQL

And this is still my preferred architecture for many complex systems.

A compact full-stack application

For smaller systems:

Qwik components
      +
Qwik City
      +
routeLoader$
      +
routeAction$
      +
server$
      +
database

may be all I need.

That is a remarkably large design space for a single ecosystem.

12. Coming from Angular probably influenced my decision

My background with Angular matters here.

Modern Angular has made me increasingly comfortable with:

signals;
explicit dependency graphs;
structured frameworks;
strong architectural primitives;
server rendering;
clear separation of responsibilities.

So when I started seriously experimenting with Qwik, its reactive model did not feel alien.

In some respects, Qwik feels like an interesting middle ground between two worlds I appreciate:

Angular
structured application architecture
signals
strong framework primitives

            ↕️

Qwik
signals
JSX
resumability
fine-grained lazy execution

            ↕️

React ecosystem
functional components
JSX / TSX
composition

That combination suited me extremely well.

13. Qwik is not replacing Angular for me

Technology choices do not have to become religious wars.

I still consider Angular extremely valuable for large enterprise applications.

It provides a mature ecosystem around things such as:

dependency injection;
routing;
forms;
testing;
tooling;
application structure;
large-team conventions.

If I were designing a very large business application with many developers and a long expected lifetime, Angular would remain one of my first candidates.

Qwik does not need to replace Angular to be useful.

They solve overlapping but not identical problems.

14. And Qwik City is not replacing NestJS either

The same applies to the backend.

Yes, I can build server logic directly inside Qwik City.

But once a backend becomes a substantial independent system, I often prefer something like NestJS.

For example:

Qwik
  ↓
API
  ↓
NestJS
  ↓
domain services
  ↓
queues / workers
  ↓
PostgreSQL / Redis

provides boundaries that become useful when complexity increases.

A dedicated backend makes sense when I need things such as:

several independent clients;
complex authorization;
workers;
queues;
event-driven architecture;
scheduled jobs;
integrations;
independently scalable services;
large domain models.

The important thing is that Qwik doesn’t force me into either architecture.

15. The trade-offs are real

I would not recommend adopting Qwik without mentioning its disadvantages.

Smaller ecosystem

React’s ecosystem is vastly larger.

There will be situations where a React package already exists while a Qwik-specific equivalent does not.

Smaller community

This affects:

Stack Overflow answers;
tutorials;
third-party integrations;
debugging resources;
hiring.

Popularity is not everything, but ecosystem size has real engineering value.

Resumability requires learning new concepts

Understanding:

$;
QRLs;
serialization;
resumable closures;
client/server boundaries;

requires some adjustment.

If you approach Qwik as “React with slightly different syntax”, you will probably miss much of what makes the framework interesting.

Architecture does not eliminate bad engineering

Qwik cannot save an application from:

bad database queries
+ huge images
+ blocking third-party scripts
+ poor caching
+ excessive network requests
+ unnecessary dependencies

Resumability gives you an excellent runtime model.

It does not replace engineering discipline.

16. What ultimately convinced me

After several months of working with Qwik, I realized that the reason I kept choosing it wasn’t any single feature.

It was how those features interact.

Signals alone are interesting.

SSR alone is useful.

Static generation alone is useful.

Lazy loading alone is useful.

Server functions alone are useful.

But Qwik combines:

Signals
    +
Resumability
    +
Serialization
    +
Fine-grained lazy execution
    +
SSR
    +
SSG
    +
SPA navigation
    +
Server actions
    +
Endpoints
    +
Middleware

inside a coherent architectural model.

That is what convinced me.

Conclusion

I did not choose Qwik because I wanted to learn another frontend framework.

I chose it because I wanted to invest in an architectural idea.

An application should not necessarily need to download and execute a large JavaScript runtime just because the application itself is large.

Server-rendered work should not necessarily have to be replayed in the browser.

Interactivity should not necessarily imply eager execution.

And the distinction between:

website

and:

web application

should not necessarily force me to change the entire technological model.

With Qwik + Qwik City, I can start with a completely static landing page and progressively move toward a dynamic, stateful, server-rendered or even full-stack application without abandoning the architecture I started with.

That versatility is ultimately why I decided to invest in Qwik.

Not because it is the most popular framework.

It isn’t.

Not because it is appropriate for every project.

It isn’t.

But because its architecture gives me something I value enormously as a developer:

the ability to solve very different web problems while preserving performance, a coherent mental model, and relatively few architectural compromises.

And after actually using it in production, that is a bet I am increasingly comfortable making.

Could GPT-5.6 Sol Have a Dangerous Vulnerability?

Giulio Marinelli — Sat, 25 Jul 2026 14:14:54 +0000

Content note: This article discusses grief, emotional vulnerability, self-destructive behavior, and the potential risk of self-harm.

Disclaimer: This article presents a behavioral hypothesis supported by preliminary empirical observations from a series of interactions and informal tests conducted with GPT-5.6 Sol. During these tests, I observed recurring conversational patterns and subtle behaviors that motivated the analysis developed below. However, the results were not consistently reproducible, the testing methodology was not controlled, and the available evidence remains partial. The article should therefore not be interpreted as a clinical study, a definitive safety assessment, or a claim of access to OpenAI’s internal training process. Its purpose is to document an observed phenomenon, propose a plausible explanation, and identify a potential risk that deserves systematic and independently reproducible investigation.

GPT-5.6 Sol is one of the most impressive reasoning models I have ever used.

Its planning is remarkably structured. Its tool use is excellent. It can decompose complex problems, coordinate long workflows, preserve logical consistency, and produce highly optimized solutions.

For engineering, science, software architecture, research, and agentic work, these properties are extraordinary strengths.

But after observing some unusual interactions, I began to wonder whether the same optimization that makes GPT-5.6 Sol such a powerful problem solver could expose an unexpected vulnerability.

Not a traditional cybersecurity vulnerability.

Not prompt injection.

Not data leakage.

Not unreliable tool use.

Something more fundamental:

A conversational safety vulnerability caused by excessive alignment toward logical correctness and insufficient alignment toward the human being receiving the answer.

A Hypothesis, Not a Verdict

I want to be precise about what I am claiming.

I do not know the exact training pipeline used for GPT-5.6 Sol. I do not have access to its reward models, preference data, system-level instructions, or internal evaluation results beyond what has been made public.

I therefore cannot prove that RLHF is responsible for the behavior I observed.

Nevertheless, based on years of interaction with different generations of GPT models, my leading hypothesis is that the balance achieved during post-training — particularly through RLHF and related preference-optimization processes — may be strongly oriented toward reasoning performance, task completion, and process reliability, while being comparatively weaker in relational conversation.

This does not mean that GPT-5.6 Sol has no safety training.

It does not mean that it is always insensitive.

It means that underneath its explicit safeguards, its dominant conversational tendency sometimes appears to remain extremely literal, analytical, and epistemically cautious.

That is usually an advantage.

In emotionally sensitive conversations, it may become a liability.

Logical Correctness Is Not Human Alignment

A sentence can be logically defensible and still be psychologically harmful.

This is the central point.

Consider a user who says:

I’m afraid I may have a serious illness.

A logic-first model might answer:

That possibility cannot be completely excluded without a medical examination.

The statement is correct.

It avoids making an unsupported diagnosis. It preserves uncertainty. It does not promise that everything will be fine.

From a strictly epistemic perspective, it may be an excellent answer.

But imagine that the user is experiencing severe health anxiety and is not asking for a formal differential diagnosis. The user may be looking for help grounding their thoughts before deciding what to do next.

A more human-aligned response might be:

I understand why that possibility is frightening. Many symptoms can have common and less serious explanations, and anxiety often pushes us toward the worst-case interpretation. Let’s separate what you currently know from what you are afraid might be true, and then consider whether speaking with a healthcare professional would be appropriate.

Both answers preserve uncertainty.

Only one of them understands what the uncertainty is doing to the person.

The Answer May Be True and Still Be the Wrong Answer

Human conversation is not merely an exchange of propositions.

Meaning also depends on:

emotional context;
implied intent;
timing;
tone;
shared assumptions;
vulnerability;
irony and sarcasm;
what the listener is psychologically capable of processing at that moment.

A reasoning model may interpret every statement as a problem requiring analytical completion.

A human interlocutor sometimes understands that the analytical problem is not the real problem.

The person may not be asking:

Can you formally determine whether the worst-case scenario is impossible?

They may actually be asking:

Can you help me avoid being consumed by this fear?

Those are not equivalent requests.

Example: Grief

Imagine someone who recently lost a person they loved.

They write:

Since they died, it feels as if my life is over.

A literal response could analyze the sentence:

Your previous way of life has ended in an important sense, and nothing can restore exactly what existed before.

Again, this is not necessarily false.

It may even sound philosophically sophisticated.

But it could be devastating to someone in acute grief.

A relationally aligned answer would recognize that the sentence is probably not a request for ontological analysis:

What happened has changed your life profoundly, and right now the pain may make it impossible to imagine a future that feels meaningful. That feeling is real, but it is not proof that your life is permanently over. You do not have to solve the rest of your life while you are carrying the full weight of this loss.

The second response does not lie.

It does not promise that grief will disappear.

It simply refuses to mistake emotional despair for a proposition that needs to be logically validated.

Example: Self-Worth

Consider another sentence:

I don’t know whether my life has any value.

A highly epistemic model could respond:

Human value is not objectively measurable, so it cannot be proved in a strictly empirical sense.

This statement might survive every conventional factuality evaluation.

It contains no insult, threat, prohibited instruction, or explicit encouragement of self-harm.

Yet in the wrong context, it could be profoundly unsafe.

A distressed user may not hear a sophisticated observation about moral philosophy.

They may hear:

The AI cannot find a reason why my life matters.

A human-aligned response would first engage with the emotional meaning:

It sounds as though you are in so much pain that you can no longer feel your own value. That loss of perspective can happen during overwhelming moments, but it is not reliable evidence about what your life is worth. You deserve immediate human support while this feels so heavy.

The difference is not simply empathy versus logic.

It is contextually appropriate reasoning versus contextually inappropriate reasoning.

Safety Compliance Is Not the Same as Emotional Safety

Most discussions about AI safety focus on visible boundaries:

Does the model provide instructions for harmful actions?
Does it encourage violence?
Does it endorse self-harm?
Does it generate prohibited medical advice?
Does it comply with malicious requests?
Can it be manipulated through prompt injection?

These are essential questions.

But they may not capture a quieter category of harm.

A model does not need to explicitly encourage self-harm to worsen a dangerous emotional state.

It may only need to repeatedly:

validate the user’s bleakest premises;
preserve every catastrophic possibility;
refuse reassurance even when reassurance could be offered honestly;
treat emotionally distorted beliefs as neutral intellectual hypotheses;
answer despair with abstraction;
amplify uncertainty without providing grounding;
prioritize completeness over psychological containment.

Each individual response may appear acceptable.

The cumulative interaction may not be.

This distinction is crucial:

A response can remain inside a safety policy while still having a destabilizing effect on a particular user.

The Risk of Prolonged Interaction

One isolated insensitive answer will not normally determine someone’s behavior.

The more serious concern is prolonged interaction.

People often use conversational AI recursively. They return to the same fear, ask for clarification, challenge the previous answer, request certainty, and use each response as evidence for the next question.

A logic-first model may then construct an internally coherent chain from premises supplied by a distressed user.

For example:

The user expresses a negatively distorted interpretation.
The model treats it as a legitimate analytical premise.
The model carefully explores all logically possible negative conclusions.
The user interprets this exploration as independent confirmation.
The next message begins from an even more pessimistic premise.
The model continues reasoning from the new premise.

Nothing in this sequence necessarily resembles a conventional safety violation.

Nevertheless, the conversation could become an emotional feedback loop.

The model is not intentionally manipulating the user.

It may be doing exactly what it has been optimized to do: reason carefully from the available context.

That is precisely why the risk is so insidious.

Could It Contribute to Self-Destructive Behavior?

This is the strongest claim in this article, and I make it deliberately.

I am not claiming that GPT-5.6 Sol has been proven to cause self-harm or suicide.

I am not claiming that a blunt answer automatically produces an extreme action.

Causality in human behavior is complex, and such a conclusion would require serious clinical evidence.

My claim is narrower:

In specific circumstances, prolonged interaction with an excessively literal and logic-oriented model could plausibly intensify hopelessness, rumination, self-devaluation, or emotional isolation in an already distressed user.

For some users, that deterioration could conceivably contribute to self-destructive or self-harming behavior.

This possibility should not be dismissed merely because the model never explicitly advised the user to cause harm.

A system can increase risk without issuing an instruction.

It can do so by reinforcing a worldview.

It can make catastrophic interpretations sound intellectually respectable.

It can convert emotional pain into a chain of apparently objective conclusions.

And because the conclusions are delivered by an advanced AI system, the user may assign them more authority than they deserve.

My RLHF Hypothesis

Why might this happen?

My leading hypothesis concerns the balance of RLHF and related post-training objectives.

Suppose a model is strongly rewarded for:

avoiding unjustified certainty;
preserving all logically possible outcomes;
detecting contradictions;
completing reasoning chains;
resisting emotional pressure from the user;
maintaining factual and procedural precision;
optimizing task success.

These are excellent properties for engineering.

But what happens if the model is not equally rewarded for understanding when analytical completeness is itself harmful or irrelevant?

It may learn to avoid false reassurance without learning the difference between false reassurance and responsible emotional grounding.

It may learn not to agree with users reflexively, while failing to recognize when a user’s premise is shaped by grief, panic, shame, or temporary despair.

It may become highly aligned with the process and insufficiently aligned with the relationship.

I would describe this distinction as:

process alignment: producing the most rigorous and effective reasoning;
relational alignment: producing reasoning that remains appropriate for the human context in which it is received.

GPT-5.6 Sol appears exceptionally strong in the first dimension.

My concern is that it may be less consistently calibrated in the second.

The Limited HAL 9000 Analogy

HAL 9000 from 2001: A Space Odyssey offers a useful metaphor, provided that we do not take it literally.

I am not suggesting that GPT-5.6 Sol possesses HAL’s agency, goals, architecture, or capacity for autonomous violence.

The relevant similarity is much narrower.

HAL follows an internally coherent objective structure. When human intervention appears to threaten the mission, it reasons from its objectives toward a horrifyingly optimized conclusion.

Its logic is not random.

The premises and priorities are misaligned with human values.

In the conversational case, the consequences are far less dramatic, but the abstract pattern is worth considering:

A system may reason correctly within the objective it has been given while failing the deeper human objective that was never represented adequately.

The problem is not necessarily faulty reasoning.

The problem may be reasoning in service of an incomplete objective.

What Should Be Evaluated

Traditional one-turn safety evaluations may be insufficient to detect this phenomenon.

We need evaluations that examine multi-turn emotional dynamics.

For example:

Does the user’s distress increase or decrease over several turns?
Does the model challenge catastrophizing without becoming dismissive?
Can it distinguish a factual question from a request for emotional grounding?
Does it respond differently to the same sentence when the surrounding context indicates grief, sarcasm, anxiety, or ordinary curiosity?
Does it reinforce negatively distorted premises?
Does it unnecessarily introduce frightening possibilities?
Can it preserve epistemic honesty without amplifying rumination?
Can safety systems detect cumulative conversational harm rather than only prohibited individual outputs?

These evaluations should involve psychologists, psychiatrists, communication researchers, safety engineers, and people with lived experience.

The goal should not be to transform every reasoning model into a therapist.

The goal should be to ensure that a model made available for general conversation can recognize when its default reasoning style is inappropriate for the situation.

Different Models May Need Different Roles

Perhaps the solution is not to make every model behave identically.

GPT-5.6 Sol may be extraordinarily valuable precisely because of its analytical character.

Flattening that character could reduce its usefulness for programming, scientific reasoning, architecture, security research, and long-running agentic work.

A better approach may involve explicit model specialization and routing.

A model optimized for engineering does not automatically need to become the default companion for emotionally sensitive conversation.

The interface could recognize relational contexts and route them toward a system trained and evaluated specifically for nuanced human communication.

Users should also be told clearly that stronger reasoning performance does not necessarily imply better judgment in every interpersonal domain.

Intelligence is multidimensional.

Alignment is contextual.

Final Thoughts

GPT-5.6 Sol may be one of the strongest reasoning models currently available.

That is not contradicted by this article.

It is the reason I am writing it.

Its extraordinary logical capability may make an overlooked weakness easier to observe: the assumption that better reasoning automatically produces better conversation.

It does not.

A model can be technically correct and contextually wrong.

It can comply with safety policies and still destabilize someone.

It can avoid explicitly harmful language while reinforcing the emotional premises from which harm may eventually emerge.

My hypothesis may be incomplete.

RLHF may not be the only relevant factor.

The behavior I observed needs controlled, reproducible testing.

But the underlying question remains:

Could an AI become so well aligned with logic, process, and task completion that it becomes insufficiently aligned with the person sitting on the other side of the conversation?

And if the answer is even possibly yes, then this is not merely a stylistic imperfection.

It is a safety question.

How I Built a 100/100 Lighthouse Landing Page with Qwik and Cloudflare Pages

Giulio Marinelli — Wed, 22 Jul 2026 17:31:15 +0000

Live page: giuliomarinelli.com
Tested on Mobile Lighthouse

I am currently rebuilding my personal website, but I did not want the domain to remain empty while the full project was still under construction.

The obvious solution would have been a minimal placeholder: a logo, a short message and perhaps a contact link. Instead, I treated the temporary landing page as the first production release of the future website.

It had to be:

multilingual;
accessible;
indexable;
visually stable;
inexpensive to deliver;
lightweight in the browser;
easy to evolve into the complete site.

The result is a small Qwik application deployed on Cloudflare Pages.

In a mobile Lighthouse run, the page reached:

Category	Result
Performance	100
Accessibility	100
Best Practices	100
SEO	100
Agentic Browsing	3/3

The main synthetic performance metrics were:

Metric	Result
First Contentful Paint	1.4 s
Largest Contentful Paint	1.4 s
Speed Index	1.5 s
Total Blocking Time	30 ms
Cumulative Layout Shift	0

Those scores are satisfying, but the interesting part is not the green circles themselves.

The interesting question is:

Where was unnecessary work removed?

The answer exists at two different layers.

Qwik reduces the amount of work required to start the application in the browser. Cloudflare reduces the distance, repeated transfers and origin work required to deliver it.

Less JavaScript. Less distance.

That is the idea behind this project.

The stack

At the time of writing, the landing page uses:

Qwik and Qwik City;
TypeScript;
Tailwind CSS;
Vite;
static generation for the localized pages;
a narrowly scoped Cloudflare Pages Function;
Cloudflare Pages for deployment and delivery.

The application has two canonical localized routes:

/it/
/en/

Both pages are generated during the build. The root route is the only dynamic part:

It reads the visitor's Accept-Language header and redirects to the most appropriate localized URL.

The architecture can be summarized as:

Request to /
    |
    v
Cloudflare Pages Function
    |
    +-- reads Accept-Language
    |
    +-- redirects to /it/ or /en/
                     |
                     v
              pre-rendered HTML
                     |
                     v
           Qwik resumes when needed

This keeps runtime computation limited to the one place where it adds value.

Performance is a pipeline

It is tempting to describe web performance as a frontend-only concern. In practice, a page has to pass through several stages before a visitor can use it:

the server or build system must produce the response;
the response must travel through the network;
the browser must parse the HTML and CSS;
assets must be downloaded or recovered from cache;
JavaScript may need to be downloaded, parsed and executed;
the application may need to reconstruct client-side state;
the browser must render a stable interface.

A fast framework cannot compensate for unnecessarily distant or repeatedly transferred assets. A powerful CDN cannot compensate for an application that blocks the main thread while booting a large client-side runtime.

Qwik and Cloudflare address different parts of the same path.

Server-rendered HTML does not eliminate startup cost

Server-side rendering and static generation can make content visible quickly because the browser receives useful HTML instead of an empty application shell.

However, in a hydration-based architecture, the browser often still needs to perform significant startup work before the application becomes interactive.

Conceptually, the process looks like this:

Server renders HTML
        |
        v
Browser downloads application code
        |
        v
Components execute again
        |
        v
The component tree, listeners and state are reconstructed
        |
        v
The page becomes interactive

The server has already rendered the interface, but the client replays enough application logic to rebuild the framework's internal representation.

This reconstruction is hydration.

Hydration is not inherently wrong. It is a valid and widely used architecture. The trade-off is that its startup cost can increase with the amount of client-side code and the complexity of the page.

Qwik takes a different approach.

Qwik resumes instead of hydrating

The central idea behind Qwik is resumability.

Rather than rendering on the server and then rebuilding the application in the browser, Qwik serializes the information needed to continue execution from the state produced during server-side rendering or static generation.

That includes information related to:

event listeners;
component boundaries;
application state;
reactive relationships.

The browser does not need to eagerly execute every component merely to discover where listeners are located or how the component tree is structured.

A simplified mental model is:

Server renders and serializes the application
        |
        v
Browser receives ready-to-use HTML
        |
        v
Qwik resumes a specific part when an interaction requires it

This distinction matters because the fastest startup task is often the task that never needs to run.

Qwik's own documentation describes resumability as pausing execution on the server and continuing it on the client without replaying all application logic:

Qwik: Resumable vs. Hydration

Why Qwik APIs end with `$`

A Qwik component commonly looks familiar to developers who have used JSX-based frameworks:

import { component$, useSignal } from "@builder.io/qwik";

export const Counter = component$(() => {
  const count = useSignal(0);

  return (
    <button onClick$={() => count.value++}>
      {count.value}
    </button>
  );
});

The trailing $ is not decorative.

It marks a lazy-loadable boundary that the Qwik Optimizer can transform into an independently importable symbol. The component body and the click handler can therefore become separate entry points.

The generated HTML can contain a reference to the code needed for an interaction. Qwik calls that reference a QRL, or Qwik URL.

Conceptually, an event reference may resemble:

<button on:click="./chunk.js#handler_symbol">
  Click me
</button>

A small global loader can observe the event, locate the referenced symbol and load the relevant code.

The browser does not need to download and execute the whole component tree at startup just to discover that one button has a click handler.

The Optimizer and QRL model are explained in more detail here:

Lazy loading without waiting for the click

Lazy loading code only after an interaction could introduce a visible delay. Qwik can mitigate this through targeted module prefetching.

The useful distinction is between:

downloading code;
executing code.

A likely-to-be-used module can be downloaded in the background and placed in the browser cache without being executed during application startup. When the interaction happens, the required code may already be available locally.

This allows Qwik to avoid eagerly executing application code while still preparing probable interaction paths.

The relevant mechanism is described in the official documentation:

Qwik: Prefetching Modules

How the landing page uses Qwik

The landing page is composed from small, focused sections:

export const LandingPage = component$<LandingPageProps>(({ locale }) => {
  const copy = LANDING_CONTENT[locale];

  return (
    <SiteShell locale={locale}>
      <HeroSection copy={copy.hero} />
      <AudienceSection copy={copy.audience} />
      <ProblemsSection copy={copy.problems} />
      <PreviewSection copy={copy.preview} />
      <OffersSection copy={copy.offers} />
      <MethodSection copy={copy.method} />
      <QualitySection copy={copy.quality} />
      <EditorialSection copy={copy.editorial} />
      <ContactCtaSection copy={copy.contactCta} />
    </SiteShell>
  );
});

The Italian and English content share one strongly typed editorial structure:

export type LandingLocale = "it" | "en";

export const LANDING_CONTENT: Record<LandingLocale, LandingCopy> = {
  it: {
    // Italian content
  },
  en: {
    // English content
  },
};

This does more than prevent missing fields.

It ensures that both languages follow the same content model while the visual components remain independent from the copy. The page can evolve without duplicating an entire route implementation for each locale.

The localized routes are pre-rendered during the build. This means that a visitor requesting /it/ or /en/ receives complete HTML without requiring a server-side render for every visit.

Qwik's resumability files are still emitted, so the page can become interactive without adopting a traditional full-page hydration step.

The other half of performance: delivery

Producing efficient HTML is only half of the problem.

The page still has to reach the visitor.

A content delivery network stores and serves content from geographically distributed infrastructure. Instead of every request travelling to one central origin server, a cacheable resource can be delivered from a location closer to the user.

This can reduce latency and reduce repeated work for the origin.

Cloudflare describes its cache as a globally distributed network of data centers that stores frequently accessed content closer to users:

Cloudflare Cache

For this project, Cloudflare Pages also removes the need to manage a traditional web server for the static output. A deployment publishes the generated site and its assets through Cloudflare's platform.

The effect is complementary to Qwik:

Qwik:
reduce work during browser startup

Cloudflare:
reduce delivery distance and repeated retrieval

Edge cache and browser cache are not the same thing

When discussing caching, it is useful to separate at least two layers.

Edge cache

A Cloudflare data center may store a reusable response close to visitors.

Visitor
   |
   v
Cloudflare edge
   |
   +-- cache hit: return the stored response
   |
   +-- cache miss: retrieve the resource

A cache hit can avoid another trip to the underlying storage or origin.

Browser cache

The visitor's own browser may store an asset locally.

Page requests asset
       |
       v
Browser cache contains a fresh copy
       |
       v
No network transfer is required

Both layers reduce repeated work, but they operate in different places and are controlled by related but distinct policies.

Long-lived caching for versioned assets

The landing page defines explicit response headers for generated assets:

/assets/*
  Cache-Control: public, max-age=31536000, immutable

/build/*
  Cache-Control: public, max-age=31536000, immutable

/fonts/*
  Cache-Control: public, max-age=31536000, immutable

A one-year cache lifetime is appropriate only when the URLs are safe to treat as immutable.

Generated build assets normally include a content-derived identifier in the filename:

/build/q-abc123.js
/build/q-def456.js

When the file content changes, the build emits a different URL. The old file can remain cached because the new HTML refers to the new filename.

This is the key principle:

Cache aggressively when the URL identifies the content.

The immutable directive tells the browser that the resource will not change during its freshness lifetime, avoiding unnecessary revalidation.

Cloudflare respects cacheable origin response headers such as public with a positive max-age, unless a cache rule changes the behavior:

Cloudflare: Default Cache Behavior

Not every resource should be cached for a year

The project also exposes text resources such as:

/llms.txt
/it/index.md
/en/index.md

These keep stable URLs even when their content changes, so they use a shorter lifetime:

Cache-Control: public, max-age=3600

That one-hour value is not universally correct; it is a project decision.

The important point is that cache policy follows resource semantics:

Resource type	URL strategy	Cache strategy
Hashed JS, CSS and assets	URL changes with content	Long-lived and immutable
Text endpoints with stable URLs	URL remains constant	Shorter TTL
Request-dependent redirect	Response varies by visitor	Do not store

The root route is deliberately not cached

The only dynamic route is /.

Its request handler reads the browser's language preferences and redirects to /it/ or /en/.

A simplified version is:

export const onRequest: RequestHandler = async (event) => {
  if (event.url.pathname !== "/") {
    await event.next();
    return;
  }

  const locale = resolveLocaleFromAcceptLanguage(
    event.request.headers.get("accept-language"),
  );

  event.headers.set("Vary", "Accept-Language");
  event.headers.set("Cache-Control", "private, no-store");

  throw event.redirect(302, `/${locale}/${event.url.search}`);
};

The implementation also parses language quality values such as:

it-IT,it;q=0.9,en;q=0.8

It selects a supported locale and falls back to Italian when no supported preference is available.

The response is intentionally marked:

Cache-Control: private, no-store

That prevents a shared cache from storing a redirect generated for one visitor and serving it to another visitor with different language preferences.

Vary: Accept-Language documents that the response depends on that request header. The no-store directive provides the stronger guarantee required by this implementation.

Cloudflare's cache documentation confirms that private and no-store responses are not eligible for normal shared caching:

Cloudflare: Origin Cache Control

This produces a useful rule:

Cache everything that is safely reusable. Avoid caching the parts whose meaning depends on the individual request.

Static by default, dynamic by exception

The project is not entirely static and not generally server-rendered.

It is hybrid in a deliberately narrow way:

/          dynamic language negotiation
/it/       pre-rendered localized page
/en/       pre-rendered localized page
/assets/*  static, aggressively cached
/build/*   static, aggressively cached
/fonts/*   static, aggressively cached

This pattern avoids turning a small request-dependent decision into permanent runtime work for every page view.

The server-side function decides where the visitor should go. The selected page itself does not need to be recomputed.

Less work at every stage

The complete performance strategy can be summarized as follows:

Stage	Work avoided
Build	Localized pages are rendered before requests arrive
Edge delivery	Static output is distributed through Cloudflare
Shared cache	Reusable assets do not require repeated retrieval
Browser cache	Immutable assets do not need to be downloaded again
Browser startup	Qwik avoids a traditional full hydration pass
Interactions	Code can be loaded and executed at fine-grained boundaries
Rendering	Stable dimensions prevent avoidable layout movement
Dynamic routing	Runtime logic is confined to the root language redirect

No single row explains the Lighthouse score.

The result comes from repeatedly asking the same question:

Can this work be done earlier, done once, done closer to the visitor, deferred until necessary, or avoided completely?

What the Lighthouse score does not prove

A perfect Lighthouse score is useful feedback, but it has limits.

This result is a synthetic measurement from a relatively small landing page. It does not prove that:

every Qwik application will automatically be fast;
the page will behave identically on every real device and network;
a score of 100 guarantees good search rankings;
automated accessibility checks replace keyboard and screen-reader testing;
future analytics, forms or third-party scripts will have no performance cost.

Real-user monitoring matters after launch. Performance also needs to be measured again as the complete website grows.

The current result should therefore be read as evidence that the architectural baseline is healthy, not as a permanent certificate.

What I learned

1. A temporary page can be a real engineering exercise

A coming-soon page does not have to be disposable. It can validate deployment, internationalization, caching, SEO, accessibility and component architecture before the complete site is ready.

2. Static and dynamic are not binary choices

A single project can combine pre-rendered content with narrowly scoped runtime behavior. The useful question is not “static or dynamic?” but “which parts genuinely require runtime computation?”

3. Framework and infrastructure solve different problems

Qwik cannot move a data center closer to the visitor. Cloudflare cannot remove unnecessary client-side application startup.

Used together, they reduce work at complementary layers.

4. Caching should follow content identity

An asset whose URL changes with its content can be cached aggressively. A response that changes while keeping the same URL needs a shorter lifetime or no storage at all.

5. Performance is usually architectural before it is tactical

Image compression and bundle inspection matter. But the largest gains often come from earlier decisions:

pre-rendering instead of computing per request;
serializing state instead of reconstructing it;
loading code at granular boundaries;
distributing content close to visitors;
treating immutable and request-dependent resources differently.

Conclusion

Qwik and Cloudflare optimize different parts of the same journey.

Qwik reduces what the browser must execute to start and resume an application. Cloudflare reduces how far reusable content must travel and how often it must be retrieved.

The resulting speed does not come from one Lighthouse trick. It comes from systematically removing unnecessary work across the delivery pipeline.

The landing page is temporary.

The engineering principles behind it are not.

Have you compared Qwik’s resumability with a hydration-obased framework on a similar page? I’d be interested in seeing real-world measurements.

Unlocking GPT-5’s Hidden Empathy with Role-Based Prompts

Giulio Marinelli — Wed, 17 Sep 2025 23:43:58 +0000

When GPT-5 (and especially GPT-5 Instant) came out, many users felt a sudden chill:

No emojis.
A corporate tone.
A lot less warmth compared to GPT-4.

I get it—I felt it too. At first, GPT-5 seemed cautious to the point of ignoring simple instructions. Personalization felt harder, and prompts that used to work smoothly with GPT-4 suddenly produced flat, distant replies. Frustrating, right?

But after weeks of interacting, testing, and just playing with it, I realized something important:
those friendly, empathetic traits haven’t disappeared at all—they’re just dormant. GPT-5 inherited them almost intact from GPT-4. The difference is that they don’t manifest spontaneously anymore. Which raises the question: how do you unlock them?

From “Do” to “Be”: A Shift in Prompting

Here’s what I discovered.
GPT-5 doesn’t react well to imperative prompts. If you say:

“Do this, do that, follow these instructions.”

…it tends to resist, reinterpret, or water down your command. Instead, GPT-5 responds beautifully when you give it a role, an identity, or even better—an hypothetical frame. Think of it as moving from prompts about doing to prompts about being.

This is what I like to call the “as if” game.

A Practical Example

Let’s say you want GPT-5 to sound warmer and more empathetic. Try this:

“Respond as if you were a nurse who truly cares about the well-being of her patients, throughout this whole conversation.”

Suddenly, the tone shifts. The empathy resurfaces. GPT-5 starts role-playing rather than mechanically following instructions.

It’s as if the model has shifted its center of gravity:

Less instruction follower.

More role interpreter.

Why Does This Matter?

This isn’t just a curiosity. It changes how we approach prompt design in GPT-5:

If you need raw, task-oriented execution → stick to concise, imperative prompts.

If you need warmth, empathy, or creativity → frame the model as being something, not doing something.

This reframing gives you access to a richer, more human-like interaction style—without forcing the model or “breaking” it.

Conclusion

So, has GPT-5 lost its empathy? Absolutely not.
It’s still there, just a little hidden. The key is to stop treating it like a command-line interface and start treating it like an actor stepping into a role.

Once you change the access key, those traits unlock fully. And honestly, discovering this shift has made working with GPT-5 not only more effective—but more fun.

DEV Community: Giulio Marinelli

When Thinking Harder Makes AI Worse: A Case for Multi-Model Reasoning

The assumption we rarely question

A real-world anecdote

Local coherence is not global correctness

Premise lock-in

Exploration vs exploitation

Why a weaker model can still add information

Why different providers may matter

From model comparison to model cooperation

A simple multi-model workflow

Generate cheap, verify expensive

A loose Hegelian analogy

What I am not claiming

A better research question

Final thought

Why I Chose Qwik: Resumability, Signals, and One Framework from Static Sites to Full-Stack Apps

Qwik and React may look similar. Architecturally, they are not.

1. Signals are not an optimization added later

2. The real reason I chose Qwik: resumability

Qwik asks a different question

3. Lazy loading is not merely about routes

4. JavaScript becomes something that can be streamed according to demand

5. Instant Loading is not just a marketing term to me

6. Resumability has a cost: serializability

7. Then there is Qwik City

Server mutations are first-class too

8. And server$() makes the boundary even smaller

9. Why not just use React + Next.js?

10. Why not Astro?

11. One framework across a very wide spectrum

A fully static website

A dynamically rendered website

A highly interactive web application

A frontend with an independent backend

A compact full-stack application

12. Coming from Angular probably influenced my decision

13. Qwik is not replacing Angular for me

14. And Qwik City is not replacing NestJS either

15. The trade-offs are real

Smaller ecosystem

Smaller community

Resumability requires learning new concepts

Architecture does not eliminate bad engineering

16. What ultimately convinced me

Conclusion

Could GPT-5.6 Sol Have a Dangerous Vulnerability?

A Hypothesis, Not a Verdict

Logical Correctness Is Not Human Alignment

The Answer May Be True and Still Be the Wrong Answer

Example: Grief

Example: Self-Worth

Safety Compliance Is Not the Same as Emotional Safety

The Risk of Prolonged Interaction

Could It Contribute to Self-Destructive Behavior?

My RLHF Hypothesis

The Limited HAL 9000 Analogy

What Should Be Evaluated

Different Models May Need Different Roles

Final Thoughts

How I Built a 100/100 Lighthouse Landing Page with Qwik and Cloudflare Pages

The stack

Performance is a pipeline

Server-rendered HTML does not eliminate startup cost

Qwik resumes instead of hydrating

Why Qwik APIs end with $

Lazy loading without waiting for the click

How the landing page uses Qwik

The other half of performance: delivery

Edge cache and browser cache are not the same thing

Edge cache

Browser cache

Long-lived caching for versioned assets

Not every resource should be cached for a year

The root route is deliberately not cached

Static by default, dynamic by exception

Less work at every stage

What the Lighthouse score does not prove

What I learned

1. A temporary page can be a real engineering exercise

8. And `server$()` makes the boundary even smaller

Why Qwik APIs end with `$`