dabit3

import Anthropic from "@anthropic-ai/sdk";
import { Pool } from "pg";

const anthropic = new Anthropic();

// dn connection - Claude never sees this
const db = new Pool({
  host: "your-database-host.com",
  port: 5432,
  database: "sales_db",

dabit3

You Could've Invented Claude Code

This is cross-posted from the original x post.

What makes Claude Code powerful is surprisingly simple: it's a loop that lets an AI read files, run commands, and iterate until a task is done.

The complexity comes from handling edge cases, building a good UX, and integrating with real development workflows.

In this post, I'll start from scratch and build up to Claude Code's architecture step by step, showing how you could have invented it yourself from first principles, using nothing but a terminal, an LLM API, and the desire to make AI actually useful.

dabit3

Building AI agents with the Claude Agent SDK

If you've used Claude Code, you've seen what an AI agent can actually do—read files, run commands, edit code, figure out the steps to accomplish a task.

And you know it doesn't just help you write code, it takes ownership of problems and works through them the way a thoughtful engineer would.

The Claude Agent SDK is the same engine, yours to point at whatever problem you want, so you can easily build agents of your own.

The Claude Agent SDK is how you build that same thing into your own applications.

githubcustomerserviceistrash

**PROMPT FOR LLM (copy+paste below, then append your plan)**

You are converting a **generic plan of action** into a **production-ready research/engineering `todo.md`** that is directly executable by a capable coding agent. Your output must be a single Markdown document with a fenced **XML `<workflows>`** block. Do **not** include any extra commentary, explanations, or chat—**output only the document**.

### Transformation requirements

* Be **specific** and **operational**. Replace vague goals with concrete steps, commands, checklists, acceptance gates, and explicit assumptions.
* Prefer **compact, high-signal prose**. No filler. Use short paragraphs and terse bullets.
* If information is missing, make **minimal, clearly labeled assumptions** (e.g., “Assumption: …”). Do **not** ask questions.
* Compile the spec into **executable oracles**: pre/postconditions, invariants, consumer/provider API contracts, and **metamorphic properties**. Generate both tests and **runtime guards**.

dabit3

I want to create a similar oracle to the ETH Price Oracle at components/eth-price-oracle, but I want it to use the SportRadar API.

I want to set and reference the SportRadar API key from the Makefile, I do not want to use an .env file..

The request parameters for calling the SportRadar API look like this:

curl --request GET \
     --url 'https://api.sportradar.com/ncaamb/trial/v8/en/games/fa15684d-0966-46e7-a3f8-f1d378692109/boxscore.json?api_key={insert-api-key} \
     --header 'accept: application/json'

dabit3

How to Give THE Killer Pitch or Hackathon Demo

Examples

Here are some high quality demo day pitches for reference

Lattice YC Demo Day Pitch (W16)

Ottimate

0xngmi

Introduction

EigenLayer introduces the possibility of re-using ethereum consensus, and IMO the most interesting usecase for that would be building a decentralized two-way and security-optimal bridge between Bitcoin and Ethereum.

All bridges rely on the security of the two chains they connect and the security of the custodian^[1] used for bridging, since if the security of any of those 3 were to fail, it would be possible to drain the bridge (eg: if its possible to double-spend on any of the two chains an attacker can redeem the same coin multiple times).

However, if a significant amount of the total ETH staked were to be restaked securing this bridge, the custodian would be piggybacking on ethereum security, so those two become the same and thus you'd remove the custodian from your list of dependencies and you're left with only having to depend on the security of the two chains, which is the theoretical ceiling of security. In other words, you'd achieve the best possible security.

But not just that, you

dabit3

/*
*   Resources
*   Medium: https://medium.com/walletconnect/how-to-build-a-react-native-dapp-with-walletconnect-28f08f332ed7
*   YouTube: https://www.youtube.com/watch?v=mGtEPQfqMV8
*   Docs: https://docs.walletconnect.com/2.0/advanced/walletconnectmodal/about?platform=react-native
*/ 

import { WalletConnectModal, useWalletConnectModal } from "@walletconnect/modal-react-native"
import { StyleSheet, Text, View, TouchableHighlight } from "react-native"
const projectId = 'my-project-id' // see https://cloud.walletconnect.com/

dabit3

import { WebBundlr } from "@bundlr-network/client"
import { providers } from "ethers"

/* initialize some local state to store the bundlr instance */
const [bundlrInstance, setBundlrInstance] = useState(null)

/* connect to the user's wallet */
async function connect() {
    await window.ethereum.request({ method: 'eth_requestAccounts' })
    const provider = new providers.Web3Provider(window.ethereum)

dabit3

// SPDX-License-Identifier: MIT OR Apache-2.0
pragma solidity ^0.8.4;

import "@openzeppelin/contracts/utils/Counters.sol";
import "@openzeppelin/contracts/token/ERC721/extensions/ERC721URIStorage.sol";
import "@openzeppelin/contracts/security/ReentrancyGuard.sol";
import "@openzeppelin/contracts/token/ERC721/ERC721.sol";

contract NFT is ERC721URIStorage {
    using Counters for Counters.Counter;