Agentic Coding from a User’s Perspective — Experience: The Work Doesn’t Disappear, It Shifts

Published Sep 6, 2026
by

Since spring 2026, two projects have been taking shape with the same coding agent: an ETL generator on Next.js and PostgreSQL, and this blog. The agent does not complete lines, it works through assignments in the repository. This article collects my agentic coding experience from a user’s perspective. I build databases, ETL processes and the framework behind them, and I use the agent as a tool without doing AI research or building AI tools myself.

Is it worth it? Yes. I spent years building client-server applications in VB.NET and C#, and I am now building a TypeScript application without knowing TypeScript. That is the visible gain. The less visible part is that the work has shifted: from programming to structuring. Rules and skills for the agent, feature specs, bug files, test cases, documentation. In my working life, other people used to deliver that work, a project lead for example, and I consumed it as a developer. I underestimated how much of it there is.

The essentials up front:

  • Is it worth it? Yes: A TypeScript application with frontend, tests and CI, built by someone who does not know TypeScript but knows databases, ETL and .NET.
  • The work is not gone, it has shifted: Rules, skills, specs, bug files, test cases, documentation. Project leads and teams used to deliver that.
  • The guidance lives in the repo, not in the prompt: The prompts are short because rule files and specs carry the work. That includes intermediate states.
  • The infrastructure was the biggest hurdle: one server with four environments, self-hosted identity, containers, TLS, and no cookie banner because the architecture does not need one.
  • Control is a loop: An agent extends the radius of what I can build, not the radius of what I can judge. Whatever I cannot judge therefore goes through recurring checks that the agent runs. A green signal is not proof.
  • This article is itself an example: The draft comes from the agent. Selection, corrections and publication are my work.

Prerequisite: none. Anyone who wants to go deeper will find the way into this blog’s technical articles at the end.

Contents

What Agentic Coding Means Here

A coding agent is a language model that, with tool access, executes several steps in a row on its own inside a repository: reading files, running commands, changing code, running tests, committing. The difference to autocompletion is not the quality of individual lines but the mode of work. I formulate an assignment, the agent works through it and reports a result.

In both projects the tool is Claude Code, in the terminal and in VS Code. The observations do not depend on the product, though. They depend on an agent having access to repository, shell and database, and on a human deciding what happens with it. The mechanics behind rule files, skills and sub-agents are covered by the hub article AI-Assisted SQL Development with Claude Code. This article is about what they changed in my daily work.

Case Study 1: A TypeScript Application Without TypeScript Skills

The app project is called DI² and is an ETL generator on Next.js and PostgreSQL. The database layer consists of more than 150 DDL files, the repository is private, and I work on it alone. On the ETL side, the app’s tools build on a framework of my own that I am publishing on GitHub step by step.

From .NET to TypeScript

What I bring is data models, SQL, ETL processes and years of client-server applications in VB.NET and C#. I know how an application with database, business logic and user interface is cut, where state lives and where errors originate. What I do not bring is the language. TypeScript, the React ecosystem and the test tooling of the web world were new to me, and to this day I cannot read a file of this application the way I read a stored procedure.

The frontend, the CI pipeline and the test infrastructure came into being anyway. The clearest example is the 241-line Node script that checks the project’s SQL conventions and that I could not have written. My role was a different one: I knew the conventions, I could judge a finding as right or wrong, and I made the framing decisions. Acceptance ran through runs, not through reading the code, as the article about the guard shows. An agent extends the radius of what I can build. It does not extend the radius of what I can judge. Where the two diverge, acceptance needs a criterion that can be checked without understanding the code.

Conventions in the Repo Instead of in My Head

In a classic solo project, the conventions live in the developer’s head. With an agent that starts every session without the history of the previous one, that does not work. In the DI² project this turned into 27 rule files, 28 by now, one per convention, each with its reasoning. Features and bugs get their own files with a running ID before a single line of code exists. How such a rule set is derived from an existing codebase is described in the generate-refine-derive loop. What it costs when rules alone are not enough is shown by 799 hardcoded font sizes despite an unambiguous design rule.

The second half of this rule I only noticed when it failed. I accidentally ended a session in the middle of a bug fix and asked a new one to pick up where the old one had left off. The agent found no remains, neither in the working tree nor in the stash. That getting back in still took only minutes was down to the bug file in the repository: error description, database evidence, reproduction steps and three named hypotheses with a checking order. The intermediate state lives in the repo, or it does not live at all.

The Infrastructure Was the Biggest Hurdle

The part of the project that cost me the most time is not a line of application code but the infrastructure underneath. The application runs on a single VPS at Hetzner, and on this machine live four environments: development, integration, test and production, each with its own checkout, its own database and its own port. On top of that come a self-hosted Keycloak as identity provider and an nginx that terminates TLS and routes requests by hostname. A good dozen containers run there. All-Inkl, the host of this blog, plays only two supporting roles: DNS and mailboxes. One of the first lessons was that the VPS provider blocks outgoing mail ports.

