4 ms·

My old rule about the difference between coding and software engineering: For coding, "it seems to work for me" is good enough. For software engineering, it'

My old rule about the difference between coding and software engineering: For coding, "it seems to work for me" is good enough. For software engineering, it's not. My new rule: For coding, you can use AI to write your code. For software engineering, you can't.

epolanski 11mo ago
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.
- strix_varius 11mo ago
  Totally agree. For me, the hard part has been figuring out the distinction with junior engineers... Is this poorly thought out, inefficient solution that is 3x as long as necessary due to AI, or inexperience?
  - manwe150 11mo ago
    Does it matter? Either way seems to just reflect badly on the junior, who needs to improve their self-review skills and knowledge
    - epolanski 11mo ago
      It's not easy to be a junior, and we might be speaking with survivor bias, but most juniors don't end up in solid engineering teams, they are merely developers that are much cheaper and from whom you expect much less, but more often than not they are borderline left learning and figuring out things on their own. They need to luck some senior member that will nurture them and not just give them low quality work (which I admit I have done too when I had myself lots of pressure to deliver my own stuff). Even in less desperate teams, as productivity grows with AI (mine does, even if I don't author code with it it's tremendous help in just navigating repos and connecting the dots, it saves me so much time...) the reviewing pressure increases too, and with that fatigue.
    - strix_varius 11mo ago
      It does matter, because it's a worthwhile investment of my time to deeply review, understand, and provide feedback for the work of a junior engineer on my team. That human being can learn and grow. It is not a worthwhile use of my time to similarly "coach" LLM slop. The classic challenge with junior engineers is that helping them ship something is often more work than just doing it yourself. I'm willing to do that extra work for a human.
  - stocksinsmocks 11mo ago
    Not defending him, but we were already doing this with electron apps, frameworks, libraries, and scripting languages. The only meaningful cost in most software development is labor and that’s what makes sense to optimize. I’d rather have good software, but I’ll take badly made software for free over great software that costs more than the value of the problem solved. These discussions are always about tactics and never operations.
    - sidjxnbx 11mo ago
      I get it, but I think there’s something deeply anti human about being ok with this (not just in software). It’s similar in sentiment to how you behave when nobody is looking - a culture and society is so much better off if people take pride in their work. Obviously there’s nuance (I’ll take slop food for starving people over a healthy meal for a limited few if we’re forced to choose), but the perverse incentives in society start to take over if we allow ourselves to be ok with slop. Continuously chasing the bottom of the barrel makes it impossible for high quality to exist for anyone except the rich. Put another way: if we as a society said “it is illegal to make slop food”, both the poor and the rich would have easy access to healthy food. The cost here would be born by the rich, as they profit off food production and thus would profit less to keep quality high.
      - stocksinsmocks 11mo ago
        I’m pretty sure the USSR, Cuba, and the like never succeeded doing this sort of thing, but maybe if we hit ourselves in the head with the same hammer (and sickle) just one more time it will work?
        cindyllm 11mo ago
        [dead]
        Ekaros 11mo ago
        The capitalist west seems fully happy buying slop and crap as long as it is cheap... Nearly no one demands quality anymore.
networked 11mo ago
> 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).
- jorl17 11mo ago
  100% this. Just don't expect to get decent code often if you mostly rely on something like cursor's default model. You literally get what you pay for.
bhouston 11mo ago
> 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.
rootlocus 11mo ago
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).
- krupan 11mo ago
  "I feel like these distinctions are equivalent to LLMs can make mistakes. Humans can't." No, that's not it. The difference between humans and AI is that AI suffers no embarrassment or shame when it makes mistakes, and the humans enthusiastically using AI don't seem to either. Most humans experience a quick and viseral deterrent when they publish sloppy code and mistakes are discovered. AI, not at all. It does not immediately learn from its mistakes like most humans do. In the rare case when there is a human that is consistently persistently confidently wrong like AI, a project can identify that person and easily stop wasting their time working with that person. With masses of people being told by the vocal AI shills how amazing AI is, projects can easily be flooded with confidently wrong aaI generated PRs.
- blibble 11mo ago
  > 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. in my experience these tests don't test anything useful you may you have 100% test coverage, but it's almost entirely useless but not testing the actual desired behaviour of the system rather just the exact implementation
gherkinnn 10mo ago
I disagree with the new rule. The old one is fine and applies to LLMs. Vibing and good enough is a terrible combination, as unknown elements of the system grow at a faster rate than ever. Using LLMs while understanding every change and retaining a mental model of the system is fine. Granted, I see vibe+ignorance way too often as it is the short-term path of least resistance in the current climate of RTO and bums in seats and grind and ever more features.

epolanski 11mo ago

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.

strix_varius 11mo ago
Totally agree. For me, the hard part has been figuring out the distinction with junior engineers... Is this poorly thought out, inefficient solution that is 3x as long as necessary due to AI, or inexperience?
- manwe150 11mo ago
  Does it matter? Either way seems to just reflect badly on the junior, who needs to improve their self-review skills and knowledge
  - epolanski 11mo ago
    It's not easy to be a junior, and we might be speaking with survivor bias, but most juniors don't end up in solid engineering teams, they are merely developers that are much cheaper and from whom you expect much less, but more often than not they are borderline left learning and figuring out things on their own. They need to luck some senior member that will nurture them and not just give them low quality work (which I admit I have done too when I had myself lots of pressure to deliver my own stuff). Even in less desperate teams, as productivity grows with AI (mine does, even if I don't author code with it it's tremendous help in just navigating repos and connecting the dots, it saves me so much time...) the reviewing pressure increases too, and with that fatigue.
  - strix_varius 11mo ago
    It does matter, because it's a worthwhile investment of my time to deeply review, understand, and provide feedback for the work of a junior engineer on my team. That human being can learn and grow. It is not a worthwhile use of my time to similarly "coach" LLM slop. The classic challenge with junior engineers is that helping them ship something is often more work than just doing it yourself. I'm willing to do that extra work for a human.
- stocksinsmocks 11mo ago
  Not defending him, but we were already doing this with electron apps, frameworks, libraries, and scripting languages. The only meaningful cost in most software development is labor and that’s what makes sense to optimize. I’d rather have good software, but I’ll take badly made software for free over great software that costs more than the value of the problem solved. These discussions are always about tactics and never operations.
  - sidjxnbx 11mo ago
    I get it, but I think there’s something deeply anti human about being ok with this (not just in software). It’s similar in sentiment to how you behave when nobody is looking - a culture and society is so much better off if people take pride in their work. Obviously there’s nuance (I’ll take slop food for starving people over a healthy meal for a limited few if we’re forced to choose), but the perverse incentives in society start to take over if we allow ourselves to be ok with slop. Continuously chasing the bottom of the barrel makes it impossible for high quality to exist for anyone except the rich. Put another way: if we as a society said “it is illegal to make slop food”, both the poor and the rich would have easy access to healthy food. The cost here would be born by the rich, as they profit off food production and thus would profit less to keep quality high.
    - stocksinsmocks 11mo ago
      I’m pretty sure the USSR, Cuba, and the like never succeeded doing this sort of thing, but maybe if we hit ourselves in the head with the same hammer (and sickle) just one more time it will work?
      - cindyllm 11mo ago
        [dead]
      - Ekaros 11mo ago
        The capitalist west seems fully happy buying slop and crap as long as it is cheap... Nearly no one demands quality anymore.

networked 11mo ago

> 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).

jorl17 11mo ago
100% this. Just don't expect to get decent code often if you mostly rely on something like cursor's default model. You literally get what you pay for.

bhouston 11mo ago

> 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.

rootlocus 11mo ago

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).

krupan 11mo ago
"I feel like these distinctions are equivalent to LLMs can make mistakes. Humans can't." No, that's not it. The difference between humans and AI is that AI suffers no embarrassment or shame when it makes mistakes, and the humans enthusiastically using AI don't seem to either. Most humans experience a quick and viseral deterrent when they publish sloppy code and mistakes are discovered. AI, not at all. It does not immediately learn from its mistakes like most humans do. In the rare case when there is a human that is consistently persistently confidently wrong like AI, a project can identify that person and easily stop wasting their time working with that person. With masses of people being told by the vocal AI shills how amazing AI is, projects can easily be flooded with confidently wrong aaI generated PRs.
blibble 11mo ago
> 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. in my experience these tests don't test anything useful you may you have 100% test coverage, but it's almost entirely useless but not testing the actual desired behaviour of the system rather just the exact implementation

gherkinnn 10mo ago

I disagree with the new rule. The old one is fine and applies to LLMs. Vibing and good enough is a terrible combination, as unknown elements of the system grow at a faster rate than ever. Using LLMs while understanding every change and retaining a mental model of the system is fine. Granted, I see vibe+ignorance way too often as it is the short-term path of least resistance in the current climate of RTO and bums in seats and grind and ever more features.