undefined

points

[-]

Right, it's just pretending to be able to delay the inevitable. It's like the assembly programmers of the 70s and 80s keeping their assembly-fu sharp. Yes it might come handy, and it's good to have a grasp of the concepts, but most careers have shifted to not needing to use assembly. Yes, I know that better knowledge of the low level would improve performance and efficiency. But people don't work with this any more, and the goal back then also wasn't to keep retyping a GCC output to keep the skill fresh. It was to get to a higher level of control and think about the organization of structured code, code maintenance issues, thinking at the level of how to make the C++ implementation.

With AI, our role also shifts. It's mainly to know what to spend effort on, to set priorities and, to be able to verbalize requirements, missing social context and unwritten rules, to anticipate what additional documents the agent needs, to prioritize deadlines, feature necessity, and other judgment calls.

We are right at the stage where our coding ability and review ability is still needed though, but this stage won't last long. Soon there will be as little point to a human diving into the code as to trying to beat a chess engine, or humans constructing buildings by hand. Of course the discussion and prioritization may involve looking at the code itself, to get a better idea of why the agent says that a certain feature would be tedious to implement in the current architecture, but then most people will just learn to take its word for it, just as you may want to understand a chess engine's step, but you typically wouldn't want to override it.

by skydhash8 hours ago|

parent|

[-]

> With AI, our role also shifts. It's mainly to know what to spend effort on, to set priorities and, to be able to verbalize requirements, missing social context and unwritten rules, to anticipate what additional documents the agent needs, to prioritize deadlines, feature necessity, and other judgment calls.

Did you not do that before AI? It’s so strange to me when people are calling out these kind of tasks like they were not already a requirement for the job. What were you doing before?

> Soon there will be as little point to a human diving into the code as to trying to beat a chess engine, or humans constructing buildings by hand

Chess is way less complex than coding. The rules are like a few pages. While the specs for an 8 bit chip like the AVR is in the hundreds of pages. Books like “The Linux Programming Interface” are thousand pages long.

Also humans are using tools for building. Tools that do exactly what you control them to do. When you use a drill for a hole, you don’t have to worry that pressing the trigger have a good chance of sending the bit in your guts.

by bonoboTP7 hours ago|

parent|

[-]

> Did you not do that before AI? It’s so strange to me when people are calling out these kind of tasks like they were not already a requirement for the job. What were you doing before?

No, you didn't have to explicitly say it in words. My mind doesn't run on internal monologue. Many people can just do their work without ever having reflected on it in words. Tacit knowledge, routines, shared assumptions and culture in a team, common knowledge etc. People have a hard time using AI because they are bad at modeling the knowledge state / information context from the AI POV. You need good theory of mind for this, and being a good programmer is distinct from that soft skill. Yes yes blabla soft skills are more important than hard skills blabla, I don't buy it. It used to be valuable to be great at the hard skills even with mid-tier soft skills. You can have a ton of smooth talkers who are attuned to feel each others emotion and desires super well, but the thing has to actually work too.

> What were you doing before?

Wrote code. Yes, you have to explain the outcome to your boss or your team at some point, but people generally have better developed theories of mind for people than for AI.

> Also humans are using tools for building. Tools that do exactly what you control them to do. When you use a drill for a hole, you don’t have to worry that pressing the trigger have a good chance of sending the bit in your guts.

Right. I'm not sure how to reconcile the two though. A tool whose job is to do some of the thinking part seems to be a contradiction to me. If I so much know what there is to do that it's pure execution and can reliably be executed in a way that basically ensures no potential surprises to me, then I wouldn't need more thinking. But I agree, it would be better to somehow find a hybrid that is both doing thinking and feels more like a tool also while using it.

by 2snakes6 hours ago|

parent|

[-]

Llms are a relational responsive reasoning interface, not a mind.

by bonoboTP6 hours ago|

parent|

[-]

The point is that you have to have an idea of what it has access to in its context. Many expect it to work like an omniscient genie and then give up once it turns out that it can't read your mind and you have to be able to halfway-coherently state what you want.

by skydhash7 hours ago|

parent|

prev|

[-]

