Hacker Newsnew | past | comments | ask | show | jobs | submit | wreath's commentslogin

At work we are literally forced to use AI and it’s part of our performance review. Even though I really like coding by hand, I have to now use AI so I can keep my job. I will try this out though, 2 days per week using AI and the rest handcoding, enough to stave off the inevitable lay off perhaps.

Surely it can’t be hard to token max at work the same fucking way people have games Jira metrics for years and years.

If I’m ever in that position (everything I work on it air-gapped, it’ll never happen) I would make it a priority to figure out how to game that bullshit metric so I could get on with solving actual problems.

I imagine a lot of people do this. Metric becomes a target, etc.


I recommend trying "make this code more enterprise", it seems to pull in the joke and start overengineering everything and giving them absurd names.

And what of the original author is not there anymore?


The world will not end. I’ll get there.


Even with enough money, you may not be able to attract/keep talented engineers who are willing to put up with such a work environment (the codebase itself, and probably the culture that led to its state) and who want to ship well built/designed software but are slowed down by the mess.


This completely depends on the current economy.

When you work with F500s you end up seeing code and culture that is absolute balls and that I would never work directly for all the time. And yet roles are always filled. And when the economy gets bad, they have decent engineers.

I call it the fast food quality theory of economics. When the economy is good, low pay jobs tend to have low quality employees and it shows in their products. When the economy gets bad higher quality employees end up downgrading because of layoffs and the quality of these low tier jobs improves.


PMs do different things in different organizations.

In my last job, PMs were responsible for identifying problems that were worth solving and align with the overall company vision and plans within the owned domain, and design+engineering decided how to solve those problems and what to build. Of course with collaboration w/ the PMs (and EMs).

The job before that, PMs wrote jira tickets and nagged engineering when tickets will be delivered. The "what problems to solve and what to build" questions came straight from CEO/CTO.


I’m not saying you’re wrong but as a senior PM, the engineers I work with see about 10-20% of what I actually do in a week, so in general engineers are not a good judge of the utility of product management.


> i see how one they cannot think and feel clearly anymore if your neighbours dream constantly about your elimination. All sides just need to stop with that hatred. It leads to so much pain.

I think by now we all know this is a straw man, considering the disproportionate amount of power both parties have. There is absolutely no excuse left for what Israel has been doing in Gaza.


[flagged]


What's wrong with their charter?


I dont think parent was questioning it, sounded they were more curious but thanks for explaining because i wasnt sure myself.

Re: safe from LLMs, id imagine the level of rigor in sys engineering is higher so maybe people are more wary of LLM produced code?


I'm not sure. You'd have to define "level of rigor". TypeScript has a vastly more expressive type system than C, for example, so given their respective prevalence in their domains, you could easily say that coding apps nowadays is actually more rigorous. There's Rust, but somehow people write lots of apps in it. And so on.

I don't think systems programming is inherently harder than writing apps. You deal with different sets of problems (users stubbornly misusing your UI vs. hardware vendors notoriously lying in the manuals; hundreds of dependencies vs. endemic NIH syndrome; etc.), but coding is, for the most part, the same thing everywhere. IME, the "level of rigor" (as in "kinds and pervasiveness of actions taken to ensure correctness") depends much more on actual people or organizations than on the domain.


You're probably talking about cases when systems engineers develop apps. In my experience, when app developers develop apps, it's a mess.


Yeah to get the definitive answers, sure AI is quicker. Google is more like the librarian pointing you at possibly good resources to get your answers from after reading the materials and there are a lot of good learning opportunities there. LLMs just give you the answer and robs you of those opportunities.


Exactly! How do other parts of the organization deal with this avalanche of features in terms of documenting, pricing and packaging, marketing, selling and getting feedback on them. How do users adopt these features and incorporate them in their workflows so fast? Never in my career was the speed of writing code alone the bottleneck.


> deal with this avalanche of features

You mean avalanche of bugs and technical debt.


Technical debt is never a problem now since only AI reads code /s


I dont even think you need to be neurodivergent or anything to answer this question like the parent’s cofounder did.

From one side, we call ourselves problem solvers, on the other hand we are not satisfied with simple solutions to these problems. If im interviewing for a job, i should be expected to behave and solve hypothetical problems the way id do it on the job. If that screws up your script, you probably suck at hiring and communicating your expectations.


We also aren't mind readers and interviews are a crapshoot. Some companies do in fact want you leveraging tools and API's in your solutions. Some want to probe your foundational technical knowledge. Ideally they will poke you towards the answer they want, but not always. But few will let you know ahead of time for some reason.


Thats interesting. While i do get mentally tired after a session of focused coding, i feel like i have accomplished something. Using AI for coding feels similar to spending hours doom scrolling reels. Less engaging but Im drained as hell at the end.


I'd argue you still have to stay engaged, if not more-so. Its a different type of engagement. Look at you: You're the CTO now.


It's hard to be engaged when you are constantly jumping from one thing/prompt to another vs you are actually doing the work.


Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: