[{"content":"Lately I\u0026rsquo;ve been using voice input for prompting AI more and more. Before this, I was very much a keyboard person — I thought the keyboard was cool. I can type fast, I work in Emacs with all its commands and shortcuts for navigating around text, and that always felt very efficient. But I\u0026rsquo;m seeing more and more power users and senior developers using voice input in their day-to-day development work. I even came across a meme post about how developers of the future will only need two buttons and a pedal for prompting AI. So one day, I decided to try it for myself. Claude Code has a built-in voice mode, so I just tried it — and it actually feels much better.\nOne major issue I had before was with the Claude Opus 5 model producing very lengthy output. The response overflows past one screen, so you end up scrolling down and down to keep reading while trying to hold on to your thoughts — by the time you reach the end, you\u0026rsquo;re juggling reading and note-taking at the same time. Voice input changed exactly that flow: instead of pausing to type, you press the voice shortcut, say out loud your thoughts or suggestions about what you just read, release the voice key, and keep scrolling. Reading and responding become one continuous loop instead of two competing activities.\nIt just feels more natural — more like actually communicating with the agent. Sometimes you almost wish the agent could talk back to you, like talking to an actual person. But voice input makes providing prompts much easier and reduces the mental load and pressure of writing.\nThere\u0026rsquo;s also the simple input-speed comparison: how many words you can type per minute versus how many you can say per minute. With voice, you simply get more prompt out. And with AI, providing a richer prompt means it does more of exactly what you want.\n","permalink":"https://genegi.github.io/posts/voice-input-for-prompting-ai/","summary":"I was a keyboard person — Emacs shortcuts and all. Then I tried Claude Code\u0026rsquo;s voice mode. Why dictating prompts feels more natural than typing, especially when reading lengthy agent output.","title":"Voice input for prompting AI"},{"content":"Design docs used to be a core part of any serious project. Writing one meant your project had enough scope to warrant upfront design: understanding the problem, clarifying requirements, learning the existing system, weighing options, and landing on a recommendation. It usually took more than two weeks, plus a couple rounds of design review to get the team aligned.\nAI has changed the whole nature of development, and it also impacts how we write design docs. There\u0026rsquo;s a saying these days that people don\u0026rsquo;t do design anymore: instead of arguing about options on paper, you should build a live prototype. AI can generate one easily now, letting you quickly experiment with multiple options, which gives you a better feel for what it actually looks like and where the limitations are. I think this approach works well for most front-end work like UI interfaces (though AI still isn\u0026rsquo;t very good at UX design yet). But for back-end work, there are usually multiple dependencies across teams, and you don\u0026rsquo;t have full control of the system — we can\u0026rsquo;t rely on AI to build all of those as mocks.\nAlso, for projects running in production with many dependencies, the design doc is still the better way to seek alignment: it lets our dependency teams know what changes are coming. As a stakeholder upstream or downstream, they will understand clearly the impact of your changes on their services.\nI recently did one of these design reviews, and I\u0026rsquo;d say AI helped a lot — but it totally changed my way of writing a design doc. We have a template for writing design reviews, so I provided the template to AI, and it generated a version that was more or less correct. It can do some research, and you can provide context documents and requirements. Basically, it\u0026rsquo;s very cheap to get an initial version of your design. But how you iterate on top of that is still an open question.\nOne issue I\u0026rsquo;m noticing with AI-generated design review docs is that they tend to be very lengthy and hard to read. Yes, you could use something like an agents.md or specific writing guidelines, ask the agent to follow them, maybe even profile your previous artifacts so the agent writes in your style — but the problem remains. After AI generates the initial draft, you need to read it and effectively review it. Before, you would write the doc and others reviewed it; now AI provides the draft and you\u0026rsquo;re doing the design review for your own document. That tends to be time consuming.\nAnother issue: because the doc is so long, my attention drops over time. The first half of my document was much more thoroughly revised — I read it carefully and gave feedback to the agent, which iterated based on my comments. But by the later version, the effort required to read the whole doc kept increasing, so the second half ended up sloppier and didn\u0026rsquo;t get my full attention. Quite a few sections remain where you don\u0026rsquo;t agree with the agent or want to confirm certain things — and AI sometimes includes unrelated or questionable claims that you have no idea where they came from. If you leave those in, it gets quite awkward when a colleague asks you what a particular section means and you don\u0026rsquo;t know. You\u0026rsquo;ll likely just copy-paste the same question into your AI agent.\nThat\u0026rsquo;s the big issue with writing design docs this way, in my mind.\nSo here\u0026rsquo;s my ideal way to write a design doc currently. First, definitely keep what we did before AI: you need to do research. You work with your research agent together — you provide the direction, it produces a small research summary — and you read that first. Based on the AI research summary, you write down your own ideas and insights.\nMaybe draft a few bullet points, then ask AI to rewrite them — to make them more readable and follow the best format for the audience. Things like clarifying requirements and listing use cases, AI can help with, but you need to review everything. I\u0026rsquo;m leaning toward not letting AI write your thoughts: you should write yourself based on the AI output, and only ask AI to modify on top of your ideas. One thing AI does better than any of us, though, is cross-referencing. When you update one part of a design, a human tends to miss one or two other places that referenced it — AI can catch all of them and update every related place consistently. Similarly for the design options — the main part of the doc, the options you considered with their pros and cons. Write your own thinking first; you should already have some ideas from the AI research summary. Once those notes are done, you can ask the agent about other approaches, compare against what you have, surface any pros or cons you missed, and add them back into your own doc.\nThat\u0026rsquo;s my current ideal way to write a design doc in the AI era. I expect it will keep evolving with the models\u0026rsquo; abilities, but for now, this is what works best for me.\n","permalink":"https://genegi.github.io/posts/how-to-write-a-design-doc-in-ai-era/","summary":"AI can draft a design doc cheaply, but iterating on it means reviewing your own document — and attention fades. Why design docs still matter for alignment, and my workflow: research with AI, write your own ideas, let AI polish and cross-reference.","title":"How to write a design doc in the AI era"},{"content":"In my day-to-day work, code review still requires human approval to be merged. But more and more frequently, the author doesn\u0026rsquo;t even review the code anymore and reviewers rely more on the AI code review comments. AI will provide the verdict to Approve or just leave blocking comments. I also see people don\u0026rsquo;t even review the comments provided by AI and just post them, all of that information flooded to the author is hard to process and likely the author will just use AI to handle all those comments.\nI am also working on a side project after work. It is still in the early phase of the development, and I am not reviewing any code generated by AI. The major reason is AI is writing code way faster than people can review, so humans will be the bottleneck for delivering the feature. But it is not no review: I use an adversarial AI agent to run code review against the change, and it will usually generate some feedback and AI will address those first with the feedback loop. I will just merge the AI code and rely on the next version of the app with new code to verify the behavior.\nSo back to the title, do we still need to review AI-generated code? I think it still depends. In the early phase of the feature development, or if you have limited users and you can accept the risk of AI taking down your service and hurting the existing experience and prefer faster iteration, yes, you don\u0026rsquo;t need to review the code anymore, that is slowing you down. Instead, create some feedback loop and set certain guardrails, like code still builds (compiler), linting still passes (linter), integration tests about the behavior. Rely on those to keep AI on track instead of reviewing each line of code.\nBut the story changes once you have more and more users and handle critical data. The stories about AI bringing down the whole service and deleting the DB are still happening. In those cases, how can you trust the AI will not accidentally pass the test by just deleting them? Humans should still be the gate for those cases if you want more reliable code. Though such things also happened before AI came, fully human-written code will also cause such issues. The thing about developing is that writing bugs doesn\u0026rsquo;t change, it is just how we hold people, or AI, accountable.\nAlso for open source projects, do you trust any random person\u0026rsquo;s code generated by AI, to merge it into your code base and have it lose your control? Most people don\u0026rsquo;t want that. AI is not that welcome in open source; it is still about building your reputation in the open source community, people will trust the people.\n","permalink":"https://genegi.github.io/posts/do-we-still-need-to-review-ai-generated-code/","summary":"It depends on the stage and the risk. Why I skip review on my side project, why I wouldn\u0026rsquo;t at work, and how we are shifting from reviewing code to verifying behavior.","title":"Do we still need to review AI-generated code?"},{"content":"Today, during work, I was doing some away team work on a partner team\u0026rsquo;s code package. For the code review I submitted, I received about 15 comments about it. All comments are quite long and have a line saying that it is reviewed by AI. It took me quite a while to basically read through all of the comments and think about how to address them. Some of them do make sense and some are edge cases, I don\u0026rsquo;t think worth adding this round. I did perform some code review from another model (my code written by Claude Opus and I had it reviewed by Codex Sol) before I published the CR. Some of them I kind of intentionally kept out of this CR, but all those comments came back on colleagues\u0026rsquo; AI review. It largely impacted my delivery speed of the day.\nSome thoughts about the AI CR review are: for the AI review workflow it should be a standard across the team, so other team members can run the same flow and get the same feedback, so their coding agent can capture those comments and have those addressed. Humans should review AI CR comments they want to post; if the reviewer doesn\u0026rsquo;t review the comments they provide, they shouldn\u0026rsquo;t expect the code author to read them all and address them. Another thing is, should I just throw those comments to AI and ask AI to help me address them? The major problem of that is currently AI is too strict about corner cases and pushes too hard on it, causing the code to be very complex and hard for humans to understand later.\n","permalink":"https://genegi.github.io/posts/ai-code-review/","summary":"Complains about AI code review comments and my thoughts about AI code review","title":"I got a bunch of AI Code Review comments"},{"content":"A lottery drawing app built for Spring Festival gatherings. Configure prize tiers, run animated draws, and keep results in sync across devices via Firebase.\nBuilt with React 19, TypeScript, and Vite.\nOpen the lottery →\nSource on GitHub\n","permalink":"https://genegi.github.io/projects/spring-festival-lottery/","summary":"A React lottery app built for Spring Festival — configurable prizes, animated draws, and Firebase-backed results.","title":"Spring Festival Lottery"},{"content":"起因是和Ray一起吃饭的时候聊到一部叫《伊丽莎白镇》的电影，电影里女主给心灰意冷的男主一份自制的当地地图，男主最后根据地图找到女主，重拾生活的信心。\n我们就想自己设计一份基于西雅图的解谜，所有就有了这个。\n如果能线下去走一走的，推荐去走一走。在线上基于Google地图街景也能玩。\nHave Fun！\n","permalink":"https://genegi.github.io/projects/seattle-puzzles/","summary":"一份基于西雅图的中文诗谜解谜。线下可以走起来，线上用 Google 街景也能玩。","title":"Seattle Puzzles"},{"content":"Professional Summary Experienced software engineer with a passion for building innovative solutions. Skilled in modern development technologies, with a focus on creating efficient and elegant solutions.\nExperience Software Development Engineer - Amazon 2021 - Present\nEducation Master of Science in Computer Science University of Southern California, 2019-2020\nSkills Programming Languages: Python, JavaScript Web Technologies: React, Node.js Projects Contact GitHub: https://github.com/GeneGi Email: junzheji@gmail.com ","permalink":"https://genegi.github.io/about-me/","summary":"\u003ch2 id=\"professional-summary\"\u003eProfessional Summary\u003c/h2\u003e\n\u003cp\u003eExperienced software engineer with a passion for building innovative solutions. Skilled in modern development technologies, with a focus on creating efficient and elegant solutions.\u003c/p\u003e\n\u003ch2 id=\"experience\"\u003eExperience\u003c/h2\u003e\n\u003ch3 id=\"software-development-engineer-amazon\"\u003eSoftware Development Engineer - Amazon\u003c/h3\u003e\n\u003cp\u003e\u003cem\u003e2021 - Present\u003c/em\u003e\u003c/p\u003e\n\u003ch2 id=\"education\"\u003eEducation\u003c/h2\u003e\n\u003ch3 id=\"master-of-science-in-computer-science\"\u003eMaster of Science in Computer Science\u003c/h3\u003e\n\u003cp\u003e\u003cem\u003eUniversity of Southern California, 2019-2020\u003c/em\u003e\u003c/p\u003e","title":"About Me"},{"content":"Tried with AI agent to fix my org roam node title issue, it works surprisingly well. And also tried to set up blogging and AI just did all of it for me.\n","permalink":"https://genegi.github.io/posts/having-fun-with-ai-agent/","summary":"\u003cp\u003eTried with AI agent to fix my org roam node title issue, it works surprisingly well. And also tried to set up blogging and AI just did all of it for me.\u003c/p\u003e","title":"Having fun with AI agent"},{"content":"Hello, World! Welcome to my new blog! This is my first post created with org-mode and Hugo.\nWhy I Started This Blog I wanted to share my thoughts and experiences using a simple yet powerful blogging setup.\nHow It\u0026rsquo;s Built This blog is built using:\nEmacs with Doom configuration Org-mode for content creation ox-hugo for exporting to Hugo Hugo for static site generation GitHub Pages for hosting What\u0026rsquo;s Next I plan to write about:\nTechnology Programming Personal projects And more! Stay tuned for more content coming soon!\n","permalink":"https://genegi.github.io/posts/hello-world/","summary":"\u003ch2 id=\"hello-world\"\u003eHello, World!\u003c/h2\u003e\n\u003cp\u003eWelcome to my new blog! This is my first post created with org-mode and Hugo.\u003c/p\u003e\n\u003ch3 id=\"why-i-started-this-blog\"\u003eWhy I Started This Blog\u003c/h3\u003e\n\u003cp\u003eI wanted to share my thoughts and experiences using a simple yet powerful blogging setup.\u003c/p\u003e\n\u003ch3 id=\"how-it-s-built\"\u003eHow It\u0026rsquo;s Built\u003c/h3\u003e\n\u003cp\u003eThis blog is built using:\u003c/p\u003e","title":"Hello World"}]