UsługiNarzędzia AI do kodowania

Konsulting Cursor dla zespołów o wspólnym sposobie pracy

Uzgadniamy z twoimi zespołami reguły projektu, dostęp do narzędzi i praktykę review, a inżynierów szkolimy w twoich własnych repozytoriach.

Porozmawiaj z inżynierem

.cursor/rules/testing.mdcPrzykład

---
description: Test commands and conventions
globs: src/**/*.ts
alwaysApply: false
---
- Run pnpm test:unit before proposing a diff
- Add a test for new behaviour in the same folder
- Never change a snapshot just so a test passes

Reguły projektu trzymane w repozytorium

Kiedy nic nie jest spisane, agent działa według tego, co inżynier wpisał tego dnia w czacie. Recenzenci przypominają wtedy o tych samych konwencjach w jednym pull requeście po drugim. Reguły zapisane w repozytorium rozwiązują ten problem, o ile pozostają krótkie i ktoś za nie odpowiada. Im dłuższy plik reguł, tym mniejszą wagę ma każda linijka. Reguła stosowana do wszystkich żądań za każdym razem zajmuje też część kontekstu.

Reguły piszemy razem z twoimi recenzentami i każdą sprawdzamy na prawdziwych zadaniach. Regułę, którą agent ignoruje albo źle rozumie, usuwamy.

Prawdziwe polecenia do budowania, testów i lintowania, żeby agent mógł sam sprawdzić swoje zmiany
Konwencje, na które zwracają uwagę twoi recenzenci, spisane raz i ograniczone do ścieżek, których dotyczą
Dla każdej reguły jasna decyzja, czy jest zawsze aktywna, dołączana według ścieżek czy wczytywana na żądanie
Jedna osoba odpowiedzialna za reguły i review każdej zmiany w nich

Zadania dzielone tak, żeby review nadążało

Kiedy agenci dostarczają diffy w równym tempie, praca zaczyna czekać w kolejce do review. Z twoimi inżynierami ćwiczymy dzielenie pracy tak długo, aż każde zadanie daje jeden diff, który człowiek jest w stanie zrecenzować. Gdy zmiana obejmuje więcej niż jeden moduł, nawykiem staje się to, że agent najpierw pisze plan, a dopiero potem dotyka kodu. Plan, który sięga dalej, niż wymaga zadanie, zostaje odrzucony.

Gdy sesja oddala się od briefu, ciągnie za sobą nieaktualny kontekst albo kończy się diffem zbyt dużym na review, szybciej jest zacząć od nowa z węższym briefem, niż sprowadzać ją z powrotem na właściwy tor. Testy uruchamia człowiek, który sam przegląda ich wynik, zamiast ufać podsumowaniu agenta.

Zadania na tyle małe, że jeden recenzent przeczyta cały diff za jednym podejściem
Przy pracy obejmującej kilka modułów pisemny plan recenzowany tak samo jak notatka projektowa
Wyniki testów czytane przez inżyniera, niezależnie od tego, czy testy uruchomiono lokalnie, czy w CI
Uzgodniony z góry moment, w którym inżynier porzuca sesję, zaczyna od nowa albo kończy zmianę ręcznie

Do czego agent ma dostęp, lokalnie i w chmurze

To, jakie serwery MCP podłączasz i jak ustawiony jest auto-run, decyduje o tym, do czego agent ma dostęp i co robi bez pytania o zgodę. Jeśli każdy laptop jest skonfigurowany po swojemu, wyniki różnych inżynierów trudno porównać. Po incydencie niełatwo też ustalić, co się właściwie stało. Razem z tobą uzgadniamy allowlistę serwerów. Odnotowujemy w niej serwery, które przechowują dane uwierzytelniające, i to, na co pozwala każdy zestaw tych danych. Wspólna konfiguracja trafia potem do repozytorium albo do ustawień administracyjnych, jeśli twój plan je obejmuje.

Agent chmurowy przenosi zadanie do zdalnego środowiska, pracuje na własnym branchu i oddaje pull request. Zanim twoje zespoły zaczną polegać na agentach chmurowych, sprawdzamy, czy zdalne środowisko potrafi zbudować repozytorium i uruchomić jego testy. Spisujemy też sekrety, których to środowisko by potrzebowało. Potem porównujemy, jak twój plan rozlicza takie uruchomienia, a jak pracę w edytorze. Zadania, w których wymagania wciąż się zmieniają albo jeden błędny krok dużo kosztuje, powinny zostać w edytorze.

