Comment by dreamcompiler

> For coding, you can use AI to write your code. For software engineering, you can't.

You can 100% use AI for software engineering. Just not by itself, you need to currently be quite engaged in the process to check it and redirect it.

But AI lowers the barrier to writing code and thus it brings people will less rigour to the field and they can do a lot of damage. But it isn't significantly different than programming languages made coding more accessible than assembly language - and I am sure that this also allowed more people to cause damage.

You can use any tools you want, but you have to be rigorous about it no matter the tool.

> For coding, you can use AI to write your code. For software engineering, you can't.

This is a pretty common sentiment. I think it equates using AI with vibe-coding, having AI write code without human review. I'd suggest amending your rule to this:

> For coding, you can use AI. For software engineering, you can't.

You can use AI in a process compatible with software engineering. Prompt it carefully to generate a draft, then have a human review and rework it as needed before committing. If the AI-written code is poorly architected or redundant, the human can use the same AI to refactor and shape it.

Now, you can say this negates the productivity gains. It will necessarily negate some. My point is that the result is comparable to human-written software (such as it is).

I absolutely don't care about how people generate code, but they are responsible for every single line they push for review or merge.

That's my policy in each of my clients and it works fine, if AI makes something simpler/faster, good for the author, but there's 0, none, excuses for pushing slop or code you haven't reviewed and tested yourself thoroughly.

If somebody thinks they can offset not just authoring or editing code, but also taking the responsibility for it and the impact it has on the whole codebase and the underlying business problem they should be jobless ASAP as they are de facto delegating the entirety of their job to a machine, they are not only providing 0 value, but negative value in fact.

I feel like the distinction is equivalent to

    LLMs can make mistakes. Humans can't.

Humans can and do make mistakes all the time. LLMs can automate most of the boring stuff, including unit tests with 100% coverage. They can cover edge cases you ask them to and they can even come up with edge cases you may not have thought about. This leaves you to do the review.

I think think the underlying problem people have is they don't trust themselves to review code written by others as much as they trust themselves to implement the code from scratch. Realistically, a very small subset of developers do actual "engineering" to the level of NASA / aerospace. Most of us just have inflated egos.

I see no problem modelling the problem, defining the components, interfaces, APIs, data structures, algorithms and letting the LLM fill in the implementation and the testing. Well designed interfaces are easy to test anyway and you can tell at a glance if it covered the important cases. It can make mistakes, but so would I. I may overlook something when reviewing, but the same thing often happens when people work together. Personally I'd rather do architecture and review at a significantly improved speed than gloat I handcrafted each loop and branch as if that somehow makes the result safer or faster (exceptions apply, ymmv).