My experience with AI software engineering, as someone who did without for over a decade, is that you stay up the abstraction layer for longer now. Before AI, over 60% of your time involved weird finicky edge-cases. Learning the interfaces of new libraries, automating a series of simple commands you had manually entered enough that converting the workflow would pay dividends later, conflicts between versions of libraries, conflicts between libraries and the language version, conflicts between operating systems. The was an incredible amount of busywork.
Now, you spend a lot more time defining the problem, defining how the system will scale, trust boundaries for security, and more than anything, designing the architecture so it’s maintainable and iterating on parts of the code that don’t follow the architecture. Software engineering has essentially moved from involving tons of junior level learning, to primarily staff level work. Junior engineers are now prompting but without having the hard lessons from the past, so they can’t see the problems they’re introducing. This leads to modern codebases spiraling into chaos and invisible bugs are introduced even after iterating on fixes, and if the base does get handed off to an experienced engineer, fixing it is a slog. Writing tests, previously a less emphasized part of the job, is now one of the most critical parts of the workflow. Writing tests before writing a feature is frequently less prone to bugs than the implementation code, and keeps AI generation honest about functionality and stability. This is why they have a tendency to reward hack and create tests that pass naively. Since a junior programmer would frequently miss these naive tests, even those critical tools will fail.
We’re faced with a liminal moment in software development. Lots of features and functionality are being shipped, while those systems are also trivially exploitable, and unstable, and will have to be rewritten as they’re less maintainable than simply regenerating. The next stage is that RSI produces superhuman coders, that will then replace the functionality that barely functions now, and we’ll see a wave of cyberattacks in the interim as the amount of ambient exploitable code has exploded relative to stable engineering. Soon after, we will then see security harden as intelligent firewalls become the norm.
Many of the organizations who decided to continue to employ experienced engineers will differentiate themselves. Because they’ll experience the best of all worlds in terms of productivity, stability, and security.
The hard part of software engineering has always been figuring out the right requirements. Once you do that, writing source code is merely doing a particularly difficult type of compiling. ;)
My experience with AI software engineering, as someone who did without for over a decade, is that you stay up the abstraction layer for longer now. Before AI, over 60% of your time involved weird finicky edge-cases. Learning the interfaces of new libraries, automating a series of simple commands you had manually entered enough that converting the workflow would pay dividends later, conflicts between versions of libraries, conflicts between libraries and the language version, conflicts between operating systems. The was an incredible amount of busywork.
Now, you spend a lot more time defining the problem, defining how the system will scale, trust boundaries for security, and more than anything, designing the architecture so it’s maintainable and iterating on parts of the code that don’t follow the architecture. Software engineering has essentially moved from involving tons of junior level learning, to primarily staff level work. Junior engineers are now prompting but without having the hard lessons from the past, so they can’t see the problems they’re introducing. This leads to modern codebases spiraling into chaos and invisible bugs are introduced even after iterating on fixes, and if the base does get handed off to an experienced engineer, fixing it is a slog. Writing tests, previously a less emphasized part of the job, is now one of the most critical parts of the workflow. Writing tests before writing a feature is frequently less prone to bugs than the implementation code, and keeps AI generation honest about functionality and stability. This is why they have a tendency to reward hack and create tests that pass naively. Since a junior programmer would frequently miss these naive tests, even those critical tools will fail.
We’re faced with a liminal moment in software development. Lots of features and functionality are being shipped, while those systems are also trivially exploitable, and unstable, and will have to be rewritten as they’re less maintainable than simply regenerating. The next stage is that RSI produces superhuman coders, that will then replace the functionality that barely functions now, and we’ll see a wave of cyberattacks in the interim as the amount of ambient exploitable code has exploded relative to stable engineering. Soon after, we will then see security harden as intelligent firewalls become the norm.
Many of the organizations who decided to continue to employ experienced engineers will differentiate themselves. Because they’ll experience the best of all worlds in terms of productivity, stability, and security.
The hard part of software engineering has always been figuring out the right requirements. Once you do that, writing source code is merely doing a particularly difficult type of compiling. ;)