DEV Community: Giulio Marinelli

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.