标签：#webdev

What I Built Gnoke Books works like an actual printed magazine on a table — you grab the...

Most organizations do not operate a single website. A typical customer journey might move through: company.com ↓ docs.company.com ↓ company-academy.com ↓ company-checkout.com These properties may belong to the same organization, but browsers and analytics systems can treat each domain as a separate visitor and session. Cross-domain measurement is possible with major analytics platforms, but it normally ties the implementation to a specific vendor, transfers an existing measurement identifier through the destination URL, or depends on users authenticating. I built Nylo to explore another approach: Preserve pseudonymous continuity across domains an organization controls, without browser fingerprinting, third-party cookies, or requiring the visitor to log in. Nylo is not intended to identify a person. It is intended to answer a narrower question: Did the same pseudonymous browser journey continue from one authorized domain to another? What Nylo is Nylo consists of: A zero-dependency JavaScript client SDK A server-side event ingestion interface A pseudonymous identifier called a WaiTag A short-lived cross-domain token exchange DNS-based verification of participating domains Configurable event collection Storage adapters for different backend systems The core analytics SDK is available under the MIT License. Production commercial use of the cross-domain WTX-1 functionality uses a separate commercial license. Nylo is designed to function as an analytics collection and continuity layer. It can eventually send events to an existing warehouse or analytics platform rather than requiring organizations to replace their reporting stack. How continuity works Consider a visitor moving between two independently registered domains: Visitor opens site-a.com | v Nylo creates a pseudonymous WaiTag | v Visitor follows an authorized link | v A short-lived token is transferred | v site-b.com verifies the token | v Both events reference the same pseudonymous journey Before enabling cross-d

What are Semantic Tags? When we create a webpage, we don't just want it to look good. We also want the browser and other developers to understand what each part of the page is. This is where semantic tags help us. The word semantic means having meaning. These tags describe the purpose of the content instead of just creating a box like a <div> . Common Semantic Tags HTML provides different semantic tags for different parts of a webpage. <header> – Used for the top section of the webpage. <nav> – Contains navigation links like Home, About, and Contact. <main> – Holds the main content of the webpage. <section> – Groups related content together. <article> – Used for a complete piece of content like a blog or news article. <aside> – Contains extra information such as related links or advertisements. <footer> – Used for the bottom section of the webpage, usually containing copyright or contact details. Why Semantic Tags? Semantic tags make HTML code clean and easy to read. When another developer opens the code, they can quickly understand the structure of the webpage. Search engines like Google can also understand the content better, which helps with SEO. They also improve accessibility because screen readers can identify different sections of the webpage and help visually impaired users navigate the page more easily. Instead of using many <div> tags everywhere, semantic tags make the code more meaningful and easier to maintain.

How to Add a Real-Time Search Layer to an Agent Graph Agent frameworks make it easier to build systems that can plan tasks, call tools, maintain state, and decide what to do next. But a well-designed workflow can still produce a confidently structured wrong answer. The graph may execute exactly as expected while relying on information that is outdated, incomplete, duplicated, or difficult to verify. This becomes especially noticeable when an agent handles recent news, product information, market research, academic research, or other knowledge-intensive tasks. One way to address this is to treat real-time search as a shared evidence layer inside the agent graph. In this article, I will break down a practical architecture for doing that. Disclosure: This article uses Cloudsway SmartSearch as one implementation example. The overall architecture is provider-agnostic and can work with other search APIs that return structured results and source metadata. The Difference Between an Agent Loop and an Agent Graph A basic tool-using agent often follows a loop: Reason ↓ Choose a tool ↓ Observe the result ↓ Decide what to do next This pattern works well for relatively simple tasks. As the number of tools, branches, and stopping conditions grows, however, the system prompt may begin carrying too much responsibility. It must describe the tools, maintain context, control branching, evaluate results, and decide when the task is complete. An agent graph makes that control flow explicit. Instead of asking one model to manage the entire process, the workflow can be divided into nodes such as: User Request ↓ Router ↓ Query Planner ↓ Search ↓ Source Verification ↓ Answer Generation Each node has a narrower responsibility. The router decides whether external information is required. The planner creates focused search queries. The search node retrieves evidence. The verifier evaluates the quality of that evidence. The final node generates an answer from the verified sources. If the evidenc

As software engineers, our default setting is often to over-engineer. When tasked with building a web utility—such as an image sorter or a layout planner—our minds immediately jump to designing a complete backend ecosystem. We start sketching out PostgreSQL schemas, configuring AWS S3 bucket lifecycles for user uploads, setting up Redis caches, and writing authentication middleware. While this architecture is robust, it introduces massive overhead: Financial Cost: Database queries and S3 egress fees scale with your user base. Maintenance Burden: Keeping server packages updated, managing API endpoints, and handling database backups. Legal Compliance: Storing user-uploaded files means dealing with GDPR, CCPA, and data privacy regulations. When I started building Rankly, an online Tier List Maker, I challenged myself to eliminate the backend entirely. I wanted to build a high-performance web tool capable of scale, with a server hosting bill of exactly $0/month, while giving users complete privacy. Here is a technical deep dive into how we built a stateless, zero-database frontend architecture that processes complex image grids entirely client-side. Traditional tier list tools follow a client-server-client round-trip pattern: User uploads images -> Sent to server. Server saves to S3 -> Returns public URLs. User drags/drops -> State saved to database via JSON payload. Export -> Server-side headless browser (like Puppeteer) renders the page and takes a screenshot -> Sent back to user. This pattern is slow and highly resource-intensive. Rankly completely bypasses the server by implementing an entirely local-first rendering pipeline. [Local File Upload/Drag] │ ▼ (FileReader API / Object URL) [Local Memory State (React/State)] ───► [Interactive Grid UI (Tailwind)] │ ▼ (HTML5 Canvas Synthesis) [Local Client-Side Render] ───► [High-Res PNG Download] To let users use their own images without uploading them to a remote server, we utilize the HTML5 File API. When a user drags and

Hello world, it's Wednesday, August 5, 2026, and here's what happened This Week in PHP Internals. 13 stories this week, so let's get into it. But first, This week's episode is brought to you by Tideways . When a request is slow in production, Tideways takes you from symptom to root cause in minutes, with profiling, tracing, and monitoring built specifically for PHP. It installs in 5 minutes, there's no credit card required, and it's hosted in Germany. Start your free trial at tideways.com . This week's top story: the mass deprecation vote for PHP 8.6 is in its final week. All 35 ballots close Monday , August 10, and Gina P. Banyard posted the 1-week reminder so nobody gets caught out. Most of the 35 are passing comfortably. The interesting ones are the holdouts. list() is now deadlocked at 21 to 21 — a flat tie, nowhere near the 2/3 it needs. Reserving let stands at 22 to 11, which is exactly two-thirds — a single vote in either column decides it. The dechunk filter sits at 17 to 15 — still well short. The gettext _() alias is failing at 9 to 20, and reserving in , out , and inout is failing at 7 to 20, with 12 abstentions. Everything else you'd recognize from the list — the object-parameter cleanups, the is_double() family, spl_classes() — is cruising toward the finish. The thread itself turned into a corrections desk this week. Calvin Buckley relayed a note from Nora, who isn't on the list, pointing out: "The text for the metaphone deprecation isn't fully right. It lists \"linguistics\" as a replacement package, but that one actually uses php-src's metaphone internally too." Weilin Du, who proposed that item, conceded the docs point while standing by the idea, writing: "My point in deprecating it is to stop using ancient metaphone algo as a whole." Voters seem unbothered — metaphone stands at 19 to 6, with 15 abstentions. Rowan Tommins raised a bigger flag on reserving is : it would collide with Hamcrest, the test assertion framework, whose PHP port has 500 millio

For a side project, the short answer is: Cloudflare Pages if you want the cheapest ceiling and never think about bandwidth, Vercel if you're on Next.js and want the smoothest developer experience, Netlify if you want a mature all-in-one with forms and identity baked in. All three have a free tier that will host a hobby app fine. The differences that actually bite you show up later — when a post gets traffic, when your build gets slow, or when you outgrow static files and start running server code. I've deployed personal projects on all three over the last couple of years. Below is how I'd choose today, with the real trade-offs rather than the marketing version. What are you actually deploying? Before comparing platforms, be honest about your app, because it changes the answer more than any feature chart: Pure static site (docs, a marketing page, a SPA that talks to an external API): all three are excellent and free. The decision barely matters. Static frontend + a few serverless functions (a contact form handler, an auth callback, a small API): now runtime, cold starts, and function limits matter. A full framework app with server rendering (Next.js App Router, SvelteKit, Remix): now framework-specific adapters and edge/runtime compatibility matter a lot. The takeaway: pick based on your heaviest workload, not your current one — migrating hosts after you've wired up auth and functions is the annoying part. How do the free tiers really compare? This is where these platforms differ the most for hobby use. The headline distinction, as of mid-2026: Cloudflare Pages does not meter bandwidth on its free plan , while Vercel and Netlify both count usage (bandwidth, function invocations, build minutes) against free-tier limits and will ask you to upgrade — or throttle — when you cross them. Concern Vercel (Hobby) Netlify (Free) Cloudflare Pages (Free) Bandwidth Metered, capped Metered, capped Unlimited Build minutes Limited Limited Limited (per-month build count) Serverless/e

AI photo editors look simple from the outside: upload an image, describe a change, and download the result. The hard part is everything around the model call. If you are building or evaluating a browser-based image editor, the workflow needs to protect the original file, reject bad inputs early, make retries safe, and help the user compare the result with the source. This article walks through a small implementation pattern that does that without turning the UI into a complex desktop editor. 1. Validate the image before upload Do not rely on the file extension. Check the MIME type, file size, and whether the browser can actually decode the image. const ACCEPTED_TYPES = new Set ([ " image/jpeg " , " image/png " , " image/webp " , ]); async function validateImage ( file ) { if ( ! ACCEPTED_TYPES . has ( file . type )) { throw new Error ( " Use a JPG, PNG, or WebP image. " ); } const maxBytes = 10 * 1024 * 1024 ; if ( file . size > maxBytes ) { throw new Error ( " The image must be smaller than 10 MB. " ); } const bitmap = await createImageBitmap ( file ); const dimensions = { width : bitmap . width , height : bitmap . height }; bitmap . close (); if ( dimensions . width < 64 || dimensions . height < 64 ) { throw new Error ( " The image is too small for a useful edit. " ); } return dimensions ; } This catches renamed files, broken images, and tiny inputs before they consume bandwidth or model credits. 2. Treat the prompt as a single edit contract Open-ended chat is useful, but it can make image editing unpredictable. A clearer UI asks for one concrete change at a time: remove the person on the right; replace the background with a plain white wall; repair the crease across the top-left corner; extend the image to a 16:9 frame. The request object should preserve that intent without mixing it with UI state: function buildEditRequest ( file , prompt , options = {}) { const normalizedPrompt = prompt . trim (). replace ( / \s +/g , " " ); if ( normalizedPrompt . length < 5 )

Hi guys, I'm a 2026 fresher. I'm confused about choosing between Java, Python, .NET, and MERN. Is Full Stack still worth learning with AI growing so fast? Can a skilled fresher still get a job? Any advice?

TypeScript Strict Null Checks in 2026: Real-World Patterns for Handling undefined Without the Noise This article was written with the assistance of AI, under human supervision and review. Most TypeScript null safety problems stem from teams treating strictNullChecks as a boolean toggle instead of a design constraint. The compiler flag eliminates an entire class of production bugs, but codebases that flip it on without adjusting their patterns end up drowning in type assertions and optional chaining operators. The result is worse than the original false confidence wrapped in noise. The fundamental issue is that JavaScript conflates absence and failure. A missing property, an API error, and an uninitialized variable all return undefined or null , but they represent completely different failure modes. When teams enable strictNullChecks without encoding these distinctions into their types, the compiler forces them to handle every potential undefined the same way. That leads to defensive checks that obscure intent and catch nothing of value. The correct approach treats null safety as a type design problem. Discriminated unions encode why a value is missing. Branded types prove non-nullability at the boundary. Type guards narrow only when the business logic demands it. The patterns are simple, but they require understanding what the compiler is actually checking and what guarantees your code actually needs. This post covers the essential patterns teams need to write null-safe TypeScript in 2026 without the noise. Apply these in production and the difference will be immediate. Key Takeaways strictNullChecks eliminates runtime null errors only if your types encode why values are missing, not just that they might be missing. Discriminated unions outperform null returns for API responses because they force exhaustive handling of failure cases at compile time. Non-null assertions ( ! ) are acceptable at proven boundaries where external systems guarantee non-null values, but ne

Bridging Design and Code to Empower Local Businesses As a full-stack developer specializing in JavaScript and React, one of the most exciting ventures I'm currently on is building ready-made websites and Next.js templates through Softchic. This isn't just about coding; it's about deeply understanding the needs of businesses, particularly within the vibrant and rapidly evolving Nigerian market, and translating those into high-performance, beautiful web solutions. Why Next.js? Performance, SEO, and Developer Experience My choice of Next.js as the primary framework for these templates was deliberate: Performance: Server-side rendering (SSR) and static site generation (SSG) capabilities are crucial. In areas where internet speeds might vary, a fast-loading website isn't just a nice-to-have; it's essential for user retention and conversion. SEO: For businesses looking to establish a strong online presence, robust SEO capabilities out-of-the-box mean our templates provide a solid foundation for discoverability. Developer Experience: Building with Next.js allows for efficient development, leveraging the power of React while simplifying routing, data fetching, and API routes. This means faster iteration and higher quality templates. The Nigerian Market: Unique Challenges, Immense Opportunity Crafting templates specifically for the Nigerian market presents a fascinating set of considerations: Design Aesthetics: Understanding local preferences in terms of color palettes, layouts, and user flows is critical. It's not just about what looks good globally, but what resonates locally. This is where my dual role as creative director for promotional materials comes into play – applying that eye for design directly to the templates. Mobile-First Mentality: A significant portion of internet users in Nigeria access the web via mobile devices. Every template is meticulously designed with a mobile-first approach to ensure optimal responsiveness and user experience on smaller screens. Aff

I run 75 scrapers in production. Three of them do any fingerprint spoofing. Maybe five use residential proxies. The rest run on plain datacenter IPs or no proxy at all, and they have been running for months. If you learned scraping from blog posts, that number probably sounds wrong to you. Every tutorial you have read starts the same way: sign up for a residential pool, install a stealth browser, randomize your fingerprint, throttle like a human. Then, on step five, you finally get to look at the actual website. That order is backwards, and it is backwards on purpose. Proxy companies write most of the scraping content on the internet. They were never going to write "you probably do not need us." The scraper with the $80 a month costume Last month my guy sent me his Greenhouse job board scraper to fix. It had everything. Puppeteer with the stealth plugin. Rotating residential proxies. Randomized mouse movements between actions. Human-like typing delays. It still kept dying. So I did the thing nobody had done: opened the page in a normal browser with devtools up. The entire job list was sitting in one XHR request to a public JSON endpoint. No auth. No cookies. A rate limit so loose I never managed to hit it. I deleted basically his entire codebase and replaced it with a fetch call. It has not broken since. He had been paying for proxies for months to hit an endpoint that does not care who you are. This was not a rare lucky case. This is most cases. The 20 minute method What I do on every new target, before writing a single line of code: Open the network tab, filter to XHR/fetch. Reload the page. Click around. Paginate. Search. Find the request that returns the actual data. It is usually JSON and usually obvious. Right click, copy as cURL. Paste it in a terminal and start deleting headers one at a time. Rerun after each delete. Whatever survives step five is your scraper. Most of the time the answer is a user agent header and nothing else. Sometimes a referer. Occasion

Here's the problem. Every AI coding agent (Cursor, Codex, Claude Code, whatever) is trained on millions of websites. Most of those websites are average. So when you prompt "build me a landing page," the model gives you the average of everything it's seen: a centered hero, a purple gradient, three equal feature cards, Inter font, ease-in-out , done. It's not broken. It's just mediocre by default. I'm 17 and I got tired of fighting this in every conversation. So I built VibeCurb : a collection of strict constraint skill files, that force AI agents to actually think about design before they touch code. How it works Every skill follows the same four-phase pipeline: Design Read - The agent reads your reference image, existing codebase, or brief and extracts design signals: typography, palette, layout, focal element, spacing. No code is written here. Quality Gate - The extraction has to pass before the agent is allowed to generate anything. It must prove it understands the design direction, not just spit out defaults. Precise Build - Code generation happens against the extraction, not against the model's built-in idea of what a "website" looks like. Each skill has its own build sequence. Visual Diff - The output is checked against the reference using PASS/FAIL tables across composition, typography, color, motion, and responsiveness. If it drifts, it gets caught. There's also an inline drift rejection layer. It catches known AI defaults (CSS keyword easings like ease-in-out , AI-purple #7c3aed gradients, generic glassmorphic cards, placeholder Lorem ipsum content) and flags them before they make it into the output. The skills Each skill constrains a specific problem space: awwwards-hero - Hero sections only. Six documented architectures (Cinematic Center, Editorial Split, etc.) with implementation blueprints. The agent picks one and commits. awwwards-sections - Pricing tables, bento grids, feature highlights, footers. Same pipeline, different element constraints. awwwards-

If you've ever needed to let a third-party service talk to your local dev environment, you've probably reached for ngrok. I've been moving some of that over to Tailscale Funnel instead — here's what works, what broke, and how it stacks up against Cloudflare Tunnel. Key takeaways Tailscale Funnel exposes a local dev server to the public internet, similar to ngrok or Cloudflare Tunnel — useful for testing webhooks, payment callbacks, or anything a third party needs to reach on your machine. It's free for solo/small use, with no device limit on the Personal plan (up to 6 users). tailscale serve is tailnet-private; tailscale funnel is what actually makes something public — easy to mix up. Getting it working behind Caddy + Symfony in Docker means fixing two separate redirect loops (one from Symfony, one from Caddy's own auto-HTTPS) and explicitly telling Symfony to trust the proxy. The one real trade-off versus Cloudflare Tunnel: no custom domain with a valid cert — you're stuck with the ts.net hostname unless you accept a browser cert warning. This isn't a "ngrok / local tunnel / Cloudflare tunnel is bad" post. It's a "here's another tool that does the same job, and here's exactly what broke when I set it up" post. Why bother? A few reasons I looked at Tailscale instead of just defaulting to ngrok again: Stable hostname. ngrok's free tier gives you a random URL that changes every time you restart it. Tailscale Funnel gives you a fixed hostname tied to your machine ( your-machine.your-tailnet.ts.net ) that doesn't change. Genuinely free for solo/small use. Tailscale's free Personal plan covers up to 6 users with no device limit at all — plenty for a solo dev juggling a laptop, a desktop, and a couple of test machines. No "3 device" ceiling to bump into. Already in my toolchain. I use Tailscale for other things, so there's no new account, no new pricing tier to think about. Automatic HTTPS. Tailscale handles certificate provisioning for you — no separate cert step. The tr

TL;DR MCP servers are powerful, but they can provide access to production systems if...

Wiremodal is a framework-agnostic modal package for Laravel, which allows to handle modals, so you don't have co configure them in all your projects. It ships a few Livewire-side helpers that make exactly this pleasant. This post is the Livewire integration end to end: opening and closing from PHP, delivering a payload on open, the one trap to avoid, and the optional form panel for when a modal happens to be a form. How to install Pull the package in and get the assets onto the page. composer require edulazaro/wiremodal php artisan vendor:publish --tag = wiremodal-assets The service provider auto-registers and there is no config file. Point your layout at the published files: <link rel="stylesheet" href="{{ asset('vendor/wiremodal/css/wiremodal.css') }}"> <script src="{{ asset('vendor/wiremodal/js/wiremodal.js') }}" defer></script> If you bundle with Vite, skip the publish and import straight from the vendor directory instead, so a package update flows through without re-publishing anything: /* resources/css/app.css */ @import "../../vendor/edulazaro/wiremodal/resources/css/wiremodal.css" ; // resources/js/app.js import ' ../../vendor/edulazaro/wiremodal/resources/js/wiremodal.js ' ; Opening and closing from Livewire Define the modal once with the <x-wiremodal> component, give it a name , and fill the body and footer slots. Here is a delete confirmation: <x-wiremodal name="confirm-delete" title="Delete record?" size="sm"> <x-slot:body> <p>This action cannot be undone.</p> </x-slot:body> <x-slot:footer> <button type="button" data-wm-dismiss>Cancel</button> <button type="button" wire:click="destroy">Delete</button> </x-slot:footer> </x-wiremodal> The Cancel button carries data-wm-dismiss , and any element with that attribute closes the modal it sits in, so you never write a cancel handler. To open and close from the component itself, use the macros the package registers on every Livewire component: public function confirmDelete (): void { $this -> openModal ( 'confirm

A visitor lands on a website and immediately sees prices in the wrong currency, content written for another region, and shipping information that does not apply to them. Nothing is technically broken, yet the experience feels poorly designed. For international websites, location can be a useful personalization signal. Instead of asking every visitor to manually select a country before displaying relevant information, developers can use IP based geographic data as an initial indication of where a request originates. That is where ip geolocation for content personalisation can become useful. The objective is not to identify a person. It is to make an otherwise anonymous visit more contextually relevant. How can location improve content personalisation? Location can influence many small decisions that collectively affect the user experience. An ecommerce website may display a local currency. A news publisher may surface regional stories. A software company may show country specific documentation or availability information. The process is relatively simple. A visitor sends a request to a website. The server obtains the request's public IP address. That IP is sent to a geolocation service. The response provides geographic information. The application then selects content according to predefined rules. The crucial part is the final step. Geolocation provides data, but business logic determines what the visitor actually sees. Which approaches can websites use? One approach is manual location selection. The user chooses their country or region from a menu. This is transparent and usually accurate because the user explicitly provides the information. However, it adds friction and may be forgotten during future visits. Browser based location is another option. It can provide more precise positioning, but it normally requires permission and is not always appropriate for simple content personalization. IP based geolocation sits between these approaches. It requires no location

Sites that start from a stock theme tend to look like it. This one did too — until recently it was the default PaperMod screen. The editorial homepage and unified article styling you're looking at came out of a single day of customization. This guide is that work written down, with the code. One principle drove all of it: never fork the theme. The theme stays a submodule and keeps receiving updates; you win with site-level files only. Hugo resolves same-path site files ahead of theme files, which makes this possible. The entire customization of this site is a handful of files: layouts/index.html ← full homepage replacement data/home/ko.yaml, en.yaml ← homepage copy (per language) assets/css/extended/home.css ← homepage styles assets/css/extended/custom.css ← unifying every other page The starting point is a Hugo site with PaperMod as a submodule, deployed to GitHub Pages. Basic installation is well covered by the PaperMod wiki , so I'll skip it. 1. Replace the homepage wholesale Create a single layouts/index.html and the homepage is yours. The theme's home template stays untouched. The key move: don't hardcode copy into the markup — pull it from data files. On a bilingual site, one template then serves both languages: {{- $copy := index .Site.Data.home .Site.Language.Lang -}} {{- $posts := first 4 (where .Site.RegularPages.ByDate.Reverse "Section" "blog") -}} <section class= "editorial-hero" > <p class= "editorial-eyebrow" > {{ $copy.hero.eyebrow }} </p> <h1> {{ range $i, $line := $copy.hero.titleLines }}{{ if $i }} <br> {{ end }}{{ $line }}{{ end }} </h1> <p class= "editorial-intro" > {{ $copy.hero.intro }} </p> </section> data/home/en.yaml holds nothing but words: hero : eyebrow : " IDEAS · PRODUCTS · OPPORTUNITIES" titleLines : - " Where ideas become products," - " and products become new opportunities." Copy edits stop requiring template changes, and adding a language is one more yaml file. Latest posts are pulled dynamically as above — handle the {{ else }} emp

