DEV Community: Liatmoss

Keeping You in the Driver's Seat and AI as the Copilot

Liatmoss — Sun, 26 Apr 2026 13:08:36 +0000

Code literacy and code competence are very interesting topics of conversation at the moment. With AI doing a large amount of the investigating, planning and coding work lately, how do we make sure as engineers that we are keeping on top of the code that we write and how do we make sure that it's readable and understandable to everyone else in the team.

It occurred to me recently, speaking to some people on the topic, that maybe my willingness to pick up these tools, comes from being a self-taught software engineer. I don't have the same level of code literacy as some of my peers and while that hasn't been an issue, I'm able to catch up and learn faster with the use of AI.

Pairing with my agent and using it as a built-in rubber duck has helped my confidence and my understanding of the code. While for some people, these tools are just seen as "code monkeys", doing the work so we can sit aside them mindlessly watching the thought process, I am using it as a discussion tool, asking questions, building my knowledge to bridge any gaps in my education and understanding of what is going on.

While I don't trust the code, and constantly check for mistakes or places for improvement, I am able to ask questions and understand why certain choices have been made. Similar to the discussions I would normally have with senior team members.

I definitely understand some of the hesitancy to utilise the tools and they can definitely be daunting to start with but from my experience, these are the steps that I take to make sure that I am learning from the tool, not relying on it:

AI tools are a copilot: they shouldn't be in the drivers seat without someone keeping an eye on them to make sure they're on track
Ask questions: if you're unsure of why something has been selected or why a particular piece of code has been written, ask! If you don't know how it works, then you don't know that it works
Review everything: you own the code you write, not the AI agent. If you merge code that looks right but hasn't been verified, that is on you as the approver/author of the code
Understand the tools: there are many modes available across all AI tools, it's important to understand them in order to utilise them correctly. Just because the AI tool is acting the way you want, doesn't mean that it's the most efficient way to utilise it
Rubber duck it: AI is a pair programmer, use it the same way you would a rubber duck. Talk to it (out loud if you need to), ask it questions, make it check and re-check everything written to make sure that you're happy with it. Go over the same code suggestions with different models to receive the best outcome

The biggest takeaway for me when looking at implementing new tools, isn't about what's shiny and new or the latest workflows, but about mindset.

Staying in the driver’s seat means being intentional about how and when we use AI. We should not be defaulting to it, but at the same time, we should not be avoiding it.

It’s not about handing over control but rather about using AI deliberately, where it adds value, while staying responsible for the outcome.

A practical guide to getting comfortable with AI coding tools

Liatmoss — Tue, 21 Apr 2026 10:26:24 +0000

There is a large shift at the moment in how people are approaching AI tools. It's one of those moments where if you don't start using them, you will be left behind. Given the large shift in capabilities recently, jumping in can seem confusing, overwhelming or even a little intimidating.

When I first started using AI for my workflow, it was slow going. I was hesitant to pick up new tools or to use them too much. It was hard to understand tokens and context, but a larger part was simply not knowing where to start. A lot of the online workshops and tutorials become outdated, fast, making them unreliable and difficult to follow.

Many people I've spoken to want to jump straight in and build agents, skills and superpowers without understanding the basics of how the tools work. Most developers want to start with 100% AI code and that's where it starts to feel hard. Starting small might feel like you're not doing enough, but it's easy to speed through these steps and move on to more complex tools.

By following these steps, you'll be able to use an AI tool to explore and understand a codebase in a structured way and have a simple workflow you can reuse.

A Practical Guide for Getting Comfortable with AI (Github Copilot)

There are many tools available for coding but I have found Github Copilot a good starting point. There are many built in tools which make it easy for those just starting out and the docs are very easy to follow.

Step One - Start Small

Before jumping in to having your AI write your code, look at your AI tool like a pair programmer. They're a junior developer just starting out; you need to give context, guide it, and review what it produces.

Copilot comes built in with features like /simplify and /explain which are great starting tools for using your AI agent

