# Why Cursor Suggests Outdated Cloud Patterns

- Tool: Cursor
- Difficulty: Beginner
- Time required: 10-15 min
- Compatibility: Cursor Free+, AWS CDK v2 projects
- Last updated: March 2026

## TL;DR

Cursor frequently generates AWS CDK v1 patterns including core module imports, deprecated construct APIs, and outdated Stack syntax because its training data contains more v1 examples. By adding project rules that specify CDK v2, referencing your package.json and existing stacks with @file, and prompting with explicit version context, you ensure Cursor generates code using the current aws-cdk-lib unified module and modern construct patterns.

## Why Cursor suggests outdated cloud patterns and how to fix it

AWS CDK v1 and v2 have fundamentally different import structures. V1 used separate packages like @aws-cdk/aws-s3 while v2 uses a single aws-cdk-lib package. Cursor's training data contains far more v1 examples, leading it to generate deprecated imports and patterns. This tutorial configures Cursor to always use CDK v2 with current best practices.

## Before you start

- Cursor installed with an AWS CDK v2 project
- aws-cdk-lib and constructs packages installed
- Basic understanding of AWS CDK stacks and constructs
- Familiarity with Cursor Chat (Cmd+L) and project rules

## Step-by-step guide

### 1. Create an AWS CDK v2 enforcement rule

Add a project rule that specifies CDK v2 conventions and explicitly bans v1 patterns. The key difference is the import structure: v2 uses aws-cdk-lib as a single package while v1 used dozens of separate @aws-cdk packages.

```
---
description: Enforce AWS CDK v2 patterns
globs: "*.ts,**/cdk/**,**/infra/**"
alwaysApply: true
---

# AWS CDK v2 Rules
- Project uses AWS CDK v2 with aws-cdk-lib
- NEVER import from @aws-cdk/* packages (that is CDK v1)
- ALWAYS import from 'aws-cdk-lib' and 'aws-cdk-lib/aws-*'
- ALWAYS import Construct from 'constructs' (not @aws-cdk/core)
- Use L2 constructs where available, L1 (Cfn*) only when needed
- Use Stack.of(this) for cross-stack references
- Use cdk.RemovalPolicy.DESTROY for dev, RETAIN for prod
- Use cdk.Tags.of() for resource tagging

## Correct Imports:
```typescript
import * as cdk from 'aws-cdk-lib';
import * as s3 from 'aws-cdk-lib/aws-s3';
import * as lambda from 'aws-cdk-lib/aws-lambda';
import { Construct } from 'constructs';
```

## WRONG Imports (CDK v1 — NEVER use):
```typescript
import * as cdk from '@aws-cdk/core';       // WRONG
import * as s3 from '@aws-cdk/aws-s3';       // WRONG
import { Construct } from '@aws-cdk/core';   // WRONG
```
```

**Expected result:** Cursor generates CDK code using aws-cdk-lib imports and v2 patterns instead of deprecated v1 packages.

### 2. Reference your CDK project for version context

Always reference package.json and an existing stack file when prompting Cursor for CDK code. This gives Cursor concrete proof of your CDK version and existing patterns to follow.

```
@aws-cdk.mdc @package.json @lib/main-stack.ts

Add an S3 bucket to the main stack with these requirements:
1. Versioning enabled
2. Server-side encryption with S3-managed keys
3. Lifecycle rule: move to IA after 30 days, Glacier after 90, delete after 365
4. Block all public access
5. CORS configured for the frontend domain
6. RemovalPolicy.DESTROY for dev environment

Use CDK v2 L2 constructs from aws-cdk-lib/aws-s3.
Follow the same patterns as existing resources in the stack.
```

> Pro tip: Reference an existing stack file with @file so Cursor matches your constructor signature, naming conventions, and resource organization patterns.

**Expected result:** Cursor generates an S3 bucket using aws-cdk-lib/aws-s3 with L2 construct methods and proper v2 import structure.

### 3. Use @docs to reference current CDK API documentation

Add the AWS CDK v2 API reference to Cursor's indexed docs. This gives Cursor access to current construct APIs and prevents it from suggesting deprecated methods. Open Cursor Settings, add the CDK docs URL, and then reference it in prompts.

```
@docs AWS CDK @aws-cdk.mdc

Create a Lambda function with API Gateway integration:
1. Node.js 20 runtime with arm64 architecture
2. API Gateway v2 HTTP API (not REST API)
3. Lambda function URL as an alternative endpoint
4. Environment variables from SSM Parameter Store
5. X-Ray tracing enabled
6. Log retention set to 14 days

Use aws-cdk-lib L2 constructs. Reference the latest CDK v2 API
for HttpApi and NodejsFunction constructs.
```

**Expected result:** Cursor generates Lambda and API Gateway code using current CDK v2 constructs with correct method signatures.

### 4. Fix v1 imports in existing code with Cmd+K

If Cursor generates v1-style imports despite your rules, select the import block and use Cmd+K to fix them. This is a quick correction that teaches you the exact import mapping between v1 and v2.

```
Convert all CDK v1 imports to CDK v2.
Replace @aws-cdk/* with aws-cdk-lib/*.
Replace @aws-cdk/core with aws-cdk-lib.
Replace Construct from @aws-cdk/core with Construct from constructs.
Do not change any other code, only the import statements.
```

**Expected result:** All imports are converted from @aws-cdk/package to aws-cdk-lib/package format.

### 5. Generate a complete CDK stack with Composer

Use Composer Agent mode to generate multiple CDK constructs and stack files at once. This approach maintains consistent imports and patterns across all generated infrastructure code.

```
@aws-cdk.mdc @package.json @lib/main-stack.ts

Create a new microservice infrastructure stack with:
1. lib/api-stack.ts — API Gateway HTTP API + Lambda functions
2. lib/database-stack.ts — DynamoDB table with GSIs
3. lib/monitoring-stack.ts — CloudWatch alarms and dashboard
4. lib/constructs/api-lambda.ts — reusable L3 construct for Lambda+API

All files must use aws-cdk-lib imports (CDK v2).
Follow the same Stack constructor pattern as main-stack.ts.
Use cross-stack references with cdk.CfnOutput and cdk.Fn.importValue.
```

**Expected result:** Cursor Agent generates four CDK files with consistent v2 imports, L2 constructs, and cross-stack reference patterns.

## Complete code example

File: `.cursor/rules/aws-cdk.mdc`

```markdown
---
description: Enforce AWS CDK v2 patterns
globs: "*.ts,**/cdk/**,**/infra/**,**/lib/**"
alwaysApply: true
---

# AWS CDK v2 Rules
- Project uses AWS CDK v2 with aws-cdk-lib
- NEVER import from @aws-cdk/* packages (CDK v1 — deprecated)
- ALWAYS import from 'aws-cdk-lib' and 'aws-cdk-lib/aws-*'
- ALWAYS import Construct from 'constructs' package
- Use L2 constructs first, L1 (Cfn*) only when L2 lacks a feature
- Use Stack.of(this) for cross-stack references
- Use cdk.Tags.of() for consistent resource tagging
- Use cdk.CfnOutput for exported values

## Correct Import Pattern:
```typescript
import * as cdk from 'aws-cdk-lib';
import * as s3 from 'aws-cdk-lib/aws-s3';
import * as lambda from 'aws-cdk-lib/aws-lambda';
import * as apigw from 'aws-cdk-lib/aws-apigatewayv2';
import * as dynamodb from 'aws-cdk-lib/aws-dynamodb';
import { Construct } from 'constructs';
```

## Stack Constructor Pattern:
```typescript
export class MyStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);
    // resources here
  }
}
```

## FORBIDDEN (CDK v1):
```typescript
import * as cdk from '@aws-cdk/core';     // NEVER
import * as s3 from '@aws-cdk/aws-s3';     // NEVER
```
```

## Common mistakes

- **Not specifying CDK version in rules, getting mixed v1/v2 imports** — Cursor's training data contains far more CDK v1 code. Without explicit version rules, it defaults to v1 import patterns or mixes v1 and v2 styles. Fix: Add explicit NEVER import from @aws-cdk/* and ALWAYS import from aws-cdk-lib to your rules with examples of both correct and incorrect patterns.
- **Referencing CDK v1 documentation or blog posts in prompts** — If you paste code snippets from old CDK v1 tutorials, Cursor pattern-matches against them and generates v1-style code even with v2 rules. Fix: Always use @docs with the official CDK v2 API reference. Remove v1 code from your project before asking Cursor to extend it.
- **Using L1 (Cfn) constructs when L2 constructs are available** — Cursor sometimes drops to L1 constructs because they map directly to CloudFormation properties. L2 constructs provide safer defaults and simpler APIs. Fix: Add to rules: Use L2 constructs first, L1 (Cfn*) only when the L2 construct does not support a specific feature.

## Best practices

- Always reference package.json and an existing stack file when generating CDK code
- Use @docs with the CDK v2 API reference for up-to-date construct APIs
- Create reusable L3 constructs for common patterns and reference them with @file
- Include both correct and incorrect import examples in your rules file
- Use Cmd+K to quickly fix v1 imports rather than regenerating entire files
- Keep CDK rules in a separate .mdc file from application code rules
- Start new Chat sessions if Cursor reverts to v1 patterns mid-conversation

## Frequently asked questions

### Why does Cursor keep importing from @aws-cdk packages?

CDK v1 had years of widespread adoption and its import patterns dominate Cursor's training data. Explicit rules with both correct and incorrect examples are the most effective fix.

### Can Cursor generate CDK for languages other than TypeScript?

Yes. CDK supports Python, Java, C#, and Go. Adjust your rules to specify the language and include language-specific import patterns.

### How do I keep Cursor updated on new CDK constructs?

Use @docs to index the CDK v2 API reference. When new constructs are released, Cursor can reference them through the indexed documentation.

### Should I use CDK or Terraform with Cursor?

Both work well with Cursor. CDK is better if your team prefers TypeScript. Terraform has broader provider support. Create tool-specific rules regardless of which you choose.

### Can Cursor generate CDK tests?

Yes. Prompt Cursor with @file referencing your stack and ask for assertion-based tests using aws-cdk-lib/assertions. Include your test framework (Jest) in the prompt.

### Can RapidDev help set up cloud infrastructure?

Yes. RapidDev designs AWS infrastructure using CDK with proper security, monitoring, and cost optimization, and configures Cursor rules for ongoing infrastructure development.

---

Source: https://www.rapidevelopers.com/cursor-tutorial/how-to-correct-cursor-ai-if-it-suggests-references-to-older-v1-aws-cdk-constructs-in-new-projects
© RapidDev — https://www.rapidevelopers.com/cursor-tutorial/how-to-correct-cursor-ai-if-it-suggests-references-to-older-v1-aws-cdk-constructs-in-new-projects