I Am the Bottleneck. We Are.

A few minutes before I was going to commit my code, much of it appeared to disappear.

I was working on a transportation management system for a client. Some invoicing changes had been made from Halkidiki, Greece: working in the morning, beach in the afternoon. I had relaxed one of my usual habits, though. Instead of committing each finished feature, I let a larger batch of uncommitted changes accumulate.

Back home, I finished and asked my coding agent to commit and push everything. There should have been around thirty modified files and eight new ones.

Instead, it found two files.

Five minutes earlier, the changes had been there. I wondered whether Cursor's file view was misbehaving. Had the agent run a Git reset? I checked the conversation and asked. It said it hadn't.

I asked another agent, through Codex, to investigate. It found a series of “Undo reject diff” events in Cursor's history shortly before the disappearance. The missing changes were there, and we recovered them. What we never established was who or what had triggered those events.

This happened on September 25, 2026. I still don't know exactly why.

I'm used to AI agents making mistakes. Usually, when something goes wrong, I can inspect the code, improve the instructions, or ask another agent to review the work. This time, for the first time, I felt genuinely insecure about a process I had carefully designed and trusted.

And it brought me back to a thought I have increasingly had over the last two years: implementation is becoming astonishingly accessible, but responsibility hasn't disappeared. The bottleneck has moved.

From coding to directing work

Hi, I'm Bogdan. I've loved programming for most of my life. I've worked across more than twenty languages and frameworks, I run a small software company, and I teach at a university. I'm a geek, and I love the tools becoming available to us.

Two years ago, I was a senior software engineer at an international startup building augmented-reality instructions. I led an instruction-translation feature. I gathered requirements, designed modules and interfaces, chose technologies, prototyped, coded, and tested.

I could implement quickly. One of my most useful contributions, though, was introducing a manual testing flow: actual people systematically checking the software, because the team lacked a coherent end-to-end test process. Fast code is not the same as a verified release.

Today, I still discuss what stakeholders need. I still make architectural decisions. But I no longer need to implement every part myself.

I describe the desired behavior and architecture, then guide agents through implementation. They help with research, code, documentation, browser-based tests, acceptance checklists, and debugging. I can try ideas that once would have demanded far more time and specialist knowledge.

For someone running a small company, that's empowering. I don't have a large team. I do have tools that allow me to attempt more—as long as I can guide and verify the work. And I genuinely love exploring approaches I might never have discovered on my own. My time, curiosity, and capacity to learn increasingly set the limits.

But I don't simply say “build an application” and hope for the best.

My development environment has more than thirty documentation files and conventions. Entry documents point agents toward relevant architecture, standards, and working style. I care about code consistency: shared patterns, familiar technologies, and systems that someone can maintain later.

Sometimes I ask an agent whether it actually followed our working style. The answer amounts to “mostly, except here.” Then we fix those parts.

I use Cursor extensively for coding, alongside Codex and other agents with specialized roles. I've built a handoff process so an agent handling sales or research knows when an engineering task belongs with a coding agent. This isn't a magical autonomous company. It's a system I keep designing and improving.

With good requirements, implementation can be incredibly fast. During work on an expenses module for a transportation management system, I saw agents execute substantial functionality and test it using the context I had prepared.

I was proud of how the system worked. The agents had tested it, and I also tested it myself. Nothing went wrong in that case, and the result made me proud of the development system I had designed. Final verification was still my responsibility.

The hard part comes before the prompt

The most demanding part of my job is often discovering what a client actually needs—not simply repeating what they first ask for.

AI makes meeting transcription and initial analysis much easier. In one project, roughly four hours of discussions became twenty-one large requirement packs and sixteen initial questions for the client.

Those sixteen questions didn't end the discovery process. Their answers generated more questions.

That's not a failure. That's the work. A client can describe an editable field or a button. I need to understand what problem the change is supposed to solve. What value are we trying to deliver? What is the smallest useful change? How will the people using the system know it works?

AI can synthesize conversations and propose sensible answers, but it can't replace agreement between the people involved. It also shouldn't quietly make commercial or operational trade-offs on their behalf.

This is one place the bottleneck has moved: from producing an implementation to deciding what should be implemented, and why.

And it moves downstream as well. Someone must verify whether the result is correct, maintainable, appropriate for the client's environment, affordable to operate, and ready to deploy.

“Use best practices” is not a complete specification. Two recommendations may each be reasonable and still pull a system in different directions. I want technology I can understand, and that the client can use naturally.

The work of engineering is increasingly about coherent decisions, not just lines of code.

When another system breaks

I recently helped investigate defects in a medical software system that analyzed biological features. I wasn't its original developer, and I didn't need to personally rewrite everything.

Instead, I guided agents through the investigation. I questioned their assumptions, asked for evidence, narrowed the issues, and directed fixes. Some problems could be addressed immediately; other work was left for later. We made important progress within a short engagement.

That experience reminded me why my hands-on background still matters. I knew what to ask, how to test an explanation, and when an answer wasn't sufficient.

But it also raises a difficult question: if agents handle much of the implementation, how will future engineers learn to investigate a complicated system they didn't build?

I don't have a complete answer.

I used to feel proud of adapting to a new programming language within a couple of weeks. I still value that skill. But syntax is no longer the only gateway to making something useful.

I would encourage young people to develop logic, curiosity, communication, architecture, and the habit of experimenting. Coding is still a good way to learn those things, even if the final program is generated.

Define the problem. Make a hypothesis. Try something. Observe what actually happens. Check the result. Learn from it.

I've been inquisitive and experimental since I was a child. I hope we keep cultivating that geek or hacker mindset in the next generation.

Will relying on AI make us less capable? Perhaps some skills will get less practice. But human beings have always adapted to new tools and new kinds of difficulty. The challenge is to keep the ability to understand, question, and intervene—even as our tools grow more powerful.

A bottleneck outside the IDE

There's another uncomfortable truth about my own career. My technical capability was never my only constraint.

I could build sophisticated systems, but I didn't always know how to sell what I could do. Building more software did not automatically bring more customers.

So I've also begun using AI to help with business development: researching potential clients, identifying possible problems, tracking relationships, and preparing outreach. I created a system around a sales operator agent. Some experiments failed. For example, I discovered that early cold emails weren't reaching people as I expected.

Having an agent send messages doesn't make the messages valuable. It doesn't create trust or genuine interest.

Again, the bottleneck is understanding people: what they need, whether I can help, and whether the work would actually create value.

I want technology to serve people in their real situations—not demand that they adapt to whatever happens to be easy for an engineer or an AI to build.

What remains human

I have another reason to care about this distinction. I sometimes struggle to express myself in written English as well as I think. I've written scientific papers, but an essay is something else. I'm a geek, not a professional essayist.

I dictated and manually edited the original essay for a writing challenge. I respect the value of genuinely human experience, and I also see a meaningful difference between asking AI to invent a perspective and using it to communicate one rooted in lived experience.

The ideas here came from my work, my projects, my doubts, and my mistakes. AI has helped me express those ideas more clearly in this public edition—much as it helps me express software requirements and turn them into working systems.

The strange thing is that the more implementation becomes accessible, the more the quality of our intentions matters.

We still need people who can ask good questions, care about consequences, test what they are told, and take responsibility when something goes wrong.

AI makes me more capable of creating, researching, developing, and learning. It also makes me more aware of what I cannot delegate: deciding what is worth doing, recognizing whether the result serves its purpose, and owning the decisions along the way.

I am the bottleneck.

We are.