Been coding since I was a kid, MSc computer science, into programming languages (https://www.firefly-lang.org/).

We tried a few agentic coding tools at work, but they didn't really help.

Along came a project that required us to build a custom harness. One day we added some very basic coding tools to the harness at a whim, and it just immediately (and surprisingly) blew away everything we'd tried.

Now we do most coding through that, and it's a clear productivity boost (2x?). It still requires hand holding and review, and some amount of manual fixing.

But being able to build things much faster is a lot of fun.

For sure! I offload most work, except the "idea", rarely any domain-specific logic, and rarely any core design / architecture.

Mostly I treat the coding agent genie as a code calculator, building a plan, writing code, running tests, reviewing other code with scripts...

Fine to allow the genie to pick an idea from a queue of work, "what is most urgent and important" but not fine to go with whatever the genie thinks should be done - that's a fast track to building something you don't need yet.

I also run a pair-programming session once a week with my team where we direct the genie as a "third" person. It's important to me that we still socialize around the work, even if the genie is involved. Sitting around the pile of code on the table and riffing together is fun. Just because every team member has Claude doesn't mean we stop gathering around the table once a week.

Generally though, the enjoyment comes from the same problem-solving enjoyment I had when writing code before coding agents. It's fun to create things, fun to fix things.

The challenge is managing the addiction. I try to be done with any coding focused task by 2 pm, that let's me wind down and avoid any late into the evening wrap up. I'll spend the final hours of the workday reorganizing plans, reviewing PRs and admin tasks like email, IMs, etc..

Remember even though your enterprise is paying for your tokens, they are extracting 2x, 3x, 10x maybe even 20x the value from you with the heightened productivity from coding agents. If you have equity, let it rip ha but if you don't, take some of that productivity back for yourself.

> take some of that productivity back for yourself.

Truer words hath not been spoken.

Does a burger flipper enjoy flipping burgers all day? - Not unless you're a robot. But Making a Gourmet burger without time pressure? - yes No it is not enjoyable if you have enjoyed coding by hand earlier and like your craft. Maybe for some grunt work or work that you could never do it is great. I've given up trying to enjoy at professional work.

What kind of setup do you have where implementing things is as easy as flipping a burger?

As I've more reliably produced reasonable quality code with automation I've found my joy coming from coding solutions to my own day-to-day problems and less to do with solving the problems I'm employed to solve.

It's not a bad thing IMO, the work is still getting done to a high standard but I have to look elsewhere for the satisfaction that used to come from doing my job well.

I think I feel the same in the sense that AI now allows me to choose more carefully what I'm actually working on and offload boring other tasks to the AI. Of course, it only works as long as the deadline allows it.

> As I've more reliably produced reasonable quality code with automation I've found my joy coming from coding solutions to my own day-to-day problems and less to do with solving the problems I'm employed to solve.

Not the best job security.

I no longer care whether I am productive at work.

I'm enjoying myself, but then again I'm not currently employed, so not in your target audience.

Related: Anyone looking for a nerd in Berlin, mit B1 Deutsch?

I'm working for myself (own product, decently profitable SaaS, been in production for 7 years now and used by actual customers), so I'm not sure if I fit your "employed" category or not. If I do, then here's my setup:

1. I have a custom-built minimal flow of 5 "commands", that take an idea to implementation through capturing intent, impact analysis, iterative planning, execution orchestration and then review/demo. each of these effectively builds up a single shared plan file. The intent command takes one or two lines of free text and turns it into a structured intent document (goals/anti-goals/constraints...); impact-analysis takes the intent document and maps it to the codebase, looking for functional gaps and things that need to change. iterative-planning takes the result of the impact analysis and splits into tasks/phases that are independently verifiable and deployable, and builds a task list... so they all build on each other, and update the same plan file that sits in git and I review it as it goes through the pipeline

2. we have a minimal CONTRIBUTING.md that explains the shape of the workspace and the key rules how to work, that's applicable to humans and agents. CLAUDE.md loads it from @CONTRIBUTING.md

3. the guardrails of what the agent is allowed or not allowed to do mostly sit in deterministic tools, such as custom linting rules, custom style checks, and they are all invoked from eslint via the custom language plugin. this has grown to thousands of rules, linting programming language code but also html, scss, yaml, liquid, markdown.... Eslint runs as a post-tool use hook on edit and write, so each file an agent writes gets immediate feedback and fixes. when we catch the agent doing something it should have not done with the code or docs, we get it to write another custom rule with unit tests for the rule. With each rejection Claude also gets a helpful message what to do instead.

4. there's a "regulator" script that helps us avoid decision fatigue for approvals. it runs as a pre-tool use hook for Bash commands, does deep parsing of whatever sausage Claude wants to run, goes into loops, function definitions etc, then goes through our rule set and approves/rejects or forces an ask. With each rejection Claude also gets a helpful message what to do instead. (e.g. don't run npx, use eslint directly from the path). Each time claude asks, we run the command through a debug script to understand why it's asking, and add another rule.

