Posts tagged engineering.
Seeing what agents do is a necessary first layer. The product is the layer that tells an organization whether that activity is correct, effective, and improving.
The scarce resource in an agent-enabled engineering day is synchronous, high-bandwidth thinking. Everything downstream of that conversation is execution that can be delegated live or overnight.
Someone asked me recently: where do you get so much work to kick off? I did not understand the question in the moment, and it kept bothering me the next day. Engineering has to be developing the work. That does not mean making up work. There are tiers of work engineering should already own.
Agents run autonomously for hours only where verification is deterministic. That constraint, more than model intelligence, defines what agentic work actually functions today. It also explains a split that keeps repeating, where "agent ships your code" compounds and "agent builds your business plan" disappoints.
The hard part of putting an AI agent into a team's chat is not the chat. It is encoding a complex workflow into the agent and then proving the agent does that workflow correctly.
Horizontal code agents are running on VC-subsidized tokens. Vertical agents are paying sticker price. If you're building one of the latter, you have a problem to solve, and "we have a better prompt" isn't it.
Companies picking an AI plan almost always frame it as a budget question. Which tier gives us the most usage for the money? It's the wrong question.
Every agent company hires from the same labor pool. You and your competitor employ literally the same workers: the same frontier models, refreshed quarterly by the same vendors. Raw capability is identical by construction.
We still assign a human reviewer to every pull request. The human opens the diff, scrolls, approves. That ritual is already dead. Most teams are just propping up the corpse.
The most valuable thing I do as an engineer right now isn't writing code. It isn't even reviewing code. It's building the harness that lets the agent verify its own work before it asks me to look at it.
The thing nobody talks about with AI-assisted development isn't the models. It's the cycle time. The agent's iteration loop got longer, the right way to work changed, and most people are still working as if the loop is two seconds long.
My laptop is a four-year-old Dell XPS 15 with 16 gigs of RAM. Fine for normal work. Not fine for running Windows, WSL, a real codebase, a Claude session, and a browser at the same time.
I haven't written a Linear ticket by hand in six months. I don’t write the majority of my Claude prompts. The two stopped being separate things. The ticket is the prompt.
I've been rebuilding one of my Claude Code workflows because the old version was too linear.
Your engineering team adopted AI coding tools six months ago. Deployment frequency is up. Lead time is down. PRs are flying through the pipeline. Everyone feels faster.
You're four steps into an AI agent workflow. Steps one through three went perfectly. Step four goes sideways. So you start correcting.
Three AI agents. Three different problem contexts. Each time, the solution emerged with the same architecture.
AI is forcing software development back to first principles. The practices most teams abandoned as overhead, specs, formal verification, architectural review gates, are becoming essential again the moment humans stop reading every line of code.
The distance between what you meant and what the AI produced, and why no refactoring pass can reverse it.
The software development lifecycle isn't dead. It just lost its center of gravity.
SaaS companies are all AI companies these days. How deep does does that AI integration really go, though?
Batch processing architecture has a clean pattern that scales elegantly: decouple batch systems asynchronously from everything else.
When designing data platforms, I frequently encounter teams trying to build one unified system that handles both real-time streaming and batch analytics.
Everyone's worried about AI replacing engineers. The more interesting question is what happens when the cost of building software drops so dramatically that entirely new categories of software become viable.
Every small organization has gaps. Maybe you have an engineering lead but no dedicated DevOps team. Maybe your product manager is stretched thin and the tech lead is absorbing PM responsibilities. Maybe a designer role is emerging, but nobody owns it yet.