Forem: Anuraj S.L

How Global Steering Revolutionizes SDLC using Amazon KIRO

Anuraj S.L — Mon, 30 Mar 2026 21:30:33 +0000

Say Goodbye to Repetitive Setup: How Global Steering Revolutionizes Project Management

You've told your AI assistant a dozen times that you prefer functional React components. You've re-explained your Git conventions at the start of every project. You've copy-pasted the same security policies into yet another workspace. Sound familiar?

Here's the thing: most of what you tell your AI coding assistant isn't project-specific. Your coding style, testing philosophy, security standards — they stay the same whether you're building a fintech API or a personal side project. So why are you repeating yourself every single time?

This is exactly the problem that Global Steering in Kiro was built to solve.

What Is Steering?

Steering is persistent AI context. It's a collection of markdown files that give Kiro knowledge about your preferences, standards, and architectural decisions before it starts working on your code. Instead of re-explaining the same conventions in every chat session, you write them once in a steering file, and Kiro reads them automatically with every interaction.

There are two scopes for steering files:

Workspace steering — lives in your project at .kiro/steering/ and applies only to that specific workspace.
Global steering — lives in your home directory at ~/.kiro/steering/ and applies to every workspace you open.

Global steering is the key ingredient here. Any markdown file you place in ~/.kiro/steering/ becomes available to Kiro across all your projects, automatically. No copying, no pasting, no forgetting.

Why Global Steering Changes the Game

One Folder, Infinite Projects

Think of global steering as your .bashrc for AI context — configuration that follows you everywhere. Write your coding style preferences, security policies, testing philosophy, and documentation standards once, and they become the foundation for every project you touch.

For a developer working across 20 projects a year, that's hours of repetitive setup eliminated. For a team of 50? The savings compound fast.

The Best of Both Worlds

Universal rules are great, but flexibility matters. Global Steering lets you layer your instructions:

Global steering (~/.kiro/steering/) defines your baseline — coding style, security requirements, accessibility standards.
Workspace steering (.kiro/steering/) adds project-specific context — the tech stack, product domain, file structure.

When there's a conflict between global and workspace instructions, workspace steering takes precedence. This means you can set broad defaults globally and override them for specific projects when needed. It's not one-size-fits-all — it's sensible defaults with surgical overrides.

Seamless AGENTS.md Compatibility

Kiro fully supports the AGENTS.md standard. You can place AGENTS.md files in your global steering folder (~/.kiro/steering/) or in the root of any workspace, and Kiro picks them up automatically. Note that AGENTS.md files don't support Kiro's inclusion modes — they're always included. But if you already have agent instructions written in this format, they'll work out of the box.

Instant Team Alignment

For teams, global steering is a serious productivity lever. Organizations can distribute standardized steering files to every developer through:

Version-controlled repositories — maintain a shared repo of company-wide steering files. Developers clone it during onboarding and symlink or copy the files to ~/.kiro/steering/. A simple setup script automates the whole process.
MDM solutions (Jamf, Intune, Group Policies) — push steering files directly to ~/.kiro/steering/ on every developer's machine. Zero manual setup, centralized policy management, and automatic updates when standards change.

New team members inherit your team's exact coding standards the moment they start working with Kiro. No forgotten policies, no drift, no onboarding friction.

What Belongs in Global Steering?

Focus on what's consistent across your work, regardless of the project:

🎨 Coding style — component patterns, naming conventions, formatting preferences
🧪 Testing philosophy — coverage expectations, test file organization, mocking approaches
🔒 Security requirements — authentication standards, input validation, data handling rules
📝 Documentation standards — comment styles, README templates, API documentation formats
🏗️ Architecture principles — design patterns, dependency management, error handling strategies

What NOT to include: API keys, secrets, database credentials, internal URLs, customer data, or any PII. Steering files are plain-text markdown — treat them like code that could be shared.

Smart Inclusion Modes