Another option is /tests which will take the selected code and write a collection of unit tests which can be used to check your code.

Utilising these build-in tools will help you to learn the capabilities of your AI faster and provide you with easy prompts that can be reused.

Step Two - Build Trust

It is very easy to take everything at face value and trust that the output is correct. It's important to take a step back and ensure that the information you're providing and the output of the tool are both correct. Just as we can make mistakes while working, so can AI and it's still your responsibility no matter which one of you wrote the code.

I suggest starting with Copilot in your IDE rather in the CLI. It's a more visual approach and can be easier to start with when doing smaller tasks.

There are two ways to talk to your agent, the first is inline and this has developed from the initial format of comment to code. Copilot has a built in chat inline where you can ask a question or assign an agent to update your work. The inline agent can be found by clicking the stars on the left side of your screen once you've highlighted your code.

This is a great tool for small changes and specific questions about sections of code.

When you want to do a large piece or build a new feature, the chat window is a better way to go. This will give you options for plan, agent and ask

These work the same as your inline chat but can be more generic or can relate to a whole file rather than just one section.

Agent mode will allow your AI agent to make code changes on your behalf by suggesting a possible solution to the prompt that you input.

It's a lot of fun seeing the agent work for the first time but it's very easy to get carried away, it's always important to trust, but verify.

Step Three - Integrate

Once you're familiar with the basics, it's time to start giving your AI more responsibility. Along with making code changes, most of the powerful AI capabilities come with debugging, exploring a new codebase and drafting implementations.

Debugging:

Code doesn't always work the way we want it to first time round. There can be issues with the syntax, missing dependencies or something just isn't looking right. AI can be a great pair programmer in these scenarios as it can be a good buddy to bounce ideas off of and to ask for help without needing to ask another member of the team.

Exploring a new codebase:

We've already looked through /explain which can be a great starting point when we need to understand a method that may not be written in a readable way. But what happens when we have a whole new codebase or a class that we need to understand?

By using the built in plan mode with a prompt guiding what is required, Copilot is able to put together a detailed document of the project or feature that you're learning.

This is an unfamiliar codebase and I need to understand what this
program does in order to extend the logic.
Can you write out a detailed investigation of this code and include 
any structural diagrams you believe would be necessary to my understanding.

Drafting Implementations:

Plan mode can also be used to generate detailed code plans before assigning to an agent. These are handy because it adds another check to ensure the new code is doing what we are expecting. Once a plan has been created, you can ask questions, adapt the plan and make sure that the proposed change matches what you are asking it to do.

I would like to expand the logic of my password checker. Write a plan 
that meets the following requirements:
- I would like to ensure that there are no spaces in the password
- All other validation should stay the same
- There should be test cases to match

Once you're happy with your plan, there's an option to start implementation which will assign your plan to an agent for them to work through the code changes that you have approved.

It's still important to check all test cases and to make sure that your code is building correctly as there's sometimes context missing from the work the agent is doing. Trust, but verify.

Step Four - Expand

Once there's an understanding of the fundamentals and how the tooling works practically, it's then easy to build on the existing knowledge to more complex tasks.

Once I understood how to utilise these ideas, I went on to add external MCP tools and eventually I built my first custom agent

It's important to understand when to use each skill and to refine prompts and models to receive the best possible outcome. Once you have that foundation, the options are limitless.

Confidence over complexity

Many people jump into using AI tools without fully understanding the complexities. While it's very possible to use AI completely to write 100% of code, it's important to start slow, understand where the tooling is beneficial and where human intervention is important.

For me, I enjoy the planning tools. It's where I spend more of my time and iterating through plans and ensuring they match the output I want means that I can sit back and let the agent take over the code.

This took a lot of trial and error. A lot of opening PR's and closing them because the code had compilation errors or just didn't match what I needed it to do. Sitting back and becoming more familiar with the basics meant that I could learn faster and do more with the tools.

It does still take time to learn but by slowing down, researching and asking questions of those already utilising the tools, my skills are growing faster, I'm getting more confident and there are less mistakes.

