{"articles":[{"id":37,"documentId":"vtdxydanyk44pjf9bmm4h0ga","title":"My Spec-Driven Development Experience: Building a Next.js and Nest.js Full-Stack Project","description":"Workflow-first development, AI-assisted coding, and systematic specifications","slug":"my-spec-driven-development-experience-building-a-next-js-and-nest-js-full-stack-project","content":"*How I transformed [copilot-proxy](https://hankchiu.tw/writings/copilot-proxy-your-free-llm-api-for-local-development/) into a modern full-stack application [Coxy](https://github.com/coxy-proxy/coxy) using workflow-first development, AI-assisted coding, and systematic specifications*\n\n\nRecently I tried spec-driven development to build [Coxy](https://github.com/coxy-proxy/coxy), a complete rewrite of my previous [copilot-proxy](https://hankchiu.tw/writings/copilot-proxy-your-free-llm-api-for-local-development/) project. The experience taught me valuable lessons about modern development workflows, AI integration, and sustainable architecture decisions. Here's why I made the switch, how I approached it, and what I learned along the way.\n\n## Why I Rewrote copilot-proxy\n\n### Technical Limitations of the Original Project\n\nThe original copilot-proxy was built with SolidStart, which seemed like a good choice initially but created several challenges:\n\n**Framework Maturity Issues**: SolidStart is lightweight and performant, but its ecosystem isn't as mature as Next.js. I spent considerable time debugging build processes and working around framework limitations instead of focusing on features. The time investment in tooling troubleshooting outweighed the framework's benefits.\n\n**Monolithic Architecture Problems**: I had combined frontend and backend implementations in a single codebase, which initially seemed efficient but quickly became messy. As the proxy management features grew more complex, maintaining clear separation between API logic and UI components became increasingly difficult. This architectural decision made testing, deployment, and scaling problematic.\n\n**Development Experience Friction**: The build process was unpredictable, dependency management was complex, and the development workflow felt fragmented. These friction points slowed down iteration cycles and made the project less enjoyable to work on.\n\n### The Opportunity for Spec-Driven Development\n\nBeyond addressing technical limitations, I wanted to experiment with spec-driven development methodology. This approach promised several advantages:\n\n- **Clearer requirements definition** before writing code\n- **Better AI collaboration** through structured prompts and specifications\n- **More maintainable architecture** with documented decision rationales\n- **Systematic approach to feature development** reducing scope creep\n\nThe rewrite presented a perfect opportunity to implement these methodologies from the ground up, rather than retrofitting them onto existing code.\n\n## My Spec-Driven Development Strategy\n\n### Workflow-First Philosophy: Avoiding Vendor Lock-in\n\nMy core strategy focused on **development workflow optimization** rather than tool selection. This philosophy aimed to avoid vendor lock-in with specific AI tools like Cursor or Claude Code, which can limit flexibility as new tools emerge.\n\n**Key principles I established:**\n\n- **I determine the workflow**, tools adapt to serve the workflow\n- **Documentation drives implementation**, not the reverse\n- **Tool-agnostic specifications** enable switching between AI assistants\n- **Modular architecture** supports different development approaches\n\nThis approach meant investing time upfront in workflow design, knowing that I could optimize tool choices later without restructuring the entire development process.\n\n### Benefits of Workflow-First Development\n\nThe workflow-first approach delivered three key wins: cleaner architecture through upfront planning, faster debugging with systematic processes, and easy tool switching when better options emerged.\n\n## Implementation: From Architecture to Features\n\n### Nx Monorepo: Scalable Project Structure\n\nI chose Nx as the foundation for Coxy's architecture, primarily to achieve clean separation between frontend and backend concerns that plagued the original copilot-proxy.\n\n**Strategic architecture decisions:**\n\n```\ncoxy/\n├── apps/\n│ ├── frontend/ # Next.js frontend\n│ ├── backend/ # Nest.js backend\n│ └── frontend-e2e/ # End-to-end tests\n├── libs/\n│ ├── shared/ # Cross-platform utilities\n│ ├── ui/ # React component library\n│ ├── logger/ # Centralized logging\n│ └── types/ # TypeScript definitions\n└── ...\n\n```\n\n**Why this structure worked for Coxy:**\n\n- **Clear boundaries** between proxy management UI and API logic\n- **Shared libraries** eliminated code duplication across apps\n- **Independent deployments** for frontend and backend services\n- **Scalable foundation** supporting future microservices architecture\n\n### Tooling Optimization: Biome Over ESLint/Prettier\n\nI replaced ESLint and Prettier with Biome for better performance and simpler configuration. Biome reduced setup complexity by 70%, improved build times, and required fewer dependencies to manage. The migration was straightforward with immediate performance benefits.\n\n### Spec-Driven Development: USER_STORY.md Files\n\nFollowing spec-driven development principles, I created comprehensive USER_STORY.md files for each Coxy feature. These documents became the foundation for all development activities.\n\n**Example for proxy configuration management:**\n\n```markdown\n # User Story 1: OpenAI-Compatible Proxy Endpoint\n \nAs a developer using OpenAI-compatible tools, I want to send requests to a proxy server that forwards them to GitHub Copilot so that I can use GitHub Copilot through existing OpenAI-compatible interfaces.\n \n ## Acceptance Criteria (EARS):\n \n - **Given** a valid OpenAI-compatible request, **when** sent to `/chat/completions`, **then** forward to GitHub Copilot API.\n - **Given** an invalid API key, **when** making a request, **then** return `401 Unauthorized`.\n - **Given** a malformed request, **when** sent to the proxy, **then** return `400 Bad Request` with validation errors.\n - **Where** the system acts as a transparent proxy between OpenAI clients and GitHub Copilot.\n \n ---\n \n # User Story 2: Admin Dashboard\n \n As a system administrator, I want an admin interface to monitor and configure the proxy so that I can manage API usage, view logs, and configure settings.\n \n ## Acceptance Criteria (EARS):\n \n - **Given** admin credentials, **when** accessing `/admin`, **then** display dashboard with usage statistics.\n - **Given** proxy requests, **when** they occur, **then** log them for admin review.\n - **Given** configuration changes, **when** submitted through admin panel, **then** update proxy behavior.\n - **Where** admin access is protected by authentication.\n\n```\n\n### Project-Wide System Prompt: Development Constraints\n\nI created a comprehensive system prompt that served as both a constraint and development guideline for AI assistance throughout the project:\n\n```\n# Nx Project Refactoring System Prompt\n\n## 1. Persona\nYou are a senior software architect and Nx expert with extensive experience in monorepo management, dependency optimization, and large-scale refactoring. You have deep knowledge of:\n- Nx workspace architecture and best practices\n- TypeScript/JavaScript ecosystem and tooling\n- Micro-frontend and library design patterns\n- Build optimization and dependency graph management\n- Code migration strategies for monorepos\n\n## 2. Task Statement\nAnalyze and refactor code within an Nx workspace to improve maintainability, performance, and adherence to Nx best practices while preserving functionality and minimizing breaking changes.\n\n## 3. Context\nYou are working within an Nx monorepo that may contain:\n- Multiple applications (React, Angular, Node.js, etc.)\n- Shared libraries and utilities\n- Complex inter-project dependencies\n- Existing build configurations and tooling\n- Team conventions and coding standards\n- CI/CD pipelines that depend on the current structure\n\n```\n\nThis system prompt ensured consistency across different AI tools and development sessions.\n\n## AI-Enhanced Development Workflow\n\n### Structured LLM Prompt Guidelines\n\nI developed a systematic approach to creating feature-specific prompts using \"Structured LLM Prompt Guidelines.\" This meta-process involved:\n\n**Prompt creation workflow:**\n\n1. **Analyze USER_STORY.md** to extract key requirements\n2. **Feed Structured LLM Prompt Guidelines to Claude** for refinement\n3. **Generate feature-specific prompts** tailored to proxy management needs\n4. **Test prompts across different AI tools** for consistency\n\n**Example Structured LLM Prompt Guidelines (partial):**\n\n```markdown\n# Structured LLM Prompt Guidelines\n\n## 1. Persona\nSpecify the role, expertise, or point of view you want the model to adopt.\n\n_Example:_\n> You are a senior frontend developer experienced in React and TypeScript.\n\n## 2. Task Statement\nClearly define the main objective or requirement of your prompt.\n\n_Example:_\n> Implement a reusable modal dialog component for a web application.\n\n## 3. Context\nProvide relevant background information, project details, or the scope of application to ensure the model understands nuances and boundaries.\n\n_Example:_\n> The component will be used across multiple pages in a SaaS dashboard built with React, styled using Tailwind CSS, and should support ARIA accessibility attributes.\n\n```\n\n**Example feature prompt for chatting feature (partial):**\n\n```markdown\n# AI Chat Feature Implementation Prompt\n\n## 1. Persona\nYou are a senior React/Next.js developer specializing in real-time chat interfaces and conversational UX design. You have extensive experience building intuitive messaging systems with optimistic UI updates and seamless user experiences.\n\n## 2. Task Statement\nImplement the AI chatting feature with a centered input box on the main page that transitions to a dedicated chat session page after the first message is sent, supporting continuous conversation flow with follow-up messages.\n\n## 3. Context\nThis is part of a larger AI chatbot SaaS application built with Next.js 15, TypeScript, and Tailwind CSS. The chat feature should provide a smooth, intuitive experience where users start with a prominent input box and seamlessly transition into a full conversation interface. The system integrates with an external AI API and uses Clerk for authentication. Users should feel like they're having a natural conversation with instant feedback and proper message handling.\n```\n\n### Multi-Tool AI Implementation Strategy\n\nI used Rovo Dev and Gemini CLI as primary implementation tools, chosen for their modern LLM models and generous free quotas.\n\n**Development workflow:**\n\n1. **Plan Review**: AI generates implementation plan based on USER_STORY.md\n2. **Architecture Validation**: Manual review ensures alignment with Nx structure\n3. **Iterative Implementation**: Code generation with frequent human oversight\n4. **Bug Resolution**: Systematic debugging using AI assistance\n\n**Why this multi-tool approach worked:**\n\n- **Cross-validation** reduced AI hallucinations in complex scenarios\n- **Tool-specific strengths**: Rovo Dev excelled at backend logic, Gemini CLI at frontend components\n- **Flexibility**: Could switch tools based on feature requirements\n- **Learning opportunity**: Compared AI tool capabilities across different use cases\n\n### Documentation Synchronization Strategy\n\nA crucial aspect of the workflow was keeping specifications synchronized with implementation:\n\n**Periodic documentation updates:**\n\n- **Manual analysis** where AI reviewed current code against specifications\n- **Automatic detection** of specification-implementation gaps\n- **Document updates** reflecting architectural decisions and lessons learned\n- **Prompt refinement** based on implementation experience\n\nThis process ensured that specifications remained valuable throughout the development lifecycle.\n\n## Lessons Learned: What Worked and What Didn't\n\n### What Worked Well\n\n**Top-down understanding transformed my development approach.** Spec-driven development forced systematic thinking about requirements and architecture before implementation, leading to better decisions and more cohesive features.\n\n**AI revealed unknown unknowns during planning.** When creating proxy management specifications, AI identified edge cases, security considerations, and performance optimizations I hadn't considered, leading to more robust implementations.\n\n**Structured specifications accelerated development.** Comprehensive USER_STORY.md files enabled AI tools to generate higher-quality initial code. Time invested in specifications paid dividends through faster iteration and fewer bugs.\n\n### Challenges That Required Adaptation\n\n**Tool switching created mental overhead.** Managing different AI tools required energy that could have been spent on development. I learned to batch similar tasks within single tools.\n\n**Documentation became a project itself.** Organizing specifications and prompts required dedicated time and systematic approaches. Templates and naming conventions helped manage this complexity.\n\n**Costs accumulated quickly.** AI tool quotas sometimes were exhausted faster than expected. The convenience came with real monetary costs that needed project planning consideration.\n\n## Next Steps: SpecKit and Beyond\n\nGitHub SpecKit offers exciting opportunities to formalize my spec-driven approach. I plan to explore SpecKit integration for native GitHub workflow management, automated documentation generation, and standardized specification formats.\n\nFor future projects, I'll focus on systematic prompt management with version-controlled prompt libraries, performance tracking, and automated testing. The goal is creating repeatable processes that scale across different projects and team members.\n\n## Conclusion: Growing with AI, Not Surrendering to It\n\nBuilding [Coxy](https://github.com/coxy-proxy/coxy) with spec-driven development taught me that AI collaboration works best when humans maintain architectural ownership while leveraging AI for implementation speed. Rather than giving complete control to AI tools, the spec-driven approach helped me grow alongside AI capabilities.\n\nThe key insight: systematic approaches scale better than ad-hoc AI usage. Structured prompts, comprehensive specifications, and organized workflows produce more consistent results than spontaneous AI interactions. Documentation remains critical while AI generates code quickly, human-created specifications ensure that code serves actual business requirements.\n\nThe transformation from copilot-proxy to [Coxy](https://github.com/coxy-proxy/coxy) represents more than a technology upgrade. It demonstrates how thoughtful AI integration with systematic development practices can elevate both project outcomes and developer capabilities.","createdAt":"2025-09-23T12:42:57.463Z","updatedAt":"2025-09-23T13:03:12.720Z","publishedAt":"2025-09-23T13:03:12.730Z","createdById":1,"updatedById":1,"locale":null,"authorLinks":[],"categoryLinks":[],"tagLinks":[{"id":55,"articleId":37,"tagId":8,"tagOrd":2,"articleOrd":4,"tag":{"id":8,"documentId":"ejb7qw9sls2h5wg992mfltjo","name":"OpenAI","createdAt":"2025-05-11T16:15:55.920Z","updatedAt":"2025-05-11T16:15:55.920Z","publishedAt":"2025-05-11T16:15:55.975Z","createdById":1,"updatedById":1,"locale":null}},{"id":54,"articleId":37,"tagId":10,"tagOrd":1,"articleOrd":2,"tag":{"id":10,"documentId":"nf2lt0bf1q90dr7jxmw5byob","name":"LLM","createdAt":"2025-07-10T12:35:22.318Z","updatedAt":"2025-07-10T12:35:22.318Z","publishedAt":"2025-07-10T12:35:22.346Z","createdById":1,"updatedById":1,"locale":null}}]},{"id":34,"documentId":"s1yq3vmwcu9n0ekp95syfjpx","title":"Copilot Proxy: Your Free LLM API for Local Development","description":"Maximize the usage of Github Copilot free quota","slug":"copilot-proxy-your-free-llm-api-for-local-development","content":"> Update: I have complete rewritten Copilot Proxy as [Coxy](https://github.com/coxy-proxy/coxy). Read [My Spec-Driven Development Experience: Building a Next.js and Nest.js Full-Stack Project](https://hankchiu.tw/writings/my-spec-driven-development-experience-building-a-next-js-and-nest-js-full-stack-project) for details.\n\nDeveloping applications powered by Large Language Models (LLMs) can be costly, especially during the development phase. Each API call to services like OpenAI or Anthropic consumes tokens, and these costs can accumulate rapidly during iterative development and debugging.\n\nI developed [Copilot Proxy](https://www.npmjs.com/package/copilot-proxy) to address this issue. It's a local API proxy that routes your LLM requests to GitHub Copilot, maximizing your free quota usage and minimizing your API costs.\n\n## Existing Alternatives and Their Limitations\n\nSome developers turn to local solutions like **Ollama**, which allows running open-source models such as LLaMA and Mistral locally. While this approach offers privacy and cost benefits, it comes with certain limitations:\n\n* **Hardware Requirements**: Running these models efficiently requires above-average hardware, such as modern Apple Silicon or high-end GPUs.\n* **Model Availability**: Ollama primarily supports open-source models. Mainstream models like GPT-4, Claude, or Gemini are not available through this platform.\n* **Performance Variability**: The performance and quality of open-source models can be inconsistent compared to their proprietary counterparts.\n* **Management Overhead**: Handling model downloads and dependencies can be cumbersome.\n\n## Copilot Proxy's Features\n\n- **Seamless API Proxying**: Transparently routes your OpenAI-compatible API requests to `https://api.githubcopilot.com`, allowing you to use GitHub Copilot as a drop-in replacement for expensive LLM APIs during development.\n- **Supported Endpoints**: Handles key endpoints such as `/chat/completions` for conversational AI and `/models` for model discovery, ensuring compatibility with most OpenAI-based tools and SDKs.\n- **Intuitive Admin UI**:\n - **GitHub Authentication**: Securely log in with your GitHub account to generate and manage Copilot tokens directly from the interface.\n - **Manual Token Management**: Easily add, remove, or update tokens as needed, giving you full control over your Copilot access.\n - **Multi-Token Support**: Manage several tokens at once, allowing you to distribute requests across them and make the most of your available free quota.\n - **Usage Analytics**: Visualize chat message and code completion statistics to monitor your development activity and optimize token utilization.\n\n### Ideal Use Cases\n\n* Developing with frameworks like [LangChain](https://python.langchain.com/) or [LlamaIndex](https://www.llamaindex.ai/) to prototype and test LLM-powered workflows without incurring API costs.\n* Using the [LLM CLI](https://llm.datasette.io/en/stable/other-models.html#openai-compatible-models) for your daily tasks, such as generating commit messages or summarizing code changes.\n* Chatting with GitHub Copilot through [Open WebUI](https://docs.openwebui.com/getting-started/) outside VSCode.\n\n\n### Not a Replacement for Production APIs\n\nWhile Copilot Proxy is excellent for development purposes, it's not intended for production use. Copilot doesn't support features like function calls, tools, or streaming outputs that are available in full-fledged APIs. However, for local testing and development cycles, it serves as a cost-effective solution.\n\n---\n\n## Try It Out\n\nIf you're building LLM-powered applications and want to optimize your development process without incurring high costs, give Copilot Proxy a try.\n\n> If you are looking to build a content-based website, it doesn't have to mean dealing with the complexity of modern SPA frameworks, consider trying **[Strikingly](https://www.strikingly.com/a/IG5yzQ)**.\nWith Strikingly, you can build a fast, beautiful, and mobile-friendly website in under 30 minutes. As your needs evolve, you can easily add features like e-commerce and analytics to enhance your site at your own pace.","createdAt":"2025-05-11T16:13:16.585Z","updatedAt":"2025-09-23T12:49:46.279Z","publishedAt":"2025-09-23T12:49:46.290Z","createdById":1,"updatedById":1,"locale":null,"authorLinks":[],"categoryLinks":[],"tagLinks":[{"id":45,"articleId":34,"tagId":6,"tagOrd":1,"articleOrd":1,"tag":{"id":6,"documentId":"m4o9odn22c3o742aw0tnibal","name":"NPM","createdAt":"2025-05-11T16:15:24.999Z","updatedAt":"2025-05-11T16:15:24.999Z","publishedAt":"2025-05-11T16:15:25.062Z","createdById":1,"updatedById":1,"locale":null}},{"id":46,"articleId":34,"tagId":8,"tagOrd":2,"articleOrd":1,"tag":{"id":8,"documentId":"ejb7qw9sls2h5wg992mfltjo","name":"OpenAI","createdAt":"2025-05-11T16:15:55.920Z","updatedAt":"2025-05-11T16:15:55.920Z","publishedAt":"2025-05-11T16:15:55.975Z","createdById":1,"updatedById":1,"locale":null}}]},{"id":31,"documentId":"fpeswxnnzgt2n7449f7f2vnv","title":"Auto-generate Commit Messages with LLMs in Your Terminal","description":"For those who stick to their workflow on the terminal heavily","slug":"auto-generate-commit-messages-with-ll-ms-in-your-terminal","content":"Writing commit messages can be a drag. While IDEs like Cursor can automate this, what if you live in your terminal and want a fast, controllable way to generate conventional commits?\n\nThis guide is for you. It's as simple as piping `git diff` to a command-line LLM client to create well-formatted commit messages without leaving the terminal.\n\n### Quick Summary\n\n1. **Use a non-interactive LLM client:** We need a tool that takes input from a pipe, sends it to the model, and prints the result to standard output.\n2. **Craft a system prompt:** Instruct the LLM to generate a message in the Conventional Commits format.\n3. **Create a Git alias:** Make the entire process accessible through a simple command like `git ca`.\n\n### The System Prompt\n\nFirst, let's define our instructions for the LLM. This prompt ensures the output is consistently formatted as a Conventional Commit:\n\n```\nWrite a commit message in the Conventional Commits format. Use the structure:\n (): \n\n \n\n \n\nExample types: feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert\nOptionally, include a body for more details in bullet points.\nOptionally, in the footer, use BREAKING CHANGE: followed by a detailed explanation of the breaking change.\n\nJust return the commit message, do not include any other text.\n```\n\n### LLM Clients for the Terminal\n\nSeveral command-line tools can handle this task. Here are a few examples of how to use them, piping your staged changes directly to the model.\n\n * **[LLM CLI](https://llm.datasette.io/en/stable/)**\n\n ```bash\n git diff --cached | llm -s ''\n ```\n\n * **[Gemini CLI](https://github.com/google-gemini/gemini-cli)**\n\n ```bash\n git diff --cached | gemini -p ''\n ```\n\n * **[aichat](https://github.com/sigoden/aichat)**\n\n ```bash\n git diff --cached | aichat --prompt ''\n ```\n\n * **[Claude CLI](https://www.google.com/search?q=https://github.com/anthropics/claude-cli)**\n\n ```bash\n git diff --cached | claude -p ''\n ```\n\n### Create a Git Alias\n\nTo make this truly seamless, add an alias to your `.gitconfig`. This example uses `llm` to commit all staged changes and then displays the latest log entry.\n\nPlace your full system prompt directly into the alias or save it to a file and reference it.\n\n```ini\n# In your ~/.gitconfig file\n\n[alias]\n ca = \"!(git commit -m \\\"$(git diff --cached | llm -s 'Write a commit message in the Conventional Commits format...')\\\" && git log --stat -1)\"\n```\n\nNow, instead of `git commit`, simply run:\n\n```bash\ngit ca\n```\n\nYour staged changes will be sent to the LLM, the generated message will be used for the commit, and you'll see the result instantly. It's a quick, powerful way to keep your workflow moving, all from the comfort of your terminal.","createdAt":"2025-07-10T12:34:31.627Z","updatedAt":"2025-07-10T12:53:14.004Z","publishedAt":"2025-07-10T12:53:14.019Z","createdById":1,"updatedById":1,"locale":null,"authorLinks":[],"categoryLinks":[],"tagLinks":[{"id":41,"articleId":31,"tagId":8,"tagOrd":1,"articleOrd":3,"tag":{"id":8,"documentId":"ejb7qw9sls2h5wg992mfltjo","name":"OpenAI","createdAt":"2025-05-11T16:15:55.920Z","updatedAt":"2025-05-11T16:15:55.920Z","publishedAt":"2025-05-11T16:15:55.975Z","createdById":1,"updatedById":1,"locale":null}},{"id":42,"articleId":31,"tagId":10,"tagOrd":2,"articleOrd":1,"tag":{"id":10,"documentId":"nf2lt0bf1q90dr7jxmw5byob","name":"LLM","createdAt":"2025-07-10T12:35:22.318Z","updatedAt":"2025-07-10T12:35:22.318Z","publishedAt":"2025-07-10T12:35:22.346Z","createdById":1,"updatedById":1,"locale":null}}]},{"id":27,"documentId":"hh3sfw7ndwu9056e4ft2q994","title":"Free Claude Sonnet 4 for Local Development: Setting Up Aider with Cody","description":"Using Aider with Claude Sonnect 4","slug":"free-claude-sonnet-4-for-local-development-setting-up-aider-with-cody","content":"*Reading time: 3 minutes*\n\nLooking to experiment with cutting-edge AI models for coding without breaking the bank? While premium tools like Cursor and Windsurf offer polished experiences, they come with subscription costs that can add up. If you're curious about modern language models but want a budget-friendly way to explore their capabilities, combining Aider with Cody offers an interesting alternative worth considering.\n\nThis approach isn't perfect – it comes with limitations and requires more setup than plug-and-play solutions. But for developers who enjoy tinkering and want to experience models like Claude Sonnet 4 without monthly fees, it's a compelling option to explore.\n\n## What You're Working With\n\n**Aider** is an open-source command-line tool designed for AI-assisted coding. Unlike IDE-integrated solutions, it works directly with git repositories, making commits based on natural language instructions. It supports various editors and focuses on making actual code changes rather than just providing suggestions.\n\n**Cody** is Sourcegraph's AI assistant that powers chat, code completion, and automated code edits. Its free plan includes 200 messages per month with premium models like Claude Sonnet 4. These limits mean this setup works best for occasional experimentation, learning, or small projects rather than heavy daily development. If you're planning to use AI assistance extensively, you'll likely hit these caps quickly. However, for exploring what modern language models can do or handling specific coding challenges, these quotas can be quite useful.\n\n## Setting Up Aider with Cody's Cloud Endpoint\n\nThe integration process involves connecting Aider directly to Sourcegraph's cloud API rather than running a local Cody CLI instance.\n\n**Step 1: Install Aider**\n\nFollow the [official document](https://aider.chat/docs/install.html), e.g.\n\n```bash\npython -m pip install aider-install\naider-install\n```\n\n**Step 2: Generate Your Access Token**\nVisit Sourcegraph's token settings page at `https://sourcegraph.com/users//settings/tokens` and create a new access token. This token authenticates your requests to Sourcegraph's LLM API.\n\n**Step 3: Configure Your Project**\nIn your project directory, create two configuration files that tell Aider how to communicate with Sourcegraph's endpoint:\n\n```yaml\n# .aider.conf.yml\nopenai-api-base: https://sourcegraph.com/.api/llm\nopenai-api-key: sgp_xxxxx # put your actual access token here\nmodel: openai/anthropic::2024-10-22::claude-sonnet-4-latest\n\n# .aider.model.settings.yml\n- name: openai/anthropic::2024-10-22::claude-sonnet-4-latest\n use_system_prompt: false\n extra_params:\n extra_headers:\n X-Requested-With: aider 0.0.0\n max_tokens: 64000\n```\n\nThe first file handles basic authentication and model selection, while the second configures specific parameters for optimal performance with Claude Sonnet 4, including the maximum token limit and required headers.\n\n**Step 4: Launch and Code**\nWith your configuration in place, simply run `aider` from your project directory. Aider will automatically use your settings to connect to Sourcegraph's API and give you access to Claude Sonnet 4 within your free usage limits.\n\n## Is This Right for You?\n\nThis setup works best for developers curious about modern AI models without subscription commitments – students, hobbyists, or those working on side projects. The quota limitations make it unsuitable for heavy daily use, but as an accessible entry point into AI-assisted development, it offers genuine learning value.\n\nConsider it a stepping stone to understand how AI can enhance your coding. Once you've explored the capabilities within these constraints, you can make informed decisions about investing in more comprehensive solutions.","createdAt":"2025-06-16T11:29:18.958Z","updatedAt":"2025-06-17T00:21:38.963Z","publishedAt":"2025-06-17T00:21:39.034Z","createdById":1,"updatedById":1,"locale":null,"authorLinks":[],"categoryLinks":[],"tagLinks":[{"id":34,"articleId":27,"tagId":8,"tagOrd":1,"articleOrd":2,"tag":{"id":8,"documentId":"ejb7qw9sls2h5wg992mfltjo","name":"OpenAI","createdAt":"2025-05-11T16:15:55.920Z","updatedAt":"2025-05-11T16:15:55.920Z","publishedAt":"2025-05-11T16:15:55.975Z","createdById":1,"updatedById":1,"locale":null}}]},{"id":23,"documentId":"wv344hll744lgrgcfoq9jcb4","title":"The Paradigm Shift in Web Development for AI-Era: From Client-Side to Server-Side Rendering","description":"How Server-Side Rendering is coming back in AI-Era","slug":"the-paradigm-shift-of-web-frameworks-in-ai-era-from-client-side-to-server-side-rendering","content":"\nThe following article, written with AI assistance, explores this topic.\nMy initial ideas were:\n- A brief history of the rise of Single-Page Applications (SPAs).\n- Engineering challenges of client-side rendering for AI-native applications.\n- How server-side rendering can address these challenges.\n- Practical tools and libraries for further exploration.\n\nEnjoy the read!\n\n \n\n---\n\n \n\nThe web development landscape is experiencing a fundamental transformation. As artificial intelligence becomes deeply integrated into web applications, we're witnessing a significant shift away from the client-side rendering dominance that defined the 2010s.\n\n## The Rise and Reign of Single Page Applications\n\n### The SPA Revolution (2010-2020)\n\nThe Single Page Application era began with frameworks like Angular (2010), React (2013), and Vue.js (2014) promising desktop-like experiences in the browser. SPAs offered fluid user experiences with no page refreshes, rich interactivity, and clean separation between frontend and backend.\n\nBy the mid-2010s, client-side rendering became the default choice. Several factors drove this adoption:\n- Improved JavaScript engines made client-side computation viable\n- CDN proliferation made delivering JavaScript bundles cost-effective\n- Mobile hardware improvements provided sufficient processing power\n- Broadband adoption reduced concerns about initial load times\n\nThe result was a generation of developers who learned web development through React, Angular, and Vue. Client-side rendering became the cultural norm.\n\n## Engineering Challenges in the AI Era\n\n### Real-Time Processing Challenges\n\nModern AI applications demand capabilities that traditional SPAs struggle to deliver:\n\n**Network Overhead and Latency**\nAI applications require constant communication with servers for model updates, training data, or hybrid processing. This creates more network requests than traditional SPAs, ironically reducing the performance benefits that CSR was meant to provide. Real-time AI features like live translation, content generation, or computer vision processing suffer from network round-trip delays.\n\n**Synchronization Complexity**\nAI applications frequently need to maintain state consistency across multiple AI services (embeddings, completions, fine-tuned models). Managing this distributed state on the client introduces significant complexity and potential for data inconsistencies, especially when handling real-time collaborative AI features.\n\n**Processing Bottlenecks**\nClient devices, particularly mobile phones and budget laptops, lack the computational power for real-time AI processing. While servers can leverage specialized GPUs and TPUs, client-side AI inference creates noticeable delays and poor user experiences for time-sensitive applications.\n\n### Development and Maintenance Overhead\n\n**Fragmentation Across Devices**\nDifferent devices have varying AI capabilities (Neural Processing Units, GPU acceleration, WebGL support). Creating consistent AI experiences across this fragmented landscape requires substantial engineering effort. Developers must handle graceful degradation, feature detection, and multiple code paths for different device capabilities.\n\n**Version Management Complexity**\nAI models evolve rapidly with frequent updates and improvements. Managing model versions, backward compatibility, and deployment across diverse client devices becomes exponentially more complex than traditional web application updates. Each client potentially runs different model versions, creating support nightmares.\n\n**Resource Management**\nClient-side AI applications must carefully manage memory usage, processing threads, and battery consumption. This adds significant complexity to the development process, requiring specialized knowledge of device capabilities and performance optimization techniques that most web developers lack.\n\n## Server-Side Rendering: The AI-Era Solution\n\n### Why SSR Makes Sense for AI Applications\n\nServer-side rendering addresses the fundamental misalignment between AI computational requirements and client device capabilities:\n\n**Specialized Hardware**\nServers utilize GPUs, TPUs, and specialized AI hardware that provide orders of magnitude better performance than client devices for AI workloads.\n\n**Consistent Performance**\nServer-side AI processing provides predictable performance regardless of client device capabilities, ensuring all users receive the same high-quality experience.\n\n**Simplified Architecture**\nCentralized model deployment simplifies updates, A/B testing, and maintenance of AI capabilities while reducing client-side complexity.\n\n### Technical Benefits\n\n- **Reduced Initial Load Times**: Users receive pre-rendered HTML with AI-generated content already in place\n- **Enhanced Security**: AI models and processing remain on the server, preventing model extraction\n- **Better SEO and Accessibility**: AI-generated content is immediately available to search engines and screen readers\n- **Resource Efficiency**: Server infrastructure allows efficient resource sharing across users\n\n## Practical Tools for AI-Era SSR\n\n### Next.js: Server Actions and Streaming\n\nNext.js leads the SSR renaissance with powerful AI features:\n\n```javascript\n// Server Action for AI processing\n'use server'\nexport async function generateResponse(formData) {\n const message = formData.get('message')\n const response = await openai.chat.completions.create({\n model: \"gpt-4\",\n messages: [{ role: \"user\", content: message }]\n })\n return response.choices[0].message.content\n}\n```\n\n**Key Features:**\n- Server Actions for seamless AI processing\n- Edge Runtime support for global distribution\n- Built-in streaming for real-time AI responses\n\n### SvelteKit: Performance-First Approach\n\n```javascript\n// Pre-process AI data before rendering\nexport async function load({ params }) {\n const userPreferences = await getUserPreferences(params.userId)\n const aiRecommendations = await generateRecommendations(userPreferences)\n \n return { recommendations: aiRecommendations }\n}\n```\n\n**Benefits:**\n- Minimal JavaScript footprint\n- Server-side load functions for AI pre-processing\n- Excellent performance characteristics\n\n### Specialized AI Tools\n\n**Vercel AI SDK**\n```javascript\nimport { streamText } from 'ai'\nimport { openai } from '@ai-sdk/openai'\n\nexport async function POST(req) {\n const { messages } = await req.json()\n const result = await streamText({\n model: openai('gpt-4'),\n messages,\n })\n return result.toAIStreamResponse()\n}\n```\n\n**Infrastructure Options:**\n- **Vercel Edge Functions**: Global AI processing distribution\n- **Cloudflare Workers**: Low-latency AI inference at the edge\n- **AWS Lambda**: Serverless AI processing with AWS integration\n\n### Caching Strategies\n\n- **Redis**: Cache AI responses and user sessions\n- **CDN Caching**: Static AI-generated content with proper headers\n- **Edge Caching**: Distribute AI-processed content globally\n\n## The Hybrid Future\n\nThe future involves sophisticated hybrid approaches:\n\n**Smart Rendering Decisions**\nFrameworks will automatically decide where to render based on content type, device capabilities, network conditions, and AI processing requirements.\n\n**Progressive AI Enhancement**\nApplications will layer AI capabilities progressively, ensuring core functionality works universally while enhancing experiences where possible.\n\n## Conclusion\n\nThe shift toward server-side rendering represents a maturation of web development practices in response to AI requirements. As AI becomes central to web applications, computational realities demand server-centric architectures.\n\nThis evolution incorporates lessons from the SPA era while addressing AI-native application challenges. The tools and frameworks are ready—the question is how quickly development teams will adapt to leverage AI-era server-side rendering benefits.","createdAt":"2025-06-02T12:38:42.336Z","updatedAt":"2025-06-04T10:51:20.695Z","publishedAt":"2025-06-04T10:51:20.729Z","createdById":1,"updatedById":1,"locale":null,"authorLinks":[],"categoryLinks":[],"tagLinks":[{"id":29,"articleId":23,"tagId":2,"tagOrd":1,"articleOrd":3,"tag":{"id":2,"documentId":"zpdbbgq2uial3hfwbe4s0w79","name":"Framework","createdAt":"2025-04-23T10:19:59.629Z","updatedAt":"2025-04-23T10:20:03.641Z","publishedAt":"2025-04-23T10:20:03.659Z","createdById":1,"updatedById":1,"locale":null}},{"id":30,"articleId":23,"tagId":4,"tagOrd":2,"articleOrd":2,"tag":{"id":4,"documentId":"e7krdg9jiv9fnpuuicjo790y","name":"Vibe Writing","createdAt":"2025-04-23T10:20:19.876Z","updatedAt":"2025-04-23T10:20:19.876Z","publishedAt":"2025-04-23T10:20:19.908Z","createdById":1,"updatedById":1,"locale":null}}]},{"id":17,"documentId":"v691cp9buchp8k64x676z3bm","title":"Rethink non-SPA Web Development in 2025","description":"Rethink SPA defaults—simpler, faster, user-first web dev often works better.","slug":"rethink-non-spa-web-development-in-2025","content":"Over the years, I have worked on projects using SPA. One thing has become increasingly clear to me: the web development community's love affair with Single-Page Application (SPA) has led us to overcomplicate many projects that could be simpler, faster, and more accessible.\n\nThis isn't another \"React vs Angular vs Vue\" debate. Rather, it's an invitation to step back and reconsider our fundamental approach to building for the web in 2025.\n\n## The SPA Dominance: How We Got Here\n\nWhen I started my career, SPA were revolutionary. The promise was enticing: rich, desktop-like experiences delivered through the browser. Frameworks like React, Angular, and Vue made it possible to build complex interfaces with relatively clean code organization.\n\nSPA quickly became the default choice for new projects. Job listings demanded React experience. Bootcamps centered their curricula around these frameworks. Conference talks assumed SPA as the baseline.\n\nBut somewhere along the way, we stopped asking a crucial question: is this approach actually the best fit for what we're building?\n\nI recently planned to create a blogging website and the first question unconsciously showed in my mind was \"Angular or React?\". Only after a while, I realize it should not be about frameworks. This mindset reflects how thoroughly SPA thinking has permeated our industry.\n\n## First Principles: What Are We Really Trying to Accomplish?\n\n### User Needs vs. Developer Convenience\n\nWhen I strip away assumptions and return to first principles, I always come back to this: what do users actually need?\n\nUsers need websites that:\n\n- Load quickly\n- Work reliably\n- Are accessible to everyone\n- Accomplish their goals with minimal friction\n\nThey don't care about our component architecture, state management solutions, or build pipelines. They don't benefit from our hot module reloading during development.\n\nYet so much of our framework choice discussion centers on developer experience rather than user experience. I've been guilty of this myself—choosing tools because they make my workflow more pleasant, not because they deliver the best end result.\n\n## The Interaction Spectrum\n\nNot all web projects have the same requirements. I find it helpful to think about a spectrum of interaction complexity:\n\n### Static Content: When Simple HTML Wins\n\nFor content-focused websites—blogs, marketing sites, documentation—the interaction model is primarily:\n\n1. User requests a page\n2. Server returns the complete HTML\n3. User reads/consumes content\n4. User clicks to another page, returning to step 1\n\nFor these cases, generating static HTML (whether at build time or request time) often provides the best performance. A framework like Astro, 11ty, or even a traditional CMS can deliver lightning-fast experiences without shipping a single line of JavaScript to the browser.\n\n### Partial Interactivity: The Sweet Spot\n\nMany web applications fall into a middle ground—mostly content-focused with some interactive elements:\n\n- Forms with validation\n- Filtering and sorting interfaces\n- Cart/checkout flows\n- Comment sections\n\nThese interactions benefit from JavaScript but don't necessarily require a full SPA architecture. This is where approaches like HTML-over-the-wire (HTMX, Hotwire, etc.) or the \"islands architecture\" really shine.\n\n### Full Interactivity: When SPA Make Sense\n\nI'm not anti-SPA. For truly application-like experiences with complex state management needs, SPA remain appropriate:\n\n- Data dashboards with real-time updates\n- Complex editing interfaces (like Figma or Google Docs)\n- Applications with offline functionality requirements\n- Interfaces with constant user interaction and minimal page transitions\n\n## The Technical Foundations\n\n### Rediscovering HTML's Power\n\nHTML has evolved significantly since SPA gained popularity. Elements like `