Software Development 2.0

Extended from original post on LinkedIn.

I’ve been using an AI agent to build an AI agent that can build AI agents for me.

I’m also writing this post while the agent works.
This is becoming standard procedure of the Software Development 2.0 methodology.
If you or your company develop software or tools and you’re not working towards it, then you’re likely to start falling behind quite soon.

I’m one of those people who say: “you want something well done, you gotta do it yourself.”.
As such I’m always skeptical about promises of magical software development solutions that can allow to write software without writing software.
That’s where the ball hits the post ⚽🥅.

Sounds great for prototyping - but why would you not want to write software?
In a Software 2.0 era, the definition of “writing software” is going through a change itself.
But software writing has taken many forms - from punch cards, to assembly coding, to high-level and OO languages - what and how we code has changed drastically over time.
We’re still writing software - and we should - recently we just got supercharged IDEs that go well beyond autocomplete or automatic code formatting and refactoring.
And by the way, we still need all of those too.

Current teams and engineers face two main challenges:\

• First challenge aims more at product owners and project managers.

  It is now feasible to prototype faster, and to develop functional placeholders for components that will be refined in the future.
  This may affect whole Agile workflows where you don’t start with the skate but actually start with the car, except the wheels are made of fragile paper so it’s not production ready.
  The huge advantage of it is that we start defining and applying the integration interfaces right from the start, and thus can be better prepared for scale and real world adoption.
  Still, don’t mistake fancy prototypes for production-ready products.

• Second one, for engineers, is more practical.

  We’ve all been learning that coding LLMs work better with smaller, focused and well specified tasks.
  We also know how much they can mess up the code in a single iteration and need to ensure better versioning practices.
  That’s something that needs some focus.
  There’s also reorganising your AI-generated code into clean commits so your PR isn’t immensely huge and unreadable, so that your team can actually work with you.
  Finally, what I find is that writing specs documents to be fed into the context tends to work better than just elaborating on the prompt.

Academic institutions and coding academies need to adapt to these new methods as they train new junior engineers asap. As far as I know that also requires more attention.

Companies may need to bring in people with this type of vision to help them adapt their workflow and methods too. AI won’t replace their engineers - they will just be less capable and slower without it.