If you thought code writing speed was your problem you have bigger problems

gammalost

Seems easy to address with a simple rule. Push one PR; review one PR

luxuryballs

It’s definitely going to create a lot of problems in orgs that already have an incomplete or understaffed dev pipeline, which happen to often be the ones where executive leadership is already disconnected and not aware of what the true bottlenecks are, which also happen to often be the ones that get hooked by vendor slide decks…

furyofantares

> The bottleneck is understanding the problem. No amount of faster typing fixes that. Why not? Why can't faster typing help us understand the problem faster? > When you speed up code output in this environment, you are speeding up the rate at which you build the wrong thing. Why can't we figure out the right thing faster by building the wrong thing faster? Presumably we were gonna build the wrong thing either way in this example, weren't we? I often build something to figure out what I want, and that's only become more true the cheaper it is to build a prototype version of a thing. > You will build the wrong feature faster, ship it, watch it fail, and then do a retro where someone says "we need to talk to users more" and everyone nods solemnly and then absolutely nothing changes. I guess because we're just cynical.

gedy

I'm cynical but kinda surprised that so many mgmt types are rah-rah AI as "we're waiting for engineering... sigh" has been a very convenient excuse for many projects and companies that I've seen over past 25 years.

everdrive

Companies genuinely don't want good code. Individual teams just get measured by how many things they push around. An employee warning that something might not work very well is going to get reprimanded as "down in the weeds" or "too detail oriented," etc. I didn't understand this for a while, but internal actors inside of companies really just want to claim success.

6stringmerc

Because the way the world is currently and this is trending, let me jump in and save you a lot of time: Expedience is the enemy of quality. Want proof? Everyone as a result of “move fast and break things” from 5-10 years ago is a pile of malfunctioning trash. This is not up for debate. This is simply an observation. I do not make the rules. See my last submission for some CONSTRUCTIVE reading. Bye for now.

petcat

As human developers, I think we're struggling with "letting go" of the code. The code we write (or agents write) is really just an intermediate representation (IR) of the solution. For instance, GCC will inline functions, unroll loops, and myriad other optimizations that we don't care about. But when we review the ASM that GCC generates (we don't) we are not concerned with the "spaghetti" and the "high coupling" and "low cohesion". We care that it works, and is correct for what it is supposed to do. And that it is a faithful representation of the solution that we are trying to achieve. Source code in a higher-level language is not really different anymore. Agents write the code, maybe we guide them on patterns and correct them when they are obviously wrong, but the code is merely the work-item artifact that comes out of extensive specification, discussion, proposal review, and more review of the reviews. A well-guided, iterative process and problem/solution description should be able to generate an equivalent implementation whether a human is writing the code or an agent.

renewiltord

Understanding the problem is easier for me experienced with engaging with solutions to the problem and seeing what form they fail in. LLMs allow me to concretize solutions so that pre-work simply becomes work. This allows me to search through the space of solutions more effectively.

lukaslalinsky

If I can offload the typing and building, I can spend more energy understanding the bigger picture

danilocesar

I'm here just for the comments...

teaearlgraycold

> I once watched a team spend six weeks building a feature based on a Slack message from a sales rep who paraphrased what a prospect maybe said on a call. Six weeks. The prospect didn't even end up buying. The feature got used by eleven people, and nine of them were internal QA. That's not a delivery problem. That's an "oh fuck, what are we even doing" problem. I have very much upset a CEO before by bursting his bubble with the fact that how fast you work is so much less important than what you are working on. Doing the wrong thing quickly has no value. Doing the right thing slowly makes you a 99th percentile contributor.

nathias

people can have more than one problem

podgorniy

Yeah, we again have a solution (LLMs) in search of problems. Proper approach to speeding things up would be to ask "What are the limiting factors which stops us from X, Y, Z". -- This situation of management expecting things to become fast because of AI is "vibe management". Why to think, why to understand, why to talk to your people if you saw an excited presentation of the magic tool and the only thing you need to do is to adopt it?..

wolttam

"Our newest model reduces your Mean Time To 'Oh, Fuck!' (MTTF) by 70%!"

725686

The word typing is wrong. It is not about the speed of typing code. Its about the speed of "creating" code: the boilerplate code, the code patterns, the framework version specific code, etc.

larsnystrom

I can really relate to this. At the same time I’m not convinced cycle time always trumps throughput. Context switching is bad, and one solution to it is time boxing, which basically means there will be some wait time until the next box of time where the work is picked up. Doing time boxing properly lowers context switching, increases throughput but also increases latency (cycle time). It’s a trade-off. But of course maybe time boxing isn’t the best solution to the problem of context switching, maybe it’s possible to figure out a way to have the cookie and eat it. And maybe different circumstances require a different balance between latency and throughput.

gyanchawdhary

he’s treating “systems thinking” and architecting software like it’s some sacred, hard to automate layer that AI apparntly sucks at ..

milesward

Correct, but I'd frame it to confused leaders a bit differently. Because we made this part easier, we've increased how critical, how limiting, other steps/functions are. Data's more valuable now. QA is more valuable now. More teams need to shift more resources, faster.

sorokod

Amdahl's law applies regardless of whether you are believe in it or not

avereveard

Eh code doesn't have a lot of value. Especially filling methods between signatures and figuring out the dependencies exact incantation is mechanistic and definitely time better spent doing other things. A lot of these blog start from a false premise or a lack of imagination. In this case both the premise that coding isn't a bulk time waste (and yes llm can do debugging, so the other common remark still doesnt apply) is faulty and unsubstantiated (just measure the ratio of architects to developers) but also the fact that time saving on secondary activities dont translate in productivity is false, or at least it's reductive because you gain more time to spend on doing the bottlenecked activity.