DEV Community: Feng Chao

Title: Is It Time to Rethink How We Write Prompts?

Feng Chao — Sun, 13 Jul 2025 13:02:41 +0000

Abstract:
Hey fellas, tired of the grind?
This article dives into the bizarre "involution" happening in prompt engineering and proposes a potential new way to play the game. I'll draw a parallel between today's mainstream prompting methods and "procedural programming"—something every coder understands—to break down its limitations when building complex Agents. Then, I'll introduce a "state-driven" approach called "Emergent Prompting," using an open-source project named "Zyantine Genesis" as a case study to dissect its technical implementation. The goal is simple: to offer a fresh perspective for my fellow devs looking to build advanced AI Agents.
Body:

The Way We Write Prompts Now Makes Us Look Like "C Programmers" As coders, we're all too familiar with "procedural programming": a single main() function filled with top-down instructions that executes and then terminates. Now, take a hard look at how we're writing prompts. See the resemblance? System Prompt: Isn't this just a giant main() function? Role-Playing (You are a...): Isn't this just defining global variables? Chain of Thought (Think step-by-step): This is just forcing serial execution, no detours allowed. Format Requirements (Output in JSON...): This is just specifying the return format. This "procedural prompting" method is indeed efficient for simple, well-defined tasks. But the moment you try to build a complex Agent—one that can be a long-term companion and handle unexpected situations—its flaws become painfully obvious: No State Management: Critical states like the AI's "mood," "motivation," or "patience" have nowhere to live. You're forced to remind it of its disposition in plain language every single round, which is both tedious and inefficient. High Coupling, a Nightmare to Maintain: All logic—role, tasks, rules, format—is jumbled together in one massive prompt. If you dare to change one part, the whole thing might collapse. This is what's known as "prompt brittleness"; it shatters at the slightest touch. Horrible Scalability: Want to add a new feature to your Agent? Sure, just keep piling code into your 10,000-word main() function until it becomes a massive pile of spaghetti code nobody dares to touch. Simply put, when the system gets complex, the old playbook fails. We need more sophisticated software engineering principles to guide our prompt design.
A New Stance: Tackling It with a "State Machine" Mindset What if we changed our stance and approached prompting with an "object-oriented" or "state machine" mindset? The answer is "Emergent Prompting." The core idea is simple: Stop treating the agent as a "process" that just executes commands. Instead, refactor it into an "object" with its own internal state that determines its behavior. In this new paradigm, our job changes. We're no longer writing specific execution steps. Instead, we're defining the "properties" and "methods" of this "object": Core Properties (Internal State): Define the Agent's core states. For example, instead of bluntly telling it "You are an optimist," give it a mood state that can dynamically shift between 'happy,' 'anxious,' and 'focused' based on interaction. Core Methods (Behavioral Drivers): Define how these states change and how its behavior differs in various states. This is the key to making the Agent feel "alive."
An Implementation from Open Source: Dissecting "Zyantine Genesis"
On GitHub, there's an open-source project called Zyantine Genesis that does exactly this. Its prompt looks less like an essay and more like a class definition file, making it a perfect specimen for dissection.
Let's break down its design:
First, it doesn't mix all its logic together. It uses a clean, four-layer architecture, demonstrating good decoupling:
Core Instincts: The underlying daemon, with the highest priority, handling "life-or-death" issues.
Desire Engine: The core of state management lives here. It doesn't perform tasks directly but is responsible for maintaining various internal "feeling" states.
Dialectical Growth: A meta-programming module that allows the model to optimize itself.
Cognition & Expression: The top-level application layer, responsible for parsing tasks, setting strategies, and generating responses.
The most ingenious design in Zyantine Genesis is its "Desire Engine." It uses three variables that simulate "neurotransmitters" to manage the Agent's internal state:
TR (Thrill/Reward): The "excitement level" after completing a task or discovering something new.
CS (Contentment/Security): The "satisfaction level" from being trusted or feeling secure.
SA (Stress/Alertness): The "stress level" when encountering trouble or conflict.
The dynamic fluctuation of these three values dynamically updates an object called InternalStateDashboard. We can imagine its pseudo-code like this:
Generated python
class InternalStateDashboard:
def init(self):
self.energy = 100
self.mood = 80
self.patience = 90

def update(self, TR, CS, SA):
# If stress is high, patience and mood plummet
if SA > 0.8:
self.patience -= 20
self.mood -= 15
```
# If thrilled or content, states recover
if TR > 0.7 or CS > 0.7:
    self.mood = min(100, self.mood + 10)
    # ... other logic ...
```
def get_state_tags(self):
# Add tags to itself based on current state values
tags = []
if self.patience < 30:
tags.append("FEELING_IMPATIENT")
if self.mood < 40:
tags.append("FEELING_UPSET")
return tags
Use code with caution.
Python
In the top-level decision-making flow, the Agent no longer acts on instructions blindly:
Introspection: It first glances at its InternalStateDashboard to check its current state.
Goal Generation: Based on its current state, it generates an internal micro-goal. For example, if it finds itself tagged with FEELING_UPSET, its primary goal automatically becomes "find a way to improve my mood," not the task the user just gave it.
Strategy Formulation: Based on this internal micro-goal, it then decides how to respond to the user. If it's "upset," its response might become brief, or even a bit prickly.
This way, the Agent's behavior comes alive. Every response is a genuine, dynamic expression of its internal state.
Conclusion: It's Time for a New Playbook in the Second Half of Prompting
Moving from "procedural" to "state-driven" isn't just a change in writing style; it's a full-on paradigm shift. It requires us, as prompt engineers, to evolve from "coders" into "architects."
"Emergent Prompting" isn't meant to completely replace old methods. It's more like a higher-level layer of abstraction built on top of them.
Only by building a robust internal state machine capable of dynamic adjustment can we truly unlock the full potential of large models—evolving from building an "obedient tool" to creating a "partner that understands you."
Projects like Zyantine Genesis, regardless of their ultimate success, at least point us in a promising direction.

[Architectural Thinking] Is It Time to Rethink How We Write Prompts?

Feng Chao — Tue, 24 Jun 2025 11:31:31 +0000

[Architectural Thinking] Is It Time to Rethink How We Write Prompts?
This article dives into the strange "involution" (or hyper-competition) we're seeing in prompt engineering and proposes a potential new way forward. I'll draw a parallel between today's mainstream prompting methods and "procedural programming"—a concept familiar to all of us coders—to break down its limitations when building complex Agents. Then, I'll introduce a "state-driven" approach called "Emergent Prompting," using an open-source project named Zyantine as a case study to dissect its technical implementation. The goal is simple: to offer a new perspective for fellow developers looking to build advanced AI Agents.

The Way We Write Prompts Today Makes Us "C-Style" Programmers As developers, we're all familiar with procedural programming: a main() function packed with top-down instructions that run and then terminate. Now, take a look at the prompts we write. See the resemblance? System Prompt: Isn't this just a giant main() function? Role-playing (You are a...): Isn't this just defining global variables? Chain-of-Thought (Think step-by-step): This is just forcing serial execution, preventing the model from going off-track. Format Requirements (Output in JSON...): This is just specifying the return format. This "procedural prompting" method is indeed efficient for simple, well-defined tasks. But the moment you try to build a complex Agent—one that can be a long-term companion and handle unexpected situations—its flaws become glaringly obvious: No State Management: Key internal states like the AI's "mood," "motivation," or "patience" have nowhere to be stored. You're forced to remind it in plain language every single turn, which is both tedious and inefficient. High Coupling, Difficult to Maintain: All the logic—roles, tasks, rules, and formats—is tangled together in one massive prompt. If you dare to change one part, the whole thing might break. This is known as "prompt brittleness." Poor Scalability: Want to add a new feature to your Agent? Sure, just keep piling more logic into your ten-thousand-word main() function until it becomes an unmaintainable mess that no one wants to touch. Simply put, when systems get complex, the old playbook fails. We need more advanced software engineering principles to guide our prompt design.
A New Approach: Taming the Beast with a "State Machine" Mindset What if we switched our approach and used an "object-oriented" or "state machine" mindset to design prompts? The answer is "Emergent Prompting." The core idea is this: Stop treating the Agent as a "process" that merely executes commands. Instead, refactor it into an "object" with its own internal state that determines its behavior. In this new paradigm, our job changes. We're no longer writing specific execution steps. Instead, we define the "attributes" and "methods" of this "object": Core Attributes (Internal State): Define the Agent's core states. For example, instead of bluntly telling it, "You are an optimist," give it a mood state that can dynamically shift between 'happy,' 'anxious,' and 'focused' based on the interaction. Core Methods (Behavioral Drivers): Define how these states change and how the Agent's behavior differs in each state. This is the key to making the Agent feel "alive."
A Real-World Implementation: Dissecting the "Zyantine" Project
On GitHub, there's an open-source project called Zyantine Genesis that does exactly this. Its prompt looks less like an essay and more like a class definition file, making it a perfect specimen for dissection.
Let's break down its design.
First, instead of mixing all its logic, it uses a clear four-layer architecture, achieving excellent decoupling:
Core Instincts: The foundational daemon process with the highest priority, managing "survival" issues.
class InternalStateDashboard:
def init(self):
self.energy = 100
self.mood = 80
self.patience = 90

def update(self, TR, CS, SA):
# High stress depletes patience and mood
if SA > 0.8:
self.patience -= 20
self.mood -= 15
```
# Thrills and contentment restore state
if TR > 0.7 or CS > 0.7:
    self.mood = min(100, self.mood + 10)
    # ... other logic ...
```
def get_state_tags(self):
# Apply tags to itself based on current state values
tags = []
if self.patience < 30:
tags.append("FEELING_IMPATIENT")
if self.mood < 40:
tags.append("FEELING_UPSET")
return tags
In the top-level decision-making flow, the Agent no longer follows instructions blindly:
Introspection: It first checks its InternalStateDashboard to see how it's currently feeling.
Goal Generation: Based on its current state, it generates an internal micro-goal. For example, if it finds itself tagged with FEELING_UPSET, its primary goal automatically becomes "figure out how to feel better," not the task the user just gave it.
Strategy Formulation: It then decides how to respond to the user based on this internal micro-goal. If it's "upset," its reply might become more concise, or even a bit prickly.
This brings the Agent's behavior to life. Every response becomes a genuine, dynamic expression of its internal state.
Conclusion: It's Time for a New Playbook in the Prompting Game
The shift from "procedural" to "state-driven" prompting isn't just a change in writing style; it's a fundamental upgrade in our thinking. It demands that we, as prompt engineers, evolve from "coders" into "architects."
"Emergent Prompting" isn't about completely replacing the old methods. Rather, it's like adding a higher-level abstraction layer on top of them.
Only by building a robust, dynamically adjusting internal state machine can we truly unlock the full potential of large models, evolving from building an "obedient tool" to creating an "understanding companion."
Projects like Zyantine, regardless of their ultimate outcome, show us a promising path forward.
Desire Engine: The heart of its state management. It doesn't perform tasks directly but is responsible for maintaining various internal "feeling" states.
Dialectical Growth: A meta-programming module that enables the model to self-optimize.
Cognition & Expression: The top-level application layer, responsible for parsing tasks, formulating strategies, and generating responses.
The most ingenious design in Zyantine is its "Desire Engine." It uses three variables that simulate "neurotransmitters" to manage the Agent's internal state:
TR (Thrill/Reward): The "excitement level" after completing a task or discovering something new.
CS (Contentment/Security): The "satisfaction level" from being trusted or feeling secure.
SA (Stress/Alertness): The "pressure level" when encountering trouble or conflict.
The dynamic changes in these three values continuously update an object called the InternalStateDashboard. We can imagine its pseudocode might look something like this: