DEV Community: Mellina Yonashiro

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.