# Beyond agentic engineering > ## Agentic engineering and what comes next ## 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](https://corca.ai/). ## 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](https://wiki.g15e.com/en/pages/Welcome%20to%20the%20Era%20of%20Experience.txt).) Existing code needs to be good for AI to produce good code. (See: [Improving frontend design](https://claude.com/blog/improving-frontend-design-through-skills)) Lower code quality (long code, , high coupling, etc.) means more tokens in an [LLM](https://wiki.g15e.com/en/pages/Large%20language%20model.txt)'s context → . 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](https://wiki.g15e.com/en/pages/Cognitive%20complexity.txt), 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](https://wiki.g15e.com/en/pages/Source%20code%20quality%20in%20the%20AI%20era.txt), [Enforcing the quality of AI-generated code](https://wiki.g15e.com/en/pages/Enforcing%20the%20quality%20of%20AI-generated%20code.txt) (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](https://wiki.g15e.com/en/pages/Cognitive%20complexity.txt), 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](https://wiki.g15e.com/en/pages/Specification%20written%20in%20natural%20language.txt). > "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." --, [Software Abstractions: Logic, Language, and Analysis](https://wiki.g15e.com/en/pages/Software%20Abstractions%20-%20Logic,%20Language,%20and%20Analysis.txt) Problem 2. Spec-code drift. ### Let's execute the specifications [Framework for integrated test](https://wiki.g15e.com/en/pages/Framework%20for%20integrated%20test.txt), created by [Ward Cunningham](https://wiki.g15e.com/en/pages/Ward%20Cunningham.txt) in 2002. ![Framework for integrated test.png](https://wiki.g15e.com/data/Framework%20for%20integrated%20test.webp) Both problems are mitigated: 1) spec-code drift, 2) the ambiguity of natural language. ### specdown [specdown](https://wiki.g15e.com/en/pages/specdown.txt): Writing executable software specifications by putting in Markdown documents. ![specdown.png](https://wiki.g15e.com/data/specdown.webp) ## 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](https://wiki.g15e.com/en/pages/Defect%20cost%20increase.txt)) - 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.