Today I've made the difficult decision to reduce the size of Coinbase by ~14% • Hacker News Board

Re: Today I've made the difficult decision to reduce the size of Coinbase by ~14%

#671

Post by MeetingsBrowser » Wed, May 06, 2026, 1:55 PM UTC

logicchains wrote: post #617

MeetingsBrowser wrote: post #395

Earlier quoted context omitted.

As a software engineer who also hires other software engineers, I’m curious about the disconnect in our experiences. I do systems programming. Before AI feature development roughly went like, design, implement, test, review with some back edges and a lot of time spent in test and review. AI has made the implementation part much faster, at the cost of even more time spent testing and reviewing, though still an improve…

>AI has made the implementation part much faster, at the cost of even more time spent testing and reviewing, Maybe they're using AI for testing and reviewing more than you are, not just for coding?

The "AI implementation" step in my workflow includes separate agents dedicated to testing and reviewing changes. The self feedback loop catches a lot of errors and mistakes, but it rarely produces working code in one go.

In my experience, the generated code handles the happy path, but isn't great about edge cases or writing clean code, even with explicit instruction in the initial prompt.

We usually end up doing multiple iterations with what claude/codex output, pointing out issues, asking for changes, etc.

Re: Today I've made the difficult decision to reduce the size of Coinbase by ~14%

#672

Post by dahart » Wed, May 06, 2026, 2:00 PM UTC

siren2026 wrote: post #561

kelnos wrote: post #515

> Leaders will own much more, with as many as 15+ direct reports. [...] Every leader at Coinbase must also be a strong and active individual contributor. Managers should be like player-coaches, getting their hands dirty alongside their teams. Oof. So not only are they giving their remaining managers more reports, but those managers will be expected to do lots of other, non-management work. Sure, nothing can go wrong…

Or maybe we should go back to what it was before Google and big $$$ tech decided that if you were a "manager" you shouldn't contribute technically. Being a manager now means a bunch of busy work talking to other managers and weekly 1:1s. There is a ton that has been written about the managerial class. Producing nothing, but for sure making themselves look self-important. Before that the manager was essentially the be…

> We don't need weekly 1:1s to check on feelings.

As a manager that does weekly 1:1s, I agree with that statement. But I do need 1:1s to check on progress, uncover blockers that people haven’t surfaced on their own, make continuous small decisions, offer support, assess performance, collect status information for my manager, and last but not least give employees the opportunity to share feelings frequently. They do, and it’s not very often, but it’s important to have a dedicated place for it otherwise devs often don’t share until damage is being done.

I’ve also watched devs who didn’t have weekly check-ins go pretty far off the rails. One dev I remember would go off by himself for weeks designing clever code and over-engineering things that weren’t needed. I thought to myself that someone should be checking in with him, and then months later I got stuck doing overtime before a delivery deadline with dozens of other devs on a weekend chasing an intermittent release-only runtime crash that turns out he caused by trying to get tricky with copy constructors. A quick 1:1 could have prevented this bug that ended up costing tens or hundreds of thousands before it ever happened.

BTW, the best managers I’ve ever had were technical contributors, and they tended to be more relaxed about check-ins than the non-technical managers, in part because they had a better sense of where things sat. Personally I also feel like a better manager when I’m contributing technically to a project, and devs seem to respect that more.

Re: Today I've made the difficult decision to reduce the size of Coinbase by ~14%

#673

Post by henry2023 » Wed, May 06, 2026, 2:02 PM UTC

alansaber wrote: post #588

henry2023 wrote: post #483

Earlier quoted context omitted.

This is the holy-grail in TradFI, not sure if it applies to fintech. It's not uncommon to hear from people who own an internal process only they know that's essentially their whole job security. The extreme being people that produce only one report a month and that more than justifies their income + bonus.

Simple, we make them use a company computer, log everything they've ever done then reverse engineer it

Paying the person's income + bonus is a lot cheaper and safer than revese engineer some processes.

Re: Today I've made the difficult decision to reduce the size of Coinbase by ~14%

#674

Post by Zach_the_Lizard » Wed, May 06, 2026, 2:03 PM UTC

skippyboxedhero wrote: post #569

siren2026 wrote: post #561

Earlier quoted context omitted.

Or maybe we should go back to what it was before Google and big $$$ tech decided that if you were a "manager" you shouldn't contribute technically. Being a manager now means a bunch of busy work talking to other managers and weekly 1:1s. There is a ton that has been written about the managerial class. Producing nothing, but for sure making themselves look self-important. Before that the manager was essentially the be…

As a data point, I work at a US company that ended up in this place and the same thing is happening. In my BU there were directors with 2 direct reports. Even at the next level up, the number of non-IC directs is only high single digits. There are many managers who were already engaging technically with the product (not PRs but playing an active role in planning work) and they have no idea what directors are actually…

As one of those supposedly higher level ICs, I agree entirely with the assessment.

A decade or so ago, the high level ICs I interacted with were much more technical.

They were the kind who would perhaps not invent truly novel things--but plenty did in the right companies--but they had mastered their domains and genuinely solved thorny problems that others struggled with.

Nowadays, they are more political and less involved. I have met many that do not code or barely code. I've been in months of meetings to decide to do something fairly obvious just to ensure "alignment" even though no parties actually disagreed, just wanted to nitpick minor details that could just be a comment on a PR.

Re: Today I've made the difficult decision to reduce the size of Coinbase by ~14%

#675

Post by pron » Wed, May 06, 2026, 2:04 PM UTC

snapcaster wrote: post #668

pron wrote: post #655

Earlier quoted context omitted.

They're not productive for any workflow is my point because they don't produce sustainable software, yet that's exactly what Armstrong is calling for. They don't work, and people experienced with AI workflows already know that. If you review the code and tell the agent to revert when it gets things wrong (not functionally but architecturally) you're fine. That's not what I was responding to.

You're just wrong on this though, and I don't know why you aren't realizing it's a skill issue on your part

Nah, it's a skill issue on the part of those who believe in "agent swarms" (in fact, that's how I recognise AI noobs; they think swarms work). Studies (like this [1]) and Anthropic's experiements have told us they don't. We do experiments with software correctness and formal methods experts who actually dive deep into "swarm outputs" and try to put evolutionary pressure on them. Swarms simply cannot (yet) produce viable software. They do, however, produce software that for a while passes tests. What I think is happening is that people who believe swarms work just look at test results. But obviously, every software engineer has known for decades that tests can only tell you if your software works today; they can't tell you that it will work tomorrow. And the people who say that unreviewed agent output will work tomorrow are those who didn't review it closely enough, so they have no idea, either.

[1]: https://arxiv.org/abs/2603.03823

Re: Today I've made the difficult decision to reduce the size of Coinbase by ~14%

#676

Post by fastasucan » Wed, May 06, 2026, 2:05 PM UTC

tyyyy3 wrote: post #613

p0w3n3d wrote: post #601

Earlier quoted context omitted.

Exactly. I won't unless you hire me :wink: ---- edit ---- TBH I will post an article, I'm finishing it. But it won't be so doomy, but rather on what to avoid to not fail

I strongly believe increasing the rate at which one produces code misses the point. If engineers already know up front with clarity what they need to build, and, the leadership are very focused and concentrate resources on doing a few things.. then increasing the rate at which LOC is written is not beneficial - because getting the product built right is what matters.

Exactly. We all laughed at the cases where productivity was measured in lines of code. But now the whole world somehow optimize for it.

Re: Today I've made the difficult decision to reduce the size of Coinbase by ~14%

#677

Post by yalogin » Wed, May 06, 2026, 2:05 PM UTC

Finally one ceo came out honestly and said ai is the reason for laying off people. It makes sense, no point in being obscure. It doesn’t matter if they over hired or not, AI is giving them the freedom to lay off. I would expect a lot more layoffs and more importantly the configuration of teams and nature of roles is going to change, has to change to be effective with AI

Re: Today I've made the difficult decision to reduce the size of Coinbase by ~14%

#678

Post by 4ggr0 » Wed, May 06, 2026, 2:07 PM UTC

dbgrman wrote: post #380

Banditoz wrote: post #270

Earlier quoted context omitted.

What would you blame instead?

Bitzscaling. Reid Hoffman's snake oil (thought piece). https://www.blitzscaling.com/ It has poisoned more than one company (especially startups). Its the "go big or go home" mentality. The "the market is ours to take if we just put more fuel to this fire" mentality. was in a startup once (Reid was an investor). The CEOs bought into blitzscaling, told the whole company we're going to "blitzscale". Hired 2 directors (w…

> blitzscaling

what a tone-deaf way to name a business. yuck.

Re: Today I've made the difficult decision to reduce the size of Coinbase by ~14%

#679

Post by [deleted] » Wed, May 06, 2026, 2:07 PM UTC

Atotalnoob wrote: post #347

brandall10 wrote: post #289

Earlier quoted context omitted.

Internal tools and help/marketing pages aren't generally considered production code.

What world do you live in internal tooling isn’t production code? Internal tools keep the lights on and allow customer facing code to function! Operational tooling also isn’t a sexy thing, but it’s vital for any company to function.

[deleted]

Re: Today I've made the difficult decision to reduce the size of Coinbase by ~14%

#680

Post by dbalatero » Wed, May 06, 2026, 2:07 PM UTC

shigawire wrote: post #510

keithnz wrote: post #315

Earlier quoted context omitted.

Same, I've been coding for 40+ years, and other people I know of similar length of time also seem real quick to adopt AI. I'm constantly having to show the young devs how to get the most out of their AI agents and also adapting my workflows regularly as things changes. Weirdly its some of the youngest who are most resistant, I think because they are learning coding skills, and just have got the hang of coding such th…

As a "young" coder I am hesitant because I don't have decades of skills to fall back on. It is even more abstraction, even harder to follow the code I'm "writing" with AI. Also I have a fear that if/when the AI tide recedes, I'll be the one caught with my pants down since I have been forced to vibe code the majority of my career. As opposed to greybeards who can fall back on their decades of knowledge.

You nailed it. Only option is to build skills, preferably on company time. Just remember there's a lot of mediocre devs, and you probably have more time than you think to do things.