9 ms·

In my startup, I am currently in consideration for doing this exact thing. The interesting part is it's not really the AI that's causing the issue. It's the eas

In my startup, I am currently in consideration for doing this exact thing. The interesting part is it's not really the AI that's causing the issue. It's the ease of my developer to make a mess, either with messy code or feature bloat. After figuring out the exact product we need with some very quick development cycles with AI, we now have some problems that I can't keep under control because of AI. So, currently under consideration to rewrite the core functionality without AI so we can keep it simple, understandable and slower to change. The interesting part is that AI could do this, but managing developers with AI has become very difficult to get them to slow down and build stable simple things. EDIT: I found it interesting how negative the comments were and I thought it would be easier to add context to the root. My developers wanted to use AI. I was a skeptic for several reasons. But I agreed that it was worth committing to and seeing what came of it. And all in all, the rapid prototyping is excellent. However, as parts of the software are past the point of rapid prototyping, I talked with my team and everyone agreed that the core piece deserved a re-factor/re-write because of the mess it was. Classic tech debt of deprecated code hanging around and prototype features with patchwork additions that now are a poor way of executing the intended function. So, we agreed to do a significant re-factor and did. However, quickly it got incredibly messy again. Partially due to AI using git to look at prior commits and add things back. And so, it was essentially an unsuccessful refactor and we find ourselves with the same issue. They also agree that using AI is the problem here because it's very easy to get new things. And the temptation to solve a problem quickly is high (I am stressing the opposite, to go slow), but it can be hard to say no to a co-worker who isn't dealing with the technical issues. So, both myself and my developers agree that AI is the issue in creating a messy that has resulted in unstable code. The reason I say that I am considering this choice is because while they acknowledge the issues it's causing, they aren't excited about returning to coding without them. Which is also why I'm considering the right move here, since the goal is both a happy team and well functioning software.

gilrain 1mo ago
> I am currently in consideration for doing this Try “I am considering”.
- rpdillon 1mo ago
  In a situation where you are an editor and focusing on the clarity and the brevity of the writing, I think this is a fantastic suggestion. Hacker News has long ago decided that making comments on the quality of the writing in the comments is not welcome. Correcting spelling, correcting word usage, changing phrasing, and making other suggestions to improve the grammar of a post is not something that Hacker News readers want to encounter in the comments section. It bothers me every day because there are gobs of cases where the writing is horrible, but I understand why the rule exists. It would make the comments section insufferable if everybody were just correcting each other's grammar the whole time.
- stasomatic 1mo ago
  Why are you being so friendly? Perhaps En isn't their native language. Although, taken out of context, that sentence could be interpreted as "I got myself in trouble for doing this". :)
- gamerDude 1mo ago
  Rereading, I can appreciate the active verb you want me to use, but I like "in consideration". I am in a period of consideration, it's more passive which accurately captures the reality.
adamtaylor_13 1mo ago
This is a leadership problem, not an AI problem. I have the opposite situation: I don't think about code "messiness" anymore. I trust my developers to ship the right thing because we communicate constantly about what our goal is and why we're doing it. Solve the leadership problem and the AI thing becomes an advantage instead of a problem.
- rpdillon 1mo ago
  This is correct. It's a giant red flag in GP that they're worried about their developers making a mess with AI. That's an issue of the developers' judgment not being any good, not a problem with AI.
  - adamtaylor_13 1mo ago
    If your developers aren't focusing on what's important to you, that's a leadership problem, not an AI problem.
watwut 1mo ago
> The interesting part is that AI could do this, but managing developers with AI has become very difficult to get them to slow down and build stable simple things. That is mutually incoherent. If AI can reliably do it, developers who reliably did it before AI would reliably did it again. Sounds like AI cant reliably do it and your developers struggle to control its outputs.
fy20 1mo ago
It just sounds like accumulated tech debt? And the faster you ship new features, the faster it accumulates.
cyanydeez 1mo ago
I think I definitely see the problem as a solo dev. I can just wing it with refactors and new tests, and all manners of sloshing about. But if I tried to do this with just one other person, they'd be pulling their hair out trying to understand why the last time they had to understand the code has completely shifted. There definitely going to be a lot of fortune 500 companies absolutely wrecked by the amount of changes to their code base that no one will be "responsible" for because none of the workers will really know if it was their agent that changed something. There could be some outliers who found the correct tools at the right time, but I don't think they'll suddenly be thrust into the money, because good code is definitely not the only thing that lets people succeed.
conartist6 1mo ago
Of course. You've described a company with no team. What you've said also makes clear why nobody would have an incentive to play like a team player. You have this comprehension work you think is important and you've already devalued it by saying that humans would be a waste if AI could be used. If I were a human working for you I would conclude that regardless of your exact words, your actions create the conditions whereby it is far safer to try to get the AI to bullshit its way through things than to risk trying to do them well as a human. You clearly articulate here that the bullshit is all you care for. If that is what will satisfy you most readily, why would anyone working for you aim higher anymore?
jbs789 1mo ago
Yeah I see the same thing. Also shows up when people produce an “analysis” largely driven by AI and they haven’t really thought it through. They/we are outsourcing their thinking.
- HeavyStorm 1mo ago
  That's what affecting me the most. Pure Claude hallucinated analysis that the poster has not really read; worse part is that I can ask Claude for the same analysis, so there's no benefit, only long questions that waste my time.
Cameri 1mo ago
Check out AI-DLC or another structured development workflow for your team and stick to it. If you’ve got devs: not using any structured workflow, or using a variety (speckit, openspec, superpowers, their own) it’s going to be hard to control the quality of the development process itself and its outputs: you are just producing slop. What many businesses are going through is the industrialization of software development.
dijksterhuis 1mo ago
> the goal is both a happy team and well functioning software. software first. team second. team happiness is important as a miserable team will hamper productivity and quality. but the team’s happiness is secondary to their overarching reason d’être — the software. if there were no need for the software, the team wouldn’t need to exist. so that goal should take precedence. YMMV
- esseph 1mo ago
  Companies come and go but humans and relationships can stay for a lifetime, often through multiple companies. You may have it backwards.
  - dijksterhuis 1mo ago
    OP wasn't asking how to ensure their team members have relationships that extend beyond the time they spent working in that team. it was about the trade-off between team happiness (getting to use tools how the team wants to) versus the results (problems with the produced software because the team are using the tools how the team wants to).
- GTP 1mo ago
  You should really look at studies on how happy employees are much more productive than unhappy ones. And the trend continues way above the bare minimum of not being miserable.
  - dijksterhuis 1mo ago
    not sure why you've equated the team's happiness is less important than the software to make the team unhappy. that's an incredibly binary perspective. there's usually more than two priorities. and i agree with you that a team's wellbeing is important. it should be up there in priorities. i'm just pointing out that a team that accepts being <some imaginary figure that's not 100% like 70% or 80%> happy, focussing on the software as more important than their own happiness might do better than a team who are trying to focus on their happiness at the same level of priority as the quality of the software.
josedrobles 25d ago
[flagged]

gilrain 1mo ago

> I am currently in consideration for doing this Try “I am considering”.

rpdillon 1mo ago
In a situation where you are an editor and focusing on the clarity and the brevity of the writing, I think this is a fantastic suggestion. Hacker News has long ago decided that making comments on the quality of the writing in the comments is not welcome. Correcting spelling, correcting word usage, changing phrasing, and making other suggestions to improve the grammar of a post is not something that Hacker News readers want to encounter in the comments section. It bothers me every day because there are gobs of cases where the writing is horrible, but I understand why the rule exists. It would make the comments section insufferable if everybody were just correcting each other's grammar the whole time.
stasomatic 1mo ago
Why are you being so friendly? Perhaps En isn't their native language. Although, taken out of context, that sentence could be interpreted as "I got myself in trouble for doing this". :)
gamerDude 1mo ago
Rereading, I can appreciate the active verb you want me to use, but I like "in consideration". I am in a period of consideration, it's more passive which accurately captures the reality.

adamtaylor_13 1mo ago

This is a leadership problem, not an AI problem. I have the opposite situation: I don't think about code "messiness" anymore. I trust my developers to ship the right thing because we communicate constantly about what our goal is and why we're doing it. Solve the leadership problem and the AI thing becomes an advantage instead of a problem.

rpdillon 1mo ago
This is correct. It's a giant red flag in GP that they're worried about their developers making a mess with AI. That's an issue of the developers' judgment not being any good, not a problem with AI.
- adamtaylor_13 1mo ago
  If your developers aren't focusing on what's important to you, that's a leadership problem, not an AI problem.

watwut 1mo ago

> The interesting part is that AI could do this, but managing developers with AI has become very difficult to get them to slow down and build stable simple things. That is mutually incoherent. If AI can reliably do it, developers who reliably did it before AI would reliably did it again. Sounds like AI cant reliably do it and your developers struggle to control its outputs.

fy20 1mo ago

It just sounds like accumulated tech debt? And the faster you ship new features, the faster it accumulates.

cyanydeez 1mo ago

I think I definitely see the problem as a solo dev. I can just wing it with refactors and new tests, and all manners of sloshing about. But if I tried to do this with just one other person, they'd be pulling their hair out trying to understand why the last time they had to understand the code has completely shifted. There definitely going to be a lot of fortune 500 companies absolutely wrecked by the amount of changes to their code base that no one will be "responsible" for because none of the workers will really know if it was their agent that changed something. There could be some outliers who found the correct tools at the right time, but I don't think they'll suddenly be thrust into the money, because good code is definitely not the only thing that lets people succeed.

conartist6 1mo ago

Of course. You've described a company with no team. What you've said also makes clear why nobody would have an incentive to play like a team player. You have this comprehension work you think is important and you've already devalued it by saying that humans would be a waste if AI could be used. If I were a human working for you I would conclude that regardless of your exact words, your actions create the conditions whereby it is far safer to try to get the AI to bullshit its way through things than to risk trying to do them well as a human. You clearly articulate here that the bullshit is all you care for. If that is what will satisfy you most readily, why would anyone working for you aim higher anymore?

jbs789 1mo ago

Yeah I see the same thing. Also shows up when people produce an “analysis” largely driven by AI and they haven’t really thought it through. They/we are outsourcing their thinking.

HeavyStorm 1mo ago
That's what affecting me the most. Pure Claude hallucinated analysis that the poster has not really read; worse part is that I can ask Claude for the same analysis, so there's no benefit, only long questions that waste my time.

Cameri 1mo ago

Check out AI-DLC or another structured development workflow for your team and stick to it. If you’ve got devs: not using any structured workflow, or using a variety (speckit, openspec, superpowers, their own) it’s going to be hard to control the quality of the development process itself and its outputs: you are just producing slop. What many businesses are going through is the industrialization of software development.

dijksterhuis 1mo ago

> the goal is both a happy team and well functioning software. software first. team second. team happiness is important as a miserable team will hamper productivity and quality. but the team’s happiness is secondary to their overarching reason d’être — the software. if there were no need for the software, the team wouldn’t need to exist. so that goal should take precedence. YMMV

esseph 1mo ago
Companies come and go but humans and relationships can stay for a lifetime, often through multiple companies. You may have it backwards.
- dijksterhuis 1mo ago
  OP wasn't asking how to ensure their team members have relationships that extend beyond the time they spent working in that team. it was about the trade-off between team happiness (getting to use tools how the team wants to) versus the results (problems with the produced software because the team are using the tools how the team wants to).
GTP 1mo ago
You should really look at studies on how happy employees are much more productive than unhappy ones. And the trend continues way above the bare minimum of not being miserable.
- dijksterhuis 1mo ago
  not sure why you've equated the team's happiness is less important than the software to make the team unhappy. that's an incredibly binary perspective. there's usually more than two priorities. and i agree with you that a team's wellbeing is important. it should be up there in priorities. i'm just pointing out that a team that accepts being <some imaginary figure that's not 100% like 70% or 80%> happy, focussing on the software as more important than their own happiness might do better than a team who are trying to focus on their happiness at the same level of priority as the quality of the software.

josedrobles 25d ago

[flagged]