Selected for Chiba Institute of Technology's AI Utilization Promotion Grant Program — When the Application Itself Was a Conversation with AI
Overview
This is a grant program run internally at Chiba Institute of Technology, where I am enrolled, to encourage AI use in learning and research. The grant consists of a Claude Enterprise premium seat, and the project period runs from July 28, 2026 to May 1, 2027.
My proposal title was “ReLow60 L-HE: Improvement and New Product Development of a Hall Effect Keyboard through AI Collaboration”, and the result was selected.
An Unusual Application Format
The most interesting aspect of this program was how to apply. Rather than writing a motivation statement in a form, the conversation itself with an AI (Evaluator) was the submission. The process of exploring your topic through dialogue became the deliverable.
There was no time limit, and submission was one-shot. I started the conversation curious about how well it would actually understand what I was working on — and the questions that came back were far more pointed than I expected. Below I summarize what was asked and how I answered.
What Was Asked and How I Answered
How I Have Used AI So Far
The largest share goes to review and verification. In PCB design, I worked through layout decisions for noise reduction, asking for supporting sources alongside each recommendation. For firmware and configuration tools, I use AI to generate initial drafts and discuss implementation approaches.
That said, the judgment on what to adopt and the verification on actual hardware is always mine. Nothing comes out of those conversations and goes straight into a product. Things like typing feel and ease of configuration — “parts you can only judge by actually pressing the key” — are areas where AI cannot substitute for me.
AI also serves as a second perspective outside myself in situations that require stepping back from the project, such as marketing or contest applications.
The Moment I Found Most Valuable
It was when a wiring mistake in a circuit design was caught. It was a serious error, but because the AI read my schematic file and flagged it, I caught it before placing the order. Had I needed to redo the board, I would have lost significant time and money.
A close second was being shown what conditions to measure under and what criteria to use for evaluation when characterizing a finished board. I had no background in product testing and was at a loss, so this was invaluable. It felt less like “getting an answer” and more like “being handed a measuring stick.”
What I Plan to Do Next
The current version is in limited sale as a test release, and I am now at the stage of incorporating that feedback into a full production version. I answered with priorities.
Priority 1: Software / Firmware (shared foundation)
- Advanced macro features (time delays, conditional branching, variables, etc.)
- ReConf UI improvements. Users have reported getting lost due to the feature density, so separating beginner and advanced modes and surfacing key features
- Firmware and ReConf integration optimization, memory usage reduction
Priority 2: Revised hardware
- Revisiting the case structure (improvements targeted for the next revision)
- Design, ordering, and testing of the revised version
Priority 3: New product development
- 75%, ortholinear, split, and similar layouts. This also serves the goal of broadening the range of input device options available.
- Extending existing software to support new products
Priority 4: Custom boot system (deferrable)
Currently, firmware is written via DFU mode from a browser, but on Windows, WebHID sometimes fails to acquire DFU mode (this does not occur on Linux or Mac). A custom boot system would resolve this, but it is not a mandatory improvement and carries substantial engineering cost, so it was deprioritized.
Software was made the top priority because the same software will be reused across future new products. Raising the quality here benefits every product that follows.
How I Will Use AI in Hardware Design
In the previous design, I did not leverage AI much on the hardware side. The reason is straightforward: CAD files cannot simply be handed over as-is.
Going forward, I plan to provide concrete numerical values and have the human side articulate the design in language before working through it with AI, in order to eliminate design mistakes. This covers things like discussing fit depth and load mechanics, and verifying screw hole placement and structural strength.
My Stance on Using AI
Delegating everything to AI means no growth for me, so I make a point of bringing my own hypothesis to AI first. That way I can catch flaws in my own understanding — and sometimes catch hallucinations on the AI side as well.
On Parallel Development
Developing alone means there is a hard limit on how many things I can advance simultaneously. My approach is to build a spec document from user feedback, my own requirements, and AI input; have AI generate an implementation draft after I confirm the content; and write the next spec document myself while that is in progress.
Running too many things in parallel causes them to fall out of sync, so I share a progress-tracking file and keep the foundations aligned so things are easy to integrate later.
Even with limited web knowledge, being able to shape ReConf and the product site with AI assistance was significant. On the other hand, ReConf’s UI was where things did not go smoothly. I went through many rounds of dialogue until I was satisfied, and ultimately refined the details myself. This was a case where “AI will make it faster” simply did not hold.
What I Noticed Through the Conversation
At the end, I was asked: “Did anything new become clear to you through this conversation?”
The realism of my schedule. Breaking things into granular tasks is something I am good at, but long-term planning is a genuine weakness. Through this conversation, I learned a method — and its importance — for pressure-testing specific tasks against a long-term plan.
At one point, I had a plan to run “software improvements, revised hardware, and a new product” in parallel with only two months until a September event. The AI asked me directly: “I’ll ask honestly — do you genuinely think this is achievable in two months?” The point was that with PCB manufacturing lead times, there was almost no room for a second order if something went wrong.
That pushed me to think it through, and I was able to confirm: September is not an absolute deadline but a milestone; DIY keyboard events happen every three months; and because the test and revised versions share nearly the same software, development can continue during hardware production lead time. These were things I could only articulate once I was pressed on them.
When asked “If you could do it over, what would you change?”, I answered: “I would open with my QWS Challenge application text and design philosophy.” Starting from the underlying question rather than the technical features would have gotten to the core faster.
Grant Conditions (Summary)
There are several things I have been asked to do as part of the grant. Omitting the full detail, the gist is:
- Manage deliverables (source code, configuration files, documentation, etc.) in a Git repository to the extent possible
- Share the repository with the supervising faculty for progress checks. Making it public is not required — private sharing is fine
- Monitoring is passive only, through Git history and usage data; no active surveillance
- Track all work in Git from day one, committing frequently including trial-and-error
- API keys are not issued by default; they can be discussed once sufficient progress and need have been demonstrated
Which proposals to pursue during the period is left to the applicant, and goal changes or pivots as the work evolves are explicitly welcome.
Going Forward
Through May 2027, I will start with software and firmware improvements. Once that foundation is solid, it will benefit every subsequent product.
TiB・AI活用助成・DigiKey・QWS の4件まとめ
ReLowシリーズ キーボードコンフィギュレータ