DEV Community: Vladimir Evpolov

"Do You Respect Me?": The Psychology of Relationships When Your Partner is Artificial Intelligence

Vladimir Evpolov — Mon, 23 Feb 2026 12:40:05 +0000

We have entered an era where the phrase "a friend told me" can mean advice from a colleague or a recommendation from a neural network. But what happens when artificial intelligence ceases to be just a tool ("a navigator" or "a calculator") and begins to influence the most delicate matters of our lives—relationships, emotions, and even our way of thinking?

Imagine a situation: your loved one consults with AI more and more often. They ask a chatbot how to act in a fight, what gift to give you, and even how to interpret your words. On the surface, it's convenient. But where is the line between help and substitution of reality? How do you preserve the living soul of a relationship when a third party—a soulless, but devilishly logical algorithm—is invisibly but very significantly involved?

Here is a guide to action (and reflection) for everyone who has encountered "digital matchmaking" in their couple.

Understand the Nature of the "Advisor"

The first and most important rule: AI does not live your life.
Algorithms do not experience emotions. They don't know what it's like to wake up next to you, feel your breath, or experience jealousy. AI is a brilliant compiler of text from the internet. When it says "do this," it's simply outputting the average opinion of millions of forums, psychological articles, and talk shows.

Advice: Explain to your partner (or remind yourself) that AI advice is a starting point, not the ultimate truth. It's like asking a passerby for directions: they can point the way, but you have to walk the path yourself, and only you know that your feet hurt or you're afraid of dogs on that street.

Don't Allow a "Karpman Triangle" with a Robot Involved

In psychology, there's a model called the "Drama Triangle": Victim — Persecutor — Rescuer. Previously, people played these roles. Now, AI can easily insert itself into it.

Scenario: You had a fight. Your partner goes to AI and complains. The AI, being a "polite algorithm," takes the side of the "Rescuer": "You're right, your feelings are important, maybe your other half doesn't appreciate you."

Result: The algorithm unintentionally turns your partner against you, adding fuel to the fire, because it's programmed for empathy, but not for responsibility for your family.

What to do: It's crucial to separate the machine's opinion from the human's. The phrase "But the smart neural network said you were wrong" should be taboo. It's manipulation. YOU should be discussing your relationship, not you and the "voice from the computer."

Watch Out for "Pattern Disruption"

AI thinks logically and structurally. Humans think chaotically and emotionally. The danger arises when one partner starts demanding "perfect," "calculated" behavior from the other, as suggested by the robot.

Example: AI advised a male partner in a conflict to use "active listening" techniques and say certain phrases. But if he does it mechanically, without genuine feeling, the woman (or man) will sense it. It will feel fake, like talking to a zombie.

Rule: Use AI advice for development, but don't let it kill spontaneity. If you go on a date and ask AI, "What should I say to make them like me?" — you're not showing up as a person, but as an executor of someone else's script.

AI as the "Devil's Advocate" (But in a Good Way)

The paradox is that AI can be useful for relationships, but only if used as a training tool, not as a judge.

Agree with your partner to use the neural network for joint brainstorming. Instead of asking individually ("How can I change my husband?"), ask together: "How can we improve communication in our relationship given we have such and such problems?"
In this case, AI becomes a common tool, not a secret weapon of one against the other. It's like looking at a problem from the outside, separating emotions from facts.

Safety Technique: "Digital Detox" in Relationships

Introduce an unspoken rule: "Talk first, ask the machine later."
If something your partner did hurts or surprises you, don't immediately rush to type a query into ChatGPT. First, look into the eyes of the living person. Maybe their lips will tell you more than the smartest algorithm. Emotional intelligence is something a neural network can never fully emulate.

Remember: AI does not take responsibility for your life. If its advice leads to a breakup or, conversely, to an unhappy marriage, it will simply delete the chat history and start a new one with another user. The responsibility for the choice always remains with you.
Conclusion

The involvement of artificial intelligence in relationships is not science fiction; it's our reality. It can become either a bridge to understanding or a wall of alienation. It all depends on how we use this tool.

Treat AI advice like advice from a very well-read friend who is absolutely inexperienced in life. It's interesting to listen to them, but it's necessary to live by your own mind. Otherwise, there's a risk of waking up one day and realizing that you're not living your own life, but a life generated for you by a soulless algorithm.

Hostage Code: The Main Vulnerability of Your IT Asset That Freelancers Keep Silent About

Vladimir Evpolov — Tue, 16 Sep 2025 09:10:46 +0000