Twój plan Cursor decyduje o tym, jakie funkcje i kontrole administracyjne są dostępne, więc od niego zaczynamy. Następnie ustalamy, jakie dane i dokąd trafiają przy twoich obecnych ustawieniach trybu prywatności i indeksowania. Porównujemy to z warunkami Cursor, bo zobowiązania dotyczące prywatności składa Cursor.

Co obejmuje szkolenie

Na jednej sesji szkolimy jeden zespół, na jego własnych repozytoriach i pozycjach z jego backlogu. Czas poświęcamy na nawyki, które trzeba zmienić. Funkcje opisuje dokumentacja Cursor, więc nie omawiamy ich po kolei.

Zespoły, dla których Cursor jest nowy, zaczynają od podstaw: reguł, określania zakresu zadań i review. Zespoły, które używają go na co dzień, rozstrzygają zamiast tego spory: ile pracy oddać agentowi, który model jest domyślny i co recenzent może zakładać o diffach agenta.

Gdzie i w jakim języku szkolimy

Przyjeżdżamy do twoich zespołów w Polsce i w Niemczech albo prowadzimy sesje przez wideo. Język wybierasz ty: polski, angielski lub niemiecki. Na jednej sesji nigdy nie łączymy zespołów, a każdy z nich pracuje we własnych repozytoriach. Otwarte kursy, pojedyncze miejsca i certyfikaty nie należą do naszej oferty.

pstack: workflow jednego inżyniera dopasowany do twojego zespołu

pstack to plugin do Cursor autorstwa Lauren Tan, udostępniony na licencji MIT w repozytorium cursor/plugins. Zawiera skille i playbooki do pracy inżynierskiej, która wraca raz po raz. Ma też regułę, która określa, jaki model pełni daną rolę, oraz workflowy do równoległego prowadzenia pracy i review.

Plugin odzwierciedla sposób pracy Lauren Tan, więc najważniejsze jest ustalenie, które jego części pasują do twojego zespołu. Czytamy dokładnie tę rewizję, którą zamierzasz zainstalować. Spisujemy, na czym się opiera: na osobnym pluginie cursor-team-kit, serwerach MCP, modelach i funkcjach wbudowanych w Cursor. Potem twoi recenzenci przechodzą z nami przez playbooki. Playbook mówi agentowi, co ma robić, ale niczego nie może wymusić. Dlatego to, ile autonomii dostaje playbook, zależy od mechanizmów kontroli, które twoja konfiguracja wymusza poza pluginem. Są to wymagane akceptacje, ochrona branchy i CI. Liczą się też uprawnienia i dane uwierzytelniające, które dajesz agentowi. Jeśli playbook oczekuje więcej swobody, niż pozwalają te mechanizmy, dostosowujemy go, zawężamy jego zakres albo z niego rezygnujemy.

Jedna przypięta rewizja pluginu w forku pod twoją kontrolą, z lokalnymi zmianami w systemie kontroli wersji i wskazanym właścicielem
Playbooki, które uruchamiają polecenia build, test i CI, których już używasz, i zatrzymują się wszędzie tam, gdzie wymagasz akceptacji
Model dla każdej roli i limit pracy równoległej, oparte na wynikach i kosztach zmierzonych na określonym zestawie twoich zadań
Przed przejściem na nową rewizję kontrola, która ponownie uruchamia te same zadania i obejmuje nie tylko playbooki, ale też regułę ról

Testowanie wariantu pstack względem twojej obecnej konfiguracji · Jak liczymy koszty workflowów wieloagentowych · Kod i README pstack w cursor/plugins · Nasz przewodnik po workflowach pstack

Co zostaje w twoich zespołach

Reguły projektu, każda z osobą, która za nią odpowiada
Zadania do ćwiczeń wzięte z twojego backlogu
Notatki o tym, z jakich narzędzi i serwerów MCP agent może korzystać
Krótki runbook, który pomaga nowym inżynierom zacząć pracę

