Agentic Engineering Is Here, and Most Teams Can’t Even Write a Ticket

Automation doesn’t fix unclear work.

Photo by Alex Knight on Unsplash

Agentic engineering is having its moment.

Agents that can plan, call tools, write code, open PRs, run workflows. The demos look clean. The roadmaps look even cleaner. You can feel the budget lines moving.

Some of it holds up in real life. Especially on the work that drains time without producing much learning. The mechanical stuff that blocks the actual thinking.

But there’s a gap between what teams are buying and what they can operate day to day.

Most teams can’t even write a ticket.

Not a “we should improve observability” bucket. I mean a ticket that a stranger could pick up, execute, and ship without needing three meetings and a side-channel history lesson.

---

Tickets are where intent either survives or dies

People treat tickets like admin. That choice has consequences.

A ticket is often the only durable record of what the team believed at the start. What problem they were trying to solve. What constraints mattered. What risks were known. What “done” was supposed to look like before the code started pulling the conversation off track.

When the ticket is thin, the work turns into interpretation. Review becomes archaeology. QA turns into a debate about meaning. On-call gets dragged into product decisions because nobody wrote down the decision earlier.

You’ve seen the patterns:

A title that reads like a Slack ping. “Login issue??”

A description that starts with “users are mad” and ends with “should be easy.”

A screenshot of a chart with no timeframe and no link.

Acceptance criteria that say “works as expected.”

Then someone ships a change that matches the words on the ticket and misses the real need. Everyone agrees the ticket was unclear. Next week, same movie, different service.

Now add an agent.

---

Agents amplify whatever your team already does

An agent will happily write code inside a fog. It won’t complain. It won’t get tired. It won’t feel awkward about missing context. It will do the best it can with what it has.

Humans usually patch the fog with social behavior. They DM the PM. They ask the staff engineer what the system actually does. They remember the incident from last year. They know which dashboards lie. They know which service is a landmine. None of that shows up in a ticket.

So the agent asks questions. And in a team that already avoids writing things down, those questions don’t resolve the fog. They create a new loop. Someone has to answer in a comment thread that nobody will reread three months later. Or the agent gets a half-answer and fills in the rest.

That “fill in the rest” part is where things get weird, fast.

Because the system you’re giving it was already full of gaps, and now there’s something that can move forward without the social friction that normally slows humans down.

---

The moment it turns

Early rollout goes fine. You start with low-stakes chores. Dependency bumps. Test scaffolding. Log parsing. Small scripts that nobody wants to own. The team feels the relief.

Then somebody says, “Can it take a whole feature?”

That’s when the environment matters more than the model.

Tickets are vague. API boundaries are soft. Ownership means “whoever touched it last.” Staging data doesn’t resemble production. Monitoring exists, but nobody trusts it. Decisions get deferred because everyone is busy, and deferred decisions don’t disappear and just come back later as incidents.

In that environment, the agent behaves like a team under deadline pressure. It changes what it can reach. It patches around what it can’t. It chases green checks because green checks are what your process rewards.

For a little while, that looks like acceleration.

Then you start paying for it.

Regressions that don’t map cleanly to a single change. PRs that are hard to review because the diff looks plausible but the intent is missing. A backlog full of “follow-up” tasks that never get followed up. People stop trusting automation, yet keep using it because deadlines don’t care about trust.

Leadership eventually asks for “better prompts.” The team learns the prompts weren’t the missing piece. The missing piece was a working way to describe the work.

---

The hard part that makes the rest possible

If you want agents to help, you need a sharper handoff from intent to execution.

Write tickets like they’ll be executed by someone without access to your Slack threads, your assumptions, or your institutional memory.

State the goal in one sentence.

Define “done” using things you can verify. Something you can measure, observe, or test.

Link the dashboards. Include time windows. Include the query, not a screenshot.

Call out edge cases you already know exist. Mention the failure modes you’re trying to avoid.

Name an owner. Even if ownership is messy. Pick someone who will make decisions, not just approve PRs.

Be explicit about what you’re not doing. That’s where most projects leak.

This is the work teams skip because it feels slow. But it’s the part that keeps the system legible, which is what both humans and agents need.

---

Closing reflection

Agentic engineering will keep getting better. That’s not the interesting question.

The interesting question is what kind of org you actually have underneath the tooling. Some teams have a real execution layer: clear tickets, real acceptance criteria, ownership that means something, and a habit of writing down decisions. Those teams will get value quickly.

For everyone else, agents mostly turn hidden ambiguity into visible output. That output looks impressive right up until you have to maintain it, explain it, or defend it during an incident.

If your tickets are placeholders for conversations that never got captured, the agent will run on placeholders too. And you’ll end up spending your time doing the same thing you always did: trying to reconstruct intent after the fact, except now there’s more code on the ground.

---