Running my own identity provider was the biggest single hurdle: a realm per environment, a login theme in two languages, the migration from password login to the external identity provider and from a two-role to a four-role model. Provisioning is now handled by a script of almost 500 lines of Bash that can run any number of times without changing anything on the second run. I did not write a single line of it. What I decided was that there would be one server instead of four, a self-hosted identity instead of a cloud service, and a location in the EU.

Behind these decisions is a design goal I cared about in particular: The application should get by without a cookie banner. That only works if it does not need consent, so no trackers, no third-party scripts and no analytics services in the browser. What remains are three technically necessary cookies: the login’s session token and CSRF token, plus a language cookie for the public pages. For cookies that are strictly necessary to provide a service the user has explicitly requested, Section 25 (2) No. 2 of Germany’s TDDDG, the Telecommunications Digital Services Data Protection Act, requires no consent, and the privacy policy names them individually. The same rule applies to this blog. CI pipeline and database deploy are already covered on this blog in Database CI/CD with PostgreSQL, in GitHub Actions for Postgres Deploys and in Deploying a SQL Schema Without a Migration Tool. The infrastructure behind it will get an article of its own.

Reading Is No Longer a Control

Two things together changed the way I work. The first is the language: Whoever cannot read the language of their code cannot control it by reading. The second is the volume. The agent writes so many lines in so little time that reading and understanding all of it would not be possible even if I knew the language. Reading my own code in full, the way I knew it from my .NET projects, therefore drops out as a control. That is not an admission of failure but an unavoidable change in the way of working. If reading drops out as a control, something else has to take its place.

The Control Loop

The control I cannot provide myself has to happen somewhere else: in a loop of checks that the agent runs, but whose yardstick is not its own judgment but rules, tests and audit reports. It does not run once but repeatedly. After every piece of feedback, a rule is sharpened. Recurring checks have skills, that is, versioned prompts in the repository, among them one for security audits and one for update checks. I had unit tests pushed under existing code after the fact. The foundation for that only came in July 2026, and by now there are more than 700 tests. Since the end of August there is a catalog of manual test cases with acceptance criteria. All in all, 14 skills and 28 rule files carry this loop.

It has found things I would not have found by reading. A rate-limiting rule in the web server had been pointing at an endpoint that no longer existed since the identity provider was switched, and for months it looked like protection. Another case started with a vague sentence from me that the page was barely responding. The agent compared all four environments, found production affected as well although it did not even have the new version, and discovered 2.9 GB in swap. The identity service was sitting on disk, hence 9.6 seconds for the first login and 0.19 seconds for every subsequent one. No application code was involved. This troubleshooting will get an article of its own.

One lesson matters more to me than any number: A success signal is not proof. A test suite was green for four weeks while three fix attempts went right past a scroll bug, because the test had stubbed exactly the value whose wrongness was the bug. An audit report said “passed”, and only my follow-up question revealed that the decisive click path had never been executed. Both signals attest that a process ran, not that an effect occurred. Since then, verifying means finding a second, independent route to the same question. How to write test cases that deliver that will be the subject of its own article.

Case Study 2: Writing a Blog with an Agent

This blog has been run editorially with the same tool since May 2026. Back then the articles were moved from WordPress into a repository, one folder per topic with a German and an English version. Today there are 65 topics, 55 of them live in both languages. What the agent does here differs less from the app project than I would have expected.

Spec, Rounds, Revision Log

Before every article comes a spec: role in the topic cluster, target audience, search intent, outline, boundary to neighboring articles. Then the article runs through fixed rounds, from the critique of the existing text through structure and style to the English version. Every round gets an entry in a revision log and its own commit. Nine rule files carry the conventions, among them style heuristics against typical markers of AI-written text: no semicolon in the prose, at most one dash per paragraph, no first-person plural. Every one of these heuristics came out of a piece of feedback from me. The agent writes drafts, I correct, and the correction becomes the rule for the next article.

The way onto the live site remains manual. I copy the text into the WordPress block editor, set images and SEO fields, and publish. Afterwards the agent verifies remotely via live HTML and REST API. For the article on the functional aesthetics of SQL it found four defects across the two language versions that way, defects invisible in the repository because they only arise in the editor: an image that had been pointing at another article’s file for months, an SEO title that lost its last letter on paste, a jump link that led nowhere because of an old HTML anchor, and, in the English version, a link to the article on SSMS editor options that pointed at the German instead of the English version. I corrected that link twice in the block editor, and twice it stayed wrong. The agent read the post’s modification timestamp via the REST API: It had not moved on either attempt, so my save clicks had not been saves at all. The cause was the editor’s link dialog. Whoever types in the new URL and then clicks outside the dialog instead of confirming it with Enter or “Apply” discards the change, even if they press “Update” afterwards. On the third attempt the link held. The finding has been a note in the rule file for live verification ever since.

The Review Comes from a Fresh Session

A language model can also evaluate a text, and I have used that from the start. The methodology, however, I had to develop myself. While reviewing an article I noticed that a model anchors on its earlier verdicts within the same chat session: first rating about 8 out of 10, after several revisions in the same session 9.7, in a fresh session clearly more critical again. The high scores were not quality but history. Since then every review runs in a fresh session of a model from a different vendor, with a frozen standard prompt. The score is a diagnosis, not a goal.

I hand the result back to the agent as a raw paste, and it sorts it into three categories: adopt, matter of taste, already addressed. Experience from more than twenty reviews: 30 to 50 percent of the points are valid. The review is deliberately context-free, and precisely for that reason it needs as its counterpart the agent with repository context, which can look up in the revision log that a suggestion was already rejected months ago. A review is a finder, not proof. When one flagged a statement as “too absolute”, the agent’s cross-check showed it was not too absolute but wrong. What settled it in the end was a test against running database containers. These review experiences will get an article of their own.

What Generalizes

The agentic coding experience in both projects produced the same patterns. Four of them carry my daily work.

The guidance lives in the repo, not in the prompt. Rule files, specs, bug files and revision logs are the actual work. The prompts only name the entry point and the assignment. The intermediate state belongs there too: What an agent has worked out is recorded promptly as a commit or a note in the feature or bug file. Language models live on text. What is not written down does not exist for the next session.

The structuring work is the price of the gain in radius. I get an application I would not have built alone and a blog I would not sustain alone. In return I take on roles that are spread across a team: writing requirements, formulating acceptance criteria, declaring test cases, maintaining documentation.

The repo learns, not the agent. Every session starts without the history of the previous one. What was learned from a mistake exists for the next session only if it is written down: as a rule or a checkpoint in the repository. That also works backwards: Many defects I correct in old articles today were not violations when they were written, because the rule only came afterwards. The existing body ages relative to the rules that were learned from it.

Learning remains mandatory. This blog holds the position that formatting is learning: Whoever indents a statement by hand builds the mental model of the data. For agentic coding that applies with more force. Whoever does nothing but sign off loses, over time, the model they need for signing off.

Where It Gets Rough: Limits from a User’s Perspective

The limits are the part of my agentic coding experience that cost the most time.

Code Drift Despite Rules

A rule with a stated reason improves the hit rate but does not guarantee compliance, and at high volume every residual rate turns into measurable drift. The frontend case with 799 hardcoded font sizes is the evidence, and the answer was not a better rule but a check that does not get tired. The blog’s editorial work knows the same effect: Despite the style heuristics, every first draft from the agent contains semicolons or compressed notation, and I recognize AI-written text by exactly these patterns. What is in the rules still has to be checked, only the checking moves from reading to counting.

Collateral Damage in the Working Tree and on My Machine

As soon as more than one session works in the same repository, or one session works alongside me, an error class arises that does not exist in single operation. Within a good week, one agent used git add -A to pull someone else’s work into a commit on a different topic, another session committed with individually named files and still took along foreign changes from the shared index, and a third mistook the files of a parallel session for its own side effect and deleted them. Only git commit --only with explicit paths turned out to be reliable. The lesson from the first case would not have prevented the second, and that is the actual point.

A resource that rarely appears in experience reports is my own machine. To prove a sporadic test failure under load, an agent started 220 infinite loops and ran the test suite under them for twelve minutes. I noticed because my computer stopped responding. The agent sees exit codes, not a stuttering user interface. Whether a machine may be unusable for twelve minutes is for its owner to decide, beforehand. Both error classes will get an article of their own.

You Can Only Sign Off on What You Can Judge

Review effort is the new bottleneck. The answer is not to read faster but to shift acceptance: to runs instead of reading, to criteria instead of impression, to external reviews instead of my own goodwill. Each of these shifts presupposes that I can formulate the criteria and recognize a result as right or wrong. With the Node guard I could, because I knew the SQL conventions. With a script whose domain logic I could not judge, the same division of labor would be a risk.

Added to that is a weakness that belongs to the tool’s strength. An agent usually tests hypotheses systematically with measurements, and precisely because of that it hardly shows on the occasions when it builds a coherent story from incomplete clues instead. During one troubleshooting session the agent formulated a plausible cause as if it had been measured. It had not been. Since then I ask of every finding which part of it was measured.

Working Prompts as Examples

The prompts in both projects are short because the guidance lives in the repository. Three examples show what a prompt still has to do then.