Po czym poznać, że wspólna konfiguracja działa

Każde repozytorium ma jeden zestaw reguł, z którego korzystają wszyscy, zamiast prywatnego zestawu na każdym laptopie
Zmiany zrobione w Cursor wymagają mniej rund review
Koszt zaakceptowanej zmiany, mierzony we wszystkich zespołach, które używają Cursor

Pytania

Które zadania lepiej nadają się dla agenta chmurowego niż do edytora?

Zadanie nadaje się dla agenta chmurowego, jeśli możesz je przekazać na piśmie, a błędny wynik wyszedłby w testach. Zdalne środowisko musi się budować bez sekretów, które wolisz trzymać lokalnie, a ktoś musi zrecenzować pull request. Jeśli któryś z tych warunków nie jest spełniony, lepszym miejscem na to zadanie jest edytor.

Czy wszystko to jest dostępne w każdym planie Cursor?

Nie. Funkcje i kontrole dostępne dla administratorów różnią się w zależności od planu i z czasem się zmieniają. Pomijamy wszystko, czego twój plan nie obejmuje.

Którego modelu nasz zespół powinien używać domyślnie?

Wybierz model, który dobrze radzi sobie z twoimi zadaniami przy koszcie, który ci odpowiada. Odpowiedź zależy od repozytorium i rodzaju zadania. Inżynierowie mogą wybrać model przy każdym żądaniu, więc model domyślny to głównie umowa w zespole. Ewaluacja pozwala zmierzyć, który model się sprawdza, a optymalizacja kosztów zajmuje się rachunkiem.

Czy możemy zacząć od przeglądu naszej obecnej konfiguracji Cursora?

Tak. Bierzemy jedno repozytorium i przeglądamy reguły, które już w nim są, serwery MCP i inne narzędzia podłączone do Cursora oraz kilka zadań typowych dla tego zespołu. To, co działa, zostaje bez zmian. Dla reszty ustalamy z tobą, które zmiany przetestujemy na tych zadaniach. Nie musisz wcześniej decydować się na wdrożenie we wszystkich zespołach.

Czego potrzebujemy od zespołu do pilotażu?

Kilku typowych zadań z backlogu i poleceń, którymi budujecie i testujecie repozytorium. Potrzebny jest też jeden inżynier, który robi review zmian agenta, i jedna osoba odpowiedzialna za wspólną konfigurację. Zakres dostępu ustalamy przed rozpoczęciem pracy. Pierwsza, 30-minutowa rozmowa nie wymaga kodu ani danych dostępowych.

Powiązane usługi

Wdrażanie agentów kodujących

Agenci, którzy z kilku zespołów pilotażowych trafiają do reszty działu inżynierii, ze szkoleniami i jedną wspólną konfiguracją.

Harness engineering

Konfiguracja, która mówi agentowi, jak budować, testować i zmieniać twój kod, trzymana w systemie kontroli wersji.

Ewaluacje na twoich repozytoriach

Narzędzia, modele lub ustawienia porównywane ze sobą na zmianach, które zostały już zmergowane, zanim wybierzesz jedno z nich.

Optymalizacja kosztów LLM

Wydatki na agentów rozbite na zespoły i zadania, a potem obniżone dzięki ustawieniom domyślnym, budżetom i routingowi, które twój zespół platformowy może sam utrzymywać.

Z bloga

Reguły Cursora w monorepo

Jak utrzymać reguły Cursora adekwatne do każdego pakietu w monorepo: reguły zawężone do ścieżek, zagnieżdżone pliki AGENTS.md i właściciel każdej reguły.

Workflowy pstack

Co zawiera plugin pstack do Cursor, jak działają jego playbooki i role modeli oraz jak zespół wdraża go pod własną kontrolą.

Porozmawiaj z inżynierem

Przyjdź z jednym zadaniem, które chcesz usprawnić. Rozmowa trwa 30 minut i nie wymaga dostępu do twoich systemów ani danych.

Umów 30-minutową rozmowę

Rezerwacja odbywa się w Kalendarzu Google.

Wolisz najpierw napisać? Zostaw adres e-mail i kilka zdań, a odpowiemy, proponując terminy.