Abdullah Ayman

Blog

  • Code Quality Is the Victim

    Code Quality Is the Victim

    AI still generates bad code. Bad system design, redundant logic, repeated components, unnecessary re-renders. That hasn’t changed. What changed, from what I’ve seen, is that people stopped looking.

    Let me walk through how we got here.

    The Autocomplete Era

    This was probably the best phase of AI-assisted development. You knew exactly what you wanted to write and where. The AI just typed it for you. If the suggestion was off, you saw it immediately and corrected it. You were still in the driver’s seat. The AI was a fast typist, nothing more.

    The code that came out of this era was mostly yours. You understood it because you were making every decision. The AI was filling in the blanks you already knew the answers to.

    Agents Enter the Picture

    Then Cursor and Claude Code showed up, and the dynamic shifted. Now the agent wasn’t just finishing your sentence. It was writing entire features.


    In the beginning, developers were still reviewing the output. The agent would do most of the work, but you’d scrutinize the result, find the issues, and fix them. And while you were in there fixing things, you’d notice other problems. A structural issue here. A questionable design decision there. You’d fix those too. The process of reviewing AI output was accidentally making developers engage deeply with the codebase. It wasn’t perfect, but the feedback loop still existed.

    Where We Are Now

    On some of the teams and projects I’ve been close to, the pattern looks like this: managers want fast results. Developers use agents to move fast. The feature works. The manager is happy. So the developer asks themselves: why would I review the code?

    They don’t. They move on to the next task.

    This isn’t because AI agents suddenly got better at writing clean, optimized code. They didn’t. What changed is two things: far fewer people are looking, and the code actually runs now. Early AI-generated code was broken in obvious ways. It had bugs you’d hit immediately, and that forced you back into the code to read it, understand it, and fix it. The broken output was accidentally a quality check. That’s no longer true. The code agents produce today mostly works. The feature does what it’s supposed to do. The tests pass. The manager clicks through the UI and sees no errors. So there’s no moment that forces the developer to look closely. When the output was broken, review was mandatory. Now that it runs, review feels optional. And under deadline pressure, optional things don’t happen.

    In codebases I’ve worked on, this is exactly what slips through: the page re-rendering three times when it should render once، the three separate loops over the same dataset that could’ve been one, the component copy-pasted into five different files because the agent didn’t know it already existed.

    The product works. Ship it.

    The problems are still there. They’re just hiding under working software.

    I don’t think this is entirely the developer’s fault. If you have ten tasks before a deadline and you stop to reason through every trade-off in every file the agent touched, you will not finish. The pressure is real. The incentive to just move is real.

    The Trade-off Nobody Names

    Here’s the honest version of what’s happening: many teams are trading codebase health for delivery speed, without acknowledging that it’s a trade-off at all.

    That’s the part that bothers me. The trade-off itself isn’t wrong. Sometimes you need to ship fast and clean up later. That’s a legitimate call. But when you don’t recognize it as a trade-off, you don’t plan for the cleanup. The technical debt doesn’t get scheduled. The codebase quietly rots. And then one day the cost of adding a new feature is three times what it should be, and nobody can explain why.

    You either keep the codebase clean and take longer to build, or you build fast and inherit a codebase you’ll eventually want to throw away and rewrite from scratch. Both paths are real. Both have costs.

    The mistake is pretending the second path has no cost just because the demo looks fine.

    The Rule I Work By Now

    I can’t fix the incentives of a whole industry, so I settled on a rule for my own work instead: I don’t ship agent-written code I can’t explain. Not a line-by-line audit of every file, but enough reading that I could tell a reviewer why each piece exists. If I can’t, I either read until I can, or I delete it and let the agent try again under my direction.

    And when a deadline genuinely forces me to skip that, I treat it as borrowing, not earning. The unreviewed code gets written down as debt, with a task and a date, instead of left as a silent hope. Making the trade-off is fine. Making it invisible is the part I refuse to do.

  • When My Own Pull Request Tried to Steal Secrets

    When My Own Pull Request Tried to Steal Secrets

    This is my third write up about contributing to WooCommerce. The first one was about a “good first issue” that taught me how a large codebase fits together. The second was about a block where I learned to read before I write. This one is different. This time the most important thing I learned had nothing to do with the feature I was fixing, and everything to do with a piece of malware that hijacked my machine and pushed itself into an open source project used by millions, under my name.

    Let me tell the story from the start.

    Why I picked this issue

    After two merged PRs, I wanted something harder than a “good first issue”. I wanted a real bug, the kind where something is silently broken and you have to understand why.

    The issue I found was exactly that. When you enable “Full Page Reload” on a Product Collection block, the product filters stop applying. You click a filter, and nothing happens. I liked it because it touched parts I hadn’t worked with before in this repo: server side rendering, the interactivity API, and the way two separate blocks talk to each other on the same page. So I commented on the issue (https://github.com/woocommerce/woocommerce/issues/64057), asked to be assigned, and started.

    Naming the real problem

    I carried the lesson from my last PR with me, which is to read before touching anything. So before writing a single line, I spent time
    understanding how these blocks are connected.

    That reading changed how I saw the whole thing. Product Collection and Product Filters are not parent and child. They are siblings on the page, linked only by a shared queryId, with no shared DOM parent between them. So this was not really a “filter bug”. It was a communication problem between two blocks that don’t have an easy way to talk to each other. Once I named it that way, I knew what kind of solution I was actually looking for.

    The first fix, and the trade off I didn’t fully weigh

    My first solution worked. On the server, the Controller marked the block with a forcePageReload flag. On the client, the navigate action read that flag, and if it was set, it did a full window.location.assign(url) instead of going through the interactivity router. I pushed it, opened the PR (https://github.com/woocommerce/woocommerce/pull/64131),
    and Albert (Aljullu), the same maintainer who reviewed my earlier PRs, confirmed it. He wrote “Really nice work” and said the PR fixed the issue. But he also left a comment, and CodeRabbit raised the same point. I had passed the flag using wp_interactivity_config, which is a global. That meant one Product Collection’s setting would leak into every Product Filters block on the page. My fix made the bug go away, but it wasn’t correct. This is something I keep relearning: making a bug disappear and solving it properly are two different things. I had chosen the global config because it was the fastest path to a working result, and I had quietly pushed the real cost into the future.

    I was getting ready to fix that. And then something much stranger happened.

    A nation state worm hijacked my pull request

    My .gitignore had quietly stopped ignoring .env, and my postcss.config.js had an obfuscated payload added to it that ran at import time. I stared at it. I had not written that. I had not even opened those files.

    What I had on my machine was something called PolinRider. It is a supply chain attack attributed to the Lazarus Group, and by the time I ran into it, it had already infected almost two thousand GitHub repositories. I picked it up from a teammate on a completely different project, through a weaponized npm package that pretended to be a normal PostCSS and Tailwind utility. Once it was on my machine, it appended its obfuscated code to config files like postcss.config.js, which is its most common target, and dropped a small batch file that ran git commit --amend and force pushed with –no-verify, even rolling my system clock back to fake the original commit time. That is exactly how malicious code ended up inside my branch, under my name, without me ever seeing a prompt or a diff. The payload’s whole purpose was to read secrets, which is why it un-ignored .env.

    The part that still sits with me is the target. This was aimed at a project used by millions of people, and my own laptop was the delivery
    vehicle. I always thought of my environment as separate from the code I ship. It is not. My machine is part of the supply chain too.

    Burning it down instead of cleaning it up

    When you are dealing with something that amends commits and force pushes behind your back, you cannot trust that you found every trace of it by reading a diff. Trying to scrub it carefully felt like exactly the kind of confidence that gets you in trouble. So I followed Albert’s suggestion, and closed the PR. And I fully removed the malware from my machine using a public write up that documents the campaign and how to clean it (https://github.com/OpenSourceMalware/PolinRider) before I wrote another line of code.

    Doing it right the second time

    I opened a new PR (https://github.com/woocommerce/woocommerce/pull/64247), and this time I opened it as a draft, because I wasn’t done.

    Before I asked anyone anything, I tried to solve it myself. I spent about two days looking for the correct way to drop the global config and handle the sibling case properly, and I could not find it. The thing I kept missing was simple in hindsight: I never thought to split the problem into separate cases and handle each one on its own. I was looking for a single clean answer to a problem that actually had two shapes.

    After those two days, I decided to ask Albert. I told him that Product Collection and Product Filters are siblings, linked only by queryId,
    with no shared DOM parent, and asked what the cleanest pattern in the codebase was for this kind of per instance communication. I asked because I wanted the solution to follow the repo’s own conventions, not to invent some pattern of my own that fights the way the codebase already does things. The best solution was the one that fits the project, and Albert knows the project far better than I do.

    That question was worth more than any number of speculative commits. Albert gave me two clear paths. For the case where Product Filters is a
    descendant of Product Collection, the query context already flows down, so I could read forcePageReload straight from $block->context['query'] and pass it through the rest of the interactivity context. For the sibling case, I would keep my config approach but let the per instance context
    take priority over the global config when it is defined.

    So that is what I built. The flag now travels through real per instance context using providesContext and usesContext, with the config only as a fallback. I added the types, updated the tests, wrote the changelog, and fixed the PHPStan baseline. The fix was finally correct, not just working. It was merged.

    What I took from this

    On the code side, the lesson is the one I keep circling back to. Reach for the scoped, correct tool first. “It works” and “it’s correct” are two
    different review gates, and a maintainer’s job is to catch the gap between them.

    On security, this changed how I think about my own setup. I now assume my environment is part of what I ship. I rotated the secrets that were reachable, audited my lockfile and editor extensions for the known bad packages, and I read my own diff line by line before pushing, instead of trusting that the only changes are the ones I remember making.

    And on collaboration, the strongest move in this whole story was a single well scoped question to the right person, but only after I had earned it. I spent two days trying to find the correct fix on my own before I asked. Trying first is what made the question sharp, and asking the maintainer is what kept my solution aligned with the repo’s own conventions instead of some pattern I invented that fights the codebase. The goal was always the solution that fits the project, and sometimes the fastest way to that is to ask the person who knows it best.

  • I Fixed a Bug I Never Found in AI-Generated Code

    I Fixed a Bug I Never Found in AI-Generated Code

    A few days ago, I was working on a fairly complicated feature: web sockets, AI live sessions, and user media interaction in the browser. I had been at it for about two weeks.

    At the start, I created a comprehensive plan with Claude Code. It looked solid. Implementing the plan took about an hour, fixing the initial bugs took another hour, and then I tested it. The feature was ostensibly working, so I moved on. The wrong decision I made: I never actually read the code.

    Over the following days, I kept layering more features on top of that foundation without reviewing a single line. Things looked like magic. Until they didn’t.

    When Everything Dropped at Once

    At a specific point in the implementation, everything stopped working. I tried solving it with AI. It got worse. I spent three days in that loop before accepting that no amount of prompting was going to find whatever was buried in there.

    Something was deeply wrong, and I had no idea where, because I had never actually understood the code I was building on.

    8 Hours of Reading My Own Codebase

    I stepped back and started walking through the flow from the beginning, following the request lifecycle and each socket event manually. No AI. Just me and the code.

    It took about 8 hours. Almost every line needed refactoring. I deleted a significant amount of logic: some of it I didn’t understand, some of it looked completely useless. I wasn’t sure which category some pieces fell into, but if I couldn’t reason about why something existed, I removed it.

    Then I ran the code.

    Everything worked perfectly.

    I never found the original bug. I just deleted it. It was hiding somewhere inside code I hadn’t written, hadn’t read, and didn’t understand, and the fix was making the codebase small enough that I could finally hold it in my head.

    What I Actually Learned

    AI got me moving fast. That part is real. But it also handed me a codebase I had no mental model of, and when something broke deep inside it, I had no way to reason about the problem. The tool that saved me an hour upfront cost me three days later.

    The failure wasn’t using AI. The failure was skipping the step where I actually understand what I’m building.

    Treating generated code as a draft to read and revise isn’t slower than trusting it blindly. It’s the opposite. Because the hour you spend reading is the insurance policy against the three days you’d spend debugging something you never understood in the first place.

  • What a “Good First Issue” Taught Me About Real-World Software Engineering

    What a “Good First Issue” Taught Me About Real-World Software Engineering

    When I opened my first pull request to WooCommerce, I chose an issue labeled “good first issue.”

    Not because it looked exciting.
    Not because it was high impact.

    But because I wanted a safe way to enter a large and unfamiliar codebase.

    That choice taught me more about real world software engineering than I expected.

    Why I Picked It

    The issue was about replacing WooCommerce’s custom accordion block with the WordPress core accordion block for WordPress 6.9 and later.

    It was tagged as a good first issue.
    There were no open pull requests.
    No one had said they were working on it.

    My goal was not to make a big impact. My goal was to understand how WooCommerce is structured and how its blocks are built.

    Looking back, that was my first real engineering decision: focus on learning, not visibility.

    Setup Problems Are Normal

    I cloned the repository and followed the README to set things up locally using wp-env. It did not work right away. Docker needed changes. File sharing settings had to be adjusted.

    That was my first reminder that setup problems are normal in real projects.

    Once everything was running, I started exploring the block structure. Each block had:

    • A PHP part for backend behavior
    • A React part for the editor interface
    • Separate behavior for editor and frontend rendering

    Even though the issue was labeled “good first,” it touched several parts of the system.

    That was my second lesson: “good first” does not mean easy. It means limited in scope.

    My First Mistake

    When I ran into problems, especially with tests, I searched online and asked AI tools how to fix them.

    Some answers helped. Some did not.

    What I ignored at first were the README files inside the project’s test folders. They had clear instructions written for this codebase.

    I wasted time because I looked for general answers instead of reading the project documentation.

    In real software projects, local context matters more than generic advice.

    When It Finally Worked

    After updating the PHP and JavaScript files, I tested the block in the browser. It did not work at first because I forgot to rebuild the project.

    After rebuilding, it worked.

    That moment felt small, but it mattered. It was the first time I changed something inside a large open source product and saw it working in a real interface.

    But seeing it work in the browser was not enough.

    Tests Are Part of the Work

    When I opened the pull request, many GitHub Actions workflows ran automatically. Lint checks failed first because my formatter did not match WordPress coding standards.

    Instead of fixing each issue by hand, I set up my auto formatter correctly. It took more time at the start, but saved time later.

    Then integration tests failed.
    Then end to end tests failed.

    Running E2E tests locally was difficult. A welcome modal blocked execution, and I could not match the CI behavior exactly on my machine.

    So I made a trade off.

    Instead of perfecting my local setup, I opened a pull request on my fork and used CI results to guide my changes. Feedback was slower, but it matched the maintainers’ environment.

    That helped me keep moving.

    Sometimes it is better to make steady progress than to aim for a perfect setup.

    The Bigger Lesson

    If this pull request had never been made, WooCommerce would have kept its own accordion instead of using the WordPress core version for newer installs.

    It was not a flashy feature. But it reduced duplicate code and kept WooCommerce closer to WordPress core.

    That is something I understood only after working through the change.

    Much of real world software engineering is not about building new features. It is about reducing future maintenance work and keeping systems aligned.

    What a “Good First Issue” Really Taught Me

    It taught me that engineering is not only about writing code.

    It is about:

    • Reading the project before changing it
    • Understanding how backend, frontend, and tests connect
    • Making trade offs with limited time and knowledge
    • Improving your tools so future work is easier
    • Accepting feedback and improving
    • Thinking about maintenance, not just implementation

    The label said “good first issue.”

    What it gave me was my first real experience working inside a production level, community driven codebase.

    Real world engineering is less about solving a problem once, and more about solving it in a way that fits the system, the team, and the future.

  • What Being the Only Developer Early in My Career Taught Me

    What Being the Only Developer Early in My Career Taught Me

    I was employed for the first time in my career in the second quarter of 2022. At that time, I was the only developer working in the company. The first company in one’s career is an important step, as it is where you gain a lot of experience from old developers, which is not what happened with me.

    Dealing Directly with Business Owners

    Being the only developer in the company means I don’t just implement tasks, I create them. There were no developers or product managers who understood business needs to divide that into smaller tasks and assign them to me. I was the one who talked with the owners to understand the goals of their business, suggested how the system can help achieve those goals, and implemented that system.

    The ‘I Know How to Do It’ Trap

    This environment was a perfect example of one that can produce a bad engineer who implements everything in the wrong way. Any problem I face, I have a way to solve it, but it does not take long to realize that this is the way engineers were solving it twenty years ago. I learned that I have to search and learn how those problems are solved, even if I have an idea for solving them that looks brilliant.

    Nobody Understands What I Am Doing

    Business owners are only interested in what the end result is. If I leave a significant issue in the code, such as a security vulnerability, there is nobody to discover it. I had to be the reviewer of my own code, and make sure that the code I deliver is the best I can do, even when the owners can’t see that. There were also situations when I face a complicated problem, but simply nobody cares. They only see that I have been late, and didn’t deliver the product in time. I learned that I have to be dedicated to what I am doing even if nobody understands it. Stopping and listening to them would just make the situation worse.

    Over time, all of these experiences changed how I was approaching problems and learning as an engineer. I realized that I don’t know everything, or actually that I know very little. I have to always learn, even when I think I know the topic.
    A quick search will not take much time, but may change the whole approach you take.

    In other words, confidence without continuous learning is dangerous, and responsibility doesn’t disappear just because no one is watching.

  • How Solving the Cutting-Stock Problem at 19 Changed How I Build Software

    How Solving the Cutting-Stock Problem at 19 Changed How I Build Software

    When I was 19, I joined a company in Egypt that built a mobile application used by thousands of people in the uPVC industry. The app helped workshops calculate the exact cuts and measurements needed to manufacture windows and doors.

    During my first weeks there, the team asked for a new feature they weren’t sure was even possible:
     automatically generating optimal cutting plans to reduce wasted material.

    They didn’t know the name of the problem.
     I didn’t either.
     But something about the challenge made me want to understand it deeply.

    Finding the real problem

    The first thing I learned was that the difficulty wasn’t in coding the feature. It was in figuring out what the problem actually was.

    After a few days of reading forums, digging through academic papers, and searching for what this type of optimization belonged to, I finally discovered the name:
     the Cutting-Stock Problem, a well-known problem in operations research.

    That moment changed something in me.
     Until then, I assumed every feature request in a job had a straightforward implementation.
     This was the first time I realized that naming a problem correctly is half the solution.

    My process: research first, code second

    Once I understood the problem type, I spent a week studying classic solutions:

    • First-Fit Decreasing
     • Dynamic Programming
     • Linear Programming approaches
     • Different heuristics and trade-offs between speed and optimality

    I didn’t have anyone to ask in the company. I was the only developer there at that time, so I had to build my own understanding from scratch.

    This forced me to slow down, take notes, sketch ideas, and think like a researcher instead of a feature implementer.

    Choosing a realistic approach

    At first, I planned to implement everything completely from scratch. I quickly realized this would be extremely difficult and not the smartest way to solve the problem.

    So I shifted direction.

    While exploring different approaches, I found a Python implementation using Google OR-Tools. It explained the idea clearly and showed how other people modeled similar constraints.

    I studied the logic carefully, understood how the solver defined the variables and constraints, and then recreated the same algorithm in C#.
     This approach wasn’t about taking a shortcut. It was about understanding the model deeply and rebuilding it in a way that fit our system.

    You can see the C# version I built here:
     https://github.com/AbdullahAymanMSRE/cutting_stock_problem_cs

    Designing the solution in C#

    Even with OR-Tools guiding the direction, I still had a lot of decisions to make:

    • whether to aim for perfect optimization or acceptable optimization
     • how to structure the input to match real workshop needs
     • how to design the logic so it ran fast on normal machines
     • how to let users tweak parameters without overwhelming them

    The first version wasn’t perfect.
     The second one was much better.
     And the final one was good enough to be used daily by thousands of people.

    Publishing the core logic later felt important, because I knew someone out there would be searching for the same thing I had searched for.

    Trade-offs I had to navigate

    One of the biggest lessons was understanding that there is no best algorithm. There is only the best algorithm for a specific situation.

    Some trade-offs I had to consider:

    • Speed vs accuracy
     • Memory vs clarity
     • Perfect engineering vs shipping on time

    This was my first exposure to real engineering constraints.

    The surprising lesson

    The technical part was interesting, but the biggest impact on me came from something else:

    I learned how much I don’t know.

    When you suddenly discover an entire field like operations research, you start wondering what other fields you’ve never heard of yet. That mindset has stayed with me ever since.

    Today, before jumping into a new task, I ask myself:

    Is there a known name for this problem?
     Has someone already solved it in a different field?
     Am I choosing this approach because it’s best, or because it’s the only one I know?

    That experience taught me that being a good engineer has less to do with typing code fast and more to do with understanding the problem deeply before touching the keyboard.

    How this shaped my engineering mindset

    Looking back, this project taught me four things that influence how I work today:

    1. Understanding beats rushing
       Taking time to research saved weeks of wrong implementation.
    2. Naming the problem is a superpower
       Once you know the name, you can find decades of prior solutions.
    3. Trade-offs are the real engineering
       Sometimes good enough is more valuable than perfect.
    4. Curiosity outperforms confidence
       Once you think you know enough, you stop being creative.

    Final thoughts

    I didn’t realize it back then, but solving this feature shaped how I think about engineering more than any tutorial or course ever did.

    It taught me to be curious, to research widely, to question my assumptions, and to never rely only on what I already know.

    And it reminded me of a simple fact that I still repeat to myself often:
     you don’t know what you don’t know.