tohuwabohu

This reads awfully familiar. Recently a colleague retired. The company knew about that in advance and did: Nothing. No handover prepared. No knowledge transfer planned. Nothing. Poof, 30 years of institutional knowledge gone. No problem, we have AI.

For some reason managers now vibecode greenfield projects and ask experienced engineers to fix their mess. I asked for functional documentation. What did you feed the prompt? What gap tries this project to fill? What are the use cases? What exactly are you going to deploy? They don't know. They tried retrofitting that info through AI but didn't even bother to read the results, nevermind validating them against the actual behavior of the application. Because, render me surprised, this requires domain knowledge and getting your hands dirty.

So I dug through the generated code and found 200 issues. Invited them to a presentation where I tried explaining that we're looking at 2-4 years of worth of backlog. Those are only technical ones. Of course they had already pitched the idea of going live within two months to the C-suite. Great, now please define a feature set as MVP and I'll see how to patch it up so it won't blow up in your face. Maintainance of a product that large will provide enough work for a team of 6 engineers working fulltime on it.

They were not having any of that and instead started challenging my estimates. You must deliver one fixed issue per day - through AI. We will retrofit the docs to figure out what the application does - through AI. Why did you not create the functional docs through AI during the review. AI here, AI there. Let's skip code reviews with AI. AI is the solution. Let's onboard more engineers through AI. Let's use math to make that number friendly: 200 issues / 3 engineers = 67 days until all issues are fixed. Problem solved.

That thing that I became captain of. Is it even a ship? I can't tell anymore.

It will be interesting (read as: bad) times to get to that point and I agree. The Junior market is basically not existent ever since coding agents appeared, stripping the industry of its future Seniors. We will be chained to our desks.

I use my own brain to sketch out what I want to work and how. Before writing any code, I use the LLM to point out gaps and how to close them. Pros and cons of certain decisions. Things you would discuss with colleagues. Then, I come up with a plan for the order I want the code to be written in and how to fragment that into smaller, easy to handle modules. I supervise and review each chunk produced, adapt code mostly manually if required, write the edge case tests - most importantly, run it - and move to the next. This is how I use it successfully and get results much faster than the traditional way.

At my job though I can witness how other people use it. I was asked to review a fully vibecoded fullstack app that contains every mistake possible. Unsanitizised input. Hardcoded tokens. Hardcoded credentials. 2500+ LoC classes and functions. Business logic orchestrators masquerading as service. Full table scans on each request. Cross-tenant data leaks. Loading whole tables into the memory. No test coverage for the most critical paths. Tests requiring external services to run. The list goes on. Now they want me to make it production ready in 8 weeks "because you have AI".

My point: This was an endorphine fueled vibecoding session by someone who has no experience as developer, asked the LLM to "just make it work", lacking the ability to supervise the work that comes with experience. It was enough to make it rum locally and pitch a "system engineered w/o any developer" to management.

Those systems need guidance just as a Junior would and I am strongly and loudly advocating to restrict access to this incredibly useful tool to people who know what they do. Nobody would allow a manager to use a laser cutter in a carpentry workshop without proper training, worst case is they will burn down the whole shack.

I appreciate you having a open mind about it at least. I needed some time to adjust as well. I don't even use Opus, most of the time my workflow consistently produces usable code with Sonnet. Maybe you can try what I explained initially? Just don't try any language you're not familiar with, that will not end well.

That's awesome, I was looking for a tool like that. Rust, tauri and SvelteKit is such a nice stack to work with, I've been using that setup myself for a while now.

This one: https://github.com/thwbh/tauri-typegen

It generates the typescript boilerplate required to invoke tauri commands from the frontend and allows optional zod validation with graceful error handling and type coercion for runtime type safety.

I get your point, but in this case the author of the article has quite a lot of public projects hosted on github and actively contributes to various organizations while claiming most of his code is written by AI now.

As the author of minijinja, he wrote a whole article about his experiences porting from rust to golang: https://lucumr.pocoo.org/2026/1/14/minijinja-go-port/

The code is here: https://github.com/mitsuhiko/minijinja/tree/main/minijinja-go

I myself used claude to create and maintain a publically available tool for tauri. To my surprise people actively use it without me advertising it even once.

Yes it will, while at the same time augmenting experienced developers that know what they're doing. I evaluated Claude code for a month. Does it help building simple, well-defined tasks faster? Yes. Do I imagine it working well in a large scale project, maintained by multiple teams? Absolutely not.

I'm working on a page hit counter that I use to track visits on my personal websites. To make it challenging, it runs on quarkus with hibernate reactive and deploys to a serverless environment. So far it had no usable admin UI, prompting me to stitch together a React UI lib with a look & feel inspired by TUI applications.

Think keyboard navigation, visualisation through ASCII characters etc. but some of the convenience that comes with modern webapps. The goal is to create components that mostly work out of the box to use with my personal projects.

I felt the same about Stardust Crusaders but pulled through. The second half is substantially better with E34 (D'Arby the Gambler) being my favorite episode of the show.