My daily development machine is a 2021 MacBook Pro with an M1 Max—a 10-core CPU and 32-core GPU.[1] Four chip generations later, Apple's M5 Max offers an 18-core CPU and up to a 40-core GPU.[2]
My machine is no longer Apple's newest performance showcase. I also keep it in Low Power Mode while designing, coding, testing, and running Misaki Studio.
On that machine, with Low Power Mode enabled, Misaki Studio holds 120 frames per second during active interaction.
Apple describes ProMotion on Apple-silicon MacBook Pro models as an adaptive refresh rate that can reach 120 Hz.[3] The display is not locked to that rate every moment, nor should it be. It can adapt when the full refresh rate is not needed. The performance claim here is about active interaction: when the user moves, selects, drags, or edits, the application is ready to move with them.
That may sound like a story about powerful hardware. It is really a story about software that tries not to waste the power it already has—and about learning how to build that software with AI without surrendering engineering judgment.
Low Power Mode as the normal environment
I do not enable Low Power Mode only when the battery reaches 10 percent. It is my normal working environment. I use it while designing, coding, testing, and running Misaki Studio.
Apple says Low Power Mode reduces energy use to increase battery life and, on supported Macs, can reduce fan noise.[4] For me, it also creates an honest development constraint. Faster hardware can hide unnecessary renders, background activity, and overloaded interaction paths. A smaller power budget makes that waste easier to experience.
I could solve the problem by buying a newer Mac and gaining more headroom. That would make my machine faster. It would not automatically make Misaki Studio more efficient.
Instead, I treated Low Power Mode as part of the product brief: the editor should still feel immediate when the system is being asked to consume less.
AI made iteration faster, not judgment automatic
AI has been a major part of building and optimizing Misaki Studio. It can read broad areas of code, trace relationships, generate alternatives, add instrumentation, and build regression tests much faster than I could do every step manually.
But “built with AI” does not mean “built by accepting every AI answer.”
Sometimes an AI coding agent finds the right path quickly. Sometimes it gets stuck in a loop: it changes the same area repeatedly, trusts a passing test while the live interface is still wrong, or keeps improving a number that is not the real product problem.
Public research shows why it is difficult to reduce AI-assisted development to one productivity number. In a controlled experiment, developers using GitHub Copilot completed a standardized JavaScript HTTP-server task 55.8 percent faster than the control group.[5] In a different randomized study, 16 experienced open-source developers completed 246 real tasks in repositories they knew well. With early-2025 AI tools, they took 19 percent longer—even though they believed the tools had made them faster.[6]
Those results are not actually contradictory. The task, codebase, developer, tool, and feedback loop all matter. METR's later attempt to measure newer tools also encountered selection and time-tracking problems serious enough that the researchers called the central estimate unreliable.[7] Measuring AI's impact inside real work is harder than reading a benchmark score.
That matches my experience. AI can increase the speed of iteration dramatically. Human experience still has to decide whether those iterations are moving toward the right outcome.
The real output is the truth
Performance work creates an attractive trap: the metric starts as evidence and quietly becomes the goal.
A benchmark answers a deliberately narrow question under controlled conditions. A product has to keep the correct pixels on screen, preserve the right behavior, respond to input, and remain stable through a real working session. A benchmark cannot see all of that unless the benchmark has somehow become the entire product.
During Misaki Studio's development, I tested an optimization that looked dramatically faster in isolation. The number improved. The tests looked healthy. The live interface behaved incorrectly.
It did not ship.
That experience gave me a rule I now trust: a benchmark can tell you how quickly the wrong answer arrived. The real output is the truth.
This is not an argument against measurement. It is an argument for putting measurement in the correct order:
Experience the real workflow.
Reproduce the behavior that matters.
Measure enough to locate the work.
Use a focused benchmark to compare possible fixes.
Return to the product and verify the complete output.
If the isolated result and the real application disagree, the application wins.
Performance by doing less
Misaki Studio is an Electron application, so it combines desktop capabilities with a Chromium rendering environment. Electron's own performance guidance is clear that this flexibility puts responsibility on the developer: avoid blocking the main and renderer processes, defer work that is not yet needed, and use workers for sustained CPU-heavy operations.[8]
The performance strategy behind Misaki Studio follows a simple set of public, well-understood ideas.
Render only what is visible
Long lists and complex panels use virtualization, so the interface focuses on the content near the viewport instead of constructing every possible row at once.
Apple demonstrated the same principle in a 2025 Power Profiler session. An app was eagerly creating hundreds or thousands of video cards, including items that were not visible. Replacing that structure with lazy, on-demand rendering made the view responsive and reduced the demonstrated average CPU power-impact value from 21 to 4.3.[9]
Different framework, same lesson: invisible pixels should not compete with the interaction happening now.
Protect the interaction thread
When work can run away from the pointer, keyboard, and canvas, Misaki Studio uses off-main-thread browser capabilities such as Web Workers. This does not make the work free. It prevents analysis from unnecessarily blocking the part of the application that must respond to the user.
Work with the display
Visual updates are synchronized with the browser's animation-frame cycle rather than assuming that every screen and power state runs at one fixed refresh rate. Chromium's rendering pipeline has distinct JavaScript, style, layout, paint, and compositing costs. High-performance rendering comes from avoiding unnecessary stages and keeping required work inside the available frame budget.[10]
This is what makes 120 fps during active interaction meaningful. The goal is not to run a timer 120 times each second and print a large number. The goal is to have the right frame ready when a compatible display can present it.
Return to idle
Unnecessary background activity consumes the same budget needed by the next real interaction. Apple's energy-efficiency guidance recommends eliminating non-user-driven work, avoiding updates to invisible content, minimizing timers, moving long work away from the main thread, and batching tasks where possible.[11]
For a responsive app, idle is not wasted capacity. It is preserved headroom.
The human–AI performance loop
My optimization process usually begins before any profiler opens. I feel a selection hesitate, notice an animation lose its rhythm, or sense that a workflow becomes heavier over time.
That feeling is not proof, but it identifies the experience worth measuring.
I then reproduce the interaction and collect evidence. Once “the app feels slow” becomes a specific event, AI becomes far more useful. I can give the agent a bounded workflow, the observed behavior, the measurement, and the product constraints that must not change.
The working loop looks like this:
Experience — Use the real product and identify the interaction that feels wrong.
Measure — Capture timing, rendering, or scheduling evidence around that interaction.
Direct AI — Ask the agent to investigate a bounded cause, not to “make everything faster.”
Observe — Check whether each iteration changes the evidence and the actual experience.
Interrupt — Stop the agent when it repeats itself or optimizes the wrong proxy.
Code manually — Take over when runtime context or product judgment is missing.
Verify — Run the complete workflow again and judge the real output.
Manual coding is not a failure of AI-assisted development. Knowing when to take over is part of using AI well. Once I uncover the missing fact or correct the direction, AI becomes useful again with better context.
The human supplies taste, continuity, and responsibility. AI supplies breadth and iteration speed. Measurement connects them, but the running product settles the argument.
What Low Power Mode changed
Building this way has made Low Power Mode feel less like a limitation and more like a filter. It exposes work that does not deserve to exist.
The benefit extends beyond my M1 Max MacBook Pro. The same discipline helps when a project becomes larger, several applications are open, the system is busy, or the next user owns less capable hardware. A newer M5 Max can provide far more headroom, but efficient software makes better use of every generation.
Misaki Studio is smooth because performance was treated as a product behavior, not a score added at the end. AI helped me explore and implement improvements faster. Experience told me where the product was wrong. Measurement made the problem visible. Manual coding broke the loops that better prompts and more iterations could not.
That combination matters more than any one tool.
AI increases the speed of iteration. Human experience decides whether the iteration is moving in the right direction.
The real output is the truth.
Sources
Apple, “Introducing M1 Pro and M1 Max: the most powerful chips Apple has ever built,” October 18, 2021.
Apple, “MacBook Pro — Technical Specifications,” accessed September 13, 2026.
Apple Support, “Change the refresh rate on your MacBook Pro or Apple display,” March 17, 2026.
Apple Support, “About Power Modes on your Mac,” June 5, 2026.
Sida Peng, Eirini Kalliamvakou, Peter Cihon, and Mert Demirer, “The Impact of AI on Developer Productivity: Evidence from GitHub Copilot,” February 2023.
Joel Becker, Nate Rush, Beth Barnes, and David Rein, “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity,” METR, July 2025.
Joel Becker, Nate Rush, Tom Cunningham, David Rein, and Khalid Mahamud, “We are Changing our Developer Productivity Experiment Design,” METR, February 24, 2026.
Electron, “Performance,” accessed September 13, 2026.
Apple Developer, “Profile and optimize power usage in your app,” WWDC25, 2025.
Google web.dev, “Rendering performance,” accessed September 13, 2026.
Apple Developer, “Energy Efficiency Guide for Mac Apps: Best Practices,” updated September 13, 2016. This is archived guidance and is cited for enduring design principles, not current API availability.