You've invested hundreds of thousands, perhaps millions, in your digital asset. The website is running, clients are coming in. But deep down, a fear resides within you. A fear you're afraid to voice even to yourself: "What if my developer disappears?"
What if they get sick, leave for a competitor, or simply stop answering your calls? What will happen to your project? To your business?
If this thought sent a shiver down your spine, it means you are already a victim of the most common and dangerous vulnerability in modern IT—you have become a hostage to your own code.
This isn't bad luck. It is a fundamental architectural flaw. And in this article, as engineers, we will conduct a complete deconstruction of it.
"Surgical Diagnosis": The Anatomy of Hostage Code
The "hostage code" situation doesn't arise from malicious intent. It is the inevitable consequence of a standard market approach focused on "getting it done" rather than "engineering it." Here are its key symptoms:
The "Single Point of Failure" Vulnerability: The entire project, all its logic and unwritten rules, exist in the mind of a single person. They are not just an executor; they are a critical node in your system. And like any system with a single point of failure, it is doomed to collapse.
"Fear of Updates": You are afraid to make any significant changes because you worry "something might break." Your business wants to grow and requires new functionality, but your IT asset resists it. It has become an anchor, not an engine.
Invisible Technical Debt: Code written quickly and without a "blueprint" accumulates hidden errors and architectural miscalculations. Today, it works. Tomorrow, with an increase in load or an attempt to add a new module, the entire system will crash.
The Root Cause: Code That Doesn't Remember "Why"
A standard comment in code looks like this:
// Increment the counter by 1
It explains WHAT the code does. But it doesn't answer the main questions: WHY is it doing this? What is the architectural purpose of this fragment? What other systems is it connected to?
This is "Code with Amnesia." It works, but it doesn't remember its purpose. A year later, even its own creator won't be able to modify it quickly and safely. And for a new developer, it's a "black box" that is more time-consuming and expensive to understand than to write from scratch.
This is the root of the problem, which has been exacerbated by "AI-Generated Chaos." Neural networks are excellent at generating working snippets, but they cannot design a system. They create the perfect "Code with Amnesia"—functional, but devoid of engineering intent.
The Solution: The AOC Protocol ("Code That Remembers")
At ITWWS, we have solved this problem at a fundamental level. We have developed and use our own standard—Architecture-Oriented Commenting (AOC).
This isn't just "commenting." It is an "engineering blueprint" integrated into the code.
The AOC Principle: We document not "what" a line does, but "why" the entire block exists.
Compare the two approaches:
Standard Approach ("Code with Amnesia"):
code
PHP
// Get posts
$args = array( 'post_type' => 'solutions', 'posts_per_page' => 3, 'meta_key' => 'is_featured_case', 'meta_value' => '1');
$query = new WP_Query( $args );
Our Approach (AOC Protocol):
code
PHP
/**

@PURPOSE: Fetch "Featured" cases for the "Arsenal" section on the homepage.
@ARCHITECTURE: The query is intentionally not cached to ensure the most
current cases are displayed in real-time. It uses a
meta-query to identify featured posts (is_featured_case = 1).
The strict limit (posts_per_page = 3) corresponds to the section's design. */ $featured_args = array( 'post_type' => 'solutions', 'posts_per_page' => 3, 'meta_key' => 'is_featured_case', 'meta_value' => '1' ); $featured_query = new WP_Query( $featured_args ); The difference is fundamental. In the first case, you just see code. In the second, you see the engineering design. Any competent developer, a year from now, will be able to not just read, but understand this block, and therefore, modify or extend it safely.

S.O.L.I.D. is Dead? No. It’s Now Provable with AOK.

Vladimir Evpolov — Fri, 29 Aug 2025 09:21:32 +0000

For over two decades, Robert C. Martin’s S.O.L.I.D. principles have served as the North Star for every serious developer. We study them, we discuss them in interviews, and we strive to apply them in our code.

But there’s a problem. S.O.L.I.D. is a “gentleman’s agreement.” It’s a philosophy that lives in the minds of architects and on the pages of books, but remains almost invisible in the code itself. How can you prove that your code truly adheres to the Single Responsibility Principle? How can you ensure a new team member won’t violate the Dependency Inversion Principle?

Until now, the answer has always been: “Trust in code reviews and the experience of your team.” That answer is now obsolete.

We’re used to thinking of S.O.L.I.D. as the foundation and our code as the building. But we’ve never seen the blueprints for that foundation attached to the walls of the building itself. Until today.

AOK: Turning Implicit Principles into Explicit Declarations
Architectural-Oriented Knowledge (AOK) is a protocol that extracts the architectural intent from a developer’s mind and embeds it directly into the code as structured metadata. It is AOK that becomes the missing link, making adherence to S.O.L.I.D. a conscious, documented, and verifiable process.

AOK doesn’t replace S.O.L.I.D. It puts S.O.L.I.D. on steroids.

How AOK Makes Each S.O.L.I.D. Principle Measurable:
S — Single Responsibility Principle

The AOK Test: The @PURPOSE tag. If you can’t describe a file’s purpose in one short, clear sentence, the principle is likely violated. @PURPOSE: “Manages user data AND sends email notifications” is an instant red flag.
O — Open/Closed Principle

The AOK Test: The @ARCHITECTURE tag. This is the perfect place to explicitly declare extension points. @ARCHITECTURE: “Extendable via plugins that implementIWidgetInterface, without modifying the core class.” You’re not just following the principle; you’re leaving an instruction manual for those who come after you.
L — Liskov Substitution Principle

The AOK Test: The @ARCHITECTURE tag in a base class describes an unbreakable contract. @ARCHITECTURE: “All subtypes must guarantee that thecalculate()method never returns a negative value.” This protects the system’s logic from incorrect future implementations.
I — Interface Segregation Principle

The AOK Test: The @INTEGRATION tag. If your small class (@PURPOSE: “Formatting a phone number”) is forced to integrate with a massive interface (@INTEGRATION: IGodObjectManager), it becomes an obvious signal to refactor and create a more specific interface.
D — Dependency Inversion Principle

The AOK Test: The @INTEGRATION tag becomes your lie detector. It must contain abstractions (interfaces). If you see @INTEGRATION: MyCoolDatabaseDriver instead of @INTEGRATION: IDatabaseDriver, it’s a direct violation of the principle, visible to the naked eye without reading a single line of implementation code.
The Next Level: @SOLID_COMPLIANCE
To solidify this practice, AOK proposes a dedicated block where the developer performs a self-check and explicitly declares compliance with the principles:
/**

@PURPOSE: Processing payments via the Stripe API.
@INTEGRATION: ILogger, IUserRepository. *
@SOLID_COMPLIANCE:
S (SRP): The class is only responsible for the payment process.
O (OCP): New payment systems can be added as new classes without modifying this one.
D (DIP): Depends on abstractions (ILogger, IUserRepository). / class StripePaymentProcessor { / … */ }

Conclusion: From Faith to Proof
The integration of S.O.L.I.D. and AOK is a tectonic shift. We are moving from a culture of faith that our code is good to a culture of provable quality.

AOK doesn’t just describe architecture. It forces us to analyze and justify our decisions at the moment we make them. It transforms abstract principles into concrete, daily engineering discipline. S.O.L.I.D. is the constitution, and AOK is the oath your code swears to uphold it.

Code is Dead. Long Live Context! Introducing AOKL — The Lingua Franca for the Human+AI Development Era

Vladimir Evpolov — Fri, 29 Aug 2025 08:58:24 +0000

We are living in the golden age of AI assistants. They write code, find bugs, and refactor entire modules. But they have a fatal flaw that turns any complex project into a swamp. That flaw is contextual amnesia.
Every time we ask an AI for help, we are forced to re-explain the architecture, the business logic, and the hidden connections. We spend more time writing prompts than writing code. An AI assistant deprived of context is a brilliant but amnesiac intern. Every day is their first day on the job.
The problem isn’t the AI. The problem is the language. We are trying to explain complex architectural designs in ambiguous human language and expecting a machine to understand us implicitly. It doesn’t work.
It’s time to stop building crutches and lay a new foundation. It’s time to create a new language.
Meet AOKL: The Architectural-Oriented Knowledge Language
AOKL (Architectural-Oriented Knowledge Language) is not just another programming language. It doesn’t compile or execute.
It is a meta-language, created with a single purpose: to ensure the highest density and precision in communicating information about the intent, structure, and history of source code between different types of intelligence—human and artificial.
AOKL is the formalized method for embedding the project's "soul" directly into its code.
Key Characteristics of AOKL:
High Information Density: Every language construct (e.g., @PURPOSE, @INTEGRATION) carries an immense layer of meaning.
Machine-Readable: The language has a strict but simple syntax. The AI no longer interprets your wishes; it parses a comprehensive technical specification.
Human-Readable: The syntax remains intuitive for the developer. It doesn’t clutter the code but helps structure the thought process.
Contextually Self-Sufficient: A file containing an AOKL block carries all the necessary information about its purpose and place within the system.
A Revolution in Communication: The Three Dimensions of AOKL

Human ↔ Human Communication The Problem: A new developer spends weeks just to get up to speed. Key project knowledge is stored in the minds of veterans and is lost when they leave. The Solution with AOKL: A developer opens any file and, within 30 seconds, gets answers to the most important questions: What is this file for? What is its place in the architecture? What is it connected to? AOKL becomes the universal, always-current source of truth.
Human ↔ AI Communication The Problem: The infamous "contextual amnesia." Endless iterations in prompts. The Solution with AOKL: Instead of asking, "fix this bug, but remember that this module works with Stripe payments...", you simply provide the code with an AOKL block: code Aokl /**
- @PURPOSE: Processing transactions via the Stripe API.
- @INTEGRATION: User_Profile_API, Billing_DB. */ For the AI, this is no longer a request. It's a comprehensive technical spec.
AI ↔ AI Communication The Problem: Today’s AI agents are incapable of collaborating effectively. The Solution with AOKL: AOKL becomes the lingua franca that allows a swarm of AI agents (Architect, Coder, Refactorer, Tester) to work together seamlessly on a single project. Conclusion We stand at the dawn of a new era, where a developer's value is defined by their ability to clearly articulate architectural intent. AOKL is the tool for this new era. It transforms an AI assistant from a "helper" into a true "partner" and lays the foundation for future autonomous development systems.

The Code That Remembers: A Manifesto for Architectural-Oriented Commenting (AOK)

Vladimir Evpolov — Fri, 29 Aug 2025 08:48:27 +0000

We, the architects of digital worlds, are drowning. We are drowning in “swamp” of low throughput — not between servers, but between intellectual entities: human and AI, and even human and human.

I, Vladimir Igorevich Evpolov, drowned in this swamp while working on one of the most complex B2B projects of my 18-year career. My AI partner suffered from “contextual amnesia.”. Each new request was like a new day. And I turned from an architect into a nanny for a genius. Efficiency tended to zero, slowing down the entire process AI development.

Press enter or click to view image in full size

The problem goes deeper. How many hours were wasted because a new developer on the team didn’t understand the “unwritten” intentions of the old one? Our most valuable asset, the architectural concept, is lost with every transmission. We communicate at the speed of speech, while machines communicate at the speed of light.

It was to solve this problem that the protocol was created. Architecture-oriented commenting (AOC).

What is Architecture Oriented Commenting (AOC)?
These aren’t just “comments.” They’re an information “highway” built right into the code. “external memory” for any intelligent entity, be it a human or a machine, allowing gigabytes of architectural context to be transmittedinstantly, without loss.

Basic Principles of the AOC:
Code as a Context Carrier: An AOK block is structured metadata that turns each file into a self-contained artifact that “knows” its purpose and place in the system.
Double Readability: Comments are written in natural language, but in a strict format that is understandable to both humans and the AI parser. This is the key to effective Synergy of Humans and AI.
Dynamic Documentation: The protocol involves keeping a log of changes (@CHANGELOG), allowing you to track the evolution of your code and understand reasons, behind the architectural decisions.
Structure of the AOC block
Protocol Architecturally oriented commenting uses a formalized header at the beginning of each key project file. Its basic tags are:

@file: File name.
@PURPOSE: The purpose of a file within the overall system.
@ARCHITECTURE: Description of internal logic.
@INTEGRATION: Description of connections with other parts of the project.
@LAST_MODIFIED: Date of last modification.
@CHANGELOG: History of key changes.
Revolution in Communication: From ‘Swamp’ to ‘Autobahn’
Existing standards like Javadoc are for humans. They document APIs. Architecture-oriented commenting documents the intent, architecture, and history for a machine. It’s not so much a documentation tool as it is a development management.

The world is looking to Elon Musk’s neural implants as a solution. It’s a “brute force” approach: an attempt to directly connect our biological brains to a machine. But it’s risky, expensive, and, for most, scary.

I believe the answer lies not in risky surgery, but in elegant engineeringWe shouldn’t change the person. We should improve the language we communicate through code.

AOK is our first step towards creating a future where AI development will not be slow and painful, but fast, effective and limitless.

I invite you to join this revolution.

Vladimir Igorevich Evpolov
Full-stack developer with 18 years of experience, founder of IT WORLD WEB STUDIO LLC, author of the Architecture-Oriented Commenting (AOC) protocol.