AI Coding.Info
RepositoriesREPORTS
ABOUT

Claude Code се нарежда на второ място по отношение на броя на използваните AI кодиращи агенти. Какво е номер 1? ~Обобщение на тенденциите в кодирането с изкуствен интелект през юли 2025 г., както се вижда от данните~

AI Coding Agent Юлски тенденции

Пуснахме уебсайт, наречен AI Coding.Info.

https://ai-coding.info/ja

https://x.com/AICodingInfo

Това е сайт, който наблюдава тенденциите на използване, свързани с AI кодиращи агенти като Claude Code, Gemini или Codex от фиксирана точка от информация в хранилището на Github. За да определим използването на AI Coding Agent, ние провеждаме ежедневни проучвания при следните условия.

Степента на използване на AI Coding Agent е 2,9%

**Процентът на използване на AI Coding Agent е 2,9%. ** Това е процентът хранилища, които показват доказателства за използване на AI Coding Agent, въз основа на проучване на 3000 хранилища. Това може да се каже, че е малък процент от общия брой.

image.png

https://ai-coding.info/ja/agents

Това се дължи на множество фактори. Едната е, че това проучване се основава на 100-те най-добри звезди на Github. Следователно, може ли да се каже, че състоянието на използване на 100-те най-добри звезди на Github представлява състоянието на използване на AI Coding Agents по целия свят? Има проблем. Освен това, тъй като това се основава на публично хранилище, може да има несъответствие с текущата ситуация на използване на компаниите. По-скоро представлява статуса на осиновяване на OSS. Можете също така да кажете. Също така, като механичен проблем, ако файлове с правила като CLAUDE.md и GEMINI.md не съществуват, не е възможно да се определи дали се използват или не. Там също е проблемът. Следователно, хранилище, което използва Claude Code, но не създава файл CLAUDE.md, ще бъде оценено като неизползващо Claude Code.

Дял на AI Coding Agent по продукт

**Най-използваният продукт е „Cursor“, следван от „Claude Code“, а трети е „Copilot Agent“ (Github Copilot). ** Като се има предвид, че Gemini CLI беше обявен на 25 юни, фактът, че е на 4-то място от почти месец, може да се каже, че е доста разпространен. Въпреки това, от друга страна, може да се каже, че Gemini CLI има само около 1/3 от наличните хранилища на Cursor.

image.png

https://ai-coding.info/ja/agents

Състояние на използване на AI Coding Agent по език за програмиране

Езикът за програмиране, използван най-много от AI Coding Agent, е „Typescript“, следван от „Python“ и „Rust“. Що се отнася до TypeScript, AI Coding Agent изглежда произхожда от разширения на VS Code като Github Copilot, така че ако мислите за това от тази гледна точка, мисля, че това е донякъде разбираем резултат. Освен това, като се има предвид, че Python има голям афинитет към ML системи като DeepLearning, този резултат може да не е толкова странен. Оттам нататък третият Rust беше изненадващ резултат. Ако си представите резултата от това, Rust е език за програмиране, който набира популярност през последните няколко години. Съществува признание, че това може да се дължи на факта, че общността на програмните езици е млада и нетърпелива да научи за нови инициативи като AI Coding Agent. Може да се каже така.

image.png

https://ai-coding.info/ja/languages

Месечни тенденции в броя на хранилищата, използвани от AI Coding Agent

Нека да разгледаме тенденциите в броя на хранилищата (с припокриване), използващи AI Coding Agent през юли 2025 г. **Към 1 юли ние потвърдихме използването на AI Coding в 77 хранилища. Към 31 юли броят им се е увеличил до 112 хранилища. Броят на използваните хранилища се е увеличил с 1,4 пъти. **

image.png

През последния месец, откакто стартирахме услугата, добавихме агенти за кодиране на изкуствен интелект като Trae IDE и Junie и променихме стандартите за използване за Gemini и можем да видим, че агентите за кодиране на изкуствен интелект проникват в развитието с доста бързи темпове.

Разлика в използването на AI Coding Agent в езиците за програмиране

Проучването разкри, че има големи разлики в степента на използване на AI Coding Agent в зависимост от езика за програмиране. **За TypeScript, AI Coding Agent се използва в 21% от всички хранилища, докато за езика Go той е само около 5% от общия брой. **

image.png

https://ai-coding.info/ja/languages/typescript

image.png

https://ai-coding.info/ja/languages/go

Въпреки че няма солидни доказателства за това, чух някои интересни мнения по време на интервюта за услугата. Съдържанието беше, че „кодирането с използване на AI за генериране е забранено в OSS, свързан с инфраструктурата“. Има няколко примера за това при събиране на информация.

https://www.netbsd.org/developers/commit-guidelines.html

https://wiki.gentoo.org/wiki/Project:Council/AI_policy

https://github.com/qemu/qemu/commit/3d40db0efc22520fa6c399cf73960dced423b048

Това са NetBSD,'' GentooLinux,'' и ``QEMU,'' които не са OSS, реализирани чрез езика Go. Въпреки това, в зони, близки до инфраструктура като ОС и виртуални машини, използването на генериран AI е частично забранено. Kubernetes е известен OSS за езика Go. Въпреки това няма доказателства, че генеративният AI се използва в околната екосистема (свързана с CNCF). В такива инфраструктурни, критични за мисията и високопроизводителни области все още може да е разумно да се използва генериращ AI. Това е парадоксално, но може да се каже, че „Тъй като езикът Go се използва в критични за мисията области с висока производителност, генерираният AI код не може да се използва, защото рискът от повреда е твърде голям. Следователно езикът Go рядко се използва (особено в известните OSS).“ Ако погледнете хранилищата, които действително използват Go, изглежда, че има много малко такива, свързани с инфраструктурата. За grafana/loki или cockroachdb ли става въпрос?

image.png

https://ai-coding.info/ja/languages/go

За да обобщим казаното досега, **AI Coding Agent изглежда е популярен, но действителното му използване обикновено е ниско - 2,9% от общото. Въпреки това, от друга страна, процентът на потребителите, използващи специфични езици за програмиране като TypeScript, бързо нараства. ** Може да се каже, че това е другата перспектива, която споменах по-рано.

Кои езици за програмиране са съвместими с AI кодиране?

В предишната глава говорих за разликата между езиците за програмиране, които могат да използват AI кодиране и тези, които не могат. Тук направих проста хипотеза.

„Езиците за програмиране с много потребители вероятно имат много хранилища, използващи AI кодиране.“

Това означава. Така че нека анализираме данните. Нека начертаем броя на натисканията за конкретен език за програмиране в Github и броя на хранилищата, използвани от AI Coding Agent. Данните за броя на натисканията по език за програмиране в Github са публикувани в хранилището.

https://github.com/github/innovationgraph/tree/main

image.png

Това е първата хипотеза, която направих в началото.

„Езиците за програмиране с много потребители вероятно имат много хранилища, използващи AI кодиране.“

Изглежда, че тази хипотеза може да бъде отхвърлена. Имаше отрицателна корелация с броя на акаунтите, прехвърлени към Gthub през 2024 г. Горната хипотеза имаше за цел да покаже, че „Всъщност степента на използване на потребителите на AI Coding е около 0%, независимо от програмния език. Въпреки това, има разлики в броя на използваните хранилища в зависимост от броя на потребителите на езика за програмиране.“ Но това не е така. разбирам това Сега, напротив

„Често ли се използва AI Coding Agent за езици за програмиране с малък брой потребители?“

 Оказва се, че това не е така. Това е език за програмиране с по-малко потребители от TypeScript, като е разделен на група I и група II в графиката, и няма език за програмиране, който да използва AI Coding Agent толкова пъти, колкото TypeScript. Става. След това нека да дефинираме понятието „коефициент на използване на AI Coding Agent“. Това е стойността, получена чрез разделяне на „броя хранилища, използвани от AI Coding Agent“ на „броя акаунти, изпратени до Github през 2024 г.“. Нанесете това на вертикалната ос и „броя акаунти, изпратени до Github през 2024 г.“ на хоризонталната ос. След това начертайте „броя на хранилищата, използвани от AI Coding Agent“ като размера на кръга.

image.png

Има две неща, които могат да се видят от тази графика. Едната е, че броят на хранилищата, използващи агенти за кодиране на Rust и Python AI, е почти еднакъв, но разбивката е различна. Степента на използване на AI Coding Agent за Python е ниска. Въпреки това, поради големия брой езикови потребители, има определен брой използвани хранилища. От друга страна, Rust има много висок процент на използване на AI Coding Agent, но тъй като има малко потребители на езици, броят на хранилищата за използване остава на определено ниво. Второ, степента на използване на AI Coding Agent на TypeScript не е толкова висока. Степента на използване на TypeScript е 4,65E-06, степента на използване на Go е 5,00E-06, а степента на използване на Ruby е 4,45E-06. Относително казано, не се е променил и с 10%. Всъщност няма голяма разлика в степента на използване между TypeScript, Go и Ruby. Разликата в броя на използваните хранилища може просто да се дължи на разлика в броя на потребителите. Ако тези факти са верни, броят на потребителите на Rust може да се увеличи бързо поради AI Coding Agent. ** Това се дължи на лингвистичния характер на Rust, така че по принцип може да бъде разширен от AI Coding Agent. По-скоро това е индуктивно заключение, базирано на наблюдавани факти, но Rust и AI Coding Agent изглеждат съвместими, тъй като степента на използване на Coding Agent е висока. Като се замислите, Rust всъщност е езикът, който може да се възползва най-много от AI Coding Agent и имам чувството, че ще нарасне значително през следващата година. Понастоящем обаче броят на хранилищата за използване на AI Coding по език за програмиране, които успяхме да проучим, е 100, а от тях броят на използванията на AI Coding Agent е от порядъка на най-много 20, така че дискусията може да стане доста чувствителна, ако броят на използванията се колебае само с едно или две.

мисли

 Пуснати са много агенти за кодиране на изкуствен интелект. Само AI Coding.Info обработва 16 вида продукти. Ежедневието ми е малко натоварено. Ако забавите наваксването, ситуацията може бързо да се промени. Освен това, дори когато се опитват да наваксат информацията, източниците често са пристрастни, което затруднява получаването на точна информация. Преди малко използвах Cline. Говореше се много за това, но всъщност този, който беше популярен в Япония, беше RooCode. Въпреки това, както можете да видите от AI Coding.Info, RooCode почти не се приема в Github. Що се отнася до Cline, той е в Топ 100 хранилища на Github, така че се използва само в себе си и около едно друго хранилище. Освен това, като голяма тема, имам чувството, че напоследък около мен се говори много за ClaudeCode. От друга страна обаче, Cursor често се използва в хранилища. Имаше и пристрастия в зависимост от страната, в която се намирате, и естествения език, който обикновено използвате. Искам източник на информация, който мога да използвам, като същевременно мога да направя спокойна преценка в себе си. Ето защо започнах този сайт. Проверете тенденциите в AI кодирането и се чудете кои инструменти са съвместими с езика за програмиране, който използвате. Чудя се какви файлове с правила всъщност са написани в известния OSS? Ако се интересувате от това, моля, разгледайте.

https://ai-coding.info/ja

https://x.com/AICodingInfo