Facing AI Coding Agents

I work as a front-end engineer at Manufacturing BT. I mainly handle web applications, but I'm the type of engineer who will also do back-end and mobile work if asked.
Now, my sense of dates and memory are about as thin as canned coffee, so I'm fuzzy on the exact timing, but I believe it was around spring of last year when my department manager brought up the topic of "Can we build web applications with AI coding agents?" My answer at the time was, "It's usable if you limit it to logic like Hooks."

One year later. Now in spring 2026, just by passing a GitHub Issues URL, it handles everything from implementation to PR creation and screen testing. And this isn't something that just started recently — my sense is that it's been this way for a bit longer than that.

In the midst of all this, I feel like I've been getting along with it reasonably well in my own way, but leaving it at "reasonably well" doesn't sit right with me. So in this article, I'd like to try putting my own approach to AI coding agents into words for once.

Let existing code speak rather than convention documents

Convention documents have their limits. As rules grow bloated, contradictions arise, and to resolve them, exception clauses like "only in case A, use X" start piling up. Naturally, the maintenance cost of those rules goes up too.
It would be fine if someone could maintain them exclusively, but given the nature of Manufacturing BT projects, front-end work often runs with a small team. Spending cost there honestly doesn't feel worth it to me.
In the first place, I believe the ideal state is being able to read code, grasp the intent, and write similar code. AI coding agents also write the next piece of code while reading the surrounding code. So rather than adding more rules, my current stance is to lean toward keeping the code itself that gets referenced in good shape.

With this approach, in the early stages you inevitably end up writing a lot of the code by hand. You can shortcut the setup by referencing past repositories, but... well, the effort you put in upfront comes back to you in how easy it is to review and revise once things get moving — that's my experience.

On top of that, I combine a few skills. I use skills to supplement the parts where just having it read the codebase isn't enough to get it writing in the same style.

npx skills add baseline-ui
npx skills add fixing-accessibility
npx skills add fixing-metadata
npx skills add fixing-motion-performance

baseline-ui

This is a skill that constrains the "parts that tend to get sloppy when left to AI" around the UI. It covers everything from stack choices — like not straying from Tailwind CSS default scales, using motion/react for animations, and using tw-animate-css for entrance and fine-grained motion — down to detecting anti-patterns in typography scales and layouts. I introduced it to prevent the "it works but smells like AI" problem. I also have my own weaknesses in design, so another purpose is to bring things up to a level where they can be introduced as-is at high quality even when something working is all that's needed.

fixing-accessibility

This is a skill that bundles auditing and fixes for HTML accessibility. It covers ARIA labels, keyboard navigation, focus management, contrast ratios, form error display, and more.

fixing-metadata

This skill handles page metadata in general. It covers titles, descriptions, canonicals, Open Graph, Twitter Cards, favicons, JSON-LD structured data, and robots.

fixing-motion-performance

This skill handles animation performance issues. It detects layout thrashing, transitions to non-compositor properties, scroll-linked animations, the cost of blur effects, and more. While baseline-ui constrains the "choice" of animation, this one is for checking the "heaviness" after implementation — that's how I divide them when using both.

Keep related code close together

I'm borrowing just the design philosophy of the features directory from Bulletproof React.

https://github.com/alan2207/bulletproof-react

Rather than grouping components, hooks, and utils used on each page by type and managing them centrally, the structure cuts directories by feature unit called features/xxx, with features/xxx/components and features/xxx/hooks placed underneath.

This way, the scope you need to look at during review is narrowed down to under that feature's directory, making it much easier to follow. I think this is the strength of co-location.
Even in an age where AI writes code, there will never be a point where humans stop reading code. Front-end in particular traces processing starting from what's happening on screen — "page → component → some kind of logic" — so having the directories you need to look at narrowed along that path still really makes a difference.

Cut issues at a granularity that's reviewable

Until now, when moving from an issue to creating a PR, if someone felt "this change might get a bit large," a human would work through it and split the PR in a sensible way. Since you're writing by hand, splitting happens somewhat naturally.

But AI coding agents can write large amounts of code without difficulty and bundle it all into a single PR. While convenient, this tends to create a painful situation for reviewers. If you're handed a 500-line diff PR and told "please review this nicely," human concentration has its limits.

In that case, the timing for splitting PRs moves one step earlier — to the stage of cutting issues. "Create issues in units that a person can review" is my current approach.

My rough sense of granularity — I try to cut issues around here:

• Does the diff fit within roughly ±300 lines?
• Is the layer being touched not spreading too wide? (Issues that move the screen, API, and schema all at once should be separated)
• Does the acceptance criteria not exceed 5 bullet points? (If it does, that's a sign the scope is ballooning)

Anything that doesn't fit within this gets split into issues with dependencies written out, then worked through in order.

As a side effect, cutting issues finely also makes the context passed to the AI clearer. The smaller and more clearly defined "what to change," "what's in scope," and "what's out of scope" are, the more the agent can stay away from unnecessary files with confidence.

Review and testing are human work

To add some nuance — I mean this as "the remaining human work done with AI assistance."
Checking code quality from an engineer's perspective, verifying behavior while having AI generate test data and test code — these tasks can be progressed in collaboration with AI. Even so, looking at the actual screen and deciding "this is good" is something only a human can ultimately do. Because AI agents don't have eyes.

I think the front-end of web applications is a domain where this "eyes" factor is especially important. It's not uncommon for small changes to markup or CSS to show up as large visual differences on screen. It happens regularly that something is only a few lines in the diff, but when you open it, it looks like a completely different page.
Actually, for a period I was considering an operation where passing automated review would automatically trigger a merge, but I held off for the reasons above. Since there are breakages you only notice by looking at the screen even when the code is fine, I concluded it was too risky to remove the final check from human eyes.

On the other hand, automatically assigning Copilot as a reviewer when a PR is created is working really well as a first-pass filter for reviews. Obvious oversights get caught before a human even starts reviewing, making it easier to focus on the final check. I'd definitely recommend this.

I touched on "the possibility of black boxes forming" in the introduction, but in the end, preventing that comes down to nothing more than the unglamorous accumulation of actually opening the generated PR, actually running it, and actually reading it. Since the time AI spends writing code has gotten shorter, it might even be worth spending more time on review and testing.

Finally

Writing this out, I'm reminded once again that getting along with AI coding agents ultimately comes down to the steady work of cultivating "a codebase that's easy for AI to read and easy for people to review."
This is my approach as of spring 2026, so I have a feeling the premises may change in half a year. I'd love to hear how others who are also working with AI on the front-end are approaching it.