Mastodawn

But you can’t just not review things!

Actually you can. If you shift the reviews far to the left, and call them code design sessions instead, and you raise problems on dailys, and you pair programme through the gnarly bits, then 90% of what people think a review should find goes away. The expectation that you'll discover bugs and architecture and design problems doesn't exist if you've already agreed with the team what you're going to build. The remain 10% of things like var naming, whitespace, and patterns can be checked with a linter instead of a person. If you can get the team to that level you can stop doing code reviews.

You also need to build a team that you can trust to write the code you agreed you'd write, but if your reviews are there to check someone has done their job well enough then you have bigger problems.

loire280 Mar 17

I've seen engineers I respect abandon this way of working as a team for the productivity promise of conjuring PRs with a coding agent. It blows away years of trust so quickly when you realize they stopped reviewing their own output.

Putting too much trust in an agent is definitely a problem, but I have to admit I've written about a dozen little apps in the past year without bothering to look at the code and they've all worked really well. They're all just toys and utilities I've needed and I've not put them into a production system, but I would if I had to.

Agents are getting really good, and if you're used to planning and designing up front you can get a ton of value from them. The main problem with them that I see today is people having that level of trust without giving the agent the context necessary to do a good job. Accepting a zero-shotted service to do something important into your production codebase is still a step too far, but it's an increasingly small step.

camillomiller Mar 17

>> Putting too much trust in an agent is definitely a problem, but I have to admit I've written about a dozen little apps in the past year without bothering to look at the code and they've all worked really well. They're all just toys and utilities I've needed and I've not put them into a production system, but I would if I had to.

I have been doing this to, and I've forgotten half of them. For me the point is that this usage scenario is really good, but it also has no added value to it, really. The moment Claude Code raises it prices 2x this won't be viable anymore, and at the same time to scale this to enterprise software production levels you need to spend on an agent probably as much as hiring two SWEs, given that you need at least one to coordinate the agents.

I think Claude could raise it's prices 100x and people would still use it. It'd just shift to being an enterprise-only option and companies would actually start to measure the value instead of being "Whee, AI is awesome! We're definitely going really fast now!"

christophilus Mar 17

100x? You think people would pay $20k per month for Claude Code?

Codex is as good (or very nearly) as Claude code. Open source models continue to improve. The open source harnesses will also continue to improve. Anthropic is good, but it has no moat. No way could they 100x their prices.

jeremyjh Mar 17

Deepseek v3.2 tokens are $0.26/0.38 on OpenRouter. That model - released 4 months ago - isn't really good enough by today's standards, but its significantly stronger than Opus 4.1, which was only released last August! In 12 months I think its reasonable to expect there will be a model with less cost than that which is significantly stronger than anything available now.

And no, it isn't ONLY because VC capital is being burned to subsidize cost. That is impossible for the dozen smaller providers offering service at that cost on OpenRouter who have to compete with each other for every request and also have to pay compute bills.

Qwen3.5-9B is stronger than GPT-4o and it runs on my laptop. That isn't just benchmarks either. Models are getting smaller, cheaper and better at the same time and this is going to continue.

overfeed Mar 17

Perhaps due to FOMO outbreak[1], upper management everywhere has demanded AI-powered productivity gains, based on LoC/PR metrics, it looks like they are getting it.

1. The longer I work in this industry, the more it becomes clear that CxO's aren't great at projecting/planning, and default to copy-cat, herd behaviors when uncertain.

tripledry Mar 17

Would love to be a fly on the wall for a couple of months to see what corporate CxO's actually do.

Surely I could do a mediocre job as a CxO by parroting whatever is hot on Linkedin. Probably wouldn't be a massively successful one, but good enough to survive 2 years and have millions in the bank for that, or get fired and get a golden parachute.

(half) joking - most likely I'm massively trivializing the role.

