Forem: snickerjp

🔍 The Potential of Perspective-Driven Code Reviews - Gaining New Insights

snickerjp — Fri, 05 Dec 2025 17:58:47 +0000

Introduction

The Importance of Perspective in Code Reviews

Code reviews are a crucial process that serves as the cornerstone of quality assurance, but the content and priorities of feedback can vary significantly depending on the reviewer's perspective. This report analyzes reviews from two different perspectives - operational and architectural - by AI "kiro" using actual Terraform code reviews as a case study, and examines the new insights gained by changing perspectives.

Two-Perspective Reviews by kiro

In this report, we requested AI "kiro" to conduct reviews from the following two perspectives:

🔧 Operational Perspective: Emphasizing safety, maintainability, and practicality in team development for daily operations
🏗️ Architectural Perspective: Emphasizing code design elegance, scalability, and architectural soundness

While these perspectives are not necessarily opposing, they differ in priorities and focus points. By requesting the same AI to review from different perspectives, we can objectively analyze how perspective differences affect feedback content.

🔧 Operational Perspective Review by kiro

Review Overview

The operational perspective review was analyzed using the following four evaluation criteria:

Item	Rating	Details
Security	🔴 Needs Improvement	Hardcoded sensitive information
State Management	🔴 Needs Improvement	Using local state
Code Quality	🟡 Good	Some room for improvement
Operability	🟡 Good	CI/CD not implemented

Major Issues Identified

1. State File Management (Most Critical)

❌ Problem: Managing state files locally
⚡ Risk: Conflicts in team development, loss risk, no backup
✅ Solution: Implement S3 backend + DynamoDB locking

terraform {
  backend "s3" {
    bucket         = "your-terraform-state-bucket"
    key            = "alb-rules/terraform.tfstate"
    region         = "ap-northeast-1"
    encrypt        = true
    dynamodb_table = "terraform-state-lock"
  }
}

2. Security Concerns

❌ Problem: ARNs hardcoded in tfvars files
⚡ Risk: Sensitive information leakage
✅ Solution: Environment variables, Parameter Store utilization, .gitignore configuration

3. Stricter Version Management

❌ Problem: Provider version range too broad (~> 5.0)
✅ Solution: More specific version specification (~> 5.30.0)

4. Operational Improvement Proposals

🏷️ Unified tag strategy (localize common tags)
✔️ Add variable validation (IP format, priority range validation)
🔄 Build CI/CD pipeline
📊 Monitoring and alerting setup

Implementation Roadmap

The operational perspective presented a phased improvement plan:

📅 Phase 1 (1 week): Remote state file implementation
📅 Phase 2 (2 weeks): Security enhancement
📅 Phase 3 (1 month): CI/CD construction
📅 Phase 4 (3 months): Modularization and policy management

🏗️ Architectural Perspective Review by kiro

Review Overview

The architectural perspective focused on code design quality and future scalability.

Overall Rating: B+ → A (after improvements)

Evaluated Strengths

⚡ Dynamic Resource Generation: Excellent automatic splitting logic for ALB limitations (4 IPs/rule)
📋 Variable Separation: Externalization of configuration through terraform.tfvars
🏷️ Tag Standardization: Consistent tag strategy
🎯 Constraint Handling: Creative solutions for AWS limitations

Major Improvement Proposals

1. Modularization Recommendation (Priority: Low)

Migration from current flat structure to module-based structure
🗂️ Environment-specific directory separation (production/staging)
♻️ Creation of reusable modules

2. Dynamic Retrieval via Data Sources (Priority: Medium)

Dynamically retrieve hardcoded ARNs using Data Sources
More flexible and maintainable design

# After improvement
data "aws_lb" "main" {
  name = var.load_balancer_name
}

data "aws_lb_listener" "https" {
  load_balancer_arn = data.aws_lb.main.arn
  port              = 443
}

3. Enhanced Input Validation (Priority: High)

🌐 CIDR format validation
🔢 IP count validation
💬 More detailed error messages

variable "devinvm_ip_addresses" {
  description = "Devin VM IP addresses"
  type        = list(string)

  validation {
    condition = alltrue([
      for ip in var.devinvm_ip_addresses :
      can(cidrhost(ip, 0))
    ])
    error_message = "All IP addresses must be valid CIDR notation."
  }
}

4. Output Improvements

📝 Add detailed descriptions
📊 Output rule summaries
🗂️ More structured output format

Comparative Analysis

Common Ground: Issues Identified by Both Perspectives

The following items were identified by both kiro's operational and architectural perspectives and are items that should definitely be improved:

✔️ Adding Input Validation
- 🔧 Operational perspective: Preventing operational mistakes
- 🏗️ Architectural perspective: Improving code quality
📌 Stricter Version Management
- 🔧 Operational perspective: Preventing unexpected behavior
- 🏗️ Architectural perspective: Ensuring reproducibility
State Management Improvement
- 🔧 Operational perspective: Team development safety
- 🏗️ Architectural perspective: Infrastructure reliability
Security Enhancement
- 🔧 Operational perspective: Protecting sensitive information
- 🏗️ Architectural perspective: Design soundness

Differences: Priority Variations by Perspective

Readability Aspect

Perspective	Priority	Approach
🔧 Operational	🟡 Medium	🏷️ Tag unification, clear naming conventions
🏗️ Architectural	🔴 High	📦 Modularization, structured output

Analysis: Architectural perspective emphasizes structural code readability (modularization). Operational perspective emphasizes clarity in daily work (tags, naming).

Maintainability Aspect

Perspective	Priority	Approach
🔧 Operational	🔴 High	🔄 CI/CD, 📊 monitoring, 🔍 drift detection
🏗️ Architectural	🔴 High	📦 Modularization, 🔍 Data Source utilization

Analysis: Both prioritize maintainability, but operational perspective focuses on "operational processes" while architectural perspective focuses on "code design".

Performance Aspect

Perspective	Priority	Approach
🔧 Operational	🟢 Low	No specific mention
🏗️ Architectural	🟢 Low	No specific mention

Analysis: For this Terraform code, performance was not a major concern for either perspective.

Priority Differences

Operational Perspective Priorities

🔴 Highest Priority (Immediate Response)
  ├─ State Management
  └─ Security

🟡 Medium Priority (Medium-term Improvement)
  ├─ CI/CD
  └─ Monitoring

🟢 Low Priority (Long-term Improvement)
  └─ Modularization

Architectural Perspective Priorities

🔴 Highest Priority
  └─ Input Validation

🟡 Medium Priority
  ├─ Data Source Implementation
  └─ State Management

🟢 Low Priority
  └─ Modularization

Important Discovery:

🔧 Operational perspective: "State Management" as highest priority → Focus on problems that could occur immediately
🏗️ Architectural perspective: "Input Validation" as highest priority → Focus on code quality fundamentals

Both perspectives rated "Modularization" as low priority because the current code is simple and functions adequately.

Different Focus Points by Perspective

Kiro's operational and architectural perspectives focus on significantly different points even when looking at the same code.

Items Emphasized by Operational Perspective (Not mentioned by architectural perspective)

🔄 CI/CD Pipeline Construction: Reducing human errors through automation
📊 Monitoring & Alert Setup: Early problem detection and response
🔍 Drift Detection: Detecting discrepancies between actual infrastructure and code
Phased Implementation Roadmap: Realistic improvement plan
Team Development Conflict Risks: Safety during multi-person work

These focus on "actual daily operational challenges".

Items Emphasized by Architectural Perspective (Not mentioned by operational perspective)

📦 Detailed Module Structure Design: Ensuring reusability and scalability
🗂️ Environment-specific Directory Separation: Logical structuring
📤 Output Structuring and Detailing: Systematic information organization
🔍 Specific Implementation of Dynamic Retrieval via Data Sources: Highly flexible design

These focus on "design considering future changes and extensions".

Important Insight: Both perspectives capture problems on different time scales. Operational perspective looks at "today and tomorrow", while architectural perspective looks at "months and years ahead".

Analysis

Value Brought by Perspective Diversity

From kiro's two-perspective comparison, we gained the following important insights:

Complementary Perspectives: Operational and architectural perspectives don't oppose each other but complement each other. Operational perspective captures "current" problems, while architectural perspective captures "future" problems.
Importance of Common Issues: Items commonly identified by both perspectives (input validation, version management, state management, security) are important matters that should definitely be addressed.
Value of Priority Differences: The difference between operational perspective's "State Management priority" and architectural perspective's "Input Validation priority" should be judged based on project circumstances (team size, development phase, risk tolerance) rather than which is correct.

Balancing Operational and Architectural Perspectives

Recommended Approach

Initial Stage: Prioritize operational perspective
- State management, security, etc., ensure basic safety
- Establish team development foundation
Growth Stage: Incorporate architectural perspective
- Code structuring, modularization
- Scalability improvement
Maturity Stage: Integration of both perspectives
- Balance operational processes and code design
- Continuous improvement cycle

Application to Development Teams

