Stop Writing Prompts. Start Engineering AI Systems.

Kseniya Seliverstava — Wed, 25 Feb 2026 20:36:54 +0000

Status: Draft.

Most teams think they are building with AI.

Most are just prompting.

The difference between a chatbot user and an AI engineer is not creativity.

It is the ability to turn LLM behavior into a controlled, testable, secure product system.

1. The Real Upgrade: From Prompt to Engineering Loop

In classical software, you write deterministic code.

In AI systems, behavior is probabilistic.

You don’t hardcode logic. You shape it.

The hard problem isn’t generating text.

It’s controlling behavior across thousands of interactions.

Control comes from engineering the loop.

The AI Engineering Loop

+------------------+
|       GOAL       |
+------------------+
          ↓
+------------------+
| SUCCESS CRITERIA |
+------------------+
          ↓
+------------------+
|    TEST CASES    |
+------------------+
          ↓
+------------------+
| PROMPT + CONTEXT |
|     VERSION      |
+------------------+
          ↓
+------------------+
|   MEASUREMENT    |
+------------------+
          ↓
+------------------+
|    ITERATION     |
+------------------+
          ↺

If you do not define success before writing prompts, you are not engineering.

If you do not test behavior across structured cases, you are not engineering.

If you cannot compare versions and measure improvement, you are not engineering.

You are experimenting.

2. Prompt Engineering Is Table Stakes

A predictable prompt contains structure:

ROLE
CONTEXT
TASK
CONSTRAINTS
REFERENCES (examples and anti-examples)
OUTPUT FORMAT

This increases reliability.

But prompt structure is like a function signature.

Necessary. Not sufficient.

The moment you ask:

What happens after 20 turns?
What happens across 1,000 users?
What happens under adversarial input?
What happens when tools execute real actions?

You are no longer designing prompts.

You are designing systems.

3. Context Engineering: The Discipline Most Teams Miss

Prompt engineering is about what you say.

Context engineering is about what the model sees.

In production, the model’s context window contains:

System instructions
Conversation history
Retrieved documents
Tool outputs
Memory summaries
Integration state

All of this competes for finite tokens.

Tokens are a scarce resource.

Add too much context → attention dilutes.

Add irrelevant context → reasoning collapses.

Mix instructions with untrusted data → behavior shifts unpredictably.

This is not a bug.

It is physics.

Context Window Architecture

+------------------------------------------------------+
| CONTEXT WINDOW |
+------------------------------------------------------+
| [SYSTEM INSTRUCTIONS] |
| - Role |
| - Rules |

- Constraints
[RETRIEVED DOCUMENTS]
- High-signal chunks only
------------------------------------------------------
[TOOL RESULTS]
- DB queries
- Code output
------------------------------------------------------
[CONVERSATION MEMORY]
- Summarized prior turns
+------------------------------------------------------+

If you dump everything into context, quality degrades.

If you curate aggressively, stability improves.

RAG is not a feature.

It is memory architecture.

External knowledge must be:

Indexed
Chunked correctly
Ranked
Injected with discipline

Poor retrieval destroys generation quality.

4. Tool Use: When Text Becomes Action

The moment your model can call tools, you do not have a chatbot.

You have an agent.

A minimal agent loop looks like this:

User Request
↓
Model decides: Tool needed?
↓
[tool_use call]
↓
External Tool Executes
↓
[tool_result returned]
↓
Model continues reasoning
↓
Final Output

This is how you build:

AI-assisted coding systems
Database-backed assistants
Autonomous workflows
CI-integrated agents

But tools increase leverage and risk simultaneously.

You must validate:

Tool inputs
Tool outputs
Execution boundaries
Failure states

Otherwise your system will act incorrectly with confidence.

5. Security Is Architectural

Large language models blur the boundary between:

Instructions
Data

If untrusted content enters the same context space as system rules, behavior can be manipulated.

This is structural.

Not edge-case.

Security must be built into the loop:

Separate system rules from user content
Sanitize retrieved documents
Validate tool calls
Include adversarial test cases
Run red-team scenarios

If your agent can act, it can be exploited.

Design accordingly.

6. The AI Product System Stack