A demo Andrej Karpathy posted over the weekend stuck with me. He gave Opus 5 a million-token context and the first paragraph of The Lord of the Rings, and asked for a procedural 3D rendering of the scene in Three.js. The model worked alone for about two hours, wrote 5,500 lines, and coordinated polygon placement, camera paths, and animation on its own. Total cost: about $10. The result is faster to watch than to describe. Most reactions read it as the next step past "draw a pelican SVG" benchmarks. Something else looked bigger to me. What changed isn't the model's artistry. It's the unit of delegation. The unit of delegation changed Until now, the work we handed agents came in prompt-sized pieces. One function, one bug, one file. Anything bigger, we decomposed ourselves. The reason was simple: with a small context, the early parts of a long job slide out of view, and coherence goes with them. A million tokens erases that premise. Everything the model wrote and tried across a two-hour session stays in view. When the desk is big enough, there is no reason to hand work over in slices. Delegation moves from the task to the session. That is the difference between a function call and a work session. The first, we decompose and supervise. The second, we hand over material and intent, and receive a result. Karpathy's entire contribution was picking the paragraph and watching the output two hours later. Where the builder's work moves When execution costs $10 and two hours, execution is no longer the bottleneck. Two things remain. On the way in: the brief. What goes into the context. Karpathy's input was one paragraph, but choosing it was the design act. Translated to our work, it becomes choosing which spec, brand guide, reference, or codebase goes in whole — and what stays out. On the way out: judgment. By what standard do you accept the result? Reviewing 5,500 lines one by one doesn't match session-sized delegation. Instead, you define "done" before the run, then judge the

Graphical tools are great, but most of my daily development now happens in the terminal. A good CLI tool saves time, integrates with automation, and keeps my workflow consistent across local development and CI/CD. Here are the 10 CLI tools I use the most. Apidog CLI If you're working with APIs, this is the tool I've found myself using the most. I use it to run API test scenarios, manage environments, and reuse the same tests in GitHub Actions instead of maintaining separate GUI workflows. Git Still the foundation of every development workflow. Docker CLI The fastest way to spin up local services and reproduce production environments. GitHub CLI Creating pull requests, reviewing issues, and managing repositories without leaving the terminal is a huge productivity boost. HTTPie Perfect for quick API requests when debugging or exploring endpoints. jq If you work with JSON every day, jq is almost indispensable. ripgrep (rg) Lightning-fast code searching. Once you start using it, it's hard to go back. fd A simpler and faster replacement for the traditional find command. kubectl Essential for anyone deploying applications to Kubernetes. just A lightweight task runner that helps automate repetitive development commands. Final Thoughts The biggest improvement to my workflow has been moving repetitive tasks into the terminal. API testing, deployments, version control, and automation all become easier when everything is scriptable. Among these tools, Apidog CLI has had the biggest impact because it lets me keep API testing in the same terminal-first workflow that I already use for development and CI/CD. What CLI tool couldn't you live without?