ИТ фирми и пракси во Скопје

[Amaterasu]

Он може има, ние не. Како и да е не ти требаат unlimited tokens за да ти заврши работа. Ја неам дадено повеќе од 20 долари, a неам искуцано ништо (освен хоби проект) повеќе од 2 години.

Автоматски споено мислење: денес во 09:05

Што замислувате под добри темели?
Она што го кажувам е дека крафтот на кодирање е тотално небитен. Целата поента беше да можат девелоперите да се снајдат во кодот. И сите фрејмворкс се во таа насока. На агентот не му треба тоа - чита и се снаѓа подобро од тебе во било што, предвидува и решава багови подобро од тебе и тн.

Ова може ќе биде така ако можеш да им веруваш на агентите 100%. А во моментов сме далеку од тоа. Имаш еден куп случаи каде што AI не може да ти го најде багот. Дали затоа што нема пристап до целиот контекст (сигурно нема PROD DB access да му дадеш), дали затоа што не куцаш добро query, дали затоа што не е семоќно (сеуште).
Од тие причини, уште ти треба добра архитектура и добра организација на код. Агентот треба да куца код ист како што би куцал некој член на тимот, идеално да не можеш да познаеш дека е напишано од агент. За да кога ќе треба да отвориш некој feature да разгледаш, да ти биде лесно. Нормално дека ќе го прашаш и AI да ти го објасни непознатиот код, ама многу е полесно кога гледаш познати патерни во кодот а не 100 интерфејси креирани од АИ за да биде fancy кодот, затоа што некој му лупнал "please keep in mind all SOLID principles" во prompt-от.

Овие филмови со немање потреба од фрејмворкс, јазици и така натаму може ќе бидат релевантни за 5-10 години, кога AI ќе го достигне нивото каде што ќе имаме целосна доверба во него. Ама во тој случај зошто да застанеме на фрејмворкс? Нема да имаме потреба ни од high-level programming languages. Ќе куца AI-то директно инструкции на CPU левел и готово. Ќе имаме и realtime програми кои си го модификуваат кодот врз основа на realtime потребите. Зошто да куцаш за код за нешто што можеби ќе ти треба? Ќе се искуца кодот во моментот кога ќе стане потребно и готово.

 

[Menethil]

Ова може ќе биде така ако можеш да им веруваш на агентите 100%. А во моментов сме далеку од тоа. Имаш еден куп случаи каде што AI не може да ти го најде багот. Дали затоа што нема пристап до целиот контекст (сигурно нема PROD DB access да му дадеш), дали затоа што не куцаш добро query, дали затоа што не е семоќно (сеуште).
Од тие причини, уште ти треба добра архитектура и добра организација на код. Агентот треба да куца код ист како што би куцал некој член на тимот, идеално да не можеш да познаеш дека е напишано од агент. За да кога ќе треба да отвориш некој feature да разгледаш, да ти биде лесно. Нормално дека ќе го прашаш и AI да ти го објасни непознатиот код, ама многу е полесно кога гледаш познати патерни во кодот а не 100 интерфејси креирани од АИ за да биде fancy кодот, затоа што некој му лупнал "please keep in mind all SOLID principles" во prompt-от.

Овие филмови со немање потреба од фрејмворкс, јазици и така натаму може ќе бидат релевантни за 5-10 години, кога AI ќе го достигне нивото каде што ќе имаме целосна доверба во него. Ама во тој случај зошто да застанеме на фрејмворкс? Нема да имаме потреба ни од high-level programming languages. Ќе куца AI-то директно инструкции на CPU левел и готово. Ќе имаме и realtime програми кои си го модификуваат кодот врз основа на realtime потребите. Зошто да куцаш за код за нешто што можеби ќе ти треба? Ќе се искуца кодот во моментот кога ќе стане потребно и готово.

Муабетот - сеуште има случаи кај што АИ не може да го најде багот, ти кажува дека тоа се edge cases, и тоа најчесто е зашто нема добар контекс на проблемот или пристап до негде. Работата е што се повеќе код ќе биде пишуван од агенти, и нема да изглеа ко да е напишано од човек, зашто ниеден човек нема да куца рачно. Пишување - читање ти е agent to agent. АИ то не го занима ни солид, може да се снајде во секој случај, тоа се апстракции за нас.

Да, тоа што си го опишал со high - level languages е реална прогноза за 5-10 години. Имај у предвид дека прогнозите по години нема да се исти за сите. Луѓе кој работат во стартапи и луѓе во банка нема да имаат иста прогноза, ама прилично јасно е кој е frontrunner a кој заостанал во процесот на девелопмент. Мислам, имаш луѓе кој рачно куцаат квериња на памет и тоа им е целата работа Им држам среќа да останат кај што се, зашто работата им е позаменлива од човек на патарина.

 

[Емкаа]

Ова може ќе биде така ако можеш да им веруваш на агентите 100%. А во моментов сме далеку од тоа. Имаш еден куп случаи каде што AI не може да ти го најде багот. Дали затоа што нема пристап до целиот контекст (сигурно нема PROD DB access да му дадеш), дали затоа што не куцаш добро query, дали затоа што не е семоќно (сеуште).
Од тие причини, уште ти треба добра архитектура и добра организација на код. Агентот треба да куца код ист како што би куцал некој член на тимот, идеално да не можеш да познаеш дека е напишано од агент. За да кога ќе треба да отвориш некој feature да разгледаш, да ти биде лесно. Нормално дека ќе го прашаш и AI да ти го објасни непознатиот код, ама многу е полесно кога гледаш познати патерни во кодот а не 100 интерфејси креирани од АИ за да биде fancy кодот, затоа што некој му лупнал "please keep in mind all SOLID principles" во prompt-от.

Овие филмови со немање потреба од фрејмворкс, јазици и така натаму може ќе бидат релевантни за 5-10 години, кога AI ќе го достигне нивото каде што ќе имаме целосна доверба во него. Ама во тој случај зошто да застанеме на фрејмворкс? Нема да имаме потреба ни од high-level programming languages. Ќе куца AI-то директно инструкции на CPU левел и готово. Ќе имаме и realtime програми кои си го модификуваат кодот врз основа на realtime потребите. Зошто да куцаш за код за нешто што можеби ќе ти треба? Ќе се искуца кодот во моментот кога ќе стане потребно и готово.

Зошто во денешно време би отворил да гледаш како е искуцан некој feature?
Навистина ме интересира.
Кај нас иаме скоро неограничен буџет ( 500 долари е дневно мислам ), и кога ќе започнеш екстензивно да користиш АИ со ваков буџет, нема ни да имаш потреба од ИДЕ.
Апсолутно халуцинира во одредени моменти, ама 95% од времето е беспрекорно.

 

[Amaterasu]

Зошто во денешно време би отворил да гледаш како е искуцан некој feature?
Навистина ме интересира.
Кај нас иаме скоро неограничен буџет ( 500 долари е дневно мислам ), и кога ќе започнеш екстензивно да користиш АИ со ваков буџет, нема ни да имаш потреба од ИДЕ.
Апсолутно халуцинира во одредени моменти, ама 95% од времето е беспрекорно.

Мислам дека AI буџетот нема врска со ова. Како што кажав, имаш проблеми кои AI-то не може да ти ги реши, а тоа не се должи на токени. Ако му дадеш пристап до сите можни системи (продукциски бази, периферни системи како kafka, redis, итн) тогаш можеби ќе го зголемиш бројот на проблеми што може да ги реши. Ама често пати, кога проблемите не се поврзани само со кодот на кој работиш, многу е тешко да добиеш точен одговор од AI.
Да не збориме дека кога станува проблем за покомплексни технички проблеми, може да се врти во круг и да не ти даде ништо. Пред некој месец имавме performance issues so МongoDB Search индекси. Ги дискутиравме со Мongo support тимот и плус со ChatGPT. Одговорите на ChatGPT беа донекаде ОК, објаснуваше каде настанува bottleneck-от, ама не можеше да понуди решение. Решението му беше, имајте помалце write операции. Или зголеми го cache-от на ниво на база за да имаш помалце roundtrips до диск (што уствари ќе има обратен ефект).

Друг случај се продукциски проблеми. Во тие случаи јас очекувам луѓето да го познаваат кодот и да можат брзо да донесат одлука кај може проблемот да биде. Тука познавањето на feature-ите, на кој начин се поврзани меѓу себе во кодот е критично.
Пример ако видиш дека имаш проблем со некоја пресметка, ама видиш дека друга пресметка (која е слична на првата) е ОК, одма можеш да го исклучиш заедничкиот дел и да се фокусираш на специфичниот код што го има првата пресметка.
Тука query-то наместо да ти биде:
"Бројките за пресметка Х не изгледаат добро, што може да е проблемот?"
Ќе ти биде
"Бројките за пресметка Х не изгледаат добро, но пресметките за Y се ОК. Игнорирај го заедничкиот код и фокусирај се на проблемите што можат да настанат специфично за X."
Со ова ќе добиеш фокусиран одговор наместо да трошиш 20 минути процесирајќи ги сите одговори што си ги добил со првото broad query.

Да не зборам за тоа дека познавањето на кодот ти помага да донесеш правилни одлуки во многу ситуации. Еве пример се дискутира некој голем feature со повеќе тимови, треба да се одлучи кој дел ќе се прави во кој тим. Кога добро го знаеш кодот и како се работите имплементирани, можеш во реално време да дискутираш импакт. Пример, логично е тим Х да го направи Y, но поради тоа што тим Z веќе има добра база за Y, може тим Z да го направи.

Не знам што би правел на вакви состаноци ако врска немам ништо како е имплементирано. Дали лесно може да се надогради, дали не. Дали ќе треба голем рефактор дали не. Точно е дека AI може да ти ја олесни оваа работа (и да ти ги имплементира промените) ама не е поентата да продуцираш 1000 линии код на ден кои никој нема да сака да ги ревјуира (и кои може многу повеќе багови да донесат).

 

[iMirisIUkus]

Ај тоа што добиваш прашања од други тимови за кодот и треба да знаеш како функционира, за да можеш да им објасниш што точно кодот прави сега, а што правел порано или што треба да прави во иднина. Што праиме ако после 6 месеца откако АИ ти изгенерирало нешто, се дешава баг и ти немаш поима ни што е изгенерирано, ниту каде е изгенерирано. И ќе го зјапаш кодот ко теле у шарена врата. Кога јас лично сум го напишал кодот, тоа останало во глава. Иако не го знам на памет доволно е да го видам за да знам зошто сум го ставил таму и да се сетам на ситуацијата која што довела до тоа. Треба барем да го разбереш кодот што ти го генерира АИ то. Полно кандидати ми доаѓаа со проекти на интервју каде не си го разбираат кодот што го напишале (АИ им го напишало) и зошто решението им работи или не им работи и автоматски таквите отпаѓаа.

 

[Емкаа]

Мислам дека AI буџетот нема врска со ова. Како што кажав, имаш проблеми кои AI-то не може да ти ги реши, а тоа не се должи на токени. Ако му дадеш пристап до сите можни системи (продукциски бази, периферни системи како kafka, redis, итн) тогаш можеби ќе го зголемиш бројот на проблеми што може да ги реши. Ама често пати, кога проблемите не се поврзани само со кодот на кој работиш, многу е тешко да добиеш точен одговор од AI.
Да не збориме дека кога станува проблем за покомплексни технички проблеми, може да се врти во круг и да не ти даде ништо. Пред некој месец имавме performance issues so МongoDB Search индекси. Ги дискутиравме со Мongo support тимот и плус со ChatGPT. Одговорите на ChatGPT беа донекаде ОК, објаснуваше каде настанува bottleneck-от, ама не можеше да понуди решение. Решението му беше, имајте помалце write операции. Или зголеми го cache-от на ниво на база за да имаш помалце roundtrips до диск (што уствари ќе има обратен ефект).

Друг случај се продукциски проблеми. Во тие случаи јас очекувам луѓето да го познаваат кодот и да можат брзо да донесат одлука кај може проблемот да биде. Тука познавањето на feature-ите, на кој начин се поврзани меѓу себе во кодот е критично.
Пример ако видиш дека имаш проблем со некоја пресметка, ама видиш дека друга пресметка (која е слична на првата) е ОК, одма можеш да го исклучиш заедничкиот дел и да се фокусираш на специфичниот код што го има првата пресметка.
Тука query-то наместо да ти биде:
"Бројките за пресметка Х не изгледаат добро, што може да е проблемот?"
Ќе ти биде
"Бројките за пресметка Х не изгледаат добро, но пресметките за Y се ОК. Игнорирај го заедничкиот код и фокусирај се на проблемите што можат да настанат специфично за X."
Со ова ќе добиеш фокусиран одговор наместо да трошиш 20 минути процесирајќи ги сите одговори што си ги добил со првото broad query.

Да не зборам за тоа дека познавањето на кодот ти помага да донесеш правилни одлуки во многу ситуации. Еве пример се дискутира некој голем feature со повеќе тимови, треба да се одлучи кој дел ќе се прави во кој тим. Кога добро го знаеш кодот и како се работите имплементирани, можеш во реално време да дискутираш импакт. Пример, логично е тим Х да го направи Y, но поради тоа што тим Z веќе има добра база за Y, може тим Z да го направи.

Не знам што би правел на вакви состаноци ако врска немам ништо како е имплементирано. Дали лесно може да се надогради, дали не. Дали ќе треба голем рефактор дали не. Точно е дека AI може да ти ја олесни оваа работа (и да ти ги имплементира промените) ама не е поентата да продуцираш 1000 линии код на ден кои никој нема да сака да ги ревјуира (и кои може многу повеќе багови да донесат).

Јас имам обратно искуство, со думп на логови и давање краток контекст за проблем распространет меѓу повеќе сервиси, успешно открива сегашни и идни потенцијални проблеми.
Апсолутно мора да се има некое техничко знаење, но не мислам дека треба да е толку софистицирано како досега, реалноста е дека сме многу лесно заменливи.
Лично мене не ми се допаѓа ваквиот шифт, ја зема цела креативност од работата. Но мора да се прилагодиме на новата реалност, доколку од мене се очекува да деливирам 5 нови бизнис иницијативи до крај на годинава, јас едноставно го немам истото време како порано да се замарам со детали, побитна е големата слика и се фокусираш таму.

Ај тоа што добиваш прашања од други тимови за кодот и треба да знаеш како функционира, за да можеш да им објасниш што точно кодот прави сега, а што правел порано или што треба да прави во иднина. Што праиме ако после 6 месеца откако АИ ти изгенерирало нешто, се дешава баг и ти немаш поима ни што е изгенерирано, ниту каде е изгенерирано. И ќе го зјапаш кодот ко теле у шарена врата. Кога јас лично сум го напишал кодот, тоа останало во глава. Иако не го знам на памет доволно е да го видам за да знам зошто сум го ставил таму и да се сетам на ситуацијата која што довела до тоа. Треба барем да го разбереш кодот што ти го генерира АИ то. Полно кандидати ми доаѓаа со проекти на интервју каде не си го разбираат кодот што го напишале (АИ им го напишало) и зошто решението им работи или не им работи и автоматски таквите отпаѓаа.

Според мене, моментално ( и во иднина ) ќе биде многу побитно да си добро запознаен со бизнис логиката, да бидеш на некој начин ТПО ( со поголем акцент на бизнис страната отколку на техничката страна ). Фокусот да биде на една поголема целина од сервисно ниво. Очекувањата на бизнисот се зголемуваат, до некаде и оправдано со оглед на цената на аи. Никој нема време да се занимава со непотребни коментари на ПР околу naming strategies и СОЛИД принципи, бидејќи како што пиша некој погоре, ретко кој остана да го чита кодот, покрај агентите.

 

[Menethil]

Ај тоа што добиваш прашања од други тимови за кодот и треба да знаеш како функционира, за да можеш да им објасниш што точно кодот прави сега, а што правел порано или што треба да прави во иднина. Што праиме ако после 6 месеца откако АИ ти изгенерирало нешто, се дешава баг и ти немаш поима ни што е изгенерирано, ниту каде е изгенерирано. И ќе го зјапаш кодот ко теле у шарена врата. Кога јас лично сум го напишал кодот, тоа останало во глава. Иако не го знам на памет доволно е да го видам за да знам зошто сум го ставил таму и да се сетам на ситуацијата која што довела до тоа. Треба барем да го разбереш кодот што ти го генерира АИ то. Полно кандидати ми доаѓаа со проекти на интервју каде не си го разбираат кодот што го напишале (АИ им го напишало) и зошто решението им работи или не им работи и автоматски таквите отпаѓаа.

Тотално небитно е што е изгенерирано и каде е изгенерирано. Треба да го знаеш проектот од функционален аспект и тоа да им го објасниш.

Ќе ти остане кодирањето за бутање на интервју и толку. Во иднина никој нема да те чека да разгледуваш код за да се сетиш пред 6 месеци што си напишал, кога АИ го наоѓа и кодот и контекстот за 5 минути.

Инаку верувам дека голем дел од вас си имате воспоставен workflow на рабоа и терајте така, ако газда ти вика да копаш со лопата, копај со лопата. Лично мислам дека ако не се приметиле драстична разлика во начинот на работа изминатите 2-3 години, боље размрдајте се малце. Доста од фирмите нема да те тинтраат веќе ко порано.

 

[Taker]

Мислам дека AI буџетот нема врска со ова. Како што кажав, имаш проблеми кои AI-то не може да ти ги реши, а тоа не се должи на токени. Ако му дадеш пристап до сите можни системи (продукциски бази, периферни системи како kafka, redis, итн) тогаш можеби ќе го зголемиш бројот на проблеми што може да ги реши. Ама често пати, кога проблемите не се поврзани само со кодот на кој работиш, многу е тешко да добиеш точен одговор од AI.
Да не збориме дека кога станува проблем за покомплексни технички проблеми, може да се врти во круг и да не ти даде ништо. Пред некој месец имавме performance issues so МongoDB Search индекси. Ги дискутиравме со Мongo support тимот и плус со ChatGPT. Одговорите на ChatGPT беа донекаде ОК, објаснуваше каде настанува bottleneck-от, ама не можеше да понуди решение. Решението му беше, имајте помалце write операции. Или зголеми го cache-от на ниво на база за да имаш помалце roundtrips до диск (што уствари ќе има обратен ефект).

Друг случај се продукциски проблеми. Во тие случаи јас очекувам луѓето да го познаваат кодот и да можат брзо да донесат одлука кај може проблемот да биде. Тука познавањето на feature-ите, на кој начин се поврзани меѓу себе во кодот е критично.
Пример ако видиш дека имаш проблем со некоја пресметка, ама видиш дека друга пресметка (која е слична на првата) е ОК, одма можеш да го исклучиш заедничкиот дел и да се фокусираш на специфичниот код што го има првата пресметка.
Тука query-то наместо да ти биде:
"Бројките за пресметка Х не изгледаат добро, што може да е проблемот?"
Ќе ти биде
"Бројките за пресметка Х не изгледаат добро, но пресметките за Y се ОК. Игнорирај го заедничкиот код и фокусирај се на проблемите што можат да настанат специфично за X."
Со ова ќе добиеш фокусиран одговор наместо да трошиш 20 минути процесирајќи ги сите одговори што си ги добил со првото broad query.

Да не зборам за тоа дека познавањето на кодот ти помага да донесеш правилни одлуки во многу ситуации. Еве пример се дискутира некој голем feature со повеќе тимови, треба да се одлучи кој дел ќе се прави во кој тим. Кога добро го знаеш кодот и како се работите имплементирани, можеш во реално време да дискутираш импакт. Пример, логично е тим Х да го направи Y, но поради тоа што тим Z веќе има добра база за Y, може тим Z да го направи.

Не знам што би правел на вакви состаноци ако врска немам ништо како е имплементирано. Дали лесно може да се надогради, дали не. Дали ќе треба голем рефактор дали не. Точно е дека AI може да ти ја олесни оваа работа (и да ти ги имплементира промените) ама не е поентата да продуцираш 1000 линии код на ден кои никој нема да сака да ги ревјуира (и кои може многу повеќе багови да донесат).

Надреално ми е вака кога читам на интернет кога кажуваат дека воопшто кодот не го читаат. Оставам простор дека сум имал лоши искуства со алаткиве или па дека не знам да ги користам. Друга варијанта е да станува збор за mediocre инженери или пак ги напинаат од менаџмент да туркаат features.

Имало многу случаеви каде што за многу едноставен проблем ми нудело комплексни решенија беспотребно, па требало да се разубедуваме. На PR имам гледано overengineered срања и неидиоматски код (React), некогаш дури поисплатливо ми било пешки да направам промени него да се разубедувам со агентот.
Disclaimer: Пешки код речиси и да не пишувам веќе.

Проблем со алаткиве е што кодот што го генерираат изгледа океј на прв поглед, техничкиов долг што се креира е многу различен од тоа претходно што се креираше. Кодот што го генерираат агентиве е на ниво на некој добар мид девелопер, некогаш overengineered и overoptimized, во однос на кодот на што се тренирани е океј, иако во даден контекст може да е непотребно. Затоа за мене добар инженер нема логика да си генерира само така.

Е сега, ако е идејата да се туркаат само features тогаш не ти ни требаат инженери, пуштај агенти паралелно и лепи код, ќе се накубури технички долг и тоа е тоа, имаше и порано фирми што го правеа ова, ништо ново освен со тоа што сега многу побрзо ќе избилдаат апликација.

Не планирам meat proxy да бидам, ни пак сакам да работам со колеги што се meat proxy.

 

[Dani]

Зошто во денешно време би отворил да гледаш како е искуцан некој feature?
Навистина ме интересира.
Кај нас иаме скоро неограничен буџет ( 500 долари е дневно мислам ), и кога ќе започнеш екстензивно да користиш АИ со ваков буџет, нема ни да имаш потреба од ИДЕ.
Апсолутно халуцинира во одредени моменти, ама 95% од времето е беспрекорно.

Зависи од сензитивноста на контекстот.
Не е исто да го оставиш да креира feature за букирање термин за нокти или feature за процесирање банкарски трансакции.

5% е многу голема стапка во вториот случај.

 

[iMirisIUkus]

Тотално небитно е што е изгенерирано и каде е изгенерирано. Треба да го знаеш проектот од функционален аспект и тоа да им го објасниш.

Ќе ти остане кодирањето за бутање на интервју и толку. Во иднина никој нема да те чека да разгледуваш код за да се сетиш пред 6 месеци што си напишал, кога АИ го наоѓа и кодот и контекстот за 5 минути.

Ахам, ако на мојов шеф за некој критичен баг почнам да му праќам аутпут од аи агент има у три лепе да ме отера. Едно е тоа, а ако ти работиш во токсична компанија кај што не ти даваат ни доволно време да дебагираш ко човек, тогаш не работиш на добро место. И трето, ко што кажав АИ то нема долгорочна меморија ко човекот (сеуште), така што да ти дадам пластичен пример. Се дешава при транскација на купец, од webhook от на пејмент процесорот да стигаат дупли реквести за една трансакција. Се прави фикс од страна на некој си девелопер кој работел на проектот и веќе не работи пошто го избркале од работа заради АИ и примиле вајб кодер за помала плата. Фиксот вклучува да се игнорираат дуплираните реквести ако стигаат во рок од 5 секунди. Нема никаква докуметација, ниту пак тестови напишани за АИ то да провери зошто таа логика постои и пошто на АИ то му фали контекст ја трга проверката. Резултат на тоа се две наплаќања кај еден купец за една трансакција.

Автоматски споено мислење: денес во 15:37

Јас имам обратно искуство, со думп на логови и давање краток контекст за проблем распространет меѓу повеќе сервиси, успешно открива сегашни и идни потенцијални проблеми.
Апсолутно мора да се има некое техничко знаење, но не мислам дека треба да е толку софистицирано како досега, реалноста е дека сме многу лесно заменливи.
Лично мене не ми се допаѓа ваквиот шифт, ја зема цела креативност од работата. Но мора да се прилагодиме на новата реалност, доколку од мене се очекува да деливирам 5 нови бизнис иницијативи до крај на годинава, јас едноставно го немам истото време како порано да се замарам со детали, побитна е големата слика и се фокусираш таму.


Според мене, моментално ( и во иднина ) ќе биде многу побитно да си добро запознаен со бизнис логиката, да бидеш на некој начин ТПО ( со поголем акцент на бизнис страната отколку на техничката страна ). Фокусот да биде на една поголема целина од сервисно ниво. Очекувањата на бизнисот се зголемуваат, до некаде и оправдано со оглед на цената на аи. Никој нема време да се занимава со непотребни коментари на ПР околу naming strategies и СОЛИД принципи, бидејќи како што пиша некој погоре, ретко кој остана да го чита кодот, покрај агентите.

Јас го читам сеуште. Ако не треба да го читам која е поентата да сеуште постојат фрејмворци, хај левел јазици, гит бранчови и сл? Све у асембли нека се генерира на мастер и директно пуш и деплој. Така е или не е така?

 

[Емкаа]

Зависи од сензитивноста на контекстот.
Не е исто да го оставиш да креира feature за букирање термин за нокти или feature за процесирање банкарски трансакции.

5% е многу голема стапка во вториот случај.

Работам во банка, баш во домејнот што процесира payments.

 

[Amaterasu]

Јас имам обратно искуство, со думп на логови и давање краток контекст за проблем распространет меѓу повеќе сервиси, успешно открива сегашни и идни потенцијални проблеми.
Апсолутно мора да се има некое техничко знаење, но не мислам дека треба да е толку софистицирано како досега, реалноста е дека сме многу лесно заменливи.
Лично мене не ми се допаѓа ваквиот шифт, ја зема цела креативност од работата. Но мора да се прилагодиме на новата реалност, доколку од мене се очекува да деливирам 5 нови бизнис иницијативи до крај на годинава, јас едноставно го немам истото време како порано да се замарам со детали, побитна е големата слика и се фокусираш таму.


Според мене, моментално ( и во иднина ) ќе биде многу побитно да си добро запознаен со бизнис логиката, да бидеш на некој начин ТПО ( со поголем акцент на бизнис страната отколку на техничката страна ). Фокусот да биде на една поголема целина од сервисно ниво. Очекувањата на бизнисот се зголемуваат, до некаде и оправдано со оглед на цената на аи. Никој нема време да се занимава со непотребни коментари на ПР околу naming strategies и СОЛИД принципи, бидејќи како што пиша некој погоре, ретко кој остана да го чита кодот, покрај агентите.

Муабетот ми беше, ако проблемот ти е од типот: Сервис А повикува Сервис Б преку ХТТП и имам грешка Ц, ако има пристап до двата кода, лесно ќе ти каже што е проблемот. Мислам дека сите се согласуваме тука. Ама ако Сервис А комуницира со Сервис Б преку Кафка и пораките ти каснат, тогаш нема да може да ти го реши проблемот. Ќе ти ги наброи сите можни решенија зошто можат пораките да каснат, ама ако не ти е врзан со конфигурацијата на Кафка, ако нема пристап до внатрешни логови (или пример дебуг логовите не ти се уклучени), тогаш ќе се мачи да ти го даде резултатот. И тука ти треба експертиза на девелопер да види уствари што е проблемот. Ако му речеш "solve the issue" ќе ти искуца еден куп код, ама дали стварно го решава проблемот?

И ова погоре ме носи до следново прашање.
Ако не го разбираш feature-от како е искуцан а решаваш bug во тој feature. Како знаеш дека кодот што ти го изгенерирал AI ќе го реши bug-от? Му веруваш целосно на неговиот output? Го тестираш некако?
Мислам одговорот е едноставен ако feature-ot е "send email". Ќе го провериш за 5 минути. Ама што ако feautre-от е некој scheduled job што се извршува 7-8 саати еднаш во денот?

Од тука ми доаѓа ставот дека не е проблемот АИ да го куца кодот, ама ако кодот не се прегледа и не се разбере 100%, тогаш ќе има проблеми.

 

[Menethil]

Надреално ми е вака кога читам на интернет кога кажуваат дека воопшто кодот не го читаат. Оставам простор дека сум имал лоши искуства со алаткиве или па дека не знам да ги користам. Друга варијанта е да станува збор за mediocre инженери или пак ги напинаат од менаџмент да туркаат features.

Имало многу случаеви каде што за многу едноставен проблем ми нудело комплексни решенија беспотребно, па требало да се разубедуваме. На PR имам гледано overengineered срања и неидиоматски код (React), некогаш дури поисплатливо ми било пешки да направам промени него да се разубедувам со агентот.
Disclaimer: Пешки код речиси и да не пишувам веќе.

Проблем со алаткиве е што кодот што го генерираат изгледа океј на прв поглед, техничкиов долг што се креира е многу различен од тоа претходно што се креираше. Кодот што го генерираат агентиве е на ниво на некој добар мид девелопер, некогаш overengineered и overoptimized, во однос на кодот на што се тренирани е океј, иако во даден контекст може да е непотребно. Затоа за мене добар инженер нема логика да си генерира само така.

Е сега, ако е идејата да се туркаат само features тогаш не ти ни требаат инженери, пуштај агенти паралелно и лепи код, ќе се накубури технички долг и тоа е тоа, имаше и порано фирми што го правеа ова, ништо ново освен со тоа што сега многу побрзо ќе избилдаат апликација.

Не планирам meat proxy да бидам, ни пак сакам да работам со колеги што се meat proxy.

За мене куцање код не е ништо инженерски, а голем дел од практиките беа чисто тупење и пред АИ. Но луѓе направија кариера од тоа. Муабетот за мид инженер (ете ја пример) ќе држеше вода ако и луѓето што ги воспоставија тие практики не ви го кажуваат истото.

Основа на инженерстовото е да ги користиш алатките на располагање, да не го измислуваш тркалото етц. Разбирам дека сатисфакцијата не е иста, ама сепак е работа. Го разгледувам кодот чисто за да иам осет, генерална слика. Ама АИ алатките куцаат подобар код и праат подетално ревју од 100 проценти од програмерите што сум работел.

Пред некое време мењав работа и ми беше фасцинантно кога видов лик како пешки куца прост таск цел ден и не му беше готов. Среќа или несреќа е што е у таква фирма, па тоа проаѓа. Но нема вечно да е така.

Автоматски споено мислење: денес во 15:51

Ахам, ако на мојов шеф за некој критичен баг почнам да му праќам аутпут од аи агент има у три лепе да ме отера. Едно е тоа, а ако ти работиш во токсична компанија кај што не ти даваат ни доволно време да дебагираш ко човек, тогаш не работиш на добро место. И трето, ко што кажав АИ то нема долгорочна меморија ко човекот (сеуште), така што да ти дадам пластичен пример. Се дешава при транскација на купец, од webhook от на пејмент процесорот да стигаат дупли реквести за една трансакција. Се прави фикс од страна на некој си девелопер кој работел на проектот и веќе не работи пошто го избркале од работа заради АИ и примиле вајб кодер за помала плата. Фиксот вклучува да се игнорираат дуплираните реквести ако стигаат во рок од 5 секунди. Нема никаква докуметација, ниту пак тестови напишани за АИ то да провери зошто таа логика постои и пошто на АИ то му фали контекст ја трга проверката. Резултат на тоа се две наплаќања кај еден купец за една трансакција.

Автоматски споено мислење: денес во 15:37

Јас го читам сеуште. Ако не треба да го читам која е поентата да сеуште постојат фрејмворци, хај левел јазици, гит бранчови и сл? Све у асембли нека се генерира на мастер и директно пуш и деплој. Така е или не е така?

1. По тоа што пишуваш на темава, не ми делува дека ја сум у токсичната фирма. Инаку не би ни сакал да ,,иам време,, за да дебагирам ко човек. Нејкам да решавам проблеми што се решени.
2. Delay и legacy. Ќе дојде и тоа набрзо.

 

[korokodildandi]

Работам во банка, баш во домејнот што процесира payments.

Аууу девојко фрлај тастатурата и копај бавча жити мене/

 

[Menethil]

Муабетот ми беше, ако проблемот ти е од типот: Сервис А повикува Сервис Б преку ХТТП и имам грешка Ц, ако има пристап до двата кода, лесно ќе ти каже што е проблемот. Мислам дека сите се согласуваме тука. Ама ако Сервис А комуницира со Сервис Б преку Кафка и пораките ти каснат, тогаш нема да може да ти го реши проблемот. Ќе ти ги наброи сите можни решенија зошто можат пораките да каснат, ама ако не ти е врзан со конфигурацијата на Кафка, ако нема пристап до внатрешни логови (или пример дебуг логовите не ти се уклучени), тогаш ќе се мачи да ти го даде резултатот. И тука ти треба експертиза на девелопер да види уствари што е проблемот. Ако му речеш "solve the issue" ќе ти искуца еден куп код, ама дали стварно го решава проблемот?

И ова погоре ме носи до следново прашање.
Ако не го разбираш feature-от како е искуцан а решаваш bug во тој feature. Како знаеш дека кодот што ти го изгенерирал AI ќе го реши bug-от? Му веруваш целосно на неговиот output? Го тестираш некако?
Мислам одговорот е едноставен ако feature-ot е "send email". Ќе го провериш за 5 минути. Ама што ако feautre-от е некој scheduled job што се извршува 7-8 саати еднаш во денот?

Од тука ми доаѓа ставот дека не е проблемот АИ да го куца кодот, ама ако кодот не се прегледа и не се разбере 100%, тогаш ќе има проблеми.

Идеата е да имаш пристап до МЦП на Кафка ( со ГЕТ пермисии), и да има контекст и за логови и за конфигурација. И нема да му напишеш pls solve, туку истражи, дефинирај ми проблем и предложи решение. Нема никаква разлика меѓу примерите, освен контекст и пермисии.

Автоматски споено мислење: денес во 15:57

Зависи од сензитивноста на контекстот.
Не е исто да го оставиш да креира feature за букирање термин за нокти или feature за процесирање банкарски трансакции.

5% е многу голема стапка во вториот случај.

Не мислеше дека тие 5% идат директ во продукција.