In 2009, Microsoft’s launch of Songsmith did not meet expectations. Designed as a tool for anyone to make music, all you had to do was sing a few lines, and the software would provide a beat and melody to go with it. The New York Times was one of many to point out its faults, quoting Susan Sontag from Notes on Camp: “Bad to the point of being laughable, but not bad to the point of being enjoyable.”
It turns out the available inputs (Happy, Jazzy) weren’t enough to create good music. Some understanding of music theory, even learned informally, was necessary to create something worthwhile. If released today, Songsmith would likely fall into the ‘vibe-composing’ category alongside tools such as Strudel.
Research tells us that most developers use AI coding tools daily. Yet serious developers are not ‘vibe coding’. They are integrating AI as part of their workflow of creating, interrogating and refining code, involved at each stage but not wholly responsible for any part. Used efficiently, AI does not result in the coding equivalent of Songsmith’s legacy, but secure, reliable code, created efficiently.
The use of AI today is more like the electronic music and sampling revolution of the 1980s — improving how developers work with new techniques and tools, but still underpinned with knowledge and experience. However, with any evolution, the infrastructure that supports developers needs to adapt, too.
Ensuring Productivity
Research has shown a link between higher AI use and lower productivity. How can this happen? The problem arises when productivity gains are not shared across the entire coding cycle. When developers make changes faster than anyone can review and test, it results in backlogs and wasted time dealing with them.
There is also, sometimes, a problem of sloppiness. Around a third of developers admit to not checking code before shipping it: A habit that desperately needs to be changed in the AI era. AI-created code is like a rough draft, likely to contain errors and inefficiencies. AI tools will likely generate code that works, but it will take more effort to generate good, efficient and thoroughly tested code.
One of the major downsides of AI use is more time spent reviewing code than coding itself. If code can be put together in seconds, but careful review takes much longer, it simply makes sense for this to be the focus of the work.
The job of developers has fundamentally shifted from ‘write code’ to ‘orchestrate and validate code generation’. The future is ’spec coding’, creating specifications that become a ’single point of truth’ for both developers and their AI tools to follow.
The important decisions, therefore, still lie with humans: Writing specifications and defining interfaces, data models and security boundaries — all the big decisions that matter in the long run and are hard to reverse. With these decisions made, AI can then handle the implementation within human-authored constraints and guidelines.
Spec coding means developers can be seen as the lead architect, heading up a team of AI coders. Rather than relying on a single AI tool, multiple tools can be used, and AI can review and critique code written by another AI, just as developers review code written by others. Moreover, while we should be careful of assigning emotions to AI tools, they often seem to enjoy criticizing the work of other AI tools, making for useful and diligent reviews.
This is very far from the idea of vibe coding. In fact, it places more demand on a coder’s knowledge, relying on them to spot errors, inefficiencies and security vulnerabilities. It means putting in place the right support so that developers can continue to work with these changes.
This also highlights a key finding: Humans can cope with gaps and incomplete guidelines. AI tools just get stuck in loops or deliver malfunctioning code. We must get better at following a more structured software delivery process than what we’ve done these past 20 years.
Putting the Right Support in Place
We’re often told that good developers will use AI responsibly. However, a developer doesn’t have to be lazy to end up misusing AI. Deadline pressure, unfamiliar domains, junior developers who lack the experience to fully understand risks — these are all potential issues that may lead to irresponsible use of AI. These are not due to misplaced risks, but rather a lack of safeguards.
The infrastructure developers build on need to have systemic safeguards in place to ensure safety without feeling restrictive or slowing down development. This should include:
- Fast and Reliable Build Pipelines: Find issues fast and create deterministic build artifacts.
- Automated Security Scanning: This shouldn’t be optional; it should happen for every change, no matter how small.
- Instant Preview Environments: Production-like conditions to test code should be available immediately.
- Policy as Code: Automatic compliance can be automatic with the right rules, rather than asking developers to remember policies such as ‘containers don’t run as root’ and ‘log all external API calls’.
- Software Bills of Material: Log4j taught us how valuable software bills of materials (SBOMs) can be in identifying exposure to security issues. Generating these in CI/CD simplifies this process and makes it automatic.
The thinking should be that there is no need for shortcuts, as the best way of working is already available and is straightforward. That way, responsible AI use is built in.
Responsible AI use as the Default
AI is not going to replace developers any time soon. It may take away some of the more tedious work and help create solutions to problems, but the need for humans to review and improve code is just as valuable as the ability to code quickly.
But AI is here, and in use, so developer teams need to be ‘AI-ready’. That doesn’t mean being willing to use AI, or even encouraging its use, but rather creating the infrastructure and policies for AI use to thrive, and changing the expectations of developers so they can make the best use of AI.
Being a developer is far more than just creating code — it’s about designing reliable user experiences, handling edge cases, ensuring security, managing integrations and maintaining performance. All these responsibilities fall outside of AI’s capabilities. It is, in effect, why Songsmith failed — it could put together a melody and a beat but lacked the understanding of music to be truly creative, while the human using the software couldn’t get involved enough with the process to make something good.
That’s why robots and humans need the right infrastructure and support to enable success. Developers’ roles may change, but they remain fundamental to the process.
