Your first agentic session - let's actually do something

Mar 9 2026 · Agentic coding demystified

Alright, so you’ve read the intro post, you have a vague idea of what agentic coding is, you might have even installed a tool or two. Now what?

Now we actually do something. Open up your project, pick your weapon of choice (IDE, terminal, standalone app, whatever), and let’s walk through your first real session together. No theory, no fluff, just a real task from start to finish.

What are we building?

For this walkthrough, I’m going to add a feature that pretty much every app has and every developer has built a hundred times: a settings screen. It’s got a list of options, maybe some toggles, maybe some navigation to sub-screens. It’s not rocket science, and that’s the point.

You don’t want your first agentic session to be “rewrite my entire networking layer.” You want something that’s:

Familiar — you know what the end result should look like
Scoped — it’s not going to spiral into a week-long refactor
Verifiable — you can look at the result and immediately tell if it’s right

A settings screen ticks all those boxes. Pick whatever feature makes sense for your project, but if you’re following along, settings screen it is.

Setting up

Open your project in whatever tool you picked. If you haven’t picked one yet, here’s a quick refresher from the last post: your IDE probably already has agent support built in, there are terminal CLIs from the big providers, and there are standalone apps that wrap those CLIs.

For this walkthrough, it genuinely does not matter which one you use. The flow is the same across all of them:

Point the agent at your project
Give it a task
Watch it work
Tell it what to fix
Repeat until you’re happy

That’s it. That’s the whole workflow. Let’s do it.

The first prompt

Here’s where most people overthink things. Your first prompt doesn’t need to be a masterpiece. It doesn’t need to be a perfectly engineered 500-word essay about exactly what you want. It’s a conversation, not a contract.

Here’s roughly what I’d type:

“Add a settings screen to the app. It should have a list of options including: dark mode toggle, notification preferences, account info, and an about section. Follow the existing navigation patterns in the project.”

That’s it. Nothing fancy. A few things to note:

I told it what to build (settings screen)
I gave it specifics (the list of options)
I told it to follow existing patterns (this is key — more on this later)

Could I have given it more detail? Sure. Could I have given it less? Also sure. The beauty of agentic coding is that it’s a conversation. If the agent doesn’t get it right, you tell it. You’re not writing a requirements doc, you’re pair programming with a very fast, very eager junior developer.

Watching the agent work

This is where it gets fun. And, if I’m being honest, a little bit unsettling the first time.

The agent is going to start reading your project. It’s going to look at your file structure, your existing screens, your navigation setup, your models. It might read 10, 20, 30 files before it writes a single line of code. And you’re going to sit there watching it, going “oh shit, it’s reading everything.”

This is normal. This is good. It’s trying to understand your project before it starts making changes. You know, like what a good developer should do.

Then it’s going to start writing. It’ll create files, modify existing ones, maybe add new dependencies. Depending on the tool you’re using, you’ll see this happening in real time, or you’ll get a summary at the end.

Here’s the thing that trips people up: the first output is not the final output. Read that again. The agent’s first attempt is a draft. It’s a starting point. And this is where the actual skill of agentic coding comes in.

Reviewing and course-correcting

The agent wrote you a settings screen. Great. Now look at it.

Does it compile? Probably. Does it work? Most likely. Does it look like something you’d actually ship? Ehh. Let’s see.

Here’s some stuff you might notice:

It used a different architecture pattern than the rest of your app
The naming conventions are off
It added a dependency you don’t want
The UI is functional but doesn’t match your design system
It put files in the wrong folders

All of this is fine. This is expected. Here’s what you do: you tell it.

“The settings screen looks good, but we use MVVM in this project. Can you restructure it to match the pattern used in ProfileScreen?”

“The toggles are working but they should use our custom DesignSystem.Toggle component, not the default one.”

“Move the SettingsViewModel to the ViewModels folder, not the Screens folder.”

See what’s happening? You’re not starting from scratch. You’re refining. The agent did 80% of the work, and you’re steering the last 20%. That back-and-forth, that conversation, that is the skill. Not the first prompt.

Some sessions, you’ll go back and forth 2-3 times and you’re done. Other sessions, you’ll be going back and forth 10 times and want to throw your laptop out the window. Both are normal. The more you do it, the better your first prompts get, and the fewer rounds you need.

Know when to start fresh

Here’s a thing that a lot of noobies trip on: conversations with agents have a shelf life. The longer a session goes on, the more back-and-forth you have, the worse the agent gets. It starts forgetting things you told it earlier, contradicting itself, or confidently making up stuff that doesn’t exist in your project.

This isn’t a bug, it’s just how these things work. The agent has a limited memory for the conversation (they call it “context”), and when it fills up, older stuff gets compressed or dropped. Think of it like a whiteboard — eventually you run out of space and start erasing the stuff at the top.

My rule of thumb: one task, one conversation. If you asked the agent to build a settings screen and it’s done (or close enough), and now you want to add a networking layer — start a new conversation. Don’t keep piling tasks into the same session hoping the agent remembers everything from an hour ago. It won’t.

Signs that it’s time to start fresh:

The agent starts “forgetting” things you already told it (re-adding that dependency you asked it to remove, ignoring your architecture, etc.)
It confidently references files or classes that don’t exist
The responses start feeling generic, like it lost track of your project
You’ve been going back and forth for ages and you’re going in circles

When in doubt, just start a new one. It’s free, it’s fast, and you’ll get better results than trying to salvage a session that’s gone off the rails.

The result

So, what did we end up with?

A working settings screen with a list of options, some toggles, navigation to sub-screens, and it mostly follows the existing patterns in the project. I had to manually tweak a few things — some spacing was off, a couple of naming conventions were wrong, and it didn’t quite nail the navigation transition I wanted.

Was it faster than writing it from scratch? Yes. Meaningfully so. The boilerplate alone — the view, the view model, the navigation registration, the list cells — that would have taken me a solid chunk of time just typing it all out. The agent did that in seconds.

Was the code good? It was… fine. It compiled, it worked, it was readable. It wasn’t going to win any architecture awards, and it needed some massaging to fit the project properly. But as a starting point? Pretty damn solid.

Here’s my honest assessment: the agent is really good at the boring parts. The boilerplate, the scaffolding, the repetitive setup code. It’s less good at understanding the soul of your project — the little conventions, the design patterns, the “we do it this way because of that one bug in 2024” stuff. That’s still your job. For now.

Takeaways

Your first prompt doesn’t need to be perfect. It’s a conversation. You’ll refine as you go.
The agent’s first output is a draft, not a final product. The skill is in the back-and-forth, not in the initial prompt.
Start with something familiar. Don’t try to learn agentic coding and a new framework at the same time. Use it on something you already know how to build, so you can focus on learning the workflow.
The agent is great at boilerplate, less great at your project’s conventions. You’ll spend most of your time steering it toward your patterns, not fixing compilation errors.
One task, one conversation. Long sessions degrade. If the agent starts forgetting things or making stuff up, start fresh — don’t try to rescue a stale session.

In the next post, we’re going to tackle that last point head-on. We’ll look at how to teach the agent your codebase — rules files, context, and all the tricks to make it stop writing code that works but looks nothing like the rest of your project.