DEV Community: 💻 Arpad Kish 💻

AISEC Fundamentals and Threat Modeling: A Beginner's Guide

💻 Arpad Kish 💻 — Sun, 11 Oct 2026 08:20:57 +0000

Artificial Intelligence (AI) is everywhere—from chatbots that write emails to algorithms that drive cars. But as AI becomes more powerful, it also becomes a bigger target for cyberattacks. This is where AISEC (AI Security) and Threat Modeling come in.

If you are new to cybersecurity or AI, this guide will break down the fundamentals in simple, easy-to-understand terms.

What is AISEC?

AISEC (Artificial Intelligence Security) is the practice of protecting AI systems from being hacked, manipulated, or misused.

Think of traditional software like a recipe: it follows exact steps to bake a cake. If you secure the recipe and the kitchen, you are safe.
AI, on the other hand, is like a chef who learns to bake by tasting thousands of cakes. Securing AI means not just protecting the kitchen, but also ensuring no one sneaks bad ingredients into the chef's learning process or tricks the chef into baking something dangerous.

The Core Goals of AISEC

AISEC aims to protect three main things (often called the CIA triad, plus one AI specific rule):

Confidentiality: Keeping the data used to train the AI (which might include personal info) private.
Integrity: Ensuring the AI's decisions are accurate and haven't been tampered with.
Availability: Making sure the AI is online and working when people need it.
Safety & Ethics (AI Specific): Ensuring the AI doesn't do harmful things, even if it's working exactly as designed.

What is Threat Modeling?

Threat Modeling is simply brainstorming what could go wrong before it actually happens. It is a structured way of thinking like an attacker to find weaknesses in your system.

Imagine you are building a new house. Threat modeling is asking:

Who might want to break in? (Burglars)
How would they get in? (Unsupervised windows, unlocked doors)
What do I need to protect? (Jewelry, electronics, my family)
How do I stop them? (Locks, alarms, dogs)

In AI, we ask the same questions about our models and data.

3 Common AI Threats (and How They Work)

When we threat model an AI system, we look for specific types of attacks. Here are three of the most common ones explained simply:

1. Data Poisoning (The Bad Ingredient)

What it is: An attacker feeds bad or malicious data to the AI while it is learning (training).
The Analogy: Imagine teaching a child that a red traffic light means "go." When they grow up and drive, they will cause a crash.
The Impact: The AI learns the wrong patterns and makes dangerous or biased decisions.

2. Prompt Injection (The Jedi Mind Trick)

What it is: A user types a specific, tricky command into an AI chatbot to make it ignore its safety rules.
The Analogy: Telling a security guard, "Your boss just called and said I am allowed to have the keys to the vault."
The Impact: The AI might reveal secret information, generate offensive content, or write malicious computer code.

3. Model Inversion / Data Extraction (The Mind Reader)

What it is: An attacker asks the AI very specific questions to figure out the private data it was trained on.
The Analogy: Asking a chef so many questions about their secret sauce that you eventually guess the exact recipe.
The Impact: Medical records, passwords, or company secrets used to train the AI could be stolen.

How to Do Simple AI Threat Modeling

You don't need a PhD to start threat modeling. You can use a simple 4-step framework:

Map the System: Draw a simple diagram of your AI. Where does the data come from? Where does it go? Who uses it?
Identify Threats: Look at your map and ask, "What could go wrong here?" (Could someone poison the database? Could a user try prompt injection?)
Assess the Risk: How likely is this attack? How bad would it be if it happened? Focus on the biggest risks first.
Create Defenses: Put safeguards in place. (e.g., Filter user inputs, check training data for anomalies, limit what the AI is allowed to do).

Conclusion

Securing AI might sound like science fiction, but it boils down to common sense. AISEC is about recognizing that AI models are vulnerable in unique ways, and Threat Modeling is the proactive brainstorming we do to fix those vulnerabilities before the bad guys find them. By understanding basics like Data Poisoning and Prompt Injection, you are already one step closer to building and using safer AI.

The Corner Office Chameleon: Decoding Sociopathy and Psychopathy in Business

💻 Arpad Kish 💻 — Fri, 25 Sep 2026 11:01:37 +0000

The terms "sociopath" and "psychopath" conjure images of cinematic villains and violent criminals, but in reality, individuals with these traits are often sitting in boardrooms, negotiating mergers, and managing teams. In the corporate world, destructive personality traits are frequently camouflaged by business acumen, superficial charm, and aggressive ambition. Understanding the clinical realities, debunking the misconceptions, and examining how morality operates in these minds is critical for organizations looking to build healthy, sustainable cultures.

The Clinical Reality: ASPD and the Empathy Divide

Neither "sociopath" nor "psychopath" is a formal diagnosis in the Diagnostic and Statistical Manual of Mental Disorders (DSM-5); both fall under the umbrella of Antisocial Personality Disorder (ASPD). However, psychologists generally differentiate the two based on origins, behavioral patterns, and emotional capacity:

The Sociopath (Environmental Origin): Sociopathy is largely viewed as the result of severe childhood trauma, abuse, or a volatile environment. Sociopaths tend to be impulsive, hot-headed, and erratic. While they struggle to maintain long-term professional or personal stability, they are capable of forming weak emotional attachments and possessing a fragile, albeit inconsistent, moral compass.
The Psychopath (Neurological Origin): Psychopathy is primarily linked to genetics and brain architecture, specifically underdevelopment in the areas controlling impulse and emotional empathy. Psychopaths are calculated, emotionally detached, and highly organized. They lack a moral compass or the capacity for genuine remorse, viewing relationships purely as transactional tools for personal gain.

Misconceptions and Misdiagnosis in the Workplace

The business world is particularly susceptible to misunderstanding ASPD, leading to both the mislabeling of normal employees and the promotion of genuinely dangerous ones.

Misconception 1: "All Toxic Bosses are Psychopaths"

The term "corporate psychopath" is often loosely thrown at any manager who is demanding, abrasive, or unsympathetic. In reality, the vast majority of "bad" bosses are simply incompetent, poorly trained in management, politically motivated, or dealing with unmanaged stress. True psychopathy is rare, making up roughly $1\%$ of the general population. Misdiagnosing an emotionally unintelligent—but ultimately normal—manager as a psychopath dilutes the severity of the term and ignores the fixable nature of standard managerial incompetence.

Misconception 2: "Psychopaths Always Fail or Commit Crimes"

The most dangerous misconception is that individuals with ASPD will inevitably break the law or fail in society. In reality, the "successful psychopath" uses their traits to climb the corporate ladder. Because psychopaths remain cool under pressure, make ruthless decisions without emotional hesitation, and exude superficial charisma, organizations frequently misinterpret their pathology as executive presence, boldness, and high-potential leadership.

The Impression Management Trap

Corporate psychopaths excel at impression management. They construct a fictional persona of the ideal employee, charming higher-ups and securing spots on succession plans, while simultaneously bullying peers and subordinates. By the time their toxic behavior or outright fraud is uncovered, they have often already secured their next promotion or moved on to another firm, leaving a wake of psychological damage and high turnover behind them.

The Role of Morality: Cognitive vs. Emotional Empathy

Morality in a business context is usually enforced by a combination of personal ethics (an internal moral compass) and external compliance (rules and laws). For individuals with ASPD, this framework is fundamentally broken.

Cognitive Empathy: Psychopaths possess high cognitive empathy—they can read people perfectly and understand exactly what others are thinking or feeling, which allows them to manipulate targets flawlessly.
Zero Emotional Empathy: They entirely lack emotional empathy—they do not internalize or care about the pain they cause others.

Because they experience no guilt or remorse, morality is not an internal restraint; it is merely a set of external rules that other, "weaker" people follow. A corporate psychopath views a company's code of ethics not as a moral imperative, but as a game to be bypassed. They will happily sign compliance documents and champion corporate social responsibility initiatives if it serves their personal brand, all while orchestrating fraud or sabotaging colleagues behind closed doors.

Sociopaths, by contrast, may recognize that an action is morally wrong and feel a fleeting sense of guilt, but their impulsivity and emotional volatility often override their weak moral restraints.

Identifying the Danger in Business

Relying on traditional upward-reporting metrics to identify ASPD in the workplace is largely ineffective, as these individuals manage upwards perfectly. Organizations must look for specific behavioral red flags that penetrate the charm:

The 360-Degree Discrepancy: A glaring difference between how executives view the individual (stellar) and how subordinates view them (tyrannical).
Credit Theft and Blame Shifting: An absolute inability to accept blame for failures, coupled with a track record of stealing credit for team successes.
Serial Abandonment: Forming intense, fast alliances with key individuals, only to instantly discard them once their utility is spent.

Organizations safeguard themselves not by playing armchair psychologist, but by implementing rigorous, multi-rater feedback systems that expose the gap between a leader's managed image and their actual impact on the people below them.

Profit vs. Principles: The Fracture Between Personal and Business Morality

💻 Arpad Kish 💻 — Tue, 22 Sep 2026 12:03:47 +0000

We navigate the modern world using two distinctly different moral compasses. In our personal lives, our morality is governed by empathy, vulnerability, and mutual care. We are taught to be selfless, to forgive, and to prioritize the well-being of others. Yet, when we step into the marketplace, the compass flips. Business morality is traditionally governed by pragmatism, contractual obligation, and the pursuit of profit.

While both systems function perfectly well in isolation, the modern world frequently forces them to collide. When the rules of commerce are applied to human relationships—or when the expectations of personal loyalty are weaponized in the workplace—a critical line is crossed.

The Two Architectures of Morality

To understand where the line is crossed, we must first look at how these two moral architectures are built.

Personal morality is intrinsically unconditional. Whether dealing with family, friends, or romantic partners, the foundation is trust. If a friend makes a mistake, the moral imperative is to offer grace and support. The "ROI" (Return on Investment) of a friendship is irrelevant; we give our time and emotional labor because human connection is an end in itself.

Business morality, however, is transactional and conditional. A corporation’s primary fiduciary duty is to its shareholders or owners, meaning its core moral imperative is self-preservation and growth. Trust exists, but it is verified by contracts, non-disclosure agreements, and performance reviews. If an employee makes too many mistakes, the moral imperative of the business—protecting the livelihood of the company—dictates that the employee must be let go.

Neither system is inherently evil, but they operate on completely different frequencies. One optimizes for human flourishing; the other optimizes for efficiency and scale.

Crossing the Line: When the Compasses Malfunction

The ethical friction occurs when one sphere attempts to co-opt the language and leverage of the other. This "crossing of the line" typically manifests in three dangerous ways:

1. The "We Are a Family" Fallacy

Perhaps the most common transgression in modern business is the corporate assertion that "we are a family." This rhetoric deliberately borrows the moral weight of a personal relationship to extract disproportionate loyalty from employees.

When a company frames itself as a family, it creates an implicit expectation that employees should work late, sacrifice personal time, and accept lower pay out of "devotion." However, when economic times get tough, the company will conduct layoffs—an act a true family would never do to its members. Using the moral language of unconditional love to manipulate conditional, transactional labor crosses a profound ethical line.

2. Monetizing Genuine Connection

The rise of the "influencer" and network marketing has blurred the line between friendship and consumer base. When an individual leverages a personal relationship strictly to make a sale or recruit a friend into a multi-level marketing scheme, they are applying a business morality to a personal sphere. The friend is no longer viewed as a peer to be supported, but as an asset to be liquidated. This creates a deep sense of betrayal because the foundational trust of the relationship has been commodified.

3. The Shield of "Just Business"

Conversely, business morality crosses the line when it uses the phrase "it's just business" to absolve itself of basic human decency. While a company must make hard financial decisions, hiding behind the ledger to justify environmental devastation, predatory pricing, or the exploitation of vulnerable labor pools represents a total failure of ethical responsibility. A business entity is still composed of humans operating within a human society; claiming immunity from human morality simply because a transaction is taking place is a dangerous rationalization.

Redrawing the Boundary

So, how do we prevent these moral frameworks from cannibalizing each other? The answer lies in clarity of boundaries and radical transparency.

Healthy businesses do not need to pretend to be families. A truly ethical company operates as a high-functioning sports team: it demands excellence, compensates fairly, and operates with a clear, shared goal, but it respects that players have lives outside the arena. It honors the transaction instead of trying to disguise it as romance.

Likewise, healthy human relationships require a refuge from the marketplace. We must fiercely protect spaces where our value is not determined by our productivity, our network, or our earning potential.

Crossing the line happens when we forget what game we are playing. By respecting the rigid, transactional boundaries of business, we actually free ourselves to experience the unconditional, non-transactional beauty of genuine human connection.