Perspective-driven reviews can provide the following benefits:

Junior Developer Growth: Learn practical skills from operational perspective reviews and design philosophy from architectural perspective reviews
Reviewer Burden Reduction: Clarifying perspectives makes review intentions clear and discussions constructive
Team Diversity Utilization: Members with different backgrounds can contribute from their respective perspectives

Importance of Code Simplicity

Through this analysis, we confirmed that "code simplicity" is valued by both perspectives:

Architectural perspective also values practical design over excessive abstraction
Operational perspective emphasizes clear, maintainable code over complex structures
Both perspectives rated the current implementation (ALB limitation handling) as "excellent" and "creative"

This is because code maintained by diverse members requires understandable and easily modifiable code.

Conclusion

New Insights from Changing Review Perspectives

From this report's analysis, the following values became clear:

Comprehensive Quality Improvement: Problems overlooked by a single perspective can be complemented by multiple perspectives
Priority Clarification: Common issues should definitely be addressed, while perspective-specific issues can be judged based on circumstances
Learning Opportunity Creation: Reviews from different perspectives provide valuable opportunities to broaden developers' horizons
Promoting Constructive Discussion: Clarifying perspectives makes "why that feedback is given" clear and deepens discussions

Recommendations for Future Review Culture

1. Perspective Clarification

Clearly marking perspectives (operational, architectural, security, etc.) in review comments makes intentions easier to understand.

2. Encouraging Diverse Perspectives

Foster a culture that actively seeks feedback from reviewers with different backgrounds within the team.

3. Accepting Gradual Improvement

Rather than seeking perfection, distinguish between operational perspective's "immediately necessary improvements" and architectural perspective's "future improvements", accepting gradual improvement.

4. Utilizing AI Reviews

As demonstrated in this report, using AI to efficiently obtain reviews from multiple perspectives can reduce human reviewer burden while improving quality.

Concrete Actions You Can Start Tomorrow

Perspective-driven reviews can be started today without special preparation.

🤖 Perspective-Specific Reviews Using Generative AI

The simplest method is to 🎯 specify perspectives when requesting reviews from generative AI:

Example 1: 🏗️ Architectural Perspective Review Request

"Please review this Terraform code from an 🏗️ architectural perspective.
Focus on design elegance, scalability, and future maintainability for feedback."

Example 2: 🔧 Operational Perspective Review Request

"Please review this Terraform code from an 🔧 operational perspective.
Focus on daily operational safety, team development practicality, and troubleshooting ease for feedback."

By simply 📝 splitting requests into two, you can gain insights from different perspectives. Please try it!

👥 Team Implementation

🏷️ Add Perspective Tags to Review Comments
- Tags like [🔧 Operational Perspective] [🏗️ Architectural Perspective] clarify intentions
📝 Specify Expected Perspectives in Review Requests
- "Please review focusing on 🔧 operational issues"
- "Could you provide feedback from a 🏗️ design perspective?"
👥 Perspective Role Assignment
- Operations staff review from 🔧 operational perspective, architects from 🏗️ design perspective
- Obtaining both perspectives enables comprehensive quality improvement

🎉 Final Words

Perspective-driven reviews are not mere "✅ checking tasks" but 👥 venues for sharing team-wide knowledge and experience. By combining 🔧 operational and 🏗️ architectural perspectives with various other viewpoints, we can build more robust and maintainable codebases.

This initiative promotes 🌱 junior developer growth, shares 👨‍💼 senior developer insights, and ultimately contributes to 📈 overall project quality improvement. Accepting perspective diversity and building better software together through constructive discussion is the essential value of development teams.

📚 References

Please feel free to check out my first post:

Understanding the Differences: Kiro IDE, Kiro CLI, and Amazon Q Developer - DEV Community

Understanding the Differences: Kiro IDE, Kiro CLI, and Amazon Q Developer

snickerjp — Thu, 27 Nov 2025 10:17:13 +0000

※ This article was researched and created by Kiro, then edited by a human.

📋 Overview

Amazon Q Developer is an AI assistant provided by AWS, available in both IDE and CLI.
In November 2025, Amazon Q Developer CLI was rebranded to Kiro CLI.

"Kiro CLI is built on top of the advanced agentic capabilities of Amazon Q Developer CLI (including agent mode, MCP, steering, and custom agents), with the addition of social login, Haiku 4.5, and an Auto agent that automatically balances performance, efficiency, and output quality."

— AWS Blog: Introducing Kiro CLI (November 18, 2025)

🔍 Key Differences

💻 VS Code Q Developer Extension vs Kiro IDE

