In early 2025, computer scientist Andrej Karpathy gave a name to a way many developers were already using AI to write software: "vibe coding." It means describing what you want in plain language and letting AI generate the code. About a year later, at Sequoia's AI Ascent event in 2026, Karpathy said the term was already becoming outdated and described what he saw as the next stage of AI-assisted software development: "agentic engineering."
We sat down with Stanislav Kostenich to unpack what agentic engineering is and how it differs from vibe coding.
Background & experience:
With over 10 years of experience in software development and cloud-native engineering, Stanislav is an AI Engineering specialist currently focused on enterprise AI, LLM infrastructure, AI-assisted software development, and agentic engineering.
What is agentic engineering, and why did it emerge now?
Stanislav: Agentic engineering means guiding AI agents to build software instead of writing all the code yourself. The AI agents can plan, write, test, and sometimes deploy the code. You still review their work and remain responsible for the software's design, quality, compliance and security, and overall control.
Karpathy sees late 2025 as a turning point. Before then, he wrote most of the code himself and used AI to help with the rest. By late 2025, he had switched to letting AI do most of the work and stepping in mainly to correct it. In simple terms, the shift was from "AI helps me code" to "I direct AI agents to code." By this time, coding agents were increasingly capable of working independently for longer, using tools more effectively, and handling more complex tasks.
The numbers back this up. LangChain's 2026 State of Agent Engineering report surveyed over 1,300 engineers and technical leaders. It found that 57% of organisations now run AI agents in production. That's up from 51% the year before. Larger companies are leading the adoption.
The question has changed. It's no longer "Can agents work?" It's "How do we run them reliably at scale?"
How is agentic engineering different from vibe coding?
Stanislav: As Karpathy has explained, vibe coding raises the floor, while agentic engineering raises the ceiling. Vibe coding made software development more accessible. Someone who had never written code could use AI to build a working prototype. That is useful, but it can create problems as projects scale.
If developers stop reviewing the code and accept what AI produces, they can build up technical debt, unclear business logic, and security problems. The software can become harder to maintain.
Agentic engineering keeps the speed of AI while bringing back good engineering practices. The key idea is that delegating work to AI does not mean giving up responsibility. You are still responsible for the software, even if an AI agent wrote the code. “The agent wrote it” is not an excuse for a security problem.
This responsibility makes agentic engineering more suitable for regulated industries such as banking and healthcare, but only with proper governance, quality testing, and human review.
What does an agentic engineering workflow look like in practice?
Stanislav: Instead of writing the code yourself and asking AI for help, you describe what you want built, review the agents' work, and let them do the implementation. In practice, the process has four main steps that repeat:
- Spec design. Writing a detailed specification before prompting, covering the invariants, the interfaces, the constraints, and a clear definition of done. This is deeper than a quick plan; it is the contract the agents work against.
- Delegation. Handing well-scoped tasks to one or more agents, often running in parallel, each responsible for a bounded piece of work.
- Review. Reading the diffs. This is the non-negotiable step vibe coding skips. It is where an engineer catches the plausible-looking mistake — for example, an agent that links Stripe purchases to Google accounts by matching email addresses. The code runs fine, but it's the wrong design, since a user's Stripe email and their Google login email can differ.
- Evaluation. Automated checks and eval loops that verify behaviour before it ships, so the engineer is reviewing a candidate that has already cleared the machine-checkable bar.
The loop runs several agents at once rather than one at a time. A specification is decomposed into bounded tasks that specialised agents take in parallel, with one on the data layer, another on the interface, and a third writing tests, while the engineer integrates and arbitrates.
This is where the current generation of AI coding tools operates. Coding agents that are native to the terminal, including Claude Code, OpenAI's Codex CLI, and Google's Gemini CLI, are used in conjunction with coding assistants based on IDEs such as Cursor and GitHub's Copilot coding agent. All of these tools can plan across a repository, run tests, and iterate over long sessions rather than producing just one code snippet. Although the particular tools may change, the approach to coordinating them is the lasting element.
To make this clearer, think about the example of introducing a payment API. Rather than having a single assistant produce the whole feature, an agentic workflow breaks the task down into implementing the API, making the necessary database migration, writing automated tests, having a security review carried out, performing integration testing, and producing documentation. While several agents carry out these tasks in parallel, the engineer checks the architecture and examines the resulting changes.
The engineer's primary role is no longer writing every line of code. Instead, they orchestrate fallible, stochastic agents while remaining responsible for architecture, quality, and outcomes.
Engineers now need to break work into clean pieces, write instructions agents can't misread, and review fast enough to keep several agents moving at once.
How does it relate to context engineering and harness engineering?
Stanislav: They are the two pillars underneath agentic engineering. Context engineering and harness engineering are the technical disciplines that make agentic work reliable rather than aspirational.
- Context engineering governs what each agent knows at the moment it acts, including the spec, retrieved knowledge, tool outputs, and the history that fits inside its working memory. Get this wrong and even highly capable agents perform poorly.
- Harness engineering builds the control system around the agent, covering tool orchestration, verification loops, guardrails, and observability. It is what keeps a long, autonomous run accountable.
To put it plainly, agentic engineering is the goal. Context engineering is what the agent sees. Harness engineering is the scaffolding that keeps it honest. A team that adopts the agentic mindset without investing in the two disciplines beneath it ends up with exactly the unreliable agents that fail the moment they leave a demo.
Why do so many agent initiatives still struggle to reach production?
Stanislav: Shipping an AI agent is easy, and shipping a reliable one is hard. Most teams underinvest in the hard part. In the LangChain report mentioned above, quality and accuracy were the single largest barrier to putting agents into production, cited by 32% of respondents. Observability has become close to table stakes, implemented by nearly 89% of teams, but formal evaluation lags well behind at around 52%. Many companies run agents in production with little systematic testing. That is a risk dressed up as speed.
In demos, the process is controlled. In production, it isn't. An agent might reach an answer that looks correct while taking a faulty route. For example, it might select the wrong tool, pull the wrong document, or make an invalid inference that happens to cancel itself out. Output-only metrics may miss these failures. They tell you whether the final answer was correct, but not necessarily whether the agent followed the right path to get there. This is why evaluating the execution path matters: it means checking the agent's actions, tool calls, intermediate results, and execution path, not just its output. Without that check, a system can look like it's working well in the logs while failing real users.
Industry analysts share this caution. Gartner predicts that more than 40% of agentic AI projects will be cancelled by the end of 2027, pointing to escalating costs, unclear business value, and inadequate risk controls, problems made worse by widespread hype and "agent-washing," where existing tools are rebranded as agentic without the underlying capability.
Anthropic offers a similar warning in its own guidance on building effective agents: the same autonomy that makes agents powerful also raises costs and increases the risk of compounding errors. Anthropic recommends extensive sandboxed testing and strong guardrails before deploying agents in production.
What makes a great agentic engineer, and where should leaders focus their investments?
Stanislav: Deep technical mastery is more important than ever. If an agent can build almost anything you ask, the real challenge is how well you define your requirements, make architectural decisions, and catch mistakes during reviews. An expert who knows the system can guide many agents and get real results. A less experienced engineer, using the same tools, makes mistakes faster. Over time, the difference between them only gets bigger.
Leaders should focus on building their team's skills, not just buying new tools. Getting agent licenses is simple, but the real value comes from investing in:
- Evaluation and observability, so you can track and measure what agents are really doing
- Guardrails and permission controls, to keep agents working safely within set boundaries
- Reskilling engineers to focus on writing specifications, reviewing work, and managing agents, instead of just coding line by line
Teams that see agentic engineering as a skill to build, rather than a product to purchase, are the ones who successfully use agents in production and keep them running.
What does this mean for the human developer?
Stanislav: Further up the value chain, not out of the picture. The work shifts from writing code to deciding what "correct" means, designing the constraints, and exercising the kind of judgment agents can't supply, namely, architecture, acceptable risk, and accountability. These have always been the most valuable and the hardest parts of engineering to automate.
The engineers who succeed most in this environment aren't the ones writing the most code, or even the ones with access to the best model. They're the ones who invest in clearly specifying, critically reviewing, and designing the systems that keep agents accountable. As writing code becomes increasingly cheap, the rare skills are knowing what to build, specifying it precisely, and recognising the moment the machine is confidently wrong.
Related insights
The breadth of knowledge and understanding that ELEKS has within its walls allows us to leverage that expertise to make superior deliverables for our customers. When you work with ELEKS, you are working with the top 1% of the aptitude and engineering excellence of the whole country.
Right from the start, we really liked ELEKS’ commitment and engagement. They came to us with their best people to try to understand our context, our business idea, and developed the first prototype with us. They were very professional and very customer oriented. I think, without ELEKS it probably would not have been possible to have such a successful product in such a short period of time.
ELEKS has been involved in the development of a number of our consumer-facing websites and mobile applications that allow our customers to easily track their shipments, get the information they need as well as stay in touch with us. We’ve appreciated the level of ELEKS’ expertise, responsiveness and attention to details.