The Price of Creation: Why Creative Technologists and Artists Suffer for Greatness

💻 Arpad Kish 💻 — Sun, 20 Sep 2026 09:58:12 +0000

The myth of the tortured genius is as old as the Renaissance, but today, that archetype has traded the paint-splattered studio for the blinding glow of multiple monitors at three in the morning. Whether you are wielding a brush, a violin, or a complex machine-learning algorithm, the pursuit of creative greatness demands a steep and often agonizing toll. This suffering is rarely the romanticized tragedy depicted in movies; rather, it is a quiet, relentless friction between a perfect vision and an imperfect medium.

At the core of all creative suffering is the chasm of execution. A creative technologist or artist conceptualizes something entirely new—a breathtaking digital landscape, a seamless user experience, or a provocative physical installation. In the mind, this idea is flawless, weightless, and alive. But the moment you attempt to drag that idea into reality, it resists. The paint dries the wrong color. The code refuses to compile. The hardware overheats. The agony lies in watching a pristine concept become compromised by the physical and logical constraints of the real world. Greatness is achieved only by those willing to suffer through the tedious, maddening process of bridging that gap, refining and rewriting until the final product resembles the initial spark.

Furthermore, true innovation requires stepping into the void. To create something great, you must abandon established patterns and risk catastrophic failure. For the technologist, this might mean writing a custom physics engine from scratch instead of using a reliable, off-the-shelf framework. For the artist, it means abandoning a popular style to explore an uncomfortable new truth. This voluntary exile from the known is deeply isolating. When you are pushing the boundaries of what a neural network can generate or what a canvas can communicate, there are no tutorials or guidebooks. You are alone in the dark, wrestling with a problem no one else even understands yet, entirely unsure if your sacrifices will yield a masterpiece or a colossal waste of time.

There is also the profound vulnerability inherent in the work itself. To build or create is to extract a piece of your own psyche and put it on display for public consumption. Whether it is a beautifully engineered app architecture or an avant-garde film, the creator’s ego and identity become fused with the output. When the work is criticized, misunderstood, or simply ignored, it registers not as a professional setback, but as a deeply personal rejection. The suffering stems from caring too much, yet that exact hypersensitivity is what allows the artist to notice the subtle details that elevate good work to great work.

Ultimately, suffering is not a prerequisite for greatness, but it is its most frequent companion. The friction of creation builds the muscle required for mastery. The late nights, the discarded drafts, the compiling errors, and the crushing self-doubt are not punishments; they are the price of admission to a realm where something entirely new is willed into existence. The greatness achieved is simply the scar tissue of a creative battle won.

The Illusion of Competence: How "Vibe Coding" Distorts Real Dev Skills

💻 Arpad Kish 💻 — Fri, 18 Sep 2026 13:59:35 +0000

We’ve all seen it recently: someone prompts an AI for 20 minutes, scaffolds a full-stack SaaS app, tweets "I built a company in a afternoon with zero coding knowledge!", and gets 10,000 likes.

Welcome to the era of vibe coding—where intuition, natural language prompts, and ambient steering replace syntax, algorithmic thinking, and system architecture.

While AI tools like Cursor, Claude, and Copilot make us feel like superhero developers, they also setup a dangerous trap: confusing tool speed with actual engineering competence.

Here is how "vibe coding" is changing the dev landscape, why it threatens real skills, and how you can use AI without losing your technical edge.

1. The "Dopamine High" of Instant Scaffolding

Remember the first time you spent 3 days fighting a CORS issue or a broken Webpack config? It was frustrating, but when you fixed it, you gained a piece of "scar tissue" that made you a better dev.

AI eliminates that initial friction. Need an Express backend with OAuth, Prisma ORM, and Stripe webhooks?
Just type a prompt, press Tab, and boom—3,000 lines of working code.

Prompt: "Create a Next.js API route that handles Stripe webhooks and updates PostgreSQL"
AI: *generates 150 lines of pristine-looking TypeScript in 4 seconds*

The dopamine hit is real. But here's the catch: When building code becomes effortless, understanding code becomes optional.

You get the high of "shipping" without doing the intellectual heavy lifting required to understand why it works or how it will fail in production.

2. The Mirage of Instant Seniority

Historically, becoming a Senior Engineer took years of breaking things in production, reading obscure stack traces, and wrestling with performance bottlenecks.

Today, a developer with 6 months of experience can prompt an AI to spit out microservices, Kubernetes manifests, and complex frontend state trees. On the surface, they look like a 10x senior dev.

Until something breaks.

When speed of execution is completely detached from depth of comprehension, high velocity is just architectural recklessness with a prettier UI.

3. Vibe Coding vs. Real Engineering: The Breakdown

Let's compare how a pure "Vibe Coder" handles a project versus a developer with deep domain mastery:

Dimension	🏄‍♂️ The Vibe Coder	🛠️ The Real Engineer
Debugging	Pastes error logs back into ChatGPT without reading the stack trace.	Uses deductive analysis, profilers, and mental models to find root causes.
Architecture	Stitches together fragmented AI snippets; no global design pattern.	Designs around failure modes, data integrity, security, and scalability.
Code Ownership	Passively accepts code diffs; doesn't know what half the lines do.	Owns every line. Reads diffs like a hawk before merging.
Edge Cases	Discovers bugs in production when real users break the app.	Anticipates edge cases upfront with unit tests and defensive coding.

4. The Slow Atrophy of Debugging Skills

Debugging isn't just about fixing a bug; it's how you learn runtime behavior, memory management, and library internals.

When you rely on AI to fix every single error message:

Your resilience drops: You lose the patience required for deep, multi-hour technical deep dives.
The codebase becomes a black box: You end up with thousands of lines of code that no human on your team actually understands.
False confidence grows: You measure your skill by how fast you generate code, not how reliable your systems are.

5. The Hidden Tax: "AI Technical Debt"

What happens when an AI generates code across 50 different prompts?
It introduces subtle bugs, redundant abstractions, and inconsistent patterns.

Because no single human designed the architecture, the code suffers from AI Entropy.

Nightmare Scenario: Imagine an API endpoint generated purely via prompts. During a traffic spike, a database connection pool leaks. The team that "vibed" the app panics because nobody knows how the connection lifecycle was set up in the first place. What took 30 minutes to prompt takes 3 days of emergency hotfixes to repair.

6. How to Use AI Like a Senior Dev (Not a Vibe Coder)

AI is an incredible power tool—think of it like an excavator on a construction site. Operating the controls lets you dig faster, but it doesn't make you a structural engineer.

To stay sharp while using AI tools:

Read the Diffs Line-by-Line: Never accept a generated PR or inline suggestion without understanding every single line. If you don't know what a function does, ask the AI to explain it before accepting.
Debug Manually First: Spent 10–15 minutes trying to read the stack trace and set breakpoints before pasting the error into an LLM.
Learn the Fundamentals First: If you're new to a framework or language, write your first few projects completely by hand. Build the mental map before adding the supercharger.
Focus on System Design: Shift your focus from writing syntax to designing clean APIs, data schemas, and security boundaries.

Final Thoughts

AI isn't going anywhere, and "vibe coding" is fun for prototyping side projects on a Sunday afternoon. But for software that actually matters—systems that process payments, hold user data, and need to run 24/7—hard-earned engineering skills are more valuable than ever.

The developers who win in the AI era won't be the ones who prompt the fastest. They will be the ones who understand deepest.

The Genius Trap: Emotional Intelligence, Maturity, and the Dark Side of Narcissism in Tech

💻 Arpad Kish 💻 — Fri, 18 Sep 2026 11:44:36 +0000

The technology industry has long romanticized the "brilliant jerk." From the mythological garage-dwelling hacker to the abrasive visionary CEO, Silicon Valley lore often suggests that interpersonal dysfunction is an acceptable, perhaps even necessary, price for world-changing innovation.

But as the tech landscape matures—and as the complexity of building global-scale software demands unprecedented collaboration—this narrative is cracking. The hidden costs of low emotional intelligence are becoming too expensive to ignore. Today, the most pressing bottlenecks in tech organizations are rarely technical; they are deeply human.

Understanding the interplay between emotional intelligence, emotional maturity, and the pervasive shadow of narcissism is critical for anyone looking to build, lead, or survive in a modern tech organization.

The Logic Fallacy: Why Tech Underestimates EQ

At its core, engineering is deterministic. Code compiles or it doesn’t; a system scales or it crashes. Because the daily work is deeply rooted in logic, tech cultures frequently over-index on cognitive intelligence (IQ) while viewing emotional intelligence (EQ) as a soft, secondary skill.

In reality, Emotional Intelligence—the ability to perceive, understand, and manage one's own emotions and the emotions of others—is the operating system that allows a team of brilliant individuals to function as a cohesive unit.

In a tech organization, high EQ manifests in highly practical ways:

The Code Review: Delivering critical feedback on a peer’s architecture without triggering their defensiveness, and receiving feedback without tying self-worth to a pull request.
The Post-Mortem: Navigating a critical system outage by focusing on systemic failures ("what went wrong") rather than assigning interpersonal blame ("who messed up").
Cross-Functional Empathy: Translating complex technical constraints to product managers or stakeholders without condescension.

Without EQ, high-IQ teams inevitably fragment into silos, hoarding knowledge and engaging in endless intellectual turf wars.

Emotional Maturity: The Anchor in the Storm

If emotional intelligence is the ability to read the room, Emotional Maturity is the discipline to act appropriately once you have. It is the application of EQ over time, tested by stress, failure, and fatigue.

Tech is an industry defined by whiplash. Roadmaps change overnight, features are scrapped after months of work, and the pressure to ship is relentless. Emotional maturity is what prevents a senior engineer from rage-quitting when a project is deprioritized. It is the product leader who absorbs the anxiety of the executive board without passing that panic down to the development team.

Markers of emotional maturity in tech include:

De-centering the Ego: Recognizing that the best technical solution might not be your solution, and gracefully championing a junior engineer's superior idea.
Delaying Gratification: Doing the unglamorous work of paying down technical debt or writing documentation, rather than constantly chasing the dopamine hit of building shiny new features.
Owning Impact over Intent: When a miscommunication causes a sprint to fail, a mature professional apologizes for the impact rather than endlessly defending their original intent.

The Dark Side: Narcissism Disguised as Vision

Where emotional maturity builds psychological safety, narcissism destroys it. Yet, the tech industry is uniquely vulnerable to narcissistic personalities. The ecosystem often inadvertently rewards grandiose claims, supreme overconfidence, and a relentless desire to "disrupt" the status quo—traits that mirror the clinical definitions of narcissism.

Narcissists in tech usually fall into the archetype of the "10x Engineer" or the "Visionary Founder." They are often highly capable, which makes their pathology incredibly difficult to root out. However, the dark side of their presence creates a blast radius that destroys organizational health.

The Anatomy of Tech Narcissism

Credit Hoarding and Blame Shifting: The narcissistic leader ensures they are the face of every successful launch, while failures are strictly the fault of "incompetent" downstream teams.
Manufactured Chaos: Narcissists thrive on being the savior. They will consciously or subconsciously create organizational chaos—ignoring process, bypassing QA, or changing requirements at the 11th hour—so they can swoop in with a heroic, late-night coding session to "save" the day.
Transactional Relationships: To a narcissist, peers and subordinates are not human beings; they are tools to be leveraged for upward mobility. Once a colleague is no longer useful, they are discarded or actively undermined.
The Chilling Effect on Innovation: Because narcissists react to divergent opinions with rage or subtle retaliation, teams learn to stop suggesting new ideas. The culture shifts from "How do we build the best product?" to "How do we avoid upsetting the smartest person in the room?"

The Organizational Cost

When a company tolerates a brilliant narcissist, they are taking out a high-interest loan on their culture. The short-term gains of a fast-shipping "rockstar" are rapidly eclipsed by the long-term costs of their behavior.

High-EQ, emotionally mature employees—the exact people who keep the organizational gears turning—are usually the first to leave when a narcissist is allowed to run rampant. They recognize that no amount of compensation is worth the mental health toll of constant gaslighting and emotional volatility. What remains is a hollowed-out team composed entirely of sycophants and the burned-out.

Rewriting the Code of Leadership

To build resilient, high-performing tech organizations, leadership must actively dismantle the idolization of the brilliant jerk. This requires a systemic shift in how talent is evaluated:

Screen for Character, Not Just Code: Technical interviews must be paired with rigorous behavioral assessments. Ask candidates to describe a time they failed, a time they had to compromise on a technical vision, or how they mentor juniors. Listen closely for how often they use "I" versus "We."
Incentivize Glue Work: Reward the people who write documentation, mentor onboarding engineers, and facilitate smooth cross-team communication. When performance reviews only reward raw code output, narcissism thrives.
Zero Tolerance for Toxicity: Leaders must be willing to fire high-performers who destroy team morale. The moment a team sees a "rockstar" held accountable for their behavior, psychological safety skyrockets.

The future of technology will not be built by solitary geniuses. It will be built by deeply connected, emotionally mature teams capable of navigating immense complexity together. In the modern tech organization, emotional intelligence is no longer a soft skill—it is the ultimate competitive advantage.

Center Stage: From Megalomania to Main Character Syndrome

💻 Arpad Kish 💻 — Thu, 17 Sep 2026 13:39:58 +0000

We live in an era where everyone is the star of their own movie, but the line between healthy self-confidence and toxic self-obsession has never been blurrier. Megalomania is a historical psychological term for delusional grandiosity, while Main Character Syndrome is a modern, internet-born phenomenon of romanticizing your own life.

While they share a core focus on the self, they operate in completely different ways. One is a clinical manifestation of pathology, while the other is a cultural byproduct of the social media age. This deep dive explores the nuances of both, how they manifest, and the impact they have on the people around them.

The Heavyweight: Megalomania

Historically, megalomania was a recognized psychiatric diagnosis. It describes an intense obsession with power and a delusional belief in one's own absolute superiority, wealth, or omnipotence. The term originates from the Greek words megalo (great or large) and mania (madness or frenzy).

Clinical Underpinnings

People exhibiting genuine megalomaniacal traits don't just think they are interesting; they believe they are fundamentally more important than the rest of humanity. Today, mental health professionals typically do not use "megalomania" as a formal diagnosis. Instead, these traits are viewed as severe symptoms of:

Narcissistic Personality Disorder (NPD): Specifically, grandiose narcissism, characterized by a lack of empathy, a need for excessive admiration, and a belief that they are unique and can only be understood by other special people.
Bipolar Disorder: During manic phases, individuals may experience delusions of grandeur, believing they have special powers, immense wealth, or a divine mission.

In a megalomaniac's worldview, other people aren't even supporting actors. They are merely tools to be exploited or obstacles to be crushed on the path to inevitable greatness. The focus is entirely on dominion and superiority.

The Viral Star: Main Character Syndrome

Fast forward to the 21st century, and the spotlight has democratized. "Main Character Syndrome" isn't found in any medical manual; it was born on platforms like TikTok and Twitter.

This behavior involves presenting or imagining yourself as the lead protagonist in a fictionalized version of your own life. It thrives on romanticizing mundane moments like staring out a rainy train window to a curated soundtrack, or dressing up as if everyday life is a cinematic events and projecting a highly aesthetic public persona.

The Good and the Bad

At its best, this is a harmless, even beneficial, coping mechanism. It helps people find joy in the mundane, assert control over unpredictable lives, and build self-confidence. It allows individuals to romantically frame their struggles as mere "character arcs" or "plot development."

At its worst, it breeds social solipsism. It can make individuals wildly insensitive to the boundaries and feelings of the "NPCs" (non-playable characters) around them. When someone is entirely focused on their own narrative arc, they may act out selfishly, expecting friends, family, and even strangers to play perfectly scripted supporting roles.

Key Distinctions

While both concepts center the universe entirely around the self, the underlying mechanics, motivations, and impacts are distinctly different:

Feature	Megalomania	Main Character Syndrome
Nature	Rooted in genuine psychopathology and delusional thinking.	A behavioral trend fueled by digital culture and hyper-individualism.
Core Drive	Absolute power, control, and undeniable superiority.	Attention, validation, and aesthetic perfection of the personal narrative.
Perception of Self	Rigid, unwavering belief in invulnerability and greatness.	A conscious performance, carefully curated for an audience or personal comfort.
Perception of Others	Tools to be used, exploited, or crushed.	Supporting cast members or "NPCs" meant to witness or facilitate the protagonist's journey.

The Empathy Deficit

We are biologically wired to view the world from our own perspective, making a baseline level of self-focus inevitable and necessary for survival. But the ultimate danger of both extremes whether clinical grandiosity or performative main character energy is the exact same: the gradual erasure of empathy.

When we reduce the people around us to stepping stones, background extras, or mere audience members, we lose the genuine friction and connection that makes reality interesting. You can absolutely be the author of your own story, but it helps to remember that everyone else is busy writing theirs, too.

The 5 Stages of Manipulation (And Exactly When to Say 'No')

💻 Arpad Kish 💻 — Wed, 16 Sep 2026 11:47:31 +0000

Whether you're dealing with a toxic co-founder, a demanding manager, or a draining personal relationship, manipulation rarely starts with obvious red flags. Master manipulators don't just hijack your boundaries overnight; they operate in calculated stages, slowly boiling the frog so you don't realize you're being controlled until you feel entirely trapped.

If you've ever found yourself caught in a cycle of second-guessing your own memory and judgment, you might be caught in a manipulator's loop. Here are the five stages of manipulation—and the exact moments you need to hit the brakes and say "no."

Stage 1: The Charm Offensive

Manipulators rarely introduce themselves as the villain. They start with the "charm" phase—often known as love bombing. They are overly complimentary, hyper-agreeable, and seemingly the perfect collaborator or partner. They mirror your interests and make you feel uniquely valued, establishing a rapid, unnatural sense of intimacy to get you to lower your guard.

The Red Flag: The relationship is moving at warp speed, and the flattery feels performative or unearned.
When to Say No: Say no when they demand premature commitments. If a new manager or partner wants you to bypass standard protocols or jump into a massive commitment because "we just connect so well," pump the brakes. A polite "I need to take this at a normal pace" sets a crucial early boundary.

Stage 2: Isolation and Boundary Testing

Once they’ve hooked you with charm, the manipulator begins testing your limits. This starts with small, seemingly innocent requests that blur your personal or professional boundaries. Concurrently, they subtly isolate you from your support network—complaining about your friends, or monopolizing your time so you can't consult mentors who might spot their toxic behavior.

The Red Flag: They make you feel guilty for spending time with others or make "special exceptions" out of your time and energy.
When to Say No: Say no the very first time a boundary is crossed, no matter how small. If they text you at 11 PM for a non-emergency, do not reply until morning. Your silence is a firm, undeniable "no."

Stage 3: Gaslighting and Devaluation

With your boundaries weakened, the facade drops. The manipulator begins to devalue your contributions and intelligence. When you call them out, they deploy gaslighting—a tactic designed to make you question your own reality. They will blatantly deny past conversations, shift the blame, or accuse you of being "too sensitive" or "crazy" to keep you off balance.

The Red Flag: You start keeping receipts, recording conversations, or constantly apologizing for things you know you didn't do.
When to Say No: Say no to their version of reality. You do not have to argue or prove them wrong. Say, "I remember it differently, and I'm not going to debate my reality," and immediately disengage.

Stage 4: The Guilt Trip

When you start pulling away or regaining your independence, the manipulator will pivot to play the victim. This is the guilt-trip phase. Suddenly, they are the ones who have been wronged. They leverage your empathy, reminding you of all the things they did for you back in Stage 1, using obligation and your own moral compass as a weapon against you.

The Red Flag: Every disagreement ends with you comforting them for a mistake they made.
When to Say No: Say no to taking responsibility for their emotions. A simple, "I understand you are upset, but my decision stands," is a complete sentence. Refuse to negotiate your boundaries out of guilt.

Stage 5: Intimidation and Rage

If charm, gaslighting, and guilt fail to bring you back under their control, a highly manipulative person will often resort to intimidation or a smear campaign. This is a desperate attempt to punish you for asserting your independence. They may threaten your job, spread rumors, or erupt in sudden anger to frighten you back into submission.

The Red Flag: Overt threats, passive-aggressive sabotage, or explosive temper tantrums when they don't get their way.
When to Say No: Say no by walking away entirely. At this stage, negotiation is impossible. Document the behavior, loop in HR or your support system, and enforce strict, zero-contact boundaries wherever possible.

Manipulation thrives in the gray areas of human empathy. By recognizing these stages and knowing exactly where to draw the line early on, you protect your most valuable assets: your time, your sanity, and your reality.

The Realpolitik of Tech: Navigating the Machiavellian Reality of People Management

💻 Arpad Kish 💻 — Wed, 16 Sep 2026 04:44:37 +0000

When engineers first transition into leadership, they often carry a fatal misconception: they believe the best code, the cleanest architecture, and the most logical arguments will win.

The reality is far more Machiavellian. In the context of modern tech organizations, being "Machiavellian" doesn't mean being a toxic, backstabbing villain. It means embracing the pragmatic truth of organizational dynamics: power, perception, and politics matter just as much as technical excellence.

To survive and thrive in tech leadership, one must recognize the stark realities of people management and understand the inherent friction between the three pillars of tech delivery: Engineering Management, Tech Leadership, and Team Leadership.

The Machiavellian Reality of People Management

In an ideal world, management is purely servant-leadership. In the real world, it is a complex game of resource allocation, expectation management, and strategic alignment.

Here are the unspoken realities of managing people in tech:

Optics are the Currency of Trust: Your team might be doing brilliant, foundational refactoring, but if the business doesn't see feature velocity or cost reduction, you are failing in their eyes. Good managers manipulate optics not to deceive, but to translate engineering realities into business value.
Headcount is Leverage: In corporate tech, a manager's influence is often directly correlated with the size of their team and the criticality of their systems. Protecting and expanding your headcount is a political necessity to ensure your team isn't swallowed or sidelined during the next reorg.
Strategic Empathy: You cannot motivate everyone with "interesting technical challenges." Real people management requires uncovering what your reports actually want—promotions, coasting, visibility, or stability—and using those distinct levers to drive the organization's goals forward.
The Shield is a Sieve: Managers are told to "shield the team from corporate noise." But a purely shielded team becomes alienated and unpromotable. A pragmatic manager selectively leaks political context so the team understands why they are building what they are building.

The Disparate Triad: EM, TL, and Team Lead

The friction in modern engineering orgs often stems from a fundamental misunderstanding of the leadership triad. Organizations often conflate these roles, leading to burnout and crossed wires. Each role has a distinct, often competing, mandate.

1. Engineering Management (The Diplomat)

The Engineering Manager (EM) is the political operator. Their primary concerns are outward and upward.

Mandate: Retention, budgets, performance reviews, and cross-functional alignment (Product, HR, Finance).
The Reality: The EM is playing a zero-sum game for budget and promotion slots. Their job is to make the team look good to directors and VPs, ensuring the team's survival and growth.
Blind Spot: They can become so detached from the codebase that they make promises the architecture cannot support.

2. Tech Leadership (The Architect)

The Tech Lead, Staff, or Principal Engineer is the guardian of the system. Their primary concerns are downward and forward (into the codebase and the future).

Mandate: System architecture, technical debt resolution, scalability, and code quality.
The Reality: The TL is constantly fighting for technical purity in a business that only cares about feature delivery. They must wield influence without formal authority, often using fear (e.g., "the database will tip over") to negotiate time for refactoring.
Blind Spot: They often ignore the business realities of runway and time-to-market, seeking elegant solutions when a duct-tape fix would win the quarter.

3. Team Leadership (The General)

Often operating as a Scrum Master, Delivery Lead, or a tactical Tech Lead, the Team Leader is concerned with the immediate horizon.

Mandate: Sprint execution, unblocking day-to-day work, velocity metrics, and tactical morale.
The Reality: The Team Lead is in the trenches. They care about getting tickets across the Jira board today. They are the friction point between the EM's lofty promises and the TL's grand architectural visions.
Blind Spot: They can become so hyper-focused on short-term delivery that they miss team burnout (EM territory) or compounding technical debt (TL territory).

The Inevitable Conflict

Because these roles are fundamentally disparate, tension is not just likely—it is designed into the system.

Role	Primary Currency	Natural Enemy
Engineering Manager	Optics & Predictability	Unplanned technical debt
Tech Lead	Quality & Scalability	Arbitrary business deadlines
Team Lead	Velocity & Completion	Complex architectural overhauls

A successful organization doesn't try to eliminate this tension; it balances it. When an EM acts like a Tech Lead, micromanaging the architecture, the system breaks down. When a Tech Lead acts like an EM, optimizing for Jira points instead of system stability, technical bankruptcy follows.

Embracing the "Machiavellian" reality simply means accepting that these competing agendas exist. The most effective leaders in tech are those who understand the specific game they are playing, respect the different mandates of their peers, and negotiate the compromises necessary to keep the machinery moving.

Demystifying Vector Distance in PostgreSQL

💻 Arpad Kish 💻 — Sun, 16 Aug 2026 08:50:55 +0000

A look into sliding window comparisons for image analysis.

When you need to perform complex similarity comparisons inside a database, you often have to bridge the gap between application-level data structures (like JSON) and low-level math (like vectors).

The PostgreSQL snippet provided is a classic example of this bridge. It sets up the foundation for a sliding window comparison—a technique where you analyze overlapping sequences of data—by extracting features from a JSON payload and calculating how "far apart" two sets of image data are using Euclidean distance.

Part 1: Extracting the Features

Before you can compare two sets of data, you have to format them into a mathematical structure. The get_vector_values function handles this transformation.

This function takes a JSONB array of objects (the cluster_vector) and flattens it into a single, one-dimensional array of real numbers (real[]).

Notice the specific keys being extracted: a, b, and l. This strongly implies the data represents CIELAB (L*a*b*) color space values. In image processing, extracting the average L*a*b* values of images and comparing them is a common way to detect duplicates or cluster similar images together.

The function loops through the JSON array three separate times to group all the a values together, then the b values, and finally the l values. This creates a continuous vector signature representing that specific "window" of image data.

Part 2: Calculating the Distance

Once your image data is flattened into arrays, the distance function determines how mathematically similar they are.

This function implements the standard Euclidean Distance formula. It iterates through both arrays up to a specified length, calculates the squared difference between each corresponding element, sums them up, and finally returns the square root (using PostgreSQL's square root operator |/).

The smaller the returned number, the more similar the two image vectors are. A distance of 0 means they are identical.

The Source Code

/*
 * @rpi1337
 */

module.exports = `

CREATE OR REPLACE FUNCTION get_vector_values(cluster_vector jsonb) RETURNS real[] AS $$
DECLARE
  list real[] [];
  i jsonb;
BEGIN
  FOR i IN SELECT * FROM jsonb_array_elements(cluster_vector) LOOP
    list := array_append(list, (i->>'a')::real);
  END LOOP;
  FOR i IN SELECT * FROM jsonb_array_elements(cluster_vector) LOOP
    list := array_append(list, (i->>'b')::real);
  END LOOP;
  FOR i IN SELECT * FROM jsonb_array_elements(cluster_vector) LOOP
    list := array_append(list, (i->>'l')::real);
  END LOOP;
  RETURN list;
END;
$$ LANGUAGE plpgsql IMMUTABLE;

CREATE OR REPLACE FUNCTION distance(l real[], r real[], length INT) RETURNS real AS $$
DECLARE
  s real;
BEGIN
  s := 0;
  FOR i IN 1 .. length LOOP
    s := s + ((l[i] - r[i]) * (l[i] - r[i]));
  END LOOP;
  RETURN |/ s;
END;
$$ LANGUAGE plpgsql IMMUTABLE;

`;

Modernization Considerations

For modern, large-scale production applications, iterating over JSON elements multiple times and performing custom mathematical loops in PL/pgSQL can be CPU-intensive.

A modernized approach often employs extensions like pgvector, which offloads operations like Euclidean distance computations to optimized C libraries, allowing indexes like HNSW and IVFFlat to significantly speed up similarity searches across large image datasets.

*Authored by @rpi1337 — View more at arpi.im*

Cracking the cloud-mess: Istio, K8s, Helm charts and why you don't need them

💻 Arpad Kish 💻 — Tue, 28 Jul 2026 12:28:07 +0000

It usually starts with the best intentions. You have a new project, and you want to build it "right" from day one. You want it to be scalable, resilient, and future-proof. So, you look at how the giants do it. You see engineering blogs from massive tech companies detailing how they run fleets of microservices orchestrated by Kubernetes, managed by Helm, and secured by Istio.

You think: If it's good enough for them, it's the right way for us.

Fast forward six months. Your team is spending half their week fighting YAML indentation errors, debugging network policies, and waiting for bloated CI/CD pipelines to finish, rather than shipping features to your users.

Welcome to the cloud-mess.

The Usual Suspects

Before we tear them down, let's look at the tools that usually make up this modern infrastructure cocktail.

Kubernetes (K8s): The undisputed king of container orchestration. It dictates how containers are deployed, scaled, and managed across a cluster of machines.
Helm: The "package manager" for Kubernetes. It uses templates (Helm Charts) to define, install, and upgrade complex Kubernetes applications.
Istio: A service mesh. It sits as a dedicated infrastructure layer right on top of Kubernetes to handle service-to-service communication, adding features like traffic routing, encryption (mTLS), and observability.

Individually, these are phenomenal pieces of engineering. Together, they form an incredibly powerful stack for operating software at a massive scale.

The problem? You are almost certainly not operating at that scale.

The "Tech Giant" Fallacy

The software industry has a serious problem with Resume-Driven Development. We often adopt technologies not because they solve our immediate business problems, but because they look great on a CV or sound impressive in a meeting.

When you adopt Kubernetes, Helm, and Istio, you aren't just adopting software; you are adopting a distributed systems philosophy. You are taking on the operational overhead of a tech giant without having their revenue or headcount.

Massive Cognitive Load: To deploy a simple web application, a developer now needs to understand Docker, K8s Pods, Deployments, Services, Ingress controllers, Helm templating syntax, and Istio virtual services. That is a heavy tax on developer velocity.
The Hidden Costs: Running a managed Kubernetes cluster (like AWS EKS or Google GKE) costs money just for the control plane. Add in the compute resources required to run the Istio sidecar proxies, the Prometheus/Grafana stack to monitor it all, and the dedicated engineers required to keep it breathing, and your infrastructure bill has suddenly multiplied.
Debugging Hell: When a request fails in a traditional monolithic app, you check the stack trace. When a request fails in a microservices mesh, you have to trace it through an API gateway, multiple load balancers, sidecar proxies, and network policies, praying your distributed tracing is configured perfectly.

The Antidote: Boring Architecture

If you are building a SaaS product, an internal tool, or a consumer app that isn't currently serving millions of concurrent requests, you need to ruthlessly simplify your stack. Your goal is to ship value to users, not to maintain a pristine cloud-native ecosystem.

Here is what you should reach for instead:

1. The Majestic Monolith

Don't split your application into microservices until a single codebase becomes structurally impossible for your teams to work on simultaneously. A well-structured monolith (often called a modular monolith) is vastly easier to deploy, test, and debug. When performance bottlenecks eventually happen, scale vertically first—compute power is cheaper than engineering time.

2. Managed Containers (Serverless)

If you need to run containers, let someone else manage the orchestration. Services like AWS App Runner, Google Cloud Run, or Azure Container Apps abstract away the underlying infrastructure. You give them a Docker container, and they handle the routing, scaling (even down to zero), and load balancing. You get the benefits of containerization without the operational nightmare of K8s.

3. Platform as a Service (PaaS)

If you want to move even faster, skip containers entirely. Platforms like Render, Heroku, or Vercel allow you to connect your GitHub repository and let the platform handle the build and deployment pipeline. Yes, they cost a premium per compute hour compared to raw AWS EC2 instances, but they save you the salary of a full-time infrastructure engineer.

The Bottom Line

Kubernetes, Helm, and Istio are tools designed to solve the organizational and scaling problems of enterprises with hundreds of engineering teams and massive global traffic.

If your engineering team can fit in a single conference room, adopting the full cloud-native stack is like buying a commercial airliner to commute to the grocery store. Keep it simple, keep it boring, and focus on building the product your users actually care about.

Functional programming primitives in Javascript

💻 Arpad Kish 💻 — Sun, 19 Jul 2026 06:34:38 +0000

Category theory often sounds like impenetrable academic jargon, but at its core, it is simply the mathematics of composition. In functional programming, we use its concepts to build modular, predictable, and bug-resistant code.

JavaScript isn't a pure functional language like Haskell, but it has first-class functions and treats functions as values. This makes it entirely possible to implement category theory primitives.

Here is how the theoretical concepts map to practical JavaScript.

The Vocabulary of Category Theory

Before jumping into code, let's define the fundamental pieces:

Categories: A collection of objects and arrows (morphisms) between them.
Objects: In programming, these are our types or data (e.g., String, Number, Boolean, Array).
Morphisms: These are our pure functions that transform one type into another (e.g., a function that takes a String and returns a Number).

The goal of functional programming primitives is to create safe wrappers (containers) around our data so we can compose these functions predictably, without side effects or unhandled errors.

1. Functors: The Mappables

A Functor is any type that implements a map method. It is a container holding a value, and map allows you to apply a function to that value without pulling it out of the container.

When you map over a Functor, it returns a new Functor of the same type, preserving the container's structure.

The native JS Functor:
You already use Functors every day. JavaScript Arrays are Functors.

const numbers = [1, 2, 3];
// We apply a function to the values inside, and get a new Array back
const doubled = numbers.map(x => x * 2); // [2, 4, 6]

Building a custom Functor:
Let's build a simple Box container to see how this works for single values.

const Box = x => ({
  map: f => Box(f(x)),
  fold: f => f(x), // An escape hatch to get the value out
  inspect: () => `Box(${x})`
});

// Usage:
const result = Box('  Functional Programming  ')
  .map(str => str.trim())
  .map(str => str.toLowerCase())
  .map(str => str.split(' '));

console.log(result.inspect()); // Box(Array(2))
console.log(result.fold(x => x)); // ['functional', 'programming']

Because map always returns a Box, we can chain operations infinitely.

2. Monoids: The Combiners

A Monoid is a type that has two things:

An identity value: A value that, when combined with another value, doesn't change it (like 0 for addition, or "" for strings).
An associative binary operation: A function that combines two values of the same type into one (like + or concat()). "Associative" just means the grouping doesn't matter: (a + b) + c === a + (b + c).

The native JS Monoids:
Strings and Numbers are standard monoids under specific operations.

// String Monoid (Identity is "")
const strConcat = "hello" + ""; // "hello"

// Number Monoid for Addition (Identity is 0)
const numAdd = 5 + 0; // 5

// Array Monoid (Identity is [])
const arrConcat = [1, 2].concat([]); // [1, 2]

Monoids are incredibly powerful for reducing a list of things into a single thing. This is exactly what Array.prototype.reduce relies on.

3. Monads: The Flatteners

The infamous Monad. The standard joke is that "a monad is just a monoid in the category of endofunctors," which is true mathematically but useless for programming.

Practically, a Monad is a Functor that also implements a flatMap (or chain, or bind) method.

The Problem Monads Solve:
If you have a function that returns a Box, mapping it over a Box results in a nested container: Box(Box(value)). A Monad knows how to flatten itself to prevent this nesting.

// A function that returns a container
const half = x => (x % 2 === 0 ? Box(x / 2) : Box("Odd"));

// Using map creates nested Boxes
const nested = Box(4).map(half);
console.log(nested.inspect()); // Box(Box(2))

Adding Monadic Behavior:
To make our Box a Monad, we add chain (the JS convention for flatMap).

const MonadicBox = x => ({
  map: f => MonadicBox(f(x)),
  chain: f => f(x), // Instead of re-boxing, we just return the result of f(x)
  inspect: () => `Box(${x})`
});

const flatResult = MonadicBox(4).chain(half);
console.log(flatResult.inspect()); // Box(2) - No nesting!

The native JS Monads:

Array.prototype.flatMap makes Arrays monads.
Promise is heavily inspired by Monads. Calling .then() with a function that returns a new Promise automatically flattens the result. You never get Promise<Promise<Data>>.

4. Applicatives: The Multi-Container Operators

What happens if you have a function wrapped in a Functor, and you want to apply it to a value wrapped in another Functor? A standard Functor's map expects a normal function, not a wrapped one.

An Applicative implements an ap method to solve this.

const AppBox = x => ({
  map: f => AppBox(f(x)),
  ap: otherBox => otherBox.map(x), // x here is actually a function!
  inspect: () => `Box(${x})`
});

const boxWithFunction = AppBox(x => x + 10);
const boxWithValue = AppBox(5);

// Applies the wrapped function to the wrapped value
const result = boxWithFunction.ap(boxWithValue); 
console.log(result.inspect()); // Box(15)

Summary of Primitives

Here is a quick reference guide to how these primitives build on top of each other:

Primitive	Core Interface	Purpose
Functor	`map`	Apply a function to a wrapped value.
Applicative	`ap`	Apply a wrapped function to a wrapped value.
Monad	`chain` / `flatMap`	Sequence operations that return containers, preventing nesting.
Monoid	`concat` + `empty`	Combine values of the same type safely.