Ask HN: Engineers working AI tools. Are you working more or less?
Curious whether AI tooling are making engineers more productive with more free time or more productive with even less free time.
22 comments
No question. I am far more productive because it lets me get to the answers I need far faster.
I'm more of a iterative solver rather than someone who tries to solve it all into their head the first go. And ai tools are perfect for that kind of approach.
I'm more of a iterative solver rather than someone who tries to solve it all into their head the first go. And ai tools are perfect for that kind of approach.
Besides not wanting to give most enjoyable part of the work to LLMs, reviewing LLM-generated code is much more daunting compared to writing the code yourself. So, I only use it for a very narrow and specific 2-3 liners, e.g. some arcane Win32 API calls, where I'd otherwise be browsing some old forums.
This is my reflection as well. I find myself spending MORE time reviewing LLM-generated code and also spending time thinking through LLM generated choices, which, at many times are inefficient or bloated. Keeping the LLM on the right rails takes up more time, even with lengthy agent.md and claude.md files to manage behaviors.
Work less time on work, work more time on my side project, because it can let me use less time to get job done, so I have more time on my side project.
And AI has expanded my boundaries — for example, I used to know nothing about image processing, but now with AI help, I’ve learned and use the technology and even built an initial product prototype using OpenCV, which helped my side project get off the ground successfully.
And AI has expanded my boundaries — for example, I used to know nothing about image processing, but now with AI help, I’ve learned and use the technology and even built an initial product prototype using OpenCV, which helped my side project get off the ground successfully.
I'd guess about 20-50% overall productivity, given that only a fraction of my work is writing code.
We have to spend a good amount of time organizing the requirements, as it never comes perfectly from product management, as well alignments and weighting tradeoffs from the architecture.
Reviewing code also became a very daunting and time-consuming task.
We have to spend a good amount of time organizing the requirements, as it never comes perfectly from product management, as well alignments and weighting tradeoffs from the architecture.
Reviewing code also became a very daunting and time-consuming task.
I would like to tell about an unexpected benefit I enjoy as a new farther of a 4 month old. I do mostly 'spec-driven-development' meaning most of the time I am iterating and discussing how things currently work, what are the goals, caveats, edgecases, gotchas etc. Only at the very end actual implementation starts. These spec-documents are on a higher abstraction level than raw code and are far easier to hop on and off and the now frequent interuptions are less detrimental.
Working the same, the nature of the work has changed. Less time spent on the minutia of syntax and project scaffolding. More time spent on how the minutia compose into a larger system.
This is a great indication of where engineers will be spending more of their time: complexity composing.
I have a rough time calculating how much more productive AI tooling has made me, because when it does save me time (simple mocking, greenfielding, proof-of-concept), - it saves me a ton of time. Conversely when it fails hard on me I can lose a lot of time and also patience.
The trick is developing the intuition to know when to cut your losses early and instead of continuing to fight the LLM, just implement it yourself.
The trick is developing the intuition to know when to cut your losses early and instead of continuing to fight the LLM, just implement it yourself.
Depends on the task at hand.. Some tasks like information collection for planning have definitely improved and made easy, but the quality is still not at a level where you can use it without doing an overview.
Overall, it's just the illusion of more productivity or free time. It's just made grunt work easier while making testing/review even more important than before
Overall, it's just the illusion of more productivity or free time. It's just made grunt work easier while making testing/review even more important than before
I'm still working my regular hours, I think I'm getting considerably more work done in that time.
The type of work has changed too - mind numbing refactors across dozens of files are easier, for new feature work I have time to build several prototypes before picking a direction.
The type of work has changed too - mind numbing refactors across dozens of files are easier, for new feature work I have time to build several prototypes before picking a direction.
AI tools are super helpful if you know what they are good for and where the limits are currently. If you work at a place where your expected "time" is constant, aka has a good work/life balance, then its important to be more productive because your competitors will certainly be.
There are parts of the SDLC that cannot be made more productive with AI - all the human parts, communication about changes, testing often involves manual work, etc. So if you have management that just thinks a blanket X% more productivity is achievable across the board, find someplace else to work, its about as smart as a RTO mandate because they like seeing butts in seats.
There are parts of the SDLC that cannot be made more productive with AI - all the human parts, communication about changes, testing often involves manual work, etc. So if you have management that just thinks a blanket X% more productivity is achievable across the board, find someplace else to work, its about as smart as a RTO mandate because they like seeing butts in seats.
Doing less, more productive, but I know its limits. I treat is as my "little assistant" - able to accomplish a lot but without the experience or cognition to make good decisions independently. Been using it a lot for framing out basic unit tests, governance configuration files, bulk renaming, building test files on a known syntax, etc. On the side, I've been using it to throw together PoCs I can quickly test to see if I like my an implementation or need to take my idea back to the drawing board.
I stopped using AI for projects that I care about. For projects that I don't care about—absolutely, I am working way less.
AI made us 10x more productive. Management noticed. Now we are expected to ship 10x more features.
The free time was a lie we told ourselves.
The free time was a lie we told ourselves.
>> AI made us 10x more productive.
I'm wondering what you are doing to feel that much of a productivity boost? There have been three occasions since 2022 where I felt concretely 10X more productive. The rest of the time I'm not feeling a huge / direct impact. While it isn't necessarily drastically more productive in a linear sense (churning out more of the same stuff for instance) things have radically changed nonetheless.
I'm wondering what you are doing to feel that much of a productivity boost? There have been three occasions since 2022 where I felt concretely 10X more productive. The rest of the time I'm not feeling a huge / direct impact. While it isn't necessarily drastically more productive in a linear sense (churning out more of the same stuff for instance) things have radically changed nonetheless.
It will be interesting if it leads to a bloat of unnecessary features that customers dont really want
Prediction. The rise of articles discussing AI attributed bloat and technical debt.
As they say.. Garbage in..
As they say.. Garbage in..
From that standpoint, it's definitely happening already. But removal is easier too now. The real question is whether teams will have the discipline to delete. Most won't, but those who do will build better products.
I am beginning to notice more "features" in apps that suspiciously raise questions: "Was that feature really needed and was the AI to sneak it in there!?"
Always the case
Working more, because of coding errors.