3 ms·

I am more and more convinced that many engineers are very defensive about AI and would rather point out any flaw than think how to leverage the tools to get any

I am more and more convinced that many engineers are very defensive about AI and would rather point out any flaw than think how to leverage the tools to get any benefit out of them. Just the other day I used cursor and iteratively implemented stories for 70 .vue files in few hours, while also writing documentation for the components and pages, and with the documentation being further fed to cursor, to write many E2Es, something that would've taken me at least few days if not a week. When I shared that with some coworkers they went into a hunt to find all the shortcomings (often petty duplication of mocks, sometimes missing a story scenario, nothing major). I found it striking as we really needed it and it provides tangible benefits: - domain and UI stakeholders can navigate stories and think of more cases/feedback with ease on a UX/UI pov without having to replicate the scenarios manually doing multiple time consuming repetitive operations in the actual applications - documentation proved to be very valuable to a junior that joined us this very january - E2Es caught multiple bugs in their own PRs in the weeks after And yet, instead of appreciating the cost/benefit ratio (something that should characterise a good engineer, after all, that's our job) of the solution, I was scolded because they (or I) would've done a more careful job missing that they never done that in the first place. I have many such examples, such as automatically providing all the translation keys and translations for a new locale, just to find cherry picked criticism that this or that could've been spelled differently. Of course it can, what's your job if not being responsible for the localisation? That shouldn't diminish that 95% of the content was correct and provided in few seconds rather than days. Why they do that? I genuinely feel some feel threatened, most of those reek insecurity. I can understand some criticism towards those who build and sell hype with cherry picked results, but I cannot but find some of the worst critics suffering of Luddism.

krainboltgreene 2y ago
Given how much damage it's done to our industry without any appreciable impact on the actual system's efficacy it makes sense to me that experts in a mechanism are critical of people telling them how effective this "tool" is for the mechanism. I suppose it's simply easier to think of them as scared and afraid of losing their lobs to robots, but the reality is most programmers already know someone who lost their job to a robot that doesn't even exist yet.
- chchchangelog 2y ago
  [flagged]
  - jazzyjackson 2y ago
    You sound like a markov chain.
    - cutnpaste 2y ago
      [flagged]
      - jazzyjackson 2y ago
        You can just cat the file, what does piping to echo give you? Edit: it gives you nothing, because echo echos its arguments, ignores stdin
  - __loam 2y ago
    Least insane hackernews commenter
__loam 2y ago
To me it sounds like you're rushing the work and making mistakes then dismissing people who point it out.
- epolanski 2y ago
  Maybe I didn't express myself correctly but it was neither planned nor budgeted and my client is a small team with more projects than people. I strongly believed in the value provided by setting up stories, writing more documentation and E2Es in the few hours I had and it did. Due to the boilerplate-y nature of the task LLMs proved to be a great fit, having me reviewing more than writing thousands of lines of code across almost 80 files in few hours rather than multiple days. The fact that the cost/benefit ratio is lost on so many people is appalling but unsurprising in a field that severely lacks the "engineering" part and is thus uneducated to think in those terms.
namanyayg 2y ago
I'd love to hear more about how you're using cursor for testing especially e2e tests for frontend applications. In my experience since cursor doesn't know how a frontend app looks like nor can it run a browser, the tests it writes are often inane. Can you tell me what testing stack do you use, and how do you approach the process of writing large tests for mature codebases with cursor?
- epolanski 2y ago
  What I've done was to use composer recursively. First I had it write stories based on the pages and components. I had obviously to review the work and further add more cases. Then I had it generate a markdown file where it documented the purpose and usage and apis for those and combined it with user stories written in our project management tool which I copy pasted in different files. It helped our user stories are written in a gerkin-like fashion (when/and/or/then) which is computer-friendly. As most of the components had unique identifiers in terms of data-test attributes I could further ask it to implement more e2e cases. Overall I was very satisfied of the cost/benefit ratio. Stories were the most complicated part as Cursor tended to redeclare mocks multiple times rather than sharing them across, and it wasn't consistent in the API choices it made (storybook has too many ways to accomplish the same thing). E2Es with Playwright were the easiest part, the criticism here was that I used data attributes (which users don't see) over elements like text. I very much agree with that, as I myself am a fan of testing the way that users would. Problem is that as our application is localized I had to compromise in order to keep them parallel and fast, as many tests do change locale settings which was interfering, as new pages loading had a different locale then expected. I'm not the only one using such attributes for testing, I know it's common practice in big cushy tech too. One thing I want to note, you can't do it in few prompts, it feels like having to convince the agent to do what you ask him iteratively. I'm still convinced of the cost/benefits ratio and with practice you get better at prompting. You try to get to the result you want by manual editing and chatting, then feed the example result to generate more.
  - fragmede 2y ago
    > One thing I want to note, you can't do it in few prompts, it feels like having to convince the agent to do what you ask him iteratively. Success with current day LLMs isn't about getting them to output perfect code. Having them do the pets their good at - rough initial revs - and then iterating from there, is more effective. The important metric is code (not LoC, mind you) that gets checked into git/revision control and sent for PR and merged. Realizing when convincing the LLM to output flawless code ends up taking you in circles and is unproductive, while not throwing away the LLM as a useful tool is where the sweet spot is.
swiftcoder 2y ago
Man generates 1000s of lines of (buggy) boilerplate across 70 files, which was neither budgeted nor planned, and his coworkers are annoyed at him... News at 11
- epolanski 2y ago
  There was no bugs, where did you read that?
  - swiftcoder 2y ago
    You mentioned your coworkers found shortcomings, I assume that implies the presence of bugs (be it in code, documentation, or even just more unnecessary code to maintain)
    - epolanski 2y ago
      No code at all is the best code, that's a given. It was a matter of cost vs benefit ratio which ultimately resulted in net benefits. Stakeholders like designers and product don't see nor care that some mocks are repeated or that the sub optimal API is used in stories. Customers don't care why the application is broken, they care it is and the additional E2Es catched multiple bugs. Juniors would appreciate documentation and stories even if they might be redundant. I think the biggest fallacy committed in evaluating the benefits of LLMs is in comparing them with the best output humans can generate. But if those humans do not have the patience, energy or time budget to generate such output (and more often than not they don't) I think one should evaluate leveraging LLMs to lower the required effort and trying to find an acceptable sweet spot, otherwise you risk falling into Luddism. Even as of 2025 humans outperform machines in tailoring 200 years after Luddism appeared, that doesn't change that it's thanks to machines that lifted humans out of a lot of the repetitive work that we can cloth virtually every human for pennies. That hasn't removed the need for human oversight in tailoring or that very same role behind higher quality clothes.
v3xro 2y ago
I think the mention of Luddism is a nice tell. From Wikipedia: > The Luddites were members of a 19th-century movement of English textile workers who opposed the use of certain types of automated machinery due to concerns relating to worker pay and output quality. I think the push for AI is the modern-day equivalent for software development - to move making programs from being labour intensive to being capital intensive. There are some of us who don't see it as a good thing. As for my personal perspective - I view AI as the over-confident senior "salesman" programmer - it has no model for what sort of things it cannot do yet when it attempts anything it requires a lot of prompting to get somewhere which looks passable. My values for developing software is reliability and quality - which I had hoped we were going to achieve by further exploring advanced type systems (including effect systems), static analysis, model checkers, etc. Instead the "market" prioritises short-term garbage creation to push sales until the next quarterly cycle. I don't have much excitement for that.
- gessha 2y ago
  To add to your points, the job market is looking pretty grim, and it feels natural to feel threatened by layoffs and AI replacement. If there was no threat from layoffs, a lot less people would be against using a tool that makes their job easier.
uludag 2y ago
What your coworkers are experiencing could be signs of Luddism. This Luddism could be a very natural and human reaction. The life situation of your coworkers could vary widely: maybe some are financially insecure living paycheck to paycheck, maybe some have made a significant purchase and cant afford to loose their job, maybe someone had a new child born and doesn't have the time to make huge investments in their workflow and is afraid of drowning in the rising tide. Maybe they're pushing back against performative business, not wanting everyone to feel that to be productive they need to constantly be modifying 100s of vue files. Maybe they're jealous of you and your cybernetic superpowers; jealousy is a completely normal human feeling. Or maybe you were going about this in an ostentatious manner, appearing to others as tooting your own horn. Maybe there's a competition for promotions and others feel the need to make such political moves like shooting your work down. Maybe this work that you did was a political move. Technologies are deployed and utilized in certain human contexts, inside certain organizational structures, and so on. Nothing is ever a plain and simple, cold hard cost-benefit analysis.

krainboltgreene 2y ago

Given how much damage it's done to our industry without any appreciable impact on the actual system's efficacy it makes sense to me that experts in a mechanism are critical of people telling them how effective this "tool" is for the mechanism. I suppose it's simply easier to think of them as scared and afraid of losing their lobs to robots, but the reality is most programmers already know someone who lost their job to a robot that doesn't even exist yet.

chchchangelog 2y ago
[flagged]
- jazzyjackson 2y ago
  You sound like a markov chain.
  - cutnpaste 2y ago
    [flagged]
    - jazzyjackson 2y ago
      You can just cat the file, what does piping to echo give you? Edit: it gives you nothing, because echo echos its arguments, ignores stdin
- __loam 2y ago
  Least insane hackernews commenter

__loam 2y ago

To me it sounds like you're rushing the work and making mistakes then dismissing people who point it out.

epolanski 2y ago
Maybe I didn't express myself correctly but it was neither planned nor budgeted and my client is a small team with more projects than people. I strongly believed in the value provided by setting up stories, writing more documentation and E2Es in the few hours I had and it did. Due to the boilerplate-y nature of the task LLMs proved to be a great fit, having me reviewing more than writing thousands of lines of code across almost 80 files in few hours rather than multiple days. The fact that the cost/benefit ratio is lost on so many people is appalling but unsurprising in a field that severely lacks the "engineering" part and is thus uneducated to think in those terms.

namanyayg 2y ago

I'd love to hear more about how you're using cursor for testing especially e2e tests for frontend applications. In my experience since cursor doesn't know how a frontend app looks like nor can it run a browser, the tests it writes are often inane. Can you tell me what testing stack do you use, and how do you approach the process of writing large tests for mature codebases with cursor?

epolanski 2y ago
What I've done was to use composer recursively. First I had it write stories based on the pages and components. I had obviously to review the work and further add more cases. Then I had it generate a markdown file where it documented the purpose and usage and apis for those and combined it with user stories written in our project management tool which I copy pasted in different files. It helped our user stories are written in a gerkin-like fashion (when/and/or/then) which is computer-friendly. As most of the components had unique identifiers in terms of data-test attributes I could further ask it to implement more e2e cases. Overall I was very satisfied of the cost/benefit ratio. Stories were the most complicated part as Cursor tended to redeclare mocks multiple times rather than sharing them across, and it wasn't consistent in the API choices it made (storybook has too many ways to accomplish the same thing). E2Es with Playwright were the easiest part, the criticism here was that I used data attributes (which users don't see) over elements like text. I very much agree with that, as I myself am a fan of testing the way that users would. Problem is that as our application is localized I had to compromise in order to keep them parallel and fast, as many tests do change locale settings which was interfering, as new pages loading had a different locale then expected. I'm not the only one using such attributes for testing, I know it's common practice in big cushy tech too. One thing I want to note, you can't do it in few prompts, it feels like having to convince the agent to do what you ask him iteratively. I'm still convinced of the cost/benefits ratio and with practice you get better at prompting. You try to get to the result you want by manual editing and chatting, then feed the example result to generate more.
- fragmede 2y ago
  > One thing I want to note, you can't do it in few prompts, it feels like having to convince the agent to do what you ask him iteratively. Success with current day LLMs isn't about getting them to output perfect code. Having them do the pets their good at - rough initial revs - and then iterating from there, is more effective. The important metric is code (not LoC, mind you) that gets checked into git/revision control and sent for PR and merged. Realizing when convincing the LLM to output flawless code ends up taking you in circles and is unproductive, while not throwing away the LLM as a useful tool is where the sweet spot is.

swiftcoder 2y ago

Man generates 1000s of lines of (buggy) boilerplate across 70 files, which was neither budgeted nor planned, and his coworkers are annoyed at him... News at 11

epolanski 2y ago
There was no bugs, where did you read that?
- swiftcoder 2y ago
  You mentioned your coworkers found shortcomings, I assume that implies the presence of bugs (be it in code, documentation, or even just more unnecessary code to maintain)
  - epolanski 2y ago
    No code at all is the best code, that's a given. It was a matter of cost vs benefit ratio which ultimately resulted in net benefits. Stakeholders like designers and product don't see nor care that some mocks are repeated or that the sub optimal API is used in stories. Customers don't care why the application is broken, they care it is and the additional E2Es catched multiple bugs. Juniors would appreciate documentation and stories even if they might be redundant. I think the biggest fallacy committed in evaluating the benefits of LLMs is in comparing them with the best output humans can generate. But if those humans do not have the patience, energy or time budget to generate such output (and more often than not they don't) I think one should evaluate leveraging LLMs to lower the required effort and trying to find an acceptable sweet spot, otherwise you risk falling into Luddism. Even as of 2025 humans outperform machines in tailoring 200 years after Luddism appeared, that doesn't change that it's thanks to machines that lifted humans out of a lot of the repetitive work that we can cloth virtually every human for pennies. That hasn't removed the need for human oversight in tailoring or that very same role behind higher quality clothes.

v3xro 2y ago

I think the mention of Luddism is a nice tell. From Wikipedia: > The Luddites were members of a 19th-century movement of English textile workers who opposed the use of certain types of automated machinery due to concerns relating to worker pay and output quality. I think the push for AI is the modern-day equivalent for software development - to move making programs from being labour intensive to being capital intensive. There are some of us who don't see it as a good thing. As for my personal perspective - I view AI as the over-confident senior "salesman" programmer - it has no model for what sort of things it cannot do yet when it attempts anything it requires a lot of prompting to get somewhere which looks passable. My values for developing software is reliability and quality - which I had hoped we were going to achieve by further exploring advanced type systems (including effect systems), static analysis, model checkers, etc. Instead the "market" prioritises short-term garbage creation to push sales until the next quarterly cycle. I don't have much excitement for that.

gessha 2y ago
To add to your points, the job market is looking pretty grim, and it feels natural to feel threatened by layoffs and AI replacement. If there was no threat from layoffs, a lot less people would be against using a tool that makes their job easier.

uludag 2y ago

What your coworkers are experiencing could be signs of Luddism. This Luddism could be a very natural and human reaction. The life situation of your coworkers could vary widely: maybe some are financially insecure living paycheck to paycheck, maybe some have made a significant purchase and cant afford to loose their job, maybe someone had a new child born and doesn't have the time to make huge investments in their workflow and is afraid of drowning in the rising tide. Maybe they're pushing back against performative business, not wanting everyone to feel that to be productive they need to constantly be modifying 100s of vue files. Maybe they're jealous of you and your cybernetic superpowers; jealousy is a completely normal human feeling. Or maybe you were going about this in an ostentatious manner, appearing to others as tooting your own horn. Maybe there's a competition for promotions and others feel the need to make such political moves like shooting your work down. Maybe this work that you did was a political move. Technologies are deployed and utilized in certain human contexts, inside certain organizational structures, and so on. Nothing is ever a plain and simple, cold hard cost-benefit analysis.