Do we need developers anymore?
i used microsoft designer, to make the article header

Do we need developers anymore?

It's been maybe 8 weeks now of developing (pair developing) with Cursor AI as a co-developer. I am trying to follow the patterns that I detailed in last months article, working as if it was a series of agile styled sprints, with a sprint plan, estimates, and roles.

This is probably going to be a nerd article of the newsletter, but hang in there Project managers, Product owners.. at the very end, or maybe in the middle I will help you out.

My role is a hybrid technical project manager.

The application is a a full stack application, with a react front end (server side and client side) and a fastapi backend, most of my work with cursor has been in the ui (next.js) server and client application.

This is interesting because the react native 'demos' of 'wow I don't need a developer' you see on LinkedIn, and X (toXic as I like to refer to it), typically end up generating this sort of code / stack of code.

So the question, No Developer's right?

I am not that technical..

Disclaimer... I always say this to project teams, it turns out that its a bit of a white lie, so if you really are a non technical project owner, dreaming of a developer free future, where you can from your sun lounger as a digital nomad throw a dictated diatribe of features for your 'awesome app (tm)',

spoiler alert: You are out of luck, come back later (tm)

How's it going then?

I don't have a lead developer, but I have worked with them extensively. Code production rate and quality is still quite far off, especially without my oversight. This manifests itself in a few specific patterns

Solving the same thing differently... every time...

Code is a selection of design decisions and patterns. How to access the database, where to store the code, what to name variables. There are often multiple ways to code a solution. effective development teams invest time in standards and patterns, they build efficiency through reuse (DRY principles). Cursor cares not for that.

It likes to solve a problem, however it fancies to solve the problem, often effectively refactoring a whole piece of code in isolation so that it no longer works with the rest of the repo by choosing a new pattern on the next edit. Humans are lazy coders, AI are lazy code readers.

Me: I want you to read the reference code exactly and use that pattern to implement this similar thing
...
AI: 'Ok, i will read the code'
AI: <code... some entirely random code nothing like the reference>
...
Me: thats not the reference code
AI 'I apologize for not following the reference code..
AI: <code some more entirely not reference code....         

It's ok we can solve that using rules files... I have 30, neatly named, in markdown, with the defined descriptions, and 'globs'. I even sometimes add them into the context by hand. It sometimes reads them, sometimes it scans bits of them, sometimes it frankly cant be bothered and then just apologises for not reading it, and asks which file (the one i just gave it) it should look at... which it then ignores...

So the takeaway, everyone is excited about how complex it can solve things, or the size of its context, which are all really good...but.. can we solve 'adherence to standards', and just being a better developer citizen, to be a teammate as opposed to a code maverick. Across my career running software development, the very best code and developers are team players, standard writers and followers

Versions, time and updates are not your friend

The code cut off for the agents is almost a year ago (as of time of writing), despite the promises for 'content updates'. A lot of code libraries have moved a long way in a year.

Its ok you can have a versions rule file the AI can read to know when to websearch or look up docs....

(see above...)

This is a real catch out particularly as some of the changes to the underlying libraries have enjoyed major version updates, which are pattern and breaking changes. When the AI encounters these, its solution will be to downgrade to the version it knows about to make the code work. On one occasion, it solved the error by just deleting the code, which to be fair, did make the error message stop...

Automated testing, can be great or terrible

Automated testing, especially unit tests should be part of the code building process, they add safety and reliability... They are not popular to code, I don't like coding them, I don't like writing them, they are drudgery. Which should be ideal candidate for the AI, it loves drudgery. Think of all the books it read to become an AI, all that fanfiction about game of thrones...

Keep an eye on coverage, brittle natured and obsessive tests. Product Owners you need to make the call on the level of test you want, and what you care about. this can be a real warren of minor tests to get that 1 line of code to have a test... when well written code, maybe didn't need that, 80% is considered a good coverage. Where I have chosen to get coverage i have often got way above that on first pass, and then the last two tests I spent two hours getting to work, when i should have asked..

What does this test do,cover, will it make a meaningful difference to code quality and progress, is it actually a unit test trying to be an implementation test

All in all, I do keep adding them, but when I get to a test that i just can't get to work, i kill off the activity and put fixing the test into the backlog, based on its value.


Managing the sprints and backlogs

