81–90 of 206 posts
There's another great comment by daxfohl that I saved. The "complacency" at scale worries me [1] Copied to save you a click: > I worry about the "brain atrophy" part, as I've felt this too. And not just atrophy, but even moreso I think it's evolving into "complacency". Like there have been multiple times now where I wanted the code to look a certain way, but it kept pulling back to the way it wanted to do things. Lik…
Earlier quoted context omitted.
Do you have management pressure to use these tools? I don’t have any data but me and virtually every software engineer I talk to regularly is feeling or has felt pressure to use these tools.
FWIW, I'm responsible for our engineering team, and I'm the one starting to put some gentle pressure on the developers right now. Velocity used to be one of the bigger issues we had: Features used to be in development over weeks, while customers, product management, and engineers iterated on the feature, until it was finally deemed stable enough and shipped. With AI, we can shorten that cycle considerably, and get st…
And it is. You are going to end up with a wreck of a product and not a single person you can call upon to fix it. It is your choice and you will pay for it.
Earlier quoted context omitted.
Do you have management pressure to use these tools? I don’t have any data but me and virtually every software engineer I talk to regularly is feeling or has felt pressure to use these tools.
FWIW, I'm responsible for our engineering team, and I'm the one starting to put some gentle pressure on the developers right now. Velocity used to be one of the bigger issues we had: Features used to be in development over weeks, while customers, product management, and engineers iterated on the feature, until it was finally deemed stable enough and shipped. With AI, we can shorten that cycle considerably, and get st…
Is there definitive proof of long term productivity gains with no detriment to defects, future velocity, etc?
If so I’d say you’re irresponsible at best to put this much trust in a tool that’s been around for a few months (at the current level). Absolutely encourage experimentation, but there’s a trillion dollar marketing hype machine in overdrive right now. Your job is to remind people of that.
The hell with with whatever speed boost I might get. I still write all my code by hand every day, and own what it does. I know it. And I don't have to worry about atrophy. Could've outsourced a long time ago to humans, if I wanted to deal with reading code most of the time instead of writing it.
Writing code by hand and managing the mental model of its execution and architecture is one of the few remaining joys of my day job, apart from delivering a good product people want and use and being helpful. Even the small things, the tedious chores of refactoring or scaffolding that initial bit of CRUD boilerplate are steps that matter to me. The callouses matter. The tedium matters. These moments of pain and drudg…
I've found that I reach for Copilot most often when working on frontend javascript code. Will the incentive to improve the frontend libraries, browser standards, etc vanish now that LLMs let us avoid some of this pain?
One of the things I have started to realize whilst building apps using AI is that you get a bit indulgent when it comes to features. So in my toy project I wanted all sorts of quality of life bells-and-whistles. If this were a proper enterprise application there would have a been a review and priortization process where the merits would be weighted against the cost. In this case the cost is tokens, so fraction of FTE…
Other comments have mentioned upstream delays in deciding what features to build now that teams can deliver faster - but you bring up another issue around downstream “understanding debt”. How can sales and marketing sell this stuff if they don’t even know what everything does? How does customer service support it? Sure you can just slop-together documentation, blogs, etc but what good are all these extra features if…
I started my coding apprenticeship back in early 80s with a senior programmer who taught me to code in LSI-11 processor codes. I memorized the whole table of octal processor opcodes and learned how to compose them with data to write programs on PDP-11. I was able to understand what each exact 16-bit word in my program is doing. It was a great skill. But then the same guy taught me FORTRAN 83, and I suddenly understoo…
The difference between now and then is a grand skill shift (from logic to vibe) and also fear of being replaced by this technology which was never the case before at this scale. You and me, we don't have this fear but many colleagues fear this new tech and also those colleagues who seem to get along with it.
To me, personally, this shift is really enabling and refreshing. I usually have lot's of ideas but did not neither time nor capacity to play with them. Some of them were just impossible to do as a team of one. Now everything is possible! :)
Earlier quoted context omitted.
"so as long as I maintain my ability to reason about code…what’s the issue?" It seems like that is the open question. The article suggests that people don't maintain this ability: "The AI group scored 17% lower on conceptual understanding, debugging, and code reading. The largest gap was in debugging, the exact skill you need to catch what AI gets wrong. One hour of passive AI-assisted work produced measurable skill…
This use to be the most embarrassing thing that could happen. A team member asks you why you did something a certain way during a PR and you can't provide an answer. This seems to be becoming the norm now.
Edit: I had an instance once where about once a month another developer would ask me about workplace setup, mentioned it to someone and was told maybe they were the English speaker of the group. Upon further investigation, that seemed to be the case.
The challenge is that the competitive and economic pressures make this moot.
A person, entering the field via AI driven development, will have none of the qualms about skill, seniority, understanding the codebase, or craftsmanship. Those arguments are handwringing by the previous generation of engineers. Their focus is solely on the outcome and value produced from the input prompt. That aligns closer to how businesses see their codebase: something they have to prompt their engineers to produce in order to generate business value.
Similarly, new AI driven companies focused on delivering value at speed and lower costs will have none of the baggage of the legacy code companies with engineers stuck debating these questions. These new gen companies will be focused on delivering value, doing so at quicker speeds and lower costs, raising the level of competition for existing incumbents.
Will existing businesses be willing to spend money to purchase services from these new gen companies of AI developed products? Seems like it.
There are real problems with these AI developed codebases. They tend to collect baggage and start to feel like a house of cards. A big open question is whether AI models will continue to improve in order to patch all the vibe-holes being generated. Seems like they will improve.