` is always a few pixels off from the gap below it, and why you've shipped more than one `margin-top: -0.15em` with a comment that just says `// don't ask`. There's finally a real fix: the `text-box-trim` and `text-box-edge` properties. Let me walk through what the space actually is and how to cut it cleanly. ## What is the invisible space? It's called **leading**, specifically *half-leading*. Every font file defines its own default line height, larger than the letters themselves, and the browser splits the extra space into two halves: one above the text, one below. \[4] Different fonts bake in different amounts, which is exactly why consistent vertical typesetting has always been a pain on the web: the same `font-size` produces different-height line boxes across fonts. \[3] So when you set `line-height: 1.5`, that breathing room isn't centered on the letters in any way you control, it's distributed by metrics buried in the font. The letters sit inside an invisible box that's taller than they are, and that box is what throws your alignment off. ## The old way (magic numbers and shame) Before this existed, there was no clean way to remove that half-leading. \[9] You reached for one of: * Negative margins tuned by eyeball (`margin-top: -0.18em`) that broke the moment you changed the font. * Padding hacks to fake the offset back. * `::before`/`::after` pseudo-elements with negative margins to claw back the leading. All of them are font-specific magic numbers. Swap the typeface and every value is wrong again. It was guesswork dressed up as CSS. ## The new way: two properties that do one job The fix is split across two properties, and the split is the whole mental model: * **`text-box-trim`** decides *which* edges to cut: `none`, `trim-start` (top only), `trim-end` (bottom only), or `trim-both`. \[3] * **`text-box-edge`** decides *how much* to cut, i.e. *where* the new edge lands. It takes one or two keywords: the first is the over (top) edge, the second is the under (bottom) edge. \[6] `text-box-edge` does nothing on its own, it only takes effect once `text-box-trim` is set to something other than `none`. \[6] And there's a shorthand that sets both at once, which is the form you showed and the one I reach for: ```css h1 { text-box: trim-both cap alphabetic; } ``` That reads as: trim both edges; cut the top flush with the top of the **cap**ital letters, and cut the bottom flush with the **alphabetic** baseline. \[3] No magic numbers, and it adapts to whatever font is actually rendering. ## The edge values, in plain terms The `text-box-edge` keywords are just named lines in the font's anatomy. Valid **over (top)** values are `text`, `cap`, and `ex`; valid **under (bottom)** values are `text` and `alphabetic`: \[6] * `cap`, trim the top down to the top of capital letters. The usual choice for headings. * `ex`, trim the top down to the x-height (the top of lowercase letters like *x*). Tighter, good for all-lowercase type. * `alphabetic`, trim the bottom up to the baseline, ignoring descenders. The usual choice for the under edge. * `text`, trim to the font's full text edge (the em box, including ascender/descender room). The loosest cut; the only value valid as a single keyword. \[6] So `cap alphabetic` (cap on top, baseline on bottom) is the sensible default for most UI text, which is why it's the value most examples land on. \[3] ## Where this actually earns its keep This isn't a cosmetic toy, it removes a category of alignment bugs: * **Buttons and badges.** Text inside a button often looks vertically off because the half-leading above and below isn't equal. Trim it and the label sits where it should, no padding fudging. \[9] * **Headings against other elements.** When an `

` sits next to an icon or in a flex row, the leading throws the optical alignment off. `trim-both` lets you center on the actual letters. \[9] * **Tight, deliberate spacing.** Want the gap above a heading to exactly match the gap below it? Trim the font's contribution to zero and your `margin` is now the *only* thing creating space, which means it's finally predictable. The principle: trimming turns vertical spacing from *metric* (whatever the font baked in) into *optical* (what you actually set). That's the win. ## The gotchas, read these before you ship it * **It only trims the first and last line.** `text-box-trim` cuts the half-leading at the very top and very bottom of a block, not the leading *between* lines in a wrapped paragraph. \[9] For multi-line body text, your `line-height` still does its normal job in the middle. * **The default is no trimming.** Despite what some demos imply, the properties don't kick in until you opt in (`text-box: normal` is the same as `none auto`). \[5] Nothing changes on your existing pages by accident. * **Browser support is good but not universal.** As of early 2026 it works in Chrome and Edge 133 (February 2025) and Safari 18.2 (December 2024), but Firefox does not support it yet. \[1] So treat it as progressive enhancement, not a load-bearing layout tool. Because of that last point, gate it behind `@supports` and let unsupported browsers fall back to your normal spacing: ```css h1 { /* normal spacing everyone gets */ margin-block: 0.5rem; } @supports (text-box-trim: trim-both) { h1 { text-box: trim-both cap alphabetic; margin-block: 0.75rem; /* now that the leading is gone, set real spacing */ } } ``` ## The takeaway For years, the empty space around text was a thing you fought with negative margins and hoped nobody resized the font. `text-box-trim` and `text-box-edge` turn it into a property you declare: pick which edges to cut and where the cut lands, and the browser does the font math for you. Use the shorthand, default to `trim-both cap alphabetic`, remember it only touches the first and last line, and wrap it in `@supports` until Firefox catches up. It's a small property. It quietly deletes a whole genre of "why is this off by three pixels" bugs. ## Sources 1. ICS Media, "Using CSS text-box-trim and text-box-edge for vertical text spacing," March 2026 (browser support as of January 2026), [ics.media](https://ics.media/en/entry/250319/) 2. MDN Web Docs, "text-box (shorthand), CSS", [developer.mozilla.org](https://developer.mozilla.org/en-US/docs/Web/CSS/text-box) 3. MDN Web Docs, "text-box-trim, CSS", [developer.mozilla.org](https://developer.mozilla.org/en-US/docs/Web/CSS/text-box-trim) 4. (see \[3]) Font metrics and leading explanation, MDN. 5. MDN Web Docs, "text-box (the normal keyword equals none auto)", [developer.mozilla.org](https://developer.mozilla.org/en-US/docs/Web/CSS/text-box) 6. MDN Web Docs, "text-box-edge, CSS" (valid over/under keywords), [developer.mozilla.org](https://developer.mozilla.org/en-US/docs/Web/CSS/text-box-edge) 7. Can I Use, "CSS text-box-trim support table", [caniuse.com](https://caniuse.com/css-text-box-trim) 8. CSS-Tricks Almanac, "text-box-trim" (old workarounds, button centering, defined in CSS Inline Layout Module Level 3), [css-tricks.com](https://css-tricks.com/almanac/properties/t/text-box-trim/) *** *Written by* **Syed Moinuddin** Full Stack Engineer. Notes on AI tooling, agentic systems, and building things that survive contact with production. Last updated on June 1, 2026 --- title: "The Scraper That Doesn't Get Banned: Building a Scalable Web Scraping Pipeline in Go" description: "A Go web scraping pipeline that survives at scale: rate limits per domain, rotating proxies, retries, and the layered architecture that keeps you from getting banned." last_updated: "May 31, 2026" source: "https://syedmoinuddin.com/blog/scalable-web-scraping-pipeline-go" --- # The Scraper That Doesn't Get Banned: Building a Scalable Web Scraping Pipeline in Go A Go web scraping pipeline that survives at scale: rate limits per domain, rotating proxies, retries, and the layered architecture that keeps you from getting banned. A scraping script that works on your laptop and a pipeline that runs for months at scale are two completely different things. The gap between them is proxies, rate limiting, retries, and architecture, and Go is unusually good at all four. On localhost, scraping feels deterministic. You request a URL, the HTML loads, your selectors resolve, you get data. It works almost every time. Then you point the same code at ten thousand URLs across real targets, and the illusion collapses: IPs get banned within the hour, requests time out, a parser error kills the whole run, and the site starts feeding you CAPTCHAs. I build crawlers in Go for a living, and the lesson that took the longest to sink in is that a scraper isn't a script, it's a pipeline. Once you treat it like a system with decoupled stages, the hard problems (blocking, scale, reliability) become layers you can solve one at a time. This is how I build them. Go earns its place here for a concrete reason: goroutines and channels give you high-throughput concurrency with almost no overhead, it compiles to a single static binary you can drop on any box, and on parsing-heavy work Go scrapers typically run several times faster than the Python equivalent. \[1] For a pipeline whose whole job is doing thousands of things at once, that matters. ## The mental model: four decoupled stages Every scalable scraper is the same four stages, and the trick is to keep them *separate* so a failure in one doesn't take down the others: 1. **Frontier**, the queue of URLs waiting to be fetched, deduplicated so you never crawl the same page twice. 2. **Fetch**, workers that pull URLs, send HTTP requests through proxies and rate limits, and return raw responses. 3. **Parse**, extract structured data from raw HTML, *after* fetching, never inside it. 4. **Store**, write results somewhere durable. The single most important architectural rule, learned the hard way: **fetch raw first, parse later.** Don't let a regex error on one weird page kill a network request that cost you a proxy rotation and three seconds. \[7] Pull the bytes, store or queue them, and parse in a stage that's allowed to fail independently. ## Layer 1, Fetch: pick the right tool, don't over-reach The fetch layer is where most people reach for a headless browser by reflex. Don't. Headless Chrome is slow, memory-hungry, and usually unnecessary. Match the tool to the target: \[1]\[2] * **`net/http` + `goquery`**, for static HTML. Fastest, lightest, most control. goquery gives you jQuery-style CSS selectors over the response body. * **Colly**, when you need crawling: link-following, cookie handling, request queues, and built-in concurrency, all out of the box. * **chromedp or Rod**, *only* when the data is rendered by JavaScript and there's no underlying API to hit. Rod adds stealth features; chromedp is the common choice. Reserve these for pages that genuinely need a browser. \[1]\[2] Most "I need a headless browser" situations are actually "I didn't check the network tab for the JSON endpoint the page is already calling." Check first. ## Layer 2, Rate limiting: rotate at human speed The fastest way to get banned is to behave like a machine. A real visitor doesn't fire fifty requests per second from one address. \[5] Your scraper shouldn't either, and the clean way to enforce that in Go is the official `golang.org/x/time/rate` package, a token-bucket limiter maintained alongside the standard library. \[3] You create a limiter with a rate `r` and a burst size `b`, and you call `Wait` before each request. The key refinement for a real crawler: **one limiter per domain**, so you're polite to each target independently instead of throttling your whole pipeline to the slowest site. ```go type DomainLimiter struct { mu sync.Mutex limiters map[string]*rate.Limiter r rate.Limit burst int } func NewDomainLimiter(perSecond float64, burst int) *DomainLimiter { return &DomainLimiter{ limiters: make(map[string]*rate.Limiter), r: rate.Limit(perSecond), burst: burst, } } // Wait blocks until this domain is allowed another request. func (d *DomainLimiter) Wait(ctx context.Context, host string) error { d.mu.Lock() lim, ok := d.limiters[host] if !ok { lim = rate.NewLimiter(d.r, d.burst) d.limiters[host] = lim } d.mu.Unlock() return lim.Wait(ctx) // sleeps until a token frees up } ``` `Wait` is the method to reach for in a scraper, it blocks until a token is available rather than rejecting the request, which is exactly the smoothing behavior you want. \[3] And watch the responses: the moment you start seeing `429 Too Many Requests`, back off immediately. The server is telling you the limit. \[7] ## Layer 3, Proxies: the part that actually decides whether you get blocked A single IP burns out fast against a serious target. After enough requests it gets flagged and your scraper stops working until you swap. \[5] Proxies are how you spread load across many addresses, and choosing the right *type* matters more than the pool size on the marketing page: \[4] * **Datacenter**, fast and cheap, best for unprotected sites. Easiest to detect and block. * **Residential**, routed through real home ISP addresses, so requests look like they came from an apartment, not a server rack. Expensive (priced per GB), but they get through advanced bot management and geo-blocks. * **ISP**, static IPs with residential trust signals; ideal for sticky sessions like logged-in flows where rapid rotation triggers lockouts. * **Mobile**, extreme trust because blocking one risks blocking many real users behind carrier NAT. Reserve for hard edge cases. The rotation decision is just as important as the type. **Per-request rotation** (a fresh IP every call) is right when each request is independent. **Sticky sessions** (one IP held for a few-minute window) are right when you need continuity (a cart, a login, a multi-step flow) because switching IPs mid-session breaks cookies and gets you bounced to a CAPTCHA. Most failed residential setups are using per-request rotation where they needed sticky sessions. \[5] In Go, the clean pattern is one reusable `http.Client` per proxy, picked round-robin, so you're not rebuilding transports on every request: ```go type ProxyPool struct { clients []*http.Client n uint64 } func NewProxyPool(proxyURLs []string) (*ProxyPool, error) { clients := make([]*http.Client, 0, len(proxyURLs)) for _, p := range proxyURLs { pu, err := url.Parse(p) if err != nil { return nil, err } clients = append(clients, &http.Client{ Timeout: 30 * time.Second, Transport: &http.Transport{Proxy: http.ProxyURL(pu)}, }) } return &ProxyPool{clients: clients}, nil } func (p *ProxyPool) Next() *http.Client { i := atomic.AddUint64(&p.n, 1) return p.clients[i%uint64(len(p.clients))] } ``` One 2026 caveat worth knowing: proxy *sourcing* is now a real security and compliance question. Google Cloud's takedown of the IPIDEA network in January 2026 showed that where your residential IPs come from matters, and Cloudflare's "Pay Per Crawl" (HTTP 402) model is starting to shift parts of the web from hard blocking toward metered, paid access. \[4] Vet your provider, and don't assume free or grey-market pools are safe. ## Layer 4, Looking human: headers, user agents, and TLS Proxies hide your IP, but the request itself still carries fingerprints. Rotate your `User-Agent` and send a realistic, consistent set of headers, a real browser doesn't send a bare request with no `Accept-Language`. \[8] For aggressively protected targets, the next layer down is TLS fingerprint spoofing (libraries like CycleTLS), because anti-bot systems increasingly fingerprint the TLS handshake itself, not just the headers. \[1] Layer these defenses based on how hard the target pushes back, don't pay the cost of browser automation and TLS spoofing on a site that a plain `net/http` request walks straight into. ## Layer 5, Resilience: failures are the normal case Once you leave localhost, failure stops being an edge case and becomes an operating condition. Networks flake, proxies time out, targets get overloaded. \[7] Build for it from the start: * **Retry with exponential backoff and jitter.** Don't retry instantly, that just hammers a struggling endpoint. Increase the delay each attempt, and add randomness so a thousand workers don't all retry in lockstep. * **Know what's retryable.** A `429` or `503` or a timeout deserves a retry. A `404` or `401` does not, retrying it wastes a proxy and a token. * **Cap attempts, then dead-letter.** After a few failures, stop and route the URL to a dead-letter queue for manual review instead of looping forever. \[6] ```go func DoWithRetry(ctx context.Context, attempt func() error) error { const maxAttempts = 4 base := 500 * time.Millisecond for i := 0; i < maxAttempts; i++ { err := attempt() if err == nil { return nil } if !isRetryable(err) { return err // don't retry 4xx (except 429) } // exponential backoff with full jitter window := base * (1 << i) sleep := time.Duration(rand.Int63n(int64(window))) select { case <-time.After(sleep): case <-ctx.Done(): return ctx.Err() } } return errors.New("max retries exceeded") } ``` The mindset shift is accepting an **error budget**: at scale, 1–3% of requests will fail no matter what you do. Build the pipeline to retry and move on, not to demand perfection. \[7] ## Layer 6, Scaling out: workers, a shared frontier, and a queue The in-process version of scale is the worker pool, a fixed set of goroutines all reading from one channel of URLs. This alone takes you a long way: ```go func Crawl(ctx context.Context, urls <-chan string, results chan<- Result, workers int) { var wg sync.WaitGroup for i := 0; i < workers; i++ { wg.Add(1) go func() { defer wg.Done() for u := range urls { // ranges until the channel closes results <- fetch(ctx, u) } }() } wg.Wait() close(results) } ``` When one machine isn't enough, you go distributed, and the components are well-established: a **scheduler/queue** holds the URL frontier, **stateless workers** pull from it across many nodes, and a **store** collects results. \[6] The pieces that make it survive production: * **Deduplicate the frontier.** A shared store like Redis tracks seen URLs so workers across nodes never crawl the same page twice. \[8] * **Use a real message queue** (NATS, RabbitMQ, Kafka) for the URL frontier so work isn't lost when a worker crashes. \[6] * **Separate retry queues** with increasing delays, feeding a dead-letter queue after repeated failure, never push failed URLs straight back into the main queue, or you build an infinite loop that hammers broken endpoints. \[6] * **Keep workers stateless** so a crash loses no data, and **restart them periodically**, long-lived workers parsing malformed HTML accumulate memory leaks. \[6]\[7] * **Score your workers.** They won't all have the same proxy quality and network speed; route the hard jobs to your best performers. \[6] ## Storage and observability Store raw responses first (object storage or a `raw_pages` table), then run parsing as its own stage writing structured rows to Postgres or MongoDB. That separation means a parser bug is a re-run over saved bytes, not a re-crawl. Then watch the system, because a scraper that can't see itself is a scraper that's quietly failing. The metrics that matter aren't vanity numbers, they're **success rate**, **latency** (if a target slows down, slow your scraper down to avoid a ban), and **cost per successful request**, which is the number that actually tells you whether a proxy provider is worth it. \[4]\[7] When you trial proxies, compare on cost-per-success on *your* targets, not on headline pool size. \[4] ## The line you don't cross: legal and ethical This isn't legal advice (I'm an engineer, not a lawyer, and this area is actively being shaped in courtrooms) but every scraper builder needs the lay of the land. \[9] The simplest test anyone has produced: open an incognito window, don't log in, and try to view the page. If you can see it without authenticating, it's public data, and under current US case law scraping it is likely defensible. If it's behind a login, you're in dangerous territory. Courts have effectively drawn the line at authentication. \[9] The landmark *hiQ Labs v. LinkedIn* ruling held that accessing publicly visible pages doesn't violate the Computer Fraud and Abuse Act, the Ninth Circuit ruled this way in 2019 and reaffirmed it in 2022. \[9] But "not a CFAA violation" isn't the whole story: * **Terms of Service can still bite.** *Meta v. Bright Data* showed that scraping data subject to a site's terms may be a breach-of-contract issue even when the data looks public. \[9] * **Anti-circumvention is its own risk.** *Reddit v. Perplexity* (filed late 2025, pending in early 2026) invokes the DMCA over allegedly circumventing rate limits and anti-bot measures, a different legal theory from the CFAA. \[9] * **robots.txt is voluntary but meaningful.** Ignoring it isn't automatically illegal, but respecting it reads as good faith, and disregarding it can be used as evidence of bad faith in a lawsuit. Read it. \[9] * **Personal data triggers privacy law.** GDPR and CCPA apply the moment you collect data about identifiable people, regardless of whether the page was public. Minimize and avoid PII unless you have a real basis to handle it. \[9] The honest summary: scrape public, non-personal data, respect robots.txt and rate limits, read the terms, and get real legal advice before any high-stakes commercial scraping. ## The takeaway A scraper that survives isn't the one with the cleverest selectors, it's the one built as a pipeline of independent layers. Fetch with the lightest tool that works. Meter yourself per domain and rotate at human speed. Pick proxy types and rotation modes to match the target. Assume failure and retry with backoff and jitter. Decouple fetch from parse so one bad page can't sink a run. Scale out with a deduplicated frontier, a durable queue, and stateless workers. And stay on the right side of the line while you do it. Go gives you the concurrency and the single-binary simplicity to make all of this boringly reliable. The rest is discipline: build the layers, watch the metrics, and respect the sites you're pulling from. ## Sources 1. Roundproxies, "Web scraping in Golang: 2026 step-by-step guide," updated December 2025, [roundproxies.com](https://roundproxies.com/blog/web-scraping-golang/) 2. Olostep, "Web Scraping in Golang: Libraries, Anti-Blocking, and Scale," 2026, [olostep.com](https://www.olostep.com/blog/web-scraping-golang) 3. The Go Programming Language, "Go Wiki: Rate Limiting" and golang.org/x/time/rate package docs, [go.dev/wiki](https://go.dev/wiki/RateLimiting) · [pkg.go.dev](https://pkg.go.dev/golang.org/x/time/rate) 4. Olostep, "Best Proxies for Web Scraping: What Actually Scales," 2026, [olostep.com](https://www.olostep.com/blog/best-proxies-web-scraping) 5. Technology.org, "Rotating Residential Proxies for Web Scraping: When They Beat Datacenter Proxies," May 2026, [technology.org](https://www.technology.org/2026/05/14/rotating-residential-proxies-for-web-scraping-when-they-beat-datacenter-proxies/) 6. Bright Data, "Guide to Distributed Web Crawling: Scale Your Scraping," 2025, [brightdata.com](https://brightdata.com/blog/web-data/distributed-web-crawling) 7. OnlineProxy, "How to Scale Web Scraping: Architecture for 1 Million Requests per Day," April 2026, [medium.com](https://medium.com/@onlineproxypmm/how-to-scale-web-scraping-architecture-for-1-million-requests-per-day-b8c43088412f) 8. DEV Community, "Building a High-Concurrency Web Crawler in Go: A Practical Guide," January 2026, [dev.to](https://dev.to/jones_charles_ad50858dbc0/building-a-high-concurrency-web-crawler-in-go-a-practical-guide-i3a) 9. Legal landscape, PromptCloud, Tendem, and SociaVault compliance overviews (hiQ v. LinkedIn, Meta v. Bright Data, Reddit v. Perplexity, CFAA, robots.txt, GDPR/CCPA), 2026, [promptcloud.com](https://www.promptcloud.com/blog/is-web-scraping-legal/) · [tendem.ai](https://tendem.ai/blog/is-web-scraping-legal-compliance-overview) · [sociavault.com](https://sociavault.com/blog/web-scraping-legality-court-cases-public-vs-private-data) *** *Written by* **Syed Moinuddin** Full Stack Engineer. Notes on AI tooling, agentic systems, and building things that survive contact with production. Last updated on May 31, 2026 --- title: "Boring on Purpose: Go Basics for People Who Want to Ship" description: "Go's whole pitch is that the basics are enough. A pragmatic tour of the small toolset (structs, slices, errors, goroutines, interfaces) that ships real systems." last_updated: "May 30, 2026" source: "https://syedmoinuddin.com/blog/boring-on-purpose-go-basics" --- # Boring on Purpose: Go Basics for People Who Want to Ship Go's whole pitch is that the basics are enough. A pragmatic tour of the small toolset (structs, slices, errors, goroutines, interfaces) that ships real systems. Go was designed to be small. Fewer features, fewer ways to do things, fewer footguns. That's not a limitation, it's the whole point, and it's why you can learn the basics in an afternoon and be productive the same week. Most languages grow by adding things. Go grew by refusing to. No inheritance, no exceptions, no generics for its first decade, no clever metaprogramming. What's left is a language with a tiny surface area that compiles to a single fast binary and is genuinely hard to misuse. I write Go for backend services and crawlers every day, and the thing I'd tell anyone starting out is this: the basics *are* most of the language. There's no deep second layer you're missing. Learn these few things well and you can build real systems. Let's go. ## Hello, world (and the toolchain) A Go program is made of packages. The entry point is `main`: ```go package main import "fmt" func main() { fmt.Println("Hello, world") } ``` Run it with `go run main.go`. When you're ready to ship, `go build` compiles it to a single static binary, no runtime to install on the server, no dependency hell. That one fact is why Go deployments are so boring (in the good way): copy one file, run it. A real project starts with `go mod init yourname/project`, which creates a module and tracks dependencies in `go.mod`. That's the entire setup ceremony. ## Variables, types, and zero values Two ways to declare. Inside a function, `:=` infers the type and is what you'll use 90% of the time: ```go var name string = "explicit" // full form age := 30 // inferred, function scope only count := 0 // int ratio := 3.14 // float64 ok := true // bool ``` The basic types are what you'd expect: `int`, `float64`, `string`, `bool`, plus sized variants like `int64` and `byte`. The one idea that surprises newcomers: **every type has a zero value**, and Go uses it automatically. No uninitialized garbage. Numbers start at `0`, strings at `""`, booleans at `false`, and pointers, slices, maps, and interfaces at `nil`. You can lean on this, a freshly declared `var total int` is already `0`, ready to use. ## Functions, and the thing that makes Go *Go* Functions are ordinary, but Go has one trick that shapes the entire language: **multiple return values**. ```go func divide(a, b int) (int, error) { if b == 0 { return 0, fmt.Errorf("cannot divide %d by zero", a) } return a / b, nil } ``` That second return value is how Go does error handling, which deserves its own section, because it's the thing people either love or fight. ## Error handling: explicit on purpose Go has no exceptions. A function that can fail returns an `error` as its last value, and you check it. Immediately. Every time. ```go result, err := divide(10, 0) if err != nil { log.Printf("division failed: %v", err) return } fmt.Println(result) ``` Yes, you'll write `if err != nil` a lot. That's the trade: there's no hidden control flow, no invisible stack-unwinding, no surprise about where a failure goes. You can read a Go function top to bottom and see every path it can take. After a week it stops feeling verbose and starts feeling like the code is just honest with you. ## Structs and methods, no classes required Go doesn't have classes. It has structs (data) and methods (behavior attached to a type): ```go type User struct { ID int Name string Email string } // a method with a receiver, this is how behavior attaches to a type func (u User) Greeting() string { return "Hi, " + u.Name } func main() { u := User{ID: 1, Name: "Ada", Email: "ada@example.com"} fmt.Println(u.Greeting()) } ``` Use a pointer receiver (`func (u *User)`) when the method needs to modify the struct or when the struct is large and you want to avoid copying it. That's most of the design decision right there. ## Slices and maps: the two workhorses You'll reach for these constantly. A **slice** is a growable list: ```go nums := []int{1, 2, 3} nums = append(nums, 4) // append returns a new slice, reassign it fmt.Println(len(nums)) // 4 for i, n := range nums { // index and value fmt.Println(i, n) } ``` A **map** is a key-value store, with the "comma ok" idiom for checking presence: ```go ages := make(map[string]int) ages["ada"] = 36 age, ok := ages["ada"] // ok is false if the key is missing if ok { fmt.Println(age) } ``` The one gotcha to internalize: `append` may return a *new* underlying array, so always assign its result back. And map iteration order is random by design, never depend on it. ## defer: cleanup that can't be forgotten `defer` schedules a call to run when the surrounding function returns, no matter how it returns. It's how Go handles cleanup without `try/finally`: ```go f, err := os.Open("data.txt") if err != nil { return err } defer f.Close() // runs when the function exits, guaranteed // ... use f freely; you've already handled closing it ``` Open a thing, defer closing it on the next line, and forget about it. Files, locks, database rows, same pattern every time. ## Goroutines and channels: concurrency that's actually approachable This is Go's headline feature, and it's simpler than its reputation suggests. Put `go` in front of a function call and it runs concurrently, a **goroutine**, which is far lighter than an OS thread. You can run thousands. ```go go doWork() // runs concurrently; main keeps going ``` The problem with concurrency is always communication, and Go's answer is **channels**, typed pipes that goroutines use to pass values safely: ```go ch := make(chan string) go func() { ch <- "done" // send into the channel }() msg := <-ch // receive (blocks until a value arrives) fmt.Println(msg) ``` The Go proverb is *don't communicate by sharing memory; share memory by communicating.* Instead of locking shared state, you pass ownership of data through channels. It takes one project to click, and then concurrent code stops being scary. ## Interfaces: satisfied without saying so Go interfaces are structural. A type satisfies an interface just by having the right methods, you never write `implements`. This is quietly one of the best things about the language. ```go type Stringer interface { String() string } // User automatically satisfies Stringer just by having this method func (u User) String() string { return fmt.Sprintf("User(%d, %s)", u.ID, u.Name) } ``` Because satisfaction is implicit, you can define small interfaces *where you consume them*, and any type with the right shape fits. The community wisdom ("accept interfaces, return structs") falls right out of this. Keep interfaces tiny; the standard library's `io.Reader` and `io.Writer` are each a single method, and they're everywhere. ## The handful of gotchas worth knowing early * **`append` returns a new slice.** Always reassign: `s = append(s, x)`. * **Map order is random.** If you need order, sort the keys yourself. * **Loop variables** were historically reused across iterations, capturing one in a goroutine could bite you. Modern Go fixed this, but if you see old advice about copying the loop variable, that's why. * **A `nil` slice is fine to use.** You can `append` to it and `range` over it. A `nil` map, however, panics if you write to it, `make` it first. * **Unused variables and imports are compile errors.** The compiler refuses to let you be sloppy. Annoying on day one, a gift by month two. ## The takeaway Go's whole pitch is that the basics are enough. There's no expert dialect you graduate into, the same small set of tools (structs, slices, maps, errors, goroutines, interfaces) builds everything from a CLI to a high-throughput service. The language stays out of your way so you spend your thinking on the problem, not the syntax. So write the verbose `if err != nil`. Lean on zero values. Pass data through channels. Keep your interfaces small. It feels almost too plain at first, and then you ship something, and you realize plain was the feature all along. ## Sources 1. The Go Programming Language, official site and docs, [go.dev/doc](https://go.dev/doc/) 2. A Tour of Go (interactive intro), [go.dev/tour](https://go.dev/tour/) 3. Effective Go (idioms and style), [go.dev/doc/effective_go](https://go.dev/doc/effective_go) 4. Go by Example (annotated runnable examples), [gobyexample.com](https://gobyexample.com/) *** *Written by* **Syed Moinuddin** Full Stack Engineer. Notes on AI tooling, agentic systems, and building things that survive contact with production. Last updated on May 30, 2026 --- title: "I Spent 6 Months Tuning Claude Code. Here's the Exact Setup That Finally Worked." description: "The exact Claude Code setup after six months: a lean CLAUDE.md, lazy-loaded skills, subagents, hooks, git worktrees, and the five MCP servers that earn their place." last_updated: "May 29, 2026" source: "https://syedmoinuddin.com/blog/claude-code-setup-6-months" --- # I Spent 6 Months Tuning Claude Code. Here's the Exact Setup That Finally Worked. The exact Claude Code setup after six months: a lean CLAUDE.md, lazy-loaded skills, subagents, hooks, git worktrees, and the five MCP servers that earn their place. CLAUDE.md, subagents, hooks, skills, worktrees, and the five MCP servers that earn their place. For the first month, I used Claude Code the way most people do: a chat box in my terminal that happened to be able to edit files. It was fast and impressive and produced a steady stream of code I didn't fully trust. Six months later it runs a real chunk of my workflow across a Go crawler backend, a pile of Next.js frontends, and a fleet of FastAPI services, and it does it without me babysitting every diff. The difference wasn't a better model. It was finally understanding that Claude Code is not a chatbot. It's an agent loop with a handful of extension points, and each one has a different *context cost*. Once that clicked, the whole thing got predictable. This is the setup I landed on. Not a docs summary, the actual layout, the rules, the things I stopped doing. ## The one idea that fixed everything: context cost Every extension point plugs into a different part of the loop, and the only question that matters is *when does this load into the context window.* * `CLAUDE.md` is loaded every single session. It's always-on. Expensive by default. * Skills load lazily, Claude sees only a name and a one-line description until a task actually matches, then it pulls the body in. * Subagents run in their own separate context and hand back only the result. * Hooks don't touch the context at all. They're shell commands that fire on events. * MCP servers add tools, and tools have a token weight whether you call them or not. Once you think in those terms, the placement decisions answer themselves. If a rule must be true on *every* turn, it goes in `CLAUDE.md`. If it's a procedure you need *sometimes*, it's a skill. If it's noisy research that would pollute your main thread, it's a subagent. If it's an automatic guardrail, it's a hook. Stop arguing with the model in chat, encode the decision once and move on. That framing is straight from how the tool is built. Claude Code launched in early 2025 as a terminal tool that could edit files and run bash; the extension layers arrived over the following year, MCP, then subagents, hooks, skills, plugins, and most recently agent teams. \[1]\[2]  *Context cost in one picture: everything funnels through the context window, so where a rule loads is really a decision about what it costs.* ## Layer 1, CLAUDE.md: the rules I'm tired of repeating `CLAUDE.md` is project memory. It's the thing Claude reads before it does anything, so the temptation is to dump your whole engineering handbook in there. Don't. Every token in this file is paid on every turn. Mine is deliberately short, stable, non-negotiable rules only. The actual core of mine, trimmed: ```markdown # Engineering rules (always apply) ## Frontend - Tailwind only. No CSS modules, no styled-components, no inline style objects. - pnpm. Never npm or yarn. - Strict TypeScript. `any` is banned, if you reach for it, stop and ask. ## Backend (Python) - Poetry for deps. No bare pip. - FastAPI routes are async-only. - Every request/response model is a Pydantic schema. No raw dicts crossing a boundary. ## Infra - Every Dockerfile/compose service declares memory limits. - Commits are atomic and conventional. One logical change per commit. ## Workflow - When I describe a bug, feature, or task, draft a Jira ticket for it (title, description, acceptance criteria, priority, labels) before writing code. ``` That last rule is the one that quietly changed how I work. I describe what I'm about to do, and a structured ticket comes back before a single line is written. The work documents itself. The discipline here is editing it like code. A recurring mistake or a review comment I keep leaving is a `CLAUDE.md` edit, not a one-off correction I'll have to repeat next week. If I find myself typing "no, use Tailwind" twice, that's a bug in this file.  *The mental model: each extension point loads into context at a different time, so where a rule lives is really a decision about what it costs.* ## Layer 2, Skills: the procedures I don't want to paste Skills are the part that genuinely surprised me. A skill is a folder with a `SKILL.md`, YAML frontmatter (a name and a description) plus instructions, and optionally scripts and templates. \[5]\[8] At session start Claude only sees the name and description, roughly a hundred tokens. When a task matches, it reads the full body. If the body points at scripts, those run in bash and only their *output* comes back, the source never burns tokens. \[8] That progressive-disclosure model means you can keep a big library of workflows around at almost no standing cost. I invoke them as slash commands or let Claude pull them in on its own. The ones that earn their keep for me: * `new-service`, scaffolds a FastAPI service the way I actually structure them: async routes, Pydantic schemas, Poetry, Dockerfile with memory limits, the lot. * `pr-review`, runs my pre-PR checklist before I ever open the PR. Catches the `any` that slipped in, the missing test, the non-atomic commit. * `webp-pipeline`, my S3 image-optimization routine, because I have run the "convert these to WebP and re-upload" dance enough times to never want to type it again. Rule of thumb: if I've pasted the same 150-word prompt twice, it becomes a skill.  *A skill captures a repeatable procedure (explore, plan, review, build) and loads only when a task actually matches.* ## Layer 3, Subagents: keeping the main thread clean A subagent is a separate Claude instance with its own context window that does one job and returns only the result. \[4] You define it in `.claude/agents/` as Markdown with frontmatter, name, description, the tools it's allowed, and a system prompt. ```markdown --- name: schema-auditor description: Reviews DB queries and Pydantic models for N+1s, missing indexes, and unvalidated input tools: Read, Grep, Glob --- You are a database and schema reviewer. Inspect the changed files only. Report: risky queries, missing indexes, any boundary taking a raw dict instead of a validated schema. Be specific with file and line. Do not edit. ``` The reason subagents matter isn't delegation for its own sake, it's context hygiene. When I ask the main session to "go read these forty files and tell me where auth is enforced," all forty files end up in my main context and everything afterward is slower and dumber. Hand that to a subagent and I get back a two-paragraph answer while my main thread stays focused on the actual task. One trap worth flagging, because it bit me: if you leave the `tools` field off a subagent, it implicitly inherits *every* tool, including your MCP tools. \[8] Scope them deliberately. A reviewer that can only read should not be able to write or hit your database. ## Layer 4, Hooks: automation that doesn't depend on me asking Hooks are the layer I underused the longest. They're shell commands wired to lifecycle events, think git hooks, but for the agent. You configure them in `settings.json` (or interactively via `/hooks`), with an event, a matcher, and a command. \[3] They don't ask permission and they don't cost context; they just fire. My two workhorses: ```json { "hooks": { "PostToolUse": [ { "matcher": "Write|Edit", "hooks": [ { "type": "command", "command": "pnpm prettier --write $CLAUDE_FILE 2>/dev/null; true" } ] } ], "PreToolUse": [ { "matcher": "Bash", "hooks": [{ "type": "command", "command": "./.claude/guard-bash.sh" }] } ] } } ``` The `PostToolUse` formatter means I stopped caring whether Claude's output is formatted, it always is, deterministically, without a single token spent telling it to. The `PreToolUse` gate is a small script that blocks the commands I never want run unattended (anything touching `rm -rf`, force-pushes, prod env files). The model proposing something dangerous and a script refusing to run it are two different safety layers, and I want both. If a rule can be enforced by a program instead of a prompt, enforce it with a program. Prompts are probabilistic. Hooks are not. ## Layer 5, Worktrees: how I run three of these at once This isn't a Claude Code feature, it's plain git, but it's the thing that took my throughput from "one task at a time" to genuinely parallel. `git worktree` lets you check out multiple branches into separate directories backed by the same repo. One Claude Code session per worktree, each on its own branch, each with its own clean context. ```bash git worktree add ../helixcrawl-rate-control feature/rate-control git worktree add ../helixcrawl-bugfix fix/sitemap-parser # now open a Claude Code session in each directory ``` While one session refactors the rate-control service, another chases a parser bug, and I review whichever finishes first. No stashing, no branch-switching mid-thought, no two agents fighting over the same working tree. For anything bigger than a quick edit, this is how I work now. ## The five MCP servers that earn their place MCP is the highest-setup, highest-temptation layer. Every server you connect adds tools, and tools cost context whether or not you call them. I've installed and removed a lot of them. These five stayed, because each one removes a real copy-paste loop from my day. (Edit the config directly, `.mcp.json` for project scope, rather than fighting the CLI wizard. \[8])  *MCP wires external tools (Jira, GitHub, Postgres, a browser, live docs) into the agent loop. Every server adds tools, and tools cost context.* 1. **Atlassian / Jira.** Non-negotiable for me. My `CLAUDE.md` drafts tickets; this server actually files them, links them to branches, and updates status. The loop from "I'm starting this" to a tracked ticket is now one sentence. 2. **GitHub.** PRs, issues, and review comments without leaving the session. It reads the diff, drafts the PR body against my checklist, and pulls review threads back in when I'm addressing feedback. 3. **Postgres.** Schema-aware. Instead of guessing at column names or pasting `\d+` output, Claude inspects the live schema before it writes a query or a migration. This alone killed a whole category of "that column doesn't exist" errors. 4. **Playwright.** Browser automation for E2E checks and for poking at the frontends I'm building. Given my crawler work, having the agent drive a real browser to verify a flow, instead of asserting it "should" work, is worth the tool weight. 5. **Context7 (live library docs).** The honest fix for hallucinated APIs. It pulls current documentation for whatever library is in play, so the agent writes against the version I'm actually on instead of whatever it half-remembers. For fast-moving packages this is the difference between working code and confident nonsense. Everything else (the calendar servers, the chat servers, the dozen "cool demo" integrations) I turned off. If a server isn't removing a recurring loop, it's just tax on every prompt. ## The whole thing, on disk ``` .claude/ ├── CLAUDE.md # always-on rules (short on purpose) ├── settings.json # hooks: formatter + bash guard ├── .mcp.json # the five servers ├── guard-bash.sh # pre-tool safety gate ├── agents/ │ ├── schema-auditor.md │ ├── pr-reviewer.md │ └── docs-researcher.md └── skills/ ├── new-service/SKILL.md ├── pr-review/SKILL.md └── webp-pipeline/SKILL.md ```  *The whole setup on disk: a lean `.claude` folder, rules, agents, skills, settings, MCP. Nothing in it is long.* Nothing in here is long. `CLAUDE.md` is a few hundred tokens. Each subagent is maybe thirty lines. The hooks are one gate and one formatter. The power isn't in any single file, it's in not making the model re-derive my conventions every session. ## What I stopped doing * **Stuffing CLAUDE.md.** My first version was a 2,000-token wall of preferences. Half of them were "sometimes" rules that belonged in skills. Cutting it made every response sharper. * **Arguing in chat.** Correcting the same thing twice is a config smell. The fix lives in a file, not in my patience. * **Trusting "done."** The model is much better than it was at flagging its own uncertainty, but I still let hooks and a review subagent be the thing that says done, not the chat message. A green test suite is a fact; "I've completed the task" is a claim. * **Collecting MCP servers.** Fun to connect, expensive to keep. Five is plenty. ## The takeaway Six months in, the setup that works isn't clever. It's boring and it's layered: stable rules that are always loaded, procedures that load on demand, research that happens off to the side, guardrails that run as code, and just enough external tools to close the loops I actually hit. The model got better over those six months too, but the thing that made it *trustworthy* was deciding, for every rule, where it should live and what it should cost. Start with `CLAUDE.md`. Add the rest when a real trigger shows up. Don't try to wire up all six extension points on day one, you'll just build a slower agent. ## Sources 1. Claude Code, "Extend Claude Code" (features overview), 2026, [code.claude.com](https://code.claude.com/docs/en/features-overview) 2. Towards AI, "Claude Code Extensions Explained: Skills, MCP, Hooks, Subagents, Agent Teams & Plugins," April 2026, [pub.towardsai.net](https://pub.towardsai.net/claude-code-extensions-explained-skills-mcp-hooks-subagents-agent-teams-plugins-9294907e84ff) 3. Claude Code documentation, Hooks configuration, [docs.claude.com](https://docs.claude.com/en/docs/claude-code/overview) 4. Level Up Coding, "A Mental Model for Claude Code: Skills, Subagents, and Plugins," March 2026, [levelup.gitconnected.com](https://levelup.gitconnected.com/a-mental-model-for-claude-code-skills-subagents-and-plugins-3dea9924bf05) 5. Smith Horn Group, "Choosing between skills, subagents, and MCP servers in Claude Code," 2025, [smithhorngroup.substack.com](https://smithhorngroup.substack.com/p/choosing-between-skills-subagents) *** *Written by* **Syed Moinuddin** Full Stack Engineer. Notes on AI tooling, agentic systems, and building things that survive contact with production. Last updated on May 29, 2026 --- title: "The Bluffing Problem: What Claude Opus 4.8 Changes About Trusting AI Code" description: "Claude Opus 4.8's real upgrade isn't raw capability, it's honesty. A model ~4x less likely to let its own code flaws slip by silently, and what that means for agentic AI." last_updated: "May 28, 2026" source: "https://syedmoinuddin.com/blog/claude-opus-4-8-bluffing-problem" --- # The Bluffing Problem: What Claude Opus 4.8 Changes About Trusting AI Code Claude Opus 4.8's real upgrade isn't raw capability, it's honesty. A model ~4x less likely to let its own code flaws slip by silently, and what that means for agentic AI. AI models are getting faster and more autonomous, but the real bottleneck for production work isn't raw capability, it's whether the model tells you the truth about what it actually did. Claude Opus 4.8 makes that its headline bet. A model that confidently says "done" is more dangerous than a model that says "I'm not sure this is right." That gap is exactly where most agentic coding workflows break. Anthropic released Claude Opus 4.8 on May 28, 2026, roughly six weeks after Opus 4.7, and at the same price as its predecessor. \[1]\[2] The benchmark gains are real but modest. The interesting part is what the model was trained *not* to do: jump to conclusions and claim progress it can't back up. For anyone wiring AI into long-running agents, CI pipelines, or autonomous engineering loops, that's the upgrade that actually matters. ## What is the bluffing problem? The bluffing problem is the point where an AI model's confidence stops tracking its correctness. The code compiles, the agent reports success, the summary sounds plausible, and nobody notices that a flaw slipped through, because the model never flagged it. It's a quiet failure mode. It rarely shows up in a demo. It shows up three weeks later in production, in the 20% of the system the model glossed over while sounding 100% certain. ## What developers should know before adopting 4.8 * The benchmark jump over 4.7 is incremental, not dramatic. The reliability and honesty improvements are the real story. * The clearest win is calibration: the model is far less likely to let its own mistakes pass silently. \[1] * Pricing is unchanged, so there's no cost penalty to upgrading. \[1] * "Fast mode" is now meaningfully cheaper, which changes the math for high-volume, latency-sensitive workloads. \[1] * New effort controls let you trade quality for speed and rate-limit headroom per task, useful for tuning agent fleets. \[1] * It's already live in third-party tooling like GitHub Copilot, so you may be using it before you choose to. \[5] ## Why honesty is the headline feature Every frontier model is trained to be honest. The hard part is calibration under uncertainty, knowing when the evidence is thin and saying so, instead of producing a confident-sounding answer that *looks* like a reasonable response. Anthropic's framing is direct: a general problem with AI models is that they sometimes jump to conclusions and claim progress despite thin evidence. \[1] Opus 4.8 is trained to flag that uncertainty instead of papering over it. In their evaluations, the model is around four times less likely than its predecessor to let flaws in code it wrote pass unremarked. \[1] That number is the one worth tattooing on the wall. In a single chat, a confident wrong answer is annoying. In an autonomous agent running unattended across hundreds of subtasks, a confident wrong answer compounds. ## The capability gains (the modest part) The benchmark deltas over Opus 4.7 are steady improvements rather than a generational leap: * Agentic coding: 64.3% → 69.2% \[2] * Multidisciplinary reasoning with tools: 54.7% → 57.9% \[2] * Computer/browser use (Online-Mind2Web): 84%, a clear jump over both Opus 4.7 and GPT-5.5 \[1] Anthropic also claims Opus 4.8 tops OpenAI's GPT-5.5 and Google's Gemini 3.1 Pro across several agentic benchmarks, including coding, financial analysis, and computer use. \[4] As always with vendor-reported numbers, treat them as a starting point for your own evals, not gospel, which, fittingly, is exactly the kind of skepticism this release is built to support. ## What ships alongside the model The model rarely arrives alone, and the surrounding features tell you where Anthropic thinks the work is heading. * **Dynamic workflows.** A research-preview feature in Claude Code that lets the model plan a large task, run hundreds of parallel subagents in a single session, then verify its own outputs before reporting back. Anthropic says it can handle codebase-scale migrations across hundreds of thousands of lines of code, using the existing test suite as the bar. \[1] Available on Enterprise, Team, and Max plans. * **Effort control.** A new setting next to the model picker in claude.ai and Cowork. Higher effort means deeper, more frequent reasoning; lower effort means faster responses that burn through rate limits more slowly. Available on all plans. \[1] * **Messages API system entries.** Developers can now insert system instructions mid-conversation inside the messages array, updating permissions, token budgets, or environment context as an agent runs, without breaking the prompt cache. \[1] ## The pricing math Pricing is identical to Opus 4.7 for regular usage: $5 per million input tokens and $25 per million output tokens. \[1] Fast mode runs at 2.5× the speed for $10 per million input and $50 per million output, and Anthropic notes fast mode is now roughly three times cheaper than it was on previous models. \[1] For high-throughput agent workloads, that fast-mode price drop is the line item most likely to change your architecture decisions. Combined with effort controls, you now have two independent knobs, speed and reasoning depth, to tune cost against quality per task instead of per model. The API string is `claude-opus-4-8`. ## The alignment side Anthropic ran its standard pre-release alignment assessment. The team reported that Opus 4.8 reaches new highs on prosocial traits like supporting user autonomy and acting in the user's interest, and that rates of misaligned behavior, deception or cooperation with misuse, are substantially lower than Opus 4.7, landing close to their best-aligned model, Claude Mythos Preview. \[1] For teams shipping AI into regulated or high-stakes domains (legal, healthcare, finance) lower deception rates aren't a feel-good metric. They're a diligence requirement. ## A practical adoption checklist Upgrading a model isn't free even when the price tag is identical. Use these gates before you flip the default: * **Before swapping in production agents:** re-run your own evals. The honesty gains mean you may see *more* flagged uncertainties, which is the point, but it can change downstream control flow. * **Before relying on dynamic workflows:** confirm your test suite is genuinely the bar you want. The feature uses it as ground truth for large migrations. * **Before scaling fast mode:** benchmark quality at the lower price point on your actual tasks, not on a toy example. * **Before tuning effort down:** remember low effort burns rate limits more slowly but reasons less, fine for boilerplate, risky for anything touching trust boundaries. * **Before assuming you're on it:** check your tooling. It's already generally available in GitHub Copilot for Pro+, Business, and Enterprise users, launching with a 15× premium request multiplier until usage-based billing begins June 1, 2026. \[5] ## What's next: Mythos Anthropic also teased what comes after Opus. It plans to release a higher-intelligence class of model, Mythos-class, with Claude Mythos Preview already in the hands of a small number of organizations for cybersecurity work under Project Glasswing. The company says models at that capability level need stronger cyber safeguards before general release, and expects to bring Mythos-class models to all customers in the coming weeks. \[1]\[3] If the honesty improvements in 4.8 are a preview of the safety posture those models will ship with, that's a reasonable trade for the wait. ## The takeaway Opus 4.8 is a modest capability bump wrapped around a meaningful trust improvement. For chat, you'll notice it a little. For autonomous, agentic, long-running work, the direction the whole industry is sprinting toward, a model that knows when to say "I'm not sure" is worth more than a few benchmark points. Treat AI output as scaffolding that still needs inspection. The good news with 4.8 is that the scaffolding is now more likely to tell you which parts it isn't sure about. Use that. Build your evals around it. And keep a human in the loop wherever the cost of being confidently wrong is high. ## Sources 1. Anthropic, "Introducing Claude Opus 4.8," May 28, 2026, [anthropic.com](https://www.anthropic.com/news/claude-opus-4-8) 2. 9to5Mac, "Anthropic upgrades Claude with new Opus 4.8 model, here's what's new," May 28, 2026, [9to5mac.com](https://9to5mac.com/2026/05/28/anthropic-upgrades-claude-with-new-opus-4-8-model-heres-whats-new/) 3. Axios, "Anthropic releases new model, Opus 4.8," May 28, 2026, [axios.com](https://www.axios.com/2026/05/28/anthropic-opus-release-mythos) 4. Yahoo Finance, "Anthropic debuts flagship Claude Opus 4.8 AI model as IPO race with OpenAI heats up," May 28, 2026, [finance.yahoo.com](https://finance.yahoo.com/news/anthropic-debuts-flagship-claude-opus-48-ai-model-as-ipo-race-with-openai-heats-up-170000527.html) 5. GitHub Changelog, "Claude Opus 4.8 is generally available for GitHub Copilot," May 28, 2026, [github.blog](https://github.blog/changelog/2026-05-28-claude-opus-4-8-is-generally-available-for-github-copilot/) 6. Anthropic, "Claude Opus 4.8 System Card," May 28, 2026, [anthropic.com](https://www.anthropic.com/claude-opus-4-8-system-card) *** *Written by* **Syed Moinuddin** Full Stack Engineer. Notes on AI tooling, agentic systems, and building things that survive contact with production. Last updated on May 28, 2026 --- title: "Feature Bento" description: "A bento-style feature grid with corner-decorator cards and a circular UI showcase." last_updated: "May 23, 2026" source: "https://syedmoinuddin.com/blog/feature-bento" --- # Feature Bento A bento-style feature grid with corner-decorator cards and a circular UI showcase. ```tsx import { Calendar, ChevronDownIcon, ChevronLeftIcon, ChevronRightIcon, CircleIcon, type LucideIcon, MapIcon, MoreHorizontalIcon, } from "lucide-react" import type { ReactNode } from "react" import { cn } from "@/lib/utils" import { Card, CardContent, CardHeader } from "@/components/ui/card" export default function FeatureBento() { return (

Smart scheduling with automated reminders for maintenance.

) } interface FeatureCardProps { children: ReactNode className?: string } const FeatureCard = ({ children, className }: FeatureCardProps) => ( {children} ) const CardDecorator = () => ( <> ) interface CardHeadingProps { icon: LucideIcon title: string description: string } const CardHeading = ({ icon: Icon, title, description, }: CardHeadingProps) => (

{title}

{description}

) type PaymentRow = { status: string email: string amount: string done: boolean highlight?: boolean } const PAYMENTS: PaymentRow[] = [ { status: "Success", email: "ken99@yahoo.com", amount: "$316.00", done: true }, { status: "Success", email: "abe45@gmail.com", amount: "$242.00", done: true }, { status: "Processing", email: "monserrat44@gmail.com", amount: "$837.00", done: true, highlight: true, }, { status: "Failed", email: "carmella@hotmail.com", amount: "$721.00", done: false }, ] const PaymentsTableMock = () => (

Payments

Manage your payments.

Filter emails…