> I have stopped writing code, occasionally I jump into the changes proposed by LLM and make manual edits if it is feasible, otherwise I revert changes and ask it to generate again but based on my learnings from the past rejected output

Isn't it a very inefficient way to learn things? Like, normally, you would learn how things work and then write the code, refining your knowledge while you are writing. Now you don't learn anything in advance, and only do so reluctantly when things break? In the end there is a codebase that no one knows how it works.

▲

throwaw12 15 hours ago | parent | next [-]

> Isn't it a very inefficient way to learn things?

It is. But there are 2 things:

1. Do I want to learn that? (if I am coming back to this topic again in 5 months, knowledge accumulates, but there is a temptation to finish the thing quickly, because it is so boring to swim in huge legacy codebase)

2. How long it takes to grasp it and implement the solution? If I can complete it with AI in 2 days vs on my own in 2 weeks, I probably do not want to spend too much time on this thing

as I mentioned in other comments, this is exactly makes me worried about future of the work I will be doing, because there is no attachment to the product in my brain, no mental models being built, no muscles trained, it feels someone else's "work", because it explores the code, it writes the code. I just judge it when I get a task

▲

oytis 15 hours ago | parent [-]

I don't know where it goes, but it sounds pretty dumb for the companies involved too. Tech companies are in the business of nurturing teams knowledgeable in things so they can build something that gives them an advantage over competition. If there is no knowledge being built, there is no advantage and no tech business.

	▲	hobofan 15 hours ago \| parent [-]
		> Tech companies are in the business of nurturing teams knowledgeable in things It pains the anti-capitalist fibers in my body to say this, but no they are not. At the maximum the value is in organizational knowledge and existing assets (= source code, documentation), so that people with the least knowledge possible can make changes. In software companies in general, technical excellence and knowledge is not strongly correlated with economic success as long as you clear a certain bar (that's not that high). In comparison, in hardware/engineering companies, that's a lot more correlated. In the concrete example of a legacy codebase we have here, there is even less value in trying to build up knowledge in the company, as it has already been decided that the system is to be discarded anyways.

▲

hobofan 16 hours ago | parent | prev [-]

> you would learn how things work and then write the code

In a legacy codebase this may require learning a lot of things about how things work just to make small changes, which may be much less efficient.

	▲	oytis 15 hours ago \| parent [-]
		I might still be naive about the industry, but if you don't know how the legacy codebase works, you might either delegate the change to someone else in the company who does, or, if there is no one left, use this opportunity to become the person who knows at least something about it.