montfort

What I've noticed for the past couple of days is a spike in resource consumption for trivial tasks like examining a commit or listing a directory; it goes around in circles with absurd actions, it doesn't need to diff the files in a directory to search for a single file.

I have a similar impression. I think it's because the workflow isn't fully refined, and the IDE interfaces don't match that undefined flow. These are strange times; for a moment, I felt Antigravity was what I needed, but it was just a stripped-down VSCode. I simply don't understand the new VSCode Agents window. The impact is so vast that many of us are returning to the simplicity and power of the terminal.

Exactly, that's precisely the point. They're different experiences. What I achieve now with three weeks of theoretical work, other teams achieve incrementally over several months in iterable work blocks.

The interesting thing is what you mentioned, that "no further documentation is needed." In the industries I work in, it's mandatory (with or without AI, and it's been that way for many years) to have everything fully documented from the design process onward. For me, it hasn't been difficult to work this way with AI because I know and have practiced the discipline of documenting decisions for a long time. For my clients, it's an essential accountability requirement.

These documents now have a dual purpose because they now serve to manage cognitive discipline too, so that agents do a better job than they would with vibe coding. Because without that discipline, what you say is absolutely true: AI agents do a terrible job and only hinder the good workflows already adopted by professional teams.

I suppose our opinions stem from different experiences. I don't expect AI to do all the work with just a paragraph of instructions. Some people do, and they get very poor results. I design large, complex systems based on microservices, and so far I haven't encountered any of the obvious and glaring errors that other users report. For each project, I've spent two or three weeks working on thousands of lines of specification documents, user stories, plans, and task lists, using DDD. My prompts consist of dozens of files with 10,000-20,000 lines in total. Because the implementation tasks are extensive and atomic, AI has worked very well for me in solving them.

My experience shows that AI can program like the best programmers; its code is very good when given precise instructions, just like a human. I've encountered problems elsewhere, such as anti-patterns in unwired modules, which are "large-scale" implementation errors. I'm resolving these thanks to an open source tool I'm building for AI cognitive governance, and it's yielded excellent results for me. The code produced at both small and large scales is high quality.

In my experience, people experiencing gross AI errors are doing so because they aren't giving it precise instructions. And by precise instructions, I don't mean a highly refined prompt or "vibe-coding"; I'm talking about instructions thousands of lines long, just like the ones we create when developing with human teams.

If two people are using the same model, and one reports that the AI "neglected to handle a case where a database could have multiple rows with the same ID", while the other says they can develop a huge microservices system with multiple databases without any major issues, perhaps one of them isn't using the tool optimally, based on my experience.

I understand your point, but what you're describing is exactly the kind of mistake even the best human programmer could make in a poorly managed environment. I'm concerned that since AI emerged, we've overestimated our programming abilities. The comparisons we make between our own work and AI are based on an assumption of absolute perfection that doesn't exist in reality. Bugs aren't an invention of AI; they're ours. All modern software engineering, testing systems, version control systems, and so on, were developed through years of dealing with our own mistakes. We don't make systems fault-tolerant by understanding that failures are external to our work. These failures are our doing, and now they're AI's doing too. We have to deal with applying to those agents the management that we previously applied among ourselves. The example you provide is very good, because you yourself, with your human mind that solves problems, suspect that the origin of the problem was poor communication, and you are very likely right, but just as if it were a human error, the programmer is responsible for their faulty code, but you are responsible for poor process management, and yes, the same applies to working with AI agents.

Under very specific instructions to obtain only logs and not make any changes to files, Gemini Pro 3.1 applied remediation measures by altering configuration on two occasions. It only stopped because we discontinued its use.

The profession has already changed. For the past eight months, AI has been competent enough to code like the best human programmer, but strangely, the software isn't any better yet. Everyone has lost sight of what the profession truly is. It's not just about coding; it's about software engineering. Our role is no longer that of programmers, AI has taken over that role. Our role is that of engineers who manage programming agents. Every attempt to have AI develop a medium-to-large project fails because the goal is to solve everything with a magic four-line prompt. We're forgetting the structural aspect, the engineering side. We must treat the tool as just that: a tool. The direction and responsibility remain in our hands. It's not about reviewing the code line by line; it's about ensuring that the product faithfully represents a well-planned engineering intent. That's why the concept of AI-augmented Software Engineering is so important.

TUI applications are necessary when most of your workflow takes place in the terminal, and their functions are embedded almost like a pipe into that flow. Unlike graphical desktop applications, where you find multiple ways to interact with data, TUI applications tend to be more rigid in how things are done. When it comes to covering a minimum number of user stories, and that user already works in the terminal and will continue in the terminal after finishing with my application, I opt for a TUI.

I do see the point if you focus on embedded systems that struggle running a monolithic kernel like Linux, implementing a microkernel architecture and an efficient, open user space surface to run drivers that different vendors could develop for their various products. It's a small niche, but there's some room for it.

Take a look at the AMD Ryzen AI Halo Developer Platform with a Ryzen AI Max+ 395 processor. These systems, with 128GB of unified memory and their specialized processors, deliver greater performance and inference power than Apple's Mac Studio. This already allows you to run fairly decent models for personal classification and coding tasks. I think for complex design needs you'll still require frontier models that can only be run in large data centers, but much of the underlying work could already be done on-premises.

I use my own tool (released as open source "StrangeDaysTech/straymark"), which takes blocks of related implementation tasks, builds a comprehensive prompt with auditing instructions (comparing intent against implementation), then I run agents from three different models to perform the audits and generate reports. These reports are then analyzed by the main agent to rule out hallucinations or misinterpretations of intent, and finally, a remediation plan is created. This tool can perform this task fragmentation because it's part of its cognitive governance function. Its operation is somewhat complex, but these auditable work units have a coherent structure within the overall project thanks to a knowledge graph that is built from the early design phases through to implementation.

This is a common experience for everyone. A combination of small models with overly abbreviated prompts will produce poor and faulty output. This is where what's called "prompt engineering" comes in. With practice, you'll see that detailed, well-structured, and regularly large requests will yield better results. You'll also find that you can establish dialogues with the agents to refine ideas and ask them to take structured notes before starting implementation work. The idea of achieving good results with a lot of agent work stemming from a small prompt should be dismissed. It requires a lot of conversation, planning, and design on our part. Don't give up; it's just a matter of getting used to this "language" for communicating with the agents.