You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
はじめに「AIは速度をフロントローディングし、失敗をバックローディングする」 Opsera社が25万人のエンジニアを分析した2026年版ベンチマークレポートに記されたこの一文は、AI時代のソフトウェア開発組織が直面している本質的な矛盾を的確に言い当てている（出典: Opsera AI Coding Impact Benchmark Report 2026）。93%の開発者がAIツールを使い、コーディング速度は30〜58%向上した。しかしその代償として、PR レビュー時間は441%増大し、本番インシデント数は242.7%増加し、開発者一人あたりのバグ数は54%増加した（出典: Faros AI Engineering Impact Report 2026）。 AIは組織を速くした。しかし、強くはしていない。 3つの独立した大規模調査が同じ結論を示すStanfordが10万人のエンジニアを対象
こんにちは！逆瀬川ちゃん (@gyakuse) です！ 今日はCoding Agent時代の開発ワークフローについて、みんながやっているものからわたしがやっている手法までまとめて紹介していきたいと思います。 前回の記事 Claude Code / Codex ユーザーのための誰でもわかるHarness Engineeringベストプラクティス では、LinterやHooks、テスト戦略といった決定論的ツールでCoding Agentの出力を矯正するHarness Engineeringに特化しました。 今回はその上位にある問い、つまりハーネスは分かったけど全体としてどう開発を進めればいいのか、に答えます。プロジェクトの進め方、Agentとのコーディングテクニック、それを支えるインフラの3つの視点から2026年3月時点の状況を整理し、最後にわたし自身のワークフローも紹介します。 Agenti
AI agents didn't make the SDLC faster. They killed it. I keep hearing people talk about AI as a "10x developer tool." That framing is wrong. It assumes the workflow stays the same and the speed goes up. That's not what's happening. The entire lifecycle, the one we've built careers around, the one that spawned a multi-billion dollar tooling industry, is collapsing in on itself. And most people have
A few weeks ago, I made a casual tweet about the power and accuracy of Opus 4.5. I was trying to capture how quickly I felt things are changing when I said software engineering was close to being "done." The tweet went viral, and not in a good way. Now that they've been able to spend some time with the new model, I think more people understand where I was coming from. I meant to say that we are he
For years, I’ve felt that writing lines of code was never the bottleneck in software engineering. The actual bottlenecks were, and still are, code reviews, knowledge transfer through mentoring and pairing, testing, debugging, and the human overhead of coordination and communication. All of this wrapped inside the labyrinth of tickets, planning meetings, and agile rituals. These processes, meant to
SWET第二グループのKuniwakです。本記事では画面仕様（後述）の仕様書に対する静的検査器を開発した事例について紹介します。 伝えたいこと 画面表示と画面遷移を記述する仕様書は機械可読にできる 仕様書が機械可読であれば仕様の静的検査ができる 静的検査によって自身の担当範囲の15%の画面から計40件弱の欠陥を発見した 機械可読な仕様書にはさらなる応用が見込める おさらい：仕様とは 仕様の定義はいくつかあります。 ここでは仕様とは実装の正しい振る舞いを定める基準とします。 ある実装が正しいと判定されることを、実装が仕様を満たしたといいます。 誰による判定でも実装が仕様を満たしたかどうかの判定結果は一致すべきです。 さて実装の欠陥と同様に、仕様にも欠陥が生じえます。 本来正しいと意図した実装の振る舞いを誤っていると判断したり、その逆に誤っていると意図した実装を正しいと判断する仕様には欠陥があ
エンジニア不足、エンジニア不足と言われて久しいですが、日本でのプログラミングスクールの先駆けとも言えるTECH::CAMPさんのサービス開始が2014年なので、今や8年が過ぎようとしているわけです。 ともすると、市場に既にベテラン級のエンジニアがわんさかいてもおかしくないんですが、今でも「エンジニア採用できない」という声が絶えることないように見えます。はて？どうしたことだろうか、と思ったので今市場でどんなエンジニアが求められているのかを考えてみました。 高い技術力よりも「いい感じ」力を求めている エンジニアというと、技術を駆使して問題解決をするスペシャリストというイメージがあり、技術力が高い=優秀という認識を持つのが自然です。実際、技術力が低くてまともにプロダクト開発出来ないようでは論外だし、技術的な難問の攻略が命運を分けるケースはあるにはあります。 しかし、実際には開発プロジェクトの失敗
※この記事は、2022 Speee Advent Calendar25日目の記事です。 どうもこんにちは。まさかのアドベントカレンダー2022最終日担当、デジタルトランスフォーメーション事業本部 (以下、DX事業本部)ソフトウェアエンジニアの石井です。 私はこれまでDX事業本部の中でも特にHousii (ハウシー)という事業にメインで携わり、約2年間、「エンジニアとして事業に貢献する」というテーマと向き合い続けてきました。過去にも以下のようなテーマで登壇させていただきました。 tech.speee.jp そこで今回はHousiiを通じて得た自身の学びや実際の取り組みをご紹介しつつ、 エンジニアとして事業に貢献するとは「Why-What-Howの一貫性を保ちながら、技術意思決定を積み重ねること」である そのためには、Why-What-Howの接点に関わりながら、技術意思決定力を磨き続けること
スマホマーケットの概要と、�マーケティングの失敗例と改善 （アナリティクス アソシエーション 特別セミナー）
まえがき こんにちは。Owners Experience Backend Group の杉浦です。主にサーバーサイドのアプリケーションの実装をしています。 エンジニアとして働いていると、当然、技術的なことには意識を向けるのですが、ROI（Return of Investment = 投資利益率）を意識することはあまりないと感じたので、この観点でエンジニアリングを考察しました。 想定する読者としては、下記を意識しています。 エンジニアの方で、ROIというビジネスの概念を知りたい方 エンジニアではない方で、ROIの観点でエンジニアリングの理解を深めたい方 このため、テックブログではあるものの、エンジニアではない方にも趣旨を理解いただけるように、技術に関しては少々噛み砕いて書いています。普段、コードには触れないビジネスパーソンの方にとっても、エンジニアリングを理解する一助になりましたら幸いです。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
