251–260 of 269 posts
Maybe not 10x, but there's definitely a significant boost in velocity of development and delivery.
We used to be a team of 20+, now only 9, and we are delivering more than before. Besides that, we did some major refactors that were sitting in the backlog for months.
Earlier quoted context omitted.
I've been waiting with baited breath for this to bite me for more than six months now. So far unbitten.
meaningless without telling us what you're working on
I don't understand Myth 1 (Developers Spend Most of Their Time Writing Code). They quote a study in which developers report to spend 11-14% of their day coding. The rest is stuff like solution design and meetings. The insinuation is that AI can at most automate 14% of your day. The problem with this argument is that once you have code, some (not all) of the precursors to code go away.
Yeah, this seriously drives me nuts. That meeting that you spent an hour in to understand the requirements? You don't need that meeting if you're not writing the code. That sync up with the QA engineer you did to hand it off to them? Don't need that meeting if you're not writing the code. That half hour you spent installing vim extensions? Don't need 'em if you don't open vim anymore. There are engineers whose jobs g…
You don't need that meeting if you're not writing the code.
My mates are not, their code editor are not either : I am.
Yes, I could be a clown and be accountable for something I know nothing about. I choose not to.
Not everybody is a cruft-engineer .
even an AI assist that makes coding twice as fast would, in theory, improve developers’ overall productivity by less than 15 percent. The other 85 percent of their time remains untouched I stopped reading after this. AI has massively impacted most aspects of my non-coding work including the mentioned planning, understanding legacy code bases, setting up environments, etc etc. Either this article is written by people…
Earlier quoted context omitted.
I don't have anything else to hand that I can think of. I don't keep a time tracking diary.
> I don't keep a time tracking diary. That's why Microsoft did a study (referenced in the article), where they measured the time spent on things, so they could get to the truth of how much time people spend coding using "a shape of evidence would you find convincing"
Earlier quoted context omitted.
Lots os engineering projects took as long as you mentioned because they were horribly specified. Then the engineer either waits for an answer (which they generally do not get) or takes a decision (which might not be ideal without domain knowledge). Then you release and the customer suddenly starts explaining what they want. You can improve some parts with LLM (make more prototypes, iterate faster), but if humans are…
Specification is hard because you are trying to predict a future state in a vacuum. You need to do that because creating the product is very expensive coding wise. If instead you could instantly build to your current specification then you could iterate on the specification against a real product. Even if all that code is thrown out the end result would be a better specification.
My experience is that users (customers) even when presented with a prototype (done fast by AI, or previously, in the slow way) can take days to "discover" or "think" about things they wish. Then more days to understand why some wishes can't be done because it breaks other stuff they want.
Maybe you have smarter, faster, more experienced and decided users. Then I can only say: good for you, you are lucky!
Earlier quoted context omitted.
Because customers have better things to do.
Do they though? I assume they’re also getting replaced by LLM in this hypothetical.
Earlier quoted context omitted.
>> How are you going to prompt the LLM or validate its output if you don't understand the requirements? > Your PM can write the ticket, and your QA can test the output. If your PM can write the ticket and your QA can test the output, why not cut out the middleman by having the PM write the coding agent prompt(s)? And if your PM can write the coding agent prompt(s), why not cut out the QA group by having the PM write…
And finally: Why bother making new software at all when AI can just do the thing you wanted done, directly?
In many ways, the "save costs by LLM-ing everything" mindset is the same logical fallacy companies fell into in the 90's/00's with regard to outsourcing. The end-state was rationalizing outsourcing call centers, then production system support, then software development, then project management, then...
Once the outsourcing raptor came for the accountants (who wrote the cheques) and remaining management (who cashed quarterly bonus cheques), outsourcing became "less appealing."
Earlier quoted context omitted.
> That was because coding was expensive and we needed to be sure we didn't code the wrong thing. Coding has never been expensive as it is nothing more than a reification of a solution to a problem as it is understood at that time. It is the underlying understanding of the problem which has always been expensive and remains so.
Coding was expensive in the sense that once you decided what to do, it took a few engineers months / years to do moderately complex projects. That's not true anymore. Therefore the risk of "coding the wrong thing" is less.
This conflates two orthogonal concerns; understanding what needs to be done with encoding a solution for what needs to be done. I am reminded of an axiom I have long held:
When making software, remember that it is a snapshot of
your understanding of the problem. It states to all,
including your future-self, your approach, clarity, and
appropriateness of the solution for the problem at hand.
Choose your statements wisely.
I disagree with the proposition that being able to generate "wrong code faster" has anything to do with understanding what ultimately needs to be done. In fact, exploratory efforts having the intent to refine problem domain understanding (a.k.a. "proof of concept" projects) is an established industry technique whose work product is best discarded.