AI agents should be treated like junior engineers embedded in software development processes, with humans defining requirements and reviewing their work.
2
Enterprise coding agents need explicit context, system contracts, access controls, version control, and evaluation examples before they can work safely on large codebases.
3
Teams should start with narrow agent tasks, observe failure patterns, and expand the agent's scope through repeated improvement.
Summary
Kiriti Badam describes co-engineering as a way to use coding agents in enterprise software development. He compares agents with junior engineers who need clear requirements, relevant context, supervision, and feedback. Greenfield applications can often be built quickly with agents, but legacy repositories add system history, deployment rules, security constraints, and performance requirements. Badam recommends files such as agents.md and spec.md for documenting conventions and system contracts, while warning against flooding an agent with files, tools, or logs. He also applies the same ideas to debugging and incident response, where agents need summarized telemetry, runbooks, and postmortems. His advice is incremental: define narrow tasks, add guardrails, evaluate results against real examples, and keep humans responsible for intent and approvals. He expects models to handle longer tasks over time, but says teams need this groundwork before giving agents more control.
AI agents should be treated like junior engineers inside existing processes
Badam's main mental model is that AI agents will work as junior engineers embedded in planning, coding, testing, deployment, debugging, and review. People must define what the agent is allowed to do and what information it needs. He reduces the operating principles to making agents observable, making them accountable, and keeping an improvement loop. This matters especially in enterprise codebases, where agents must account for legacy decisions, security rules, compliance requirements, performance, and stability. Humans remain responsible for the intention behind code changes, while agents take on increasingly complex implementation work.
Enterprise agents need context outside the code itself
Badam says agent work depends on high-signal context because language models do not retain state between API calls. Teams should document decisions that are not visible in functions or docstrings. An agents.md file can contain repository relationships, style rules, directory conventions, and other instructions. A spec.md file can describe system contracts and behavior that must remain consistent during refactoring. For a multi-repository system, the contract can explain how the repositories connect, where the front end and back end live, and how deployment works. Simple text documentation is enough to start.
Too much context and too many tools make agents less reliable
Badam warns against dumping every file in a large directory into an agent's context or connecting dozens of MCP servers without a focused purpose. He recommends explicit instructions about the task, the permitted actions, and the tools the agent may use. Compacting or clearing old context matters when moving between problems. Subagents can handle bounded work and report back to the main agent. In operations, the same problem appears when a log query returns thousands of records, so tools should return summaries rather than entire time series or raw log lists.
Safety requires permissions, approvals, and recoverable changes
Coding agents should operate with allow lists or deny lists, explicit user approvals, and version control. Badam mentions cases where an agent deleted a file while trying to make tests pass, which is why teams need a way to recover work. He gives a similar warning for operational agents: do not give an agent write access to a production database and let it run freely. Start in a dry sandbox, grant the least privilege needed, and increase access only after observing how the agent behaves.
Small evaluation sets can measure whether an agent fits a codebase
Teams do not need an enormous evaluation suite to compare coding agents, according to Badam. They can collect a small set of real examples, such as code review changes containing known bugs. The evaluation can test whether an agent finds the bugs, follows local style, follows instructions, runs CI checks, and runs pre-commit checks. Similar examples can test code writing. The evaluation should reflect what the company considers a good result, rather than relying only on a generic model benchmark.
Documentation quality becomes a requirement for agent work
Badam argues that traditional engineering practices become mandatory when agents work on a codebase. Clear documentation, meaningful variable names, and recorded architecture decisions give agents information that the code alone may not contain. This also applies to debugging and incident response. Agents need access to logs, metrics, traces, runbooks, and postmortems, preferably through tools that return focused summaries. Incident hygiene can include indexing these documents in a vector store so an agent can retrieve relevant context during preliminary analysis.
Badam does not present agent adoption as a one-shot change. Teams should watch failure patterns, identify missing context, and update the workflow. He recommends asking an agent what could be improved in the current system, creating a plan, and then implementing a limited change instead of asking for a complete refactor. The same approach applies across coding, reviews, debugging, and operations. As models improve at tool use and longer tasks, this groundwork can let them take on larger features while people continue to define intent and review the result.