Not every steering file needs to load every time. Kiro offers four inclusion modes to keep context relevant:

Mode	Front Matter	Behavior
Always (default)	`inclusion: always`	Loaded in every interaction. Use for core standards.
Conditional	`inclusion: fileMatch`	Loaded only when working with files matching a pattern (e.g., `components/*/.tsx`).
Manual	`inclusion: manual`	Available on-demand via `#steering-file-name` in chat.
Auto	`inclusion: auto`	Automatically included when your request matches the file's description.

This means your React component guidelines only load when you're editing .tsx files, and your deployment runbook only appears when you ask about deployments. Clean, focused context.

A Real-World Example

Say you're a full-stack developer working across client projects, open source, and side projects. Your global steering folder might look like:

~/.kiro/steering/
├── style.md              # Functional components, Prettier with semicolons
├── accessibility.md      # Semantic HTML, ARIA attributes, alt text
├── testing.md            # Jest, 80% coverage, tests in __tests__/
└── security.md           # Input validation, auth patterns, OWASP basics

Now you start a new e-commerce project. Your workspace steering adds the specifics:

.kiro/steering/
├── tech.md               # Next.js, TypeScript, Tailwind CSS
├── product.md            # Product data models, cart logic
└── structure.md          # Components in src/components/

When you ask Kiro to "Create a new ProductCard component," it reads both layers and generates a functional TypeScript component using Tailwind, with proper semantic HTML and accessibility attributes, placed in the right directory with a test file — all matching your personal coding style. No instructions needed.

Getting Started in 3 Steps

Step 1: Create your first global steering file. Pick the thing you repeat most — usually coding style:

mkdir -p ~/.kiro/steering

Create ~/.kiro/steering/style.md with your preferences in plain markdown.

Step 2: Test it. Open any project in Kiro and ask it to generate some code. It should follow your style preferences without you mentioning them.

Step 3: Expand gradually. Add more files as you notice patterns you keep repeating. Build your steering library organically.

The Bottom Line

Global Steering turns your accumulated development wisdom into persistent, portable AI context. Write your standards once in markdown, drop them in ~/.kiro/steering/, and Kiro follows them everywhere — across every project, every language, every team member.

No more copy-pasting. No more forgotten policies. No more explaining yourself for the 48th time.

What will you put in your global steering? Share in the comments

Sources: Kiro Steering Documentation, Kiro Blog - Stop Repeating Yourself.

I Built a CLI That Catches What AI Coding Tools Break

Anuraj S.L — Sun, 29 Mar 2026 19:44:09 +0000

I've been using AI tools (Claude, Antigravity, Kiro, Copilot, Cursor) to build software for the past year. They're incredible at writing code but terrible at remembering what depends on what.

Here's a scenario every AI-assisted developer knows:

You ask the AI to refactor your user model.

It does a great job. Clean code, good types, well-structured.

What it doesn't know is that six other files import from that model. Your auth service, your cart controller, your API docs, your validation middleware. All of them still reference the old interface. The AI has no idea they exist.

You don't notice either. Not until something breaks in production three sessions later.

The pattern I kept seeing:
After about 40 development sessions, I started tracking these failures.

They fell into three buckets:

Anchor drift. A core file changes, but everything that depends on it stays stale. The AI modified the source of truth without updating the consumers.
Context loss. Session crashes, token limits hit, or I simply started a new day. The AI had zero memory of what we decided yesterday, what was half-finished, or which files were in a fragile state.
Silent regressions. Tests quietly removed. Files growing past 500 lines. Documentation falling weeks behind the code. Nobody checking because there was no system to check.

These aren't bugs in the AI. They're structural problems. The AI is stateless. It can't track cross-file dependencies across sessions. That's not its job. But someone needs to.

So I built TRACE

TRACE is a CLI tool that enforces structural coherence in AI-augmented codebases. It's not a linter. It's not a test runner. It's a system that understands which files are your sources of truth (anchors), which files depend on them (consumers), and whether everything is still in sync.

npm install -g trace-coherence

Here's what a typical session looks like:

# Start of session
$ trace gate start

━━━ Start Gate — MyProject ━━━

✓ TRACE state exists
✓ Baseline tests passing (37/37)
✓ No unresolved debt (0/5)
✓ Integrity checksums verified
✓ Config validation passed
✓ AI context generated

GATE PASSED — Session open.

That last line, "AI context generated", creates a file called .trace/AI_CONTEXT.md that contains only what's relevant to this session: which anchors exist, which consumers depend on them, any outstanding debt, current plan items. Your AI tool reads this and has focused context instead of fumbling through the whole project.

The anchor-consumer model
The core concept is simple. In trace.yaml, you declare which files are anchors (sources of truth) and which files consume them:

yamlanchors:
  - id: user_model
    file: src/models/user.ts
    consumers:
      - src/services/auth.service.ts
      - src/controllers/user.controller.ts
      - src/middleware/validation.ts
      - src/routes/user.routes.ts
      - docs/api/users.md

Now TRACE knows the dependency graph. When user.ts changes but auth.service.ts doesn't, that's a coherence violation. The gate end check catches it:
bash$ trace gate end

━━━ End Gate — MyProject ━━━

✗ Consumer sync: user_model anchor modified,
but 3 consumers not updated:

src/services/auth.service.ts
src/middleware/validation.ts
docs/api/users.md

GATE BLOCKED — Fix consumer drift before closing.
This is what makes TRACE different from a linter. A linter checks syntax. TRACE checks whether your changes are structurally complete. Did you update everything that needed updating? Did you leave any file in a state that contradicts another file?

Two ways to start
New project:trace init
Creates trace.yaml and the .trace/ directory. All gates default to "block" mode. Full enforcement from the start.

Existing project:trace scan
This is where it gets interesting. trace scan does a 4-phase analysis of your codebase:

Scans all files and identifies likely anchors (files with many importers)
Maps consumer relationships from import/require statements
Detects existing test infrastructure and quality tools
Auto-calibrates complexity thresholds based on your actual codebase

It generates a trace.yaml with everything pre-configured. Gates default to "warn" mode so nothing blocks your existing workflow. This is the "Clean as You Code" approach borrowed from SonarQube: pre-existing issues get a baseline pass, new code is fully enforced.

What else it does
22 commands total. Here are the ones I use most:

trace impact user_model   # Show blast radius before coding
trace checkpoint          # Crash recovery + auto-observation
trace plan add "Auth refactor" --priority high
trace plan move ITEM-003 done
trace plan release v1.2.0   # Auto-generate release notes
trace ci --json           # PR-scoped analysis for CI/CD
trace license           # Dependency license compliance check
trace validate         # Config check with "did you mean?" typo detection

The planning system is a YAML-based Kanban board. No infrastructure. No SaaS. Just a file in your repo that tracks what's todo, in progress, done, or deferred. trace plan release turns completed items into formatted release notes.

The CI command only checks files changed in the current PR. It can output JSON and generate GitHub PR comments automatically. No need to run full-project analysis on every push.

Zero network calls. Runs entirely offline.

It works with any language (TypeScript, Python, Go, Java, Rust). Any AI tool (Claude, Copilot, Cursor, ChatGPT). Any CI system (GitHub Actions, GitLab CI, Jenkins).

What it costs in tokens
About 1,000 to 2,000 tokens per session for reading the AI context file and running gates. But it prevents the 50,000+ token debugging sessions that happen when drift goes undetected. The math works out heavily in your favor.

What I learned building it
The biggest insight: AI tools are excellent at local reasoning (this file, this function) but have no mechanism for global reasoning (across files, across sessions). TRACE fills that gap. It's not competing with the AI. It's providing the structural memory that AI can't maintain on its own.
The second insight: "Clean as You Code" is the only adoption strategy that works for existing projects. Nobody will stop everything to retrofit coherence checks. But if you only enforce rules on new code, people adopt it naturally because it never blocks them on old problems.

Try it
npm install -g trace-coherence

cd your-project
trace scan
trace gate start

GitHub: https://github.com/anurajsl/trace

I built this because I needed it. If you're using AI tools to write code and have ever been burned by cross-file drift, give it 5 minutes.

Happy to answer questions in the comments.

Building AI Agents That Actually Work: A Developer's Reality Check

Anuraj S.L — Mon, 22 Sep 2025 18:01:45 +0000

Everyone's talking about 2025 being "the year of AI agents." But after digging into what's actually happening in production environments, I've learned the conversation needs to shift from hype to honest implementation.

The Promise vs. The Reality

The tech news cycle wants you to believe autonomous AI agents will revolutionize everything overnight. Meanwhile, developers building these systems are learning something different: the gap between a working demo and a production system is massive.

Here's what caught my attention: a recent study found that experienced developers actually took 19% longer to complete tasks when using AI tools. Not because the tools don't work, but because the real world is messier than benchmarks suggest.

And the numbers get worse from there. When you chain agent actions together, error rates compound exponentially. A system with 95% reliability per step drops to just 36% success over 20 steps. In production, you need 99.9%+ reliability, which is why 76% of developers still won't use AI for deployment and monitoring tasks.

Choosing Your Framework: It's Not Just About LangGraph

The agent framework landscape is crowded, and each takes a different philosophy:

LangGraph gives you graph-based control where you explicitly manage state and flow. Companies like LinkedIn, Uber, and Klarna use it because it prioritizes control over convenience. If you need to see exactly what's happening at each step, this is your tool.

CrewAI focuses on multi-agent teams with role-based coordination. Think of it as organizing AI agents like you'd organize a human team, with specialized roles and collaboration protocols. Great when you have clearly defined responsibilities.

AutoGen from Microsoft emphasizes conversational multi-agent systems with built-in human-in-the-loop patterns. It's designed around the idea that agents should communicate like people do.

Semantic Kernel integrates tightly with Azure and the Microsoft ecosystem. If you're already invested there, it reduces friction.

The real question isn't which framework is "best"—it's which matches your team's skills and your specific use case. Stack Overflow's 2025 survey shows Ollama (51%) and LangChain (33%) leading adoption among developers building agents, but that's correlation, not causation.

The Three Things That Actually Matter

After reviewing dozens of production implementations, three patterns emerge for successful agent systems:

1. State Management Is Your Foundation

Most agent failures trace back to context problems. The LLM doesn't have the right information at the right time. This is why stateful frameworks like LangGraph work—they make context explicit and trackable.

Instead of hoping your agent remembers what happened three steps ago, you design exactly what information persists and how it flows between operations. This isn't sexy, but it's what separates toys from tools.

2. Humans Stay in the Loop

The agents that work in production aren't fully autonomous. They're collaborative.

Your code review agent? It flags issues and suggests fixes, but a developer approves changes. Your database agent? It generates SQL queries, but requires confirmation before execution. The pattern repeats: AI handles complexity, humans handle judgment.

This isn't a limitation—it's a design choice. Recent data shows 70% of successful agent implementations include human approval steps. The teams skipping this step are the ones dealing with production incidents.

3. Tool Design Matters More Than Model Choice

Here's the part that surprised me: the quality of your tools matters more than which LLM you use.

Every tool you give an agent needs careful design. How does it communicate success? What happens on partial failures? How do you avoid burning through context with verbose responses?

The real engineering challenge isn't prompt writing—it's building an ecosystem of tools that agents can actually use effectively.

What This Means for Your Organization

If you're a technical leader evaluating agents, here's the business perspective that matters:

Cost Reality: Context windows create quadratic token costs. A single long-running agent conversation can cost 10-100x more than you'd expect from simple calculations. Budget accordingly and build cost monitoring from day one.

Time to Value: The companies seeing ROI are those starting with narrow, well-defined use cases. Wells Fargo processed 245 million interactions successfully—but they didn't start there. They started small and scaled what worked.

Team Impact: 52% of developers report AI tools improved their productivity, but that's heavily dependent on use case. The gains come from automation of specific tasks (documentation, code review, testing), not wholesale replacement of workflows.

Risk Management: For compliance-heavy industries, you need audit trails, rollback mechanisms, and human oversight. Most organizations aren't agent-ready from a governance perspective. The technical work is building APIs and integration points; the harder work is policy and process.

The question isn't "should we use agents?" It's "which specific problems justify the engineering investment, ongoing costs, and operational overhead?"

Getting Started Without Drowning

If you're thinking about building with agents, start small:

Pick one specific problem where automation would genuinely help. Not "automate our entire codebase" but "flag potential security issues in pull requests" or "generate API documentation from code."

Build with these principles:

Explicit over implicit: Make your agent's decision points visible
Bounded over broad: Narrow scope leads to better results
Monitored over autonomous: Observability isn't optional

Use the ReAct (Reasoning and Acting) pattern. Let your agent think through problems step by step, use tools to gather information, then observe results before deciding what's next. This creates an audit trail and makes debugging actually possible.

The Production Checklist

Before you deploy, you need:

Observability: Can you see what your agent is doing at each step? According to the latest Stack Overflow survey, 43% of teams use Grafana + Prometheus for agent monitoring—they're adapting traditional DevOps tools because AI-native solutions aren't mature yet.

Cost controls: Long conversations get expensive fast. Design with limits in mind. Set budgets per conversation, implement caching strategies, and monitor token usage religiously.

Error handling: What happens when a tool fails? When the LLM returns unexpected output? When external APIs are down? Your agent needs graceful degradation, not silent failures.

Testing infrastructure: You can't just "try it and see." You need systematic evaluation of both outputs and the execution path. Did it work? Did it work the right way?

What's Actually Working

The successful agent implementations I've seen share a pattern: they're not trying to replace humans, they're augmenting specific workflows with clear boundaries.

A self-documenting code system that adds docstrings and flags issues? That works. An agent that tries to understand requirements, write code, test it, and deploy it? That's still science fiction.

The difference is scope. The first has clear inputs, defined outputs, and measurable success. The second has too many variables and too many ways to fail.

The Honest Truth About 2025

AI agents will be everywhere this year, but probably not how you think.

We'll see more copilots and assistants. More tools that make developers faster at specific tasks. More systems that handle the boring parts so humans can focus on the interesting problems.

What we won't see—despite the headlines—is fully autonomous systems replacing development teams. The math doesn't work. The reliability isn't there. The trust hasn't been earned.

And honestly? That's fine. The real value isn't in replacement, it's in partnership. Build systems that make your team faster, not systems that try to replace them.

Where to Go From Here

If you're building agent systems:

Start with problems, not technology. Don't build an agent because agents are hot. Build one because you have a specific workflow that needs automation.

Choose your battles. Some tasks are perfect for agents (documentation, analysis, pattern matching). Others aren't (deployment, architecture decisions, anything requiring deep business context).

Invest in your tools. The framework matters, but your tool library matters more. Build reusable components that future agents can leverage.

Monitor everything. Production agents need production observability. Invest in tracing, logging, and evaluation from day one.

The agent revolution might not look like the one in the headlines, but it's real. The teams winning are the ones building deliberately, not desperately chasing hype.

If you've tried agents in production, what worked—and where did they break down? I'm especially interested in hearing about unexpected costs, reliability issues, or use cases that succeeded against expectations. Sharing real stories will help the community cut through the hype and focus on what actually delivers value.