DEV Community: Mellina Yonashiro

Use case: Creating an agentic workflow from frontend to test automation

Mellina Yonashiro — Wed, 30 Sep 2026 09:04:55 +0000

Introduction

Every time our Frontend (FE) changed a UI component, a little nightmare started: tests broke, the Test Automation (TA) team was called and what seemed to be endless back-and-forth happened.

I saw an opportunity to reduce this friction by introducing a headless agent into our workflow - one that picks up the broken tests and tries to fix them.

Developing automations like this is a hard process though - designing a meaningful flow, dealing with cross-dependencies and accesses that might turn into dead-ends, and other unknown issues along the way. In this article, I'll walk you through the problem, the design decisions and trade-offs, and how it was implemented end-to-end.

The Problem

When working in frontend, we have some CI steps set up. One of them is to run test automation. More often than not, these tests fail because frontend changed the HTML structure or user flow altogether. When this happens, we have to go through these steps shown in the diagram.

Summarizing:

FE: makes a breaking change. Tests break.
TA: skip related tests.
FE: CI pipeline now passes and merges the feature branch.
TA: unskip the test, fix them, open a pull request and merge.

This workflow triggers for every feature branch opened by FE. The steps have to be done in sequence, and the flow involves at least four engineers (the ones writing the code and the ones reviewing it), context switching, and cross-team dependency. Also, there is a period in between that we lose test coverage: the tests pass, but only because they're skipped.

For our experiment, we decided to narrow our focus to something specific and easy to fix: when FE changes a UI component, needing a selector change; and only smoke tests would be used as the gate. I’ll give you more context below.

What are selectors in UI testing?

In frontend applications, we implement components that users interact with. These components are accessible - either by their text, input placeholder, role or by non-visible screen-reader aria-* attributes, falling back to data-testid. These identifiers, selectors (or locators, as some libraries call them), are used by testing libraries, such as Testing Library, Playwright or Cypress to conduct automated tests, which simulate user flows.

Whenever a text, label, or whatever is used to identify the testing component is changed, the tests break. You may think this is a rare problem, but it can happen in some situations:

If the frontend is using a design system and it’s moving to another one, this will likely break selectors. This will happen a lot during migrations.
If the text is changed and sometimes its position, this will likely break as well.
Any HTML change can break the selector.

What are smoke tests?

Smoke tests are a small set of end-to-end tests that cover only the most critical flows of an application. The idea is not to test everything, but to quickly answer one question: is the app still working? Because they are fewer and faster than the full suite, they are cheaper to run on every feature branch - and for this experiment, that also meant fewer (and less flaky) failures for the agent to deal with. If you want to go deeper, this article is a good starting point.

Constraints

This use case is not a one-size-fits-all solution, but it can give you some ideas. We had this specific setup:

Two separate codebases: some projects keep the frontend and test automation suite in the same codebase. This is not the case for our project - there is one repository for the frontend and another for test automation.
FE can’t be built locally in TA CI: this means that the TA pipeline can’t test on the same conditions as FE does. FE runs on a local build and triggers smoke tests there. On the other hand, TA can’t - it can only run against some deployed QA environments. Bottom line: because of this, the same tests that fail in the FE pipeline can pass in TA (and vice-versa). This is why one of the agent's outcomes is Not reproduced (more on that below).
Different CI/CD tools per repository: FE runs its CI pipeline in Drone and its CD (deployments) in GitHub Actions (GA). TA only has a CI pipeline in Drone - it doesn't deploy anything, just some reports, which are managed by Drone as well.

Proposed Solution

The overall idea is that whenever there is a change in FE, the CI pipeline runs smoke tests, and if they fail, it would trigger a workflow agent in TA by sending a repository_dispatch event to the TA repo (through the GitHub REST API), which starts a GitHub Actions workflow there. This agent would then try to fix the non-passing tests. If it is successful, it would create a PR for a human to check. If this PR was merged, then the FE CI pipeline would pass.

Some notes to consider here:

When TA PR is merged, FE CI is not triggered automatically. A user has to re-trigger the job in Drone. This could be tightened in the future, by adding another task to do it when the branch is merged to main in TA.
Also when TA PR is merged to main, it will cause FE main and other branches to fail the tests (because they would not up-to-date yet with the feature branch). This is a known trade-off, which is acceptable, considering we are speeding up the process, at the same time controlling the flow (because a human will need to push the button to merge TA PR into main).

After coming to this high-level design (after a lot of back and forth), I started to think about the details.

Designing the automation flow

To implement this, some questions had to be answered:

Timing: FE can trigger the agent every time tests fail, but should it?
Platform: Where should the agentic workflow run - Drone or GitHub Actions?
Cross-repo/CI communication: How would the connection between FE and TA repositories happen?
Outcomes: What happens if the agent can’t fix the test? What if it can? What if it can’t reproduce (tests pass)?

Timing: when should the agent run?

Considering that every feature branch in FE triggers a CI pipeline and because of cost-efficiency and having more control, especially during the testing of this automation, I chose to trigger the agent under certain conditions. The feature branch changes would need to be deployed into a specific environment (we have more than 4 environments set up, so we can test multiple feature branches at the same time). Let’s call this environment the QA Env.

Having this environment is also needed because of the constraint that TA can only run smoke tests against deployed environments.

Platform: where should the agent run?

There are multiple steps of the automation design, and one of them is to decide where to trigger the agentic flow. As mentioned in the Constraints, we were using both Drone and GA.

Our Drone was becoming crowded already - it was running processes on all branches, including main. And I realised that with GA we would have more control on when and how to trigger - their interface was more friendly for testing and manual triggering. Also, I could create a separated flow only for the agent, not mixing with other processes.

For those reasons, I decided to go with GA for the agentic workflow, therefore the point of connection should be GA for triggering the agent.

Connecting the dots: how do the repositories communicate?

The initiator of this automation is FE when two conditions are met: smoke tests fail AND it is deployed to QA Env. Since FE CI runs in Drone and FE CD runs in GA, these two conditions are checked in different places. I had two options:

Run smoke tests in GA after QA Env deployment, and then send the dispatch event to TA.
In Drone, after smoke tests step, check if QA Env is deployed and then send the dispatch event to TA.

The first option would be more costly - we would need to bring the smoke test step into the GA, and it would duplicate the step in both CI and CD pipelines.

The second option, on the other hand, would be a simple check. That’s because we use GitHub labels to track which environment is being deployed. We already had a flow set up where adding a label to a PR triggers a deployment to that environment.

Given that, we could check the GitHub label right after the Smoke tests step. If both smoke tests failed and the deployment label was set as QA Env, then Drone would send the dispatch event to TA.

Given that CI and CD happen in different environments, one trade-off here is that it is possible that Drone will receive and identify the label, but the GA deployment process can fail, or Drone check can happen before the branch is actually deployed. I accepted these trade-offs, because the worst that could happen is that the tests run against an environment without FE change, triggering a false negative.

For the race condition, as soon as the label is added, usually the CD happens in 5 minutes. The entire CI pipeline usually takes 15 minutes, making it a comfortable pass, since the check would be as the last step of the CI pipeline.

Outcomes: what should the agent report?

The FE created a new feature that broke smoke tests, it was deployed to QA Env, and the dispatch event was sent. Now what? What should the agent do?

The entire goal is for the broken smoke tests to be fixed, by updating the selectors. For that, I took some decisions:

We had more than 40 written smoke tests in total. For the purposes of this automation, we don’t need the entire suite to run. Therefore, there should be a payload carrying the information of which smoke tests have failed in the FE side.
When attempting to fix the test, I see some outcomes, overall:
- The agent is able to fix the test.
- The agent is not able to fix the test.
- The tests pass.

So, with three main outcomes, plus two edge cases we would have:

If tests are fixed, then a PR is created in TA side, and a comment is sent to FE PR with the message of “Already repaired”, along with the link to the TA PR.
If tests were already fixed by a prior run, then a comment is sent to FE PR with the message of “Already repaired”, without a link to a TA PR.
If tests are not fixed, then no PR is created, but a message is sent back to FE PR with the message of “Possible regression”.
If tests pass, then a message is sent back to FE PR with the message of “Not reproduced”.
If there is an environment failure (e.g., QA Env is unreachable), the agent aborts and no message is sent back to FE PR - the error is only logged in the GA run.

Although it is possible to see all the logs in GA workflows page, I wanted to make provide as much up front transparency as possible, by ending the flow in FE PR, with a message on what was the outcome of the entire process.

Then, with most of the definitions set up, we can finally look at how the agent does this, and the harnesses around it, in the next sections.

Setting up the prerequisites

As you will see, there are multiple steps to implement the flow end-to-end.

Creating the agent harness

A harness is everything around the model that shapes how the agent works - instruction files, skills, commands, scripts and guardrails - so it behaves predictably without someone guiding it step by step.

The initial state of the codebase was not ready for AI at all. To avoid increasing the blast radius of the project, I decided to just create enough harnesses to implement this POC. Two assets were created:

AGENTS.md: with CLAUDE.md pointing to it, which enables uses for both Claude and OpenAI models to read. Normal instructions file that is injected to every agent session (not going too deep into this as there's plenty of documentation on the web).
Selector conventions skill: defines the guidelines on how to choose the selector. There is a hierarchy the agent has to follow. For example, the first attempt should be with getByRole, then by getByLabel and so on.

With those, I tested how it performed using my own agent (local Claude Code CLI).

Other commands were created too, but they belong to the automation per se, so they will be specified in the following sections.

Making tests environment-agnostic

Another problem was that the tests were not able to run against QA Env. Data was coupled into a specific environment, as well as some selectors. This isn’t related to AI nor to automation, but it would impact the ability to develop it. Therefore, I had an additional prep work: creating functions that would setup/create and teardown/delete data for every test run and making selectors environment agnostic.

Implementing the flow

A visual diagram of the entire flow is shown below:

Frontend: dispatching the event

As the flow starts in FE, naturally I had to start there, but the work was slim: I’ve added a new step in drone.yml, after the Smoke test step:

- name: Smoke test
  commands:
# Smoke tests instructions

- name: Dispatch selector repair
  environment:
    GITHUB_APP_TOKEN:
      from_secret: GITHUB_APP_TOKEN
    REPAIR_ENVIRONMENTS: QA_Env
  commands:
    - sh ci/drone/dispatch-selector-repair.sh
  depends_on:
    - Smoke test
  when:
    status:
      - failure

(Note: this is an example piece of code and should not be used as it will not work).

As variables, a GitHub App token was needed to enable cross-repository communication and the REPAIR_ENVIRONMENTS is a mirror list of which environments are enabled. For now, only QA Env is enabled to trigger this automation.

I could add all the instructions in the YAML file, but I had extracted them into ci/drone/dispatch-selector-repair.sh to separate concerns and improve readability. In this script, a few things were done:

Check if deployed environment is valid
Check if GitHub token is valid
Collect the failed tests. Exit if no JSON report of failed tests is found.
Fetch commit SHA, PR id number
Prepare payload and dispatch frontend-smoke-failed event

Then, TA would receive this event and payload n its end.

Test Automation: running the agent

To receive the event, a GA workflow was created. selector-repair.yml is triggered when the event is received:

repository_dispatch:
  types: [frontend-smoke-failed]

It can also be trigger manually, although this was mostly enabled for testing purposes, when evaluating the performance of the agent.

This workflow:

Runs deterministic checks before calling the agent: validates the payload from the dispatcher (environment, FE PR, SHA and failed specs) with regex and against injection, checks API keys, re-checks the deployed environment and confirms portal access. Failing early here avoids unnecessary agent calls and adds a security layer.
If everything’s ok, then installs OpenAI Codex CLI, for headless agent. The chosen model was GPT-5.4. The goal is for the harness be good enough that we don’t need more capable/high reasoning (and more expensive) models, such as Opus and Astra.
Triggers the agent to run repair, by using codex exec command, which runs the Repair selector command (described below, officially called repair-selectors-ci)
Outputs repair summary and uploads evidence (HTML files and images)
Comments back in FE PR

As you can see, the LLM is only involved in in one specific step. Before and after, deterministic scripts were written, both to reduce AI costs and improve quality. The agent is only triggered if it can actually run the tests in an enabled environment; and after the agent finishes, a script puts together the message body for the PR comment back to FE.

The Repair selector command

On top of the shared harness from the setup section, the CI run adds two commands. Namely:

Repair selector command: the command that is triggered by automation itself.
Open repair PR command: a separate command that is triggered inside the Repair selector command.

The Repair selector command is where the core agent logic lives. In summary, it does:

1. Reads inputs from environment variables: which environment to test, which FE PR triggered the run, and a list of failed specs.

2. Manages a persistent branch: one branch per frontend PR, reused and appended to across multiple runs rather than recreated each time, as each commit in the same branch triggers a new run. It never rebases or force-pushes, since the commit history works as an audit log. Also, if there is a new commit from FE side, GA cancels the current run via concurrency: cancel-in-progress, so it doesn’t keep working on outdated code. If the commit was already pushed, it stays there.

3. Determines what to test: either the specific failing specs or runs the whole smoke suite itself, in case of a manual run. If a previous repair run already committed a fix for it on the persistent branch, it's categorized as “Already repaired”.

4. Triages each failure into one of three buckets:

Rot - the element is still there, just addressed differently (changed role/name/DOM position) → safe to auto-fix.
Regression — the element is missing or the underlying data is wrong → escalate to a human, reported as Possible regression.
Environment failure — the portal itself was unreachable/broken, so failures aren't meaningful at all → abort triage entirely rather than misreporting every spec as broken. Nothing is sent back to FE; the error is only logged in the GA run.

5. Repairs rot-classified selectors by probing the live page for accessible signals (role, label, text, placeholder, etc.), picking the most precise selector that resolves to exactly one element, and verifying the fix actually turns the test green before keeping it.

6. Runs quality gates — lint/prettier checks, cleanup of any scratch/probe files — before allowing anything to be committed.

7. Opens or updates a draft PR (never merges) - this is the Open repair PR command.

8. Writes a structured JSON summary (repair-summary.json) as its only communication channel back to the calling workflow — listing what was fixed, what was escalated as a regression, what couldn't be reproduced, what a prior run already fixed, and any environment error — with strict rules about which fields must stay empty in which scenarios, so the human-facing report is never misleading.

After that, the payload is sent back to selector-repair.yml to be picked up by the last step of "Comment back on FE PR". This is a deterministic code that executes the feedback to the FE repository as we already discussed in "Outcomes: what should the agent report?" section.

Conclusion

Before this experiment, a single breaking UI change meant skipping tests, merging with gaps in coverage, and coordinating at least four engineers across two teams. With this flow, FE gets feedback directly in its PR, TA reviews a draft fix instead of writing it from scratch, and, when the agent is successful, tests no longer need to sit skipped on main.

The biggest lesson for me was that the agent was the smallest part of the work. Most of the effort went into the pieces around it: deciding when it should run, connecting two repositories and two CI tools, making the tests run against a shared environment, and writing deterministic checks so the LLM is only called when it can actually help.

There's still room to improve and I believe this can serve as a case study for autonomous systems that go beyond using AI in local development. The future is agents working in the cloud without a human driving each step - and for that, we need solid harnesses and guardrails, and to keep observing their output to improve quality, reduce costs and speed things up.

Building resilient large-scale applications

Mellina Yonashiro — Mon, 20 Apr 2026 13:34:39 +0000

The principles for writing software are the same, but the development process itself is quite different when doing it for small versus large applications. Reading, fixing, and building on a small codebase is easier and more forgiving than in large ones. I have worked on applications from small clients, greenfield applications as well as large-scale ones, serving thousands of users. The difference is that, when there is already a fully operational machine running, mistakes are more costly and downtimes harder to recover from. Therefore, processes, guardrails and constant alignment become part of everyday development.

Most of the concepts I cover here are applicable to any part of web development, but as a frontend engineer, my focus and examples will stay in that domain, especially in the modularization topic.

Stating the challenge: multiple people involved on a very large codebase

Having a disorganized codebase is a problem in itself, but the problem multiplies when there are dozens of people working on the same project, which is often the case for large-scale applications. It can be developers from the same team, engineers from other teams, external contributors, or cross-functional staff engineers. Without some level of coordination, the following problems tend to emerge:

Problem	Description	Strategy
Regression	A team ships a feature or refactors code that unknowingly breaks another team's work	Unit tests for logic, integration tests for module contracts, and E2E for critical user journeys, all enforced in CI
Code duplication	Similar features are implemented independently across teams, leading to diverging logic	Shared modules for common components, hooks, and utilities
Inconsistency	Standards around formatting, code style, and tooling are not enforced uniformly	CI guardrails: linters, formatters, shared tsconfig, path alias enforcement
Unintended Changes	A developer modifies another team's module without awareness, causing unintended behaviour changes	CODEOWNERS and enforce review from the owning team on every change (and a responsive review process)
Obscurity	Onboarding, patterns, and code conventions are unclear or scattered across different places	Central documentation covering setup, architecture decisions, and code style
Staging overwrite	A branch deployment to staging silently overrides another team's active deployment	Per-branch preview environments instead of a shared staging instance

This is by no means an exhaustive list of all of the challenges of working on a large-scale application. These are some of the most common issues I personally have come across over the years, and some strategies that have worked. But, of course, as we know, everything in software development is a trade-off, so no solution is a 100% fit for every case.

That said, I’ll discuss the issues and strategies on how to solve them in three groups: modularization, documentation, CI guardrails and CD practices.

Modularization

In “A Philosophy of Software Design”, Ousterhout calls two ways of programming: strategic and tactical. Simply put, tactical programming focuses on developing features and fixing bugs, and strategic focuses on protecting the “long-term structure of the system”. These two ways of getting things done are widely used in the industry, but the author advocates that, although slower in the beginning, the strategic way of programming pays off, as tactical programming accumulates debt that slows teams down over the long term.

Applying good and well-thought architecture is one of the principles of strategic programming, and one of the areas I chose to focus on is modularization.

What seems like a straightforward matter of developing features becomes hard when dozens of engineers and multiple teams are all committing to the same repository. Without proper coordination, this can cause issues such as code duplication, feature overwrite, tightly coupled modules, and regressions with each change.

What's worth clarifying is that modules in frontend look different from those in backend development. Usually, everything related to the application is in a single codebase, as it needs to be bundled, compiled and run in the client. Libraries are loaded and bundled, and communication between modules happens via shared state, props, or event patterns at runtime. Common architecture choices such as layered, microservice, MVC are adapted to the frontend.

Our modules - not to be confused with UI components - are units of business logic, each grouping all the code that belongs to a single domain concern. Clear module boundaries matter.

Modularization is the process of organizing your codebase into loosely coupled, self-contained pieces of code. Total independence between them is impossible, so the goal is to keep dependencies explicit and minimal. It is worth noting that the word 'module' is overused in JavaScript - ES modules, npm packages, and CommonJS modules all use the same term. Here, I use it to mean a domain-ownership unit.

To understand how we apply it in frontend, let’s take an example.

Consider this folder structure (modules by feature):

src/
  features/
    checkout/
      components/
      hooks/
      utils/
      types/
      constants/
      index.ts
    search/
      components/
      hooks/
      utils/
      types/
      index.ts
  shared/
    components/
    hooks/
    utils/

And this one (modules by type):

src/
    components/
        checkout/
      search/
      shared/
  hooks/
      checkout/
      search/
      shared/
  utils/
        checkout/
      search/
      shared/
  types/
      checkout/
      search/
  constants/
      checkout/
      search/

Although they look similar, the first makes the separation of responsibilities explicit in the file system (Modules by Feature). If team A owns the Checkout flow, and team B owns the Search, they know which folder they can change and which folders require coordination with other teams. The second structure also allows for that (Modules by Type), but feature-specific code is scattered across the codebase, which leads to more mistakes and slower cleanups.

The diagram below illustrates the difference in how code is organized under each approach.

In Modules by Type, when a codebase grows to cover ten or twenty features, the components/ folder might contain hundreds of files. Some of those components belong to the checkout flow, some to the search experience, and some are shared across features. Finding everything related to a single feature requires jumping between components/, hooks/, utils/, and types/ and knowing which files in each folder belong to which feature.

In Modules by Feature, by contrast, finding everything related to checkout means opening one folder. Deleting a feature means deleting one folder. With this structure, it is also possible to set up CODEOWNERS, which is important when there are multiple teams working in the same codebase. Whenever team A changes a piece of code under team B’s responsibility, they will be notified and required to be a reviewer of a PR, and will be prevented from merging (provided that branch protection rules are configured to require code owner approval).

On top of that, code duplication can be avoided by using Shared Modules (utilities, components, or anything that might be useful for the entire system). But discovery is the hard part - which is why clear module ownership and documentation also matter here. That's where documentation becomes the connective tissue that makes modular structure legible at scale.

Documentation

Everybody says we need good documentation, but the stakes are higher when there are hundreds of people looking at your code. In a large company, documentation is necessary. This decentralizes knowledge, enables async work, and reduces information silos.

Overall, the benefits it can bring are:

Faster onboarding: make newcomers more autonomous when running your project
Consistency: keeping patterns, code conventions, and architecture decisions documented for future reference
Centralization of information: everything related to the project, Confluence pages, observability links, localization documents, etc., can be in the repository for easy access.
AI-readiness: in addition to the “classic” benefits, agents can read through documents to implement features that comply with guidelines.

Documentation is, admittedly, tedious to write and tends to go stale quickly. For that reason, some advocate for less documentation, especially if the same intent can be expressed through the code itself. Code should speak for itself through clear naming and structure. There are, however, things that code cannot document: processes like onboarding, releases, and deployments, or decisions that need to be more visible than what lives inside the codebase.

Keeping documentation alive is a collaborative task. There is no single responsible person: every team member needs to be proactive about keeping it current. When I start at a new company, I write down everything I need to get the project running - API keys, third-party access, software to install - and use it to update the onboarding documentation if it's outdated (and it usually is). I revisit it every time I help someone else get set up.

As AI tools mature, documentation becomes a two-way investment: repository-level documentation gives coding agents the context they need, and AI-powered tools will be able to speed up the documentation update process, like via Atlassian Automation or a GitHub Actions webhook.

CI guardrails and CD practices

Modules give structure, and documentation makes that structure legible, but neither survives at scale without enforcement.

Verbal agreements matter, but automated enforcement is what actually keeps things consistent. Agreements made in conversation don't stick - people forget. The volume is too high and context switches too frequent for people to reliably catch everything: commit message conventions, PR descriptions, test coverage thresholds, review processes, and so on. Because of that, we have several tools to automate this process, and we apply them by creating CI guardrails.

For example, before a PR can merge to main, we can add a check that enforces a minimum overall coverage threshold, and a d*iff coverage* check to ensure newly introduced code is covered too. We can also run linter checks - which catch potential bugs and enforce patterns - and formatter checks for consistent code style. If those checks don’t pass, the change is not integrated into the main code. This ensures that every change meets a defined quality baseline.

With these automated checks, human review is no longer needed for mechanical steps - which is important at scale, where manual gatekeeping becomes a bottleneck. Instead of having to check formatting or whether it has enough tests, engineers can focus on business logic implementation and architectural decisions.

After passing all the checks, it’s time to deploy to a staging environment. It shouldn’t be a problem to deploy to staging - or so it seems. In practice, when multiple teams are testing different features simultaneously, a single shared environment becomes a source of constant conflict.

For that reason, when it comes to the CD part of the process, it is crucial to have multiple staging environments. What usually happens is a per-branch preview: you can deploy your branch, and it creates a unique URL. No shared staging instance means no overwrite, no "who deployed what" confusion, and no blocked QA because two teams need to test at the same time.

Conclusion

The practices covered here - modularization, documentation, and automated enforcement - are what make a large codebase workable in the long run.

That said, the investment goes beyond tooling and processes. Large companies dedicate entire roles to it: platform engineers who ensure others can ship faster, and system architects who oversee architecture across domains. Beyond roles, there are dedicated processes - like writing and approving RFCs - to govern changes that affect multiple teams.

The investment is ongoing and never fully finished. But the alternative, like teams stepping on each other, knowledge locked in people's heads, regressions shipping, costs far more.

My AI Workflow as a Frontend Engineer

Mellina Yonashiro — Fri, 27 Mar 2026 10:56:24 +0000

I decided to compile and share all the ways I currently use AI for software development, because for some time, it was confusing to me how people were actually using it. I wouldn’t say there is a correct or more effective way to do it, as I also believe there is not a single way to do software engineering (there’s always the trade-off conversation when discussing engineering strategies). But feel free to take some ideas from here.

So, in this article, I will write about the ways I use AI chatbots, agents, and other tools for my work and personal/hobby coding projects. For some more context on what I currently use - Claude code in the command line, Claude chatbot (with some integrations, such as Github and Notion), and some Gemini models in Roo Code (VS Code extension). I will be focusing on how I use them for engineering work, not so much for my personal life. Also, I will not discuss how companies may be implementing in their workflows.

Investigation & Debugging

Reading and parsing error messages from logs
Debugging frontend runtime errors via console log

It was common practice for me to (try to) read the error message to identify where and why it occurred. If I didn’t understand, I’d paste the text in a search engine and dive deep into StackOverflow. Now, I paste the logs into a chat to speed up the research and solution process. This is especially valuable when the logs are long and hard for a human to read.

The frontend debugging workflow works quite differently. Components break at runtime - for example, a state is not passed down correctly. It’s hard to catch in development, because the issue happens when interacting in the browser, when the code is already compiled and running. Then, when this happens, the agent, acting more like a coding partner, asks me to add (or have it add) console.log() calls in strategic places in the code, and it asks me what the dev tools console prints. It will then get more information and eventually understand where the problem is. This will proceed iteratively until we reach a solution.

Codebase Understanding & Quality

Looking for inconsistencies in the codebase
Writing unit tests and mocks
Comparing changes with the main branch to catch regressions

Inconsistencies in a codebase are easy to miss and hard to prioritize. Using agentic coding that has access to the project makes it easy to find and make it more consistent. Most of the time, I don’t want it to act right away, as the codebase is huge - it can help with creating a plan, though. I make it read the project code, assess the opportunities to improve, and ask for a planning document. It’s important to keep patterns, naming conventions, and architecture consistent, for both bots and humans.

Writing unit tests is a must, but a time-consuming task - especially writing mocks. In the frontend, we also have a hard time finding the right selector (finding a reference to a DOM element), as design systems create complex HTML structures for rendering components. It works wonderfully for those. AI can even completely write the test by scanning the function or component.

Additionally to assisting with unit tests, I can compare my changes with the main branch, and have it check if there is something I wrote that can affect another part of the codebase (cause regression), or if it’s not consistent (as in code style or patterns).

Active Development

Performing migrations and package upgrades
Dealing with breaking changes
Developing new features based on the current architecture
Jira ticket descriptions to pull/merge requests

Usually, projects have many dependencies, and these dependencies release updates very often. Dependabot (in GitHub), which has existed for a while now, already helped with minor package updates. Now, agentic code can help to deal with major upgrades and breaking changes. It can handle tedious tasks such as renaming parameters or replacing logic that has become obsolete.

Moreover, one of the most powerful tools is to create new product features. It can take a feature description (or Jira ticket description) and implement it. Of course, agentic coding is better if your codebase is prepared for automation - if you’ve written proper documentation, context, and if it uses consistent patterns, architecture, and coding style. Plus, your instructions are clear (specifying which files to change, with example files).

Documentation & Communication

Writing codebase documentation
Creating Jira tickets

AI is great at reading large chunks of data and summarizing. With that, I make it read the entire codebase and create documentation, separating by subject, such as security, observability, and accessibility. These are important to inform developers on which practices and patterns we are currently using, or where configurations are. There are also links to external resources if necessary, which may also be accessed by the agent.

On a different direction, I use it to write comprehensive Jira tickets and PR descriptions for others to read. I usually have no problem writing them, but there are days when I’m just mentally tired. When this happens, I write some notes in draft format and ask AI to formulate a readable piece of text for humans (and machines) to understand.

Planning & Review

Code reviews (GitHub-integrated)
Brainstorming and looking for improvements

Having AI act as an additional reviewer, integrated into GitHub, for example, doesn't replace human review, but it catches things: inconsistencies, edge cases, logic that's technically correct but fragile, and not used parameters. Sometimes it is not correct, but most of the times it at least gives you some food for thought. What’s interesting in this interaction is that sometimes one model writes the feature code and another reviews it (for example, Claude writes the code, and Gemini reviews it). I’m looking forward to a future where I read some epic interaction between robots on what approach is the best to take.

Brainstorming sessions are looser but useful. Sometimes you don't need a solution; you need to learn the pros and cons of it. For example, would it make sense to change from Yarn to Bun? What are the trade-offs in this case? Or, how could a certain for loop be more performative? These are real questions I have already asked (with more details, of course).

Experimentation

Me as a human learning new stuff
Vibe coding (hobby projects)
Agent development

People are using AI for many different things, and I am also doing some experimentation myself. I have been using it to keep me up to date on the latest technologies - frontend is a subject that is constantly transforming, and it is historically hard to keep up. At the same time that good practices are mostly the same, there are new tools everywhere - state management libraries, observability systems, frameworks that challenge the status quo.

Also, there are some hobby projects I want to implement, but they are not my field of expertise. For those, I use the (in)famous vibe coding to implement projects from scratch. I’m pretty impressed by the outcome: using Python, we developed a web scraper while customizing it for my own needs.

Lastly, I’m in the stage where I’m experimenting with implementing an agent myself. I’m still unsure in which direction I will take this, but I’m planning on something basic at first, just to understand the implementation process: token usage, integration, and how to connect to existing MCPs.

What I've Learned

Information about how to use AI is all over the place, but overall, what I understood is that written communication is very important when prompting. I’ve always liked to write. I wrote journals, stories, on paper, on my computer, or on a notepad in my smartphone while on the tram. I don’t consider myself a writer, but I like doing it as a hobby. Because of that, I feel it is easier to write prompts and direct AI on what I want it to output. I can be direct when I want something specific, and I start a conversation with open questions when I want to do creative tasks. If you are good at communication or have some background knowledge on how these models work, you will most likely get better outcomes.

Project Management for Engineers

Mellina Yonashiro — Thu, 12 Mar 2026 12:03:40 +0000

Project management is a diverse and complex topic, and each company handles it differently. To achieve better results, companies usually build a multi-skilled team with engineers, managers, product owners, and QA testers. With so many people, what is the actual role of software engineers in project management, then? How much involvement should non-technical and technical people have in each other's areas of influence? These are questions without a universal answer — but patterns do emerge, especially as AI tools make the line between "who decides what to build" and "who builds it" increasingly thin.

This is my take on that, based on real experience across very different environments.

Some foundation - What I understand as Project Management?

Project management is the practice of planning, organizing, and guiding work toward a specific goal, within constraints like time, budget, and scope. It's not just about Gantt charts and status updates, but making sure the right people are working on the right things at the right time, and that everyone actually knows what "done" looks like.

Today, engineers are expected to participate in planning and project management, by estimate their own work, flag risks early, communicate progress, and sometimes even define the scope of what they're building.

The Competencies: Where Engineers and Project Managers Overlap

A project manager's core competencies typically include things like stakeholder communication, risk assessment, timeline planning, resource allocation, and scope management. A software engineer's core competencies include system design, implementation, debugging, code review, and technical decision-making.

These seems like two distinct skill sets, but they are closer at some strategic points, and that intersection is where the most effective engineers tend to live.

Estimation is one obvious overlap. Engineers estimate technical complexity and project managers translate that into timelines and resource plans. But a good engineer doesn't just throw numbers to story points: they understand why the timeline matters, what business decision depends on it, and how to communicate uncertainty in a way that actually helps the team plan.
Dependency mapping is another. Knowing that your feature depends on a backend endpoint, a design decision, and a third-party API approval isn't just project management, it's engineering survival. Engineers who think in terms of dependencies and unblock themselves proactively are invaluable.
Communication might be the biggest one. Writing clear tickets, giving useful status updates, and knowing when to escalate a risk. These feel "soft," but they have very real consequences on project outcomes.

The intersection, in short, is ownership thinking: the ability to care about the outcome of your work, not just the output.

My Experience: What Different Companies Actually Expect From You

I've worked across very different contexts, big tech companies, consultancies, and open-source projects. What "project management for engineers" means is different in each.

Big Company: Coordination as a Full-Time Sport

In a large organization, the sheer number of moving parts means that getting anything done requires a surprising amount of coordination. Cross-team alignment, stakeholder approvals, dependency tracking, and navigating the tension between what engineering wants to build, between technical excellence and controlling tech debt, and what the roadmap says.

In this environment, I worked closely with designers and product managers to figure out what could realistically be delivered and in what timeline. My job wasn't just to build, but also to make sure what I was building actually landed inside the system within the established procedures.

This taught me a lot about bureaucracy as a communication problem. All that process exists because people need to stay aligned across a large, complex organization. The engineers who thrive learn to work with the process - and occasionally, strategically, to work around it.

Consultancy: Being the Bridge

Consulting is a different world entirely. The diversity of projects means you're constantly context-switching between different clients, tech stacks, and team cultures. But there's a common thread: you are always, in some way, the translator.

In my time at a consultancy, the teams were large, the clients had their own ways of working, and the gap between "what the client asked for" and "what we understood them to ask for" was a constant source of risk. My role shifted toward being the bridge between our technical team and the client's expectations in some projects. That meant coordinating with my team on priorities, and constantly calibrating based on what signals were coming from the client side.

What this context taught me, specifically, was how to read silence. Clients rarely tell you directly when something is off. You learn to catch it in how they phrase feedback, what they don't ask about, and when enthusiasm drops. That's a skill that doesn't show up in any job description, but it shapes how I communicate to this day.

Open Source: Full Ownership, Minimal Structure

Working in open source is, in many ways, the purest form of engineering ownership I've experienced. There's no product manager telling you what to prioritize.

In practice, this meant taking full ownership over what to build and how to build it, of course, within the broader directives of the project, but with significant autonomy. I decided what was most important based on my own findings when I talked to users. I shaped the roadmap, communicated it, and executed it. The bureaucratic overhead was almost nonexistent, and the trust was remarkably high.

My Personal Flavor: Design and User-Centered Perspective

Most of what I developed came from being thrown into situations where it was needed, and from someone seeing something in me that I hadn't fully articulated for myself at those times.

Looking back, what seems to resonate with the people I've worked with is a combination of things rooted in my background: I came into engineering with a design background and have always been user-oriented. Those two things shape how I approach technical problems: I think in terms of how things will be experienced, not just how they'll be implemented.

One specific habit that keeps coming up: I like to create visual elements — boards, diagrams, maps — as a way to make sense of complex projects. I do this first for myself, to understand the shape of what I'm working on, but then I use those visuals when presenting to non-technical stakeholders. The goal is to give people an entry point into the technical conversation.

I also bring a certain orientation toward education into how I communicate. I try to translate technical concepts without dumbing them down, which is a harder balance than it sounds. The goal is always to make the other person feel more informed and more capable, not more confused or dependent. That usually involves meeting people where they are, using analogies that fit their world, and then carefully building toward the technical layer.

And maybe most importantly: I genuinely care about relationships. I want to know the people I'm working with, I want to talk to users. I want to understand who I'm building for, not just what I'm building. That sounds soft, but it has very practical consequences. When you understand who your users are, your technical decisions get sharper. You know what's worth over-engineering and what isn't. You know what "good enough" actually means.

Conclusion: It's Not a Separate Skill Set - It's an Extension

If there's one thing I'd want you to take away from this, it's that project management isn't something you need to become a different kind of person to do. It's an extension of the curiosity and care you already bring to your technical work, just pointed outward, toward the team, the stakeholders, and the users.

Different companies will need different things from you. But the underlying thread is the same: take ownership, communicate clearly and early, and care about the outcome, not just the output.