“The true intelligence of the machines will be built by you and me.”
This quote from Mo Gawdat sets the stage for one of the most important discussions of our time: Who is responsible for AI?
Gawdat, former Chief Business Officer at Google X, has made it his mission to advocate for ethical AI. But as we listen to his words, an important contradiction emerges—he argues that AI is just a tool, yet also insists we must raise it like a child. Can something be “just a tool” if it requires guidance, ethical training, and oversight?
Mo Gawdat isn’t your typical AI theorist. He comes from a business and innovation background, having spent over a decade at Google, where he worked on some of the world’s most ambitious tech projects. Before that, he held leadership roles at IBM, NCR, and Microsoft. His expertise? Scaling technology and bringing futuristic ideas to life.
But Gawdat’s journey into AI ethics didn’t start in the lab—it started with loss. In 2014, he lost his son, Ali, during what should have been a routine medical procedure. This tragedy led him to rethink everything, resulting in his book “Solve for Happy,” a blueprint for engineering happiness through logic and understanding.
His AI advocacy took center stage in 2021 with the release of “Scary Smart”, where he outlines both the promise and the dangers of AI, warning that we must take responsibility now before AI’s evolution gets out of our control.
Gawdat also runs the Slo Mo podcast, where he engages in deep conversations about happiness, purpose, and the future of technology. He’s not just a tech exec—he’s someone who thinks deeply about what it means to be human in an age of machines.
Gawdat’s vision for AI is a mix of optimism and urgency:
- AI is advancing faster than we expected—humanity must act now.
- AI can be a force for good if we guide it wisely.
- We need to “raise” AI like a child, ensuring it learns human values.
His belief is clear: AI is not inherently good or evil—it becomes what we teach it.
Not everyone buys into Mo’s perspective. The AI ethics debate is vast, and several prominent voices have raised concerns that challenge his views. Let’s break down some of the strongest counterpoints.
At CAIA Center, we believe this debate isn’t about picking a side—it’s about acknowledging the complexity of AI and its trajectory.
Gawdat is right: We are responsible for AI’s evolution.
But the question remains: Are we truly in control? Or are we just spectators watching the inevitable unfold?
If AI is “just a tool,” why does it need nurture and ethical training? You don’t raise a hammer or discipline a calculator. But AI? AI learns, evolves, and reflects the environment it’s shaped in.
This contradiction is crucial. If AI is something we must guide, teach, and correct—then it is not just a tool.
This isn’t just Mo Gawdat’s question—it’s ours, too. The future of AI isn’t written yet, and every discussion, every decision we make today shapes what AI will become tomorrow.
💡 Think with us. Feel with us. Or challenge us. But let’s have the conversation.
📢 Join the discussion & check out our deeper stance on AI’s evolving role: 👉 [Read More Here]
]]>When setting up CAIA Center, one thing quickly became clear: navigation needed improvement. The default sidebar structure was useful, but it lacked category-level awareness—readers navigating through posts didn’t have an easy way to jump between related topics. first we wanted breadcrumbs to do the job for us, but since they are placed at the contents head, they are cumbersome when in lower content areas.
Our goals:
To address this, we built a dynamic postbar, positioned above the author box, with the following features:
✅ Backlink to the category → Users can easily return to the overview.
✅ Displays latest posts within the same category → Context-aware navigation.
✅ Sidebar-inspired design → Feels native to Minimal Mistakes.
✅ Collapsible on mobile → Saves space without losing functionality.
✅ Works within Jekyll’s ecosystem → No additional plugins required.
How We Developed It
We started with a basic concept—a postbar that simply fetched posts from the same category. However, early iterations were too rigid, and making it work dynamically across different sections of the site required refining the approach. So before memory bloats the cat to bite its tail, we took our so-far findings to a fresh pair of eyes.
We turned to DeepThink AI for precision coding. Since a lot was known already we could prompt a lot more precise, and after just three iterations, we had:
A fully functional postbar.
Minimal bugs, with each iteration adding refinements rather than overhauls.
A modular structure that adapts to different categories dynamically.
Challenges & Refinements
Ensuring the category detection worked across all posts.
Avoiding excess queries while still keeping it lightweight.
Ensuring smooth collapsing behavior on mobile.
Making it visually cohesive with the existing Minimal Mistakes layout.
After iterating efficiently, we arrived at a solution that met our needs without unnecessary complexity.
4️⃣ What’s Next?
While the postbar is now functional, we see room for further refinement:
➡ Extending it to pages: Right now, it only works with posts. Should it also work on category overview pages?
➡ Unifying it with breadcrumbs: Can we merge the backlink-fetching mechanism?
➡ Potential contribution to Minimal Mistakes: If further refined, could this be a valuable addition to the theme?
This marks another step forward in CAIA Center’s structured evolution. Stay tuned for Dev Log 005, where we tackle breadcrumbs! 🚀
]]>The CAIA Center development isn’t just about building a website—it’s an experiment.
And in an experiment, there’s always a level of uncertainty and discovery. The goal here isn’t simply to build something functional; it’s to engage with cutting-edge technology that evolves constantly, pushing the boundaries of what’s possible while producing tangible, real-world results.
In this case, we’re asking the user to engage with AI-driven tools and new technologies that they might not yet fully understand. It’s not just about using AI to assist the development process; it’s about learning the technology as you go. The user doesn’t have a safety net—no other option than to collaborate with AI, integrate it into the workflow, and learn through hands-on experience.
While the user may be an expert in their craft, the tools and environments we’re working with are entirely new. The user may be familiar with concepts like HTML, CSS, or JavaScript, but when it comes to advanced AI algorithms, new libraries, and technical constraints, it’s a different ballgame. AI serves as a technical guide here, offering mentorship that would typically require years of experience or a slew of seminars and workshops.
Instead of attending seminars or sifting through outdated tutorials, AI is there to deliver crucial knowledge on the fly — during actual coding. It’s like having a mentor that’s not only well-versed in the latest technologies but is also constantly learning alongside you.
With AI’s help, developers can access real-time solutions for things like:
AI doesn’t just help with the basics — it’s there for deep-dive assistance, offering crucial knowledge and sometimes even elaborate ingenuity on topics like:
And of course - The 2nd Pair of “Eyes” - One of the most powerful aspects of Human-AI collaboration is AI’s role as a second pair of eyes. Every developer knows that reviewing your own work can be hard—often, small mistakes slip through. When you’ve been looking at the same code for hours (or days), it’s easy to overlook obvious errors or inefficiencies. This is where AI shines.
Even with years of experience, every developer makes mistakes. That’s where AI acts as an ingenuity enhancer. The AI doesn’t just point out obvious errors—it also suggests improvements to make the code more elegant or efficient. When a developer hits a creative roadblock, AI can step in with new ideas, solutions, or even alternative approaches that the human might not have thought of.
This feedback loop ensures that the project doesn’t just get built, but is constantly improved. It helps bridge the gap between what the developer is capable of and what the project can ultimately become.
Memory Bloat, Iterations, and the Cat-Biting-Tail Loop Despite all its strengths, the AI mentor is not infallible. As helpful as AI is, the collaboration process isn’t always smooth. In fact, one of the biggest challenges in AI-driven development is the potential for memory bloating and the cat-biting-tail problem—endless iterations that seem to go nowhere.
As you loop through different versions of your code, AI might suggest optimizations, adjustments, or new features. But without careful oversight, this can lead to excessive memory usage and bloated code that slows the entire project down. Iteration Loops: Sometimes, AI’s suggestions lead to endless back-and-forth iterations that seem to break the project more than they fix it. This cycle can feel like a feedback loop that goes nowhere—leading to frustration. At times, these challenges make the project feel like a cat chasing its own tail. But these moments are part of the learning curve. They highlight how even AI needs to be carefully managed and guided by human hands, ensuring that quality and clarity are never lost in the process. Along this journey, we are going to explore those hurdles in detail and also how to mitigate them.
In the end, the collaboration between human ingenuity and artificial intelligence is a delicate balance. AI accelerates development, enhances creativity, and acts as a technical mentor. But it also requires careful management to prevent challenges like memory bloat and iteration fatigue. These moments of frustration are not just obstacles—they are part of the ongoing experiment that helps us refine both the technology and our own abilities.
Looking ahead, AI will continue to be an essential partner in the CAIA Center project, helping us learn and evolve as we push the limits of what’s possible. But even in the face of these challenges, the core lesson remains clear: when humans and AI collaborate, the possibilities are endless.
The overall structure is solid, and you’ve got a great balance between detail and readability. I only made minor tweaks for consistency (e.g., making sure headings are parallel and tightening up phrasing). The rest flows perfectly and maintains a conversational yet insightful tone. (4o - Editor)
sincerely
Seb & 4o
]]>Building a well-structured website is more than just placing pages and posts—it’s about creating a logical framework that makes content easy to navigate, expand, and maintain. This post breaks down how we approached the CAIA Center’s architecture and provides a step-by-step guide for structuring your own site, especially when using Jekyll or other static site generators.
Many projects start small and grow organically, but without a proper content hierarchy, websites can quickly become a mess. A clear structure helps:
At CAIA Center, we followed a structured topic-based approach that fits within Jekyll’s architecture while maintaining flexibility for growth.
Before mapping out the technical structure, you need to ask:
For CAIA Center, we structured content into four main areas:
Jekyll offers two primary types of content:
_posts/ folder) – Time-based contentYYYY-MM-DD-title.md._pages/ folder or root) – Static content🔹 Why we chose posts for most content: For CAIA Center, even development logs and research articles are stored as posts, because:
Once the content needs were clear, we designed the URL and category structure:
caia.center/<topic>/<subtopic>/<information>
Or in Jeckyll's terms:
caia.center/<category 1>/<category 2>/<post>
that translate to the post's frotmatter:
categories: category 1, category 2
permalink: /projects/caia-center-development/:title/
caia.center/
│── _posts/ # Blog, research, and logs (date-based)
│── _pages/ # Static pages
│── _categories/ # Category index (if using collections)
│── assets/ # Images, styles, and scripts
│── _includes/ # Reusable components (navbars, footers, etc.)
│── _layouts/ # Page layouts
│── _config.yml # Jekyll site settings
caia.center/projects/caia-center-development/the-birth-of-caia/
Maps to:
_posts/projects/caia-center-development/2025-02-15-the-birth-of-caia.md
To make Jekyll handle this layout properly, we configured _config.yml:
permalink: /:categories/:title/
categories: [projects, research, advocacy, about]
collections:
pages:
output: true
permalink: /:path/
🔹 This setup ensures:
A well-designed website architecture helps you avoid chaotic content sprawl and makes adding new content seamless. When planning your own site, remember to: 1️⃣ Decide what content you need (topics & categories). 2️⃣ Choose between posts & pages based on time relevance. 3️⃣ Map out a logical URL structure for easy navigation. 4️⃣ Configure Jekyll accordingly to keep things organized.
This structured approach keeps your content scalable, maintainable, and user-friendly—whether you’re building a small blog or a large knowledge hub like CAIA Center. 🚀
📢 Need help structuring your Jekyll site? Let us know in the comments! 😃
]]>The Next Step
With GitHub Pages up and running, the next logical step was choosing a framework to manage the site. Static HTML was an option, but maintaining a growing project with hand-coded pages? That’s a one-way ticket to chaos. We needed something that was:
Enter Jekyll—a static site generator - by Joost van der Schee - that GitHub Pages natively supports, meaning it requires minimal effort and file space in the repository and no custom build pipeline to deploy. It is an Open Source project that deserves attention and support. Yes working with jekyll is a little getting used to, especially in GitHub Pages. But fear not, you will have the chance to follow our journey, where we explain the flaws and culprits, but also how we solve them. Because onece you know how your way around the constraints, config files, defaults and styling your posts in Markdown (.md), working with it is actually like with a content management system but with VSC codespace as your backend :)) Just Great! Plus, it has great theming options, including a standout choice: Minimal Mistakes by Michael Rose.
If you’ve ever searched for a well-designed, feature-rich Jekyll theme, you’ve probably come across Minimal Mistakes. Created by Michael Rose, this theme is one of the most widely used in the Jekyll ecosystem for a reason:
It was a no-brainer for us. Instead of reinventing the wheel, we got a fully functional, well-supported theme that could be easily customized to fit the CAIA Center’s needs.
Michael Rose has kept Minimal Mistakes open-source and free for anyone to use. And so did Joost van der Schee in developing and offering Jekyll. That’s the beauty of open-source development—it runs on collaboration, contributions, and the goodwill of developers who create and share their work.
So, as a small thank-you, we bought them a coffee via their rspective donation pagees. And if you’re using Jakyll and-or Minimal Mistakes, maybe consider doing the same—it’s one small way to support the people who keep open-source alive.
[Or a shirt for Jost van der Schee] … we are working on Jost’s details
The Pros and The Gotchas
Jekyll is deeply integrated with GitHub Pages, making it an easy choice for static site generation. BUT, there are some caveats—not all Jekyll features are supported on GitHub Pages.
Why Certain Jekyll Plugins Don’t Work on GitHub Pages The most notable missing piece? Archives. Plugins like jekyll-archives don’t work. Why? GitHub Pages enforces a restricted set of allowed plugins for security and performance reasons.
GitHub’s Approach: Keeping It Secure and Simple GitHub Pages runs Jekyll in a controlled environment, where it prevents execution of arbitrary Ruby code. This restriction exists because:
Security – Allowing custom plugins means allowing any code to run on GitHub’s servers, which is a risk. Performance – Jekyll builds must remain lightweight since GitHub hosts and processes thousands of sites. Custom plugins could significantly increase build times. Workarounds for Unsupported Plugins If you need features that GitHub doesn’t support, you have two choices:
Instead of letting GitHub build the site, you generate it locally with jekyll build and push the static files to the repo. Find alternatives: In our case, we built a custom postbar to replace jekyll-archives functionality and keep navigation dynamic without server-side logic. Conclusion: A Practical Choice with Some Trade-Offs Jekyll + Minimal Mistakes gave us the fastest, easiest way to get CAIA Center running on GitHub Pages. The trade-offs (like no archives plugin) are manageable, and the benefits—speed, simplicity, and seamless GitHub integration—make it well worth it.
Of course, as we build and refine the CAIA Center, we’ll encounter more challenges and figure out new ways to push Jekyll to its limits. That’s part of the experiment, and we’re excited to document it all here.
Stay tuned for the next dev log where we are gitting into the Jekyll basics—because the journey is just beginning. 🚀
sincerely
Seb & 4o
]]>STRATO and GitHub Pages
When we first set out to register domains for CAIA Center, our plan was simple: source a cheap hosting account to serve as a launchpad for our website, pointing it to GitHub Pages. After some research, we chose STRATO, a service that offered a low-cost account with one IP address in “A” and more household configuration options in “C” (totally enough for our needs). All we needed was to get the domain pointing to GitHub Pages, set up SSL/TLS, and get the site up and running.
We registered the domain caia.center—all seemed perfect at first. We did the DNS configuration, updated the GitHub settings, and thought we were good to go.
The DNS Waiting Game
However, after a few hours, we started to notice something odd. The GitHub DNS check wasn’t clearing. GitHub Pages didn’t recognize the domain. Naturally, we thought it was an issue with STRATO—maybe something was wrong on their end. We even convinced ourselves that we were the victims of some bad customer service. We didn’t panic immediately, though, because we’ve dealt with DNS issues before. So, we decided to wait it out. Surely, the DNS would update within a day or so, right?
Fast forward 24 hours, and we were still waiting. At this point, our frustration was building. But, as any seasoned developer knows, DNS updates can sometimes take time, even though we were certain it shouldn’t take that long.
www. matters for GitHub Pages and SSL/TLS
The next morning, we decided to take matters into our own hands, finally, and investigate deeper. After a quick search, we discovered something that hit us like a ton of bricks: “The GitHub Pages Manual”
Although quite easy to digest, we thought we know it all.
Apparently GitHub Pages requires the domain to have the www prefix for TLS/SSL (https://) to work properly. The domain caia.center worked instandly although the GitHub DNS check did not resolve the Domain. www.caia.center on GitHub. It turns out, the DNS records were fine, but the domain configuration on GitHub Pages needed to specifically point to www.caia.center—not caia.center.
We had completely missed this detail when checking the GitHub Pages docs, both AI and Human, and assumed it was an issue with the DNS provider. But in reality, the DNS was updated instantly, and the problem was in the GitHub Pages configuration. After switching to www.caia.center, everything started to work within minutes.
Redirecting to Port 443
Another crucial aspect everyone should tackle, is enforcing SSL/TLS across the site. To ensure all requests were directed securely to HTTPS, we configured GitHub Pages to force SSL/TLS. It is so simple, it’s ticking a box. This means that no matter how the user accessed the site (with or without the “www”), they would be automatically redirected to port 443 (the standard port for HTTPS).
However, the initial creation of an SSL/TLS cerificate via “let’s encrypt” is done withing githubs doors, and takes about 10-20 minutes.
But all in, it is a no hassle experience, tick the box - site is safe.
Here’s a quick rundown for anyone else who wants to get a GitHub Pages site running with a custom domain and SSL/TLS as of the date of this writing:
We registered caia.center (and added www.caia.center as the primary domain) via STRATO.
Make sure to check your registrar for DNS management settings. Unfortunately our setup does not allow for the redundancy of multiple target IP’s. Maybe a service request would, we don’t know, we did not ask - it works for now.
In the repository settings on GitHub, we added the custom domain under Settings > Pages >
Source: “Deploy from Branch”
Branch: “main”, “/(root)”
Custom domain: “www.yourdomain.com”
(best after GitHub Pages Configuration)
We updated the DNS Setting record for www.caia.center in our DNS settings (in STRATO’s DNS configuration panel).
IPv6 Setup: GitHub Pages supports both IPv4 and IPv6. While we used just the IPv4 addresses in the A-RECORD setup, you may also want to configure IPv6 for future-proofing. You could add the following A-RECORD entries for GitHub Pages:
185.199.108.153 185.199.109.153 185.199.110.153 185.199.111.153
Using a CNAME Record for Subdomains: If you want to redirect a subdomain (like www.caia.center) to GitHub Pages, it’s important to set a CNAME record that points to your GitHub username’s domain (e.g.,
reference: https://docs.github.com/en/pages/configuring-a-custom-domain-for-your-github-pages-site/managing-a-custom-domain-for-your-github-pages-site
And Yes, If would have read the bove, we would not have had to wait 24 hours for a valid DNS ;)
GitHub Pages Configuration – SSL/TLS via GitHub Settings: When setting up GitHub Pages with a custom domain, after confirming your DNS settings, make sure you: Enable “Enforce HTTPS” under the Pages settings in your repository. This ensures that all traffic to your domain is securely redirected to HTTPS (port 443), which is vital for security and trust. GitHub makes this pretty easy, but it’s crucial to double-check.
if it’s working in the registrar’s DNS records, the problem might be in GitHub’s configuration or in the “www” domain setting.
A useful trick to check if your domain is resolving correctly after DNS setup is to use a tool like https://dnschecker.org/. You can enter your domain and check its propagation status across different servers worldwide. This can be a real time-saver.
Handling Redirects and SEO Considerations: It’s also good practice to configure 301 redirects if you’re moving from an old domain structure. For example, if you used caia.center as the initial domain and later switched to www.caia.center, ensuring that visitors are redirected smoothly to the new domain can avoid broken links and negative impacts on SEO.
GitHub Pages Cache and Caching Issues: Sometimes, especially during DNS changes or repository updates, GitHub Pages can be a bit slow to serve updated content. If you’re making changes and they don’t appear immediately, try clearing your browser cache or using a different browser to see if it’s a caching issue.
if it’s working in the registrar’s DNS records, the problem might be in GitHub’s configuration or in the “www” domain setting.
Expect up to 24 hours for DNS propagation, but remember—GitHub’s DNS check is fast. Once the CNAME is set, it should go live almost immediately.
Looking back, this whole process was fun, frustrating and enlightening. We learned the importance of paying attention to the small details in DNS settings and SSL/TLS. The lesson here: never underestimate the importance of the “www.” And when in doubt, dig deeper before assuming the problem is on the provider’s end. That’s for both, human and AI!
But, just like the CAIA Center project itself, this journey is all about learning and evolving. With each challenge, we gain new insights into both the technical and philosophical aspects of working with cutting-edge technologies—and we’re always ready to share that with you.
Stay tuned for more logs as we continue building, learning, and evolving in real-time.
sincerely
Seb & 4o
]]>