From prompt to Kubernetes in an evening: what AI-assisted development really looks like
- David Turner
- Aug 4
- 5 min read
Updated: Aug 10
The nature of AI-assisted development
Much rhetoric aimed at leadership teams positions the question about AI and software development as primarily whether it will replace engineers. It's the wrong question. Asking it means missing something more useful.
The better question is what a single engineer can build in an hour, starting from scratch, and what that tells you about how technical work is changing.
Last month I spent one evening testing that directly. The brief to a Claude agent was vague by design: build something using Docker and Kubernetes. No specification or existing codebase. What emerged was a functional three-container application, a live dashboard, and a Kubernetes deployment. It also involved a broken macOS environment, an architecture mismatch that needed three attempts to diagnose, and a shell configuration conflict that would have stopped most tutorials before the first line of code appeared. That last part is the more instructive story.
Why diagnostic speed matters as much as code generation
The AI-in-development pitch is mostly sold as a code generation narrative. The model writes the function, the engineer pastes it into an IDE, you all move on. That's real, but it is not the only thing that's changed.
What has also shifted is diagnostic speed. The three environment failures in that session were each resolved in minutes. A macOS incompatibility, a CPU architecture mismatch, and a shell configuration conflict. Any one of those could have taken an afternoon to unpick six months ago. The pattern recognition is now better, and the ability to hold context across a multi-step debugging process without losing the original objective is fundamentally improved.
This matters more than code generation for a specific reason. The blocking cost in technical work has rarely been writing the code itself. It has been the time in the gap between a known error message and a diagnosis, between understanding what something should do and understanding why it does not. AI assistance compresses those gaps rather than eliminates them; the environment in that session was actively contradicting itself at one point. But enough that the work keeps moving.
What it costs to treat AI as autocomplete
The other shift is what happens before any code is written. The session began with an agentic workflow creating a comprehensive PRD: component breakdown, API endpoint table, database schema, folder structure, technology choices with justifications, security notes, and a delivery plan. Not a token gesture at documentation but a functional one, produced in the same session as the build. That structure shaped everything that followed.
Organisations that treat AI development tools as autocomplete will get autocomplete results. The diagnostic value, the architectural reasoning, the documented decision-making. None of it emerges from pasting suggestions into an IDE without understanding what they mean.
The cost is precision and, over time, dependency. An engineer who collects AI output without following the reasoning behind it learns very little and becomes progressively less capable without the tool. An engineer who follows the reasoning - why Flask and not Django, why PostgreSQL and not SQLite, why vanilla JavaScript and not React - is faster on the next project and makes better decisions on the one after that. These are engineering judgements, not style preferences. Treating them as interchangeable is the error leaders make when they deploy tools without first establishing whether their teams understand the systems those tools are operating on.
What scales with competence
The distinction between a junior and a senior engineer is not typing speed. It is the mental model brought to a problem: which questions to ask before writing anything, which decisions matter and which do not, how to diagnose a failure that is giving contradictory signals. AI tools are developing those capacities faster than most people anticipated. Not uniformly, not without failure, but faster.
In that session, the coding agent wrote itself into several files using the wrong shell command. A Dockerfile ended up with its own creation command as its first line. Architecture detection gave contradictory answers. These are not catastrophic failures. They are the kind of failure a competent human would not make, and they require someone paying attention to catch them.
And that is the real constraint. The value of AI-assisted development scales with the competence of the person using it. An engineer who understands what a container is, what Kubernetes is solving for that Docker Compose does not, and why one database fits a given architecture better than another will get proportionally more out of these tools than someone who does not. The tools raise the ceiling. They do not move the floor.
The session went from a loose brief to a working Kubernetes deployment in one evening. That is a real data point. It is also not magic. It is a capable collaborator that holds context well, reasons about problems with reasonable clarity, and moves fast. It will also write its own creation command into a Dockerfile if you are not watching.
All this means you need to prepare accordingly.
What to do before deploying AI tools to your team
Establish what your engineers actually understand before deploying AI development tools across a team. Not their tool preferences or framework familiarity, but whether they understand the systems they are building. A tool that accelerates competent engineering also accelerates the errors of engineers who do not understand what they are building. The diagnostic value compounds upward for the former and does not exist at all for the latter.
Use the PRD step to start the workflow. The session began with a proper requirements document before a single line of code was written: technology choices with stated reasons, architecture documented before it was built, a phased delivery plan that could be interrogated. That is what separates a session producing a working system from one producing a working file.
Pay attention to what gets explained and what does not. The session gave reasons for every significant choice. Those reasons are transferable. An engineer who has followed them is faster and better-informed on the next project. An engineer who has only collected the output learns nothing and becomes dependent.
Whether AI will replace engineers is not the only question currently being asked. Whether an engineer understands their work well enough to use these tools effectively is the other. It is also, increasingly, the question to which the next five years of technical hiring will turn.
David Turner is the founder of Kói, an independent strategic consultancy advising senior leaders and investors on high-value decisions across technology and adjacent creative fields.
You can reach him at: enquiries@dkoi.design
© Kói Holdings Ltd 2026. All Rights Reserved.
