Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Eight Myths on Software Engineering and GenAI

queue.acm.org

Post reply on HN
Print view View original

101–110 of 269 posts

Re: Eight Myths on Software Engineering and GenAI

#101

Post by griffiths »

claytongulick wrote: post #67
mikeyouse wrote: post #50

Earlier quoted context omitted.

In some number of cases, the business partner who would have passed you the requirements will just generate the code themselves.. I’m shocked shin some engineers don’t see a massive disruption coming..

Oh, some of us see a massive disruption coming, just maybe not in the way you think. Talented, experienced devs leaving the field out of disgust would be pretty disruptive. Crumbling, faulty technical infrastructure with unmanageable heaps of AI slop that no one understands would definitely disrupt businesses. Skill atrophy, and an entire generation of "developers" that have never actually written code will be disrup…

You will have artisans or software SWAT teams on one side and code factories on the other. For most problems code factories will be good enough.

Re: Eight Myths on Software Engineering and GenAI

#102

Post by miraculixx »

jdlshore wrote: post #81
baobeta2907 wrote: post #75

This is actually true at my company. They expect employees to be 10× more productive now that we have AI.

I’ve had people tell me, with a completely straight face, that they expected 10-100x productivity improvements. This is at the executive and VC level. The mania is extreme.

So then they should get 10-100x more revenue, now that AI does all the marketing and selling.

Re: Eight Myths on Software Engineering and GenAI

#103

Post by simonw »

the_af wrote: post #77
simonw wrote: post #40

Earlier quoted context omitted.

How's this? https://simonwillison.net/2026/Jul/13/datasette-code-frequen... I have similar charts across my three main open source projects: https://github.com/simonw/datasette/graphs/code-frequency https://github.com/simonw/llm/graphs/code-frequency https://github.com/simonw/sqlite-utils/graphs/code-frequency

Isn't this falling into the "lines of code" trap TFA mentions? More code written is not a good measure of productivity. It could be garbage, or redundant code, or simply not addressing the real or more pressing needs, it could be building the wrong thing, etc. Like TFA mentions, it's been known for decades LoC is a misleading metric for productivity. It's one of the lessons of software engineering.

I'm planning an article at the moment in defense of lines of code. Saying "lines of code are a bad measurement" is too easy! It's about time someone presented an opposing argument.

In my specific case, lines of code for my published open source projects is a metric that I trust, because I have high standards for those. I have plenty of other projects where I'll accept poor quality, unreviewed code (almost all of https://github.com/simonw/tools for example), but Datasette, sqlite-utils and LLM are not that.

Of course, that's only useful for me personally and for people who trust me to stick to my own self-declared high standards!

Re: Eight Myths on Software Engineering and GenAI

#104

Post by unknownfuture »

simonw wrote: post #40
unknownfuture wrote: post #15

Earlier quoted context omitted.

Self-reported or observational data capturing time spent for categories of task ala every other similar study in this space? This isn't exactly novel territory, here, Simon. Let's not pretend I'm asking for something strange, unprecedented, or unreasonable.

How's this? https://simonwillison.net/2026/Jul/13/datasette-code-frequen... I have similar charts across my three main open source projects: https://github.com/simonw/datasette/graphs/code-frequency https://github.com/simonw/llm/graphs/code-frequency https://github.com/simonw/sqlite-utils/graphs/code-frequency

The article mentions that coding is only a fraction of dev time and thus accelerating that part of the job can only create incremental gains, and oh PS, lines of code and similar metrics are a bad way if measuring dev productivity, anyway, and we've known that for decades.

The OP claims AI accelerates non-coding parts of the job, too, and so the article is misguided.

I ask for evidence.

In response you give me... code output metrics?

Re: Eight Myths on Software Engineering and GenAI

#105

Post by simonw »

geraneum wrote: post #90
simonw wrote: post #4

> We already know developers don’t actually spend most of their time writing code, with studies at Microsoft and elsewhere showing it’s closer to 14 percent. Anyone else finding they're spending more time writing code (or at least driving agents to write code) now? 14% used to feel about right for me - I'd spend the rest of the time researching approaches and libraries, planning things out in issues, or sometimes jus…

Does the code get reviewed? How do you deal with increased amount of code that may need to be looked at?

I review the code that matters - anything security adjacent or that's an API that will be used by other code in the future.

I don't review code that either works or doesn't - most HTML and CSS layout code for example. There I test it on desktop and mobile and commit it if it works.

Ditto for stuff that's simple. A JSON endpoint that runs a SQL query and returns some JSON? If it works and a glance at the tests looks OK then I trust my agents wrote it properly.

I'm getting more confident with my judgement over what needs a close look and what doesn't over time, as so far I haven't been majorly burned my any mistakes that snuck through.

Honestly, it's similar to being an engineer on a larger team. You don't review every line of code written by every one of your coworkers.

I think this is THE issue of our time as programmers to be honest: do you review every line of code an agent writes?

An increasing number of expert programmers are moving in the direction of NOT reviewing every line. It's working out OK for a lot of them.

Re: Eight Myths on Software Engineering and GenAI

#106

Post by sandeepkd »

Exoristos wrote: post #83
sandeepkd wrote: post #49

Earlier quoted context omitted.

From the patterns I have seen people would tend to use the time to build demo's using AI instead of design and then have a back and forth on the demo itself. One has to consider the fact that demo's look more convincing/complete and give an impression that the design decision has been made. In some ways, how agile got rid of the need for explicit & detailed documentation, the AI created demo's will cut the requiremen…

> demo's look more convincing/complete ... In the case of an LLM generated demo, usually deceptively so. > and give an impression that the design decision has been made. In the case of a vibed design, this is the opposite of useful for the team.

The concept of MVP has been there for a while, it felt deceptive too and incurred lot of tech debt. However one would feel the deception only if they understand the missing details. For a lot of roles making decisions it benefits them to ignore the details unless it really bites them

Re: Eight Myths on Software Engineering and GenAI

#107

Post by whatsgolden »

MikeTheGreat wrote: post #86
guybedo wrote: post #25

Earlier quoted context omitted.

although, if i'm out of tokens and have to wait a full day, i won't bother doing some things manually because the day i'll spend doing something won't take more than 1 hour the next day when tokens are available again.

That seems like a somewhat orthogonal point? Like, if I'm a carpenter and my batteries all run out / I can't actually power my power tools then the best course of action is to go home and recharge all the batteries instead of trying to hand-cut 100 pieces of lumber today. After all, the power tools can do it a lot faster (and with less effort) than I can. I say this as someone who's watched a bunch of woodworking vid…

I read that more so as, I'm a carpenter and my batteries have all ran flat, so I'll put them on charge and do something else today. I'll cut up the lumber tomorrow when the batteries have charged.

Re: Eight Myths on Software Engineering and GenAI

#108

Post by 1saadcodes »

I think the paper would have been stronger if it acknowledged how quickly the underlying evidence is becoming outdated. AI-assisted development in 2026 isn't just better models. The way many devs including myself work has changed and matured quite a bit as compared to last year

Re: Eight Myths on Software Engineering and GenAI

#109

Post by tkzed49 »

1saadcodes wrote: post #108

I think the paper would have been stronger if it acknowledged how quickly the underlying evidence is becoming outdated. AI-assisted development in 2026 isn't just better models. The way many devs including myself work has changed and matured quite a bit as compared to last year

how so?

Re: Eight Myths on Software Engineering and GenAI

#110

Post by bwhiting2356 »

a_bonobo wrote: post #16

>On my visits to the Bay Area, I would ask AI researchers or interns why they are doing their current research or projects, when in a year or three agentic LLMs could probably do them; This is such a weird point to make that doesn't become correct just because everyone makes it, all the time. Why clean the ocean if some magic future tech will clean them? Why save the world now if some benevolent AI is 'just around th…

A fully automated utopia isn't just going to happen. Even with frontier models, the integrations, the evals, the UX, need a lot of work and someone needs to do it. After I've automated this thing I'll move on to the next task, this is what it means to be a software engineer.
Post reply on HN