From coding assistant to engineering partner, what Agentic AI means for software delivery

It is over two years since I last wrote about generative AI in software development. I revisited that blog recently (How will Generative AI assist software development?) and still stand by what I wrote at the time. What has changed is not the direction, but the pace and the depth of what these tools can now do in practice.

Every day there is another technology headline about AI. Is it a bubble about to burst, or something that will reshape how we work and save the planet? AI is no longer something we experiment with on the side. It is becoming part of how we build and deliver software every day. For many leaders I speak to, the question has shifted from whether AI will play a role to how it should be used, and how to stay in control as that role grows.

The conversation has moved from hype to reality

AI dominates the technology headlines. Some of it points to real opportunity, while some of it leans towards extremes. In practice, most organisations are trying to cut through that noise and understand what is actually changing on the ground.

From my experience, the shift is already happening. I have been using GitHub Copilot, Gemini, ChatGPT, and Codex across delivery work, self-learning, and home projects and consuming a lot of podcasts. Like many engineers, I am ideas rich and time poor, so I use these tools to move from concept to outcome much faster than before.

At a basic level, AI still supports familiar tasks. You can generate code snippets, check syntax, or explore an approach. In many ways, this is still web search on steroids. You ask a question and get a structured answer back. However, that answer is not always correct. Hallucinated APIs and commands are still a reality, LLMs are tuned to please the prompter and often return answers that look convincing even when wrong; making review and understanding essential.

Where the real value is emerging

One of the more immediate changes is that programme language proficiency is no longer a barrier in the same way it once was. If I need to call a command in a loop and summarise the output, I no longer start from scratch. I explain the problem to GitHub CoPilot, suggest Python rather than bash, and within seconds I have a working script to review.

That speed is the real shift. These are not new tasks, and any experienced engineer could achieve the same result with time and research. What has changed is how quickly you can move from idea to outcome.

The review step still matters. The engineer needs to understand what the script is doing and why it has been written that way. If something is unclear, you can ask for an explanation to refine the output. The tools accelerate the process, but they do not replace engineering judgement.

The shift to agentic AI

The second and more significant shift is what agentic AI coding assistants can now do. They can handle complex tasks across a full solution. For example, you can ask for a mobile and web application that connects to secure APIs, implements business logic, and stores data in a relational database. You can define OpenAPI specification as the source of (API) truth, build in scrutiny from the start, and target a cloud hyperscaler using Terraform. You can even ask it to consider security analysis and cost optimisation as part of the design process.

This is not theoretical. I have done this using Codex, and the results were strong. It did not take long when you consider the quality of the output, although it initially required many prompts over several days. Having reviewed code for decades, I would say the output would stand alongside that of a senior or Principal Engineer.

In both this and earlier examples, the role of engineer remains central. It takes experience to frame the prompts, guide the approach, and review what is produced. You need to understand what good looks like. When I was not satisfied with an output, I would ask it to update its AGENTS.MD file to record the observation and make sure it did not repeat the issue. That file was for the agent itself. It captured the working instructions and the lessons learned as the work progressed and formed a useful document. It explained the technology stack, set out the commands for running components locally, and pointed to more component-level detail, engineering principles and coding standards to adopt. The README served a different purpose. It was the human-facing guide for the solution. The one thing it could not tell me was “why”. Why are we doing this? What problem are we solving? That is something the engineer driving the prompts still needs to understand.

A changing role for engineers

My last blog talked about developing with an expert buddy by your side. I feel this is shifting to tasking a team of enthusiastic and energetic senior engineers. The problem needs to be broken into manageable parts, with guardrails and expectations set. A sequence of implementations helps to learn quickly and to evolve the overall design. Knowing what good looks like is important. Without that it becomes difficult to steer the tool or assess the quality of the output. These agents are fast and responsive, but they rely on clear instruction and strong oversight.

Increasingly, I am using Codex to help create project briefs then break these into epics and backlogs. There are good frameworks to support this, but you learn a lot from doing it yourself. I would like to report back on this trend in the near future.

Control, governance, and trust

As we become more abstracted from the implementation of a project, will we end up trusting the tools more and not reviewing every file? The analogy I would make is we already rely on third party libraries in modern software stack, and this introduces a similar challenge at a different scale.

We still need good supply chain governance and to understand all our dependencies via Software Bill Of Materials (SBOM) and apply security testing through Static Application Security Testing (SAST) and Modern Dynamic and Static Application Security Testing (DAST) tooling to ensure we understand what we are deploying.

I have had good results asking AI to perform security audits and prioritise findings. I have then reviewed and resolved according to my judgement on implementation order. The cycle is repeated until a clean security health check is achieved. What would have taken weeks can now be done in hours, but the final judgement still sits with the engineer.

The wider implications

There are also broader considerations that go beyond the engineering teams. The main areas that stand out to me are environmental, economic impact and sovereign dependencies.

These tools increase demand on data centres by driving up the cost of electricity and water in impacted geographies. This causes the world to need to generate more electricity and creates repercussions associated with this. The demand for processors, memory and storage are pushing up the cost of consumer and enterprise IT components, which will push up prices universally.

There are client challenges regarding data sovereignty, supplier dependencies, ethical and/or security considerations. Do we make our system entirely dependent on one of a few large US-based providers? Has this not already happened with dependencies on Azure, AWS and Google?

There is also the question about the future of software engineering as a profession. Will the job prospects decline or will the unleashed agentic AI productivity improvements for relatively low-costs lead to an abundance of new projects? For example, the same spend remains in the eco-system, but the distribution is rebalanced. I am forever optimistic on this, but it is not certain. What is clear is the nature of Software Engineering will change. Good engineers will be in demand, but poor engineers will be replaced. We should still encourage and nurture those who want to enter engineering careers.

Final thought

To conclude, agentic AI coding assistants continue to need strong engineering input to guide and review output. Agentic AI can be understood as the amplifier. It can amplify good engineering practices but will equally amplify bad ones.

Guidelines will become standardised as will the choice of technology stack. These will be written down. This will be a good thing, a bit like an onboarding pack when starting a new assignment. Even with the use of AI coding assistants, the roles of product management, UX research and design, architecture, end-to-end functional and user testing, delivery and account management will remain.

Used well, AI can significantly improve how we deliver software and how quickly we can move from idea to value. Used without the right controls, it introduces risk just as quickly.

The models cannot think of new things to do – but they can mash up what has been done before and that might be enough. My final thoughts then, the future is bright but will be different.