How I Use LLMs Effectively

I have been using agents for code generation since before today's harnesses and tools even existed. For a long time, this was super taboo in the developer community - despite this obviously being the future to me back then. 

I wanted to share where I've landed with agents as a developer who is deeply technical and has been leveraging these tools for a long time. It took me a lot of time to figure out how to get these tools working with as little intervention needed as I do today.

Pretty much all of my development now comes down to giving agents clear direction and reviewing what they produce. I can start a thread for any of my repositories from my phone and an agent works on my server until it has a PR I can actually review. I was only able to trust agents this much until recently, previously I would hand-hold a model beside me in my IDE and hand-test, validate, and review everything. 

I've found that not only can newer models write the code, they can also handle the validation and part of the review too - given the right setup. I think the #1 most impactful thing any codebase using agents today could add that makes agentic development 999x better is to define an AGENTS.md that gives agents the tools to validate, test, and scrutinize their own code. Just like you'd give a new hire a bunch of docs to understand your codebase, your agents benefit the same.

I'm still doing technical review. I need to understand the code and the agent's actions well enough to judge whether the work is right. The process around the model gives me the confidence to let it get on with the implementation, while I put more of my attention into what I'm building.

I'll use Flare (my self-hosted file sharing platform, totally cool btw) as the example. Its PRs let you inspect this process, from a small view-count fix to a complete permissions system. This is how I work across my projects.

Give your agents their own environment

I pay roughly €80 a month for a Hetzner bare-metal server that I got through a server auction a while back. It serves a bunch of different purposes, but the biggest leverage thing that completely changed how I work is moving all of my development to it. The agents use a VM I created on it. My whole server is overkill for this, you don't need to copy that hardware bill.

Everything runs on the VM, and my agents have complete dominion over it. They can install tools, configure things, and do what they please on it. It's their environment. When they get stuck, they can unblock themselves. Untying my development from my actual main machine has been a total game changer. I don't have to worry about agents doing something dangerous on my actual hardware, I can send prompts and check in on threads from any device, and there is a single source of truth.

Making it available from anywhere

T3 Code is the brains between how I access and run agents remotely from any device. It runs as a user-level systemd service. I have lingering enabled so it keeps running after I log out of SSH. The relevant part of my setup is:

[Service]
WorkingDirectory=%h/projects
ExecStart=/opt/node/bin/node %h/.t3/runtime/service-launcher.mjs
Restart=always
RestartSec=5

T3's launcher selects the active version under ~/.t3/runtime/; thread state and settings live in ~/.t3/userdata/. On a headless machine, t3 connect offers to install this service. The background service guide covers setup.

T3 Connect links the VM to my account and handles coordination between all of my devices. App traffic reaches it through a managed tunnel, with cloudflared running on the VM.

Giving agents room to finish

The provider CLIs and GitHub CLI are authenticated there. My Flare threads use full access: Codex uses danger-full-access without per-command approvals; Claude Code uses bypassPermissions. T3 sets that for the thread. My global Codex configuration is more restrictive.

I manage this development machine and the accounts it can use. I'm comfortable letting an agent run ordinary commands without waiting for me each time given they are on their own VM and haven't let me down so far. I can assess what it's doing.

When work overlaps, agents can just use separate worktrees. Really simple stuff:

git fetch origin main
git worktree add ../Flare-raw-views -b fix/count-raw-views origin/main

Worktrees gives each agent thread a separate checkout and branch. The VM is still shared, so app ports and test databases need to be separate too (although there is a way to have multiple VMs and T3 Code can smartly orchestrate between them if you wanted).

1. I give it real direction

Being technical still matters a LOT. Honestly, it might be the only thing that matters left. You really need to have technical acumen to put thought into your prompts. I know how I want the project to behave, including the defaults that would annoy me if they were wrong.

I essentially give models my ask (usually a feature or change) and a set of technical constraints as my prompt. This can range from free-range to see how a model handles things alone, or a detailed ERD-style technical spec that I give in my prompt. Either way, knowing what agents output is still imperative.

For Flare's roles and permissions feature, #226, I wanted Discord-like roles. One part of my prompt was:

It should be fully integrated into the entire product and be super thorough permissioning

This was surprisingly enough for it to pick up on the repos patterns. I specified that the first account on a fresh instance should get an automatically created Admin role with all permissions. The old user/admin split needed replacing throughout the product. I asked for documentation and demos alongside the feature.

Those details matter. A nice role editor is useless if nobody can access it. Permissions need enforcement on server routes too, because someone can bypass the interface and make a request directly.

The agent can investigate the implementation, and I review what it chose. For a small fix, the prompt might only be a sentence. The expectations around finishing the work are already written down.

2. It finishes the work and opens a PR

I expect something ready to review. A failing test is for the agent to investigate, and changes to an API need working examples in the docs.

Flare's AGENTS.md carries those expectations into new threads. The PR template gives the agent somewhere to report its checks and attach evidence. I use skills for procedures and memory for useful things learned about the machine. Those saved notes aren't automatically shared between my providers.

When I keep giving the same correction, I write it down somewhere the next agent will find it. That saves another conversation about something I've already explained.

A big feature comes back with evidence

Because I gave agents the ability to install tools and do what they want on their own environment, I was able to setup a rule that forces all PRs to be opened with documentation and screenshots/demos by default. The demo below was attached to my roles/permissioning system PR, entirely agent generated. This allows me to see what the agent validated/tested before merging, like a real engineer would.

The roles PR added server enforcement and an upgrade path from the old account roles. It had to stop administrators granting access they didn't have themselves, and keep the last administrator accessible.

The agent reported its limits too. An external S3 test needed credentials. An older visual-test recording stopped at login, so it used fresh browser checks and captures. I want that explained in the PR.

3. Greptile reviews it and the agent handles the findings

Greptile reviews the PR and assigns a confidence score. If there are no findings and everything is good, Greptile gives a 5/5. I want 5/5 on the current revision before treating it as ready for my review. Sometimes I send a follow-up asking the agent to address its comments; once it has that direction, I leave it to work through them.

Greptile is honestly the best code review agent out there, and it doesn't even come close. It's a HUGE driving reason why I feel comfortable trusting agents to own so much of the process. It has gotten really good. Once a PR reaches 5/5, I often finish my own technical review without finding an issue or needing another iteration. It's a big part of why I trust this process now.

For an example of a smaller change, I wanted to change how views work on Flare. The raw-file view-count fix, #237, started with this entire prompt:

Put up a PR that counts /raw views as views.

Adding the counter write introduced a wait while a local file stream could emit an error. Greptile found two failure paths:

The agent fixed the stream handling and tested the real local storage provider autonomously. It used a temporary PostgreSQL trigger to force counter writes to fail, then sent full and range requests through the app. They returned errors without changing the count or leaking the fixture's file descriptors. After removing the trigger, the next request worked. The PR reached 5/5 on its next review.

Obviously, bugs can still get through - although VERY rare with a Greptile 5/5. What I get by this point is a much better PR to review, with evidence I can inspect. To be clear, I still am hand reviewing every agent PR myself - and I don't think that will change.

4. I review the code and try the change

I read the code and check what the agent actually did.

Flare's PR previews are probably my favorite part of this all. I can use the feature from the same phone I prompted it from. A bot comment gives me a link to a live deployment of the PR's head. It also identifies the commit and when the preview expires, so I can review it without checking out a branch or having a real development environment available.

How the preview gets there

Flare uses Railway for previews, separately from my development VM. This is its implementation of the broader workflow; other projects can have different deployment setups.

The build job packages the exact PR head as an OCI image artifact via Github actions, and Railway deploys that image on a public URL. The deployment gets fresh session and database secrets, with an empty database ready to go. 

Each instance starts at Flare's normal first install setup, so I can test installation too. Someone else might have created the first account before you arrive. I use made-up accounts and files. The preview documentation has the full lifecycle.

Using it changes what I ask for

In another change driven by this workflow, I added 2FA and passkey support to Flare. In my passkey PR, #227, I registered a passkey using the preview deployment and I could still sign in with a password. After trying it, I wanted an explicit setting to require a passkey. I sent that back to the agent, which handled the implementation and recovery behavior, including tests and docs.

That was a decision I got to make without needing a local environment ready. If I find an implementation problem during review, I send that back too.

5. I merge and let the release process run

When I'm comfortable with whatever changed, I merge it. Flare's rolling workflow publishes multi-platform Docker images, including a commit tag. I can run the changes together and see what turns up over time.

When I think it's ready for stable, I bump the version. The stable workflow creates the version tag and release images.

I'm happy letting AI write all the code

I want to be proud of what I ship. T3 Code and Greptile deserve a lot of credit for making this way of working practical for me. They're great products.

I don't buy the idea that AI-written code has to be slop. You can put your standards and apply yourself into the process and give the agent tools to meet them. My ideas and technical acument still drive my projects, the tooling just lets me get more out of the effort I put in.