Agentic Engineering I: A non-technical guide to working with coding agents

By Julian von der Goltz

If you're a (project) manager or product owner, you might be wondering whether you should try coding agents yourself, or encourage your technical teams to adopt them. You might also be asking whether these tools will replace developers, or whether they are better understood as a complement to their work. What can and should the AI do? And what should remain firmly in human hands?

The following article explains what coding agents can and cannot do, where they can speed up technical work, and what changes in the way teams plan, build, review, and stay accountable.

In early 2025, Anthropic released Claude Code – a terminal-based assistant that can write code and execute commands on your computer autonomously. Until then, AI in software engineering was mostly limited to copy-pasting snippets from chat interfaces or using simple autocomplete tools inside IDEs.

Claude Code’s rollout marked a turning point with companies like OpenAI and Google quickly following with their own coding agents. Usage and adoption accelerated. As with any emerging technology, early experiences and quality were often poor. Terms like “vibe coding” – blindly accepting AI-generated code with reviewing or understanding it – and “AI slop” – low quality, error-prone, or even insecure output that looks good on the surface – quickly entered the conversation. However, the technology has since evolved at a rapid pace.

At KickstartAI, we’ve been experimenting with coding agents for quite some time. We believe that we are now at a point where they are indeed useful for serious software engineering, data science, and machine learning work. In fact, given the current pace of development, teams not using coding agents may risk falling behind.

This is the first article in a series about Agentic Engineering, where we’re sharing our learnings and best practices to help teams use coding agents productively without compromising quality or  security. It is a non-technical guide to working with coding agents for people in a management or business role leading technical teams. 

The second article in the series (to be published soon) contains actionable tips for engineers, researchers, and data scientists who want to get the most out of their coding agent in practice.

How a coding agent works

A very simplified technical definition of an agent is that it is an LLM (large language model) that has access to certain tools (search files, read files, write files, execute commands) and runs in a loop.

The LLM can choose which action to do next, based on the history of the conversation. It can decide to use a tool to modify files, run code, search the web, etc. Anything that can be done on a computer is within the possibilities.

It can also decide to respond to the user, which pauses the loop and allows the user to give a follow-up instruction.

This is different from the original chat LLMs like ChatGPT that only give a single response to a question of the user, then wait until the user submits another question, resulting in a conversation like back-and-forth. 

When an LLM runs in a loop with tools, it can perform multiple actions after each other, get feedback by checking the outcomes of those actions, and autonomously continue until a task is done. This enables much longer time-horizon tasks, like actually building a software application end-to-end from start to finish. The LLM does not even have to write perfect code at the first try, the feedback loop serves as a correction mechanism that makes LLMs more reliable.

Theoretically, the LLM could go on like this forever, but in practice they check in with the user after they perform some tasks. The length and complexity of the tasks depend on the prompting, the agent software that wraps the LLM and provides tools and feedback (often called the "scaffold" or "harness"), and the capabilities of the model.

An organization called Model Evaluation & Threat Research (METR) tracks the current time horizons of the latest LLMs. They currently estimate that the best model (Anthropic Claude Opus 4.6, as of March 2026) can perform tasks of about 10 hours with a 50% success rate or one hour with 80% success rate without any human intervention.

These time horizons are rapidly increasing, so even more complex tasks will be possible in the future without any human intervention.

