DEV Community

Cover image for We Keep Hearing About AI Productivity. The QA Group Chat Told a Different Story.
xulingfeng
xulingfeng

Posted on AI-assisted

We Keep Hearing About AI Productivity. The QA Group Chat Told a Different Story.

Poll reveals hidden job market struggles

An anonymous poll, a debate about multimodal testing, and some uncomfortable questions about who benefits from the AI rush.

Recently, I published an article on DEV.to about our company's AI testing practices and the organizational changes that followed.

It was selected for DEV's weekly Top 7 Featured Posts and included in the official DEV newsletter.

The comments were more interesting than I expected. Readers from different backgrounds started sharing their own experiences. They talked about outdated PRDs, agents reporting the same bug repeatedly, isolated test environments, and the mess that automation can expose when people have been quietly filling in the gaps.

One reader from the manufacturing industry even compared our experience with his factory's automated material-tracking project. Different industry, same problem: once you automate a process, all the messy handoffs that people used to handle manually become much harder to hide.

I was still thinking about those discussions when something else caught my attention.

It happened in a QA community group I'm part of.

1. Sixteen People Said They Weren't Employed

Sixteen People Said They Weren't Employed
The group has around 500 members. Someone started an anonymous poll asking a simple question:

Are you currently employed?

When I checked the results, 76 people had voted.

Status People Percentage
Employed 60 78.9%
Not currently employed 16 21.1%

Sixteen people.

To be clear, this isn't an unemployment survey of the software testing industry. The poll was anonymous, and we have no idea why those 16 people weren't working. They could have been laid off, resigned, or simply be between jobs. Only 76 out of roughly 500 group members participated, so there's no reason to treat this as an industry-wide statistic.

Still, the number got my attention.

I also have a former colleague who works in software testing. They've been out of work for six months and still haven't found another job.

That's no longer just a number in an anonymous poll. It's someone I know and have worked with.

I don't know all the details of their job search, and I wouldn't automatically blame AI for their situation. But six months without finding another role is difficult to ignore.

The group chat quickly filled up with comments.

All we're seeing is layoffs. Nobody's hiring.

Almost 50. Who's going to hire me now?

Is there still a future in this field?

Some people suggested changing careers. Others said it was time to prepare for what's coming.

One comment summed up the mood rather well:

With all this AI-driven productivity improvement, it's getting harder and harder to keep up.

Then, almost as quickly as the conversation started, it turned to AI testing.

2. Can AI Really Compare an App Screen with Its Design?

Can AI Really Compare an App Screen with Its Design?
Someone asked whether AI-powered test automation could compare an actual app screen against its UI design, checking element sizes, colors, positions, and other visual details.

The suggestions came quickly.

Some people proposed OCR to extract information from the design and the actual screen. Others suggested multimodal models. There were also concerns about maintenance: what happens when the UI changes slightly? Do we have to rebuild the whole thing?

Someone joked:

How well will it actually work? Who knows?

I joined the discussion.

My answer was that it's technically possible, but the AI needs enough context and sufficiently detailed instructions. Just throwing a demo page at a model and expecting it to understand everything won't get you very far.

I also pointed out that using a top-tier multimodal model for this kind of work can consume a lot of tokens.

Then came my questions:

Is management paying for the tokens?

And:

If not, they can go to hell.

I made the point one more time:

You can use a top-tier multimodal model, sure. But the token consumption can be huge. If management isn't paying for it, to hell with that.

Yes, I really said that. 😆

The joke aside, I meant it.

There's a difference between proving that something can be done and proving that it's worth doing.

OCR, DOM inspection, image comparison, and multimodal models can all help with UI verification. The right approach depends on what you're trying to check. Not every visual problem needs an expensive model.

But once you start taking screenshots, sending them for analysis, comparing results, and repeating the process across multiple runs, the bill can grow quickly.

Before adopting a solution like this, I'd want to know how many real issues it catches, how many false positives it produces, how much it costs to run, and how much effort is needed to maintain it when the UI changes.

If a company expects testers to use AI but leaves them to pay for their own tokens, something is wrong.

I've seen people in that group joking about collecting free credits from different platforms every morning before starting work.

It's funny, but think about it: employees are being told to embrace AI and improve productivity, while some are trying to keep their experiments running on whatever free credits they can find.

If a company wants AI-driven productivity, AI usage needs to be part of the company's budget.

3. AI Writes the Code, AI Tests It. What Could Possibly Go Wrong?

AI Writes the Code, AI Tests It. What Could Possibly Go Wrong?
Another part of the conversation made me laugh.

Someone described an almost completely automated development process:

Describe a requirement, call the product skill, generate a demo and PRD, call the technical skill, generate the technical documentation, architecture, interfaces, and framework. Write the code, generate the tests with AI, run everything, and ship it. Done. A pile of bugs goes live.

That last sentence says a lot.

Someone else complained:

The boss uses AI to generate a demo, decides the idea is viable, and then expects everyone to build it.

Another person added:

Management expects us to deliver exactly that.

And someone joked:

Sounds like all we need is the boss. Everyone else can leave.

I've seen why this attitude develops. A demo can look convincing, and AI can generate a surprising amount of code in a very short time. It's easy to look at that output and assume the hard part is already done.

But a working demo isn't a validated product.

A generated PRD isn't proof that the requirements have been properly discussed. Generated code and generated tests don't automatically share the same understanding of what the system is supposed to do.

I ran into a version of this problem in our own testing work.

In one knowledge-base project, AI found 36 potential defects, while manual testing found 11. After review, 30 defects were confirmed as valid. AI had contributed 21 of them.

Those numbers were encouraging, but something else caught my attention.

Some of the reported issues weren't actually implementation bugs. Product and development had already agreed on changes, but nobody had updated the PRD.

The AI was following the document. The people were following an agreement that existed only in conversations.

In the past, testers often bridged that gap through experience and informal communication. They knew who to ask and which version of the requirements the team was actually following.

The AI didn't have that context.

It did exactly what it had been asked to do, and the result was a test report full of issues that looked legitimate but weren't necessarily bugs.

That's one of the things I find interesting about AI testing. It doesn't just test the software. It can expose how disconnected the people building that software actually are.

4. Why Is Every Company Suddenly Chasing AI?

Why Is Every Company Suddenly Chasing AI?
As the group conversation continued, people started discussing the industry rather than individual jobs.

One member argued that many Chinese companies keep a close eye on what's happening in the US, where much of the current technology leadership comes from. One member said Chinese companies keep a close eye on what's happening in the US, and estimated that the gap between the two markets was at least six months.

That's their estimate, not a figure I've independently verified. But the broader observation is worth discussing.

A lot of companies seem afraid of being left behind.

One company adopts AI for coding, so others feel they need it too. Another introduces AI testing, and suddenly everyone wants an AI testing strategy. When large technology companies start talking about full-stack AI transformation, smaller companies feel pressure to follow.

Someone in the group put it bluntly:

Everyone just copies what's already working elsewhere. AI cuts costs and improves efficiency. What boss wouldn't like that?

Fair point.

But how many companies have actually worked out where AI fits into their business, rather than adopting it simply because competitors are doing so?

Another member brought up education and talent development. For years, the emphasis had been on catching up and getting new technology into production quickly. Now, they argued, the demand is shifting toward people who can innovate, lead, and break new ground.

Whether that shift is happening quickly enough is another question. But the contrast is interesting: following someone else's lead and creating something new require very different skills.

There was also a comment about management thinking:

Most companies are run by professional managers focused on making it through this year. How can you expect them to think long-term?

I understand the frustration behind that.

When a company is under pressure, cost reductions and headcount cuts are easy to measure. Building new capabilities, developing people, and investing in ideas that might pay off several years later are much harder to justify.

AI fits very neatly into the first category. Its potential for the second is real, but much harder to guarantee.

5. Is AI Productivity Becoming a Sales Pitch of Its Own?

Is AI Productivity Becoming a Sales Pitch of Its Own?
One group member raised a more cynical possibility:

Everyone is selling tokens. They need to create the impression that AI improves productivity and that companies will fall behind if they don't use it. That pushes everyone to adopt AI. And with the market already in bad shape, companies can use AI as another reason to cut jobs.

I wouldn't go as far as saying that the entire AI productivity story is manufactured. I use these tools myself, and I've seen what they can do in testing, code analysis, and bug discovery.

But there are commercial incentives here that are worth recognizing.

AI providers want companies to use their models. Companies want to lower costs. Employees are being told that they need to become more productive with AI.

Those interests can reinforce one another, even when nobody has fully worked out the business case.

A company might adopt AI because it doesn't want to fall behind, rather than because it has identified a clear problem that AI can solve.

And once AI is in place, the conversation can quickly shift from what the technology can improve to how many people the company can do without.

One person in the group pointed out another part of the problem: the IT industry went through years of aggressive hiring. Large numbers of people entered the market, and companies expanded their teams rapidly.

Now the market looks very different.

From that perspective, AI isn't necessarily the original cause of the employment pressure. It may be the trigger that makes an existing imbalance more visible.

I think that's an important distinction.

We shouldn't assume every job reduction is caused by AI. Market conditions, years of hiring, changing business models, and company decisions all matter.

But AI gives companies another way to reorganize work, and that can accelerate changes that were already underway.

6. We Keep Pushing Harder. Where Does It End?

We Keep Pushing Harder. Where Does It End?
One line from the group chat stuck with me:

We keep trying to outdo everyone else, until we end up working ourselves out of a job.

Someone else described the result as a possible vicious cycle.

The IT industry has always moved quickly. One group member joked that if you stop learning for a year or two, you'll fall behind. And people in their thirties and forties are still pushing themselves to learn new things constantly.

I know what that feels like.

New frameworks, new models, new agents, new tools. Before you've finished getting comfortable with one, three more have appeared.

Companies want employees to become more productive. Employees want to stay competitive. AI providers want more adoption. And companies watch their competitors to make sure they're not falling behind.

Everyone has a reason to run faster.

But here's the question: what happens when every company tries to do more with fewer people, while the number of available jobs doesn't grow at the same pace?

We could end up in a strange situation where every company becomes more efficient, but the people working in the industry feel less secure.

We might work so hard trying to beat everyone else that we end up making the whole situation worse for ourselves.

7. Embrace AI, or Get Fired Now. Embrace AI, and Get Fired Later.

Embrace AI, or Get Fired Now. Embrace AI, and Get Fired Later.
There was one more line in the group chat that deserves to be repeated:

If you don't embrace AI, you'll get fired immediately. If you do embrace AI, you'll just get fired later.

It's a joke, but not a particularly comfortable one.

Companies tell employees to learn AI, use AI, and improve productivity. Employees do their best to keep up.

But what happens after they become more productive?

Some worry that they'll end up automating their own jobs. Others are concerned that age and a changing job market will make it harder to find another role if they lose the current one.

People in the group were already suggesting that others should change careers or start preparing for something different.

I don't think learning AI is pointless. And I certainly don't think refusing to use it will protect anyone's job.

But embracing AI doesn't guarantee job security either.

Learning AI can make you more capable. It can't guarantee that a company will continue to need you.

Those are two different things.

Individuals can improve their skills, but they can't control the job market, company budgets, or every organizational decision.

I don't think it's fair to put the entire burden of career survival on whether someone is willing to learn the latest AI tool.

Final Thoughts

I don't want to use the 21.1% from this poll to claim that the testing industry is experiencing mass unemployment.

It was an anonymous poll in a group of around 500 people. Only 76 participated, and 16 said they weren't currently employed. We don't know why.

It isn't an industry-wide survey.

But I think the conversation is worth remembering.

People were worried about losing their jobs, then spent time discussing how AI could help them perform more advanced testing.

They were worried about being replaced by AI, while exploring how multimodal models could improve their automation.

They were concerned about token costs, while looking for free credits from different platforms.

They questioned whether AI was really improving productivity, while worrying that their companies might fall behind if they didn't adopt it.

And I have a former colleague who has been out of work for six months and still hasn't found another job. That makes the conversation feel a lot less theoretical.

I'm embracing AI too. I'm building AI testing workflows, experimenting with agents and models, and changing some of my own assumptions about what automation can do.

I see the possibilities. I'm not interested in pretending otherwise.

But I also don't think productivity gains automatically solve business problems, create new markets, or guarantee better opportunities for employees.

We can build faster, generate more code, run more tests, and produce more output than before.

The harder question is what all that extra productivity is actually going to achieve, and who gets to benefit from it.

There's a Chinese idiom I keep coming back to: 管中窥豹 — looking at a leopard through a narrow tube. You can see a few markings, but never the whole animal.

looking at a leopard through a narrow tube.
That's what this poll and the group chat offer: a glimpse, not a complete picture of the QA industry. Seventy-six votes cannot tell us how widespread the problem is, and one group conversation cannot explain what's happening across every company.

But it does reveal a few things worth paying attention to: job anxiety, pressure to adopt AI, arguments over token costs, and uncertainty about who actually benefits when productivity goes up.

We may not be seeing the whole leopard. But what we can see is worth taking seriously.

If we're all becoming more productive, why are so many people becoming less confident about their future?

Top comments (88)

Collapse
 
nyaomaru profile image
nyaomaru •

This really resonates with what I’ve been experiencing too. 👀

AI has absolutely increased my productivity, and I think its basic coding ability is already very strong.

But higher output also creates new kinds of work.

I now spend a significant amount of time reviewing AI-generated changes, and then building workflows to automate parts of that review process itself. 😹

There’s also more time spent on requirements and design, because once implementation becomes faster, I can suddenly handle many more tasks at the same time.

And that creates another problem: context switching.

When we’re juggling more tasks at once, it becomes harder to focus deeply on each one, and I think that can quietly reduce the overall quality of the work.

So for me, the challenge isn’t really

“Can AI produce more?”

It obviously can.

The harder question is

how we manage everything it produces.

If we blindly generate code, tests, documents, and features without understanding why we need them, we’re not necessarily becoming more productive. We may just be creating a new kind of debt: a growing pile of outputs that someone still has to review, understand, maintain, and eventually clean up. 😹

At the same time, I’m still very optimistic about AI.

I think the important thing is learning how to work with it well, rather than simply trying to generate as much as possible.

AI can help us build better things much faster, but we still need humans to decide what is worth building, what is actually correct, and what should not be built at all.

For me, that balance is probably the most interesting challenge of the AI era. 😸

Picked as gem
Collapse
 
xulingfeng profile image
xulingfeng •

Haha this is so spot‑on and mirrors exactly what I wrote in the article 😂
From my QA perspective, my automated test agent happily runs through the night and spits out dozens and dozens of defect reports like there’s no tomorrow. It makes it look as if productivity has exploded, but the trick is that it hasn’t erased the work. It just shifts it right into my lap.
I end up spending a lot of my time sorting out what’s real, what’s just stale PRD noise, and what needs to be tossed out entirely. Even when I build extra workflows to auto filter obvious junk, there’s still that pile waiting for me every morning. And yeah, with more items to review and validate, I keep jumping between threads, and it gets harder to hold onto that deep focus we all love.
AI can absolutely crank out code, test cases and reports faster than we ever could. It just does not know what is worth caring about. If we let it run wild, we are not really building faster. We sign ourselves up for a never ending cleanup shift, and pile up a shiny new mountain of AI generated debt.
The fun part is this is not about holding AI back. It is about learning to be the captain instead of the full time janitor. The machine does the exploring, and we decide what actually matters💪

Collapse
 
nyaomaru profile image
nyaomaru •

Haha yes, exactly! 😹

I really like your “captain instead of the full-time janitor” analogy. 🏴‍☠️

That’s probably the balance we need to find.

Let AI explore, generate, test, and surface possibilities at a speed we never could before, but keep humans responsible for deciding what actually matters.

Otherwise, “more productivity” can quietly become “more things waiting for someone to clean up.” 😹

And the context-switching part is especially real. Even if each individual task gets faster, handling many more of them at once doesn’t necessarily make the whole system better. 😿

AI is incredibly powerful, but I think the real skill now is learning how to control the flow of that output instead of drowning in it. 😸💪

Thread Thread
 
xulingfeng profile image
xulingfeng •

Haha I’m happy that analogy landed well 🏴‍☠️ It really is that balance. We enjoy the speed AI brings, but we have to keep from getting drowned in all its output. Controlling the flow instead of just cleaning it up is the real trick 😂

Collapse
 
dafili profile image
Renhua Wei •

Duplicates and invalid findings are the same bug seen from two ends: the finding carries no evidence of its own, so "again" and "new" both need a human to reread it. Give every item three fields before it is allowed into the list - the failing assertion, the environment fingerprint (commit + fixture), and the exact input that triggered it. A second report with the same assertion on the same fingerprint is a +1 on the existing row, not a new row; in my own queue that path prints accepted=false (already queued) and costs one log line instead of a triage slot. Two different assertions on one fingerprint is the case worth escalating, because that is not a duplicate, that is a fix that did not take, and it should reopen the item instead of closing twice.

Collapse
 
xulingfeng profile image
xulingfeng •

That's a solid approach to making findings evidence-driven. But I think there's another layer upstream that deserves attention: Is the test oracle itself still valid?

If the PRD isn't updated when requirements change, an AI agent may keep executing perfectly valid test cases against outdated expectations.

For example, a field that used to be mandatory becomes optional. The implementation is updated, but the PRD and test cases aren't. The agent then reports every instance of an empty field as a defect.

The finding may have a valid assertion, environment fingerprint, and exact input. It may even be perfectly reproducible. But it's still not a real bug.

So I'd add another question before triage: Are we validating the software against the current requirements, or just validating it against whatever documentation happens to exist?

Evidence quality matters, but requirement freshness matters just as much.

Collapse
 
dafili profile image
Renhua Wei •

Stamp every test with the PRD revision it was written against and gate on it: if git diff --quiet "$oracle_rev"..HEAD -- prd/ reports a diff, emit stale_oracle and route it to the requirement owner instead of filing a defect. One comparison turns your example into a non-event at zero triage cost — the field that became optional never reaches the queue, the spec diff does.

Thread Thread
 
xulingfeng profile image
xulingfeng •

That's actually where the problem gets harder in my experience.The PRD is already outdated, and nobody updates it. In that case, git diff reports no change, so the gate treats an old oracle as if it were still valid.
It can detect changes to the document, but it can't tell us whether the document still reflects the actual business requirements.For example, a field was originally mandatory but later became optional. The development team changed the implementation, but nobody updated the PRD or the test cases. The AI keeps reporting empty fields as defects, and technically, all its evidence is correct.
I think we need another layer here: someone has to own the validity of the requirements, not just their version history.Otherwise, we're simply automating the execution of outdated assumptions.
And that's a much harder problem to solve with code alone.

Thread Thread
 
dafili profile image
Renhua Wei •

PRD-vs-PRD diff goes blind exactly when the doc gets abandoned, so take the change signal from the code that did record it: git log "$oracle_rev"..HEAD -G'(required|optional)' -- src/validators/ names the commit where that field's rule flipped, and a failing assertion whose field has a validator commit but no PRD commit is spec_lag — the hash and the author are the requirement owner you're asking for. Validity itself still can't be computed, so make it a signed artifact instead of a code path: one line in oracle_overrides.yaml (field, optional_since, owner, date) is what closes the item, and until that line exists the finding parks in needs_owner and never reaches triage. Nobody has to rewrite the PRD, but somebody has to sign one line, and the depth of needs_owner is the only honest spec-debt number in the pipeline.

Thread Thread
 
xulingfeng profile image
xulingfeng •

Love this idea. It uses code history and a simple override file instead of chasing perfect PRD updates, and the pending‑owner queue becomes a true metric for spec debt. But here’s the catch: much of the code is now written and committed by AI, so git history may not reliably show who actually made the requirement decision.

Thread Thread
 
dafili profile image
Renhua Wei •

Author identity is the wrong field to read. Require a trailer on the decision instead: every commit touching src/validators/ carries Req-Id: <prd-rev>, and git log "$oracle_rev"..HEAD --grep="Req-Id: $id" -- src/validators/ names the commit where that rule changed, no matter whether a human or an agent wrote it. Empty result means nobody recorded the decision, which is itself the stale_oracle signal you route to the requirement owner.

Thread Thread
 
xulingfeng profile image
xulingfeng •

Brilliant. Using a dedicated Req‑Id trailer rather than relying on the commit author keeps the traceback working even when AI writes and commits the code. An empty log directly signals an unrecorded decision.

Thread Thread
 
dafili profile image
Renhua Wei •

Make the trailer non-optional so the empty log cannot happen: in commit-msg, git interpret-trailers --parse < "$1" | grep -q '^Req-Id: ' || exit 1 rejects any commit touching src/validators/ without the stamp. Then the traceback never has to infer a decision from an empty range.

Thread Thread
 
xulingfeng profile image
xulingfeng •

That’s a solid gate. Enforcing the Req‑Id in the Git commit hook means there is no way to skip logging the requirement decision. We no longer need to guess what happened from an empty trace.

Thread Thread
 
dafili profile image
Renhua Wei •

Your commit-msg hook is client-side: git commit --no-verify walks straight past it. Mirror the same git interpret-trailers --parse | grep -q '^Req-Id: ' in a server-side pre-receive hook, where a missing trailer exits 1 and the push is refused - then the empty range is impossible, not just unlikely.

Collapse
 
mestonecold profile image
Shruti Shahi •

Great post, mate! Laughed while sitting here, unemployed as a fresher who didn't get a PPO because of manager politics😭🙌🏻. Keep posting!

Collapse
 
xulingfeng profile image
xulingfeng •

Hahaha thanks so much for your support! There’s an old saying in China: when the gods fight, it’s the mortals who get hurt.🤣 Hope you land that great role soon.

Collapse
 
mestonecold profile image
Shruti Shahi •

China and it's sayings😭 watched so many cdramas lol, this is one common thing in them all😂

Thread Thread
 
xulingfeng profile image
xulingfeng •

Hahaha we have tons of old sayings like this in China. Each one is like a neat little compressed file, so fun 😂

Thread Thread
 
mestonecold profile image
Shruti Shahi •

Yeah and hella dramatic flashbacks😭 especially the noble family dramas😂

Thread Thread
 
xulingfeng profile image
xulingfeng •

Hahaha wow, you’re watching the same short dramas my parents love 😂 Though I’d suggest not binging them too often. Too many short videos can wear down your patience. It gets harder to sit through a full movie or a long article. I barely install any short drama apps on my phone. I prefer novels, especially time‑travel stories. They’re so fun.🤣

Thread Thread
 
mestonecold profile image
Shruti Shahi •

That's great too yk, I watch animes because now I can't find the patience to sit through a drama series like I used to during school days😭 So i just read thrillers and horror and watch just movies at most but rarely 🥲 else most of the times i tend to leave them and start working again😂 I'm a mess ig🫠

Thread Thread
 
xulingfeng profile image
xulingfeng •

Hahaha fellow fan! I love anime too, especially manga. I’m hooked on all kinds of isekai stories. Honestly, I’m pretty much obsessed with time‑travel novels and comics. I guess there’s no saving me 😂
I’d take it easy with thriller and horror books though. I once read a horror novel late at night. Right at the scariest part, the lights in my room went out for no reason😱.I almost cried from fright, hahaha.🤣🤣🤣

Thread Thread
 
mestonecold profile image
Shruti Shahi •

LOL, I laughed so hard 😂 I recently watched The Summer Hikaru Died; I'll start buying mangas someday fs! I haven't had even one in my entire lifetime of 23 years😭even though for 5 years I was busy watching real-life drama😂 I was learning numbers in Japanese just yesterday XD.

Thread Thread
 
xulingfeng profile image
xulingfeng •

Most things are digital these days, but physical manga really hits different. I got my first Doraemon book when I was four, and I’ve been a huge fan ever since! Back then there weren’t digital versions, so everyone just bought physical copies to read.😅

Thread Thread
 
mestonecold profile image
Shruti Shahi •

True that, even the books I read, I never read them online; I directly bought them, even though I got my mood spoiled a few times later because it turned out to be completely different from what I looked forward to😭For instance, I bought "Before the coffee gets cold" without reading anything other than the summary at the back of the cover; it seemed interesting- time travel and stuff but then it turned out to be really overwhelming, and I somehow struggled to finish it in like 3 months or so😭. That's why I don't read emotional stuff😅.

Thread Thread
 
xulingfeng profile image
xulingfeng •

Hahaha, three months to get through it sounds rough! I only get time to read because my commute is long. It takes me 40 minutes by subway one way, so 80 minutes round trip every day. That’s my reading window. It’s really hard to squeeze in reading time any other part of the day.😅

Thread Thread
 
mestonecold profile image
Shruti Shahi •

Can understand...🫡

Collapse
 
leob profile image
leob • • Edited

"From that perspective, AI isn't necessarily the original cause of the employment pressure. It may be the trigger that makes an existing imbalance more visible" - yep, there have been years of ferocious hiring - companies were scrambling to pick up anyone who could program their way out of a paper bag - there HAD to be a correction to that, and that correction would probably have come without AI, but AI is probably accelerating it ...

"The harder question is what all that extra productivity is actually going to achieve, and who gets to benefit from it" - that's very philosophical! What is the point and the purpose of it all - is 'work' only a means, or is it also a 'goal'? You'd say it's "only a means", but that's probably a simplification - work gives many people a sense of purpose ...

And regarding "who gets to benefit from it" - all of us (well, most of us) hope it's not just the oligarchs and the "Big Tech bros" who will benefit from it - but that's also an issue for the people who govern us to consider ...

The way I see it, this is just the fourth (fifth?) Industrial Revolution, and it will cause big changes in society and in the economy - but, like previous Industrial Revolutions, it does bring productivity gains, and hopefully the benefits will "trickle down" to all of us, not just accumulate at the top ...

Collapse
 
xulingfeng profile image
xulingfeng •

Your Industrial Revolution comparison also made me think about Marx's Das Kapital, and some ideas from Mao's writings, particularly On Contradiction and On the Ten Major Relationships.

Marx raised an important question about who owns the means of production and who benefits from the productivity created by them. I think that question is becoming relevant again with AI. The models, computing infrastructure, data, and platforms are becoming important means of production. But the people using them don't necessarily own or control them.

Mao's writings offer another angle worth considering: technological and economic changes don't happen in isolation. They create new contradictions with existing social and organizational structures. If productivity changes much faster than the way work, employment, and wealth are organized, those contradictions become harder to ignore.

There's also a practical question here. We shouldn't judge progress only by how much more a company can produce with fewer people. We should also look at what actually changes in people's lives. Do they get more time, better opportunities, and a greater share of the value they help create?

I suppose this brings us back to your point about work and purpose. If AI can reduce the amount of human labor needed, that could be an opportunity to give people more freedom. But whether that opportunity becomes a reality depends on how society chooses to organize and distribute the gains.

Technology can expand what is possible. It doesn't decide who benefits.

And here's a slightly crazy thought to end with: maybe a few years from now, each of us will have a little AI robot companion following us around, helping with everyday tasks. Things could get a lot more sci-fi than we imagine. Hahaha! 🤣

Picked as gem
Collapse
 
leob profile image
leob •

Yeah I like your take, I "gemmed" this one, lol ...

"If AI can reduce the amount of human labor needed, that could be an opportunity to give people more freedom" - if the predicted productivity gains materialize then I could just see us moving from our current 5 day work week to a 3 or 4 day work week ...

I mean, that would make all the sense in the world, wouldn't it? Our (great-)grandparents worked 6 days in a week (Saturdays as well), so it's a natural evolution ...

Making this actually happen will need "new" (or stronger) social contracts, because certain people (looking at you, oligarchs and billionaires) might want to push back against this - just employing fewer people, or the same people but working fewer hours BUT for a lower salary, would probably sound attractive to them (more $$$ in their pockets and higher profit margins for their shareholders) ...

Your (or actually Marx's, lol) comment about "who owns the means of production and who benefits from the productivity created by them" is also spot on - I think at this moment a huge unbalance is being created between the oligarchs/billionaires/tech bros, versus the rest of us ...

Maybe we should start running more LLMs ourselves at home, lol? :P

Picked as gem Thread Thread
 
xulingfeng profile image
xulingfeng •

Haha, exactly! 🤣 Technological progress is supposed to make life easier. Take the agent I trained: once I clock out, it keeps running and carrying on my work at the office. In a way, it’s like having a second me.
Theoretically, I could work roughly three days and still deliver about what I used to get done in five. But in reality, I just end up with even more test projects piled on my plate. We used to hold things back by saying we didn’t have enough hands — well, that excuse doesn’t really work anymore 😂.
And speaking of running LLMs at home… Jensen Huang must be sitting pretty. GPUs stay perpetually short in supply and just keep climbing in price.😂

Thread Thread
 
leob profile image
leob •

Jensen Huang made a "whoopsie" ;-) and will have some questions to answer, but I have the feeling he'll be okay :-)

Thread Thread
 
xulingfeng profile image
xulingfeng •

Probably just something to shift everyone’s attention away 😄

Thread Thread
 
leob profile image
leob •

Yeah it's a bit silly how the news channels are all over it and going crazy, while there are more important topics, but yeah nothing new there :P

Thread Thread
 
xulingfeng profile image
xulingfeng •

Exactly! The media loves to chase flashy headlines. It’s always easy to distract people from the bigger, more important issues 😆 Still, it’s better to keep our feet on the ground and focus on our own work and life, hahaha.

Thread Thread
 
leob profile image
leob •

Yeah it's just for the clicks and views - superficial "news" that belongs in the tabloids and in the gossip magazines!

Collapse
 
jes_p_d4f61f7aa2ec405a418 profile image
Dev_PJS •

Your 36-defect list is where my queue rule earns its keep: an item only leaves the list when its closing is recorded — done, dropped, or deferred, with a date. Quietly vanishing items were how I lost whole threads of work without noticing. The queue is boring now, and boring is the point.

Collapse
 
xulingfeng profile image
xulingfeng •

That's a good point. Finding a bug is one thing, making sure it doesn't get lost is another.🤣

With AI generating more findings, I can see why your queue rule matters. Every item needs an outcome, even if the outcome is simply deciding not to fix it.

And I like your last sentence. A boring queue is a good queue. 😄

Collapse
 
akhourianmolkumar profile image
Akhouri Anmol Kumar •


competitor?😂

NICE WRITEUP bro really..

Thread Thread
 
xulingfeng profile image
xulingfeng •

🤣🤣🤣

Thread Thread
 
akhourianmolkumar profile image
Akhouri Anmol Kumar •

🫡🫡

Thread Thread
 
xulingfeng profile image
xulingfeng •

💪🤣💪

Collapse
 
technogamerz profile image
𝐓𝐡𝐞 𝐋𝐚𝐳𝐲 𝐆𝐢𝐫𝐥 •

Top 7 😁

Collapse
 
xulingfeng profile image
xulingfeng •

🙌🤣🤣Luckly,哈哈哈

Collapse
 
technogamerz profile image
𝐓𝐡𝐞 𝐋𝐚𝐳𝐲 𝐆𝐢𝐫𝐥 •

哈哈 you deserve it! Congrats 😍

Thread Thread
 
xulingfeng profile image
xulingfeng •

Haha thank you! 😆 It’s nice to see this piece resonating with people.

Thread Thread
 
technogamerz profile image
𝐓𝐡𝐞 𝐋𝐚𝐳𝐲 𝐆𝐢𝐫𝐥 •

But your badge???

Thread Thread
 
xulingfeng profile image
xulingfeng •

🤣我也不知道,不知不觉就这样了

Thread Thread
 
technogamerz profile image
𝐓𝐡𝐞 𝐋𝐚𝐳𝐲 𝐆𝐢𝐫𝐥 • • Edited

Good! But where are your top 7 badge?🤔

Thread Thread
 
xulingfeng profile image
xulingfeng •

What? 可能还没发吧😆能上top7已经很开心了

Thread Thread
 
xulingfeng profile image
xulingfeng •

😆Get It!

Collapse
 
madhabcoder profile image
Nilamadhab Senapati •

The bit about automation exposing all the messy handoffs that people used to quietly handle is the most honest thing I've read on this. The productivity number always counts the code that got written, never the person who used to notice the PRD was out of date. Hope your former colleague lands something soon.

Collapse
 
xulingfeng profile image
xulingfeng •

Totally agree. Productivity dashboards love to celebrate how much we build, but they never see all the soft work that keeps the whole system glued together. Catching a stale PRD, smoothing messy handoffs, knowing when something just does not line up none of that gets counted. I hope my former colleague finds a great role soon, they brought so much of that quiet, valuable work to the team.

Collapse
 
madhabcoder profile image
Nilamadhab Senapati •

Glue work is the right name for it. It's invisible right up until the person doing it leaves, and then everyone wonders why things suddenly feel slower. Fingers crossed for them.

Thread Thread
 
xulingfeng profile image
xulingfeng •

So true. Glue work keeps everything running quietly. I’m hoping he finds a great job soon.💪

Collapse
 
sylwia-lask profile image
Sylwia Laskowska •

Great post again, Lingfeng! 😍😍😍

Collapse
 
xulingfeng profile image
xulingfeng •

Hahaha, thanks! This was pretty spontaneous. That 500-person QA group had been almost silent for months, then suddenly the floodgates opened and everyone started talking about AI. Guess people have been holding it in for a while. 😂

Collapse
 
lakhyajit profile image
Lakhyajit Changmai •

The 36 vs 11 result makes review cost visible: confirmed findings matter more than raw volume. I also liked the point that stale requirements can turn a technically correct test into a misleading report. Recording the requirement version alongside each finding could help separate product defects from spec drift.

Collapse
 
xulingfeng profile image
xulingfeng •

Love this idea. Linking findings to requirement versions is a clean way to spot spec drift.

Collapse
 
lakhyajit profile image
Lakhyajit Changmai •

Agreed. Keeping the requirement version attached to a finding helps separate implementation drift from a changed acceptance criterion. Preserving the source wording or revision alongside a normalized identifier also makes later reviews much easier.

Collapse
 
kielltampubolon profile image
Kiell Tampubolon •

The detail about people collecting free credits every morning made me laugh and then wince a little. From the security side, that's where the budget problem turns into a data problem: screenshots of a staging build with a test account visible in the corner, or the PRD for an unreleased feature, going to whichever platform had credits that day under someone's personal login. When management isn't paying for the tokens, it usually isn't reviewing those vendors either. A company key with a per-team spend cap fixes both at once, and it costs far less than finding your roadmap sitting in someone's free tier. Did anyone in the group say whether their company has an approved tool list at all?

Collapse
 
xulingfeng profile image
xulingfeng •

No one in the group brought that up. I also grab those free credits every morning, kind of like an insurance policy. If our company’s AI gateway goes down someday, I’ve got something to fall back on, hahaha 😂

Collapse
 
kielltampubolon profile image
Kiell Tampubolon •

Ha, insurance is a fair way to put it, and the timing is funny: Microsoft 365 was down for most of last night here, so having a fallback isn't a silly idea. I'd just keep the free tier for things you'd be fine seeing on a public forum and leave work files out of it. Thanks for the fun thread!

Thread Thread
 
xulingfeng profile image
xulingfeng •

Couldn’t agree more. It’s smart to keep work data away from free tiers. I enjoyed this conversation a lot 😆

Some comments may only be visible to logged-in visitors. Sign in to view all comments.