A charitable explanation for what CxOs do is that they figure out their strategic goals and then focus really hard on ways to herd cats en masse to achieve the goals in an efficient manner. Some people end up doing a great job, some do so accidentally, other just end up doing a job. Sometimes parroting some linkadink drivel is enough to keep the ship on course - usually because the winds are blowing in the right direction or the people at the oars are working well enough on their own.

arethuza Mar 17

"Surely I could do a mediocre job as a CxO by parroting whatever is hot on Linkedin"

Having worked for a pretty decent CIO of a global business I'd say his main job was to travel about speak to other senior leaders and work out what business problems they had and try and work out, at a very high level, how technology would fit into that addressing those problems.

Just parroting latest technology trends would, I suspect, get you sacked within a few weeks.

raphlinus Mar 17

Funny enough, the author of this blog post wrote another one on exactly that topic, entitled "What do executives do, anyway?"[1]. If you read it, you'll find it's written from quite an interesting perspective, not quite "fly on the wall," but perhaps as close as you're going to get in a realistic scenario.

[1]: https://apenwarr.ca/log/20190926

What do executives do, anyway?

An executive with 8,000 indirect reports and 2000 hours of work in a year can afford to spend, at most, 15 minutes per year per person in th...

serial_dev Mar 17

Software engineers are pushed to their limits (and beyond). Unrealistic expectations are established by Twitter "I shipped an Uber clone in 2 hours with Claude" forcing every developer to crank out PRs, managers are on the look out for any kind of perceived inefficiency in tools like GetDX and Span.

If devs are expected to ship 10x faster (or else!), then they will find a way to ship 10x faster.

I always found it weird how most management would do almost anything other than ask their dev team "hey, is there any way to make you guys more productive?"

Ive had metrics rammed down my throat, Ive had AI rammed down my throat, Scrum rammed down my throad and Ive had various other diktats rammed down my throat.

95% of which slowed us down.

The only time ive been asked is when there is a deadline and it's pretty clear we arent going to hit it and even then they're interested in quick wins like "can we bring lunch to you for a few weeks?", not systemic changes.

The fastest and most productive times have been when management just set high level goals and stopped prodding.

Im convinced that the companies which seek developer autonomy will leave the ones which seek to maximize token usage in the dust in the next tech race.

FromTheFirstIn Mar 18

In my experience what you’ve described as the ideal setting for Eng work does lead to a very high quality product. The problem then is understanding if the market you’re in values high quality over speed or familiarity. All markets claim to value quality, many markets don’t.

nvardakas Mar 17

[dead]

denkmoon Mar 17

I’m so disappointed to see the slip in quality by colleagues I think are better than that. People who used to post great PRs are now posting stuff with random unrelated changes, little structs and helpers all over the place that we already have in common modules etc :’(

bluefirebrand Mar 17

> little structs and helpers all over the place that we already have in common modules

I've often wondered about building some kind of automated "this codebase already has this logic" linter

Not sure how it would actually work, otherwise I'd build it. But it would definitely be useful

Maybe an AI tool could do something like that nowadays. "Search this codebase for instances of duplicated functions and list them out" sort of thing

SkyBelow Mar 17

>this codebase already has this logic

At first glance this looks like it might be the halting problem in disguise (instead of the general function of the logic, just ask if they both have logic that halts or doesn't halt). I think we would need to allow for false negatives to even be theoretically possible, so while identical text comparison would be easy enough, anything past that can quickly becomes complicated and you can probably infinitely expand the complexity by handling more and more edge cases (but never every edge case due to the underlying halting problem/undecidability of code).

glitchdout Mar 18

You only need to detect structuraly similar code.
You absolutely do not need AI for that. You need ASTs.

In Ruby we have the Flay gem, for example.

https://github.com/seattlerb/flay

GitHub - seattlerb/flay: Flay analyzes code for structural similarities. Differences in literal values, variable, class, method names, whitespace, programming style, braces vs do/end, etc are all ignored.

Flay analyzes code for structural similarities. Differences in literal values, variable, class, method names, whitespace, programming style, braces vs do/end, etc are all ignored. - seattlerb/flay

GitHub

> You also need to build a team that you can trust to write the code you agreed you'd write

I tell every hire new and old “Hey do your thing, we trust you. Btw we have your phone number. Thanks”

Works like a charm. People even go out of their way to write tests for things that are hard to verify manually. And they verify manually what’s hard to write tests for.

The other side of this is building safety nets. Takes ~10min to revert a bad deploy.

pdhborges Mar 17

> The other side of this is building safety nets. Takes ~10min to revert a bad deploy.

Does it? Reverting a bad deploy is not only about running the previous version.

Did you mess up data? Did you take actions on third party services that that need to be reverted? Did it have legal reprecursions?

jamiemallers Mar 17

[dead]

DrewADesign Mar 17

Having data model changes be a part of regular deployments would give me persistent heartburn.

redman25 Mar 17

It's why you always have a rollback plan. Every `up` needs to a `down`.

If you do that, it expands your test matrix quadratically.

So, it makes sense if you have infinite testing budgets.

Personally, I prefer exhaustively testing the upgrade path, and investing in reducing the time it takes to push out a hot fix. Chicken bits are also good.

I haven’t heard of any real world situations where supporting downgrades of persistent formats led to best of class product stability.

Would love to hear of an example.

DrewADesign Mar 18

Aircraft engineer: “That’s why you have parachutes.”

They might be an appropriate safeguard for a prototyping shop, but not for Delta.

> Does it? Reverting a bad deploy is not only about running the previous version.

It does. We’ve tried. No it’s not as easy as running the previous version.

I have written about this: https://swizec.com/blog/why-software-only-moves-forward/

Why software only moves forward | Swizec Teller

At scale there are no rollbacks and no cut-overs. Your software only moves forward.

pdhborges Mar 17

I read the article and to be honest I don't know where we disagree. I disagree with this quote,

> Takes ~10min to revert a bad deploy

A bad deploy can take way over that just in customer or partner management communication.

namanyayg Mar 17

How does the phone number help?

That's the polite version of "we know where you live". Telling someone you have their phone number is a way of saying "we'll call you and expect immediacy if you break something."

Wanna be treated like an adult? Cool. You'll also be held accountable like an adult.

swiftcoder Mar 17

Never received a phone call at 5am on a Sunday because a bug is causing a valued customer to lose $10k/minute, and by the way, the SVP is also on the line? Lucky bastard

herbstein Mar 17

> I tell every hire new and old “Hey do your thing, we trust you. Btw we have your phone number. Thanks”

That's cool. Expect to pay me for the availability outside work hours. And extra when I'm actually called

> Expect to pay me for the availability outside work hours.

We pay people enough to care about the software they ship.

Don’t want to be called outside of work hours? Make sure your code works. Simple.

anal_reactor Mar 17

I never review PRs, I always rubber-stamp them, unless they come from a certified idiot:

1. I don't care because the company at large fails to value quality engineering.

2. 90% of PR comments are arguments about variable names.

3. The other 10% are mistakes that have very limited blast radius.

It's just that, unless my coworker is a complete moron, then most likely whatever they came up with is at least in acceptable state, in which case there's no point delaying the project.

Regarding knowledge share, it's complete fiction. Unless you actually make changes to some code, there's zero chance you'll understand how it works.

I used to do this! I can’t anymore, not with the advent of AI coding agents.

My trust in my colleagues is gone, I have no reason to believe they wrote the code they asked me to put my approval on, and so I certainly don’t want to be on a postmortem being asked why I approved the change.

Perhaps if I worked in a different industry I would feel like you do, but payments is a scary place to cause downtime.

recursivecaveat Mar 17

Do people really argue about variable names? Most reviews comments I see are fairly trivial, but almost always not very subjective. (Leftover debug log, please add comment here, etc) Maybe it helps that many of our seniors are from a team where we had no auto-formatter or style guide at all for quite a while. I think everyone should experience that a random mix of `){` and `) {` does not really impact you in any way beyond the mild irking of a crooked painting or something. There's a difference between aesthetically bothersome and actually harmful. Not to say that you shouldn't run a formatter, but just for some perspective.

anal_reactor Mar 17

Yes. 80% of comments to my PRs are "change _ to -" or something like that.

PR #467 - Reformat code from tabs to spaces

PR #515 - Reformat code from spaces to tabs

>Do people really argue about variable names?

Of course they do. A program's code is mostly a graph of names; they can be cornerstones of its clarity, or sources of confusion and bugs.

The first thing I do when debugging is ensuring proper names, sometimes that's enough to make the bug obvious.

The greatest barrier to understanding is not lack of knowledge but incorrect knowledge. That's why good names matter. And naming things is hard, which is why it makes sense to comment on variable names in a review.

whynotmaybe Mar 17

Unless the naming convention were written in the 90s and all variable must follow a precise algorithm to be made of only abbreviation and a maximum length of 15.

Or for some, if it contains the value of a column in the db, it must have the same name as the column.

So yeah, instead of "UsualQuantityOrder", you get "UslQtyOrd" or "I_U_Q_O"... And you must maintain the comments to explain what the field is supposed to contain.

alemanek Mar 17

I have seen this mostly on teams which refuse to formalize preferences into a style guide.

I have fixed this by forcing the issue and we get together as a team, set a standard and document it. If we can use tools to enforce it automatically we do that. If not you get a comment with a link to the style guide and told to fix it.

Style is subjective but consistency is not. Having a formal style guide which is automatically enforced helps with onboarding and code review as well.

_kidlike Mar 17

I'm very surprised by these comments...

I regularly review code that is way more complicated that it should.

The last few days I was going back and forth on reviews on a function that had originally cyclomatic complexity of 23. Eventually I got it down to 8, but I had to call him into a pair programming session and show him how the complexity could be reduced.

servo_sausage Mar 17

Someone giving work like that should be either junior enough that there is potential for training them, so your time investment is worth it, or managed out.

Or it didn't really matter that the function was complex if the structure of what's surrounding it was robust and testable; just let it be a refactor or bug ticket later.

_kidlike Mar 17

he is a junior yes.

I know the aggravation of getting a hairball of code to review, but I often hold my nose. At least find a better reason to send it back, like a specific bug.

If you're sure cyclomatic complexity should be minimized, I think you should put such rules in a pre-commit hook or something that runs before a reviewer ever sees the code. You should only have to help with that if someone can't figure out how to make it pass.

If you're not willing or politically able to implement that, you might be wasting time on your personal taste that the team doesn't agree with. Personally I'm pretty skeptical of cyclomatic complexity's usefulness as a metric.

surajrmal Mar 17

I always approve a change with comments for nits that are optional to address. I only hold back approval if there is a legitimate flaw of some sort. Generally this leads to small changes almost always getting approved on the first shot, but larger changes needing at least one back and forth. AI code review tools make it much easier to spot legitimate problems these days.

_kidlike Mar 17

I just used it here to approximately convey the scale.

the original function was full of mutable state (not required), full of special cases (not required), full of extra return statements (not required). Also had some private helper methods that were mocked in the tests (!!!).

All of this just for a "pure" function. Just immutable object in - immutable object out.

and yes, he was a junior.

swiftcoder Mar 17

> 2. 90% of PR comments are arguments about variable names.

This sort of comment is meaningless noise that people add to PRs to pad their management-facing code review stats. If this is going on in your shop, your senior engineers have failed to set a suitable engineering culture.

If you are one of the seniors, schedule a one-on-one with your manager, and tell them in no uncertain terms that code review stats are off-limits for performance reviews, because it's causing perverse incentives that fuck up the workflow.

anal_reactor Mar 17

The most senior guy has the worst reviews because it takes multiple rounds, each round finds new problems. Manager thinks this contributes to code quality. I was denied promotion because I failed to convince half of the company to drop everything and do my manager's pet project that had literally zero business value.

swiftcoder Mar 17

Yeah, I'm afraid that's an engineering culture that is thoroughly cooked. Not much choice except keep your head down until you are ready to cut your losses

worldsayshi Mar 17

People always makes mistakes. Like forgetting to include a change. The point of PRs for me is to try to weed out costly mistakes. Automated tests should hopefully catch most of them though.

The point of PRs is not to avoid mistakes (though sometimes this can happen). Automated tests are the tool to weed out those kinds of mistakes. The point of PRs is to spread knowledge. I try to read every PR, even if it's already approved, so I'm aware of what changes there are in code I'm going to own. They are the RSS feed of the codebase.

alkonaut Mar 17

This falls for the famous "hours of planning can save minutes of coding". Architecture can't (all) be planned out on a whiteboard, it's the response to the difficulty you only realize as you try to implement.

If you can agree what to build and how to build it and then it turns out that actually is a working plan - then you are better than me. That hasn't happened in 20 years of software development. Most of what's planned falls down within the first few hours of implementation.

Iterative architecture meetings will be necessary. But that falls into the pit of weekly meeting.

2OEH8eoCRo0 Mar 17

I've worked waterfall (defense) and while I hated it at the time I'd rather go back to it. Today we move much faster but often build the wrong thing or rewrite and refactor things multiple times. In waterfall we move glacially but what we would build sticks. Also, with so much up front planning the code practically writes itself. I'm not convinced there's any real velocity gains in agile when factoring in all the fiddling, rewrites, and refactoring.

> Most of what's planned falls down within the first few hours of implementation.

Not my experience at all. We know what computers are capable of.

steveBK123 Mar 17

> I've worked waterfall and while I hated it at the time I'd rather go back to it. Today we move much faster but build the wrong thing or rewrite and refactor things multiple times.

My experience as well. Waterfall is like - let's think about where we want this product to go, and the steps to get there. Agile is like ADHD addled zig zag journey to a destination cutting corners because we are rewriting a component for the third time, to get to a much worse product slightly faster. Now we can do that part 10x faster, cool.

The thing is, at every other level of the company, people are actually planning in terms of quarters/years, so the underlying product being given only enough thought for the next 2 weeks at a time is a mismatch.

It’s possible to manage the quarterly expectations by saying “we can improve metric X by 10% in a quarter”. It’s often possible to find an improvement that you’re very confident of making very quickly. Depending on how backwards the company is you may need to hide the fact that the 10% improvement required a one line change after a month of experimentation, or they’ll fight you on the experimentation time and expect that one line to take 5 minutes, after which you should write lots more code that adds no value.

Agile isn’t a good match for a business that can only think in terms of effort and not learning+value. That doesn’t make agile the problem.

steveBK123 Mar 17

My experience in an agile firm was that they hired a lot of experienced people and then treated them like juniors. Actively allergic to thinking ahead.

To get around the problem that deliverables took more than a few days, actual tasks would be salami sliced down into 3 point tickets that simply delivered the starting state the next ticket needed. None of these tickets being completed was an actual user observable deliverable or something you could put on a management facing status report.

Each task was so time boxed, seniors would actively be upbraided in agile ceremonies for doing obvious next steps. 8 tickets sequentially like - Download the data. Analyze the data. Load a sample of the data. Load all the data. Ok now put in data quality tests on the data. OK now schedule the daily load of the data. OK now talk to users about the type of views/aggregations/API they want on the data. OK now do a v0 of that API.

It's sort of interesting because we have fully transitioned from the agile infantilization of seniors to expecting them to replace a team of juniors with LLMs.

Heh, sounds like Goodhart's law gone wild at that place.

steveBK123 Mar 17

Yes - how to complete story points without actually solving any problems