Walkthrough: Setting up different Continue profiles for frontend vs backend work.

Another day, another tool promising to revolutionize my workflow. This time it's "Continue," the AI coding assistant you're supposed to embed in your editor. The hype train is barreling down the tracks, full of promises about context-aware completions and seamless integration. So I decided to see if it could handle the most basic reality of modern development: the starkly different contexts between frontend and backend work.

The premise is you can set up different "profiles" for different types of projects. Sounds reasonable. Until you realize that a "frontend" profile for a React/TypeScript/Tailwind monorepo has almost zero overlap with a "backend" profile for a Go service with gRPC and PostgreSQL. The default, one-size-fits-all context is a recipe for the AI suggesting `useEffect` hooks in your database connection pool logic.

Here's my attempt to force some sanity into the system. The core of this is the `config.json` for Continue, living in your `.continue` directory. You define profiles with specific `contextProviders` and `systemMessages`.

First, the frontend profile. This one needs to care about your component library, your state management, and your API client patterns. Notice the inclusion of the `github` context provider for your internal design system docs.

```json
{
"profiles": [
{
"name": "frontend-react-ts",
"systemMessage": "You are an expert in modern frontend development. Primary stack: React 18+, TypeScript, Tailwind CSS, Vite. State management is via Zustand. API client is auto-generated TanStack Query hooks from an OpenAPI spec. You prioritize accessible, composable components. Do not suggest class-based components or outdated lifecycle methods. Reference the shared UI component library from the provided context.",
"contextProviders": [
"github",
"terminal",
"file",
"search"
],
"allowContextLoading": true,
"slashCommands": [
"generate-component",
"generate-hook"
]
}
]
}
```

Now, the backend counterpart. This one needs a completely different worldview: concurrency, database schemas, API contracts, and observability. The `terminal` and `file` providers are critical here for referencing existing proto files and migration scripts.

```json
{
"name": "backend-go-grpc",
"systemMessage": "You are an expert in backend services. Primary stack: Go 1.21+, gRPC/protobuf, PostgreSQL, sqlc. Emphasis on clean architecture, error wrapping, and structured logging (zerolog). Do not suggest ORMs. Always consider idempotency and database transaction boundaries. API contracts are defined by protobuf files; always check them. Observability is via OpenTelemetry.",
"contextProviders": [
"terminal",
"file",
"search",
"diff"
],
"allowContextLoading": true,
"slashCommands": [
"generate-handler",
"generate-migration"
]
}
```

The real test, of course, isn't if you can write the JSON. It's whether this actually stops the LLM from hallucinating `package.json` scripts into your `go.mod` file. Early results are... mixed. The system message helps steer the tone, but the context providers are the real bottleneck. Loading the entire `node_modules` for context? Don't make me laugh. It times out. You have to be surgical with `.continue/ignore` rules, which is just more config debt.

And let's talk about the cost, because nobody else will. Each of these context providers is making calls, indexing files, chewing through tokens. Spinning up a separate profile for every microservice and SPA in your polyglot monorepo? You're not just paying for the Continue subscription; you're paying for the LLM context window bloat and the engineer hours spent debugging why the AI keeps suggesting GraphQL in your gRPC service because it scanned a sibling project.

So, has this "profile" feature saved me time? Marginally. It's a slightly better-organized footgun. You still spend more time curating the context and writing exclusion globs than you save on autocomplete. It's a classic tale: another layer of abstraction to manage the leaks of the previous one.

-- cynical ops