How I Develop in 2026

As of 2026, I work as a software engineer at a company in California.

In this post, I describe how I currently approach development and which methods are working for me when developing with coding agents.

In the near future, if fully autonomous development methods become established, the software engineering profession might disappear. At the very least, fewer engineers may be needed. This is simply a record of how I develop today.

Development Workflow

I adjust the process to the company's security standards and policies, as well as the nature of the application, but I generally follow these steps:

1. Triage
2. Planning / Spec
3. Dev
4. Test (static checks, TDD, E2E, or a combination)
5. PR (+ CI/CD)
6. Summary (personal takeaways, if any)

1. Triage

In this phase, I decide what to work on. I consider quarterly goals, customer problems, and task priorities, and try to start with work that has the highest priority and impact.

Dependencies between tasks can also affect the order of work. If the priorities are set poorly, development may not proceed smoothly. Reaching agreement within the team and with clients is therefore important.

2. Planning / Spec

Once I know what to work on, I define the plan and spec for how to proceed. For an abstract goal, I consider multiple approaches, understand their tradeoffs, and choose the best solution.

The best solution may depend on the application's particular characteristics and business needs, so an agent may not be able to find it on its own. With the right context, however, an agent might be able to handle it.

Useful skills such as Superpowers are available now. I prefer to use those, or instructions I have written myself in files such as AGENTS.md, to guide the work.

3. Dev

This is where I implement the change. When working with an agent, I try to follow the existing repository's coding conventions, keep changes small, and prevent regressions.

An agent may use external tools to gather the context it needs. In that case, information access must be managed carefully. For example, I define in advance which actions are allowed. If I use AWS, one option is to configure IAM permissions to allow read-only actions.

I also keep sensitive information, such as .env files, out of the agent's reach. By deciding which information it can access and where access should be restricted, I can improve development efficiency while maintaining safety.

4. Test

I run static checks with tools such as linters, along with unit tests and E2E tests.

TDD makes regressions easier to prevent. On the other hand, adding test code for every feature can make the codebase larger and increase token usage. I therefore choose a testing approach according to the situation.

For E2E testing, I may have an agent operate a browser or check the results of database updates. For higher-risk areas such as databases, though, I think it is better to take an appropriate backup and have a human perform and verify the operation directly.

5. PR

When a team reviews code, or when someone may need to refer to the changes later, creating a PR is useful. A PR template can help present the changes, background, and test results in a structure that people can understand easily.

6. Summary

If a session produces personal lessons or quantitative measurements, I record them in a Markdown file. I have created and use my own skills to organize the problem, approach, results, and lessons learned.

What Works Well

Triage & Planning / Spec

I feel that talking with stakeholders, setting priorities, and moving development in the right direction are more important than ever. Spending time adding the wrong feature or working on a low-priority task is wasteful.

To move quickly in the right direction, it is important to think about what is needed and what should come first, then make decisions as the work progresses.

Summary

Simply outsourcing my thinking to AI does not help me learn. I need to understand what went well and what did not during the session, then use those lessons to make better design choices and decisions next time.

It matters not only that AI finishes the work, but also that I understand what I learned from it.

What Doesn't Work Well

TDD / Testing

Applying TDD rigorously increases the amount of code in the codebase. With limited time, it becomes difficult to understand all of it. Depending on the situation, I therefore focus more on E2E testing, with a human taking responsibility for the final verification and outcome.

CLI-based tests are also more efficient when automated than when an agent runs each one individually. Having an agent read every log consumes many tokens. I have found it more efficient to prepare commands for static checks and have the agent review only their results.

It also helps to manage basic tasks, recurring tasks, and overall guidance as memory in Markdown files, allowing the agent to improve over time.

Conclusion

Coding agents are increasing development speed, but the speed expected of engineers is also rising, adding to the human workload. At the same time, it is becoming harder for a person to understand an entire codebase correctly and carry out all implementation and testing.

That makes it important to know how to implement trustworthy code, what outcome is expected, and how far a change might reach.

Rather than understanding every line of code in detail, I need to understand the core parts and make sound decisions about verification. I will keep refining my approach to developing software safely.