If you thought the speed of writing code was your problem - you have bigger problems
64 points by drmorr
64 points by drmorr
The speed at which I type is important -- I need to type fast enough that I avoid boredom while getting a thought into a legible form. Speed of code is similar, per the author's identified bottlenecks. If you can produce code fast enough to bounce ideas off actual programs instead of mental models, your resulting artifact can be much better.
It doesn't solve human problems, but when you make generating code faster, and can start walking into meetings with built programs ready to be discussed, your human problems can at least work in reality instead of fantasy land.
Fully agree, properly used they allow exploring domains in a way impossible before. Easy to abuse? yes, very useful? also yes.
For how I work and how my brain works typing speed is also important since I can hold a thought without getting distracted for a fairly small amount of time. I find these arguments not very understanding that each brain works differently.
True, thus I've been using the so-called README driven development with tons of explicit details and TODOs. When excitement was gone I had to just dump the code out. Not it does an LLM.
This either comes from a person working in a very specific environment, or just projecting their imagined results. I don't know if they're representing the book correctly, but the idea as presented is just wrong. For example SOX compliance is not my bottleneck, but if someone got rid of it, I'd do my job better and faster. I'd probably improve in just about any metric due to being more happy as well. Some app starting to leak memory is not a bottleneck, but again fixing it would speed things up without making any system broken.
I'm also tired of hearing the "writing code is not the bottleneck" trope. Sometimes it is, sometimes it isn't. Not accepting nuance there was fine for 2024 level capabilities, but not 2026 level LLMs. You can do design, plans, mock-ups, etc. now. Sometimes you know exactly what needs to be done and typing is the slog. Sometimes even the investigation is a slog - there's a process and you have to go through the motions. (That can be outsourced) Not all coding ends up in a review. And even then, automatic code review is not terrible anymore. (It's not good, but it can be useful and time saving)
And you'd be happiest when totally unemployed, right? That's the point at which all of the compliance and correctness concerns vanish.
Sometimes you know exactly what needs to be done and typing is the slog.
How often? Less than once a year for me.
starts with a strawman, ends with projection. Only missing the purity signal.
"SOX compliance is a discardable bottleneck" is a strawman. Compliance is a core requirement; non-compliant deliverables cannot be legally delivered. I think that it's fair to, on that point, imagine all legal obstacles to delivery as discardable bottlenecks.
You didn't answer my questions, presumably because you know how the answers would embarrass the parent's position. I answered the second question already; to answer the first question, unemployment is quite liberating and has brought me a fair amount of happiness, both in the relief of no longer answering to a boss and in the bliss of being reunited with the fruits of my alienated labor.
SOX compliance is legal compliance. It has very little to do with anything else and is effectively rubberstamped access with lots of ceremony in every place I've seen. It's CYA documentation, not quality improvement. Actually the opposite in practice - the extra process means people will ignore some bugs instead of fixing them.
I don't get the correctness part of your post. I've vibe coded stuff which is more correct and extensively tested than what I'd end up producing by hand, exactly because I get to spend more time on that part. I've found genuine issues in other implementations because of that testing, so I know it really is better than what existed before.
How often?
In "feature" kind of code in a web app: 90%. In infra, maybe 5%. (Infra work is often 1-2 line changes)
I've started using AI a lot more in the last few months. It has made some difference in the speed of writing code, but not a lot.
When using it to write code, AI tools extend documentation. Sure, they hallucinate sometimes. But not enough to make them worthless. What they're most useful for is to solve problems where it would have taken me an hour or so to read through docs, find examples, write code, debug it, etc. The AI tools are much faster, especially if they can be given test cases.
Where the AI tools help enormously is code analysis. I can't remember complex interactions across 10K lines of code. But AI can. It can analyze the code and give me summaries which are generally pretty good.
The AI tools have changed my debugging time to nearly zero. That means I can spend my time doing things only I can do: good design, architecture, etc.
I'm not sure which of the llm-related tags (if either) belong on this article. It mentions vibecoding/in some sense is a response to it, but it's not really about using those tools. It's also clearly not about new AI research or development. So I ended up not tagging with either.
I need to open with: Strongly agree with a lot of this, and I've said similar elsewhere.
One nit: the VP of Engineering framing drifts into a familiar trope -- "VP is clueless, seniors are the font of wisdom." I think that’s increasingly holding this problem the wrong way.
That "wisdom layer" is exactly what’s being upended right now. In my experience, the biggest -- and most variable -- source of friction is the senior layer.
Which is uncomfortable, because that’s the group that can and should be leading the transition.
These difficult conversations happening right now.
This isn't a shiny new Kubernetes. Even if you'e a skeptic, both the method of building software and the business of building software are shifting -- and faster than most teams can metabolize.
So…how does one map a value stream?
I fully agree with the premise that a combination of random bureaucracy and a product process that exists to reduce the productivity and value of engineers is the problem.
This paragraph from the post has more specifics.
Map your value stream. Literally follow a feature from idea to production. Write down every step. Write down how long each step takes. Write down how long things sit between steps. The gap between steps is where your cycle time lives.
A lot of what is written is relatable to my professional pre-vibe professional xp. And I understand how, vibe coding, may not always help in a professional context.
Tho, the ui/ux of chatbot is much better than pre-llm Google / Stackoverflow / github sometime reddit to debug things. And yes, I do read man pages, and documentation.
Amdahl’s law is probably more applicable here and would make a stronger argument.
Did management measure where the blockage is? If it’s not in the coding path, speeding up coding won’t help.
It’s been my experience that waiting for managers to decide is the longest wait. Also these decisions are notoriously not optimal because they delay so long and then are forced to decide under duress and then the pressure is applied to the rest of the process to get the feature release ASAP.
So I agree with the point of the article, I think the argument could be made better.
Resonated pretty strongly with me. I’m grateful to work in a small org. The dynamic described reminds me that in larger organizations, everything comes to be viewed as a tool, even the tool operators. You want engineers being the ones saying “we need AI to help us write code faster”, if that’s indeed where they identify they’re struggling (perhaps they need to prototype lots?). Or identifying what there real stoppers are and managers/stakeholders listening and providing.
Or put another way, while AI accelerated code output is an example, the real (very real and observed) problem here is “deciders” not listening to and working with the “doers.”
I and several other fantastic engineers just got laid off from a small org... I thought I was safe too, alas :(
everything comes to be viewed as a tool, even the tool operators
this is just a captialism thing unfortunately
@hapax Very sorry to hear that.
Was it a “the business case just didn’t pan out”? Or a “now tha there’s AI… you’re not needed?”