Until counting machines got ubiquitous, banks in India would count notes/bills by weight as well.
It wasn't very precise but you could move a lot of money in ball park with this method. Atleast internally across branches.
13,747 karma · joined April 15, 2011
It wasn't very precise but you could move a lot of money in ball park with this method. Atleast internally across branches.
If you had a chat with me through lunch on some technical intensive questions, It would be a breeze. I could not only answer them, I could list limitations, how to address them, and I could even come with a working plan on how I could get it done.
Do the same in an interview, I will freeze.
There are ripped men in prison.
>>That requires intrinsic motivation
How do you make some one do a thing, they don't want to do?
1)
What he means to say is, say you needed to get something done. You could ask AI to write you a Python script which does the job. Next time around you could use the same Python script. But that's not how people are using AI, they basically think of a prompt as the only source of input, and the output of the prompt as the job they want get done.
So instead of reusing the Python script, they basically re-prompt the same problem again and again.
While this gives an initial productivity boost, you now arrive at a new plateau.
2)
Second problem is ideally you must be using the Python script written once and improve it over time. An ever improving Python script over time should do most of your day job.
That's not happening. Instead since re-prompting is common, people are now executing a list of prompts to get complex work done, and then making it a workflow.
So ideally there should be a never ending productivity increase but when you sell a prompt as a product, people use it as a black box to get things done.
A lot of this has to do with lack of automation/programming mindset to begin with.
For your proposed system to work one must have a deterministic way of sending said spec to a system(Compiler?) and getting the same output everytime.
Input/Output is just one thing, software does a lot of 'side effect' kind of work, and has security implications. You don't leave such things to luck. Things either work or don't.
You mean to say if the unit and functional tests cases are given the system must generate code for you? You might want to look at Prolog in that case.
>>Might be quite awhile before you can do this with large systems but we already see this on smaller contextual scales such as Claude Code itself
We have been able to do something like this reliably for like 50 years now.
Once you do have a billion dollar product protecting it requires spending time, money and people to keep running. Because building a new one is a lot more effort than protecting existing one from melting.
The thing to note is, verifying if something got done is harder and takes time in the same ballpark as doing the work.
If people are serious about AI productivity, lets start by addressing how we can verify program correctness quickly. Everything else is just a Ferrari between two traffic red lights.
Competitive coding is oversold in this generation. You can log in to most of these sites and you will see thousands of solutions submitted to each problem. There is little incentive to reward situations where you solved some problem which a thousand other people have solved.
To that end its also a intellectual equivalent of video game addiction. There is some kind of illusion that you are indulging in a extremely valuable and productivity enterprise, but if you observe carefully nothing much productive actually gets done.
Only a while back excessive chess obsession had similar problems. People spending whole days doing things which make them feel special and intelligent, but to any observer at a distance its fairly obvious they are wasting time and getting nothing done.
I mentioned this part in my comment. You cannot trust an automated process to a thing, and expect the same process to verify if it did it right. This is with regards to any automated process, not just code.
This is not the same as manufacturing, as in manufacturing you make the same part thousands of times. In code the automated process makes a specific customised thing only once, and it has to be right.
>>The problem is those systems weren't built for LLMs specifically so the unexpected failure cases ...
We are not talking of failures. There is a space between success and failure where the LLM can go into easily.
So that only goes some distance and then you face new limitations.
I think the point he is trying to make is that you can't outsource your thinking to a automated process and also trust it to make the right decisions at the same time.
In places where a number, fraction, or a non binary outcome is involved there is an aspect of growing the code base with time and human knowledge/failure.
You could argue that speed of writing code isn't everything, many times being correct and stable likely is more important. For eg- A banking app, doesn't have be written and shipped fast. But it has to be done right. ECG machines, money, meat space safety automation all come under this.
One of things that's being discussed now is AI won't really help people ship products faster, because no one was serious about building them at the first place. In most large corps the managerial layers simply care about preserving their own jobs and comp.
Also similar things an be said about Product management too. Only a few months they would says developers are busy with other things, now that we can ship quite fast, whats your world changing idea? None
That is the best case scenario. Mostly women roll beedis(a kind of needle sized cigar) on which you get like 1 paise per 10 rolls or something like that. Or worse do assorted labor chores which can really sap one's soul real fast.
Even with all that women actually have it a lot better than men. Men literally die and are reborn every day in most parts of India.
Just drive 30 kms North of Bangalore, and you will see abject poverty scenes. People scavenging bovine dung for fuel, children with flies, no clothing. The ever present scene is always that of an elderly person with pencil thin legs wearing shorts he likely is wearing since a decade with nothing but boiled rice and salt water+turmeric to eat daily. 8 - 10 hr power cuts are the norm, that is if you can afford electricity at all. Most health care is either entirely absent, or you have to travel to the nearest metro and hope you don't die out of hunger getting treatment there. I could go on but that is life here.
£260 a month is actually great for some place like this.
1. Take a pen and paper.
2. Write down what we know.
3. Write down where we want to go.
4. Write down our methods of moving forward.
5. Make changes to 2, using 4, and see if we are getting closer to 3. And course correct based on that.
I still do it a lot. LLM's act as assist. Not as a wholesale replacement.
On the similar lines, why can't one run a refrigerator in space?
I keep telling my friends while experienced devs feel extremely productive. The newer ones will likely not develop skills needed to work with finer aspects of code.
This might work for a while, but you do a year or two of this, and then as little as a small Python script will feel like yak shaving.
You can play around with words as much as you can, but Musk even with a very high rate of failure seems to be making a lot of things work.
That's what asteroid mining is for.
>>service technicians are necessary ALL THE TIME
Optimus is already very well tele-operated. Even though over time it can likely be trained to do specific tasks far better than even humans.
AI's biggest feature is being able to ask it question and not getting humiliated and judged in the process.
More terse the better.
Thats again programming languages. Real issue with LLMs now is it doesn't matter if it can generate code quickly. Some one still has to read, verify and test it.
Perhaps we need a need a terse programming language. Which can be read quickly and verified. You could call that specification.
>>The people who dealt with Prolog on punchcards were the academics who created and/or refined it in its early days. [0]
That's like a decade of work. Thats hardly early 'days'.
Also the programming culture in the PC days and before that is totally different. Heck even the editors from that era(eg vi), are designed for an entirely different workflow. That is, lots of planning, and correctness before you decided to input the code into the computer.
Even then PC use in businesses was fairly limited.
Prolog appeared in 1972.
Either way before the PC, Programming was nothing like it is today. It was mostly a Math discipline. Math is done on paper.
Its not iterative refinement which is bad. Its just that when you use a keyboard a thinking device, there is a tendency to assume the first trivially working solution to be completely true.
This is doesn't happen with pen and paper as it slows you down. You get mental space to think through a lot of things, exceptions etc etc. Until even with iterative refinement you are likely to build something that is correct compared to just committing the first typed function to the repo.
One can imagine how development would work in a ecosystem like that. You have to understand both the problem, and your solution, and you need to be sure it would work before you start typing it out at a terminal.
This the classic Donald Knuth workflow. Like he is away disconnected from a computer for long periods of time, focussed on the problems and solutions, and he is working them out on paper and pen. Until he has arrived solutions that just work, correctly. And well enough to be explained in a text book.
When you take this away. You also take away the need to put in hard work required to make things work correctly. Take a look at how many Java devs are out there who try to use a wrong data structure for the problem, and then try to shoe horn their solution to roughly fit the problem. Eventually solution does work for some acceptable inputs, and remainder is left to be discovered by an eventual production bug. Stackoverflow is full of such questions.
Languages like Prolog just don't offer that sort of freedom. And you have to be in some way serious about what you are doing in terms of truly understanding both the problem and solution well enough to make them work.
I think much of the frustration with older tech like this comes from the fact that these things were mostly written(and rewritten till perfection) on paper first and only the near-end program was input into a computer with a keyboard.
Modern ways of carving out a program with 'Successive Approximations' with a keyboard and monitor until you get to something to work is mostly a recent phenomenon. Most of us are used to working like this. Which quite honestly is mostly trial and error. The frustration is understandable because you are basically throwing darts, most of the times in the dark.
I knew a programmer from the 1980s who(built medical electronics equipment) would tell me how even writing C worked back then. It was mostly writing a lot, on paper. You had to prove things on paper first.
Can't blame him, US residency really is a like a game of high attrition. Its your classic up or out scenario.
Some times even a passport doesn't guarantee a stay. Sooner or later, you fall ill, lose a home, have a divorce. Its a unique combination of extreme luck, work, health and many other factors several of which are totally outside of your control.
You either win spectacularly or exit trying.