AICHE +Jetbrains Idea Integration

The short answer: open IntelliJ IDEA (or any JetBrains IDE), position your cursor in a Javadoc block or markdown file, press ⌃+⌥+R (Mac) or Ctrl+Alt+R (Windows/Linux), speak your documentation for 30-90 seconds, and AICHE inserts detailed text at your cursor.

IntelliJ IDEA users typically work on large enterprise codebases where documentation matters more than in any other context. Teams are bigger, code lives for years, and the developer who wrote a service class may not be the one maintaining it in 18 months. Javadoc is required by most enterprise coding standards, but it is painful to type. Method documentation with parameter descriptions, exception explanations, thread safety notes, and usage examples can take 15 minutes per method.

Voice produces better method documentation because you naturally explain the "why" when speaking. Typing Javadoc, most developers write terse descriptions: "@param userId the user ID." Speaking, you say "the user ID from the authentication token, must be a valid UUID, used to look up the user record and verify account status before proceeding." The spoken version is more useful to the developer reading it six months later.

1. Open IntelliJ IDEA with your Java or Kotlin project.
2. Position your cursor above a class, method, or interface. Type /** and press Enter to create a Javadoc block.
3. Press ⌃+⌥+R (Mac) or Ctrl+Alt+R (Windows/Linux) to start recording.
4. Speak your complete explanation - what the method does, why it exists, what each parameter means, what it returns, and what exceptions it throws.
5. Press the hotkey again. AICHE transcribes and inserts the text.
6. Add Javadoc tags (@param, @return, @throws) manually. IntelliJ's intention actions (Alt+Enter) can help generate tag stubs.
7. Run IntelliJ's Javadoc inspection to verify all public APIs are documented.

Heads-up: AICHE transcribes prose, not code syntax. Use it for explaining logic to humans in comments and documentation, not for dictating method implementations.

Javadoc Dictation for Enterprise Code

Service Layer Documentation

Enterprise services have complex method signatures with multiple parameters, return types, and exception scenarios. Position cursor in the Javadoc block above a service method, press your hotkey, and explain the full context. Describe what the method does, what each parameter represents and its valid range, what the return object contains, which exceptions can be thrown and under what conditions, and any thread safety considerations.

Speaking naturally about a payment processing method, you would say "processes a single payment transaction for the given order. The order ID must reference an existing unpaid order, otherwise throws OrderNotFoundException. The payment details contain the card information and billing address, validated before submission to the payment gateway. Returns a PaymentResult with the transaction ID on success or an error code on failure. This method is not thread-safe for the same order ID because concurrent payments could result in duplicate charges. Use the OrderLockService to acquire a lock before calling this method."

That explanation takes 30 seconds to speak. Typing it takes over 3 minutes. And the spoken version covers concurrency concerns that most developers skip when typing.

Interface Contracts

Interfaces in enterprise Java define contracts that multiple teams implement. Documenting the expected behavior, preconditions, and postconditions at the interface level prevents implementation bugs. Dictate these contracts verbally: what implementors must guarantee, what callers can assume, and where the specification intentionally leaves room for variation.

Architecture Decision Records

Capturing Design Rationale

Large codebases need architecture decision records (ADRs) - documents explaining why the team chose one approach over alternatives. These are consistently the most valuable and most neglected form of documentation.

Create an ARCHITECTURE.md or docs/decisions/ folder in your project. Open the file in IntelliJ, press ⌃+⌥+R, and dictate your reasoning. Explain what problem you faced, what options you considered, what trade-offs each option had, and why you chose this particular approach. Enable Content Organization in AICHE settings to have your spoken reasoning structured into clear paragraphs.

ADRs that take 30 minutes to write become 5 minutes of dictation. More importantly, they actually get written, because the friction drops below the threshold where developers think "I'll document this later."

Code Review Comments

When reviewing pull requests in IntelliJ's built-in GitHub/GitLab integration (or in the diff viewer), dictate your feedback. Click into a review comment field, press your hotkey, and speak your concern: what the issue is, what the risk is, what you would suggest instead, and whether this is blocking or advisory.

Spoken review feedback tends to be more thorough and more constructive. The natural cadence of speech adds context and softens the tone compared to the terse comments developers type when reviewing ten files in a row.

JetBrains-Specific Tips

• Works across all JetBrains IDEs. AICHE is a standalone desktop app, not a plugin. It works in IntelliJ IDEA, PyCharm, WebStorm, GoLand, Rider, PHPStorm, CLion, DataGrip, and any other JetBrains product. Same hotkey, same behavior.
• Database documentation in DataGrip. If you use IntelliJ's database tools or DataGrip, dictate table and column comments directly in SQL files or the DDL editor.
• Scratch files for quick notes. IntelliJ's scratch files (Ctrl+Alt+Shift+Insert) are perfect for dictating design thoughts during debugging sessions without cluttering your project.
• No plugin marketplace. AICHE does not require a JetBrains plugin installation. No license compatibility concerns, no waiting for plugin updates after IDE upgrades.

The pro-tip: When writing class documentation, dictate while reviewing the public methods listed in IntelliJ's Structure panel (Alt+7). Walk through each method verbally, and the resulting documentation follows the natural API surface of the class.

Result: Javadoc comments with thread safety notes, parameter validation rules, and exception descriptions. Architecture decision records that capture trade-off analysis. Code review feedback that is thorough without being exhausting to produce.

Do this now: Open IntelliJ IDEA, position cursor above your most complex service class, press your hotkey, and spend 2 minutes explaining the class responsibility, key methods, and important implementation details as if onboarding a new team member.