5. the latest addition is an orchestrator script that takes our plan file format and turns into Claude Dynamic Workflow descriptions deterministically, and parses the progress of the workflows so suggest what's slow and what can be moved out of LLM processing to deterministic tools. This significantly reduced the token spend (now running at about ~20% of the token spend for workflows before) and time (from average 5-6 hours per workflow to about 20-30 minutes). It also removed the 10-15 minute wait that we had while claude was LLM constructing workflows from our plans.

6. there's a demo command that flies through the user interface based on the plan to demonstrate what users see with the new version, recording it to webm using playwright, and I can play it at a higher speed to quickly get an overview what an agent did.

7. we tend to look for ways to get faster feedback on things that agents repeatedly do badly, such as UX or UI changes. We have a set of static HTML pages with the visual design language, showing styling for key elements and components, and a set of static demo pages showing key application pages with realistic data in lots of different states. as part of the impact analysis, agents will update demo pages or add new ones so we can review/complain. there's a script that audits demo pages for WCAG and other styling issues. another example are end-to-end api tests, which evolved massively to prove api contracts but also allow agents to get their own feedback and troubleshoot quickly. generally, divide and conquer for feedback.

This tends to work generally well. I feel productive. I still review most code when it completes via git diff, but it's mostly clean because the linting rules are forcing it to write code the way I want it to be written. We use a method based on the attribute-component-capability matrix to figure out what needs manual exploratory testing and how much, and do that in addition to automated tests when needed.

happy to provide any more info if you're interested.

I think it depends on where you work at and your team.

If you come from a good team with high quality engineers around you, I imagine the experience is not as good, or if you work in a big company where on your daily job you just owe a very small slice of the whole pipeline.

I have worked on several companies where my colleagues were very mediocre on software engineering fundamentals (I'm in AI before ChatGPT a lot of Jupyter Notebook warriors [Data Scientists] having to put stuff in production for midsized companies) and very average engineers, who wouldn't really care implementing patterns, tests, linting, documentation etc...

At the risk of sounding arrogant I always wanted to be able to just 'clone' myself and keep my code discipline consistently on a project, I would push a high quality PR with good test coverage and the cleanest code I could muster, while my colleagues would approve between each other PRs with no test coverage, no linting, horrible technical debt or with work arounds around linting, making my effort moot as the slop overwhelmed any quality I tried to implement. Not just one company, 3 companies I have seen the same experience.

Also I was a full stack AI engineer in the fullest sense of the word, I did devops, deployment, proxy set up, ci/cd pipelines, backend, frontend and AI, on local servers, no external team to deploy for me, no external team to qa for me all myself, with great flexibility (my manager was completely non-technical) to try different stacks and use AI assisted coding where I forced i my AGENTS.md for codex to destroy every code, or feature I was writing as a Staff engineer, allowing me to learn a lot and upskill autonomously extremely quickly.

With this knowledge, I set up my side project where I locked in a good stack, applied solid patterns from the beginning, extensive static checks for code (extremely strict linting, testing and coverage checks) and my trust on AI grew with the project and I catered exactly to my way.

The initial commits I used it to write extremely clean code almost by hand, checking every line, locking in the stack, the linters, testing methodology, tdd methodology, etc, and I was slow but writing very clean code and setting up code examples.

Once I noticed my progress was going slow, and was noticing the AI was getting prompted by my clean code as it read the files to suggest the next lines, I started letting it go more autonomously but checking every line of code, I set up a lot of markdown files on how to test, how to code, code styling, the architecture and the patterns and would make it mandatory reading to the ai before starting, with the existing 'clean code' I got really good results, I just had to enforce the discipline that I could not enforce on my colleagues.

With the memory system in claude code and countless iterations of fixing AI mistakes and not doing stuff the way I liked it, I arrived by myself on a very similar position as Steve Yegge on me and Claude converging to a set of laws and strict way of working, and I just have a lead orchestrator agent and subagents, where I pick the issues and check every PR before merging, and merge by hand always.

This includes a specific cycle of each subagent taking a worktree, symlinking to the .env, checking if the subagent will use Playwright (spin up it's own server) and estimate the RAM memory usage (I have allocated 15GB for programming), forcing subagents to run tests with their own Haiku subagents to not pollute their context, the orchestrator scoping the implementer subagent to Sonnet or Opus depending on complexity, every subagent gets a separate reviewer that enforces the ARCHITECTURE.md and ticket goals and runs mutations on the tests done by the implementer subagents (they are forced to implement with TDD).

It is it's own ecosystem coding exactly how I like, without complaining. My initial clean code few shots the AI on keeping high code standards and there is naturally some smell, but my reviewer agents enforce separation of concerns very strictly, I know the smell is contained and if it becomes an issue on my application I can easily refactor it without breaking the rest, which I think is the most important aspect on agentic development, accept the tradeoff of the speed, and keep it contained.

For example on every issue, my orchestrator will assign the implementer subagent exactly which files it can touch, and explicitly which ones it cannot touch. The orchestrator knows what all the other subagents are doing, and this helps prevent conflicts when you have 5+ running in parallel.

It's a lot, but it's wonderful ONLY if you have full control on the whole process. Having to work under someone else process must be a nightmare. So it's a very mixed bag I would say. However for me after so many iterations and convergence I'm extremely pleased, and am a big advocate for it, but you need discipline, and a high skill ceiling on what you are doing, and know how to build things.