Beyond agentic engineering
Agentic engineering and what comes next
Examples of agentic engineering + a glimpse of the next stage
2026-04-07
0. Speaker
Have worked as a developer, researcher, data engineer, planner, and more at web portals, game companies, UX agencies, and so on.
Currently working at Corca.
1. Before we begin
❌ “I’ve found the best practice. Humans can just relax now.”
✅ “I’ve found one pretty good approach. What humans need to do seems to have changed a little.”
Things I’ve tried that work, and things I’m thinking about trying next.
2. Code quality
If AI reads and writes the code, does code quality still matter?
How can quality be good even if people don’t write or read it?
Does code quality still matter?
AI imitates humans → code that is good for humans is also good for AI. (For now. But soon: Welcome to the Era of Experience.)
Existing code needs to be good for AI to produce good code. (See: Improving frontend design)
Lower code quality (long code, circular dependencies, high coupling, etc.) means more tokens in an LLM’s context → Context rot.
Good code quality makes review easier, whether the reviewer is human or AI.
How can code quality be good even if people don’t write or read it?
Type checking, test automation, test coverage measurement.
Linters: limits on file length, function length, statement counts in functions, cognitive complexity, and so on.
Enforce dependencies: constrain code to stay within the overall design. (For example, prevent business logic from depending on the UI.)
Duplicate code checks: find and remove structurally identical chunks.
Dead code checks: find and remove unused code and dependencies.
Mutation testing: if randomly changing the code does not break a test, there is a gap in the tests. (Watch the speed, though.)
See: Source code quality in the AI era, Enforcing the quality of AI-generated code (And reduce the likelihood of supply chain attacks: dependency cooldowns, e18e, etc.)
The combination matters
“The devil is in the details.”
A good combination matters. Examples:
- If you check only test coverage without enforcing a test-to-production code ratio, the number of tests grows without limit.
- If you demand the removal of duplication without measuring cognitive complexity, the logic becomes endlessly complicated.
Spend less time watching the terminal
If all I do in the terminal is say “yep,” why am I watching it?
Write a GitHub issue → Claude Code reads it, writes code, and creates a PR → a human reviews and merges.
claude --dangerously-skip-permissions -p "docs/issue.md 파일의 지시를 수행해"
3. Specifications
If we don’t read and write code, what do we read and write? Specifications.
Spec-Driven Development (SDD)
But…
Problem 1. The ambiguity of specifications written in natural language.
“What you write down doesn’t mean exactly what you think it means. And when it does, it doesn’t have the consequences you expected.” —Daniel Jackson, Software Abstractions: Logic, Language, and Analysis
Problem 2. Spec-code drift.
Let’s execute the specifications
Framework for integrated test, created by Ward Cunningham in 2002.
Both problems are mitigated: 1) spec-code drift, 2) the ambiguity of natural language.
specdown
specdown: Writing executable software specifications by putting acceptance tests in Markdown documents.
4. Things I’m thinking about
Developing well with agents seems to work out if we approach it this way. What comes next?
Self-healing, self-growing S/W:
- What if an agent could see the system logs? (See: Defect cost increase)
- What if an agent could see Google Analytics data?
- What if it devised and executed its own promotional strategy?
More software vs. better software.
Design is not a tree.
End
Summary:
- Code quality still matters, and there are ways to manage it reasonably well.
- Good executable specifications connect documentation, tests, and code, reducing spec-code drift.
- Development is only one stage of the entire cycle. Let’s think about software that improves and grows on its own.
- Design is not a tree.
Thank you.