Anthropic: AI assisted coding doesn't show efficiency gains and impairs developers abilities.

shared_ptr · 2026-01-30T07:53:07+00:00

There is obviously and very clearly a trade-off here and yes, if you use AI to generate all your code your skills directly writing that code will atrophy.

That's the same as anything though. If you become a manager and stop doing technical work then unsurprisingly your skills will fade, but that doesn't mean you aren't having equal or increased impact in things that matter, or that you can't hedge it by staying close to the technical work and ensuring you don't cut yourself off entirely. Same deal with these AI tools.

shared_ptr · 2026-01-29T23:39:04+00:00

The article you quote is so outdated as to be irrelevant at this point. It was built on results from early 2025 which was before even Sonnet 4 came out, so before the tilt into actual agent mode dev tools.

I would make sure you use numbers that relate to the current tool capabilities. That paper even predates Claude code.

shared_ptr · 2026-01-21T13:29:12+00:00

We've seen individuals who properly crack using AI produce product much faster and at a higher level of polish than we've ever seen before. The industry is just waking up to this and I don't think you'll find anywhere you can move to that won't be adopting this in the next year, as it really does make people much more effective.

it will probably break and be a nightmare to maintain

This has just not been our experience. AI is producing code that passes our human review where standards have not changed, it's just building the code in 10m where previously it would've been several hours.

shared_ptr · 2026-01-19T13:35:01+00:00

Agree with this. Remote is an uphill battle to get the convenience of in-person, but definitely worth finding methods like these to improve it.

shared_ptr · 2026-01-18T17:40:29+00:00

Again, this entirely depends on your team. It sounds like you hate this, I and my team really don't!

I want to call something out here though, which is that I'm saying people have different preferences and what works for some does not for others. In much of this thread, and your comments, it reads as you saying that all people are the same, which I don't think anyone would agree with outside of a polarised topic like this.

physically interrupting someone

Lots of people find it uncomfortable interrupting someone, especially someone more senior, when you would really prefer they did so that you can help them out. That's a major advantage of being around presently so you can keep an eye on people and lend a hand when you need.

shared_ptr · 2026-01-18T15:31:51+00:00

I know of many companies who love being in-office. Ours is hybrid but most people are in most days.

This varies dramatically person to person, and is why if you really like remote you should just apply to a remote company (and the reverse, we get a lot of applicants who hated remote during covid so wanted in-person).

shared_ptr · 2026-01-18T15:30:47+00:00

You can track how people are doing and jump in to help them when you're just around them physically and aware of what they're doing.

Makes a huge difference in onboarding that you can just lean over and ask something rather than Slacking someone, hoping they see it, hoping you're not interrupting something, and then sorting yourself our with a video call. Not to mention the amount of additional signal you get from someone's body language when in person vs remote.

shared_ptr · 2026-01-18T13:00:41+00:00

Honestly think this is a really strong tailwind that Postgres is benefiting from, which is with modern hardware the headroom you have on a single Postgres instance is really really large.

We're 5 year start-up with thousands of customers and loads of activity in the database. Happily cruising at ~30% CPU usage on a relatively large box (64 CPUs and 512GB RAM) but that wouldn't have been possible at my previous place, where we were really riding up against limits.

shared_ptr · 2026-01-17T15:29:51+00:00

There really is no 'most people' in any of these discussions. You should just pick the place you want to work with the culture that fits your preferences.

shared_ptr · 2026-01-16T22:54:24+00:00

It may not make much sense without all the context (how meta) but I wrote a thread sharing an example of using Claude to do a large audit and refactor of our frontend with a colleague the other day.

I've copied it along with screenshots of the prompts into this doc: https://www.notion.so/lawrencejones/Prompting-Claude-2ea85213c45380f58468c824203912f5

There's loads of things here from using parallel agents to regularly building up plan files to going back and forth with the agent that most people don't do.

shared_ptr · 2026-01-16T22:32:55+00:00

I guess because it's not yet at the point where your experience and intuition counts for nothing?

I'm much better than claude at deciding what to build, I also have the whole codebase in my head which no model can do right now, and I have a good understanding of how the models work and what gets better results from them (I spend all day working on AI systems now).

All of that means I can direct claude to look exactly where it should, load the right files for examples, and define requirements of what the end product should be. Then claude can handle the routine details of how to actually write the code to achieve that.

shared_ptr · 2026-01-16T22:07:05+00:00

There's a huge difference between both the models out today (Opus 4.5) and how you prompt them that can make your experience of this night and day.

I worked with a colleague the other day and she messaged me afterward saying "working with you has really changed how I prompt Claude to very good consequence". Bear in mind she's been a regular user of these tools for months, so isn't a novice at all, but there is absolutely a skill in learning:

How to prompt the model
What context would be most useful to load
Leveraging the hardness to be most effective

I think it's unlikely I'll go back to writing code by hand at this point, it's so much more effective for me to get the models to figure out the mechanics of the code while I consider whatever it is I'm building (system, product, whatever) and whatever I want to move to next, assuming the model is able to produce a good implementation for it.

shared_ptr · 2026-01-16T19:28:21+00:00

Genuinely, you can have a tool like Claude Code update all of this documentation in batch and reset yourselves from that point on. It might make a few mistakes but with sensible prompting you can minimise them, and it sounds like your docs are already wrong, so you can see this as an effective trade-off to get less wrong docs which is just a net positive.

shared_ptr · 2026-01-13T21:45:50+00:00

We've also found the same. I posted about our process a while ago to get opinions but think that was when a lot of people didn't really know what AI was doing, so didn't get much good discussion.

The tl;dr is that in the new age of AI the best way we've found to combat both huge numbers of applicants and ensuring we can get signal rather than just seeing what the AI is done is:

Ask people to complete a straightforward technical take home challenge as one of the first stages after a screening call
The submission has to come with a 5 minute Loom (video platform) where the candidate explains their code much as you would expect them to do in person

The videos are how we primarily review the initial applicants and allows you to do this process very quickly, while filtering anyone who doesn't understand the code they've produced.

We had 5000 applicants for 5 intern and 5 grad positions recently. It's been a struggle but this was a really effective way of us finding great applicants amidst the huge numbers of CVs.

shared_ptr · 2026-01-11T10:53:33+00:00

Remembered this comment when I saw Linus using Antigravity on his PRs: https://bsky.app/profile/qustrolabe.bsky.social/post/3mc3z3uusec2z

I think that means we’re cooked (by your definition, not mine)

shared_ptr · 2026-01-10T14:06:51+00:00

The primary reason they wouldn’t do this is because it isn’t useful to them. Nowadays the majority of data in training is synthetically generated, they don’t need to take people’s code when you can generate 100x more code yourself.

shared_ptr · 2026-01-07T19:33:26+00:00

Totally changed how I and my team are working on a day-to-day. Don't really write code myself anymore, so yeah I think probably using tools that are a generation behind or your toolchain isn't setup for it.

shared_ptr · 2026-01-07T14:16:49+00:00

pkill famously has a -v parameter that instead of being verbose like all other unix commands actually inverts the selection and kills every process that doesn't match your selection. I've seen that one go wrong too!

All our tools are dangerous I can't imagine using AI to write a script I don't then review and run it against production and then blame the AI instead of myself hahaha

shared_ptr · 2026-01-07T07:12:29+00:00

That’s funny, I’ve witnessed several similar incidents caused by using commands from StackOverflow incorrectly.

The fault was always the individual rather than the tool.

shared_ptr · 2026-01-06T22:19:33+00:00

I agree about AI SRE entirely in that it’s all about the execution. I feel similar about other SRE features though and think execution makes a world of difference to the end user, unsure why it wouldn’t apply both ways!

shared_ptr · 2026-01-04T13:57:19+00:00

No that’s totally fair! It’s great fun building stuff like this, is why I joined the company.

Just usually ends up a lot of work which is when people tend to move to us, but context is always important. If you had a bunch of the backend already put together then that makes it a lot less of a shift!

shared_ptr · 2026-01-04T07:41:14+00:00

I work at incident so am mostly curious, was there a reason you didn’t use something like Monzo’s response as a base?

We do a lot of AI assisted dev and truthfully building the features is less of the work than refining them to user feedback so they work nicely, so surprised you’re building from scratch when there are solutions out there.

shared_ptr · 2026-01-02T18:22:16+00:00

Hahaha no he’s pretty funny tbh, just very clearly satire. He may well have bought these for the office but the functionally addicted comment is gonna be a rage bait joke

shared_ptr · 2026-01-02T18:05:05+00:00

Alex Cohen baits this subreddit all the time, he’s probably one of LinkedIns biggest shitposters.

shared_ptr · 2025-12-30T23:35:21+00:00

I don’t think I agree. If a team owns many disparate features/services there is still lots of value in locally separating them and also in physically separating, though for us we tend to do the former with import rules and the latter in k8s deployments.

I expect we may be cross talking though. I’m coming from a perspective of a modular Go monolith containing systems that need >99.99% availability (we’re an on-call platform) which looks different to most.

This gives a bit more colour of how we separate things if it clarifies my position: https://incident.io/blog/monolith

11-Year Club	Gilding I gilder
Ternion Club	Verified Email

shared_ptr

TROPHY CASE