Basic Differences

Item	VS Code Q Developer Extension	Kiro IDE
Form	VS Code extension	Standalone IDE
Foundation	Additional installation to VS Code	Built on VS Code open source
Optimization	General AI assistance	Optimized for spec-driven development
Supported Editors	VS Code, JetBrains, Eclipse, Visual Studio	Kiro IDE only
Future Updates	Migration to Kiro recommended	New features only in Kiro

"Kiro is built on top of the open source foundation of Visual Studio Code. It's provided as an IDE itself, optimized to execute a development methodology called spec-driven development."

— AWS Blog: Preparing to Switch from Amazon Q Developer IDE Plugin to Kiro (November 20, 2025)

Common Features

The following features are available in both:

Chat functionality: Questions about code, AWS service explanations
Agentic coding: Autonomous code generation assistance
Inline code completion: Real-time code suggestions
Inline chat: Direct interaction within the editor
Code transformation: Automatic upgrades for Java, .NET applications
MCP server support: Integration with Model Context Protocol servers
Workspace context: Assistance considering the entire project
Image analysis: Code generation from Figma designs or UI screenshots

Kiro IDE Exclusive Features

Spec-Driven Mode

Generates requirements, design, and tasks in 3 phases from a single prompt
Automatic generation of acceptance criteria using EARS notation
Documentation of data flow diagrams and API specifications
Task management divided into implementable units
Automatic synchronization between specifications and implementation

"Traditional AI coding assistants generate code immediately when you input a prompt, but it's unclear whether that code truly meets requirements or what design decisions were made. Kiro's Spec feature solves this problem."

Agent Hooks for Automation

Automatic task execution triggered by file save, create, or delete
Example: Automatically update English version when Japanese documentation is updated
Saved in .kiro/hooks/ and shareable via Git with team
Automatic application of coding standards and security checks

Steering (Evolution of Rules)

Project standard definitions placed in .kiro/steering/
Flexible application control through file pattern matching
Auto-generate from existing projects with "Generate Steering Docs"
Detailed control possible with frontmatter

---
inclusion: fileMatch
fileMatchPattern: "components/**/*.tsx"
---

Auto Mode (Intelligent Model Router)

Automatically selects the optimal model for each task
Combination of multiple models including Claude Sonnet 4.0, 4.5
More efficient credit usage than manual selection

Enhanced Context Management

#File, #Folder, #Problems, #Terminal, #Git Diff, #Codebase
Further evolution of Amazon Q Developer's @ specification

Smooth Migration from VS Code

Profile migration feature (extensions, themes, settings, shortcuts)
Compatibility with OpenVSX extension registry
Easy cross-machine migration with manual export/import

Amazon Q Developer Extension Supported Editors

Amazon Q Developer is available as an extension for the following editors:

Visual Studio Code
JetBrains IDEs (IntelliJ IDEA, PyCharm, etc.)
Eclipse
Visual Studio

⚠️ Currently Unimplemented Features

Kiro IDE:

Security Scan: Not implemented as of November 20, 2025
Alternative: Amazon Inspector Code Security
Or continue using Amazon Q Developer IDE plugin

⌨️ Q Developer CLI vs Kiro CLI

Important: Kiro CLI is a rebrand of Q Developer CLI.

Item	Q Developer CLI	Kiro CLI
Brand Name	Amazon Q Developer CLI	Kiro CLI
Basic Features	Same	Same + Additional features
Future Updates	Migration to Kiro recommended	New features only in Kiro
Documentation	AWS Documentation	kiro.dev/docs/cli

Main Features (Available in Both)

Terminal interaction: Interact with Kiro services from command line
Code transformation: Java upgrades, SQL conversion
Local builds: Local conversion and building of applications
Branch management: Automatic branch creation and commits
MCP configuration: Configuration of local and remote MCP servers
Authentication: Authentication via IAM Identity Center

Kiro CLI Additional Features

"Kiro CLI is built on top of the advanced agentic capabilities of Amazon Q Developer CLI, with the following additional features"

Custom Agents

Create AI agents specific to workflows
Automatic execution with pre-approved tools
Persistent context (project files, documentation)
Access control and tool restrictions
Examples: Backend specialist, frontend specialist, DevOps agent

{
"name": "backend-specialist",
"description": "Expert in building Express.js APIs with MongoDB",
"tools": ["fs_read", "fs_write", "execute_bash"],
"toolsSettings": {
    "fs_write": {
    "allowedPaths": ["src/api/**", "tests/api/**"]
    }
}
}

Flexible Authentication Options

GitHub account
Google account
AWS Builder ID
AWS IAM Identity Center

Auto Agent

Automatically selects the optimal model for each task
Automatically balances speed, cost, and quality
Approximately 30% more efficient than manual selection (1.3X → 1.0X credits)

Visual Indicators

Visualization of context usage (/context command)

Display of credit usage

Multimodal Input

Direct reference to images (screenshots, diagrams, error messages)

Full Integration with Kiro IDE

Shared .kiro/settings/mcp.json
Shared .kiro/steering/*.md steering rules
Shared project documentation
Single configuration for both environments

Reference: AWS Blog: Introducing Kiro CLI

Color Scheme Changes

Amazon Q Developer CLI: Red (pink) based

Kiro CLI: Purple prominent

🔄 About Upgrades

"Amazon Q Developer and Kiro are separate products with independent subscription systems. Even if you have an Amazon Q Developer Pro subscription, it won't automatically migrate to Kiro, and manual upgrade is required."

— AWS Blog: Kiro Implementation Guide (November 19, 2025)

Amazon Q Developer Pro Users

If Maintaining Current Status

Can use Kiro CLI and Kiro IDE at Pro plan equivalent
Existing Amazon Q Developer Pro features continue to be available
Limitation: Cannot change to higher plans (Pro+, Power)

If Fully Migrating:

Amazon Q Developer Pro subscription will be canceled
Complete migration to Kiro Pro plan or higher
Ability to change to higher plans becomes available

Kiro CLI Auto-Update

November 17, 2025: Manual update available (q update command)
November 24, 2025: Automatic update executed
Configuration files copied from .amazonq to .kiro
Auto-update can be disabled (not recommended due to security patches)

Individual Account Users

Can upgrade Q CLI and Amazon Q extension to Kiro (optional)
After upgrade, all Amazon Q components automatically update to Kiro
Future new features will only be provided in Kiro

Amazon Q Developer Pro Administrators

Use Kiro Console to manage user subscriptions
Kiro Console is a rebrand of Amazon Q Developer Console (same functionality)
Recommend users to upgrade IDE extensions and CLI to Kiro

💳 Plan Structure and Pricing

Kiro Plans

Kiro adopts a unified credit system. Vibe mode and Spec mode requests are consumed from a single credit pool.

Plan	Key Features
Free	Experience basic code generation and spec-driven development
Pro	For standard development teams
Pro+	More credits
Power	For large-scale development

Authentication Methods and Billing

Authentication Method	Supported Plans	Payment Method
AWS IAM Identity Center	Pro / Pro+ / Power	AWS Account (billing consolidation)
Builder ID	Free / Pro / Pro+ / Power	Credit card
GitHub	Free / Pro / Pro+ / Power	Credit card
Google	Free / Pro / Pro+ / Power	Credit card

Recommendation for Enterprise Use: Kiro Pro plan or higher + AWS IAM Identity Center

Enables AWS billing consolidation, organization-level usage management, per-user plan assignment, and MCP management

Limitations for New Kiro Users

If you newly subscribe to Kiro Pro plan or higher:

✅ Available

Kiro IDE / Kiro CLI
Amazon Q Developer IDE plugins (Visual Studio, Eclipse, JetBrains)
※ Consumes Kiro credits

❌ Not Available

Amazon Q Developer Pro in AWS Management Console
Integration with various AWS services (Amazon SageMaker, etc.)

⚙️ Management Features and Security

This section is based on information as of November 21, 2025. Please check the official documentation for the latest information.

MCP Control and Overage

MCP Control

Administrators can control MCP availability across the organization

Overage

Can continue using after exceeding monthly credit limit
Price: 0.04 USD/credit
Default: Disabled
Administrators opt-in via Kiro Console

Network Configuration

Firewall/Proxy Support

Authentication endpoints (IAM Identity Center, OIDC, etc.)
Kiro service endpoints
Telemetry endpoints

Private Network Access

VPC Endpoint (PrivateLink) support
Service names:
com.amazonaws.us-east-1.q
com.amazonaws.eu-central-1.q
com.amazonaws.us-east-1.codewhisperer
Private connection possible without going through the internet

📝 Summary

Kiro CLI is a rebrand of Amazon Q Developer (November 2025)
Basic features are the same, but Kiro has many additional features
Kiro IDE: Spec-driven mode, Agent Hooks, Steering, Auto mode
Kiro CLI: Custom agents, flexible authentication, multimodal input
Both IDE and CLI are subject to rebranding
Future new features will only be provided in Kiro
Upgrade is optional, but recommended to use the latest features