Question: Does anybody here yet personally has less (to) work 'cause of AI?
When lawyers and writers are talking to me about "docker containers" and "agents" I assure you that the amount of code out there is going to grow.
But it's at my day job, and it's because I was able to write a prompt which automates having Copilot review uploaded scanned PDFs of invoices with checks (and the bank line obscured with a pen, so no PII) and then write a batch file which renames the files per a file-naming convention, removing the need to open them in batches of 50, find the Invoice ID, re-save using that filename, then quit and re-launch Adobe Acrobat (if left running, eventually I run into a bug where it stops saving files), then run a .bat file which renames based on Invoice ID as a filename.
Problem of course is I've been running into a limit of number of allowed files per 24 hr. period.
Even if it's not less work, it feels like less effort.
The position of (for instance) the check # on a physical check varies quite widely, as can date position and format, and a fair number of them are still written by hand.
On top of that, I'm scanning thousands of these each year, and the invoice underneath the check ranges from the gamut of: "pristine copy just re-printed 'cause the customer didn't include one" through "bad inkjet photocopy of a photograph taken w/ a potato phone and then printed" and includes variations such as "customer included half-a-dozen invoices to be paid w/ one check, and if arranging them and the check _just so_ all will fit in the document camera window, saving a trip to the sheet feeder scanner"
A co-worker actually worked on this for a different program, one where actually sending in paperwork in good condition was expected and customary, but his system had a reject/failure rate of ~10% --- that would be almost 1,000 invoices each year for the program I am handling.
The problem is they are now paying me more, plus paying for the cost of using the AI, and the needless complexity also slows down the employees. So more costs there as well, any future debugging is going to cost far more and at the end of the day they are getting less quality on the core function but far more presentation data that is essentially meaningless.
But I'm trying to figure out if this is a thing in my organization. So far the channels discussing AI have been about how they use AI, how to build agents, and complaining they've run out of tokens - but nobody says anything about how much work they finished, how it impacted the product(s), the user, and the company's bottom line.
I don't know if they just don't know, don't care, don't measure, or they don't actually want to admit they're just burning through tokens with nothing to show for it.
That said, right now I'm using AI to extract some code from our app to create a minimal reproduction for an issue we're having with a 3rd party library, it's a huge time saver there - that is, I wouldn't have bothered making a reproduction because of how time consuming it can be.
So to answer your question, it's not that "I have less to do", it's "I do things I wouldn't have done otherwise because they cost less effort/time". Which is also the promise of e.g. automation - the automated loom didn't just reduce how long it takes to make cloth, it made it so people make a bajillion times more cloth.
For example, all the work like translations that used to be done by humans, now it is a CMS AI feature.
Secondly teams setup.
It used to be we did everything ourselves for development, then cloud, SaaS products and serverless decreased the teams size required for delivery.
Now with AI, there is an even greater push for low code/no code tooling, with agents, leaving the actual programming left for MCP tools that might not yet be available for the project.
Thus you get a team of five doing what used to be about 15 a decade ago.
It pushes the bulk of the work to review. So teams with good practices can account for this.
For junior teams, the time saved is massive, because they aren't doing all the other practices required to prevent technical debt.
It's like a light switch where the light has a slightly different colour every time you turn it on, sometimes the colour is very different, and sometimes it emits bursts of heavy gamma radiation. And the argument is "you flick a switch, and what you perceive in that room changes, it's the same experience." (which is a neat way to put it, because it's true even when you get evaporated by the gamma radiation burst)
That this isn't "the same kind of tool" than just a light switch and a bulb isn't even an interesting conversation to have. Of course it's not, not even close. A piece of string is not a steel rod just because you can stretch it out, take a photo of it, and play pretend.
So the really interesting bit to me is that this level of argument is even made. It's nonsense, but if the nonsense gets repeated often enough, maybe the people refuting it can be exhausted and then we can replace concrete with pudding, right? Not that this is your intent, but this stuff just feels like the thing you'd hear in a digestive tract, not at a table between peers.
Quite so. It is true that most compilers allow you to opt in to reproducible output, but it is generally not the default [iirc, gc is the only mainstream compiler that makes always reproducible output a design requirement]. There are advantages to not have to worry about reproducible output, like performance gains in allowing threads to run in any order. Of course, LLMs equally enable you to opt into reproducible output (temperature=0). Implementation details are immaterial. The human experience is always the same: Input one language, out comes another language.
> So the really interesting bit to me is that this level of argument is even made.
Yeah, it stems from a lack of base understanding of the technology. The "a compiler is deterministic but AI isn't" is always at the heart of the argument, but it isn't even true. Implementation details are immaterial, but when you don't understand the implementation it stands to reason that one would want to focus on that facet in order to learn more about it. Hey, that’s what discussion is for: to learn.
This is just splitting hairs. And temperature = 0 is not comparable either, because the we will not keep models trained on data of a specific point in time around forever.
> Implementation details are immaterial, but when you don't understand the implementation it stands to reason that one would want to focus on that facet in order to learn more about it.
Not splitting hairs is not the same as not knowing what a hair is.
> Hey, that’s what discussion is for: to learn.
You told me nothing I didn't know or didn't expect, because it gets brought up every time like clock work. It seems to be be part and parcel of not seeing or not wanting to see the woods for all the trees.
Equally, if you replace one compiler with another, it is almost certain that the output will not remain stable, even when you have enabled reproducible builds. You are not going to find a difference on the outside, even if implementation may differ under the hood.
> You told me nothing I didn't know or didn't expect
What's in it for you, then? I have been able to learn about your character, which is quite fascinating. Technology is pretty boring, which is why nobody else was talking about a technology implementation to begin with, but HN accounts are quite interesting to learn about. Seems to me like a complete waste of time if you cannot learn anything from it.
For me this exchange kinda was, but I don't see what I could possibly do about that.
I.e. some source code gets compiled, the output gets decompiled again, the result gets compiled again, and so on.
Now do the same with LLM: start with a prompt, it generates a program. Then an LLM examines that program by looking at the source, running it, etc., and is tasked to describe it, i.e. turn it into a prompt again. Then that prompt is used to generate a program, which is examined and turned into a prompt again, and so on.
I didn't do fewer hours in these weeks but had time to explore and innovate a little.
> It’s funny. I was looking at my GH activity graph. It’s been pretty solid green, for years. I stay busy.
> But since I’ve been using an LLM, it’s been bright green.
> I always check in code manually. I don’t let the LLM do it.
I can now write software quicker in most of the cases, but the rest of the organization moves as slowly as ever.
But before that I had the same output, but with less of the boring typing stuff.