An AI-native product is not:

Model + Prompt.

It is a layered system.

+--------------------------------------------------+
| AI PRODUCT SYSTEM |
+--------------------------------------------------+

1. Prompt Specification (versioned)
2. Context Architecture Map
--------------------------------------------------
3. Retrieval Layer (memory + chunking strategy)
--------------------------------------------------
4. Tool Layer (controlled action surface)
--------------------------------------------------
5. Evaluation Suite (automated + human review)
--------------------------------------------------
6. Security Layer (injection defenses)
--------------------------------------------------
7. Iteration Loop (continuous improvement)
+--------------------------------------------------+

Without these layers, you do not have a product.

You have a demo.

7. Visual Checklist: AI Product Builder Kit

Use this as a founder checklist.

Day 1 — Define Success

User persona
Core workflow (5–7 steps)
Explicit success metrics
Defined failure cases
Risk list

Artifact: LLM Success Spec

Day 2 — Prompt Library

Role-based system prompts
Few-shot examples
Anti-examples
Output contracts

Artifact: Promptbook v1

Day 3 — Context Map

What belongs in system?
What is retrieved?
What is memory?
What is dynamic state?
Chunking strategy

Artifact: Context Architecture Diagram

Day 4 — Tool Loop

Implement 2–3 meaningful tools
Validate inputs
Log usage
Test failures

Artifact: Tooling Spec + Working Tool

Day 5 — Evaluation Suite

30–60 test cases
Normal cases
Edge cases
Adversarial cases
Automated scoring

Artifact: Eval Suite v1

Day 6 — Prototype

AI-assisted implementation
Integrated test harness
Minimal deployable system

Artifact: Working Prototype

Day 7 — Ship Discipline

Full evaluation run
Context cleanup
Security review
Version documentation

Artifact: AI Product Builder Kit v1

Final Thought

Model access is becoming a commodity.

Prompt tricks are a commodity.

API integration is a commodity.

What is not a commodity:

Evaluation discipline
Context architecture
Secure tool integration
Iteration velocity

The moat is not who has the best model.

It is who builds the best systems around models.

That is engineering.

And that is how AI-native companies win.

AWS App Mesh Deprecated: Migration Guide Before September 2026 Shutdown

Kseniya Seliverstava — Sun, 15 Feb 2026 21:25:26 +0000

AWS App Mesh End of Life: September 30, 2026.[¹] New customers locked out since September 24, 2024. Existing customers have 8 months to migrate. Only critical security updates until shutdown.

AWS Official Replacements for App Mesh

ECS Service Connect (for ECS) - AWS-managed mesh without sidecars
VPC Lattice (for EKS) - Application networking across VPCs and accounts
Direct ALB routing - Simplest option for basic use cases

Real-World Migration Case Study

Migrated one production service: App Mesh → Direct ALB

Timeline: ~6 hours total

Active migration: 2 hours
Troubleshooting: 4 hours

Breakdown:

Planning & setup: 30 min
Task definition changes: 15 min
Service deployment: 20 min
Security group fixes: 1 hour
Health check troubleshooting: 2 hours
ALB configuration: 15 min
Testing: 1 hour

Results: Zero downtime. Full App Mesh removal. Instant rollback capability maintained.

Key insight: First service takes 4-6 hours (learning curve). Subsequent services: 1-2 hours each.

Critical Pre-Migration Requirements

Rollback Strategy is Non-Negotiable

Ensure all changes are reversible
Don't remove App Mesh infrastructure until new setup is validated in production
Avoid destructive configuration changes
Maintain instant revert capability

Phased Migration Approach

Deploy new configuration alongside existing App Mesh
Test thoroughly without affecting production traffic
Gradually shift traffic to new infrastructure
Validate stability and performance
Remove App Mesh components only after proven success

Common Migration Challenges

Security Groups: Update rules for direct service-to-service communication (no more Envoy proxies)

Health Checks: Reconfigure ALB health checks for direct container access

Service Discovery: Implement AWS Cloud Map or ALB target groups

Migration Resources

Action Required: 8 months until shutdown. Start migration planning now.

DEV Community: Kseniya Seliverstava