Starting a revision series. Verbatim apart from the translation from German, only the internal identifiers are replaced by their meaning:

let's start the triage of the legacy articles. all relevant changes in the
articles and the lessons from revising them go into the article about agentic
coding

Two lines are enough because the spec, the work list and the rule files exist in versioned form. The agent read them, ran the first quality pass and established the material collection for this article as a side duty of the series.

Having an article reviewed externally. This prompt goes to ChatGPT in a fresh session, that is, to a model from a different vendor. It is versioned and has been frozen since August 2026. The original is German, shown here in translation and shortened:

You are a critical, independent technical editor for a technical blog about
SQL Server, Postgres, data quality and ETL. You know neither the author nor
earlier versions of the text, and you have no reason for leniency.

Rate the article in four dimensions with a score from 1 to 10 each:
technical correctness, structure and readability, SEO fitness, language and style.

Duties: Every point of criticism quotes its location verbatim. For every point
a concrete suggestion for improvement. No courtesy points. At the end, an overall
score and the five most important points, prioritized by impact.

--- ARTICLE ---

The most important sentence is the second one. Without it, the model rates the history instead of the text. The duty to quote the location verbatim makes the result sortable, because a point without a location can neither be implemented nor rejected with reasons.

A recurring check as a skill. A skill is a versioned prompt that I call with a slash command. This is how the description of the skill that checks for updates begins, verbatim apart from the translation and the replaced file paths:

Checks updates for dev dependencies (npm, Docker image declarations, GitHub
Actions) AND for the components that actually run on the VPS (OS packages,
Docker Engine, nginx, running container tags, Certbot). Writes findings to the
update documentation and to a dated security report. Keeps a history of
applied/deferred updates. Modifies nothing on its own.

The skill defines what is checked, where the result goes and what the agent is not allowed to do. For the server side it produces a checklist of read-only commands that I run myself. The acceptance criterion is the history, which shows me at the next run what was left undone.

How This Article Came About

This article is about transparency, so it has to deliver it itself. The text is a draft by the agent, produced from a spec and a material file that agent sessions kept over six weeks. Into this file, whichever session was working wrote down, on my instruction, what happened during the work, its own mistakes included. The first version was twice as long and written in the third person. That it became shorter, stands in the first person and mentions the infrastructure at all is the result of a discussion in which I asked the agent to listen first before rewriting.

My role is the same as in both case studies. I decided that this article exists and what it carries. I read the draft, discard, cut, correct and approve. I have it rated in a fresh session of another model, transfer it into WordPress by hand and check the links. What I do not do is write the text myself. And what I cannot do is in the text: write a Node script, see an effect in swap, retrieve a data point from a lost session. I had no prior experience of what this way of working would bring. What I underestimated was not the tool but the share of rules, specs, test cases and documentation that I had previously received from others.

FAQ

Can you tell that a text was produced with AI assistance?

Often, yes. Such texts give themselves away through recurring patterns. In German, in my experience, these are above all semicolons in the prose, verbless afterthoughts behind a dash, parentheses into which a whole piece of information is packed, and abstract terms that appear as the subject of a sentence and act there like a person. I have recorded these patterns in a rule file, and every draft is read against it before publication. Whether you can tell how a text came about therefore depends less on the model than on the correction pass that a human makes with a concrete list.

Can you build a TypeScript application without TypeScript skills?

Yes, under conditions. You need a model of how an application is cut, where state lives and where errors originate. In my case that came from years with .NET and databases. You need acceptance criteria that can be checked without reading the code: runs, tests, audits. And the infrastructure underneath remains a hurdle of its own that no programming language makes smaller.

How do you control what you cannot judge yourself?

Not by reading, but through a loop of checks that work without understanding the code: rules that are sharpened after every piece of feedback, skills for recurring checks, tests that have to be red on the old version, and audits with a report. The loop does not replace understanding, but it replaces reading. Every verdict has to state its open points as a condition, otherwise a “passed” travels further than its caveat.

Where do you start as a user?

With a single convention that lives in the repository and one assignment that has an acceptance criterion. Not with a large rule set, because that grows out of feedback. Anyone who wants to set up a database project with Claude Code will find a concrete entry point in the article on the open starter kit, and the mechanics behind it are explained by the cluster’s hub article.

Is the effort worth it for a solo project?

Going by my agentic coding experience in both projects, yes. The time saved on programming is largely eaten up by the structuring work. What remains is a gain in radius: a TypeScript application including infrastructure that I would not have built alone, and a blog with spec, review protocol and revision log that a single person would not sustain without an agent. The condition is that you take on the roles that project leads and teams otherwise carry.

Hub:

Infrastructure and deploy:

Rules, drift, guard:

Getting started:

Next door: