DEV Community: Mellina Yonashiro

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.