> Some exec somewhere in the company decided everyone needs to be talking to AI, and they track how often you're talking with it. I ended up on a naughty list for the first time in my career, despite never having performance issues. I explain to my manager and his response is to just ask it meaningless questions.
That's not a career-switching issue, that's a company-switching issue. Most people will work for at least one company in their career where the people in charge are dickheads. If you can't work around them, go find a different company to work for. You don't have to throw away an entire career because of one asshole boss.
Also fwiw, resistance is more effective than you think. You'd be surprised how often a dickhead in charge is either A) easy to call the bluff of, or B) needs someone to show them they are wrong. If you feel like you're going to quit anyway, put your foot down and take a stand.
> said usage is actually getting monitored and performance appraisals have now started depending on the AI usage instead of (or at least in addition to) traditional metrics like number of priority bugs raised, code reviews, Function Points Analysis, etc.
Really? This sounds absurd. "Instead of" means it doesn't matter how shit your work is as long as you're burning tokens? Or it doesn't matter how good your work is if you're not burning tokens? Name and shame
The worst part of AI is the way it's aggressively pushed. Sometimes I have to turn off AI completions in the IDE just because it becomes extremely aggressive in showing me very wrong snippets of code in an incredibly distracting way. I hope when the hype dies down the way these tools are pushed on us in a UX sense is also dialed down a bit.
The good and bad aspect of this approach to AI in tech is that it revealed really how many developers out there are merely happy with getting something to work and get it out the door before clocking out and not actually understanding the inner workings of their code.
Steelmanning the "we must force tool usage" position: it's possible that a tool does increase productivity, but there's either a steep learning curve (productivity only improves after sustained usage) or network effects (most people must use it for anyone to benefit).
No opinion on whether or not this applies to the current moment. But maybe someone should try forcing Dvorak layout on everyone or something like that for a competitive edge!
GPT-5: Typesetting and paste-up, film prepress/stripping, CMYK color separations, halftone screening, darkroom compositing/masking, airbrush photo retouching, optical film compositing/titling, photochemical color timing, architectural hand drafting, cartographic scribing and map lettering, music engraving, comic book lettering, fashion pattern grading and marker making, embroidery digitizing and stitching, screen-print color separations
> If they’re really so confident on the LLM’s effectiveness, why not just keep it voluntary, why force it on people?
For people who are so confident (which, I'm not), it's an obvious step; developers who don't want to use it must either be luddites or afraid it'll take their jobs. Moving sales people to digital CRMs from paper files, moving accountants to accounting software from paper ledgers and journals, moving weavers to power looms, etc etc -- there would have been enthusiasts and holdouts at every step.
The PE-bro who's currently boasting to his friends that all code at a portfolio has to be written first with Claude Code and developers are just there to catch the very rare error would have been boasting to his friends about replacing his whole development team with a team that cost 1/10 the price in Noida.
Coding agents can't replace developers _right now_, and it's unclear whether scaling the current approach will allow them to at any point, but at some point (and maybe that's not until we get true AGI) they will be able to replace a substantial chunk of the developer workforce, but a significant chunk of developers will be highly resistant to it. The people you're complaining about are simply too early.
I feel bad for my friends that are married with kids working at places like microsoft, telling me how their copilot usage is tracked and they fear that if they don't hit some arbitrary weekly metric they will fall victim to the next wave of layoffs.
> I feel bad for my friends that are married with kids working at places like microsoft, telling me how their copilot usage is tracked and they fear that if they don't hit some arbitrary weekly metric they will fall victim to the next wave of layoffs.
It's not just Microsoft. Other smaller employers are aping those guys.
My employer has an utterly ridiculous PowerBI dashboard tracking how much every employee uses LLM-based tools. Make sure to enable the Premium models, because otherwise you won't get credit! There are naughty lists for people whose usage is too low. Luckily the usage goals (for now) aren't very high.
However, they're also getting anal about tracking tasks, and the powers at be have asserted control over all aspects of story creation and work process. There's speculation they're going to start tracking story completion rates, and demanding measured productivity increases.
>why not just keep it voluntary, why force it on people?
People hate learning new tools, even if they are more efficient. People would rather avoid doing things than learning a tool to do it efficiently.
Even in this thread you can see simeone who is / was a Vim holdout. But the improvement from Vim to IDE will be a fraction of the difference compared to AI integrated IDEs.
They said the same thing about the loom. "I'm an artist, no machine can replace me!" Now it's all done by machine, and none of us worry about it. We're in the early stages of the same process with AI; history rhyme.
> If they’re really so confident on the LLM’s effectiveness, why not just keep it voluntary, why force it on people? The results will be there in the outcome of the shipped product for all to see.
It’s a bit like returning to the office. If it’s such an obvious no-brainer performance booster with improved communication and collaboration, they wouldn’t have to force people to do it. Teams would chomp at the bit to do it to boost their own performance.
I am living this but the CEOs of my company are also "active" programmers.
Even when I already hear from them that "it helps them in language they do not know" (which is also my experience) I get frown upon if on meetings I do not say that I am "Actively using AI to GENERATE whole files of code".
I use AI as rubber duck, generate repetitive code or support me when going into an new language or technology, but as soon as I understand it, most of the code given for complete, non hobby, enterprise level projects contains either inefficient code or just plain mistakes which takes me ages to fix for new technologies.
You want some advice from a 16 years-in-industry person? Not so long, but long enough: software, as all industries, are driven by metrics.
Metrics we understand, but that managers miss to understand sometimes. You are a means to produce. With the advent of AI, some very hyped people think and wish they could get rid of programmers.
You know what I am doing in the meantime? I built a business. I am just finishing the beta deploymet test now. It can go wrong? Yes.
But otherwise, be faced to be a number, a production chain thing in the future. Besides that, when they can get rid of you, you are going to be in a bad positio to move at that time. Invest time now in an alternative strategy, if you can.
Of course, I know nothing about you so I might be totally wrong. If you already have financial safety for the rest of your life, this does not apply as hard.
I am trying to buy more freedom on my side. I already had some, but not enough. You will not be free with a manager to report to, even if you are thinking you are doing a better job than he thinks. Or even if you are objetively doing it.
They will care about delivery in a rush, politics, self-interest (this is not different from any human, but you will depend on them), etc.
The forcing argument has merit, it should not be forced, in fact they should say very little about how we do our work.
But the "rubber-stamp" framing is wrong, if it were true then you would not be needed at all. It's actually harder to use gen AI than to code manually. Gen AI has a rapid pace and overwhelming quantity of code you need to ensure is not broken in non-obvious ways. You need to layer constraints, tests, feedback systems for self repair and handle memories across contexts.
I recently vibe coded 100K LOC across dozens of apps, I feel the rush of power in coding agents but also the danger. At any moment they could hallucinate, misunderstand or use a different premise than you did. Going past 1000 LOC requires sustained focus, it will quickly unravel into a mess otherwise.
Just yesterday I made some notes about a program I'd like to write (hobby project, to be open sourced). After that, the thought of using an LLM to turn the notes into an implementation squished the joy right out of me.
The better the code generated by LLMs get, the less there is of an incentive to say "no". Granted, we're not nearly there yet (even though media reports and zealous tech bros say otherwise).
But - and this is especially true for organizations that already had a big code quality problem before the LLMs showed up - if the interpreter / compiler accepts the code and it superficially looks like it does what it should, there is pressure to simply accept it.
Why say no when we could be done now and move on!? Rubber-stamp it and let's go! Sigh. Maybe I'm overly pessimistic, reading the raves about LLMs every day grinds me down.
I find LLM generated code ends up pushing review/maintenance burden onto others. It "looks" right at first glance, and passes superficial tests, so it's easy to get merged. But then as you build on top of it, you realize the foundations are hastily put together, so a lot of it needs to be rewritten. Fine for throwaway or exploratory work, but heaven help you if you're working in a project where people use LLMs to "fix" bugs generated by previous LLM generated code.
So yes it does increase "velocity" for the person A who can get away with using it. But then the decrease in velocity for person B trying to build on top of that code is never properly tracked. It's like a game of hot potato, if you want to game the metrics you better be the one working on greenfield code (although I suppose maintenance work has never been looked at favorably in performance review; but now the cycle of code rot is accelerated)
> I find LLM generated code ends up pushing review/maintenance burden onto others. It "looks" right at first glance, and passes superficial tests, so it's easy to get merged. But then as you build on top of it, you realize the foundations are hastily put together, so a lot of it needs to be rewritten.
This describes most projects I've been on where there wasn't a thorough RFC process?
Where I'm seeing the sweet spot right now:
1. Have a detailed RFC
2. Ticket out the work
3. Feed the RFC and ticket to the LLM via MCP
4. Have your refactoring and design patterns textbooks close at hand so you can steer the LLM properly when things start to get messy. "DRY this out" or "implement this using X pattern" tend to be highly effective prompts
5. Use agents or other LLMs to review code for RFC compliance, test coverage, etc. (this isn't as effective as I'd like it to be right now, skill issue probably)
6. When there are bugs, force the LLM to do TDD - say "We're observing a bug in production, here are the reproduction steps, write a failing test that covers this code path." Obviously check that the test is a real test and not slop. Then, prompt the LLM to fix the isue.
I unfortunately was handed a Claude-coded react native app that I've been beating into shape over the last couple of months.
Today I realized that there was a fundamental error in the architecture and now I have to port several thousand lines of typescript into C++. I really hate it here.
I don’t think AI is anywhere near the point of replacing humans yet. The main issue here is whether the use of these tools is forced or voluntary. I’ve seen quite a few companies where the boss tries to fully adopt AI productivity tools, but faces strong resistance during implementation.From the employees’ perspective, the boss might be moving too aggressively without considering the practical realities. From the boss’s perspective, it’s frustrating to see the pushback.This tension seems to be a common challenge at the current stage of AI adoption.
If tech companies are this stupid, it ought to be very easy to disrupt and usurp them by simply shipping competing code that works. In that sense, the author is painting an incredibly bright picture of the future of the software industry: one where founders don't have to be particularly talented to hit the jackpot.
Okay, but now what? Clearly, the industry is trending towards an entirely new style of doing programming. What are the longterm options going to be for those who don't enjoy this? Especially when there is a good chunk of people embracing it and adopting tools faster than any other tools for this proffesion have been adopted in the past. How will this end?
"Needless to say, they’d still want you to take the responsibility. If bugs or tickets get raised on the shipped code, it’s you who gets fired, not the copilot or chatgpt - though the larger narrative or news headlines next day would still be, 'AI is eating jobs'!"
I'm also reminded of that legendary old IBM quote from 1979:
"A computer can never be held accountable. Therefore a computer must never make a management decision."
65 comments
[ 3.4 ms ] story [ 67.5 ms ] threadOr clones a template repo and only tweaks a few files
Or imports libraries with code I've never read
That's not a career-switching issue, that's a company-switching issue. Most people will work for at least one company in their career where the people in charge are dickheads. If you can't work around them, go find a different company to work for. You don't have to throw away an entire career because of one asshole boss.
Also fwiw, resistance is more effective than you think. You'd be surprised how often a dickhead in charge is either A) easy to call the bluff of, or B) needs someone to show them they are wrong. If you feel like you're going to quit anyway, put your foot down and take a stand.
Really? This sounds absurd. "Instead of" means it doesn't matter how shit your work is as long as you're burning tokens? Or it doesn't matter how good your work is if you're not burning tokens? Name and shame
No opinion on whether or not this applies to the current moment. But maybe someone should try forcing Dvorak layout on everyone or something like that for a competitive edge!
GPT-5: Typesetting and paste-up, film prepress/stripping, CMYK color separations, halftone screening, darkroom compositing/masking, airbrush photo retouching, optical film compositing/titling, photochemical color timing, architectural hand drafting, cartographic scribing and map lettering, music engraving, comic book lettering, fashion pattern grading and marker making, embroidery digitizing and stitching, screen-print color separations
For people who are so confident (which, I'm not), it's an obvious step; developers who don't want to use it must either be luddites or afraid it'll take their jobs. Moving sales people to digital CRMs from paper files, moving accountants to accounting software from paper ledgers and journals, moving weavers to power looms, etc etc -- there would have been enthusiasts and holdouts at every step.
The PE-bro who's currently boasting to his friends that all code at a portfolio has to be written first with Claude Code and developers are just there to catch the very rare error would have been boasting to his friends about replacing his whole development team with a team that cost 1/10 the price in Noida.
Coding agents can't replace developers _right now_, and it's unclear whether scaling the current approach will allow them to at any point, but at some point (and maybe that's not until we get true AGI) they will be able to replace a substantial chunk of the developer workforce, but a significant chunk of developers will be highly resistant to it. The people you're complaining about are simply too early.
It's not just Microsoft. Other smaller employers are aping those guys.
My employer has an utterly ridiculous PowerBI dashboard tracking how much every employee uses LLM-based tools. Make sure to enable the Premium models, because otherwise you won't get credit! There are naughty lists for people whose usage is too low. Luckily the usage goals (for now) aren't very high.
However, they're also getting anal about tracking tasks, and the powers at be have asserted control over all aspects of story creation and work process. There's speculation they're going to start tracking story completion rates, and demanding measured productivity increases.
People hate learning new tools, even if they are more efficient. People would rather avoid doing things than learning a tool to do it efficiently.
Even in this thread you can see simeone who is / was a Vim holdout. But the improvement from Vim to IDE will be a fraction of the difference compared to AI integrated IDEs.
It’s a bit like returning to the office. If it’s such an obvious no-brainer performance booster with improved communication and collaboration, they wouldn’t have to force people to do it. Teams would chomp at the bit to do it to boost their own performance.
Even when I already hear from them that "it helps them in language they do not know" (which is also my experience) I get frown upon if on meetings I do not say that I am "Actively using AI to GENERATE whole files of code".
I use AI as rubber duck, generate repetitive code or support me when going into an new language or technology, but as soon as I understand it, most of the code given for complete, non hobby, enterprise level projects contains either inefficient code or just plain mistakes which takes me ages to fix for new technologies.
Metrics we understand, but that managers miss to understand sometimes. You are a means to produce. With the advent of AI, some very hyped people think and wish they could get rid of programmers.
You know what I am doing in the meantime? I built a business. I am just finishing the beta deploymet test now. It can go wrong? Yes.
But otherwise, be faced to be a number, a production chain thing in the future. Besides that, when they can get rid of you, you are going to be in a bad positio to move at that time. Invest time now in an alternative strategy, if you can.
Of course, I know nothing about you so I might be totally wrong. If you already have financial safety for the rest of your life, this does not apply as hard.
I am trying to buy more freedom on my side. I already had some, but not enough. You will not be free with a manager to report to, even if you are thinking you are doing a better job than he thinks. Or even if you are objetively doing it.
They will care about delivery in a rush, politics, self-interest (this is not different from any human, but you will depend on them), etc.
Just choose freedom :D
Why are programs - the result of the ingenuity of people working in software field - not protected against AI slop stuff.
Why is there not any kind of narrative out there describing how fake and soulless is code written by any AI agent?
But the "rubber-stamp" framing is wrong, if it were true then you would not be needed at all. It's actually harder to use gen AI than to code manually. Gen AI has a rapid pace and overwhelming quantity of code you need to ensure is not broken in non-obvious ways. You need to layer constraints, tests, feedback systems for self repair and handle memories across contexts.
I recently vibe coded 100K LOC across dozens of apps, I feel the rush of power in coding agents but also the danger. At any moment they could hallucinate, misunderstand or use a different premise than you did. Going past 1000 LOC requires sustained focus, it will quickly unravel into a mess otherwise.
The better the code generated by LLMs get, the less there is of an incentive to say "no". Granted, we're not nearly there yet (even though media reports and zealous tech bros say otherwise). But - and this is especially true for organizations that already had a big code quality problem before the LLMs showed up - if the interpreter / compiler accepts the code and it superficially looks like it does what it should, there is pressure to simply accept it.
Why say no when we could be done now and move on!? Rubber-stamp it and let's go! Sigh. Maybe I'm overly pessimistic, reading the raves about LLMs every day grinds me down.
So yes it does increase "velocity" for the person A who can get away with using it. But then the decrease in velocity for person B trying to build on top of that code is never properly tracked. It's like a game of hot potato, if you want to game the metrics you better be the one working on greenfield code (although I suppose maintenance work has never been looked at favorably in performance review; but now the cycle of code rot is accelerated)
This describes most projects I've been on where there wasn't a thorough RFC process?
Where I'm seeing the sweet spot right now:
1. Have a detailed RFC
2. Ticket out the work
3. Feed the RFC and ticket to the LLM via MCP
4. Have your refactoring and design patterns textbooks close at hand so you can steer the LLM properly when things start to get messy. "DRY this out" or "implement this using X pattern" tend to be highly effective prompts
5. Use agents or other LLMs to review code for RFC compliance, test coverage, etc. (this isn't as effective as I'd like it to be right now, skill issue probably)
6. When there are bugs, force the LLM to do TDD - say "We're observing a bug in production, here are the reproduction steps, write a failing test that covers this code path." Obviously check that the test is a real test and not slop. Then, prompt the LLM to fix the isue.
Today I realized that there was a fundamental error in the architecture and now I have to port several thousand lines of typescript into C++. I really hate it here.
I'm also reminded of that legendary old IBM quote from 1979: "A computer can never be held accountable. Therefore a computer must never make a management decision."