It takes time to learn today to make you a better engineer tomorrow

Custom Agent or Built-In AI? A Practical Checklist for Making the Right Choice

Liatmoss — Sun, 19 Apr 2026 02:45:59 +0000

AI tools are constantly changing and are getting more powerful with each release. Since creating my first custom agent The Super-Investigator , it has been incredibly tempting to use custom agents for every situation, but in reality, not every problem needs one.

Knowing when to build a custom agent has been the most challenging and I feel like I'm still maybe under utilising the option so that I don't over complicate my work.

The Custom Agent Decision Checklist:

Repetition: Am I repeating the same prompt to get consistent results?
Complexity: Am I constantly switching between multiple modes like plan and agent?
Consistency: Should the output follow a particular structure each time this prompt is used?
Context: Is the context required for this task repeated every time I utilise this prompt?

Why I chose to write my first agent:

I wrote my first investigator agent a few weeks ago to solve the problem of repeated prompts. I was constantly asking Copilot to complete an investigation for me which, at the start, involved the same prompt and the same context no matter what I needed investigating. I was copying and pasting the majority of my prompt and updating only the small parts that added context to that day's particular problem.

Once I started adding in MCP tools like Atlassian linking context to Jira tickets and saving investigations in Confluence, the task became quite tedious as I was switching between plan for the initial investigation and agent for any updates and to save the plan to Confluence.

This was an incredibly repetitive process and although I was saving a lot of time having Copilot do the initial investigation, I was still wasting a lot of time switching between built-in tools. Having the custom agent meant that all the shared detail in the prompt could move to a custom agent file that could be used multiple times by anyone in the team. I could also add in automation to link to Jira and Confluence without having to add an additional prompt or wait until the investigation was complete.

Working with a custom agent means that my team is now generating structured documentation by utilising the same investigation pattern. We have the capacity to have a unified structure for investigation documentation and links to Jira tickets.

When I utilise the built in Plan/Agent workflows:

There are other instances where I have used a prompt frequently and have created agents (story for another time) but the majority of the time I use the built in Copilot functionality of plan and agent.

My investigation agent has become step one in most of my coding sessions and I use that as a base to get Copilot to plan what to do next. Because the investigation comes with code snippets and detail on what is likely to change, I will often use plan as the next step because that is how our natural workflow goes, iterate on that and then assign to an agent to go ahead to build and review the code.

While I could add a loop in my Investigation agent to automatically move to the plan and build stages, I don't believe that in my scenario it's needed as I still like to make changes and update the plan as I go. While this is maybe a next step I could look at, I would need my plans to be more accurate and require less human intervention before it's something I look into.

Built-in tools are there for a reason, they're common used functionality for everyone at any level.

Final Thoughts:

So I leave you with this; custom agents are incredibly powerful, but only when applied to the right situations. They still require time to build and to ensure they are working as expected and if they're going to sit in a folder and be used once every few months, I'm not sure it's worth it.

For me, I find that as soon as I need to look back through my prompts to copy and paste something into the context window, it's time to go through my checklist to see if I am able to utilise a custom agent.

There is definitely a case-by-case argument to be made for custom agents but as the tooling and the models improve, I'm not sure if the future is custom agents or more skills focused to extend the built-in tooling.

The question isn’t what AI can do, it’s when it’s worth structuring how it does it.

From Unknown to Understood: Navigating Codebases with GitHub Copilot

Liatmoss — Thu, 09 Apr 2026 11:17:42 +0000

As an engineer, the nature of the job means that we are moving teams, switching to new products or changing jobs with some frequency. Even if we have been working on the same feature for years, it's impossible for one person to keep track of everything in a particular codebase. Understanding how everything fits together can be slow, error-prone, and frustrating, especially under time pressure.

Rather than treating AI as a code generator, I reframed it as an investigative partner, one that can trace execution paths, correlate logic across file structures, and surface insights that would otherwise take hours or days to uncover.

As AI coding tools evolve, it is important as engineers that we are able to keep up with the latest trends while also maintaining our productivity.
I have found it quite challenging to reframe my thinking that while it may take me all of today to get a better understanding of this particular tool, tomorrow I will be more productive for it.

And most of the time it's actually much faster to pick up then I expected it would be!

In my current team, we are working within a large codebase with code that was written by previous team members who had different "best practices" to what we currently use. Looking through the code as part of investigation or discovery was painful and took days or sometimes weeks.

Given that none of us wrote this code, or can possibly be across all of it, I created a pathway to help the team become more efficient in navigating through the code base. With the help of the steps below, we now have a structured and efficient way to conduct investigations and discoveries which save us time and effort allowing us to spend time building new features and contributing more to the code.

Step One:

The first step I took was to use the Plan agent built into Github Copilot to help with in depth investigations.
I wrote out a detailed prompt, copying and pasting details from the Jira ticket and had Copilot create a markdown doc with the investigation findings

I want your help to assist in an investigation. Explore the codebase and 
services based on the context given from the Jira ticket. 
If you are not sure on the scope or you need clarification, 
use your intuition and document assumptions clearly. 
Research based on these assumptions and if there are multiple assumptions, 
explore and compare. 
Create diagrams where required to explain the flow of the code 
and write in an easy to read and understand format. 

---
Context:
- ..
- ..

---
Requirements:
- ..
- ..

Step Two:

While this provided some great context, it was stuck in my editor or I had to manually copy it over to wherever I wanted the investigation saved. This is where I introduced MCPs to my investigations.
I added the Atlassian MCP server to my IDE which gave me the option to send the document either to a Confluence page or to the linked Jira ticket.

This was really helpful in that I could assess the investigation in the .md file, confirm that it answered the requirement that I had set out and then switch to Agent mode and ask Copilot to submit the investigation to Atlassian in whatever format I needed it.

Step Three:

This worked really well for me as I was learning more about the tooling but it was quite inefficient as I had to switch between Plan mode to create the investigation and Agent mode to make any changes or to send to Atlassian.

The final iteration of my Investigator copilot was to create my first custom agent Super-Investigator and give the agent the best parts of both the Plan and Agent built in tools.

The purpose of the Super-Investigator is to:

Scan files, code and dependencies in the selected codebase
Investigate the details provided either from the Jira ticket or the specific prompt
Document and diagram relevant findings
Standardise how we view documentation keeping a consistent format between users and features
Create a Confluence page with the full investigation
If a Jira ticket was provided, summarise all findings and add a comment to the ticket along with a link to the new Confluence page
Collates all the investigation documentation in one place where it's easy to find based on Jira ticket reference

What Super-Investigator Produced:

With a minimal prompt of:

Use the details provided in the Jira ticket [JiraLink]

Context:
- ..
- ..

---
Requirements:
- ..
- ..

Super-Investigator was able to iterate through the code searching for key words and phrases from the ticket. The agent identified the process that the specified field flows through the system, documented and diagrammed the flow before giving recommendations of what could be simplified.

Once the investigation was completed, Super-Investigator created a Confluence page in the designated spot using the Jira ticket number as a reference and included a summary of the investigation as a comment on the ticket.

This process, which manually would have taken days, was completed in approximately 10 minutes including a manual check by me to ensure the information was correct (which it was).

Findings:

This process took me about two weeks to iterate through and until the next round of tools are released, I feel like I'm in a great place now to investigate and gather information from my codebase.

The Super-Investigator custom agent I created is able to look through the code and provide a detailed investigation much faster than using the built in Plan agent as it stores more relevant data in the agent file and I need to provide less context in my prompt. The outcome is also more accurate than what I was originally getting back.

Super-Investigator is my first custom agent and I'm sure it'll get smarter as I start using it more and sharing my findings with the rest of the team. I'm excited to see what superpowers it's able to pick up next.

Creating the Super-Investigator was helpful in this particular situation, but not every problem needs a custom agent. What we need to look at for the future, is knowing when to create and when to utilise existing or built-in tools