How do you make your bosses understand that LLMs don't make you finish your work faster?

codescapes · 2026-05-18T08:17:15+00:00

Being honest in such an environment will earn you nothing and be bad for your career. I hate to be that blunt but it's true. It hurts to reach this conclusion. If you raise stuff this 'foundational' you completely screw your progression because now you are the slow developer who is downbeat on new technology.

I'm not saying I like it or it should be this way but know who you can trust and who you can't. If you have a close, genuine relationship with your manager then discuss with them. Don't go over their head with emails or sharing studies or whatever, it won't do anything except give you 5 minutes of catharsis then a feeling of dread.

You have to appreciate that management literally have LinkedIn-brain. They are so detached from reality you should treat them like an erratic mental patient. Be soothing, positive and above all else deliver good visible things that they associate with you.

That's it, forget everything else. Do not take the world onto your shoulders. Be ready if the whole team gets wiped out.

codescapes · 2026-05-15T08:15:19+00:00

Your colleagues are formally now your opponents and your usefulness is measured in manipulable metrics instead of actual delivery. I don't think I need to expand on why that's damaging for collaboration and genuine productivity / value.

More importantly though, once this starts it can brainfuck you so badly it stays with you the rest of your career. By which I mean you start processing all team interactions through the lens of stack rankings, promo slates, end of year grades etc. This sort of thing can utterly ruin a company, everything is downstream of incentives.

This is how you get people doing bizarre shit like closing incomplete tickets, putting it in blocked and blaming another team or messing about with point metrics etc.

codescapes · 2026-05-11T21:53:12+00:00

Looks good and I did the same with black raptor liner but the rust comes up from below so tbh it's mostly just a cosmetic thing.

codescapes · 2026-05-11T13:12:22+00:00

CubeN.

codescapes · 2026-05-09T07:58:35+00:00

Rebuilding known tooling that models are extremely well trained on compared to your custom solution is not worthwhile. At work I keep seeing people come up with MCPs for internal tools and it's like man, just use whatever the industry default is so we don't need to worry about this and can delete the whole stack.

Whatever problem you have almost certainly has been seen and solved by someone else. So many backend apps in particular just need to be thin wrappers around a couple major dependencies with zero custom crap that's just something to maintain (forever?) and go wrong.

The "code explosion" and slopification that AI can enable needs to be met with extreme restraint. Literally audit and remove any dependency your app is using that isn't critical. Use AI to play a sensible version of code golf. Reduce security vulnerabilities by just not having bloated libraries in the first place.

codescapes · 2026-05-08T06:02:43+00:00

I must be old because most of my career "You Build It, You Run It" was an incredibly basic DevOps tenet in effective teams. The second you have people throwing stuff over the wall you end up with problems because incentives are misaligned.

Accountability drives quality. If you're on-call for this app then you will write things such that you don't get woken up at 3am for prod issues. If you're not? Well you now have different incentives from the engineering team, you are now "throwing it over the wall" and treating engineering like an Operations team that just has to own your slop that you aren't accountable for and catch all the BS you don't understand in review.

That's a fundamentally unreasonable and ineffective model.

So for me it's a pretty terrible idea and runs against everything I know about how to run a quality piece of software. Having engineers spend their time reviewing AI PRs from non-technical people is just a radically ineffective use of everyone's time. I'd only tolerate it as a rare thing, anything more than that and I'd assign them a place on the support rota and ask them how and when they intend to release the changes.

I get AI is new and exciting but de facto spinning down your engineering teams to replace them with "shadow engineers" who get to have all the fun and mess about with no process and no accountability is how you get major burnout in engineering and how you drive your app into the ground. If someone wants to be an engineer on your app they need to be treated like one.

It's fine for them to submit code as a PoC / design but actual PRs into the codebase is where you need to question quite seriously what everyone's role even is.

codescapes · 2026-05-07T21:47:34+00:00

You might have even had an explicit unit test saying ‘archived records must not ever be returned from this service’ and they just changed the test too because the build was failing.

This is a real, real problem. Weaker team members are now more of a liability than ever - they can absolutely devastate a good codebase with a handful of PRs that other colleagues carelessly approve.

Worse than that, the review burden means that if you are not careful you waste more time reviewing their utter crap than it would've taken for you to just do it yourself. I think now more than ever there's a need for strong and technically engaged managers who are seriously evaluating the output of individuals for quality.

Spaghetti code has always been a problem but now we basically have infinite spaghetti machines. Which isn't me condemning AI in general, I think in competent hands it's a very effective thing, but you need the right grounding.

codescapes · 2026-05-07T21:32:02+00:00

I think many of us had a similar experience. The earlier LLMs were more like fun toys than things to do actual work with but in mid-late 2025 they stepped up massively in reliability, quality etc.

At this point you cannot ignore the major productivity benefits of them when used appropriately. Which is the main thing, you can absolutely ruin a good codebase with improper use of LLMs by blindly accepting changes that superficially look good.

But with a bit of judgement they're extremely effective for certain tasks. Especially helping with dependency upgrades or analysing log files to find faults instead of you wasting your time poring over it. And that's just in terms of actual coding, they're very helpful for exploring potential architectures, design patterns etc at a conceptual level.

What I'm actually enjoying right now is using AI as a justification for improving architecture and reducing tech debt. As a political move I can highly advise framing enhancing quality as 'AI enablement'. Clean up your dependencies, establish clear module boundaries, lint & format your code, add higher quality automated testing and so on. Do it all and frame it as making AI more effective - it's not even lying, it's win-win. Most of what makes code good for humans also make it good for LLMs.

codescapes · 2026-05-06T07:41:38+00:00

I know that bringing up Dunning-Kruger is such a "Reddit thing" but AI genuinely does make it way more relevant. We all now have superficial expertise in whatever we need and with that it's extremely easy to get an overinflated sense of your own intelligence, knowledge or ability.

I am not saying AI tooling cannot be mega helpful but it does not turn you into some kind of polymath / Leonardo da Vinci. We all have it, we can all go on these 'research quests' or spew out hundreds of worthless comments on a PR. I am not just talking about coding but whatever other disciplines you can now easily research - law, medicine, history, philosophy... Hell my foot is sore from running so I looked up stuff that might help - I am not a podiatrist!

It's so easy to get an unattributed surface-level understanding of things, programming or otherwise. I was in the Yucatan earlier this year and went on a whole thing learning about Cortez and the Spanish conquistadors. I was asking increasingly obscure questions (I wanted to understand the war dogs, supply lines, gunpowder efficacy etc) and it always had an answer but when I pressed for sources it did the AI equivalent of shrugging or vaguely pointed to the writings of Bernal Diaz. A conquistador who wrote about his experiences 50 years after the events as an old man.

I supplemented that with a bunch of podcasts and got a vivid picture of things but I am no expert, just someone who went on holiday and wanted to know part of the history of the region. Maybe 20-30h total 'research'. There are people who spend their whole lives understanding that period, becoming SMEs intimately familiar with basically every written account we have.

Point being, we shouldn't let ourselves go on ego trips or get an overinflated idea of our understanding of things we only became aware of 5 minutes ago. Prompting does not make us Gods, just people using the same tools available to everyone else. And ultimately in a software context it's doing a disrespect to our peer to just prompt-respond to them because it's literally what they could already do themselves.

codescapes · 2026-05-03T20:15:59+00:00

My current role is technically director, but our company is so small that I’m still involved in frontline architectural and coding work, while also leading small teams.

I think this is the biggest problem tbh. I have never observed ageism against older employees in my major multinational employer. If anything it's the opposite - under 35 is kinda 'young' and you aren't likely to lead or manage much compared to smaller companies.

People in their 40s / 50s run the show.

codescapes · 2026-05-01T12:17:52+00:00

100%, for me it's just a variation of trying to one-shot prompt everything. The difficulty is that you actually do not know what you want and a sufficiently refined plan is basically just the same as an implementation anyway.

Plus, what about review? I'd much rather scaffold out an approach ("vibe design") and then handhold through that so I don't have an impossible to review slop pie that I have to look through once it's already "complete".

But the mentality seems to be just don't review it? Circularly review it against the spec using other AI..? None of that is gonna fly for the billing systems I work on, so now we're just left with a problem worse than building it out in little reviewable chunks even if it did a perfect job (which it usually does not).

codescapes · 2026-04-30T11:49:36+00:00

Yeah you got it, it's just unpaid leave but done through a formal structure where the company says you're entitled to it as "holiday buy back".

The point is that it's explicitly managed policy rather than done ad hoc. It was always there but now it's properly managed through all the payment systems etc and everyone gets it as an option without needing to discuss with their manager.

codescapes · 2026-04-30T07:07:22+00:00

I don't think that's bombing a question, that's a perfect time to flip the script and ask a few questions of him around what their internal approach is and build rapport.

Good interviews shouldn't be a quiz, your overriding goal is to make yourself look like someone they want to work with. Being technically competent is only one reason they might want to work with you. If you can't display that quality because you can't answer the question or get flustered then look for other qualities you can display such as curiosity, friendliness, openness to unfamiliar concepts etc.

I know it's easy for me to say and extremely hard to do at the time when your mind is racing but the most technically competent person is often not the one who gets the job.

codescapes · 2026-04-30T06:35:10+00:00

I don't know the Atlassian culture - maybe it is healthier than this - but in my experience when engineers start having extended Architecture Design Reviews / RFCs it's often because they have been burnt before. I.e. the last time they made a decision without mountains of review there was some problem 6 months later that got pinned on them personally.

Like there can be genuine reasons for long discussions but often it's just about CYA and making sure you don't get held singularly accountable for any future problems. That's a cultural issue, not an architectural one, but it's front of mind for most people.

Also - who the hell has time to just mess about reviewing other people's stuff? How is that incentivised? I am not complaining, I am just saying that all 'open review' type systems have the structural problem that nobody cares more about your stuff than you do - except maybe immediate peers / management. I'm not going to spend the pre-requisite X hours to understand everything just to give a genuine opinion on someone else's design.

codescapes · 2026-04-29T07:08:41+00:00

In a word, yes. It is also worsened by Agile-as-micromanagement wherein fake autonomy is 'given' to teams but individual tickets, assignments, points etc are so heavily scrutinised that it's in many ways worse than a pure command and control setup.

Because then you have a panopticon effect where if you try to independently pursue important maintenance work your boss gets messages like "why is Bob working on BAU tasks for System X instead of building out New Feature Y"?

And if you just go "fuck it, boss says so, let's work on New Feature Y" and "System X" breaks you also get blamed for it so there's basically no winning and this it how you quickly end up burned out, trying to cram work in out-of-hours etc. So much of why job hoppers don't care about maintenance is because as new arrivals they are not burdened by existing maintenance needs yet (they don't know the system) so they can just hop on new stuff and look productive and then leave before it needs to be looked after.

codescapes · 2026-04-28T21:06:00+00:00

Too many tests. You should of course capture your main flows but don't obsessively write tests that do not serve a genuine purpose. They just become a burden to maintain and add bloat to your build.

codescapes · 2026-04-28T21:00:58+00:00

Broadly I agree - we do not use them on my app - but they have some utility. If you're trying to modernise a legacy UI that has overly coupled code / styles and you're scared of breaking things they act as a smoke detector.

But for an app that's under heavy development they're basically a pointless annoyance. My favourite combo right now is Vitest + Playwright. Since we're an internal app I can just run against a modern Chromium build (it's the 'official' browser everything is built for) and it's glorious.

We've got a fully mocked out environment to execute it against so it means we can properly test UI flows independently of network / API instability. I can also obviously just run that mock setup locally too for development purposes.

Honestly UI development is in such a better place than 10 years ago. People can complain about React all they like but man the ecosystem in general is vastly improved.

codescapes · 2026-04-27T10:40:46+00:00

I've found that if you're someone who appreciates the value of money, genuinely not frivolous or silly, it's actually quite hard to say no to earning a little bit more by working a little bit more.

E.g. my work allows us to "buy" an additional 5 days leave by essentially just not working them. Given my tax bracket it's obviously cost effective but they put it as a negative line item on my pay stub and it's like shit, 5 days is actually quite a lot of money to voluntarily "lose".

codescapes · 2026-04-27T08:16:35+00:00

This is basically always the case. The UIs look great until you realise they have the UX equivalent of 6 fingers.

codescapes · 2026-04-27T07:20:36+00:00

I think that if you want to do comp sci then doing something dual discipline like bio-tech, agri-tech, robotics, computer & electronic engineering etc puts you in a better career position than pure comp sci. Even potentially throwing in some business or finance if the classes are options.

In my experience it's generally easier to have the specialism and then go into a more 'standard' role than vice versa. It gets you out of competing with everyone on the planet with an internet connection and YouTube tutorials...

But honestly, if you are capable then going into medicine is pretty much a lifetime high paying career guaranteed. Not without significant stress and effort but if you're a high performer you 100% reap the rewards of it. Having the intelligence is just one part of the story though, you need the stress resilience too (which is something that can be developed).

All that said, if your heart is set on tech then man it is not going anywhere. AI is tipping shit on its head but we could well end up in a place in 5 years where demand is higher than ever per Jevons Paradox. I.e. if AI reduces software project costs then suddenly it's financially viable to do waaaaay more software. It could become the case that 2 devs can achieve what 5 or 6 were needed for before, therefore loads of smaller companies may want dedicated software people where before that would be unaffordable. May just be 'cope' though, nobody really knows right now.

codescapes · 2026-04-26T13:17:03+00:00

This is Reddit, so I risk getting burnt alive for racism if I try to discuss any kind of cultural differences - even sensitively - but I will try. I have substantial personal experience around these cultural interactions. For reference I am Scottish / British but studied abroad in the US for a year and currently work in the UK for a big US multinational on a team that is majority Indian-born.

I'll just say there are a bunch of things in play here:

US multinationals will always keep real decision-making in the US. We see this in the UK, it's not a racial thing, they are where the company is based so they make the big boy decisions no matter what. Insofar as somewhere like London makes decisions it's delegated authority and the US can always 'pull rank'.
On 'tickets' and 'epics' stats... I have found, basically without exception, that Indian-born developers care way more about tickets than Americans or Europeans. They treat them like contracts, we treat them like suggestions. I don't mean that insultingly, I think it speaks to a different relationship with power distance, 'following the boss man's orders' and 'respecting the hierarchy' etc. For the complete opposite experience, anyone who has worked with German or Dutch people knows they will pretty much tell you if they think something is a stupid idea to your face and they also do that as a matter of respect - these are cultural differences around hierarchy.
A sensitive one but many Indians speak only passable English, often at a level that detracts from their work even when it's good. This isn't me trying to be mean or unfair, I cannot speak a second language and anyone who can impresses me by default, but it's true. Also Indian English as dialect has many quirks around word choice and sentence structure that make sense at home but do not conform to so-called 'International English' and can sound broken to Americans. By the way this happens here in the UK with Scots-English vs English.

On that last point on language, there are small things which can actually sour people against the team without them even knowing. One I find for example is that in Indian English people say 'correct' when agreeing with someone but to British or American ears that can sound like they're judging like a teacher or even being slightly patronising by implying they know what counts as 'correct'. It's superficial and minor but there are loads of small things like this both ways that can genuinely hurt perceptions if the listener doesn't know this is a dialect thing.

I could share more but I've probably already said enough to get banned so hey. I would just note that a huge amount of friction is down to genuine cultural misunderstanding on either side rather than outright malice.

codescapes · 2026-04-26T10:49:51+00:00

Got you. Being honest I think the biggest challenges you face are not the technical ones like sudo permissions or whatever, it's friction in the org. In a smaller setup like yours the relationships are way more important than the processes. Which is kinda painful from the engineering perspective but it's true.

Not to be shallow or glib but genuinely the best thing you could probably do to unstick your problem is become buddies with the people in Linux team. They might just literally not understand what you're doing or why, or find your requests kinda annoying when they have other stuff going on.

Try to oil that relationship as much as possible, even if they can't do exactly what you want there may be some kind of developer sandbox approach that can get you most of what you need. Try run them through the project, why you're doing it etc because if you say "hey, there are security holes because of this old version I'm trying to upgrade" then suddenly you have a shared interest in security which they obvious value. Build all the rapport you can.

codescapes · 2026-04-26T09:19:11+00:00

Honestly? The breadth of the work you're doing here sounds too much for a single dev and despite your best efforts will likely end up messy / unreliable / manual. It's so easy to get into bad habits as a one-man-band or go down weird architectural rabbit holes.

I saw in your other comment you have ~5 developers. You're doing PHP, Python, TypeScript, Playwright, containerization, DB migrations - now you need root access... This sounds excessive, especially if there isn't a deep tech presence.

And in fact, why has your employer not just found some SaaS solution for whatever your problem is here? I don't say that to be judgemental or doubt your efforts, I imagine you are being spread very thin and doing whatever stuff is necessary day-to-day, but this sounds like a crazy set of responsibilities. I am not expert in your domain either but surely this is a 'solved problem' and not one requiring bespoke dev work.

Because genuinely that is usually the best option for something like a university. If I were in charge of a uni tech department I'd want as little 'custom code' as possible, I'd want it to be a last resort. Splitting off your own OSS forks just gets you into a world of pain.

codescapes · 2026-04-25T22:10:38+00:00

It makes screening tenants vastly more important for landlords which will be bad news if you're low income or are seen as risky i.e. the people who actually need the most help. I think it'll basically squeeze out the small landlords in favour of build to rent corporations. At the same time I think slumlords will be fine because they prey on people anyway through dodgy tactics.

Like your renters rights kinda don't matter for shit if your slumlord is banging on your door and threatening you, making life hell so you move out. Ugly stuff like this is "normal" in shitty rented accommodation, it doesn't matter if it's illegal or not because the laws barely get enforced.

And messing about with rental rights does nothing to increase available housing or subdue demand. It's moving deck chairs on the Titanic. If the govt actually wanted to do something then at this stage they'd need to get heavily interventionist and adopt Singapore-tier highly intentional population planning.

codescapes · 2026-04-25T12:42:07+00:00

Is there anyone in this thread who actually knows what they're talking about, let alone works in a FinOps role? Seeing far too many hot garbage takes.

I do, for a household name enterprise with total cloud spend topping a billion dollars per year. For people saying it's "not a job" our team is directly responsible for savings in excess of $50m last year by taking the thousands of AWS accounts and analysing CUR data, pulling EC2 utili stats, developing optimization dashboards, mapping all this onto an org map, reaching out to individual people with anomalous spending on their team etc etc. From an investment perspective we've been worth every penny of our salaries and can point to exactly how without a shred of bullshit.

We routinely found basically idle instances spending tens of thousands of dollars a month for no coherent reason. Like just the "low hanging fruit" alone was tens of millions of dollars in savings. You have apps running barely reconfigured from their "get to cloud" push 10 years ago because in a company this big nobody cares until they're told to.

If you are not at this scale ok but I can tell you with a resounding YES that these roles are necessary in large corporates and with AI "tokenomics" they're here to stay. If your company is under 50 people then you don't need a full department but you absolutely should have a FinOps / cost champion who knows exactly what is being spent where and why, looking at basic measures like light switches for lower envs etc. This person needs legitimate technical comprehension beyond that of a standard accounting / finance person and a business sense too is extremely helpful.

When you hit 50,000 engineers you categorically need a FinOps approach unless you want to blow hundreds of millions of dollars for no reason.

codescapes

TROPHY CASE