--- title: "Developer Tools UX: Lessons from CodeAnt | Utkarsh Panwar" description: "Developer tools UX lessons from designing CodeAnt AI for 40,000+ weekly developers: org permissions, docs vs guided setup, density and terminology." url: https://www.utkarshdesign.com/guides/designing-for-developer-tools author: Utkarsh Dhairya Panwar updated: 2026-10-08 --- # Developer tools UX lessons from CodeAnt Guide · 7 min read · By [Utkarsh Dhairya Panwar](https://www.utkarshdesign.com/about) · Updated 8 Oct 2026 ![GitHub-style Install & Authorize dialog with options for all or selected repositories, a list of read and write permissions and a green Install & Authorize button](https://www.utkarshdesign.com/images/QWzAhleILakb0CawY3pUt5lphEE.webp) **Good developer tools UX starts from the org. The developer who finds your tool often can't install it, so design the hand-off to whoever can. Then guide first setup step by step, keep docs for reference, show a map instead of a tour, and use the words developers already use.** ## Where this comes from Since June 2024 I've been the founding designer at CodeAnt AI (YC W24), a code health platform for engineering teams. I own the UX for AI code reviews, developer insights, code quality and security scans, which 40,000+ developers use every week across 800+ companies. Developers are demanding in a particular way. They'll put up with an ugly screen if it's fast and correct, and they won't put up with a pretty one that hides what it's doing or wastes their time. Most of what follows comes back to that. ## 1. Design for the org chart Consumer onboarding assumes the same person decides, signs up and does the setup, which is almost never true for developer tools. At CodeAnt, connecting a repository meant installing the GitHub app on the company org, which needs admin rights. The developer who found CodeAnt usually didn't have them, and the install fell back to their personal account without saying so. ![Flow diagram: a developer discovers CodeAnt, is blocked at the Admin Wall outlined in red, while the org admin who has access is the one who can connect the repo](https://www.utkarshdesign.com/images/aU20VqOCAkvTLldgRFUIL0s6d4.webp) _The person with intent and the person with access are rarely the same._ So at CodeAnt we stopped treating that developer as the end of onboarding. At the permissions step they can now email the admin or share an invite link into team chat (the full before and after is in how CodeAnt doubled trial-to-paid). ![CodeAnt Request Admin Approval modal with an invite-link field and Copy button, an org admin email field with a Send button, and a Book a Call link](https://www.utkarshdesign.com/images/codeant-request-admin-approval.webp) _The shipped hand-off: copy an invite link for team chat, or email the admin directly._ Before designing any devtool onboarding, I now list every permission the setup needs and who in a typical team holds each one. Any step the signer-up can't do alone needs a designed hand-off. ## 2. Docs for reference, guided flows for first setup Developers do read docs, and good docs are part of the product. But a setup doc written for every environment leaves each reader to filter out what doesn't apply. For self-hosted teams, CodeAnt's setup lived in that kind of document. I rebuilt it as step-by-step flows, one per platform, each with its own short video. Readers see only their own steps and can check what each one should look like. The docs stayed, for edge cases and for anyone who prefers them. ![Before: CodeAnt docs page for self-hosted Azure DevOps setup, with sidebar navigation, numbered steps and an embedded Azure screenshot](https://www.utkarshdesign.com/images/vSEIhJhnwDQQxTA3aEd7PUqnTio.webp) _Before: a reference doc doing the job of a setup flow._ ![After: guided self-hosted setup with a Configure Application Details video beside step 4 of 4, a form for GitLab URL, Client ID and Client Secret](https://www.utkarshdesign.com/images/codeant-self-hosted-after.webp) _After: a single platform, shown a step at a time with a short video._ | Use a guided flow when | Use docs when | | --- | --- | | It's a one-time setup most users go through | It's reference material people return to | | The steps differ by platform or environment | The reader is debugging an unusual setup | | Getting a step wrong silently breaks later steps | The reader needs every option beyond the common path | ## 3. Show a map, skip the tour Developers close product tours. They'd rather see what exists and go straight to the part they came for. CodeAnt's Get Started screen lists each product line with a direct link into its setup, so there's no sequence to follow and nothing to dismiss. ![Branching diagram: Repository Connected leads to AI Code Review marked Explored, with Code Security and Code Quality greyed out as Unexplored](https://www.utkarshdesign.com/images/iEuSzY6wsVO5OtdDJIG2rOVWZM.webp) _Without a map, people found one product line and never saw the rest._ After that, prompts should respond to behaviour. CodeAnt's emails and in-product nudges were triggered by what each user had and hadn't set up, so a developer only heard about the parts they hadn't touched. ## 4. Use their words, and define success in their units Repo, org, pull request, quality gate, secret leak. Developers already have exact meanings for these words. Rename them to sound friendlier and the product gets harder to trust. If GitHub calls it an organisation, so should you. Success should be measured in their terms too. CodeAnt's onboarding tests made the first reviewed pull request the clear success point. A developer reads "my PR got reviewed" as proof the tool works, which a progress bar can't give them. ## 5. Density for developers, a different view for managers Developers and engineering managers both cope with a lot on one screen, but they want different things from it. A developer wants the issues in their own repo. A manager wants to know where across the org to act first. CodeAnt's manager dashboards put code analysis and secret leaks in one view, and org-level triage time dropped 35%. A devtool also has many surfaces (scan centre, code review, security flows, metrics), so a table, a severity label or a filter should behave the same on every one of them. That's why I pulled CodeAnt's repeated patterns into one system. ## 6. Trust comes from showing your work A code health tool reads private code and posts opinions about it, so it gets very little benefit of the doubt. In practice that means being explicit about what access is requested and why, pointing every finding at the exact place in the code it refers to, and making it easy to disagree with a result. The last point matters even more with AI features. I've written about those separately in designing AI features users trust. [CodeAnt AI case study](https://www.utkarshdesign.com/work/codeant-ai): Onboarding, the admin wall, self-hosted setup and the Get Started screen, with the before and after flows. If you're building a developer tool and want this kind of thinking on your product, see my AI and developer tools design service. ## Questions people ask ### What makes developer tools UX different from other SaaS? The person who discovers the tool often can't install it, so onboarding has to involve several people. Developers also expect exact terminology, high information density and fast paths over guided hand-holding. ### Should a developer tool have a product tour? Usually not. At CodeAnt we used a Get Started screen with direct links into each product line instead, and kept follow-up prompts tied to what each user had or hadn't done. ### Are docs enough for onboarding developers? Docs work well as reference. For one-time setup that differs by platform, a guided step-by-step flow with platform-specific help gets more people through, and the docs can stay for edge cases. ## Sources 1. [Installing a GitHub App from a third party](https://docs.github.com/en/apps/using-github-apps/installing-a-github-app-from-a-third-party), GitHub Docs 2. [Onboarding Tutorials vs. Contextual Help](https://www.nngroup.com/articles/onboarding-tutorials/), Nielsen Norman Group ## Working on this? Tell me what you're building and where it's stuck: [book a 30-minute call](https://cal.com/utkarsh-design/30min), email [work@utkarshdesign.com](mailto:work@utkarshdesign.com) or [send a brief](https://www.utkarshdesign.com/contact). ## Related - [Product designer for AI and developer tools](https://www.utkarshdesign.com/services/ai-and-developer-tools-design) - [CodeAnt AI (YC W24)](https://www.utkarshdesign.com/work/codeant-ai) - [Designing AI features users trust](https://www.utkarshdesign.com/guides/designing-ai-features) - [How we doubled trial-to-paid at CodeAnt](https://www.utkarshdesign.com/guides/how-we-doubled-trial-to-paid) --- Utkarsh Dhairya Panwar, Founding Product Designer and Design Engineer (IIT Roorkee; Founding Designer at CodeAnt AI, YC W24). Email: work@utkarshdesign.com · Book a call: https://cal.com/utkarsh-design/30min · Hire: https://www.utkarshdesign.com/hire · About: https://www.utkarshdesign.com/llms.txt