AI-assisted software development: Choosing the right tools
As writing code gets easier, good software engineering increasingly comes down to choosing the right way to solve the problem.
Nowadays, we have an ever-growing set of tools at our disposal. They don’t just make us work faster, they are changing the way we think about software development by encouraging us to think about problem solving differently.
I recently took on a piece of work for our sales team. The brief was simple:
“Can we automate the process of identifying genuine sales opportunities from website enquiries and social media interactions while filtering out the growing volume of spam?”
It will come as no surprise that we intended to leverage AI, but sending everything through a language model would be wasteful. Could we use traditional algorithms to filter out the obvious spam first, thus giving the AI better quality data to work with?
My instinct was to open up an IDE and start writing.
Simon had a different idea.
Simon isn’t a software engineer. Some time ago, he faced a simple but recurring problem: every morning he wanted a curated digest of news articles relevant to his interests. Writing software wasn't an option, so instead he built the solution as a workflow.
Hearing Simon’s story challenged my default assumption: that because I could solve the problem in code, I should.
The tool is irrelevant
Simon happened to use n8n to solve his issue, and on his recommendation so did I. There are plenty of other workflow platforms available, each with their own strengths and target audience, but that’s missing the point.
The important shift isn’t the software, it’s the mindset.
We have a problem we want technology to solve. As software engineers, we are already familiar with writing technical design documentation, planning data structures and designing system architectures. But sometimes we just need to grab a piece of data and work with it. Sometimes we just need a proof of concept. Sometimes, we’re building a tool that only needs to be used once.
Sometimes we over engineer the solution.
When the solution becomes the default
Having spent some time with n8n, I delivered a first iteration of the sales automation workflow to the team. They were delighted.
Yes, there was feedback, and some tweaks to be made, but we had demonstrated the potential to save time and free the team from some of their more mundane tasks.
I then took on a project for our web team, and once again looked to n8n for the solution. This time, I used it to provide an interface between our current web CMS (where you may be reading this blog from) as part of a migration to a new, more SEO friendly web solution (where we hope you’ll be reading this blog from).
When I looked through the brief for the next iteration of sales tools, I did so through the lens of the workflow, and began working out how I might start the implementation. I’d already set up credentials to integrate with systems such as Slack and Pipedrive which the team use on a regular basis, so I could get straight into the task of delivering a solution. In fact, this very blog was originally intended as a tutorial for such an approach.
Then I spoke to Jonny (we collaborate a lot at Brightec), and he asked a simple question:
“Is a workflow the right tool for this? Couldn’t we use AI to help develop a fully testable express server that could run on a smaller footprint and cut out that extra level of abstraction?”
The workflow had been ideal for proving the concept quickly. But the requirements had changed: testability, maintainability and runtime footprint now mattered more than speed of experimentation.
The issue wasn’t whether AI would be better. It was that I had assumed the answer before defining the problem.
Having substituted my default IDE with a workflow, I had made the tool relevant again.
The tool was never the point
Code is irrelevant.
Workflows are irrelevant.
AI is irrelevant.
They are just tools. Like the saw, plane and chisel on a carpenter’s bench. A skilled craftsperson doesn’t fall in love with one tool, they understand what each one is good at, when to use it, and just as importantly, when not to.
How do we know which tools to use and when?
By cultivating the mindset and skills to look at a problem from multiple angles. By designing a system that solves the problem rather than forcing the solution into a preferred system.
When we do this, we learn to adapt not just to the tools we’re comfortable with, but the ones that challenge us to do our best work.
Annie recently wrote about how faster tools make discovery more important, not less. I think the same is becoming true of engineering judgement. As the cost of turning an idea into working software falls, deciding how we should build it becomes increasingly important.
The difficult question increasingly isn’t “Can we build this?” It’s “What’s the right way to solve this problem?”
The best engineers of the next decade won’t be the ones who know the most tools. They’ll be the ones who know which tool to reach for, and why.
Looking for something else?
Search over 450 blog posts from our team
Want to hear more?
Subscribe to our monthly digest of blogs to stay in the loop and come with us on our journey to make things better!