I have got to an 3 out of 10, level of satisfaction for managing the backlog and sprints. This is on my 'thinking about when not at a screen' backlog of ideas.

Making the plan, following the plan, updating estimates are all sort of working. I am being rigorous at keeping data for future, but the capricious overzealous edit and forgetful nature of some of the AI Agents attempt at updating has definitely lost data.

This workflow of Product owner, sprint planning, data recording is absolutely going to get more automation, probably via actions integration.

I run the sprint like a sprint, planning, execution, measure, retrospectives. This is working for me as a learning pattern, Its not yet a workflow thats stress and error free. I also try to be rigorous on scope creep in a sprint, and casting new ideas (from either me or the AI, into the features backlog) to not disrupt the sprint.

No, I didn't write the actual future feature documents - I only updated the plan. Let me create the proper future feature documents.

(see above)

I have a 'how to end a sprint guide', 'how to write a plan' and some others designed to help with this process. My current versions are very targeted to making the work easier for the AI, so have a format thats not me friendly. I am reversing that and combining the two, basing it around a more Markdown / yaml (.mdc) format as opposed to JSON. This is just to make the cognitive load on me easier.

I am putting AI in the loop, as opposed to Human in the loop

I am reversing the AI / Human convenience to make it easier for me. This reminds me of the lesson 'legacy versus heritage systems'. The name defines the attitude and the value.

The data says, estimate quality is still wild (nothing new there!) though the overall confidence trend on the predictions is getting better. Tends to overestimate by adding in a load of practices that are not in our working methods (despite the guidance) and underestimate the impact of falling off patterns. When we do hit a reuse pattern, we smash the timelines... but anything involving modern apis, latest versions or pattern choices are still variable.

Project Managers, I am working on this, it annoys me too, pesky devs! I think this is more around fixing the better agentic flows throughout the software process and collecting the data. Data makes for insight

Everyone is now talking about 'Agentic AI'

<rant enabled> ......... I cannot even bring myself to get enraged about this </rant>

We have got this agent, it's a chat gpt that writes to a slack channel

Overheard at an industry webinar...

We are certainly at a bit of a moment where we are not all 100% sure what 'agentic even means'. I have a view, message me for it. So does Andrew Ng, and the CEO of Anthropic, and 2000 linkedIn influencers on AI (who should go back to TikTok dancing videos like last year).

Have a look at some of the back issues of this newsletter maybe here..

https://www.garudax.id/pulse/implementing-ai-agents-paul-bratcher-xmene/?trackingId=rvTrSipjSPieJR9G4e7CzQ%3D%3D

We are working on our (unfold:ai) view of what are agents, and we are building out some interesting use cases. We are as you can see from this article 'eating our own food' and trying to make use of the technology, so we can safely lead you to outcomes of value.

Rightnow, the constant promises of 'build a 1000 agents in no code that anyone can do for $9.99' a month.. may i also recommend you google '10000 wood working plans'. or 'collect this diorama in 199 monthly parts'.

Creating processes and software that are reliable, easy to use, create good outcomes, is not easy, and therefore anyone selling them for no value, has not done that... it's a tech ponzi scheme.

Apply some common business sense.

So can you get rid of developers...

Bad ones, yes, good ones no.


Great article, Paul. Coding has ALWAYS been 'the easy bit', (for some at least!?) We used to just remember the code (having read 'manuals'), then things like notes/cards (I used old IBM punch cards...), then a set of text files to 'seemlessly' copy and paste, then code generators, and now AI Super Clippy - "It looks like you're writing a form handler? Can I help?" And now AI ... "Write me a form handler to this DB with these fields and with this validation, use logging at key points. Build the TDD as well, ta." Click. Done. The "smart" bit has always been the design ... what the user needs to get done, where the process goes, when it runs, and what it does. That hasn't really ever changed? We've gone from being programmers, analysts, coders, developers, builders etc. to ... what exactly? I guess now we are all "Application Generation Managers"? And we need to be more tightly bound to business process, which is a Good Thing(TM), right? 😁

Great article. I love the last paragraph. It's so true. Creating processes and software that are reliable, easy to use, create good outcomes, is not easy, and therefore anyone selling them for no value, has not done that... it's a tech ponzi scheme.

To view or add a comment, sign in

More articles by Paul Bratcher

Others also viewed

Explore content categories