Programming is the conversion of ambiguous human requirements into machine readable instructions. To automate, computers would need to understand ambiguous human requirements. This is AGI.
Mix mortar to the consistency of mashed potatoes and apply gently but thoroughly to two faces of a heavy, but brittle object, then place that brick into a corner with both faces with applied mortar of even thickness touching receiving faces at the same time, no lateral sliding. Press the brick gently into the corner and tap, making sure that it lines up perfectly vertically with a string line and horizontally with the other bricks, then wipe off excess mortar, creating a visually appealing groove, all while standing on a muddy slope. Best of luck, robots.
Brick laying robots already exist. This isn't a problem that can't be solved, it's a question of making it economically viable.
But the future is pretty obviously going to be skilled machinery operators overseeing the automation.
Even more interesting its once you automate like this the constraints start changing: i.e. it's easier to have a robot lay bricks with epoxy then cement, whereas a non automated work flow would struggle.
There's a Perth based company which has a prototype which basically will layout an entire house on a concrete slab via a boom arm that uses this approach: pallets go in, structured bricks come out.
Yes, that system is discussed in the article, and it looks like it doesn't work very well. I doubt it can keep up with human labor.
I agree. It will happen eventually, but the bigger point here that is more related to to discussions on HN is that despite a lot of enthusiasm, machine learning and AI are still in the amino acid phase of evolution, and everything still sucks.
It doesn't have to keep up with human labor, it just has to reduce the total amount of human labor. And slow today doesn't mean slow tomorrow. The residential dishwasher is a great example of this.
> Yes, that system is discussed in the article, and it looks like it doesn't work very well. I doubt it can keep up with human labor.
It works poorly, therefore bricklaying has been automated. The programmers won. The bricklayers won too. It's only Grakel with his weird bet that lost.
You can mention these same difficulty of tasks for soda can manufacture or a dozen other how its made videos. And yet, a lot of those processes that are just as complicated as brick laying, have been automated by robots.
Key difference: you deploy a soda can robot in a factory. You have an enclosed environment with all of your inputs nicely set up.
For robot bricklaying, you can depend on the electrical supply. Everything else is a toss-up. I do think it's possible, but you don't choose your working environment or the weather conditions so everything is gonna be a lot more hassle.
This plays exactly into the OP's comment - but if that is your sincerely held belief there are ~4,000 bricklayers~[1] in America today and you could make a whole boatload of money if you could automate their work.
1. According to the BLS link below it's actually closer to 50,000.
No one is even thinking about trying to completely automate coding.
There's tons of "no code" solutions - but these are all just different versions of coding and programming languages - usually with GUIs and pictures instead of words.
There's more than 60,000 SWEs that work in my company. Amazon, Google, Apple, and MSFT could make >$10Bn/year each if they could automate coding.
The fact that none of them are even trying - when it sort of goes with their core businesses - should give you some indication that this is something unlikely to be automated any time soon.
The reason bricklaying ISN'T automated is probably because there's ONLY 59,000 bricklayers in the US (a $3B market), it's not generalizable, and even if it was - the cost to move a machine, set it up, and maintain it - it's hard to imagine massive cost savings - 50% seems generous.
If there were >1M bricklayers - and/or they made >$400k/year on average, the work was generalizable, and automating would bring huge cost-savings that could be captured - there would be a LOT more effort into automating bricklaying.
But none of these are true. How much of brick laying is generalizable (building a new house) vs custom (repairing some old wall with non-standard bricks)? I have no idea - but I'm guessing not a lot more than 50%. That's a $1.5B market. You'd be luck to cut the costs by 50% - that's maybe $750M.
It could easily cost more than than to automate bricklaying! Why even try?? No one is interested in investing in that risk / reward.
On the contrary - most of Radiology could be automated and most of it is generalizable. Since hospitals are monopolies and healthcare is a mess - you might be able to capture all the cost savings - which would be close to 100%!
Since there's ~35k Radiologists, and they're some of the highest paid workers in the world - there are a lot of efforts to actually automate this (and they're doing quite well).
If you think automating radiology is easier than building a hamburger-cooking robot, you're naive. If you think AGI is easier to achieve than building a tomato-harvesting machine, you're clueless.
There's just simply not hundreds of billions to be made automating cooking hamburgers and harvesting tomatoes more efficiently. And it's not easy to generalize and automate cooking or harvesting EVERYTHING. And even if there was, restaurants and groceries are commodities - not monopolies. You couldn't capture all the savings. A race to the bottom on prices would eventually just pass the savings on to the customer - not juice profits. That's not something you want to spend massive, risky R&D on. That's why we haven't automated cooking hamburgers and harvesting tomatoes. Not because it's harder than protein folding, fusion energy, or true AGI...
From another point of view - we've had machines that mop floors for decades - and there's still a lot of people employed to mop floors. Is this because mopping floors is incredibly complex and creative? No - it's because people who mop floors get paid minimum wage, and they do a lot of other things, too.
No code still has a bit to go. It's main focus right now is having a model and can generate a UI and have a method to update a database. When you get into the weeds of what companies want, it's that person in group A is allowed to update, group B can create things, and group C can only view. And on top of that there is private stuff that only the same user can see. It's that shit that makes no-code a non-starter for Google, Amazon, ...
Perhaps a company that wants to display the current Bitcoin price on a screen and let you do currency conversions you can do that in "no code", but then again, a programmer can also do that with code in 15 minutes...
I imagine this goes for most skilled trades jobs. The lack of generalizability becomes apparent every time I undertake a DIY project that doesn’t go as planned
As a tradesperson myself, working in a highly automated part of the metal fabrication process, I feel an urge to say something like:
The only thing standing between a programmer and unemployment is a sufficiently advanced compiler
But only because I great contempt for the hubris on display in these sorts of threads.
At the end of the day though, it's a-little-bit-form-column-A-and-a-little-bit-from-column-B.
We went from not-flying to landing robots on another planet in a handful of decades, who knows what a little bit more processing power and a few more layers of abstraction could bring.
Printing works really well. It's print drivers (software) that are an utter and complete mess.
I've never had a printer that didn't work: I've had plenty that wanted the correct offering to the HP website to be made and several hundred megs of adware installed before a postscript file made it to the actual hardware.
Nonsense. If you could automate programming, it would be the last thing to truly be automated before the singularity. After all, if programming was truly automated, the program for creating a brick laying robot would write itself.
