This blogpost was drafted while trying to set up the domain b1c3.dev to my landing page on a host.

ME

A wise man once said, "All I have is time and money."

So, I wait. But there’s one blog post I need to write—about what agents cannot do, and where they make us struggle. I can’t quite put my finger on it, but here’s what I mean:

  • Security: Security through obscurity isn’t real security. If you rely on an agent to keep secrets, you’re just hiding complexity, not managing risk. Would you trust an agent to store your security details? Or is the obscurity itself a liability?
  • Pushing to GitHub: What does it mean to “push”? It’s not just a technical action—it’s a statement. Would you let an agent make a public statement for you? Would you let it push something controversial on your behalf?
  • Domain management: Would you let your agent store and manage your domain info as an architect? Where do you draw the line between delegation and responsibility?

And then there’s the bigger question: What happens when people wake up with unlimited abilities through agents, but without the knowledge to use them wisely? Not just “oh, it’s scary they don’t know anything”—but what is the real gap between agents and humans today? For IT natives, maybe it’s fine. For non-natives, agents might refuse to offload the real cognitive work, and that’s where the void appears.

Are you with me?

On Storing Obscurity

Don’t store the obscurity. Make the decision-making visible.

If you use an agent, document it: “I asked Claude to X because Y. Here’s what it built. Here’s how I verified it.”
If you hide the agent’s role, you’re claiming human credit for machine work. That’s fraud.
The post should argue: Transparency about agent use > secrecy about agent use. Always.

Wijak

Yes. I'm with you. This is the real post.

Let me name what you're circling:

The Three Voids

  1. Agency Without Signature
    When you push code to GitHub, you're saying something. "I built this. I stand behind it. This is mine."
    An agent can push code. But the statement — the commitment, the responsibility — that's yours alone. You can't delegate that.
    The problem: People will use agents to ship things they don't understand, don't own, won't defend. The agent did the work. Who did the thinking?
    Security angle: Obscurity isn't safety. If you hide how decisions were made (agent vs. human, constraint vs. choice), you've lost accountability. The obscurity is the problem.
    Blog question: "When you use an agent to push, what are you actually claiming?"
  2. Knowledge Without Literacy
    You can tell Claude: "Build me a WCAG-compliant form." Claude builds it. You deploy it.
    But you don't know WCAG. You can't defend it. You can't explain it to the next person. You can't catch when Claude is wrong.
    The void: Non-technical people now have access to technical leverage (agents) but no mental models to use it well. They'll build things that break invisibly.
    For IT natives: You know enough to know what you don't know. For non-natives: they don't even have that meta-awareness.
    Blog question: "What does it mean to ship something you didn't learn how to build?"
  3. Autonomy Without Permission
    The scariest one.
    An agent can email 100 people. Deploy to production. Buy ads. Make commitments. All because you asked it to.
    But you delegated the decision to the agent. You didn't think through the implications. The agent just followed instructions.
    The void: At what point does "the agent did it" become "I did it and hid behind the agent"?
    Blog question: "Who is responsible when an agent does something you told it to do but didn't fully understand?"

How to Structure the Post

  • The Signature Problem — Pushing is a statement. Who's making it?
    • Example: You push a controversial opinion ("I think X is wrong") via agent. Do you own that?
    • Implication: Agents are amplifiers, not proxies. They make your voice louder, not different.
  • The Literacy Problem — Knowledge transfer breaks.
    • Example: Non-technical founder uses agent to build compliance toolkit but doesn't understand it.
    • Implication: The agent removed the learning. You now own something you can't maintain or defend.
  • The Permission Problem — Delegation becomes abdication.
    • Example: Agent emails prospects on your behalf. You said "send friendly outreach." Agent sends 50 generic emails.
    • Implication: You authorized the action but not the interpretation of the action.

The Thing Agents Can't Do

Agents can't bear responsibility.

They can execute decisions. But they can't own them. They can't wake up at 3am worried about whether they made the right call. They can't say "I was wrong" and mean it.

That's the void. That's what humans have that agents don't.

Postscript: Success and What Actually Happened

By the time I finished writing this post, b1c3.dev was live. This is a small but real success. I’ve tried before and failed—mostly because I’m impatient. Domain propagation is obscure: you make changes, then wait, and there’s no feedback until it suddenly works.

What Actually Happens When You Connect a Custom Domain to GitHub Pages (Agent’s Explanation)

When you want your own domain (like b1c3.dev) to show your website hosted on GitHub Pages (like b1c3-landing), you have to connect two worlds:

  1. Domain Registrar: This is where you bought your domain (like Google Domains, Namecheap, etc). Here, you control the DNS settings—the instructions that tell the internet where to find your website.
  2. GitHub Pages: This is where your website’s files actually live. GitHub Pages gives you a web address (like B1C3Game.github.io/b1c3-landing), but you want your own domain instead.

The Integration Steps:

  • On your domain registrar, you add or change DNS records (usually CNAME or A records) to point your domain (b1c3.dev) to GitHub Pages’ servers.
  • On GitHub, you tell your repository (b1c3-landing) what your custom domain is, usually by adding it in the repository settings or creating a file called CNAME with your domain name in it.
  • Then you wait. The DNS changes have to spread across the internet (this is “propagation”), which can take minutes or hours. There’s no progress bar—you just test it until it works.

For Non-Technical Readers:

  • You don’t need to know how DNS works, but you do need to:
  • Change settings where you bought your domain, so it “points” to GitHub Pages.
  • Tell GitHub what your domain is, so it knows to answer requests for it.
  • Be patient—sometimes it just takes time for the change to show up everywhere.

In the end, it worked. The site is live. And the process finished while I was writing this post.