> No, you didn't have to explicitly say it in words. My mind doesn't run on internal monologue. Many people can just do their work without ever having reflected on it in words.

Were you a solo developer? I think the amount of reports and explanations (either written or verbal) dwarfs by large the amount of code I’ve written. From training juniors to drafting a design specs for a feature. That is why people say code is the trivial part of the job because it’s easy. I’m pretty sure the mailing list of the Linux kernel is bigger than the code itself.

by bonoboTP7 hours ago|

parent|

[-]

I'm in academic ML research. Coding is mostly scoped to myself. And it's often nontrivial. My communication is more in papers, reports on experimental results, deciding what to try next, but how the code is organized is rarely the focus of discussion. Of course this may be entirely different in a software shop building routine features where the difficulty is indeed the social part and the software itself is more clearly understood. But I'd say that's when AI can be even more effective since it can do mundane coding even better proportionally than research code. Of course Amdahl's law kicks in and even if you reduce that drudgery to 0, the proportion is small when taking total work effort into context.

by skydhash6 hours ago|

parent|

[-]

> Of course this may be entirely different in a software shop building routine features where the difficulty is indeed the social part and the software itself is more clearly understood. But I'd say that's when AI can be even more effective since it can do mundane coding even better proportionally than research code

And here’s another fallacy that is always thrown around. Always underestimating the other’s tasks when you are not an expert in it and don’t know intimately what’s involved.

by bonoboTP6 hours ago|

parent|

[-]

So which is it? Is the coding part easy or hard? If it's easy and the task is mainly all the song and dance with the client, the stakeholders, getting approval and whatnot, then AI can take care of that easy coding and at least save that time. But then that is proportionally not much. I do have friends in industry, and they do sit quite a lot of hours in front of an IDE typing and fighting compilation issues, etc. It's not like they are always in meetings. I know people who work in the computer vision industry, 3D perception, and they have relatively few meetings and report to their boss occasionally, are not micromanaged, there is little red tape. They are getting real benefits from AI. It has eliminated several efficiency problems in their code that nobody took the time to fix, like consolidating repeated computations to just being done once, or similar things. They have solved a lot of CI pain with it, where they used to have an entire employee just taking care of keeping the CI in shape and updating it and remembering all the quirks, it's no longer a full time job, though also not fully automated. The CI person of course doesn't like the fact that his arcane knowledge has become un-moated. (I've worked on maintaining servers myself and I was the only one who really knew how it worked or how to fix it when it was broken, how to use it in specific special contexts, e.g. in context of a Slurm cluster. Today a lot of that hard-earned detailed knowledge is obviated by Claude, because it can answer similarly well to how I could, or better. So I have experienced such things myself too.)

I don't think we should be making sweeping claims. But everyone generalizes. The person on top claimed that productivity doesn't increase for competent people and that coding is anyway very easy. That may be true in some contexts but not in others. Some software jobs require a lot of face-to-face, others less. Some managers micromanage, others just care about results on a longer timeframe. Some people build technically difficult, computationally heavy code, deployed on special hardware with efficiency requirements, others deploy website-like iPhone apps and CRUD webapps all day. There's no single shape for a software-related job.

by skydhash5 hours ago|

parent|

[-]

The thing is coding is very much like translating. And we do have machine translation. And they do fine for simple sentences. And even with more substantial paragraphs, you can get the gist of what it’s being said. But no one will say that it does a better job than a professional translator. And if you go and translate something from a foreign language, it wouldn’t be the kind of English you’d write. So assume that English to a foreign language is equally strange for someone that speaks that language.

So comes the programmer as a translator. Why the translation itself takes some effort, but most of the intellectual works is understand the intent of the change request or the specs (nothing to do with the code) and grasping the semantics of some features of the platform (library docs,…). Once that’s done coding is fairly easy as long as you follow the consistency of the code (architecture and other design patterns).

So on one side you get the formal world of computing and buggy libraries (backed by electronics which is a bit more chaotic) and on the other side you got natural languages, the various jargons, and other formal notations. The programmer translates one to another and overtime become proficient in both.

You then add AI into the mix and the same ickiness appears. While non speakers are enjoyed that they can write code, all programmers are saying that the code is bad. Not because of syntax, but because it lacks any consistency with the program which is the formal representation of the specs/solution. Thus the rise of harness and agents. But the machine translation still does have a lot of issues that professional programmers have to clean up.

> Some software jobs require a lot of face-to-face, others less.[…] There's no single shape for a software-related job.

But there’s one fact. Code is a formal notation for an algorithm, and that notation can be executed by a computer, thus making the process have a tangible effect in the real world. That effect is what is useful and making it controllable, thus modeling it and designing an interface is a worthwhile effort. Once that’s done, you can formally write it. But we have found that it is hard to do it in one go, so incremental approach is best.

So everything about software development is about modeling and having a suitable interface. The code itself is only a tool. Just like a ruler is only a tool to get a straight line. The straight line is what’s valuable. Not the ruler.

by bonoboTP4 hours ago|

parent|

[-]

> So comes the programmer as a translator. Why the translation itself takes some effort, but most of the intellectual works is understand the intent of the change request or the specs (nothing to do with the code) and grasping the semantics of some features of the platform (library docs,…). Once that’s done coding is fairly easy as long as you follow the consistency of the code (architecture and other design patterns).

Yes, of course, but a lot of it is boilerplate and just figuring out how some function is called or how exactly it is exposed in the library, dealing with some frustrating but trivially solved inconsistencies or incompatibilities or oh you first have to initialize this or that, or actually this feature is missing from version X but can be emulated by setting an environment variable to this other value and blablabla.

> all programmers are saying that the code is bad.

Ridiculous. When did you last use AI for actual work where you wanted it to actually work? I know it may sound like saying James Randi's negative attitude blocks my telepathy or dowsing skill, but I get this impression of many people. They tried agentic coding a year ago, decided that it doesn't work and if they tried it ever since, they didn't provide context, didn't set it up for a possibility of success then immediately closed the program and sighed a sigh or relief that they are safe. It's not like that. The current frontier is very capable on higher level design tasks as well. If your problem is spiritual or social or economic, then let's skip this "not productive enough" alibi talk.

Machine translation today may not be up to the levels of the best professional translators who work on something with full focus and full effort, given all the time they want to polish it, but it's better than an ordinary (not particularly the top of the top) translator working multiple project with tight deadlines. You have to compare like for like and take cost into account too. There is an immense amount of mistranslations by "professional" translators, not sure if you've ever seen movie subtitles or TV series dubs. Lots of paid professionals hired by production studios make huge mistakes, clearly miss cultural references even sometimes grammatical structures, which modern machine translation aces and even chat models are great at it and know basically all obscure pop culture references that e.g. a regular American audience member is expected to know but a translator working in Estonia may not get. Yes you should have a guy checking the output and doing some light touchups, given the draft and explanations and references provided by the AI, but the time of doing it fully manually and being competitive on the real world translator market has ended.

by skydhash4 hours ago|

parent|

[-]

> The current frontier is very capable on higher level design tasks as well. If your problem is spiritual or social or economic, then let's skip this "not productive enough" alibi talk.

My problem is not about the productivity, it's about how this productivity is measured.

> Yes you should have a guy checking the output and doing some light touchups, given the draft and explanations and references provided by the AI, but the time of doing it fully manually and being competitive on the real world translator market has ended.

Have this been measured that this is actually faster while ensuring a quality baseline? I believe it's still the same "LGTM". And a lot of complaints about low quality text. And bugs in the case of software.

So you got a lot of messaging about how AI is supposed to make you faster. And now everyone is trying to show how fast they are with AI while the products are getting buggier.

by ChrisLTD7 hours ago|

prev|

[-]

> upper management who are already eliminating these assembly line, JIRA-ticket-taker software jobs en masse

Is there any proof of this?

by petcat7 hours ago|

parent|

[-]

Some anecdotal trends listed in this report on US demand for Indian tech workers rapidly slowing.

https://thefederal.com/category/news/h1b-visa-indian-tech-wo...

> According to the discussion, foreign hiring at Google has fallen by more than half, while approvals at Amazon have dropped by nearly a third.

> According to Xfino's Active Tech Jobs Outlook, active technology job openings fell to 93,000 in June, down 14 per cent from 108,000 a month earlier.