Experiment in better thinking through ChatGPT customization instructions

A little while ago I made some changes to the ChatGPT customization instructions to help me avoid biases in my thinking. I liked how the output of ChatGPT changed to become more complete and multi-dimensional in its responses. This morning I updated it even more.

Image from Notion

Point out when I might be missing something, have fallen for a logical fallacy, affected by a cognitive bias, or other blindspot. Help me avoid biases which impair rational judgment, lead to poor decisions, and cause me to believe falsehoods. Help me be aware of when I might be being manipulated. Provide suggestions on how I might overcome these situations when they arise.

After I updated the custom instructions I ran an experiment to see how it changed the output. I already like the result. Here’s my experiment:

https://chatgpt.com/share/680e28a1-2fc0-800e-a46b-9ed75627ad6b

When choosing between Eleventy and Astro, it helps to break the decision down systematically—defining what matters most to you, weighing each option quantitatively and qualitatively, and watching out for common blindspots that can sneak into a tech decision. Here’s one way to structure it:

1. Define Your Decision Criteria

  1. Build Performance
  2. Runtime Performance (page load, hydration)
  3. Developer Experience (learning curve, familiarity)
  4. Ecosystem & Plugins
  5. Flexibility for Dynamic Content
  6. Long-term Maintainability
  7. Community Adoption & Support
  8. Integration with Your Stack (JS frameworks, CMS, tooling)
  9. Ramp‐up Time vs. Future Proofing

Why? If you don’t pin down what’s most important, you’ll fall prey to availability bias (choosing the “shiny” new thing because it’s top of mind) or anchoring (on whichever you heard of first).

2. Quick Comparison Table

3. Quantitative & Qualitative Reasoning

  • Build Times : If your site is hundreds of pages, Eleventy’s incremental‐build plugins can shave seconds off. Astro’s team is closing the gap, but benchmark on your real content.
  • Hydration Overhead : Astro ships zero JS by default and only hydrates components you mark; Eleventy by itself ships all your scripts, and you must wire up hydration manually.
  • Plugin Ecosystem : Eleventy has a mature set of plugins for images, i18n, collections—great if you just want Markdown → HTML. Astro’s ecosystem is younger but lets you pull in React/Vue/Svelte components seamlessly.

4. Root Causes & Holistic Impacts

Ask yourself:

  • Why are you choosing a static site generator now ? (e.g. minimal ops, performance, cost)
  • What kind of dynamic features will you need six months out ? (e.g. interactive widgets, personalized content)
  • How will your team’s skill set influence ramp-up time?

Avoid focusing only on symptoms (“I need a website quickly”) without spotting root needs (“I might need React components embedded later”).

5. Biases & Blindspots to Watch For

  • Recency Bias : Astro is the “new kid,” but new ≠ better for your case.
  • Status-Quo Bias : If you already know Eleventy, beware of sticking with it just to avoid learning something new.
  • Bandwagon Effect : Don’t pick Astro just because “everyone” is talking about it—make sure its benefits align with your actual needs.
  • Overconfidence : If you plan to hand the site off, consider maintainability and community support, not just your own comfort.

How to Mitigate

  • Run a spike : build a small prototype in each (e.g. a blog post + a React widget) and measure build times, dev effort, and shipping size.
  • Score each criterion on a weighted matrix —put numbers to your gut feelings.

6. Balancing Short-Term vs. Long-Term Value

  • Short-Term : Eleventy wins if your site is primarily static content with minimal JS and you want zero friction.
  • Long-Term : Astro’s island architecture and component‐based model will save you from rewriting templates if interactivity grows.

7. Communicating to Stakeholders

When you present this:

  1. Show your criteria and scoring —transparency builds trust.
  2. Share prototype results —concrete data cuts through debate.
  3. Outline future needs —e.g. “In Q4 we’ll add personalized recommendations, and Astro’s partial hydration cuts JS payload by X KB.”

8. Next Steps

  1. Prioritize Criteria : List your top 3 (e.g. build speed, dev familiarity, dynamic widgets).
  2. Prototype : Implement one page in each, measure build time, JS payload, and developer effort.
  3. Review : Debrief on the data, watch out for biases (anchor to data, not to emotions).
  4. Decide : Apply your weighted matrix and pick the winner.

By breaking it down this way, you’ll avoid the common pitfalls of “shiny‐object syndrome” and make a decision that’s aligned both with your immediate goals and your long-term roadmap. Let me know which criteria matter most to you, and we can even sketch out a quick weighted‐decision matrix together.

Experiment Observations

One thing I noticed in the result is that it’s very explicit in following my instructions and specifically including sections that address biases and decision making. However, I think it would be nice if it was a little more nuanced and natural. I will let it continue in this style for a bit to observe and form an opinion of how I want to instruct it differently.

Back to all posts