I think the takeaway is that we have to think bigger, much bigger, now that AI coding is essentially "solved". Anyone can "write" an ARM simulator now, so that can't be the pinnacle of engineering. I'm thinking about buildings that couldn't be built (reasonably) by one person.
I'll give an example of what I'm working on. There's a model for segmenting organs from CT scans. There's another model for calculating radial diameters of blood vessels from CT scans. You can combine the two and approximate how much blood flow each organ gets based on its segmented volume and the sum total radial diameter of vessels feeding it. You can then render all of that in an app that shows perfusion to that organ.
The idea is to combine these models to extract every ounce of usable information from a CT scan that might be useful for procedural planning (I'm an interventional radiologist). While each algorithm would take weeks/months to implement, Opus 5.5 can do them in minutes to hours and then stitch them together. The results thus far have been better than anything I've seen.
As a EE by trade, AI coding has been life changing. I can read code, but since it's not my day job, trying to get a meaningful understanding of multiple codebases is frankly weeks of time.
I no longer have to beg and plead the SW team to implement driver fixes or feature ads; I can freakin' do it myself.
Likewise, being able to explore e.g, a new vision algo piped directly into the software stack allows for setting up a demo in an afternoon.
I try to stay very cautious, and thoughtful prompting / checkpointing / getting it to first search for similar PRs as a guide have helped make sure it stays 'boring' and doesn't break architecture.
> As a EE by trade, AI coding has been life changing
Waiting for
As a SWE by trade, AI hardware design has been life-changing...
As a former engineer (now Uber driver) by trade, AI hardware and software design have been life-changing...
aabajian · · focus · HN ↗
I'll give an example of what I'm working on. There's a model for segmenting organs from CT scans. There's another model for calculating radial diameters of blood vessels from CT scans. You can combine the two and approximate how much blood flow each organ gets based on its segmented volume and the sum total radial diameter of vessels feeding it. You can then render all of that in an app that shows perfusion to that organ.
The idea is to combine these models to extract every ounce of usable information from a CT scan that might be useful for procedural planning (I'm an interventional radiologist). While each algorithm would take weeks/months to implement, Opus 5.5 can do them in minutes to hours and then stitch them together. The results thus far have been better than anything I've seen.
hex4def6 · · focus · HN ↗
I no longer have to beg and plead the SW team to implement driver fixes or feature ads; I can freakin' do it myself.
Likewise, being able to explore e.g, a new vision algo piped directly into the software stack allows for setting up a demo in an afternoon.
I try to stay very cautious, and thoughtful prompting / checkpointing / getting it to first search for similar PRs as a guide have helped make sure it stays 'boring' and doesn't break architecture.
So far, I haven't been bitten... :)
musicale · · focus · HN ↗
Waiting for
> So far, I haven't been bitten... :)jmalicki · · focus · HN ↗
MajorTakeaway · · focus · HN ↗
[deleted] · · focus · HN ↗
[deleted]