Are you new to engineering? Coding was never the bottleneck. Having someone who knows what to do, and planning usually is.
I spend 20-30% of my time at most actively coding. 30-40% helping people with dumb things that take my time when they shouldn’t, and the remainder in meetings, scoping my work, or debugging.
I spend 20-30% of my time at most actively coding.
And by my experience, most of that time is still not “typing in code”.
As a benchmark, I was working in two greenfield projects, each for about five years. One was about a topic very close to my doctorate thesis in signal processing, one an embedded device for a large scientific experiment - with the systems engineers and the scientists as users sitting next door. So, in both cases, extremely well defined, far better than what an average programmer will ever see. Some colleagues worked on the JWST. That org knows damn well how to engineer stuff.
At the end of these five years, I had both times around 60,000 lines of code. Pretty productive.
Now, let’s do the math: With about 250 work days per year, that is … 48 lines of code per day. You could type that in five minutes (and no, you don’t need a Dvorak keyboard layout to do this, LOL).
For old legacy projects, that average will be far far worse.
So, most of the productive time is actually thinking about code, and talking with people. And LLMs can’t do that. They can only type. And worse, doing that they don’t use the most important key for a programmer: The ‘delete’ key.
That is just the thing, developer and tester should never be the same person. Let alone same AI model. IMO testing is never taken seriously enough, just seen as unnecessary step and merged together with dev testing. From my years of experience I know that everything testers find is just explained away rather than properly adressed, and then with all of the obvious stuff in the way you never see the real issues.
I have experience with AI generated test suites, and while its good for generating coverage, it isn’t so good for actually ensuring correctness, which is the actual point.
I’ve watched the robot happily introduce bugs to pass broken tests, and also break tests to match code, and everything in between.
You have to prompt for that, I do that regularly along with refactors. ‘Examine all tests to ensure they are testing functionality and not just passing a test.’ It finds them and will work on it. I think the problem continues to be engineering discipline. People are lazy with AI on multiple levels, not just copy pasta slop.
Basically programmers are becoming designers and code reviewers.
There are now so many code changes that the code review is the bottleneck more than the coding.
We depend more now on tests to validate software does what it should. We get AI to write the gazillion tests.
And we get AI to summarize and explain blocks of code.
Are you new to engineering? Coding was never the bottleneck. Having someone who knows what to do, and planning usually is.
I spend 20-30% of my time at most actively coding. 30-40% helping people with dumb things that take my time when they shouldn’t, and the remainder in meetings, scoping my work, or debugging.
And by my experience, most of that time is still not “typing in code”.
As a benchmark, I was working in two greenfield projects, each for about five years. One was about a topic very close to my doctorate thesis in signal processing, one an embedded device for a large scientific experiment - with the systems engineers and the scientists as users sitting next door. So, in both cases, extremely well defined, far better than what an average programmer will ever see. Some colleagues worked on the JWST. That org knows damn well how to engineer stuff.
At the end of these five years, I had both times around 60,000 lines of code. Pretty productive.
Now, let’s do the math: With about 250 work days per year, that is … 48 lines of code per day. You could type that in five minutes (and no, you don’t need a Dvorak keyboard layout to do this, LOL).
For old legacy projects, that average will be far far worse.
So, most of the productive time is actually thinking about code, and talking with people. And LLMs can’t do that. They can only type. And worse, doing that they don’t use the most important key for a programmer: The ‘delete’ key.
That is just the thing, developer and tester should never be the same person. Let alone same AI model. IMO testing is never taken seriously enough, just seen as unnecessary step and merged together with dev testing. From my years of experience I know that everything testers find is just explained away rather than properly adressed, and then with all of the obvious stuff in the way you never see the real issues.
Interested in how much actual experience you have with AI geneated testsuites.
My code was never tested this well.
I have experience with AI generated test suites, and while its good for generating coverage, it isn’t so good for actually ensuring correctness, which is the actual point.
I’ve watched the robot happily introduce bugs to pass broken tests, and also break tests to match code, and everything in between.
I don’t want lots of tests, I want good tests.
You have to prompt for that, I do that regularly along with refactors. ‘Examine all tests to ensure they are testing functionality and not just passing a test.’ It finds them and will work on it. I think the problem continues to be engineering discipline. People are lazy with AI on multiple levels, not just copy pasta slop.