Sunt Ronan și conduc departamentul de Inginerie Software Cuantică la Equal1. Proiectăm și construim computere cuantice complet integrate folosind tehnologie avansată bazată pe spini. Equal1 are birouri în Irlanda, SUA, Canada, Japonia, România și Olanda, unde locuiesc. Înainte de aceasta, am lucrat la Qblox, o companie care produce sisteme de control cuantic.
La Equal1, mă concentrez pe construirea sistemului full-stack care rulează computerul nostru cuantic de înaltă performanță RacQ. Acest sistem este conceput să se scaleze la mii de qubiți corectați logic și chiar mai mult. Unii oameni îl numesc „creierul” procesoarelor cuantice (QPU).
Munca mea mi se pare fascinantă pentru că fiecare zi aduce ceva nou de învățat și am ocazia să lucrez cu colegi extraordinari și pricepuți. Am început acest blog pentru a împărtăși ceea ce am învățat; bineînțeles, fără a dezvălui niciun secret!
Nu ezitați să-mi trimiteți un e-mail la adresa ronan sau conectează-te pe LinkedIn dacă vrei să afli mai multe!
***Disclaimer: While I work at Equal1 by the day, this blog is a personal project and does not reflect the views of my employer. The thoughts, ramblings, and opinions shared here are mine alone and haven’t been vetted, approved or modified by anyone but myself.
***Arhitectura sistemului pe scurt
Link to heading
În perioada în care am lucrat la Qblox, rolul meu a fost cel de arhitect de sistem. Mai jos este o notă despre rolul pe care l-am deținut atunci.
Aceasta este o întrebare pe care o primesc destul de des: Ce se așteaptă mai exact să facă un arhitect de sistem (sysarch)? Răspunsul variază în funcție de companie, țara de operare și domeniul de activitate. Totuși, un concept rămâne constant: Comunicarea
Da, rolul arhitectului este de a comunica idei complexe în mod simplu, fie echipelor de dezvoltare și inginerie, directorilor executivi sau clienților. Totul începe cu înțelegerea problemei cu clientul și echipa de produs, ceea ce este o parte interesantă a rolului: crearea unei soluții care să-l facă pe client fericit!
De acolo vine analiza tradițională a cerințelor de sistem și, adesea, o fază de prototipare pentru demonstrarea conceptului, în care de obicei particip direct. După aceea, urmează dezvoltarea produsului, unde acționez ca lider tehnic, lucrând cu echipe interfuncționale până când produsul este gata. În cele din urmă, vine service-ul produsului post-lansare.
Cum iau o decizie arhitecturală? Rolul arhitectului nu este neapărat să decidă, ci mai degrabă să încadreze problema prin consolidarea informațiilor necesare pentru luarea unei decizii. De exemplu, echipa de produs („cât costă dezvoltarea acestui nou produs? care este timpul de lansare pe piață?”) sau echipa CxO („dorim să investim în această nouă tehnologie? Care este rentabilitatea investiției și strategia pe termen lung?”).
Este vorba despre a fi cartesian, cercetând și definind avantajele și dezavantajele fiecărei soluții posibile, fără judecăți subiective. De asemenea, este vorba despre evaluarea costului versus beneficiul, luând în considerare nu doar efortul de implementare, ci și întreținerea pe termen lung, costurile operaționale și încărcarea cognitivă a echipei.
Mai important, este vorba și despre negocierea alinierii sociale, deoarece orice decizie de arhitectură pe care inginerii o urăsc sau managerii de produs nu o înțeleg va eșua. Luarea unei decizii înseamnă a-i atrage pe oameni în această călătorie. Pentru ciclul de Produs și Afaceri, asigurați-vă că alegerea oferă valoare de afaceri. Pentru ciclul de inginerie, solicitați critici din partea inginerilor seniori, astfel încât aceștia să fie responsabili pentru execuția acesteia.
Aceasta este o întrebare recurentă pentru toate companiile care dețin un produs software: De ce și când ar trebui să refactorizăm? Este comun să credem că atunci când produsele existente sunt lente și instabile și durează prea mult să remediem problemele datorate datoriilor tehnice acumulate, este timpul să refactorizăm. Dar răspunsul nu este întotdeauna cel corect; în schimb, rolul arhitectului este de a preveni [efectul] al doilea sistem (https://en.wikipedia.org/wiki/Efectul_al_secundului_sistem)
Filosofia mea personală este să aplic deciziile din prima zi și să le verific în raport cu testul „ușii bidirecționale”: refactorizarea este o ușă unidirecțională (aproape imposibil de inversat, cum ar fi alegerea unei paradigme de bază de date primară) sau o ușă bidirecțională (ușor de modificat ulterior, cum ar fi o alegere de bibliotecă internă)? Ușile unidirecționale necesită o validare profundă; ușile bidirecționale necesită viteză.
Pe scurt, rolul sysarch-ului este și de a promova cultura inginerească adecvată, care să creeze valoare atât pentru echipele de inginerie (mai puține intervenții de stingere a incendiilor), cât și pentru echipele de produs (lansare pe piață mai rapidă).
Deși ideea generală este să investești acum în setul tău de inginerie/software pentru a economisi timp mai târziu în dezvoltare, adevărata provocare este să găsești echilibrul potrivit între investiții și supra-inginerie: dezvoltă instrumentele și componentele software potrivite pentru a facilita dezvoltarea și întreținerea produselor, mai degrabă decât să supra-inginerezi ceva ce nu adaugă valoare.
Aceasta înseamnă, de asemenea, ca arhitectul să comunice frecvent cu echipele de produs și cu cele de nivel C pentru a promova munca echipelor care își investesc eforturile în inginerie adecvată, pregătită pentru viitor, în loc să se ocupe constant de combaterea incendiilor.
La un moment dat, refactorizarea sistemului nu mai este suficientă, deoarece intră în joc Legea lui Conway: „Orice organizație care proiectează un sistem va produce un design a cărui structură este o copie a structurii de comunicare a organizației.”
Răspunsul nu este întotdeauna de a muta oamenii, ci mai degrabă de a realinia rezultatul echipei cu organizația afacerii, astfel încât suma celor două echipe să fie mai mare decât suma părților lor. Dacă o echipă nu creează suficientă valoare deoarece structura sa de comunicare este ineficientă, creați un sistem în care rezultatul echipei este definit de componente mai bune și promisiuni API care oferă mai multă valoare afacerii. Și dacă echipa nu reușește să creeze componente noi, împărțiți munca în componente mai simple, cu promisiuni API mai directe.
Dar, mai important, este vorba despre promovarea alinierii sociale între echipă și organizație: imaginați-vă o companie în care echipa se schimbă pentru a crea mai multă valoare. Nu ar fi aceasta situația ideală?
Cum mi-a schimbat inteligența artificială modul în care lucrez? Foarte mult! La fel cum dezvoltatorii fac vibe-coding, arhitecții trebuie să fie mai buni la scrierea de „design-uri vibe” (precum și a cerințelor de sistem vibe) care pot fi introduse direct în LLM-uri ca date de intrare pentru a produce cod.
Inteligența artificială este de mare ajutor atunci când se iterează designul, deoarece poate genera rapid multe variante ale aceluiași design, permițând explorarea mai rapidă a diferitelor opțiuni. Aceste designuri pot fi apoi rapid prototipate pentru a verifica ipotezele și complexitățile dezvoltării.
Dar, mai important, este esențial să ne amintim că IA nu este aici pentru a înlocui inginerii, ci pentru a le spori capacitățile și creativitatea. Este un instrument menit să îmbunătățească procesul de proiectare, mai degrabă decât un instrument care să înlocuiască judecata și expertiza inginerească.
De exemplu, verificați diagrama de mai jos: Câți LLM vă vor spune că diagrama din dreapta arată o eroare pe qubitul 3 ( Z₂Z₃ ), în timp ce de fapt este o eroare bizantină pe qubiții 1 și 2? (explicații complete)
***