Flow Engineering: $50M para sa AI verification

Noong Setyembre 30, 2026, nakalikom ang Flow Engineering ng $50 milyong Series B sa $750 milyong valuation; pinangunahan nina Antonio Gracias ng Valor Equity Partners at Gavin Baker ng Atreides Management ang round, lumahok ang Sequoia Capital, at personal na namuhunan si Roelof Botha na sumali rin sa board. Kabilang sa mga pinangalanang customer ang Rivian, Anduril, Joby Aviation, General Motors PPU, RV Tech at Stoke Space. Para sa kumpanyang nakabase sa San Francisco, nakatuon ang bagong pondo sa software na sumusubaybay sa epekto ng mga pagbabago sa komplikadong hardware program.

Sa memo ni founder at CEO Pari Singh, isinulat niyang “Hardware engineering is next” at inilarawan ang Systems Engineering agents na sumusubaybay sa pagbabago sa CAD, Git, simulation at dokumento upang tukuyin ang epekto, conflict at requirement failure; layunin niyang paikliin ang development cycle mula buwan tungong araw. Ginagamit na ang agents sa aktuwal na hardware programs, ngunit ang pangkalahatang pag-ikli ng buong cycle sa antas na iyon ay layunin pa ng kumpanya.

Bakit pinopondohan ang hiwalay na verification layer

Nasa pagitan ng magkakaibang engineering tool ang problemang tinutugunan ng Flow. Maaaring nasa CAD ang disenyo ng isang bahagi, nasa Git ang pagbabago sa code, nasa simulation ang resulta ng pagsusuri, at nasa hiwalay na talaan ang requirements at test. Kapag may rebisyon, kailangang makita kung aling mga rekord ang umaasa sa naunang bersiyon. Kung hindi nasusundan ang ugnayang iyon, maaaring magpatuloy ang trabaho ng isang team gamit ang palagay na hindi na tugma sa bagong disenyo.

Inilalagay ng Flow ang agents sa ibabaw ng magkakaugnay na engineering record. Ang pangunahing trabaho nila ay maghanap ng mga dependency, magturo ng posibleng salungatan at ipakita kung aling requirement o test ang kailangang balikan matapos ang pagbabago. Ito ang dahilan kung bakit may hiwalay na halaga ang verification layer: hindi nito kailangang maging CAD tool, code repository o simulator upang maipakita ang epekto ng rebisyon sa mga ito.

Para sa manufacturer at enterprise-software buyer sa Pilipinas, mahalaga ang pagkakaibang iyon kapag maraming grupo at tool ang kasali sa iisang produkto. Ang pakinabang na ipinapangako ng platform ay ang mas malinaw na bakas mula sa binagong input hanggang sa pagsusuring apektado nito. Nakasalalay ang bisa ng ganitong daloy sa maayos na pagkakaugnay ng mga requirement, disenyo at test; kung may kulang sa rekord, kailangang makita at lutasin pa rin iyon ng engineering team.

Mula rebisyon sa CAD hanggang sa apektadong test

May kongkretong halimbawa ang paglalarawan ng Flow sa agents: sa isang demonstrasyon ng electric-vehicle powertrain, itinaas ang peak motor torque mula 380 Nm tungong 420 Nm, sinundan ang epekto sa motor housing at cooling jacket, at inihanda ang iminungkahing pagbabago sa hiwalay na branch para sa review ng engineer. Halimbawa ito ng daloy ng produkto, hindi iniulat na resulta mula sa isang customer. Ipinapakita nito kung bakit higit sa pagtukoy sa binagong file ang impact analysis: kailangang masundan ang mga bahaging umaasa sa bagong kondisyon.

Kapag requirement ang nagbago, maaaring kailanganin ding baguhin ang kaugnay na disenyo at suriin muli ang test coverage. Kapag CAD o software change naman ang naging panimulang input, maaaring bumalik ang pagsusuri sa requirement na dapat pa ring matugunan. Ang inilalabas ng agent ay mga apektadong ugnayan at mungkahing pagbabago na maaaring siyasatin ng tao. Hindi sapat ang simpleng pagtukoy na may bagong bersiyon; kailangang malinaw kung aling naunang ebidensiya ang maaari pang gamitin.

May mahalagang pagkakaiba ang pag-flag ng requirement failure at ang pinal na pagpapatunay sa isang disenyo. Maaaring makita ng software na nakatali ang test sa lumang bersiyon o may conflict sa magkakaugnay na tala. Ang pasya kung sapat ang bagong pagsusuri para sa aktuwal na produkto ay nangangailangan pa rin ng engineering judgment, lalo na kung may trade-off sa performance, kaligtasan o paraan ng paggawa.

Proposal ng agent, pag-apruba ng engineer

Sa daloy na inilalarawan ng Flow, maaaring magbukas ang agent ng branch, gumawa ng iminungkahing pagwawasto at ihanda ang epekto nito para sa review. Nananatili ang pangunahing engineering record habang hindi pa inaaprubahan ng tao ang pagsasama ng pagbabago. Nangangailangan din ng tahasang pahintulot ng administrator ang mga kakayahang magsulat sa system. May puwang, samakatuwid, para sa awtomatikong pagsusuri nang hindi awtomatikong nagiging pinal ang bawat mungkahi ng agent.

Mahalaga ang hangganang ito sa mga programang maraming bersiyon ng bahagi, requirement at test. Kailangang malaman ng reviewer kung saan nagsimula ang pagbabago, aling mga artifact ang naapektuhan at kung anong bagong pagsusuri ang kasama sa proposal. Kung malinaw ang bakas na iyon, mas madaling siyasatin ang isang rebisyon kaysa maghanap nang magkakahiwalay sa CAD, code at mga dokumento. Nasa engineer pa rin ang pananagutan sa pagtanggap o pagtanggi sa pagbabagong isasama sa pangunahing disenyo.

Customer proof at ang sukatan ng bilis

May bigat ang listahan ng mga pinangalanang customer dahil ginagamit ang Flow sa mga programang may magkakaugnay na pisikal na bahagi, software at mahahabang proseso ng pagsusuri. Ang pagkakaroon ng customer at ang paggamit ng agents sa aktuwal na programa ay magkaibang antas ng ebidensiya sa sinasabing pagbilis ng buong development cycle. Hindi pa ipinapakita ng mga inilathalang detalye ang pantay na paghahambing ng tagal ng magkakatulad na pagbabago bago at matapos gamitin ang agents.

Ang pinakamalinaw na sukatan para sa pangakong pagbilis ay ang oras mula sa unang rebisyon hanggang sa naaprubahang disenyo: kasama rito ang impact analysis, mga test na inulit at ang review ng engineer. Maaari kasing bumilis ang pagtukoy sa problema habang nananatiling matagal ang simulation, pagwawasto o pag-apruba. Sa ganitong datos malalaman kung gaano kalaki ang naitutulong ng agents sa buong proseso, bukod sa bilis ng unang pag-flag ng apektadong requirement.

Habang pinalalawak ng Flow ang review at branching capabilities nito, ang mga susunod na nailathalang resulta mula sa mga aktuwal na programa ang makapagpapakita kung nagiging mas maikli rin ang oras hanggang sa pinal na pag-apruba. Iyon ang magiging mahalagang pagkakaiba para sa mga team na bibili ng software upang mapabilis ang paggawa ng hardware nang napapanatili ang nasusuring ebidensiya sa bawat pagbabago.

Basahin din: