The Code Isn't The Issue

We are currently living through quite the turbulent time if you are working in tech (apparently)… We have to remember that not every company is at the front of the queue, churning out AI slop left right and centre and causing a huge pile up of PRs for human review! Some folks are probably still half way through a cloud migration project or even rubbing two sticks together on-premise trying to get a VM to start up successfully…

Having worked in this space for over 2 decades now (yes I’m that old!) I have seen my fair share of new tools and ways of working that should have made people like me obsolete. But, alas we are still here. So what’s different with this AI stuff??

I think we are looking at it wrong.

Developers writing code was never the real issue regarding the delivery of fast, secure and functional code. It’s all the processes (and mostly unnecessary ones). We have wrapped around it in the name of Agile or whatever flavour of Agile you subscribe to that month. The current SDLC we all pretend to follow is the problem.

We have become the victims of our own making. We must deliver code as fast as we can, regardless of the consequences and god dammit we will accept the risk of doing so because money…

This is how most companies operate to make that profit, and the fallout of this greedy behaviour is leaving us with poor quality software/apps and crappy customer experiences!

And no one’s really saying it out loud….

However, it certainly isn’t the Developers fault.. We need to address the elephant in most rooms and look at how we are asking the Developers to develop the code against a one line Jira ticket and then all act surprised when the feature takes a hell of a lot longer than planned and then lands in Production unfit for purpose and your operations team don’t even know it exists or have any idea on how to support it!

Now, throwing AI agents at this problem isn’t going to fix anything… All you’re going to get is code written quicker and the pressure to push it to production. At least your reports and charts stay green and investors are momentarily happy…. UNTIL production (insert cloud provider here) goes down or you find yourself at the wrong end of a ransom note :(

The reason most companies aren’t or haven’t experienced this yet really is pure luck… And AI won’t fix that, if anything it’ll probably make it worse without anyone realising until it’s much worse and far too late.

Reading this you may feel that I am anti-AI!! But dear reader I am not at all. I really like my new AI companions. I’m just pointing them at slightly different problems first..

To talk through what they are up to I thought a good old school blog series would be fun. So, if I have your attention and you want to come along for an AI done differently adventure then watch this space.

Topic 1: The Code Isn’t The Issue

AI slop is a term we are all familiar with these days. We have all seen AI generated pictures where folk have extra fingers or two right hands and many other weird examples.. I have to admit though that I don’t agree with this term. AI is a tool and immature tools can and will produce odd outputs. But, the more a tool matures the reasons behind said outputs mostly come from the people feeding it garbage: “garbage in - garbage out”.. And this is where we are finding ourselves now.

An Exec vibe coding apps is a great example. Pasting in data they shouldn’t and hosting it publicly for the world to see. That’s a sideshow. The industrial version is asking Developers to write code quicker. It doesn’t do anyone any favours. We aren’t addressing the one liner “garbage in” problem at all.

How do we stop “garbage in” in an AI landscape?…. Is it poorly defined requirements? Feature requests for the insane? Jira tickets with no acceptance? No definition of done for your tasks? A lack of testing or testing as a vibe? the list goes on and on… writing your code quicker will never fix these issues!

Imagine how great it would be if we could give our Developers clear goals and a clear idea of when something’s done! They would have the confidence to ship to production and own it, or ship to production and be confident in the fact that the operations team can own and support it, without calling anyone at 2am for help…

This is far more feasible than churning out so much code that no one can ever review it! Or the scarier path, where no one ever reviews it and it’s shipped to production and we hope for the best.

How do you do this you ask?

We need to slow the commitment and take a moment. We need to stop eating up the developers capacity with work that’s not earned the right to eat up said capacity.

1. Discover
2. Design
3. Technical / Security Design
4. Plan & Slice

Team estimates / work is sequenced

5. Build
6. Verify
7. Secure
8. Release
9. Operate
10. Support & Learn

Btw this is not good old waterfall as that freezes a programme and your builds for much longer or completely. This is per slice: consumable chunks of work. While the team build slice N, the next slice is already in step 1 (Discover).

Steps 1-3 are how the slice earns capacity. Product Owner on the problem. Architecture (including security architecture) and a Tech Lead, if you have one, consulted so you don’t invent a runtime and dump it on the team on Monday. That consultation is not the sprint.

4 is Plan & Slice. That’s the first time it consumes team time: sequence, estimates, who does what. Developers are in the room here to estimate work they will actually do. They are not building yet. Once 4 is done, the work is assigned. 5 is Build.

And here is where the problem lies at present: we are assigning that work without a clear Definition of Ready (DoR) (or a DoR on a wiki from 2019). Throw that away and start again: What is the Job, What the job isn’t, an acceptance someone can fail, known vs unknown, kill criteria and finally who supports this at 2am and how?

But, here we are instead we have some code, and we need to get this in to production ASAP and then move on to the next piece of work before anyone can ask who is supposed to operate this…

You’d be forgiven for nodding away here and thinking ‘yes we can forget about this and move on with our lives because we totally CI/CD bro!’

But, outside of your pipeline which mostly is again a nice thought to consider it robust and popping out a fit for purpose functional service in production who is going to support and operate this new spangly piece of AI code in the wild? That’s right this is someone else’s problem! So we should simply go back to steps 1-3, skip them, and keep making work to appease your shareholder overlords…

So this is where we want AI on Steps 1-3, not because Developers should never use it, but pointing AI at Build when you have a one liner Jira ticket is how you industrialise garbage. (4 is the capacity conversation. Don’t outsource that to a model so you can pretend the team had room.)

If we can confidently replace 1-3 with a new model where we draft a brief, flag contradictions, ask the 5 privacy questions, sketch cost against known units of work and list unknowns. A human still has to accept the risk. Unknown is allowed for sure but you have an output that deserves a developers capacity and we are utilising them efficiently and not asking them to simply review some AI “slop”

If we do this thoroughly we do not slow down delivery we simply stop spending our sprints on work that was never ready. Developers get something to ingest, review and stand behind. Then your next steps 5-8 have something concrete to verify, scan and release against. Still with a human in the loop.

This is where AI should be working first. The typing was never the bottleneck.