Surprisingly, the amount of information that the coding agents have about your project is very minimal when they start off a session. There is no RAG (the AI doesn't receive any related information from your codebase for every user question), no knowledge base; it is really just an LLM with tools. The philosophy is that the LLM is able to decide for itself which files to read or information to load and pull into context given the task at hand.

What changes about your team’s work

A coding agent doesn’t replace a developer. It changes what they spend their time on. Before the agent era, a developer would spend most of their day writing code, looking up documentation, and debugging. With an agent, the focus shifts. They spend less time typing and debugging code and more time reviewing it, steering the agent in the right direction, and testing whether the result actually does what it should.

Think of it like the difference between a chef who cooks every dish themselves and a head chef who directs a kitchen. The head chef still needs to know how to cook, still tastes everything, and still decides what goes on the plate. They just don’t chop every onion themselves anymore.

This means the skill set doesn’t go away, but it changes. Your developers still need to understand the code, the architecture, and the product. If anything, they need to understand it better, because they’re now responsible for reviewing output; they didn’t write line by line on their own.

What to expect

Code gets written faster with agents. But faster code doesn't automatically mean a faster product rollout. Quality control, testing, and review still take the same time and, in fact, become more important. It is key to understand that while the agent can produce large amounts of code very quickly, without proper review, that code can introduce bugs, security issues, or just bad design decisions that are expensive to fix at a later stage.

The more technical sections below lay out some tips on how you can mitigate these problems and prevent a flood of AI-generated code that slows you down.

Here’s a good way to think about it: the agent compresses the time between "we decided to build this" and "we have something that works." But it doesn't compress the time needed between "is this implementation correct?" and "does this actually solve the user’s problem?" Those questions still require human judgment.

In practice,  if your team is shipping faster while maintaining quality and reliability, the agents are working. However, if output increases while bugs rise and team members don’t seem to  fully understand how or why systems behave as they do, this is a sign that the team is over-relying on the agent and under-investing in review. It can also be a sign that the agent isn’t being directed in a way that leads to a productive outcome.

The human stays accountable

"The AI wrote it" isn’t a valid justification for code quality, errors or security issues. The developer who used the agent is responsible for the output, the same way a senior engineer is responsible for code written by a junior on their team. They should be able to explain any line of code in their project and defend the decisions behind it.

This is something to be clear about as an organization. Coding agents are a tool, and like any tool, the person using it is accountable for the result.

Scope creep

Because agents now can build features  so quickly, there’s  a temptation to keep expanding scope. “Does the feature work? Great –  but what if it also did this other thing? And while we’re at it, let’s add this small feature too.” Each addition takes only a few minutes, so it feels free, it doesn’t cost anything. In reality, it does cost something. And not only the cost of the AI tokens. Instead of spending 15 minutes on a single, focused  change, you may spend an hour implementing multiple unrelated ones . As a result, it would take you longer to ship something with AI compared than if you had worked on a single change manually.

Every feature you add must still be maintained, tested, and explained to users. The speed of the agent makes it easy to overlook this. The result is often a product that does many things, but few of them are properly finished or validated. Agents will happily continue building whatever they’re asked to build. They don’t enforce scope or push back on unnecessary complexity. That responsibility remains with the project manager and the team. 

The discipline itself hasn’t changed: decide what to build, build it, ship it, and validate it with real users. What has changed is that agents lower the perceived cost of adding “just one more thing,” making it harder to stick to that approach.

How project management changes

If your team follows an agile process with two-week sprints, daily standups, refinements, and sprint planning, much of that structure still applies. However, some elements begin to feel less effective, suggesting that you need to make adjustments.

For example, during a recent sprint refinement in a partner project, we spent considerable time discussing whether to make a change in a third-party codebase ourselves to fix a bug or wait for their team to come up with a solution. Traditionally, these decisions require careful scoping and alignment. In this case, however, a coding agent could have implemented and tested a fix in less time than it took to reach a decision.

In another instance, we were discussing in deep technical detail how to implement a certain non-standard machine learning architecture. Previously, we would create a multi-day “investigation” or “research” ticket to determine the approach. Based on the outcome, we would refine the implementation ticket before starting work.

This investigation can now be done with a coding agent in less than half an hour, producing a very detailed specification that can be directly used for implementation. In many cases, the agent can even execute that plan immediately!

But that kind of speed makes it challenging to do real (human) team work. People may disagree with the approach, assumptions may be wrong, or the scope may grow too large (as tends to happen with AI agents). Our approach now is to allow some time for the team to discuss a plan first , ensure everybody is on the same page, and only then begin execution.

This means that timeline estimation changes too. When an agent can produce a working implementation in hours instead of days, the traditional story point exercise starts to feel disconnected from reality. The bottleneck shifts from writing code to defining the problem, reviewing the solution, testing it, and ensuring it actually solves the right problem. It may make sense to bring an agent into refinement to help generate detailed specifications, based on which developers can estimate more accurately. This could significantly improve planning and reduce uncertainty, but unfortunately I am currently not aware of a tool that could do this in a seamless manner.

A similar shift also shows up in smaller tasks that don’t require elaborate planning. For example, when a user reports a bug and it’s a low-effort fix, putting it through the full sprint cycle – triage, prioritization, assignment, planning, waiting for the next sprint, implementation, review – can create more overhead than the fix itself. If an agent can resolve it in minutes, why wait two weeks? This suggests a two-track approach: the sprint handles larger, strategic work, while a separate fast lane handles small issues that can be addressed immediately. The project manager or product owner still decides what gets fixed, but the timing can shift from “next sprint” to “right now.”

How does your (team's) day look like now?

Let me describe a typical day in a previous project: The day starts with a team standup. Everyone shares what they are working on, how it is going, if the team is on track to meet the sprint goal, if there are any blockers, etc. After that, we typically resolve blockers – for example by reviewing each other’s code. Then everyone continues with their work:programming, debugging, and so on.  Throughout the day, there are usually a few meetings as well.

A day in the coding agent era could perhaps look like this: You start your day and check in with the coding agents that worked during the night. You review and test their output. If everything looks good, you ship the code. If there is something wrong, you identify follow-up tasks. Smaller tasks are handed back to the agents to work on, while bigger tasks are taken to the team for discussion. The middle of the day you spend aligning plans, writing specifications, scoping, talking to users or stakeholders. In short, all the work that requires human judgement. At the end of the day, you take those plans and kick off some new agent sessions that run through the night.

Team composition

Something we're already seeing at KickstartAI is that the boundary between technical and non-technical team members is getting blurry. A product manager who can spin up an agent and say "add this field to the form" or "pull these numbers from the database into a report" doesn't need to write a ticket and wait for a developer to pick it up. They're not becoming a developer, but they're fully able to do things that previously required one.

This changes what an ideal team looks like. If non-technical people can handle simple technical tasks and technical people can produce more output per person, you might need fewer people per team but more broadly skilled individuals. The person who is deeply skilled in one area but can also navigate adjacent areas becomes more valuable than the pure specialist who only writes backend code or only manages tickets.

The old distinction of "technical" and "non-technical" starts to look more like a spectrum. Everyone on the team can interact with agents at some level, and the differences are in degree rather than kind. What you want is a team where people can cover more ground individually, with fewer handoffs between roles.

While the ideal team structure isn’t yet fully defined, it’s clear that adapting is necessary to remain competitive: smaller teams, broader skill sets, and reduced reliance on others to make progress.

Security and trust

A common concern, especially for organizations dealing with sensitive data, is whether you can trust AI-generated code with user information, payment flows, or access control. The short answer is,  you can, as long as a human reviews it.

The agent doesn't have any malicious intent, but it also doesn't have any particular awareness of what is sensitive and what is not. It might log something it shouldn't, expose an internal endpoint, or skip input validation because it was focused on getting the feature to work. It might also be very eager to perform irreversible commands like deleting databases if it was prompted to perform, for example, a dependency upgrade and told to succeed no matter what.

These are the same mistakes a human developer can make, but the speed of agents increases the volume of code to review and the potential for such issues. 

Here are two main ways to mitigate this risk:

The first one is to incorporate security in your review process. You can explicitly instruct the agent  to check for security vulnerabilities, and you can introduce a dedicated  security review step, either automated or manual. If your team already conducts  security-conscious code reviews, good news! If your team doesn't, now is a good time to start, regardless of whether agents are involved.

The second method  is to be very deliberate about what you grant agents access to. Providing full read-write access to a production database with sensitive information, for example, is probably not a good idea. More limited access – such as read-only access to anonymized logs – on the other hand can be extremely helpful for debugging, performance analysis, and product improvement, without introducing unnecessary risk.

There are many more things to consider about agents and security. New products and services are being developed specifically for this purpose. The landscape is changing rapidly but it is important to not jump on the latest hype, but to stay critical and see what kind of best practices stick.

Should I try a coding agent?

Now that even people without any technical experience can build sophisticated apps with AI, you might be tempted to try it out. But keep in mind that coding agents are tools for software developers. They operate inside a developer's environment alongside an IDE, version control systems such as Git, package managers, and other technical tooling. This makes them hard to use for someone without a technical background. There are other products that are more suitable for non-technical people to create apps with AI, including Replit or Lovable. These products take care of the scaffolding around software engineering and you can usually get started right away.

That said, the same agent concept is now being applied to general, non-technical use cases. Products like Claude Cowork, OpenAI's Codex desktop app, and Microsoft Copilot Cowork are being released for tasks like working with spreadsheets, filling in forms, looking up information on websites or in company records. These tools don't require you to know how to code. They operate on the same principle (an AI software with access to tools, running in a loop), but the tools are your everyday computer applications instead of a code editor.

These general-purpose agents are not as mature as coding agents yet. Coding agents have had about a year of rapid iteration and are now genuinely useful. Their general-purpose equivalents are earlier in that curve. But given the pace developments are moving at, that gap can close quickly.

Conclusion

Coding agents are not going to replace your developers, but they are going to change how your team works. The developers who figure out how to work with agents will get more done. The teams that adapt their processes will move faster. The organizations that take this seriously now will have an advantage over those that wait.

At the same time, it is important to remain actively involved. Avoid over-automating allowing security risks, technical debt, or AI fatigue to build up unchecked. Set clear expectations about accountability. Watch for scope creep. Rethink your project management process where it no longer fits. And pay attention to how the roles on your team are shifting.

The pace of technology is speeding up. Six months from now, maybe everything I wrote here will be outdated. But the fundamentals won't: humans decide what to build, humans are accountable for the result, and the tools just help us get there faster.