How I Actually Do Agentic Engineering As A Senior Software Engineer

It's been a minute since I last shared How I Actually Code with AI (almost a year!) and a lot has changed during that time.

I moved to a terminal-focused dev setup
I exclusively do agentic engineering
I switched from Claude + Claude Code to GPT and OpenCode

With this new setup:

I haven't edited a single line of code in 6 months
In fact I often talk to my computer more than I type in it

Weekly PR throughput increasing from 7 before agents to 12 with early agents and 20 in the later workflow.

I've increased my throughput by ~2x - from ~7 PRs / week before agents to 12 with early agents and 20 in my current workflow

So in this post I want to share a bit more about my current agentic engineering workflow, how it works, and why I built it this way. The industry is changing fast so I'm sure this will all change in the next few months but hopefully you get smth useful out of it.

My Approach to Agentic Engineering

First we need to align on a few foundational beliefs of mine for the rest of the workflow to make sense.

Why Agentic Engineering?

I think the reason a business exists and people get hired is to provide value - value to the customer such that they are willing to pay for it, value to the company such that they are willing to keep paying for your time/energy/resources. This is why one of my core values is impact (shamelessly stolen from Meta's "Focus on Impact").

As a software engineer, I typically build software but software was never the point. The point was to solve a problem or capture an opportunity and software was just the medium to get there. As you gain more experience with the world and engineering, you start to realize that while software is amazing in its flexibility and scalability there are many problems where another approach is more effective be it process, people, or some other avenue.

So to me agentic engineering is just another tool / approach to achieving impact. The value proposition is largely the same from the customer / business standpoint but the available tools have changed, changing the most effective route to get there.

I understand the grief that comes with not needing to write every line of code anymore - I spent a decade of my career doing this and much of my freetime diving into different languages, building side projects, and thinking through how to build simple scalable systems.

But I'm even more excited about the future where I can build systems faster with even higher quality than I could've imagined before. Where the limit is mostly my focus and imagination than my energy or resources (time being an especially scarce resource now that I have a kid).

That's why I choose agentic engineering - it's simply a more effective way to get the impact / value I'm shooting for.

How I use AI Agents

In 2026 frontier AI agents are very good at coding but they're still not great at engineering. This gap is where humans still add a lot of value.

Agents are good at:

Reading and writing incredibly fast
Writing correct code (really!)
Calling tools - CLIs, APIs, MCPs, raw BASH, etc
Being ~tireless (at least within their effective context windows)

Agents are bad at:

Holding lots of context in memory (and the effective context is much lower)
Making tradeoff decisions - mostly limited by effective context
Long term vision and context alignment - mostly limited by effective context
Being deterministic (but neither are humans and that's largely the superpower of both)

Humans own direction, judgment, and quality while agents handle research, implementation, and review.

So when I think about leveraging AI agents, I think the practical approach is:

Humans own the outcome and direction
Agents do the footwork

My Agentic Engineering Workflow

The way I think of my current agentic engineering workflow is that I'm the owner and the agents are my team.

Me: Founder, owner, Tech Lead, Manager, Architect, PM
Agent: Researcher, Coder, Designer, Partner

I then think of most cycles / loops with AI as a kind of generalized creation cycle loop. I set direction and have the agents do most of the footwork. How much autonomy I give to the agents and how much scope depends on how much I trust them to accomplish this work successfully - largely driven by my own experience with them, the maturity of my skills and guardrails, and how risky this thing is to get wrong.

Small and risky -> I'll be pretty involved
Large and non-risky -> May be involved early but once I'm confident on direction, let the agents have it
Small and non-risky -> Agents can send it

The agentic stack: humans set strategy and guardrails, AI agents choose actions, and tools provide execution and feedback.

I also want to point out that this is an evolving process. It's not like code where you set it and forget it and it keeps on working (but let's be real that rarely happens in the real world anyway, change is a constant so the systems must change to accomodate them). Instead it's a continuous learning process for each new model release, each new project, each person, etc.

The agentic engineering loop: build a vertical slice end-to-end, create stacked PRs, review, ship, and improve the system for the next cycle.

My creation cycle loops look something like this. Note this is not a novel approach, this is basically how we've been doing software engineering for decades, it looks a lot like a typical SDLC, and most kanban boards / agile approaches take a similar approach.

Direction - Align on the problem / opportunity / outcomes we want to achieve
Plan - Create a plan to get there
Create - Create some artifact / take some action to fulfill the plan
Review - Double check your work

Here we're focused on coding but I think this cycle works for basically any cycle of creation - I even dubbed this approach the Creation Cycle. I also use this approach for writing though I find myself way more involved in the Create section because I believe writing your own outlines and prose is a more effective way of thinking than passing it off to AI. But YMMV - the point is this approach works for coding but is more generally generalizable to other workflows as well (also the underlying idea of Phase Golem, my configurable AI orchestrator).

Human and agent responsibilities across Direction, Planning, Coding, Review, and Ship.

Direction

Human: Set goals, constraints, and guardrails
Agent: Research, vet, iterate through problem framing

Humans own direction setting. This is largely because we have a larger effective context window. We have years of experience to pull from, we've probably heard / read things from around the org that informs our direction, and we can hold lots and lots of content in our brains AND prioritize which bits to act on vs which not to.

Agents can't. You try to feed them dozens of pages of docs and they'll do pretty good. But now feed them all the different docs / rules / initiatives at your company and they will be hamstrung by all the competing information.

So humans today are still better at crystallizing all that info into what knowledge is pertinent right now and leveraging it to make reasonable tradeoff decisions while keeping the primary goal in mind. (We also are lazy so will NOT try to read all docs / context in a company because we know it's a foolhardy / boil the ocean task but agents don't always understand that).

Agents here become helpers for sorting and sifting through the mounds of data, creating output artifacts to crystallize it, and serving as first pass reviewers.

Plan

Human: Drive the plan, review it, ask questions, and make decisions
Agent: Build the artifacts, do research, make prototypes, review

Similar to Direction, humans have a larger effective context window so they're still typically better at planning. BUT I think agents are eating away at this and benefit from the massive amounts of training data they have and fast access for searching the internet.

Together this means that they typically can come up with very reasonable solutions to most common problems. And let's be real most problems (business or personal) are not that hard / novel. It's very likely that 99.99% of problems you're facing have already been solved in some manner before.

Now this doesn't mean that any of those particular solutions are the best solution for your problem. But it does mean they're great reference points and when combined with human's larger context window and better tradeoffs typically leads to a better plan faster than you would otherwise.

Not to mention distilling this into a clear and concise artifact complete with diagrams, code examples, and maybe even a working prototype and Human+AI works wonders here.

Create (Code)

Agents: Code the whole thing

Frontier agents are really good at coding. They can read code way faster than me and write code way faster than me. They can use tools like linters, compilers, and test runners to get feedback and iterate to make them green.

At this point it really doesn't make sense for me to try and put fingers to keyboard and type stuff out. Agents are just far more efficient at it. That's why I haven't manually edited a line of code in the past 6 months - it doesn't make sense to. (It's also why I don't type nearly as much as I used to, talking to your computer is a much more efficient human:computer communication medium).

A lot of ppl will read this and be like well I see so much bad code from agents so this must just be bad code! And I think the distinction to make is that today's agents are really good at writing correct code to the spec you gave them but they aren't great at direction so this may not be the right code / system / creation that you intended or that actually fits the scenario.

This is why I still think review is an important part of the process. But as you tune your system through cycles of improving guardrails the agents tend to get a lot better at producing things in the shape you want them because you've given them the right context.

So yes in isolation the code is rather sloppy. But as part of a continuously improving system, there is a critical point where it starts to be pretty good.

This is why I have my own personal AI Dotfiles. Mine contain lots of skills / context detailing how I like to work.

How I like commits to be done - atomic commits, stacked prs, structured git commit messages
How I like to write code - functionalish, clear naming, clear domain types (make invalid states unrepresentable)
How I like to test - Focus on the behavior, use data-driven tests when useful, avoid mocks
How I like to structure code - Vertical slices, functionalish DI, DDD-like boundaries, clear business-focused naming

The AI agents don't just come out of their Labs great at coding the same way I would look at 90% of ppls code and say it's not great - it's code, it may work, but I don't love it. But a lot of that is just subjective - the code works it's just not how I would write it, so I need to tell the agents how I like to write code so the code comes out looking like smth I like.

Review

Agents: Do initial reviews based on context, configured CODE_REVIEW files, and do initial fixes
Human: Final review - focused on the higher level shape, best practices, thinking through the business cases

Review is super important, even if you're not the one doing it. AI reviewers have gotten pretty good, especially if you supply them with the appropriate context to understand your domain.

I always have an initial AI reviewer do a first pass to clean up anything it sees and keep things up to my configured standards. This is how you get away from a rough draft to a cleaned up first draft that's actually worth your time to look at.

But in most cases I still like to review the final thing before shipping it. I'm typically not looking for that many small mistakes because most of these have been ironed out by previous passes of improving context and guardrails. If I do see smth I don't like, I'll make a note to improve the guardrails for next time. Instead I'm mostly looking at the high level direction of the change to understand if it's solving the problem we set out to solve, it's the right shape of solution, it follows best practices, it's an appropriate level of complexity, and if it jogs any other ideas for me to explore.

Human review is one of the most expensive things in my initial loops so I largely try to remove my own necessity by building up sufficient context and guardrails through earlier cycles.

My Agentic Engineering Skills

I have a set of skills I've built that basically helps me run through these steps.

This is a pretty common approach - it's basically the software development life cycle in markdown that agents can follow. Similar implementations include Matt Pocock's skills, Superpowers, and PStack.

As a reminder I snapshot my full AI Dotfiles and make them available in the HAMY LABS Example Repo which is available to HAMINIONS Members.

Workflow Documents

My workflow outputs a hierarchy of documents as part of its artifacts. Documents like these are useful for sharing context between agent sessions and because agents have small effective context windows, there's going to be a lot of agent sessions to build anything meaningful.

The idea of these documents is to align the high level idea first before getting too deep into any plan or idea - agents love to get very specific very fast but this is a quick way to flood their context with useless tokens if you're not aligned on high level direction first.

This is doubly useful because it can serve as a clear way to progressively disclose information to future agents as they need it. They only need to reference the parts of the document hierarchy relevant to their job and if we've set it up correctly this is usually a small fraction of the full project context.

Given context is the bottleneck, I typically will create a new document set (what I call a Change) for any substantial project. Some projects may even get recursive hierarchies of Change documents if they're of sufficient size.

Foundation defines the outcome and boundaries; optional RFC, Design, and Stories documents add technical direction, focused detail, and execution units.

The documents:

Foundation - A 1-pager of what we're trying to accomplish, including constraints. Serves as the source of truth and tie-breaker that any agent can refer back to. Helps to align high level before we dive in further and keeps future agents from going off the rails because they can see the non-negotiables.
RFC (optional) - The tech spec. Only necessary when the approach is not straightforward enough to put in the Foundation. Typically only used for novel approaches, changes in tech stack, large projects, complex areas.
Design (optional) - Designs for specific areas. Useful for diving deeper into areas of design that need it - components, sub systems, etc.
Stories (optional) - Story files for defining milestones of work to be done. These can have parent/child connections and reference other documents in the Change. Useful for larger pieces of work that will need lots of sessions to complete.

As you can see the only mandatory bit is the Foundation which aligns the high level vision of what we're trying to do. Everything else is optional depending on the kind of project we're taking on and how much detail we think is useful / necessary.

This is very similar to how we run human projects - add the appropriate amount of up front planning and process based on the project at hand.

Direction + Plan Skills

The direction and planning skills are my general entrypoints to a project. I typically just call Plan Align to kick it off and depending on what we discover in the Foundation / future iterations in the cycle we'll dynamically choose to build out additional plans / documents to handle that area of the project.

Plan Align -> Foundation - This is my entrypoint to a Change. I have an idea, I want to do research and flesh it out, ask me questions and do research til we feel it's pretty solid and aligned.
- Very similar to Matt Pocock grill me or Superpowers brainstorm
Plan RFC -> RFC - Take the foundation, do research, and craft an RFC for review.
Plan Design -> Design - Take the Foundation and any other Change documents we have and create Designs
Plan Stories -> Stories - Take the Foundation and any other Change documents we have and create Stories
- Very similar to Matt Pocock to stories

Code + Review

One Build Orchestrator manages multiple Build Cycles, each with Implement and Review work. Cycles run one at a time.

My Code + Review skills are what translates the plan from markdown into the actual code. Review is super important again to go from a rough draft to a decent first draft.

Implement - Implement the code from a given Story / Foundation / any other Change docs we have, run the configured code tools (tests, linters, etc)
Review - Review based on my coding preferences, configured repo context, and Change documents. Here's an early version of my AI review skill that used 9 parallel AI agents, now it's a more streamlined single pass with optional auxiliary passes depending on specialty / riskiness.
Build Cycle - Take a Story and run a targeted Implement and Review cycle with 1 retry
Build Orchestrator - Take a set of Stories and run Build Cycles sequentially on them with 1 retry each

My Current Agentic Engineering Stack

So that's how I run my workflow, I wanted to give a quick overview of what my stack / dev environment looks like.

I typically have two windows up:

A terminal (Ghostty)
A browser (Google Chrome)

This is basically all I need to run my setup.

Terminal Setup

Ghostty - Modern, robust terminal. I'm not bullish but works fine for me.
Zellij - Tab / Session management. Allows me to reopen sessions after a crash (useful for remote machines when need to reconnect) and create / manage tabs which is useful for organizing all my agent sessions
OpenCode - For my AI harness. Mostly wanted a 3rd party harness so could easily use any models I wanted. Works fine, but not bullish.
GPT 5.6 + 6 - Mostly maining GPTs over Claudes these days mostly because they're faster, cheaper, and less prone to ridiculous prose I can't reason about.
Nvim - I don't really code by hand anymore but often still useful to look at the code so I use nvim because full featured (and supports vim!), light weight, has lots of plugins, and works directly in my terminal. I mostly use it for writing posts like this though.

Browser Setup

Nothing fancy. Just vanilla Chrome. But I do think it's useful to understand how and why I use it.

While my terminal is my primary workspace for agents, I still think having access to rich media is useful so I like a browser up for:

Reviewing Code - Often in GitHub directly, commenting on it, and then telling the agents to go update based on my reviews
Looking at rich media - I have an HTML Artifact skill where my agent will create html and serve it locally so I can look at more complex docs outside of markdown
Messages / task trackers - Still really useful to have available

So that's my current agentic engineering setup. I think it's pretty simple and there's a lot more areas it could be optimized for further automation, better performance and cost effectiveness, and extended to more areas of creation. But it's also pretty effective - it's become my primary way to build systems and more generally interact with my computer.

I don't think this approach is objectively the best and I also don't think it's going to work for everyone. But hopefully it inspires you to think ab your own systems and craft one that works for you. That's the true promise of AI - allowing your imagination to be the limit.

Let me know if there are any other areas you're curious about and I can make some followup deep dives and if you have your own approaches to doing this that are different / better - would love to learn!

As a reminder I snapshot all my AI Dotfiles each month and make it available to HAMINIONS Members.

If you liked this post you might also like: