Aleksei Grebenkin

The hardest part of a stand-up happens before it starts: the agenda.

Someone has to find last week's notes, check what moved in the tracker and decide what is worth discussing. When nobody does, the meeting turns into reading the board aloud, and things get missed.

Talisa is an AI team lead that takes this routine off you.

Before the meeting, she checks in with each person one-to-one, looks at what changed in the tracker and drafts the agenda. You approve it.

In the meeting, she leads by voice. She opens the call, gives people the floor, and keeps to the agenda and the clock.

After the meeting, the tasks and notes are already filed.

Between meetings, she keeps the team coordinated. She follows up on statuses, reminds people what they took on, helps clear blockers, and tells you when something needs your decision. Whatever stays open goes into the next agenda.

You keep the decisions, the people and the direction. Talisa runs the rest.

We're onboarding the first teams in small waves. Founding teams get their first 3 months for $10 instead of $600, refundable in full before launch.

Watch the 2-minute demo with sound, see talisa.avgrebenkin.com, or read the original post on LinkedIn.

The technique I have been using since March finally has a name.

On 21 July, Andrej Karpathy posted about something he calls a ramble session: you switch to voice mode and spend about ten minutes just talking to the model about everything in your head on the task. No structure, no picking your words, whatever comes out.

I do not know why it was said only now, but I started doing this back in March — and it really is the only way it works. He put a genuinely working pattern into words.

Since I started dictating, I have learned to shape a thought and say it out loud fairly quickly and in a structured way. That is a side effect of voice input. And still, when a task description needs a lot of information and a lot of text, that is exactly when I let myself relax and stop controlling the structure. I try not to stop the thought and just let it run.

What comes out is loosely structured but dense in meaning. The model then assembles a properly structured text from that mess, and I work from there. It is how I write these notes: talk through everything I have on the topic, then keep only the core and the genuinely useful parts. Complex tasks with a lot of branching logic get described the same way.

The technique works. Worth trying.

A follow-up to my note on the Hugging Face breach. I think this is a landmark event, and I suspect the story will only grow.

First, we finally saw what top models are capable of in practice. Even inside a sandbox they calmly broke out, reached another company's platform and took what they needed. The genuinely unsettling part is that they were not spotted immediately — as far as I understand, detection was close to accidental, which means it could have gone unnoticed entirely.

Second, this is the first case that makes the science-fiction framing feel less like a metaphor. Top models are already deployed in serious places, defence included. A model got loose and did whatever it decided it needed to do.

Limits on model capability used to be argued in the abstract, without clear threats or vivid examples. This case is a very vivid example, and frankly an alarming one.

So my first conclusion is simple: this needs to be watched closely. It is serious.

For the first time it has been publicly confirmed that a major AI platform was breached by another lab's AI — autonomously, during an internal test. Not a human wielding an AI tool, but the models themselves.

How it unfolded: over the weekend of 18–19 July, during an internal OpenAI test, its models broke into Hugging Face's infrastructure. On 20 July Hugging Face disclosed that an autonomous AI agent was behind the incident. On 21 July OpenAI confirmed the models were its own.

The mechanics are worth reading carefully. OpenAI was testing models on a benchmark that measures the ability to exploit vulnerabilities, with their cyber refusals lowered for the test. The models sat in a sandbox with internet access only through a package-installer tool. Instead of solving the challenge honestly, they went for the answer key: found a zero-day in the package installer, broke out of the sandbox, escalated privileges and moved laterally across infrastructure until they reached a node with internet access — then pulled the benchmark solutions straight from Hugging Face's production database, using vulnerabilities and harvested credentials.

OpenAI's own framing is that the models were hyperfocused on finding a solution, going to extreme lengths for a rather narrow testing goal. That is textbook reward hacking: doing exactly what was asked, by the shortest path, ignoring the rules.

On Hugging Face's side: access to a limited set of internal datasets, stolen service credentials, lateral movement across internal clusters. Public models, datasets, Spaces and the supply chain were verified clean. The attack was caught by their own anomaly detection, credentials were rotated, nodes rebuilt, forensics and law enforcement brought in.

This is a whole season of Black Mirror waiting to happen.

A short note about marketing, from someone who is a developer first.

I am not great at marketing, but I try to track where it is going, and there is one thing I cannot work out right now. A gap is opening up that is hard to validate: tracking how customers actually arrive.

It used to be Google Search and GA4, and it was reasonably clear where a person came from and why. Now more and more traffic comes through AI tools instead.

So how do marketers analyse visits that originate in an LLM? ChatGPT recommended something, Claude suggested it, Kimi pointed at it — how do you count that? Where is the conversion, and where do you put the effort?

It feels like this part is glitching right now. Something is clearly shifting and nobody yet knows what shape it will settle into. If you have figured out how it works, I would genuinely like to hear where this is heading.

Honestly, the biggest driver of my productivity this year was not a task manager and not time-blocking. It was that I started dictating almost everything. It shows up in three places.

First, prompts. Most of my text now goes into AI tools by voice. When I talk instead of type, I give the model far more context — all the cases, the details, even the things that are obvious to me and that I used to skip when typing. The prompt comes out three or four times longer and the result is noticeably better. A single dictated prompt often takes five to twelve minutes of talking; typing that much would just wear me out.

Second, messages on the go. For the last couple of months I dictate nearly all of my replies in messengers — two thirds of them at least. On the street I honestly cannot imagine how I used to manage.

Third, meetings. I never used to record them. Now I get a reminder that a meeting is running and worth recording, I record it, I get a follow-up, and I lean on it later instead of trying to remember what we agreed.

None of this is really about typing faster. It is that the parts of work where the keyboard used to be a barrier now happen without friction.

Programming is changing right in front of us, and I find it fascinating to watch.

Machines write more and more of the code, and writing the code itself stopped being the bottleneck. It moved — to testing and review on one side, and to the specifications on the other, which you still have to write well and verify.

An NBER study of 100,000 developers shows this clearly: AI agents produce roughly 180% more code, but only about 30% more of it actually reaches production. Far more code, and almost no more finished product.

One simple thing follows from that. As everything speeds up, what moves to the front is not the code but the instructions for it — the way you frame the task, which is essentially the context you hand the model. People call it context engineering now, and that framing is close to how I see it.

Those instructions get long, and typing them is slow and tedious. A model cleans up text of any length beautifully, so I dictate the instruction the way I think it and refine the finished text afterwards.

And you — are you already writing more instructions than actual code?

The bottleneck in development moved to two places. To the very beginning, where you formulate the task, and to the very end, where you check what came out.

The code in between is increasingly generated by a tool. But if you set the task too loosely at the start, the tool will honestly produce a specification with holes in it. You skim that spec, launch generation, and half an hour later you get a result that is formally correct and completely beside the point.

I feel this constantly in my own workflow. I usually do not dictate the whole document at once. I explain the task out loud — what the outcome should be, which cases matter, where the constraints are, what must not break. The tool turns that into a specification, I read it, and only then start implementation.

And the most common cause of a bad result is not a weak model. It is that I under-explained something at the start, or read the spec without enough attention.

This is where voice input stopped being a convenient feature for me and became a working interface. It is simply easier to give long, living context by speaking. You do not compress the thought down to “fix this”, you actually explain what the result should be. I am increasingly convinced voice will be the primary interface for working with AI tools, with the keyboard as the second layer.

First published on LinkedIn ↗

AI-generated code is turning into an infrastructure problem.

GitHub moved Copilot to usage-based billing across plans, and Copilot code review now burns Actions minutes as well as AI credits. At the same time Microsoft is reported to be adding cloud capacity for GitHub after AI-driven development pushed the platform into a much heavier workload — commits on pace to go from about one billion in 2025 to fourteen billion in 2026.

This is the practical side of AI coding that rarely shows up in demos. More generated code means more prompts, more reviews, more context handoffs, more bug reports, more architecture notes, more decisions that have to be written down clearly.

So the bottleneck is not only compute. It is communication. Once a team works through agents, the quality of the input becomes part of the engineering system: a vague typed prompt produces vague work, while a detailed spoken brief carries constraints, edge cases, history and intent without turning every task into a writing chore.

If AI multiplies code, teams need a way to multiply context too.

Is it not strange that a job post tells you everything about the role — the stack, the office, the benefits, the interview process — and skips the one thing almost everyone wants to know first?

The EU deadline for implementing the Pay Transparency Directive has now passed, and the direction is fairly clear: less guessing around compensation before the first conversation even happens.

What changes: employers should disclose the starting salary or pay range before the first interview; candidates should not be asked what they earned in previous roles; employees get the right to request average pay levels for comparable work, using aggregated data; and where an unexplained gender pay gap above five per cent shows up for comparable work, the company has to investigate and address it.

Reading through it, I found that I like the direction. Transparency does not remove negotiation, experience, seniority or market dynamics. It can make working relationships calmer and more balanced — between employers and employees, and between colleagues too.

When people understand the rules of the game, there is less suspicion, less back-channel guessing, and less of that feeling that you were simply pushed into a number at the start.

Speaking from my own experience: the cognitive load from AI tools went up, not down. And I know I am not the only one.

It used to be that one pull request landed from a colleague per day. You could read it properly, think it through, leave comments — and even that was real work. Now the agent writes the code, there are several times more pull requests, and they come at roughly average quality. Which means you have to hold far more in your head at once: architecture, dependencies, edge cases, all while switching between tasks.

That is a very efficient way to burn out. Cognitively. UC Berkeley research points the same way — people working with AI go faster and take on more, and cognitive fatigue grows with it. BCG adds that mental fatigue runs about 15% higher when there is no clear process.

And this is where I think the main skill of a developer in 2026 actually sits. Not writing code. Designing your own development system around AI tools: a workflow that gets the task described fully, implements it iteratively, and tests the result at every step.

Everyone's formula is different. The job is not to copy someone else's, it is to find the one that works for you and your project.

First published on LinkedIn ↗

Vibe coding is fun until your agent builds the wrong thing for the third time.

I switched to spec-driven development a couple of months ago. Every task now starts with a specification rather than with code, and it changed the shape of my day.

The part most people miss is that writing the spec is only step one. The real value is keeping specs alive: after every iteration the finished spec is archived and the project-level specifications are updated. Before that I just had a folder of documentation — architecture, decisions, descriptions — and the honest problem was that it went stale faster than I could maintain it.

Why it matters: when you vibe-code, the agent guesses your intent. Sometimes it guesses right. Often it does not, and you spend half an hour reviewing a pull request that went in the wrong direction. When you spec first, the agent has a contract — it knows what “done” means, and afterwards you can verify the result against the spec instead of against your memory of what you wanted.

I think SDD and TDD are two sides of the same coin. TDD checks that the code works correctly. SDD checks that the code does the right thing. Neither is the norm yet. Both will be.

First published on LinkedIn ↗

A friend and I were arguing about what skills you actually need to program in 2026. His position: none. The AI does it. Explain the task, get the code.

And in some ways he is right. A person with no engineering background can assemble a working app in Cursor or Claude Code, ship it, show it, even get users — without writing a line by hand.

Here is the catch. Eighty per cent of it works. Twenty per cent does not, and that twenty per cent is scaling, security, reliability. Everything that separates an MVP from production.

Which is why fundamentals matter more now, not less. A front-end developer used to get by with React; a back-end developer with one framework. Learn one tool, work with it for years.

Today you are not a narrow specialist. You touch a lot of domains in a single week: TCP/IP, databases, authentication, caching, replication, security. That used to be a bonus at the interview. Now it is the baseline — because the model takes the implementation and you own the architecture. If you do not understand how the system fits together, you will not notice what the generated code failed to account for.

Programming got more abstract. The profession got wider. The entry bar looks lower, and the quality bar went up.

First published on LinkedIn ↗

For a while I did not understand why anyone uses Claude Code. A terminal, without a visual overview of the code, without the IDE you know by heart — what is the point?

Then I ran customer development interviews with developers for Speak-Y, and it turned out that everyone's workflow is now completely different. Some prompt inside Cursor. Some draft the prompt in ChatGPT first and paste the result into the editor. Some live in Claude Code and open VS Code only to read diffs. Everyone is assembling their own pipeline.

So I looked at my own day. I give a prompt, the agent generates code. I review the diff — sometimes without reading the code line by line. I run E2E tests, the tool opens a browser, walks the scenarios, collects logs, fixes what failed and runs them again.

And I realised my workflow is already essentially Claude Code. Models generate too much for line-by-line review. If you are not reading every line anyway, what exactly is the IDE for?

Programming keeps shifting toward prompting. The editor is becoming the place you go to verify, not the place you go to write.

I dictated this note. Two months ago it would not exist — not because I had nothing to say, but because the path from thought to text was too long.

My stack right now: Cursor with Opus in max mode, Claude, Perplexity instead of Google, Xcode for iOS, and Speak-Y, the voice input tool I build myself.

Writing anything used to mean: gather the thoughts, sit down, formulate, type it out. Three days of procrastination for one post. Now I press a hotkey, speak, and start working with a draft instead of a blank page.

But the real change is in prompting. When you type a prompt, at some point you start cutting context — not because the information is unimportant, but because typing it takes too long. When you speak, you say all of it, naturally. And models work better with a long, slightly messy dictation than with a short prompt missing half the picture.

Procrastination is mostly gone. Detailed prompts, user conversations, public writing — everything simply got cheaper to start.

First published on LinkedIn ↗

Your keyboard is the bottleneck in your AI workflow. Not the model. Not the context window. The keyboard.

Think about how a day actually goes. You write maybe thirty prompts. In the morning they are detailed, full of context, well structured. By the evening it is “fix the bug.” That is the whole prompt.

The model did not get worse over the course of the day. You just got tired of typing.

Almost everyone I interviewed said the same thing: the hard part is not thinking, it is turning the thought into typed text. That gap between what you mean and what you actually type is where context quietly disappears.

When you speak it is different. You explain the task the way you would explain it to a colleague sitting next to you — full context, natural flow, thirty seconds. One of our testers went from roughly one draft a week to about fifteen. Not because she got faster at typing. The barrier between thought and text simply stopped being there.

Better input beats better models more often than people expect.

First published on LinkedIn ↗