If you're building a home lab, you might just give up because you are tired of searching for Cisco router syntax.
LLM can be the little bit of lube you need to understand things at a higher level, because the tedious things are not as bad as they used to be.
You then end up actually getting a few things in your lab to work correctly, get a confidence boost, and follow up with some searches about how routing actually works and why the syntax is the way it is.
The stochastic parrots thing is already old. It might have made sense at one point, but now that the parrots are solving millennium problems, I think people have to admit things have changed.
He is right that the AI giants would like a bit of regulatory capture.
It can still be stochastic over more complex token graph traversals, but it is still stochastic at the core. Anyone who uses them daily knows how often they make the most absurd assumptions and false statements, and show the limit of engineered intelligence
If the parrot randomly yaps out a solution to an open math problem, it's a useful parrot.
The fact that it sometimes says things that aren't useful, well, old intelligence does that all the time.
If you've used AI recently, you can't avoid having found it useful. Just general day-to-day intelligence like finding things in your email, writing code for you, that kind of stuff, it does well. People have some weird hangups about it being stochastic, when it doesn't really matter.
yes, the spaghetti throwers (current training regime) sometimes hit the mark quite well, but they also do some of the dumbest things, reinforcing to the stochastic nature of their construction.
If it were me, I would start by getting a summary of what problems the existing solution solves. I would also make sure that summary had the non-functional requirement. Maybe write a test suite that opens the page and does all the stuff.
Then ask the LLM to implement in another language, with those solutions in mind, but first coming up with reasons why the target language might not be as good, and where it might have useful features that the original language didn't. Use the test suite to check if things are working.
I honestly don't think you would land far away. You would have to answer a few questions along the way, but it would mostly be plain sailing.
I would expect to be able to do this with very little human attention, whereas a language rewrite two years ago might take a whole month, not including learning the new language.
You're contradicting yourself, how can it be unique if only 1000 can be assigned per given date of birth? What if more than one thousand babies are born in the country one day?
There have been collisions in Sweden, but that was due to lots of immigrants coming from the middle east that did not know when they where born. So many of them picked first of January. They “solved” it by overflowing to the next days.
They said sex is encoded in it, so it’s probably a sex digit.
edit: I was wrong. Wikipedia says, “The first digit of the sequence number encodes the century of birth (so that centenarians are distinguished from infants)”.
It also says “the last digit of the sequence number is odd for males and even for females”. What a strange system. Essentially the last three digits are two different sequences made to look like one.
I had a chat today with a friend about this. I think my working thesis is that AI is bad news for outsourcing/offshoring.
What was it good for? Well, often it was prompting a person in a low-cost location what code to write. He would pick it up in his timezone and implement it overnight, and present findings/questions as a response.
The problem is, coding has made implementation super cheap. It is now so cheap you have to compare it to the cost of dealing with someone in another timezone, who does not have the same cultural context on the problem. They also can't ask you clarifying questions while you're asleep. AI wins against the offshore guy, on both money and context.
Who does it help? Amazingly, the experienced onshore dev who thought he was going to be unemployed past 40. This person is now able to implement several things concurrently, has experience in making technical decisions, and has local cultural context.
> First, if you crack open a history book (or have an agent do it for you), you'll notice that the world goes backwards quite often.
The only thing I can think of is the reduction of truffles as an ingredient, which apparently happened around WWI. We eat a lot fewer of them than before.
> Second, I'm really curious what's your "adapt" path, because I suspect you're in denial too. Accept that, before long, an LLM will not need you to write good prompts, tell it to "keep going", or say "no, that's wrong". What's your value then? Does your employer keep you on the payroll as charity? For old times' sake? If your value is just supervising AI, then your value is declining rapidly.
Your employer cannot talk to all the LLM sessions at the same time. He also can't write a prompt that will do it for him.
> People in unskilled professions don't have choice when automation shows up and takes their jobs. Software engineering may go down in history as one of the few highly skilled professions that didn't just keel over and die, but enthusiastically embraced its own demise.
It's changed several times over the decades. How many people are working on a mainframe nowadays? How many people are writing assembly? Look at how many languages have come and gone too. LLM is a big change, but that doesn't mean software people will be gone.
A year ago, I asked ChatGPT to design me a 3D model for a wallet, the kind you can stick to the back of a phone with a magnet. It screwed it up over and over, never got to anything usable.
Last week I tried again, just explaining in words what to do, and it made what I had in my mind.
For websites, it's over. Any kind of brochure/simple restaurant booking site, that was easy years ago and trivial now. SaaS is going next, of course there's a lot of types of SaaS but your average "web implementation of commonly needed service" is now very easily copied with AI.
Anything like a task list or information management system with no particular constraints in terms of performance or scale, you can just make an AI customize for you.
I think for most things by far, product is king. If you're in a deep tech space, then no. Perhaps if you're making rockets, or compilers. But most other things become "make some engineering judgements about what we need to build, based on what the business side is asking for".
Now, it was already like that to an extent. To be crude, the job was "decide what needs to be made, and make it". People would be on various splits between the two, typically on the "make it" end if they were junior.
Initially, I thought about what effect this would have on hiring. Perhaps we would get a lot more people who were not so great at implementation, since we are hiring for judgement?
Let's consider Berkson's paradox.
Let's say that there's a correlation between implementation skill and engineering judgement, eg r=0.5, a rugby-ball shaped cloud that points up and to the right. The basis for this being that you maybe learn good judgement from implementing things, something like that.
Before AI, selection on the sum scores (judgement + implementation) would give you a set of engineers whose correlation was deflated from the underlying correlation. It could even go negative (in fact it would if the underlying correlation was zero, but we assumed it was positive). This is the original Berkson's paradox, selection makes the correlation coefficient lower. There would be less of a connection between someone's (who had been hired) judgement and implementation skill than 0.5, it would tend downwards, possibly landing at zero.
Now, let us imagine that AI means the implementation side becomes less important. We will veer towards hiring people based on engineering judgement, rather than coding skill. Suppose we add a parameter on (judgement + lambda * implementation).
What actually happens is, if lambda tends towards zero, we are selecting on a line that is only judgement. But that means actually, the deflating effect of the selection is lowered, and we get a correlation between our variables that is closer to the underlying set (it won't necessarily be all the way back, since we restrict the range).
So then actually, somehow, people we hire who are good at judgement will also be good at implementation. Somewhat unexpected.
If you're building a home lab, you might just give up because you are tired of searching for Cisco router syntax.
LLM can be the little bit of lube you need to understand things at a higher level, because the tedious things are not as bad as they used to be.
You then end up actually getting a few things in your lab to work correctly, get a confidence boost, and follow up with some searches about how routing actually works and why the syntax is the way it is.
reply